diff options
294 files changed, 35251 insertions, 10290 deletions
diff --git a/dist/bind/CHANGES b/dist/bind/CHANGES index 362cf17e0ae..aea126caaa5 100644 --- a/dist/bind/CHANGES +++ b/dist/bind/CHANGES @@ -1,4 +1,245 @@ + --- 9.3.0 released --- + +1711. [func] 'rndc unfreeze' has been deprecated by 'rndc thaw'. + + --- 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 <isc/print.h>". [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] @@ -1904,7 +2145,6 @@ --- 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] diff --git a/dist/bind/FAQ b/dist/bind/FAQ index dab25ced221..25eb00ce38b 100644 --- a/dist/bind/FAQ +++ b/dist/bind/FAQ @@ -415,3 +415,40 @@ information in the chroot area. 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 <usual arguements>" 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/dist/bind/KNOWN_DEFECTS b/dist/bind/KNOWN_DEFECTS new file mode 100644 index 00000000000..53d9ceb5ff2 --- /dev/null +++ b/dist/bind/KNOWN_DEFECTS @@ -0,0 +1,21 @@ + + Known Defects in BIND 9.3.0 + +* 'dig +chase' does not terminate on a RFC 2308 Type 1 negative response. + +* named does not correctly caching a RFC 2308 Type 1 negative response. + This causes named to emit RFC 2308 Type 3 responses instead of RFC 2308 + Type 2 responses which inturn causes problems for nsupdate (below). + +* nsupdate does not handling RFC 2308 Type 3 negative responses when looking + for the zone / master server. Use server and zone commands to work around + this. + +* "ifconfig.sh down" doesn't work for Solaris 9. + +* named.conf(5) is being installed in the wrong location. + +* dig/host/nslookup are only trying the first address when a nameserver was + specified by name. + +* Missing FULLCHECK for "trusted-key" in dig. diff --git a/dist/bind/acconfig.h b/dist/bind/acconfig.h index bf06c37279b..5d74a7a6578 100644 --- a/dist/bind/acconfig.h +++ b/dist/bind/acconfig.h @@ -1,4 +1,4 @@ -/* $NetBSD: acconfig.h,v 1.1.1.1 2004/05/17 23:43:06 christos Exp $ */ +/* $NetBSD: acconfig.h,v 1.1.1.2 2004/11/06 23:53:21 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: acconfig.h,v 1.35.2.4.2.7 2004/03/08 04:04:12 marka Exp */ +/* 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 @@ -138,3 +138,6 @@ int sigwait(const unsigned int *set, int *sig); /* Define if you are running under Compaq TruCluster.. */ #undef HAVE_TRUCLUSTER + +/* Define if OpenSSL includes DSA support */ +#undef HAVE_OPENSSL_DSA diff --git a/dist/bind/bin/check/Makefile.in b/dist/bind/bin/check/Makefile.in index de00501a1e0..0f5e5299045 100644 --- a/dist/bind/bin/check/Makefile.in +++ b/dist/bind/bin/check/Makefile.in @@ -13,7 +13,7 @@ # 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.5 2004/03/06 10:21:10 marka Exp +# Id: Makefile.in,v 1.15.2.3.8.6 2004/07/20 07:01:48 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -69,12 +69,12 @@ named-checkzone.@O@: named-checkzone.c named-checkconf@EXEEXT@: named-checkconf.@O@ check-tool.@O@ ${ISCDEPLIBS} \ ${ISCCFGDEPLIBS} ${BIND9DEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ \ + ${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} -o $@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \ named-checkzone.@O@ check-tool.@O@ ${DNSLIBS} ${ISCLIBS} ${LIBS} doc man:: ${MANOBJS} diff --git a/dist/bind/bin/check/named-checkconf.8 b/dist/bind/bin/check/named-checkconf.8 index a789d77fc05..1297a21d50e 100644 --- a/dist/bind/bin/check/named-checkconf.8 +++ b/dist/bind/bin/check/named-checkconf.8 @@ -1,4 +1,4 @@ -.\" $NetBSD: named-checkconf.8,v 1.1.1.1 2004/05/17 23:43:17 christos Exp $ +.\" $NetBSD: named-checkconf.8,v 1.1.1.2 2004/11/06 23:53:29 christos Exp $ .\" .\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000-2002 Internet Software Consortium. @@ -15,7 +15,7 @@ .\" 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.3 2004/03/08 04:04:13 marka Exp +.\" 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 @@ -58,4 +58,4 @@ errors were detected and 0 otherwise. \fIBIND 9 Administrator Reference Manual\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/dist/bind/bin/check/named-checkconf.docbook b/dist/bind/bin/check/named-checkconf.docbook index 02d9589d52e..350022e23b7 100644 --- a/dist/bind/bin/check/named-checkconf.docbook +++ b/dist/bind/bin/check/named-checkconf.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: named-checkconf.docbook,v 1.3.2.1.8.4 2004/03/08 04:04:13 marka Exp --> +<!-- Id: named-checkconf.docbook,v 1.3.2.1.8.5 2004/06/03 02:24:59 marka Exp --> <refentry> <refentryinfo> @@ -132,7 +132,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/dist/bind/bin/check/named-checkconf.html b/dist/bind/bin/check/named-checkconf.html index 2005cbee7a5..6d23123f40f 100644 --- a/dist/bind/bin/check/named-checkconf.html +++ b/dist/bind/bin/check/named-checkconf.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: named-checkconf.html,v 1.5.2.1.4.3 2004/03/08 04:04:13 marka Exp --> +<!-- Id: named-checkconf.html,v 1.5.2.1.4.5 2004/08/22 23:38:57 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >named-checkconf</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,10 +35,10 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" +></A ><SPAN CLASS="APPLICATION" >named-checkconf</SPAN -></A ></H1 ><DIV CLASS="REFNAMEDIV" @@ -62,23 +62,21 @@ NAME="AEN13" ><B CLASS="COMMAND" >named-checkconf</B -> [<TT +> [<VAR CLASS="OPTION" ->-v</TT ->] [<TT +>-v</VAR +>] [<VAR CLASS="OPTION" ->-j</TT ->] [<TT +>-j</VAR +>] [<VAR CLASS="OPTION" ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT -></TT ->] {filename} [<TT +>directory</VAR +></VAR +>] {filename} [<VAR CLASS="OPTION" ->-z</TT +>-z</VAR >]</P ></DIV ><DIV @@ -109,11 +107,9 @@ NAME="AEN30" CLASS="VARIABLELIST" ><DL ><DT ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT +>directory</VAR ></DT ><DD ><P @@ -212,7 +208,7 @@ NAME="AEN69" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/dist/bind/bin/check/named-checkzone.8 b/dist/bind/bin/check/named-checkzone.8 index f11aa32c0d8..c2e531faa97 100644 --- a/dist/bind/bin/check/named-checkzone.8 +++ b/dist/bind/bin/check/named-checkzone.8 @@ -1,4 +1,4 @@ -.\" $NetBSD: named-checkzone.8,v 1.1.1.1 2004/05/17 23:43:17 christos Exp $ +.\" $NetBSD: named-checkzone.8,v 1.1.1.2 2004/11/06 23:53:29 christos Exp $ .\" .\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000-2002 Internet Software Consortium. @@ -15,7 +15,7 @@ .\" 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.3 2004/03/08 04:04:14 marka Exp +.\" 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 @@ -93,4 +93,4 @@ errors were detected and 0 otherwise. \fIBIND 9 Administrator Reference Manual\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/dist/bind/bin/check/named-checkzone.docbook b/dist/bind/bin/check/named-checkzone.docbook index b89abce30d0..bec2940b888 100644 --- a/dist/bind/bin/check/named-checkzone.docbook +++ b/dist/bind/bin/check/named-checkzone.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: named-checkzone.docbook,v 1.3.2.2.8.6 2004/03/08 04:04:14 marka Exp --> +<!-- Id: named-checkzone.docbook,v 1.3.2.2.8.7 2004/06/03 02:25:00 marka Exp --> <refentry> <refentryinfo> @@ -222,7 +222,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/dist/bind/bin/check/named-checkzone.html b/dist/bind/bin/check/named-checkzone.html index 3c22c4fcd63..bf9a9ea9c84 100644 --- a/dist/bind/bin/check/named-checkzone.html +++ b/dist/bind/bin/check/named-checkzone.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: named-checkzone.html,v 1.5.2.2.4.3 2004/03/08 04:04:14 marka Exp --> +<!-- Id: named-checkzone.html,v 1.5.2.2.4.5 2004/08/22 23:38:57 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >named-checkzone</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,10 +35,10 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" +></A ><SPAN CLASS="APPLICATION" >named-checkzone</SPAN -></A ></H1 ><DIV CLASS="REFNAMEDIV" @@ -62,69 +62,57 @@ NAME="AEN13" ><B CLASS="COMMAND" >named-checkzone</B -> [<TT +> [<VAR CLASS="OPTION" ->-d</TT ->] [<TT +>-d</VAR +>] [<VAR CLASS="OPTION" ->-j</TT ->] [<TT +>-j</VAR +>] [<VAR CLASS="OPTION" ->-q</TT ->] [<TT +>-q</VAR +>] [<VAR CLASS="OPTION" ->-v</TT ->] [<TT +>-v</VAR +>] [<VAR CLASS="OPTION" ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->class</I -></TT -></TT ->] [<TT +>class</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-k <TT +>-k <VAR CLASS="REPLACEABLE" -><I ->mode</I -></TT -></TT ->] [<TT +>mode</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-n <TT +>-n <VAR CLASS="REPLACEABLE" -><I ->mode</I -></TT -></TT ->] [<TT +>mode</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-o <TT +>-o <VAR CLASS="REPLACEABLE" -><I ->filename</I -></TT -></TT ->] [<TT +>filename</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT -></TT ->] [<TT +>directory</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-w <TT +>-w <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT -></TT ->] [<TT +>directory</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-D</TT +>-D</VAR >] {zonename} {filename}</P ></DIV ><DIV @@ -196,11 +184,9 @@ CLASS="COMMAND" </P ></DD ><DT ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->class</I -></TT +>class</VAR ></DT ><DD ><P @@ -208,11 +194,9 @@ CLASS="REPLACEABLE" </P ></DD ><DT ->-k <TT +>-k <VAR CLASS="REPLACEABLE" -><I ->mode</I -></TT +>mode</VAR ></DT ><DD ><P @@ -235,11 +219,9 @@ CLASS="COMMAND" </P ></DD ><DT ->-n <TT +>-n <VAR CLASS="REPLACEABLE" -><I ->mode</I -></TT +>mode</VAR ></DT ><DD ><P @@ -259,11 +241,9 @@ CLASS="COMMAND" </P ></DD ><DT ->-o <TT +>-o <VAR CLASS="REPLACEABLE" -><I ->filename</I -></TT +>filename</VAR ></DT ><DD ><P @@ -274,11 +254,9 @@ CLASS="FILENAME" </P ></DD ><DT ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT +>directory</VAR ></DT ><DD ><P @@ -291,11 +269,9 @@ CLASS="FILENAME" </P ></DD ><DT ->-w <TT +>-w <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT +>directory</VAR ></DT ><DD ><P @@ -383,7 +359,7 @@ NAME="AEN137" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/dist/bind/bin/dig/Makefile.in b/dist/bind/bin/dig/Makefile.in index 48e444b22ba..c13eaa87894 100644 --- a/dist/bind/bin/dig/Makefile.in +++ b/dist/bind/bin/dig/Makefile.in @@ -13,7 +13,7 @@ # 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.10 2004/04/13 05:47:32 marka Exp +# Id: Makefile.in,v 1.25.12.12 2004/08/18 23:25:57 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -57,24 +57,24 @@ UOBJS = SRCS = dig.c dighost.c host.c nslookup.c -MANPAGES = dig.1 host.1 +MANPAGES = dig.1 host.1 nslookup.1 -HTMLPAGES = dig.html host.html +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} -o $@ \ + ${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} -o $@ \ + ${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} -o $@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \ nslookup.@O@ dighost.@O@ ${UOBJS} ${LIBS} doc man:: ${MANOBJS} diff --git a/dist/bind/bin/dig/dig.1 b/dist/bind/bin/dig/dig.1 index 2df022597d4..70e7a19933e 100644 --- a/dist/bind/bin/dig/dig.1 +++ b/dist/bind/bin/dig/dig.1 @@ -1,4 +1,4 @@ -.\" $NetBSD: dig.1,v 1.1.1.1 2004/05/17 23:43:17 christos Exp $ +.\" $NetBSD: dig.1,v 1.1.1.2 2004/11/06 23:53:30 christos Exp $ .\" .\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000-2003 Internet Software Consortium. @@ -15,7 +15,7 @@ .\" 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.5 2004/04/13 04:11:03 marka Exp +.\" 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 @@ -199,9 +199,10 @@ The search list is not used by default. Deprecated, treated as a synonym for \fI+[no]search\fR .TP \fB+[no]aaonly\fR -This option does nothing. It is provided for compatibility with old -versions of \fBdig\fR where it set an unimplemented -resolver flag. +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 diff --git a/dist/bind/bin/dig/dig.docbook b/dist/bind/bin/dig/dig.docbook index 0b0625aa93b..025155af195 100644 --- a/dist/bind/bin/dig/dig.docbook +++ b/dist/bind/bin/dig/dig.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: dig.docbook,v 1.4.2.7.4.8 2004/04/13 03:00:05 marka Exp --> +<!-- Id: dig.docbook,v 1.4.2.7.4.9 2004/06/23 04:19:41 marka Exp --> <refentry> @@ -306,9 +306,12 @@ Deprecated, treated as a synonym for <parameter>+[no]search</parameter> <varlistentry><term><option>+[no]aaonly</option></term> <listitem><para> -This option does nothing. It is provided for compatibility with old -versions of <command>dig</command> where it set an unimplemented -resolver flag. +Sets the "aa" flag in the query. +</para></listitem></varlistentry> + +<varlistentry><term><option>+[no]aaflag</option></term> +<listitem><para> +A synonym for <parameter>+[no]aaonly</parameter>. </para></listitem></varlistentry> <varlistentry><term><option>+[no]adflag</option></term> diff --git a/dist/bind/bin/dig/dig.html b/dist/bind/bin/dig/dig.html index 9ce09140dff..049bb172c40 100644 --- a/dist/bind/bin/dig/dig.html +++ b/dist/bind/bin/dig/dig.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: dig.html,v 1.6.2.4.2.5 2004/04/13 04:11:03 marka Exp --> +<!-- Id: dig.html,v 1.6.2.4.2.7 2004/08/22 23:38:57 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >dig</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->dig</A -></H1 +></A +>dig</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -56,84 +56,68 @@ NAME="AEN11" ><B CLASS="COMMAND" >dig</B -> [@server] [<TT +> [@server] [<VAR CLASS="OPTION" ->-b <TT +>-b <VAR CLASS="REPLACEABLE" -><I ->address</I -></TT -></TT ->] [<TT +>address</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->class</I -></TT -></TT ->] [<TT +>class</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-f <TT +>-f <VAR CLASS="REPLACEABLE" -><I ->filename</I -></TT -></TT ->] [<TT +>filename</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-k <TT +>-k <VAR CLASS="REPLACEABLE" -><I ->filename</I -></TT -></TT ->] [<TT +>filename</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-p <TT +>-p <VAR CLASS="REPLACEABLE" -><I ->port#</I -></TT -></TT ->] [<TT +>port#</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->type</I -></TT -></TT ->] [<TT +>type</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-x <TT +>-x <VAR CLASS="REPLACEABLE" -><I ->addr</I -></TT -></TT ->] [<TT +>addr</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-y <TT +>-y <VAR CLASS="REPLACEABLE" -><I ->name:key</I -></TT -></TT ->] [<TT +>name:key</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-4</TT ->] [<TT +>-4</VAR +>] [<VAR CLASS="OPTION" ->-6</TT +>-6</VAR >] [name] [type] [class] [queryopt...]</P ><P ><B CLASS="COMMAND" >dig</B -> [<TT +> [<VAR CLASS="OPTION" ->-h</TT +>-h</VAR >]</P ><P ><B @@ -172,9 +156,9 @@ CLASS="COMMAND" > 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 <TT +and options is printed when the <VAR CLASS="OPTION" ->-h</TT +>-h</VAR > option is given. Unlike earlier versions, the BIND9 implementation of <B @@ -229,30 +213,26 @@ CLASS="PROGRAMLISTING" CLASS="VARIABLELIST" ><DL ><DT -><TT +><CODE CLASS="CONSTANT" ->server</TT +>server</CODE ></DT ><DD ><P >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 -<TT +<VAR CLASS="PARAMETER" -><I ->server</I -></TT +>server</VAR > argument is a hostname, <B CLASS="COMMAND" >dig</B > resolves that name before querying that name -server. If no <TT +server. If no <VAR CLASS="PARAMETER" -><I ->server</I -></TT +>server</VAR > argument is provided, <B CLASS="COMMAND" @@ -265,34 +245,30 @@ and queries the name servers listed there. The reply from the name server that responds is displayed.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->name</TT +>name</CODE ></DT ><DD ><P >is the name of the resource record that is to be looked up.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->type</TT +>type</CODE ></DT ><DD ><P >indicates what type of query is required — ANY, A, MX, SIG, etc. -<TT +<VAR CLASS="PARAMETER" -><I ->type</I -></TT +>type</VAR > can be any valid query type. If no -<TT +<VAR CLASS="PARAMETER" -><I ->type</I -></TT +>type</VAR > argument is supplied, <B CLASS="COMMAND" @@ -311,44 +287,38 @@ NAME="AEN101" ><H2 >OPTIONS</H2 ><P ->The <TT +>The <VAR CLASS="OPTION" ->-b</TT +>-b</VAR > option sets the source IP address of the query -to <TT +to <VAR CLASS="PARAMETER" -><I ->address</I -></TT +>address</VAR >. 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>"</P ><P >The default query class (IN for internet) is overridden by the -<TT +<VAR CLASS="OPTION" ->-c</TT -> option. <TT +>-c</VAR +> option. <VAR CLASS="PARAMETER" -><I ->class</I -></TT +>class</VAR > is any valid class, such as HS for Hesiod records or CH for CHAOSNET records.</P ><P ->The <TT +>The <VAR CLASS="OPTION" ->-f</TT +>-f</VAR > option makes <B CLASS="COMMAND" >dig </B > operate in batch mode by reading a list of lookup requests to process from the -file <TT +file <VAR CLASS="PARAMETER" -><I ->filename</I -></TT +>filename</VAR >. 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 @@ -358,14 +328,12 @@ CLASS="COMMAND" > using the command-line interface.</P ><P >If a non-standard port number is to be queried, the -<TT +<VAR CLASS="OPTION" ->-p</TT -> option is used. <TT +>-p</VAR +> option is used. <VAR CLASS="PARAMETER" -><I ->port#</I -></TT +>port#</VAR > is the port number that <B CLASS="COMMAND" @@ -375,100 +343,86 @@ 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.</P ><P ->The <TT +>The <VAR CLASS="OPTION" ->-4</TT +>-4</VAR > option forces <B CLASS="COMMAND" >dig</B > to only -use IPv4 query transport. The <TT +use IPv4 query transport. The <VAR CLASS="OPTION" ->-6</TT +>-6</VAR > option forces <B CLASS="COMMAND" >dig</B > to only use IPv6 query transport.</P ><P ->The <TT +>The <VAR CLASS="OPTION" ->-t</TT +>-t</VAR > option sets the query type to -<TT +<VAR CLASS="PARAMETER" -><I ->type</I -></TT +>type</VAR >. It can be any valid query type which is supported in BIND9. The default query type "A", unless the -<TT +<VAR CLASS="OPTION" ->-x</TT +>-x</VAR > 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, -<TT +<VAR CLASS="PARAMETER" -><I ->type</I -></TT -> is set to <TT +>type</VAR +> is set to <VAR CLASS="LITERAL" ->ixfr=N</TT +>ixfr=N</VAR >. The incremental zone transfer will contain the changes made to the zone since the serial number in the zone's SOA record was -<TT +<VAR CLASS="PARAMETER" -><I ->N</I -></TT +>N</VAR >.</P ><P >Reverse lookups - mapping addresses to names - are simplified by the -<TT +<VAR CLASS="OPTION" ->-x</TT -> option. <TT +>-x</VAR +> option. <VAR CLASS="PARAMETER" -><I ->addr</I -></TT +>addr</VAR > 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 -<TT +<VAR CLASS="PARAMETER" -><I ->name</I -></TT ->, <TT +>name</VAR +>, <VAR CLASS="PARAMETER" -><I ->class</I -></TT +>class</VAR > and -<TT +<VAR CLASS="PARAMETER" -><I ->type</I -></TT +>type</VAR > arguments. <B CLASS="COMMAND" >dig</B > automatically performs a lookup for a name like -<TT +<VAR CLASS="LITERAL" ->11.12.13.10.in-addr.arpa</TT +>11.12.13.10.in-addr.arpa</VAR > 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 <TT +specify the <VAR CLASS="OPTION" ->-i</TT +>-i</VAR > option. Bit string labels (RFC2874) are now experimental and are not attempted.</P ><P @@ -477,25 +431,21 @@ CLASS="COMMAND" >dig</B > and their responses using transaction signatures (TSIG), specify a TSIG key file -using the <TT +using the <VAR CLASS="OPTION" ->-k</TT +>-k</VAR > option. You can also specify the TSIG -key itself on the command line using the <TT +key itself on the command line using the <VAR CLASS="OPTION" ->-y</TT +>-y</VAR > option; -<TT +<VAR CLASS="PARAMETER" -><I ->name</I -></TT +>name</VAR > is the name of the TSIG key and -<TT +<VAR CLASS="PARAMETER" -><I ->key</I -></TT +>key</VAR > is the actual key. The key is a base-64 encoded string, typically generated by <SPAN CLASS="CITEREFENTRY" @@ -505,9 +455,9 @@ CLASS="REFENTRYTITLE" >(8)</SPAN >. -Caution should be taken when using the <TT +Caution should be taken when using the <VAR CLASS="OPTION" ->-y</TT +>-y</VAR > option on multi-user systems as the key can be visible in the output from <SPAN @@ -553,18 +503,18 @@ sections of the answer get printed, and others determine the timeout and retry strategies.</P ><P >Each query option is identified by a keyword preceded by a plus sign -(<TT +(<VAR CLASS="LITERAL" ->+</TT +>+</VAR >). Some keywords set or reset an option. These may be preceded -by the string <TT +by the string <VAR CLASS="LITERAL" ->no</TT +>no</VAR > to negate the meaning of that keyword. Other keywords assign values to options like the timeout interval. They -have the form <TT +have the form <VAR CLASS="OPTION" ->+keyword=value</TT +>+keyword=value</VAR >. The query options are: @@ -574,9 +524,9 @@ The query options are: CLASS="VARIABLELIST" ><DL ><DT -><TT +><VAR CLASS="OPTION" ->+[no]tcp</TT +>+[no]tcp</VAR ></DT ><DD ><P @@ -585,25 +535,23 @@ behaviour is to use UDP unless an AXFR or IXFR query is requested, in which case a TCP connection is used.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]vc</TT +>+[no]vc</VAR ></DT ><DD ><P >Use [do not use] TCP when querying name servers. This alternate -syntax to <TT +syntax to <VAR CLASS="PARAMETER" -><I ->+[no]tcp</I -></TT +>+[no]tcp</VAR > is provided for backwards compatibility. The "vc" stands for "virtual circuit".</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]ignore</TT +>+[no]ignore</VAR ></DT ><DD ><P @@ -611,18 +559,16 @@ CLASS="OPTION" default, TCP retries are performed.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+domain=somename</TT +>+domain=somename</VAR ></DT ><DD ><P >Set the search list to contain the single domain -<TT +<VAR CLASS="PARAMETER" -><I ->somename</I -></TT +>somename</VAR >, as if specified in a <B CLASS="COMMAND" @@ -632,17 +578,15 @@ CLASS="COMMAND" CLASS="FILENAME" >/etc/resolv.conf</TT >, and enable search list -processing as if the <TT +processing as if the <VAR CLASS="PARAMETER" -><I ->+search</I -></TT +>+search</VAR > option were given.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]search</TT +>+[no]search</VAR ></DT ><DD ><P @@ -654,37 +598,42 @@ CLASS="FILENAME" The search list is not used by default.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]defname</TT +>+[no]defname</VAR ></DT ><DD ><P ->Deprecated, treated as a synonym for <TT +>Deprecated, treated as a synonym for <VAR CLASS="PARAMETER" -><I ->+[no]search</I -></TT +>+[no]search</VAR ></P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]aaonly</TT +>+[no]aaonly</VAR ></DT ><DD ><P ->This option does nothing. It is provided for compatibility with old -versions of <B -CLASS="COMMAND" ->dig</B -> where it set an unimplemented -resolver flag.</P +>Sets the "aa" flag in the query.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]adflag</TT +>+[no]aaflag</VAR +></DT +><DD +><P +>A synonym for <VAR +CLASS="PARAMETER" +>+[no]aaonly</VAR +>.</P +></DD +><DT +><VAR +CLASS="OPTION" +>+[no]adflag</VAR ></DT ><DD ><P @@ -694,9 +643,9 @@ but the ability to set the bit in the query is provided for completeness.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]cdflag</TT +>+[no]cdflag</VAR ></DT ><DD ><P @@ -704,27 +653,27 @@ CLASS="OPTION" requests the server to not perform DNSSEC validation of responses.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]cl</TT +>+[no]cl</VAR ></DT ><DD ><P >Display [do not display] the CLASS when printing the record.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]ttlid</TT +>+[no]ttlid</VAR ></DT ><DD ><P >Display [do not display] the TTL when printing the record.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]recurse</TT +>+[no]recurse</VAR ></DT ><DD ><P @@ -734,23 +683,19 @@ CLASS="COMMAND" >dig</B > normally sends recursive queries. Recursion is automatically disabled -when the <TT +when the <VAR CLASS="PARAMETER" -><I ->+nssearch</I -></TT +>+nssearch</VAR > or -<TT +<VAR CLASS="PARAMETER" -><I ->+trace</I -></TT +>+trace</VAR > query options are used.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]nssearch</TT +>+[no]nssearch</VAR ></DT ><DD ><P @@ -763,9 +708,9 @@ looked up and display the SOA record that each name server has for the zone.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]trace</TT +>+[no]trace</VAR ></DT ><DD ><P @@ -780,9 +725,9 @@ root servers, showing the answer from each server that was used to resolve the lookup.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]cmd</TT +>+[no]cmd</VAR ></DT ><DD ><P @@ -794,9 +739,9 @@ CLASS="COMMAND" been applied. This comment is printed by default.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]short</TT +>+[no]short</VAR ></DT ><DD ><P @@ -804,26 +749,24 @@ CLASS="OPTION" verbose form.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]identify</TT +>+[no]identify</VAR ></DT ><DD ><P >Show [or do not show] the IP address and port number that supplied the -answer when the <TT +answer when the <VAR CLASS="PARAMETER" -><I ->+short</I -></TT +>+short</VAR > 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.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]comments</TT +>+[no]comments</VAR ></DT ><DD ><P @@ -831,9 +774,9 @@ CLASS="OPTION" print comments.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]stats</TT +>+[no]stats</VAR ></DT ><DD ><P @@ -842,9 +785,9 @@ was made, the size of the reply and so on. The default behaviour is to print the query statistics.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]qr</TT +>+[no]qr</VAR ></DT ><DD ><P @@ -852,9 +795,9 @@ CLASS="OPTION" By default, the query is not printed.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]question</TT +>+[no]question</VAR ></DT ><DD ><P @@ -862,9 +805,9 @@ CLASS="OPTION" returned. The default is to print the question section as a comment.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]answer</TT +>+[no]answer</VAR ></DT ><DD ><P @@ -872,9 +815,9 @@ CLASS="OPTION" is to display it.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]authority</TT +>+[no]authority</VAR ></DT ><DD ><P @@ -882,9 +825,9 @@ CLASS="OPTION" default is to display it.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]additional</TT +>+[no]additional</VAR ></DT ><DD ><P @@ -892,98 +835,82 @@ CLASS="OPTION" The default is to display it.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]all</TT +>+[no]all</VAR ></DT ><DD ><P >Set or clear all display flags.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+time=T</TT +>+time=T</VAR ></DT ><DD ><P > Sets the timeout for a query to -<TT +<VAR CLASS="PARAMETER" -><I ->T</I -></TT +>T</VAR > seconds. The default time out is 5 seconds. -An attempt to set <TT +An attempt to set <VAR CLASS="PARAMETER" -><I ->T</I -></TT +>T</VAR > to less than 1 will result in a query timeout of 1 second being applied.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+tries=T</TT +>+tries=T</VAR ></DT ><DD ><P >Sets the number of times to try UDP queries to server to -<TT +<VAR CLASS="PARAMETER" -><I ->T</I -></TT +>T</VAR > instead of the default, 3. If -<TT +<VAR CLASS="PARAMETER" -><I ->T</I -></TT +>T</VAR > is less than or equal to zero, the number of tries is silently rounded up to 1.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+retry=T</TT +>+retry=T</VAR ></DT ><DD ><P >Sets the number of times to retry UDP queries to server to -<TT +<VAR CLASS="PARAMETER" -><I ->T</I -></TT +>T</VAR > instead of the default, 2. Unlike -<TT +<VAR CLASS="PARAMETER" -><I ->+tries</I -></TT +>+tries</VAR >, this does not include the initial query.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+ndots=D</TT +>+ndots=D</VAR ></DT ><DD ><P >Set the number of dots that have to appear in -<TT +<VAR CLASS="PARAMETER" -><I ->name</I -></TT -> to <TT +>name</VAR +> to <VAR CLASS="PARAMETER" -><I ->D</I -></TT +>D</VAR > for it to be considered absolute. The default value is that defined using the ndots statement in <TT @@ -992,12 +919,12 @@ CLASS="FILENAME" >, 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 -<TT +<VAR CLASS="OPTION" ->search</TT -> or <TT +>search</VAR +> or <VAR CLASS="OPTION" ->domain</TT +>domain</VAR > directive in <TT CLASS="FILENAME" @@ -1005,26 +932,24 @@ CLASS="FILENAME" >.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+bufsize=B</TT +>+bufsize=B</VAR ></DT ><DD ><P >Set the UDP message buffer size advertised using EDNS0 to -<TT +<VAR CLASS="PARAMETER" -><I ->B</I -></TT +>B</VAR > bytes. The maximum and minimum sizes of this buffer are 65535 and 0 respectively. Values outside this range are rounded up or down appropriately.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]multiline</TT +>+[no]multiline</VAR ></DT ><DD ><P @@ -1037,9 +962,9 @@ CLASS="COMMAND" > output.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]fail</TT +>+[no]fail</VAR ></DT ><DD ><P @@ -1048,9 +973,9 @@ to not try the next server which is the reverse of normal stub resolver behaviour.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]besteffort</TT +>+[no]besteffort</VAR ></DT ><DD ><P @@ -1058,9 +983,9 @@ CLASS="OPTION" The default is to not display malformed answers.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]dnssec</TT +>+[no]dnssec</VAR ></DT ><DD ><P @@ -1068,9 +993,9 @@ CLASS="OPTION" in the OPT record in the additional section of the query.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]sigchase</TT +>+[no]sigchase</VAR ></DT ><DD ><P @@ -1078,22 +1003,22 @@ CLASS="OPTION" -DDIG_SIGCHASE.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+trusted-key=####</TT +>+trusted-key=####</VAR ></DT ><DD ><P ->Specify a trusted key to be used with <TT +>Specify a trusted key to be used with <VAR CLASS="OPTION" ->+sigchase</TT +>+sigchase</VAR >. Requires dig be compiled with -DDIG_SIGCHASE.</P ></DD ><DT -><TT +><VAR CLASS="OPTION" ->+[no]topdown</TT +>+[no]topdown</VAR ></DT ><DD ><P @@ -1107,7 +1032,7 @@ Requires dig be compiled with -DDIG_SIGCHASE.</P ><DIV CLASS="REFSECT1" ><A -NAME="AEN380" +NAME="AEN385" ></A ><H2 >MULTIPLE QUERIES</H2 @@ -1117,18 +1042,16 @@ CLASS="COMMAND" >dig </B > supports specifying multiple queries on the command line (in addition to -supporting the <TT +supporting the <VAR CLASS="OPTION" ->-f</TT +>-f</VAR > batch file option). Each of those queries can be supplied with its own set of flags, options and query options.</P ><P ->In this case, each <TT +>In this case, each <VAR CLASS="PARAMETER" -><I ->query</I -></TT +>query</VAR > 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 @@ -1139,9 +1062,9 @@ should be applied to that query.</P 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 <TT +the <VAR CLASS="OPTION" ->+[no]cmd</TT +>+[no]cmd</VAR > option) can be overridden by a query-specific set of query options. For example: <PRE @@ -1152,46 +1075,42 @@ shows how <B CLASS="COMMAND" >dig</B > could be used from the command line -to make three lookups: an ANY query for <TT +to make three lookups: an ANY query for <VAR CLASS="LITERAL" ->www.isc.org</TT +>www.isc.org</VAR >, a reverse lookup of 127.0.0.1 and a query for the NS records of -<TT +<VAR CLASS="LITERAL" ->isc.org</TT +>isc.org</VAR >. -A global query option of <TT +A global query option of <VAR CLASS="PARAMETER" -><I ->+qr</I -></TT +>+qr</VAR > is applied, so that <B CLASS="COMMAND" >dig</B > shows the initial query it made for each lookup. The final query has a local query option of -<TT +<VAR CLASS="PARAMETER" -><I ->+noqr</I -></TT +>+noqr</VAR > which means that <B CLASS="COMMAND" >dig</B > will not print the initial query when it looks up the NS records for -<TT +<VAR CLASS="LITERAL" ->isc.org</TT +>isc.org</VAR >.</P ></DIV ><DIV CLASS="REFSECT1" ><A -NAME="AEN398" +NAME="AEN403" ></A ><H2 >FILES</H2 @@ -1209,7 +1128,7 @@ CLASS="FILENAME" ><DIV CLASS="REFSECT1" ><A -NAME="AEN404" +NAME="AEN409" ></A ><H2 >SEE ALSO</H2 @@ -1243,7 +1162,7 @@ CLASS="CITETITLE" ><DIV CLASS="REFSECT1" ><A -NAME="AEN417" +NAME="AEN422" ></A ><H2 >BUGS </H2 diff --git a/dist/bind/bin/dig/dighost.c b/dist/bind/bin/dig/dighost.c index bc54dabec38..c8b0f2c3321 100644 --- a/dist/bind/bin/dig/dighost.c +++ b/dist/bind/bin/dig/dighost.c @@ -1,4 +1,4 @@ -/* $NetBSD: dighost.c,v 1.1.1.1 2004/05/17 23:43:19 christos Exp $ */ +/* $NetBSD: dighost.c,v 1.1.1.2 2004/11/06 23:53:31 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: dighost.c,v 1.221.2.19.2.11 2004/04/13 03:00:06 marka Exp */ +/* 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 @@ -34,15 +34,6 @@ #include <string.h> #include <limits.h> -#ifdef DIG_SIGCHASE -#ifndef DIG_SIGCHASE_BU -#define DIG_SIGCHASE_BU 1 -#endif -#ifndef DIG_SIGCHASE_TD -#define DIG_SIGCHASE_TD 1 -#endif -#endif - #include <dns/byaddr.h> #ifdef DIG_SIGCHASE #include <dns/dnssec.h> @@ -219,7 +210,7 @@ isc_result_t prove_nx(dns_message_t * msg, dns_name_t * name, dns_name_t * rdata_name, dns_rdataset_t ** rdataset, dns_rdataset_t ** sigrdataset); -isc_result_t nameFromString( const char *str, dns_name_t *p_ret ); +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); @@ -866,7 +857,7 @@ setup_file_key(void) { dst_key_t *dstkey = NULL; debug("setup_file_key()"); - result = dst_key_fromnamedfile(keyfile, DST_TYPE_PRIVATE, + 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", @@ -973,6 +964,16 @@ setup_system(void) { #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 } @@ -1270,9 +1271,8 @@ start_lookup(void) { current_lookup->sigchase = ISC_FALSE; goto novalidation; } - result = nameFromString(current_lookup->textname, - &query_name); - check_result(result, "nameFromString"); + 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]); @@ -1331,10 +1331,8 @@ start_lookup(void) { MXNAME); isc_buffer_free(&b); - result = nameFromString(current_lookup - ->textnamesigchase, - &chase_name); - check_result(result, "nameFromString"); + nameFromString(current_lookup->textnamesigchase, + &chase_name); dns_name_init(&chase_authority_name, NULL); } @@ -2866,7 +2864,8 @@ recv_done(isc_task_t *task, isc_event_t *event) { fatal("Memory allocation failure in %s:%d", __FILE__, __LINE__); } - ISC_LIST_APPEND(chase_message_list, chase_msg, link); + 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", @@ -2891,7 +2890,8 @@ recv_done(isc_task_t *task, isc_event_t *event) { fatal("Memory allocation failure in %s:%d", __FILE__, __LINE__); } - ISC_LIST_APPEND(chase_message_list2, chase_msg2, link); + ISC_LIST_INITANDAPPEND(chase_message_list2, chase_msg2, + link); chase_msg2->msg = msg; } #endif @@ -3145,6 +3145,18 @@ destroy_libs(void) { 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"); @@ -3554,8 +3566,8 @@ get_trusted_key(isc_mem_t *mctx) return ISC_R_FAILURE; } fclose(fptemp); - result = dst_key_fromnamedfile(filetemp, DST_TYPE_PUBLIC, - mctx, &key); + 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 ) { @@ -3572,28 +3584,29 @@ get_trusted_key(isc_mem_t *mctx) } -isc_result_t -nameFromString( const char *str, dns_name_t *p_ret ) -{ - int len = strlen(str); - int ret; +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); - REQUIRE( str != NULL ); - isc_buffer_init( &buffer, str, len ); - isc_buffer_add( &buffer, len ); + REQUIRE(p_ret != NULL); + REQUIRE(str != NULL); + + isc_buffer_init(&buffer, str, len); + isc_buffer_add(&buffer, len); dns_fixedname_init(&fixedname); - ret = dns_name_fromtext( dns_fixedname_name(&fixedname), &buffer, - dns_rootname, ISC_TRUE, NULL); - if ( ret != ISC_R_SUCCESS ) return ret; + result = dns_name_fromtext(dns_fixedname_name(&fixedname), &buffer, + dns_rootname, ISC_TRUE, NULL); + check_result(result, "nameFromString"); - dns_name_init(p_ret, NULL ); + if (dns_name_dynamic(p_ret)) + dns_name_free(p_ret, mctx); - ret = dns_name_dup( dns_fixedname_name(&fixedname), mctx, p_ret ); - return ret; + result = dns_name_dup(dns_fixedname_name(&fixedname), mctx, p_ret); + check_result(result, "nameFromString"); } @@ -3616,8 +3629,6 @@ prepare_lookup(dns_name_t *name) 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) { @@ -3849,11 +3860,11 @@ 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) -{ +dup_name(dns_name_t *source, dns_name_t *target, isc_mem_t *mctx) { isc_result_t result; - dns_name_init(target, NULL); + if (dns_name_dynamic(target)) + dns_name_free(target, mctx); result = dns_name_dup(source, mctx, target); check_result(result, "dns_name_dup"); } @@ -4331,7 +4342,7 @@ sigchase_td(dns_message_t * msg) dns_name_init(&tmp_name, NULL); result = child_of_zone(&chase_name, &chase_current_name, &tmp_name); - if (chase_authority_name.labels != 0) + 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" @@ -4415,7 +4426,6 @@ sigchase_td(dns_message_t * msg) have_delegation_ns = ISC_FALSE; delegation_follow = ISC_TRUE; error_message = NULL; - dns_name_free(&chase_current_name, mctx); dup_name(&chase_authority_name, &chase_current_name, mctx); dns_name_free(&chase_authority_name, mctx); return; @@ -4428,6 +4438,7 @@ sigchase_td(dns_message_t * msg) 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, @@ -4463,10 +4474,9 @@ sigchase_td(dns_message_t * msg) cleanandgo: printf(";; cleanandgo \n"); - dns_name_free(&chase_name, mctx); - if (chase_current_name.labels != 0) + if (dns_name_dynamic(&chase_current_name)) dns_name_free(&chase_current_name, mctx); - if (chase_authority_name.labels != 0) + if (dns_name_dynamic(&chase_authority_name)) dns_name_free(&chase_authority_name, mctx); clean_trustedkey(); return; @@ -4557,7 +4567,7 @@ getneededrr(dns_message_t *msg) if (result == ISC_R_FAILURE) { printf("\n;; RRSIG is missing for continue validation:" " FAILED\n\n"); - if (chase_name.ndata != NULL) + if (dns_name_dynamic(&chase_name)) dns_name_free(&chase_name, mctx); return ISC_R_NOTFOUND; } @@ -4592,7 +4602,7 @@ getneededrr(dns_message_t *msg) printf("\n;; DNSKEY is missing to continue validation:" " FAILED\n\n"); dns_name_free(&chase_signame, mctx); - if (chase_name.ndata != NULL) + if (dns_name_dynamic(&chase_name)) dns_name_free(&chase_name, mctx); return ISC_R_NOTFOUND; } @@ -4615,7 +4625,7 @@ getneededrr(dns_message_t *msg) printf("\n;; RRSIG for DNSKEY is missing to continue" " validation : FAILED\n\n"); dns_name_free(&chase_signame, mctx); - if (chase_name.ndata != NULL) + if (dns_name_dynamic(&chase_name)) dns_name_free(&chase_name, mctx); return ISC_R_NOTFOUND; } @@ -4706,6 +4716,7 @@ sigchase_bu(dns_message_t *msg) 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, @@ -4801,7 +4812,6 @@ sigchase_bu(dns_message_t *msg) " the RRset\n"); INSIST(chase_sigdsrdataset != NULL); - dns_name_free(&chase_name, mctx); dup_name(&chase_signame, &chase_name, mctx); dns_name_free(&chase_signame, mctx); chase_rdataset = chase_dsrdataset; diff --git a/dist/bind/bin/dig/host.html b/dist/bind/bin/dig/host.html index baa41978ca0..8d2aa367508 100644 --- a/dist/bind/bin/dig/host.html +++ b/dist/bind/bin/dig/host.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: host.html,v 1.4.2.1.4.5 2004/04/13 04:11:04 marka Exp --> +<!-- Id: host.html,v 1.4.2.1.4.6 2004/08/22 23:38:58 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >host</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->host</A -></H1 +></A +>host</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -56,55 +56,45 @@ NAME="AEN11" ><B CLASS="COMMAND" >host</B -> [<TT +> [<VAR CLASS="OPTION" ->-aCdlnrTwv</TT ->] [<TT +>-aCdlnrTwv</VAR +>] [<VAR CLASS="OPTION" ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->class</I -></TT -></TT ->] [<TT +>class</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-N <TT +>-N <VAR CLASS="REPLACEABLE" -><I ->ndots</I -></TT -></TT ->] [<TT +>ndots</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-R <TT +>-R <VAR CLASS="REPLACEABLE" -><I ->number</I -></TT -></TT ->] [<TT +>number</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->type</I -></TT -></TT ->] [<TT +>type</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-W <TT +>-W <VAR CLASS="REPLACEABLE" -><I ->wait</I -></TT -></TT ->] [<TT +>wait</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-4</TT ->] [<TT +>-4</VAR +>] [<VAR CLASS="OPTION" ->-6</TT +>-6</VAR >] {name} [server]</P ></DIV ><DIV @@ -128,11 +118,9 @@ CLASS="COMMAND" > prints a short summary of its command line arguments and options.</P ><P -><TT +><VAR CLASS="PARAMETER" -><I ->name</I -></TT +>name</VAR > 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 <B @@ -140,11 +128,9 @@ CLASS="COMMAND" >host</B > will by default perform a reverse lookup for that address. -<TT +<VAR CLASS="PARAMETER" -><I ->server</I -></TT +>server</VAR > is an optional argument which is either the name or IP address of the name server that <B CLASS="COMMAND" @@ -156,45 +142,41 @@ CLASS="FILENAME" >/etc/resolv.conf</TT >.</P ><P ->The <TT +>The <VAR CLASS="OPTION" ->-a</TT +>-a</VAR > (all) option is equivalent to setting the -<TT +<VAR CLASS="OPTION" ->-v</TT +>-v</VAR > option and asking <B CLASS="COMMAND" >host</B > to make a query of type ANY.</P ><P ->When the <TT +>When the <VAR CLASS="OPTION" ->-C</TT +>-C</VAR > option is used, <B CLASS="COMMAND" >host</B > will attempt to display the SOA records for zone -<TT +<VAR CLASS="PARAMETER" -><I ->name</I -></TT +>name</VAR > 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.</P ><P ->The <TT +>The <VAR CLASS="OPTION" ->-c</TT +>-c</VAR > option instructs to make a DNS query of class -<TT +<VAR CLASS="PARAMETER" -><I ->class</I -></TT +>class</VAR >. This can be used to lookup Hesiod or Chaosnet class resource records. The default class is IN (Internet).</P ><P @@ -202,61 +184,57 @@ Chaosnet class resource records. The default class is IN (Internet).</P CLASS="COMMAND" >host</B > when the -<TT +<VAR CLASS="OPTION" ->-d</TT -> or <TT +>-d</VAR +> or <VAR CLASS="OPTION" ->-v</TT +>-v</VAR > option is used. The two options are equivalent. They have been provided for backwards -compatibility. In previous versions, the <TT +compatibility. In previous versions, the <VAR CLASS="OPTION" ->-d</TT +>-d</VAR > option -switched on debugging traces and <TT +switched on debugging traces and <VAR CLASS="OPTION" ->-v</TT +>-v</VAR > enabled verbose output.</P ><P ->List mode is selected by the <TT +>List mode is selected by the <VAR CLASS="OPTION" ->-l</TT +>-l</VAR > option. This makes <B CLASS="COMMAND" >host</B > perform a zone transfer for zone -<TT +<VAR CLASS="PARAMETER" -><I ->name</I -></TT +>name</VAR >. Transfer the zone printing out the NS, PTR -and address records (A/AAAA). If combined with <TT +and address records (A/AAAA). If combined with <VAR CLASS="OPTION" ->-a</TT +>-a</VAR > all records will be printed. </P ><P ->The <TT +>The <VAR CLASS="OPTION" ->-i</TT +>-i</VAR > 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.</P ><P ->The <TT +>The <VAR CLASS="OPTION" ->-N</TT +>-N</VAR > option sets the number of dots that have to be -in <TT +in <VAR CLASS="PARAMETER" -><I ->name</I -></TT +>name</VAR > for it to be considered absolute. The default value is that defined using the ndots statement in <TT @@ -278,31 +256,27 @@ CLASS="FILENAME" >.</P ><P >The number of UDP retries for a lookup can be changed with the -<TT +<VAR CLASS="OPTION" ->-R</TT -> option. <TT +>-R</VAR +> option. <VAR CLASS="PARAMETER" -><I ->number</I -></TT +>number</VAR > indicates how many times <B CLASS="COMMAND" >host</B > will repeat a query that does not get answered. The default number of retries is 1. If -<TT +<VAR CLASS="PARAMETER" -><I ->number</I -></TT +>number</VAR > is negative or zero, the number of retries will default to 1.</P ><P ->Non-recursive queries can be made via the <TT +>Non-recursive queries can be made via the <VAR CLASS="OPTION" ->-r</TT +>-r</VAR > option. Setting this option clears the <SPAN CLASS="TYPE" @@ -313,15 +287,13 @@ CLASS="COMMAND" >host</B > makes. This should mean that the name server receiving the query will not -attempt to resolve <TT +attempt to resolve <VAR CLASS="PARAMETER" -><I ->name</I -></TT +>name</VAR >. The -<TT +<VAR CLASS="OPTION" ->-r</TT +>-r</VAR > option enables <B CLASS="COMMAND" >host</B @@ -334,38 +306,36 @@ referrals to other name servers.</P CLASS="COMMAND" >host</B > uses UDP when making queries. The -<TT +<VAR CLASS="OPTION" ->-T</TT +>-T</VAR > 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.</P ><P ->The <TT +>The <VAR CLASS="OPTION" ->-4</TT +>-4</VAR > option forces <B CLASS="COMMAND" >host</B > to only -use IPv4 query transport. The <TT +use IPv4 query transport. The <VAR CLASS="OPTION" ->-6</TT +>-6</VAR > option forces <B CLASS="COMMAND" >host</B > to only use IPv6 query transport.</P ><P ->The <TT +>The <VAR CLASS="OPTION" ->-t</TT +>-t</VAR > option is used to select the query type. -<TT +<VAR CLASS="PARAMETER" -><I ->type</I -></TT +>type</VAR > can be any recognised query type: CNAME, NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified, <B @@ -373,15 +343,13 @@ CLASS="COMMAND" >host</B > automatically selects an appropriate query type. By default it looks for A records, but if the -<TT +<VAR CLASS="OPTION" ->-C</TT +>-C</VAR > option was given, queries will be made for SOA -records, and if <TT +records, and if <VAR CLASS="PARAMETER" -><I ->name</I -></TT +>name</VAR > is a dotted-decimal IPv4 address or colon-delimited IPv6 address, <B CLASS="COMMAND" @@ -392,35 +360,31 @@ serial number can be specified by appending an equal followed by the starting serial number (e.g. -t IXFR=12345678).</P ><P >The time to wait for a reply can be controlled through the -<TT +<VAR CLASS="OPTION" ->-W</TT -> and <TT +>-W</VAR +> and <VAR CLASS="OPTION" ->-w</TT +>-w</VAR > options. The -<TT +<VAR CLASS="OPTION" ->-W</TT +>-W</VAR > option makes <B CLASS="COMMAND" >host</B > wait for -<TT +<VAR CLASS="PARAMETER" -><I ->wait</I -></TT -> seconds. If <TT +>wait</VAR +> seconds. If <VAR CLASS="PARAMETER" -><I ->wait</I -></TT +>wait</VAR > is less than one, the wait interval is set to one second. When the -<TT +<VAR CLASS="OPTION" ->-w</TT +>-w</VAR > option is used, <B CLASS="COMMAND" >host</B diff --git a/dist/bind/bin/dig/include/dig/dig.h b/dist/bind/bin/dig/include/dig/dig.h index 510a5b8c05f..485658a8f88 100644 --- a/dist/bind/bin/dig/include/dig/dig.h +++ b/dist/bind/bin/dig/include/dig/dig.h @@ -1,4 +1,4 @@ -/* $NetBSD: dig.h,v 1.1.1.1 2004/05/17 23:43:20 christos Exp $ */ +/* $NetBSD: dig.h,v 1.1.1.2 2004/11/06 23:53:31 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: dig.h,v 1.71.2.6.2.5 2004/04/13 03:00:07 marka Exp */ +/* Id: dig.h,v 1.71.2.6.2.6 2004/06/19 02:30:12 sra Exp */ #ifndef DIG_H #define DIG_H @@ -76,6 +76,19 @@ * 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; diff --git a/dist/bind/bin/dig/nslookup.1 b/dist/bind/bin/dig/nslookup.1 new file mode 100644 index 00000000000..329c070ad15 --- /dev/null +++ b/dist/bind/bin/dig/nslookup.1 @@ -0,0 +1,194 @@ +.\" $NetBSD: nslookup.1,v 1.1.1.1 2004/11/06 23:53:31 christos Exp $ +.\" +.\" 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/dist/bind/bin/dig/nslookup.c b/dist/bind/bin/dig/nslookup.c index 61fc6fe593f..5d1bc5a4de5 100644 --- a/dist/bind/bin/dig/nslookup.c +++ b/dist/bind/bin/dig/nslookup.c @@ -1,4 +1,4 @@ -/* $NetBSD: nslookup.c,v 1.1.1.1 2004/05/17 23:43:20 christos Exp $ */ +/* $NetBSD: nslookup.c,v 1.1.1.2 2004/11/06 23:53:31 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: nslookup.c,v 1.90.2.4.2.4 2004/04/13 03:00:06 marka Exp */ +/* Id: nslookup.c,v 1.90.2.4.2.7 2004/08/18 23:25:58 marka Exp */ #include <config.h> @@ -44,15 +44,6 @@ #include <dns/rdatatype.h> #include <dns/byaddr.h> -#ifdef DIG_SIGCHASE -#ifndef DIG_SIGCHASE_BU -#define DIG_SIGCHASE_BU 1 -#endif -#ifndef DIG_SIGCHASE_TD -#define DIG_SIGCHASE_TD 1 -#endif -#endif - #include <dig/dig.h> extern ISC_LIST(dig_lookup_t) lookup_list; @@ -69,7 +60,7 @@ extern isc_task_t *global_task; extern char *progname; static isc_boolean_t short_form = ISC_TRUE, - tcpmode = ISC_FALSE, deprecation_msg = 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, @@ -654,7 +645,7 @@ setoption(char *opt) { } else if (strncasecmp(opt, "nosearch", 5) == 0) { usesearch = ISC_FALSE; } else if (strncasecmp(opt, "sil", 3) == 0) { - deprecation_msg = ISC_FALSE; + /* deprecation_msg = ISC_FALSE; */ } else { printf("*** Invalid option: %s\n", opt); } @@ -727,6 +718,7 @@ get_next_command(void) { char *ptr, *arg; char *input; + fflush(stdout); buf = isc_mem_allocate(mctx, COMMSIZE); if (buf == NULL) fatal("memory allocation failure"); @@ -872,12 +864,6 @@ main(int argc, char **argv) { parse_args(argc, argv); - if (deprecation_msg) { - fputs( -"Note: nslookup is deprecated and may be removed from future releases.\n" -"Consider using the `dig' or `host' programs instead. Run nslookup with\n" -"the `-sil[ent]' option to prevent this message from appearing.\n", stderr); - } setup_system(); if (domainopt[0] != '\0') set_search_domain(domainopt); diff --git a/dist/bind/bin/dig/nslookup.docbook b/dist/bind/bin/dig/nslookup.docbook new file mode 100644 index 00000000000..671333f498a --- /dev/null +++ b/dist/bind/bin/dig/nslookup.docbook @@ -0,0 +1,320 @@ +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> +<!-- + - 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.docbook,v 1.3.6.3 2004/08/30 00:50:11 marka Exp --> + +<!-- + - Copyright (c) 1985, 1989 + - The Regents of the University of California. All rights reserved. + - + - Redistribution and use in source and binary forms, with or without + - modification, are permitted provided that the following conditions + - are met: + - 1. Redistributions of source code must retain the above copyright + - notice, this list of conditions and the following disclaimer. + - 2. Redistributions in binary form must reproduce the above copyright + - notice, this list of conditions and the following disclaimer in the + - documentation and/or other materials provided with the distribution. + - 3. All advertising materials mentioning features or use of this software + - must display the following acknowledgement: + - This product includes software developed by the University of + - California, Berkeley and its contributors. + - 4. Neither the name of the University nor the names of its contributors + - may be used to endorse or promote products derived from this software + - without specific prior written permission. + - + - THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + - ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + - IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + - ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + - FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + - DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + - OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + - HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + - LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + - OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + - SUCH DAMAGE. +--> + +<refentry> + +<refentryinfo> +<date>Jun 30, 2000</date> +</refentryinfo> + +<refmeta> +<refentrytitle>nslookup</refentrytitle> +<manvolnum>1</manvolnum> +<refmiscinfo>BIND9</refmiscinfo> +</refmeta> + +<refnamediv> +<refname>nslookup</refname> +<refpurpose>query Internet name servers interactively</refpurpose> +</refnamediv> + +<refsynopsisdiv> +<cmdsynopsis> + <command>nslookup</command> + <arg><option>-option</option></arg> + <arg choice=opt>name | -</arg> + <arg choice=opt>server</arg> +</cmdsynopsis> +</refsynopsisdiv> + +<refsect1> +<title>DESCRIPTION</title> +<para> +<command>Nslookup</command> +is a program to query Internet domain name servers. <command>Nslookup</command> +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. +</para> +</refsect1> + +<refsect1> +<title>ARGUMENTS</title> +<para> +Interactive mode is entered in the following cases: +<OrderedList Numeration=Loweralpha> +<Listitem> +<para> +when no arguments are given (the default name server will be used) +</para> +</Listitem> +<Listitem> +<para> +when the first argument is a hyphen (-) and the second argument is +the host name or Internet address of a name server. +</para> +</Listitem> +</OrderedList> +</para> + +<para> +Non-interactive mode is used when the name or Internet address of the +host to be looked up is given as the first argument. The optional second +argument specifies the host name or address of a name server. +</para> + +<para> +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: +<InformalExample> +<PROGRAMLISTING> +nslookup -query=hinfo -timeout=10 +</PROGRAMLISTING> +</InformalExample> +</para> + +</refsect1> + +<refsect1> +<title>INTERACTIVE COMMANDS</title> +<variablelist> +<varlistentry><term>host <optional>server</optional></term> +<listitem><para> +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. +</para> + +<para> +To look up a host not in the current domain, append a period to +the name. +</para></listitem></varlistentry> + +<varlistentry><term><constant>server</constant> <replaceable class="parameter">domain</replaceable></term> +<listitem><para></para></listitem></varlistentry> +<varlistentry><term><constant>lserver</constant> <replaceable class="parameter">domain</replaceable></term> +<listitem><para> +Change the default server to <replaceable>domain</replaceable>; <constant>lserver</constant> uses the initial +server to look up information about <replaceable>domain</replaceable>, while <constant>server</constant> uses +the current default server. If an authoritative answer can't be +found, the names of servers that might have the answer are +returned. +</para></listitem></varlistentry> + +<varlistentry><term><constant>root</constant></term> +<listitem><para>not implemented</para></listitem></varlistentry> + +<varlistentry><term><constant>finger</constant></term> +<listitem><para>not implemented</para></listitem></varlistentry> + +<varlistentry><term><constant>ls</constant></term> +<listitem><para>not implemented</para></listitem></varlistentry> + +<varlistentry><term><constant>view</constant></term> +<listitem><para>not implemented</para></listitem></varlistentry> + +<varlistentry><term><constant>help</constant></term> +<listitem><para>not implemented</para></listitem></varlistentry> + +<varlistentry><term><constant>?</constant></term> +<listitem><para>not implemented</para></listitem></varlistentry> + +<varlistentry><term><constant>exit</constant></term> +<listitem><para>Exits the program.</para></listitem></varlistentry> + +<varlistentry><term><constant>set</constant> <replaceable>keyword<optional>=value</optional></replaceable></term> +<listitem><para>This command is used to change state information that affects +the lookups. Valid keywords are: + <variablelist> + <varlistentry><term><constant>all</constant></term> + <listitem> + <para>Prints the current values of the frequently used + options to <command>set</command>. Information about the current default + server and host is also printed. + </para> + </listitem> + </varlistentry> + + <varlistentry><term><constant>class=</constant><replaceable>value</replaceable></term> + <listitem><para> + Change the query class to one of: + <variablelist> + <varlistentry><term><constant>IN</constant></term> + <listitem><para>the Internet class</para></listitem></varlistentry> + <varlistentry><term><constant>CH</constant></term> + <listitem><para>the Chaos class</para></listitem></varlistentry> + <varlistentry><term><constant>HS</constant></term> + <listitem><para>the Hesiod class</para></listitem></varlistentry> + <varlistentry><term><constant>ANY</constant></term> + <listitem><para>wildcard</para></listitem></varlistentry> + </variablelist> + The class specifies the protocol group of the information. + </para><para> + (Default = IN; abbreviation = cl) + </para></listitem> + </varlistentry> + + <varlistentry><term><constant><replaceable><optional>no</optional></replaceable>debug</constant></term> + <listitem><para> + Turn debugging mode on. A lot more information is + printed about the packet sent to the server and the + resulting answer. + </para><para> + (Default = nodebug; abbreviation = <optional>no</optional>deb) + </para></listitem></varlistentry> + + <varlistentry><term><constant><replaceable><optional>no</optional></replaceable>d2</constant></term> + <listitem><para> + Turn debugging mode on. A lot more information is + printed about the packet sent to the server and the + resulting answer. + </para><para> + (Default = nod2) + </para></listitem></varlistentry> + + <varlistentry><term><constant>domain=</constant><replaceable>name</replaceable></term> + <listitem><para> + Sets the search list to <replaceable>name</replaceable>. + </para></listitem></varlistentry> + + <varlistentry><term><constant><replaceable><optional>no</optional></replaceable>search</constant></term> + <listitem><para> + 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. + </para><para> + (Default = search) + </para></listitem></varlistentry> + + <varlistentry><term><constant>port=</constant><replaceable>value</replaceable></term> + <listitem><para> + Change the default TCP/UDP name server port to <replaceable>value</replaceable>. + </para><para> + (Default = 53; abbreviation = po) + </para></listitem></varlistentry> + + <varlistentry><term><constant>querytype=</constant><replaceable>value</replaceable></term> + <listitem><para></para></listitem></varlistentry> + + <varlistentry><term><constant>type=</constant><replaceable>value</replaceable></term> + <listitem><para> + Change the top of the information query. + </para><para> + (Default = A; abbreviations = q, ty) + </para></listitem></varlistentry> + + <varlistentry><term><constant><replaceable><optional>no</optional></replaceable>recurse</constant></term> + <listitem><para> + Tell the name server to query other servers if it does not have the + information. + </para><para> + (Default = recurse; abbreviation = [no]rec) + </para></listitem></varlistentry> + + <varlistentry><term><constant>retry=</constant><replaceable>number</replaceable></term> + <listitem><para> + Set the number of retries to number. + </para></listitem></varlistentry> + + <varlistentry><term><constant>timeout=</constant><replaceable>number</replaceable></term> + <listitem><para> + Change the initial timeout interval for waiting for a + reply to number seconds. + </para></listitem></varlistentry> + + <varlistentry><term><constant><replaceable><optional>no</optional></replaceable>vc</constant></term> + <listitem><para> + Always use a virtual circuit when sending requests to the server. + </para><para> + (Default = novc) + </para></listitem></varlistentry> + + </variablelist> +</para></listitem></varlistentry> +</variablelist> +</refsect1> + +<refsect1> +<title>FILES</title> +<para> +<filename>/etc/resolv.conf</filename> +</para> +</refsect1> + +<refsect1> +<title>SEE ALSO</title> +<para> +<citerefentry> +<refentrytitle>dig</refentrytitle><manvolnum>1</manvolnum> +</citerefentry>, +<citerefentry> +<refentrytitle>host</refentrytitle><manvolnum>1</manvolnum> +</citerefentry>, +<citerefentry> +<refentrytitle>named</refentrytitle><manvolnum>8</manvolnum> +</citerefentry>. +</para> +</refsect1> + +<refsect1> +<title>Author</title> +<para> +Andrew Cherenson +</para> +</refsect1> +</refentry> diff --git a/dist/bind/bin/dig/nslookup.html b/dist/bind/bin/dig/nslookup.html new file mode 100644 index 00000000000..86c2f12cc8d --- /dev/null +++ b/dist/bind/bin/dig/nslookup.html @@ -0,0 +1,617 @@ +<!-- + - 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.html,v 1.1.6.3 2004/08/22 23:38:58 marka Exp --> + +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<HTML +><HEAD +><TITLE +>nslookup</TITLE +><META +NAME="GENERATOR" +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD +><BODY +CLASS="REFENTRY" +BGCOLOR="#FFFFFF" +TEXT="#000000" +LINK="#0000FF" +VLINK="#840084" +ALINK="#0000FF" +><H1 +><A +NAME="AEN1" +></A +>nslookup</H1 +><DIV +CLASS="REFNAMEDIV" +><A +NAME="AEN8" +></A +><H2 +>Name</H2 +>nslookup -- query Internet name servers interactively</DIV +><DIV +CLASS="REFSYNOPSISDIV" +><A +NAME="AEN11" +></A +><H2 +>Synopsis</H2 +><P +><B +CLASS="COMMAND" +>nslookup</B +> [<VAR +CLASS="OPTION" +>-option</VAR +>] [name | -] [server]</P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN18" +></A +><H2 +>DESCRIPTION</H2 +><P +><B +CLASS="COMMAND" +>Nslookup</B +> +is a program to query Internet domain name servers. <B +CLASS="COMMAND" +>Nslookup</B +> +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.</P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN23" +></A +><H2 +>ARGUMENTS</H2 +><P +>Interactive mode is entered in the following cases: +<P +></P +><OL +TYPE="a" +><LI +><P +>when no arguments are given (the default name server will be used)</P +></LI +><LI +><P +>when the first argument is a hyphen (-) and the second argument is +the host name or Internet address of a name server.</P +></LI +></OL +></P +><P +>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.</P +><P +>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: +<DIV +CLASS="INFORMALEXAMPLE" +><P +></P +><A +NAME="AEN33" +></A +><PRE +CLASS="PROGRAMLISTING" +>nslookup -query=hinfo -timeout=10</PRE +><P +></P +></DIV +></P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN35" +></A +><H2 +>INTERACTIVE COMMANDS</H2 +><P +></P +><DIV +CLASS="VARIABLELIST" +><DL +><DT +>host [<SPAN +CLASS="OPTIONAL" +>server</SPAN +>]</DT +><DD +><P +>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.</P +><P +>To look up a host not in the current domain, append a period to +the name.</P +></DD +><DT +><CODE +CLASS="CONSTANT" +>server</CODE +> <VAR +CLASS="REPLACEABLE" +>domain</VAR +></DT +><DD +><P +></P +></DD +><DT +><CODE +CLASS="CONSTANT" +>lserver</CODE +> <VAR +CLASS="REPLACEABLE" +>domain</VAR +></DT +><DD +><P +>Change the default server to <VAR +CLASS="REPLACEABLE" +>domain</VAR +>; <CODE +CLASS="CONSTANT" +>lserver</CODE +> uses the initial +server to look up information about <VAR +CLASS="REPLACEABLE" +>domain</VAR +>, while <CODE +CLASS="CONSTANT" +>server</CODE +> uses +the current default server. If an authoritative answer can't be +found, the names of servers that might have the answer are +returned.</P +></DD +><DT +><CODE +CLASS="CONSTANT" +>root</CODE +></DT +><DD +><P +>not implemented</P +></DD +><DT +><CODE +CLASS="CONSTANT" +>finger</CODE +></DT +><DD +><P +>not implemented</P +></DD +><DT +><CODE +CLASS="CONSTANT" +>ls</CODE +></DT +><DD +><P +>not implemented</P +></DD +><DT +><CODE +CLASS="CONSTANT" +>view</CODE +></DT +><DD +><P +>not implemented</P +></DD +><DT +><CODE +CLASS="CONSTANT" +>help</CODE +></DT +><DD +><P +>not implemented</P +></DD +><DT +><CODE +CLASS="CONSTANT" +>?</CODE +></DT +><DD +><P +>not implemented</P +></DD +><DT +><CODE +CLASS="CONSTANT" +>exit</CODE +></DT +><DD +><P +>Exits the program.</P +></DD +><DT +><CODE +CLASS="CONSTANT" +>set</CODE +> <VAR +CLASS="REPLACEABLE" +>keyword[<SPAN +CLASS="OPTIONAL" +>=value</SPAN +>]</VAR +></DT +><DD +><P +>This command is used to change state information that affects +the lookups. Valid keywords are: + <P +></P +><DIV +CLASS="VARIABLELIST" +><DL +><DT +><CODE +CLASS="CONSTANT" +>all</CODE +></DT +><DD +><P +>Prints the current values of the frequently used + options to <B +CLASS="COMMAND" +>set</B +>. Information about the current default + server and host is also printed. + </P +></DD +><DT +><CODE +CLASS="CONSTANT" +>class=</CODE +><VAR +CLASS="REPLACEABLE" +>value</VAR +></DT +><DD +><P +> Change the query class to one of: + <P +></P +><DIV +CLASS="VARIABLELIST" +><DL +><DT +><CODE +CLASS="CONSTANT" +>IN</CODE +></DT +><DD +><P +>the Internet class</P +></DD +><DT +><CODE +CLASS="CONSTANT" +>CH</CODE +></DT +><DD +><P +>the Chaos class</P +></DD +><DT +><CODE +CLASS="CONSTANT" +>HS</CODE +></DT +><DD +><P +>the Hesiod class</P +></DD +><DT +><CODE +CLASS="CONSTANT" +>ANY</CODE +></DT +><DD +><P +>wildcard</P +></DD +></DL +></DIV +> + The class specifies the protocol group of the information. + </P +><P +> (Default = IN; abbreviation = cl) + </P +></DD +><DT +><CODE +CLASS="CONSTANT" +><VAR +CLASS="REPLACEABLE" +>[<SPAN +CLASS="OPTIONAL" +>no</SPAN +>]</VAR +>debug</CODE +></DT +><DD +><P +> Turn debugging mode on. A lot more information is + printed about the packet sent to the server and the + resulting answer. + </P +><P +> (Default = nodebug; abbreviation = [<SPAN +CLASS="OPTIONAL" +>no</SPAN +>]deb) + </P +></DD +><DT +><CODE +CLASS="CONSTANT" +><VAR +CLASS="REPLACEABLE" +>[<SPAN +CLASS="OPTIONAL" +>no</SPAN +>]</VAR +>d2</CODE +></DT +><DD +><P +> Turn debugging mode on. A lot more information is + printed about the packet sent to the server and the + resulting answer. + </P +><P +> (Default = nod2) + </P +></DD +><DT +><CODE +CLASS="CONSTANT" +>domain=</CODE +><VAR +CLASS="REPLACEABLE" +>name</VAR +></DT +><DD +><P +> Sets the search list to <VAR +CLASS="REPLACEABLE" +>name</VAR +>. + </P +></DD +><DT +><CODE +CLASS="CONSTANT" +><VAR +CLASS="REPLACEABLE" +>[<SPAN +CLASS="OPTIONAL" +>no</SPAN +>]</VAR +>search</CODE +></DT +><DD +><P +> 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. + </P +><P +> (Default = search) + </P +></DD +><DT +><CODE +CLASS="CONSTANT" +>port=</CODE +><VAR +CLASS="REPLACEABLE" +>value</VAR +></DT +><DD +><P +> Change the default TCP/UDP name server port to <VAR +CLASS="REPLACEABLE" +>value</VAR +>. + </P +><P +> (Default = 53; abbreviation = po) + </P +></DD +><DT +><CODE +CLASS="CONSTANT" +>querytype=</CODE +><VAR +CLASS="REPLACEABLE" +>value</VAR +></DT +><DD +><P +></P +></DD +><DT +><CODE +CLASS="CONSTANT" +>type=</CODE +><VAR +CLASS="REPLACEABLE" +>value</VAR +></DT +><DD +><P +> Change the top of the information query. + </P +><P +> (Default = A; abbreviations = q, ty) + </P +></DD +><DT +><CODE +CLASS="CONSTANT" +><VAR +CLASS="REPLACEABLE" +>[<SPAN +CLASS="OPTIONAL" +>no</SPAN +>]</VAR +>recurse</CODE +></DT +><DD +><P +> Tell the name server to query other servers if it does not have the + information. + </P +><P +> (Default = recurse; abbreviation = [no]rec) + </P +></DD +><DT +><CODE +CLASS="CONSTANT" +>retry=</CODE +><VAR +CLASS="REPLACEABLE" +>number</VAR +></DT +><DD +><P +> Set the number of retries to number. + </P +></DD +><DT +><CODE +CLASS="CONSTANT" +>timeout=</CODE +><VAR +CLASS="REPLACEABLE" +>number</VAR +></DT +><DD +><P +> Change the initial timeout interval for waiting for a + reply to number seconds. + </P +></DD +><DT +><CODE +CLASS="CONSTANT" +><VAR +CLASS="REPLACEABLE" +>[<SPAN +CLASS="OPTIONAL" +>no</SPAN +>]</VAR +>vc</CODE +></DT +><DD +><P +> Always use a virtual circuit when sending requests to the server. + </P +><P +> (Default = novc) + </P +></DD +></DL +></DIV +></P +></DD +></DL +></DIV +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN218" +></A +><H2 +>FILES</H2 +><P +><TT +CLASS="FILENAME" +>/etc/resolv.conf</TT +></P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN222" +></A +><H2 +>SEE ALSO</H2 +><P +><SPAN +CLASS="CITEREFENTRY" +><SPAN +CLASS="REFENTRYTITLE" +>dig</SPAN +>(1)</SPAN +>, +<SPAN +CLASS="CITEREFENTRY" +><SPAN +CLASS="REFENTRYTITLE" +>host</SPAN +>(1)</SPAN +>, +<SPAN +CLASS="CITEREFENTRY" +><SPAN +CLASS="REFENTRYTITLE" +>named</SPAN +>(8)</SPAN +>.</P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN234" +></A +><H2 +>Author</H2 +><P +>Andrew Cherenson</P +></DIV +></BODY +></HTML +> diff --git a/dist/bind/bin/dnssec/Makefile.in b/dist/bind/bin/dnssec/Makefile.in index a761a443de4..6474297ed01 100644 --- a/dist/bind/bin/dnssec/Makefile.in +++ b/dist/bind/bin/dnssec/Makefile.in @@ -13,7 +13,7 @@ # 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.8 2004/03/08 04:04:16 marka Exp +# Id: Makefile.in,v 1.19.12.9 2004/07/20 07:01:48 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -54,14 +54,14 @@ MANOBJS = ${MANPAGES} ${HTMLPAGES} @BIND9_MAKE_RULES@ dnssec-keygen@EXEEXT@: dnssec-keygen.@O@ ${OBJS} ${DEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ \ + ${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} -o $@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \ dnssec-signzone.@O@ ${OBJS} ${LIBS} doc man:: ${MANOBJS} diff --git a/dist/bind/bin/dnssec/dnssec-keygen.8 b/dist/bind/bin/dnssec/dnssec-keygen.8 index 2207faa73d8..9392fe66cd7 100644 --- a/dist/bind/bin/dnssec/dnssec-keygen.8 +++ b/dist/bind/bin/dnssec/dnssec-keygen.8 @@ -1,4 +1,4 @@ -.\" $NetBSD: dnssec-keygen.8,v 1.1.1.1 2004/05/17 23:43:20 christos Exp $ +.\" $NetBSD: dnssec-keygen.8,v 1.1.1.2 2004/11/06 23:53:31 christos Exp $ .\" .\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000-2003 Internet Software Consortium. @@ -15,34 +15,36 @@ .\" 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.3 2004/03/08 04:04:16 marka Exp +.\" 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-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 +\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. It can also generate +(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. .SH "OPTIONS" .TP \fB-a \fIalgorithm\fB\fR Selects the cryptographic algorithm. The value of -\fBalgorithm\fR must be one of RSAMD5 or RSA, +\fBalgorithm\fR must be one of RSAMD5 (RSA) or RSASHA1, DSA, DH (Diffie Hellman), or HMAC-MD5. These values are case insensitive. -Note that for DNSSEC, DSA is a mandatory to implement algorithm, -and RSA is recommended. For TSIG, HMAC-MD5 is mandatory. +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. RSA keys must be between +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 @@ -51,8 +53,8 @@ between 1 and 512 bits. \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), HOST or ENTITY (for a key associated with a host), -or USER (for a key associated with a user). These values are +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 @@ -60,11 +62,11 @@ 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 RSA key, use a large exponent. +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 record. -The only recognized flag is KSK (Key Signing Key). +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. @@ -76,6 +78,9 @@ if possible; otherwise the default is 2. 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). @@ -161,8 +166,6 @@ the files \fIKexample.com.+003+26160.key\fR and \fIKexample.com.+003+26160.private\fR .SH "SEE ALSO" .PP -\fBdnssec-makekeyset\fR(8), -\fBdnssec-signkey\fR(8), \fBdnssec-signzone\fR(8), \fIBIND 9 Administrator Reference Manual\fR, \fIRFC 2535\fR, @@ -170,4 +173,4 @@ the files \fIKexample.com.+003+26160.key\fR and \fIRFC 2539\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/dist/bind/bin/dnssec/dnssec-keygen.c b/dist/bind/bin/dnssec/dnssec-keygen.c index 449096f7484..9bf1b5f1903 100644 --- a/dist/bind/bin/dnssec/dnssec-keygen.c +++ b/dist/bind/bin/dnssec/dnssec-keygen.c @@ -1,4 +1,4 @@ -/* $NetBSD: dnssec-keygen.c,v 1.1.1.1 2004/05/17 23:43:20 christos Exp $ */ +/* $NetBSD: dnssec-keygen.c,v 1.1.1.2 2004/11/06 23:53:32 christos Exp $ */ /* * Portions Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -18,7 +18,7 @@ * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* Id: dnssec-keygen.c,v 1.48.2.1.10.10 2004/03/10 02:55:50 marka Exp */ +/* Id: dnssec-keygen.c,v 1.48.2.1.10.11 2004/06/11 01:17:34 marka Exp */ #include <config.h> @@ -70,7 +70,7 @@ usage(void) { 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\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 <class> (default: IN)\n"); @@ -103,7 +103,7 @@ main(int argc, char **argv) { dst_key_t *key = NULL, *oldkey; dns_fixedname_t fname; dns_name_t *name; - isc_uint16_t flags = 0; + 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; @@ -145,7 +145,7 @@ main(int argc, char **argv) { break; case 'f': if (strcasecmp(isc_commandline_argument, "KSK") == 0) - flags |= DNS_KEYFLAG_KSK; + ksk = DNS_KEYFLAG_KSK; else fatal("unknown flag '%s'", isc_commandline_argument); @@ -213,17 +213,20 @@ main(int argc, char **argv) { if (algname == NULL) fatal("no algorithm was specified"); - if (strcasecmp(algname, "HMAC-MD5") == 0) + if (strcasecmp(algname, "HMAC-MD5") == 0) { + options |= DST_TYPE_KEY; alg = DST_ALG_HMACMD5; - else { + } 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) { + if (type != NULL && (options & DST_TYPE_KEY) != 0) { if (strcasecmp(type, "NOAUTH") == 0) flags |= DNS_KEYTYPE_NOAUTH; else if (strcasecmp(type, "NOCONF") == 0) @@ -273,20 +276,29 @@ main(int argc, char **argv) { fatal("no nametype specified"); if (strcasecmp(nametype, "zone") == 0) flags |= DNS_KEYOWNER_ZONE; - else 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 nametype %s", nametype); + 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); - flags |= signatory; + 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) diff --git a/dist/bind/bin/dnssec/dnssec-keygen.docbook b/dist/bind/bin/dnssec/dnssec-keygen.docbook index e1ace624fdd..79f98c39f20 100644 --- a/dist/bind/bin/dnssec/dnssec-keygen.docbook +++ b/dist/bind/bin/dnssec/dnssec-keygen.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: dnssec-keygen.docbook,v 1.3.12.4 2004/03/08 04:04:16 marka Exp --> +<!-- Id: dnssec-keygen.docbook,v 1.3.12.6 2004/06/11 01:17:34 marka Exp --> <refentry> <refentryinfo> @@ -45,6 +45,7 @@ <arg><option>-f <replaceable class="parameter">flag</replaceable></option></arg> <arg><option>-g <replaceable class="parameter">generator</replaceable></option></arg> <arg><option>-h</option></arg> + <arg><option>-k</option></arg> <arg><option>-p <replaceable class="parameter">protocol</replaceable></option></arg> <arg><option>-r <replaceable class="parameter">randomdev</replaceable></option></arg> <arg><option>-s <replaceable class="parameter">strength</replaceable></option></arg> @@ -58,7 +59,7 @@ <title>DESCRIPTION</title> <para> <command>dnssec-keygen</command> generates keys for DNSSEC - (Secure DNS), as defined in RFC 2535. It can also generate + (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. </para> @@ -73,13 +74,16 @@ <listitem> <para> Selects the cryptographic algorithm. The value of - <option>algorithm</option> must be one of RSAMD5 or RSA, + <option>algorithm</option> must be one of RSAMD5 (RSA) or RSASHA1, DSA, DH (Diffie Hellman), or HMAC-MD5. These values are case insensitive. </para> <para> - Note that for DNSSEC, DSA is a mandatory to implement algorithm, - and RSA is recommended. For TSIG, HMAC-MD5 is mandatory. + Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, + and DSA is recommended. For TSIG, HMAC-MD5 is mandatory. + </para> + <para> + Note 2: HMAC-MD5 and DH automatically set the -k flag. </para> </listitem> </varlistentry> @@ -89,7 +93,7 @@ <listitem> <para> Specifies the number of bits in the key. The choice of key - size depends on the algorithm used. RSA keys must be between + 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 @@ -104,8 +108,8 @@ <para> Specifies the owner type of the key. The value of <option>nametype</option> must either be ZONE (for a DNSSEC - zone key), HOST or ENTITY (for a key associated with a host), - or USER (for a key associated with a user). These values are + 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. </para> </listitem> @@ -125,7 +129,7 @@ <term>-e</term> <listitem> <para> - If generating an RSA key, use a large exponent. + If generating an RSAMD5/RSASHA1 key, use a large exponent. </para> </listitem> </varlistentry> @@ -134,8 +138,8 @@ <term>-f <replaceable class="parameter">flag</replaceable></term> <listitem> <para> - Set the specified flag in the flag field of the key record. - The only recognized flag is KSK (Key Signing Key). + Set the specified flag in the flag field of the KEY/DNSKEY record. + The only recognized flag is KSK (Key Signing Key) DNSKEY. </para> </listitem> </varlistentry> @@ -163,6 +167,15 @@ </varlistentry> <varlistentry> + <term>-k</term> + <listitem> + <para> + Generate KEY records rather than DNSKEY records. + </para> + </listitem> + </varlistentry> + + <varlistentry> <term>-p <replaceable class="parameter">protocol</replaceable></term> <listitem> <para> @@ -303,14 +316,6 @@ <title>SEE ALSO</title> <para> <citerefentry> - <refentrytitle>dnssec-makekeyset</refentrytitle> - <manvolnum>8</manvolnum> - </citerefentry>, - <citerefentry> - <refentrytitle>dnssec-signkey</refentrytitle> - <manvolnum>8</manvolnum> - </citerefentry>, - <citerefentry> <refentrytitle>dnssec-signzone</refentrytitle> <manvolnum>8</manvolnum> </citerefentry>, @@ -324,7 +329,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/dist/bind/bin/dnssec/dnssec-keygen.html b/dist/bind/bin/dnssec/dnssec-keygen.html index a5e30d60608..be9dc7b2747 100644 --- a/dist/bind/bin/dnssec/dnssec-keygen.html +++ b/dist/bind/bin/dnssec/dnssec-keygen.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: dnssec-keygen.html,v 1.5.2.1.4.3 2004/03/08 04:04:17 marka Exp --> +<!-- Id: dnssec-keygen.html,v 1.5.2.1.4.6 2004/08/22 23:38:58 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >dnssec-keygen</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,10 +35,10 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" +></A ><SPAN CLASS="APPLICATION" >dnssec-keygen</SPAN -></A ></H1 ><DIV CLASS="REFNAMEDIV" @@ -62,97 +62,78 @@ NAME="AEN13" ><B CLASS="COMMAND" >dnssec-keygen</B -> {-a <TT +> {-a <VAR CLASS="REPLACEABLE" -><I ->algorithm</I -></TT ->} {-b <TT +>algorithm</VAR +>} {-b <VAR CLASS="REPLACEABLE" -><I ->keysize</I -></TT ->} {-n <TT +>keysize</VAR +>} {-n <VAR CLASS="REPLACEABLE" -><I ->nametype</I -></TT ->} [<TT +>nametype</VAR +>} [<VAR CLASS="OPTION" ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->class</I -></TT -></TT ->] [<TT +>class</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-e</TT ->] [<TT +>-e</VAR +>] [<VAR CLASS="OPTION" ->-f <TT +>-f <VAR CLASS="REPLACEABLE" -><I ->flag</I -></TT -></TT ->] [<TT +>flag</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-g <TT +>-g <VAR CLASS="REPLACEABLE" -><I ->generator</I -></TT -></TT ->] [<TT +>generator</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-h</TT ->] [<TT +>-h</VAR +>] [<VAR CLASS="OPTION" ->-p <TT +>-k</VAR +>] [<VAR +CLASS="OPTION" +>-p <VAR CLASS="REPLACEABLE" -><I ->protocol</I -></TT -></TT ->] [<TT +>protocol</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-r <TT +>-r <VAR CLASS="REPLACEABLE" -><I ->randomdev</I -></TT -></TT ->] [<TT +>randomdev</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-s <TT +>-s <VAR CLASS="REPLACEABLE" -><I ->strength</I -></TT -></TT ->] [<TT +>strength</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->type</I -></TT -></TT ->] [<TT +>type</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-v <TT +>-v <VAR CLASS="REPLACEABLE" -><I ->level</I -></TT -></TT +>level</VAR +></VAR >] {name}</P ></DIV ><DIV CLASS="REFSECT1" ><A -NAME="AEN51" +NAME="AEN53" ></A ><H2 >DESCRIPTION</H2 @@ -161,7 +142,7 @@ NAME="AEN51" CLASS="COMMAND" >dnssec-keygen</B > generates keys for DNSSEC - (Secure DNS), as defined in RFC 2535. It can also generate + (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. </P @@ -169,7 +150,7 @@ CLASS="COMMAND" ><DIV CLASS="REFSECT1" ><A -NAME="AEN55" +NAME="AEN57" ></A ><H2 >OPTIONS</H2 @@ -179,38 +160,37 @@ NAME="AEN55" CLASS="VARIABLELIST" ><DL ><DT ->-a <TT +>-a <VAR CLASS="REPLACEABLE" -><I ->algorithm</I -></TT +>algorithm</VAR ></DT ><DD ><P > Selects the cryptographic algorithm. The value of - <TT + <VAR CLASS="OPTION" ->algorithm</TT -> must be one of RSAMD5 or RSA, +>algorithm</VAR +> must be one of RSAMD5 (RSA) or RSASHA1, DSA, DH (Diffie Hellman), or HMAC-MD5. These values are case insensitive. </P ><P -> Note that for DNSSEC, DSA is a mandatory to implement algorithm, - and RSA is recommended. For TSIG, HMAC-MD5 is mandatory. +> Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, + and DSA is recommended. For TSIG, HMAC-MD5 is mandatory. + </P +><P +> Note 2: HMAC-MD5 and DH automatically set the -k flag. </P ></DD ><DT ->-b <TT +>-b <VAR CLASS="REPLACEABLE" -><I ->keysize</I -></TT +>keysize</VAR ></DT ><DD ><P > Specifies the number of bits in the key. The choice of key - size depends on the algorithm used. RSA keys must be between + 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 @@ -218,30 +198,26 @@ CLASS="REPLACEABLE" </P ></DD ><DT ->-n <TT +>-n <VAR CLASS="REPLACEABLE" -><I ->nametype</I -></TT +>nametype</VAR ></DT ><DD ><P > Specifies the owner type of the key. The value of - <TT + <VAR CLASS="OPTION" ->nametype</TT +>nametype</VAR > must either be ZONE (for a DNSSEC - zone key), HOST or ENTITY (for a key associated with a host), - or USER (for a key associated with a user). These values are + 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. </P ></DD ><DT ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->class</I -></TT +>class</VAR ></DT ><DD ><P @@ -253,28 +229,24 @@ CLASS="REPLACEABLE" >-e</DT ><DD ><P -> If generating an RSA key, use a large exponent. +> If generating an RSAMD5/RSASHA1 key, use a large exponent. </P ></DD ><DT ->-f <TT +>-f <VAR CLASS="REPLACEABLE" -><I ->flag</I -></TT +>flag</VAR ></DT ><DD ><P -> Set the specified flag in the flag field of the key record. - The only recognized flag is KSK (Key Signing Key). +> Set the specified flag in the flag field of the KEY/DNSKEY record. + The only recognized flag is KSK (Key Signing Key) DNSKEY. </P ></DD ><DT ->-g <TT +>-g <VAR CLASS="REPLACEABLE" -><I ->generator</I -></TT +>generator</VAR ></DT ><DD ><P @@ -296,11 +268,16 @@ CLASS="COMMAND" </P ></DD ><DT ->-p <TT +>-k</DT +><DD +><P +> Generate KEY records rather than DNSKEY records. + </P +></DD +><DT +>-p <VAR CLASS="REPLACEABLE" -><I ->protocol</I -></TT +>protocol</VAR ></DT ><DD ><P @@ -311,11 +288,9 @@ CLASS="REPLACEABLE" </P ></DD ><DT ->-r <TT +>-r <VAR CLASS="REPLACEABLE" -><I ->randomdev</I -></TT +>randomdev</VAR ></DT ><DD ><P @@ -339,11 +314,9 @@ CLASS="FILENAME" </P ></DD ><DT ->-s <TT +>-s <VAR CLASS="REPLACEABLE" -><I ->strength</I -></TT +>strength</VAR ></DT ><DD ><P @@ -353,17 +326,15 @@ CLASS="REPLACEABLE" </P ></DD ><DT ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->type</I -></TT +>type</VAR ></DT ><DD ><P -> Indicates the use of the key. <TT +> Indicates the use of the key. <VAR CLASS="OPTION" ->type</TT +>type</VAR > must be one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default is AUTHCONF. AUTH refers to the ability to authenticate @@ -371,11 +342,9 @@ CLASS="OPTION" </P ></DD ><DT ->-v <TT +>-v <VAR CLASS="REPLACEABLE" -><I ->level</I -></TT +>level</VAR ></DT ><DD ><P @@ -388,7 +357,7 @@ CLASS="REPLACEABLE" ><DIV CLASS="REFSECT1" ><A -NAME="AEN129" +NAME="AEN136" ></A ><H2 >GENERATED KEYS</H2 @@ -484,37 +453,31 @@ CLASS="FILENAME" ><DIV CLASS="REFSECT1" ><A -NAME="AEN156" +NAME="AEN163" ></A ><H2 >EXAMPLE</H2 ><P > To generate a 768-bit DSA key for the domain - <TT + <KBD CLASS="USERINPUT" -><B ->example.com</B -></TT +>example.com</KBD >, the following command would be issued: </P ><P -> <TT +> <KBD CLASS="USERINPUT" -><B ->dnssec-keygen -a DSA -b 768 -n ZONE example.com</B -></TT +>dnssec-keygen -a DSA -b 768 -n ZONE example.com</KBD > </P ><P > The command would print a string of the form: </P ><P -> <TT +> <KBD CLASS="USERINPUT" -><B ->Kexample.com.+003+26160</B -></TT +>Kexample.com.+003+26160</KBD > </P ><P @@ -535,7 +498,7 @@ CLASS="FILENAME" ><DIV CLASS="REFSECT1" ><A -NAME="AEN169" +NAME="AEN176" ></A ><H2 >SEE ALSO</H2 @@ -544,20 +507,6 @@ NAME="AEN169" CLASS="CITEREFENTRY" ><SPAN CLASS="REFENTRYTITLE" ->dnssec-makekeyset</SPAN ->(8)</SPAN ->, - <SPAN -CLASS="CITEREFENTRY" -><SPAN -CLASS="REFENTRYTITLE" ->dnssec-signkey</SPAN ->(8)</SPAN ->, - <SPAN -CLASS="CITEREFENTRY" -><SPAN -CLASS="REFENTRYTITLE" >dnssec-signzone</SPAN >(8)</SPAN >, @@ -582,12 +531,12 @@ CLASS="CITETITLE" ><DIV CLASS="REFSECT1" ><A -NAME="AEN185" +NAME="AEN186" ></A ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/dist/bind/bin/dnssec/dnssec-makekeyset.c b/dist/bind/bin/dnssec/dnssec-makekeyset.c index 791dfa71fff..b6ef180184a 100644 --- a/dist/bind/bin/dnssec/dnssec-makekeyset.c +++ b/dist/bind/bin/dnssec/dnssec-makekeyset.c @@ -1,4 +1,4 @@ -/* $NetBSD: dnssec-makekeyset.c,v 1.1.1.1 2004/05/17 23:43:20 christos Exp $ */ +/* $NetBSD: dnssec-makekeyset.c,v 1.1.1.2 2004/11/06 23:53:32 christos Exp $ */ /* * Portions Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -18,7 +18,7 @@ * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* Id: dnssec-makekeyset.c,v 1.52.2.1.10.6 2004/03/08 04:04:17 marka Exp */ +/* Id: dnssec-makekeyset.c,v 1.52.2.1.10.7 2004/08/28 06:25:27 marka Exp */ #include <config.h> @@ -27,6 +27,7 @@ #include <isc/commandline.h> #include <isc/entropy.h> #include <isc/mem.h> +#include <isc/print.h> #include <isc/string.h> #include <isc/util.h> diff --git a/dist/bind/bin/dnssec/dnssec-makekeyset.docbook b/dist/bind/bin/dnssec/dnssec-makekeyset.docbook index 4de6ed54157..df6d78ce174 100644 --- a/dist/bind/bin/dnssec/dnssec-makekeyset.docbook +++ b/dist/bind/bin/dnssec/dnssec-makekeyset.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: dnssec-makekeyset.docbook,v 1.2.2.3.4.1 2004/03/06 10:21:15 marka Exp --> +<!-- Id: dnssec-makekeyset.docbook,v 1.2.2.3.4.2 2004/06/03 02:24:55 marka Exp --> <refentry> <refentryinfo> @@ -220,7 +220,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/dist/bind/bin/dnssec/dnssec-signkey.c b/dist/bind/bin/dnssec/dnssec-signkey.c index 2d91626b270..2ce7b093e74 100644 --- a/dist/bind/bin/dnssec/dnssec-signkey.c +++ b/dist/bind/bin/dnssec/dnssec-signkey.c @@ -1,4 +1,4 @@ -/* $NetBSD: dnssec-signkey.c,v 1.1.1.1 2004/05/17 23:43:20 christos Exp $ */ +/* $NetBSD: dnssec-signkey.c,v 1.1.1.2 2004/11/06 23:53:32 christos Exp $ */ /* * Portions Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -18,7 +18,7 @@ * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* Id: dnssec-signkey.c,v 1.50.2.2.2.6 2004/03/08 04:04:17 marka Exp */ +/* Id: dnssec-signkey.c,v 1.50.2.2.2.7 2004/08/28 06:25:28 marka Exp */ #include <config.h> @@ -28,6 +28,7 @@ #include <isc/commandline.h> #include <isc/entropy.h> #include <isc/mem.h> +#include <isc/print.h> #include <isc/util.h> #include <dns/db.h> diff --git a/dist/bind/bin/dnssec/dnssec-signkey.docbook b/dist/bind/bin/dnssec/dnssec-signkey.docbook index 37fa9350271..fa5a96125c3 100644 --- a/dist/bind/bin/dnssec/dnssec-signkey.docbook +++ b/dist/bind/bin/dnssec/dnssec-signkey.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: dnssec-signkey.docbook,v 1.2.2.2.4.1 2004/03/06 10:21:15 marka Exp --> +<!-- Id: dnssec-signkey.docbook,v 1.2.2.2.4.2 2004/06/03 02:24:55 marka Exp --> <refentry> <refentryinfo> @@ -224,7 +224,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/dist/bind/bin/dnssec/dnssec-signzone.8 b/dist/bind/bin/dnssec/dnssec-signzone.8 index 7f723e865b5..bc618719b14 100644 --- a/dist/bind/bin/dnssec/dnssec-signzone.8 +++ b/dist/bind/bin/dnssec/dnssec-signzone.8 @@ -1,4 +1,4 @@ -.\" $NetBSD: dnssec-signzone.8,v 1.1.1.1 2004/05/17 23:43:20 christos Exp $ +.\" $NetBSD: dnssec-signzone.8,v 1.1.1.2 2004/11/06 23:53:32 christos Exp $ .\" .\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000-2003 Internet Software Consortium. @@ -15,7 +15,7 @@ .\" 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.4 2004/03/15 01:02:42 marka Exp +.\" 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 @@ -25,14 +25,12 @@ dnssec-signzone \- DNSSEC zone signing tool \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. If there -is a \fIsignedkey\fR file from the zone's parent, -the parent's signatures will be incorporated into the generated -signed zone file. The security status of delegations from the -signed zone (that is, whether the child zones are secure or not) is +\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 -\fIsignedkey\fR file for each child zone. +\fIkeyset\fR file for each child zone. .SH "OPTIONS" .TP \fB-a\fR @@ -50,7 +48,7 @@ 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 \fIsignedkey\fR files in +Look for \fIkeyset\fR files in \fBdirectory\fR as the directory .TP \fB-g\fR @@ -148,8 +146,8 @@ current directory. 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 -\fIsignedkey\fR files associated with this zone -or any child zones, they must be in the current directory. +\fIkeyset\fR files associated with child zones, +they must be in the current directory. \fBexample.com\fR, the following command would be issued: .PP @@ -164,9 +162,8 @@ should be referenced in a zone statement in a .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 +Internet Systems Consortium diff --git a/dist/bind/bin/dnssec/dnssec-signzone.c b/dist/bind/bin/dnssec/dnssec-signzone.c index c10087fc648..b685fee3619 100644 --- a/dist/bind/bin/dnssec/dnssec-signzone.c +++ b/dist/bind/bin/dnssec/dnssec-signzone.c @@ -1,4 +1,4 @@ -/* $NetBSD: dnssec-signzone.c,v 1.1.1.1 2004/05/17 23:43:21 christos Exp $ */ +/* $NetBSD: dnssec-signzone.c,v 1.1.1.2 2004/11/06 23:53:32 christos Exp $ */ /* * Portions Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -18,7 +18,7 @@ * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* Id: dnssec-signzone.c,v 1.139.2.2.4.12 2004/04/15 02:10:38 marka Exp */ +/* Id: dnssec-signzone.c,v 1.139.2.2.4.16 2004/08/28 06:25:29 marka Exp */ #include <config.h> @@ -33,6 +33,7 @@ #include <isc/mem.h> #include <isc/mutex.h> #include <isc/os.h> +#include <isc/print.h> #include <isc/serial.h> #include <isc/stdio.h> #include <isc/string.h> @@ -224,7 +225,7 @@ signwithkey(dns_name_t *name, dns_rdataset_t *rdataset, dns_rdata_t *rdata, if (result != ISC_R_SUCCESS) { char keystr[KEY_FORMATSIZE]; key_format(key, keystr, sizeof(keystr)); - fatal("key '%s' failed to sign data: %s", + fatal("dnskey '%s' failed to sign data: %s", keystr, isc_result_totext(result)); } INCSTAT(nsigned); @@ -254,30 +255,32 @@ iszonekey(signer_key_t *key) { } /* - * Finds the key that generated a SIG, if possible. First look at the keys + * 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 *sig) { +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 (sig->keyid == dst_key_id(key->key) && - sig->algorithm == dst_key_alg(key->key) && - dns_name_equal(&sig->signer, dst_key_name(key->key))) + 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(&sig->signer, sig->keyid, sig->algorithm, - DST_TYPE_PUBLIC, NULL, mctx, &pubkey); + 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(&sig->signer, sig->keyid, sig->algorithm, + result = dst_key_fromfile(&rrsig->signer, rrsig->keyid, + rrsig->algorithm, DST_TYPE_PUBLIC | DST_TYPE_PRIVATE, NULL, mctx, &privkey); if (result == ISC_R_SUCCESS) { @@ -290,8 +293,8 @@ keythatsigned(dns_rdata_rrsig_t *sig) { } /* - * Check to see if we expect to find a key at this name. If we see a SIG - * and can't find the signing key that we expect to find, we drop the sig. + * 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 @@ -315,17 +318,17 @@ expecttofindkey(dns_name_t *name) { return (ISC_FALSE); } dns_name_format(name, namestr, sizeof(namestr)); - fatal("failure looking for '%s KEY' in database: %s", + 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 *sig) + dns_rdata_t *rrsig) { isc_result_t result; - result = dns_dnssec_verify(name, set, key->key, ISC_FALSE, mctx, sig); + result = dns_dnssec_verify(name, set, key->key, ISC_FALSE, mctx, rrsig); if (result == ISC_R_SUCCESS) { INCSTAT(nverified); return (ISC_TRUE); @@ -336,17 +339,17 @@ setverifies(dns_name_t *name, dns_rdataset_t *set, signer_key_t *key, } /* - * Signs a set. Goes through contortions to decide if each SIG should + * 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 *diff, dns_dbnode_t *node, dns_name_t *name, +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 sig; + dns_rdata_rrsig_t rrsig; signer_key_t *key; isc_result_t result; isc_boolean_t nosigs = ISC_FALSE; @@ -372,7 +375,7 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, nosigs = ISC_TRUE; } if (result != ISC_R_SUCCESS) - fatal("failed while looking for '%s SIG %s': %s", + fatal("failed while looking for '%s RRSIG %s': %s", namestr, typestr, isc_result_totext(result)); vbprintf(1, "%s/%s:\n", namestr, typestr); @@ -399,44 +402,44 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, dns_rdataset_current(&sigset, &sigrdata); - result = dns_rdata_tostruct(&sigrdata, &sig, NULL); + result = dns_rdata_tostruct(&sigrdata, &rrsig, NULL); check_result(result, "dns_rdata_tostruct"); - future = isc_serial_lt(now, sig.timesigned); + future = isc_serial_lt(now, rrsig.timesigned); - key = keythatsigned(&sig); - sig_format(&sig, sigstr, sizeof(sigstr)); + key = keythatsigned(&rrsig); + sig_format(&rrsig, sigstr, sizeof(sigstr)); if (key != NULL && issigningkey(key)) - expired = isc_serial_gt(now + cycle, sig.timeexpire); + expired = isc_serial_gt(now + cycle, rrsig.timeexpire); else - expired = isc_serial_gt(now, sig.timeexpire); + expired = isc_serial_gt(now, rrsig.timeexpire); - if (isc_serial_gt(sig.timesigned, sig.timeexpire)) { - /* sig is dropped and not replaced */ - vbprintf(2, "\tsig by %s dropped - " + 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(&sig.signer)) + expecttofindkey(&rrsig.signer)) { - /* sig is dropped and not replaced */ - vbprintf(2, "\tsig by %s dropped - " - "private key not found\n", + /* 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, "\tsig by %s %s - key not found\n", + 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, "\tsig by %s retained\n", sigstr); + vbprintf(2, "\trrsig by %s retained\n", sigstr); keep = ISC_TRUE; wassignedby[key->position] = ISC_TRUE; nowsignedby[key->position] = ISC_TRUE; } else { - vbprintf(2, "\tsig by %s dropped - %s\n", + vbprintf(2, "\trrsig by %s dropped - %s\n", sigstr, expired ? "expired" : "failed to verify"); @@ -446,34 +449,52 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, } else if (iszonekey(key)) { if (!expired && setverifies(name, set, key, &sigrdata)) { - vbprintf(2, "\tsig by %s retained\n", sigstr); + vbprintf(2, "\trrsig by %s retained\n", sigstr); keep = ISC_TRUE; wassignedby[key->position] = ISC_TRUE; nowsignedby[key->position] = ISC_TRUE; } else { - vbprintf(2, "\tsig by %s dropped - %s\n", + vbprintf(2, "\trrsig by %s dropped - %s\n", sigstr, expired ? "expired" : "failed to verify"); wassignedby[key->position] = ISC_TRUE; } } else if (!expired) { - vbprintf(2, "\tsig by %s retained\n", sigstr); + vbprintf(2, "\trrsig by %s retained\n", sigstr); keep = ISC_TRUE; } else { - vbprintf(2, "\tsig by %s expired\n", sigstr); + 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(diff, &tuple); + dns_diff_append(del, &tuple); INCSTAT(ndropped); } @@ -483,8 +504,10 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, unsigned char array[BUFSIZE]; char keystr[KEY_FORMATSIZE]; + INSIST(!keep); + key_format(key->key, keystr, sizeof(keystr)); - vbprintf(1, "\tresigning with key %s\n", 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; @@ -493,11 +516,11 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, name, ttl, &trdata, &tuple); check_result(result, "dns_difftuple_create"); - dns_diff_append(diff, &tuple); + dns_diff_append(add, &tuple); } dns_rdata_reset(&sigrdata); - dns_rdata_freestruct(&sig); + dns_rdata_freestruct(&rrsig); result = dns_rdataset_next(&sigset); } if (result == ISC_R_NOMORE) @@ -528,7 +551,7 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, continue; key_format(key->key, keystr, sizeof(keystr)); - vbprintf(1, "\tsigning with key %s\n", 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); @@ -536,7 +559,7 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD, name, ttl, &trdata, &tuple); check_result(result, "dns_difftuple_create"); - dns_diff_append(diff, &tuple); + dns_diff_append(add, &tuple); } isc_mem_put(mctx, wassignedby, arraysize * sizeof(isc_boolean_t)); @@ -609,7 +632,7 @@ loadds(dns_name_t *name, isc_uint32_t ttl, dns_rdataset_t *dsset) { return (result); } - vbprintf(2, "found KEY records\n"); + vbprintf(2, "found DNSKEY records\n"); result = dns_db_newversion(db, &ver); check_result(result, "dns_db_newversion"); @@ -755,7 +778,7 @@ delegation(dns_name_t *name, dns_dbnode_t *node, isc_uint32_t *ttlp) { /* * Signs all records at a name. This mostly just signs each set individually, - * but also adds the SIG bit to any NSECs generated earlier, deals with + * but also adds the RRSIG bit to any NSECs generated earlier, deals with * parent/child KEY signatures, and handles other exceptional cases. */ static void @@ -767,7 +790,7 @@ signname(dns_dbnode_t *node, dns_name_t *name) { isc_boolean_t hasds = ISC_FALSE; isc_boolean_t atorigin; isc_boolean_t changed = ISC_FALSE; - dns_diff_t diff; + dns_diff_t del, add; char namestr[DNS_NAME_FORMATSIZE]; isc_uint32_t nsttl = 0; @@ -817,9 +840,9 @@ signname(dns_dbnode_t *node, dns_name_t *name) { dns_rdataset_disassociate(&sigdsset); } else if (dns_rdataset_isassociated(&sigdsset)) { result = dns_db_deleterdataset(gdb, node, - gversion, - dns_rdatatype_rrsig, - dns_rdatatype_ds); + gversion, + dns_rdatatype_rrsig, + dns_rdatatype_ds); check_result(result, "dns_db_deleterdataset"); dns_rdataset_disassociate(&sigdsset); } @@ -852,7 +875,8 @@ signname(dns_dbnode_t *node, dns_name_t *name) { /* * Now iterate through the rdatasets. */ - dns_diff_init(mctx, &diff); + 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()"); @@ -860,7 +884,7 @@ signname(dns_dbnode_t *node, dns_name_t *name) { while (result == ISC_R_SUCCESS) { dns_rdatasetiter_current(rdsiter, &rdataset); - /* If this is a SIG set, skip it. */ + /* If this is a RRSIG set, skip it. */ if (rdataset.type == dns_rdatatype_rrsig) goto skip; @@ -873,21 +897,14 @@ signname(dns_dbnode_t *node, dns_name_t *name) { if (rdataset.type != dns_rdatatype_nsec && rdataset.type != dns_rdatatype_ds) goto skip; -#if 0 - /* - * The current draft allows DS not at a zone cut. - * This is a bad idea. Update once the RFC is published. - * XXXMPA. - */ } 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); -#endif } - signset(&diff, node, name, &rdataset); + signset(&del, &add, node, name, &rdataset); skip: dns_rdataset_disassociate(&rdataset); @@ -899,12 +916,18 @@ signname(dns_dbnode_t *node, dns_name_t *name) { dns_rdatasetiter_destroy(&rdsiter); - result = dns_diff_applysilently(&diff, gdb, gversion); + 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(&diff); + dns_diff_clear(&del); + dns_diff_clear(&add); } static inline isc_boolean_t @@ -921,7 +944,8 @@ active_node(dns_dbnode_t *node) { result = dns_rdatasetiter_first(rdsiter); while (result == ISC_R_SUCCESS) { dns_rdatasetiter_current(rdsiter, &rdataset); - if (rdataset.type != dns_rdatatype_nsec) + if (rdataset.type != dns_rdatatype_nsec && + rdataset.type != dns_rdatatype_rrsig) active = ISC_TRUE; dns_rdataset_disassociate(&rdataset); if (!active) @@ -932,18 +956,41 @@ active_node(dns_dbnode_t *node) { if (result != ISC_R_NOMORE) fatal("rdataset iteration failed: %s", isc_result_totext(result)); - dns_rdatasetiter_destroy(&rdsiter); if (!active) { /* - * Make sure there is no NSEC record for this node. + * 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"); + 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); } @@ -981,7 +1028,7 @@ soattl(void) { } /* - * Delete any SIG records at a node. + * Delete any RRSIG records at a node. */ static void cleannode(dns_db_t *db, dns_dbversion_t *version, dns_dbnode_t *node) { @@ -1413,8 +1460,8 @@ warnifallksk(dns_db_t *db) { dns_db_detachnode(db, &node); dns_db_closeversion(db, ¤tversion, ISC_FALSE); if (!have_non_ksk && !ignoreksk) - fprintf(stderr, - "%s: warning: No non-KSK key found. Supply non-KSK key or use '-z'.\n", + fprintf(stderr, "%s: warning: No non-KSK dnskey found. " + "Supply non-KSK dnskey or use '-z'.\n", program); } @@ -1570,9 +1617,9 @@ usage(void) { fprintf(stderr, "\t-g:\t"); fprintf(stderr, "generate DS records from keyset files\n"); fprintf(stderr, "\t-s YYYYMMDDHHMMSS|+offset:\n"); - fprintf(stderr, "\t\tSIG start time - absolute|offset (now - 1 hour)\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\tSIG end time - absolute|from start|from now " + 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 " @@ -1594,6 +1641,8 @@ usage(void) { 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"); @@ -1852,7 +1901,7 @@ main(int argc, char *argv[]) { DST_TYPE_PRIVATE, mctx, &newkey); if (result != ISC_R_SUCCESS) - fatal("cannot load key %s: %s", argv[i], + fatal("cannot load dnskey %s: %s", argv[i], isc_result_totext(result)); key = ISC_LIST_HEAD(keylist); @@ -1865,7 +1914,7 @@ main(int argc, char *argv[]) { { if (!dst_key_isprivate(dkey)) fatal("cannot sign zone with " - "non-private key %s", + "non-private dnskey %s", argv[i]); break; } @@ -1889,7 +1938,7 @@ main(int argc, char *argv[]) { DST_TYPE_PRIVATE, mctx, &newkey); if (result != ISC_R_SUCCESS) - fatal("cannot load key %s: %s", dskeyfile[i], + fatal("cannot load dnskey %s: %s", dskeyfile[i], isc_result_totext(result)); key = ISC_LIST_HEAD(keylist); @@ -1911,7 +1960,7 @@ main(int argc, char *argv[]) { key = ISC_LIST_NEXT(key, link); } if (key == NULL) { - /* Override key flags. */ + /* Override dnskey flags. */ key = newkeystruct(newkey, ISC_TRUE); key->isksk = ISC_TRUE; key->isdsk = ISC_FALSE; diff --git a/dist/bind/bin/dnssec/dnssec-signzone.docbook b/dist/bind/bin/dnssec/dnssec-signzone.docbook index 0bb9509cfe2..c9724cab568 100644 --- a/dist/bind/bin/dnssec/dnssec-signzone.docbook +++ b/dist/bind/bin/dnssec/dnssec-signzone.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: dnssec-signzone.docbook,v 1.2.2.2.4.6 2004/03/10 02:55:51 marka Exp --> +<!-- Id: dnssec-signzone.docbook,v 1.2.2.2.4.8 2004/06/11 01:17:35 marka Exp --> <refentry> <refentryinfo> @@ -63,14 +63,12 @@ <refsect1> <title>DESCRIPTION</title> <para> - <command>dnssec-signzone</command> signs a zone. It generates NSEC - and RRSIG records and produces a signed version of the zone. If there - is a <filename>signedkey</filename> file from the zone's parent, - the parent's signatures will be incorporated into the generated - signed zone file. 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 - <filename>signedkey</filename> file for each child zone. + <command>dnssec-signzone</command> 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 + <filename>keyset</filename> file for each child zone. </para> </refsect1> @@ -120,7 +118,7 @@ <term>-d <replaceable class="parameter">directory</replaceable></term> <listitem> <para> - Look for <filename>signedkey</filename> files in + Look for <filename>keyset</filename> files in <option>directory</option> as the directory </para> </listitem> @@ -317,8 +315,8 @@ The following command signs the <userinput>example.com</userinput> zone with the DSA key generated in the <command>dnssec-keygen</command> man page. The zone's keys must be in the zone. If there are - <filename>signedkey</filename> files associated with this zone - or any child zones, they must be in the current directory. + <filename>keyset</filename> files associated with child zones, + they must be in the current directory. <userinput>example.com</userinput>, the following command would be issued: </para> @@ -343,10 +341,6 @@ <refentrytitle>dnssec-keygen</refentrytitle> <manvolnum>8</manvolnum> </citerefentry>, - <citerefentry> - <refentrytitle>dnssec-signkey</refentrytitle> - <manvolnum>8</manvolnum> - </citerefentry>, <citetitle>BIND 9 Administrator Reference Manual</citetitle>, <citetitle>RFC 2535</citetitle>. </para> @@ -355,7 +349,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/dist/bind/bin/dnssec/dnssec-signzone.html b/dist/bind/bin/dnssec/dnssec-signzone.html index 947c334edeb..8671cb4aefa 100644 --- a/dist/bind/bin/dnssec/dnssec-signzone.html +++ b/dist/bind/bin/dnssec/dnssec-signzone.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: dnssec-signzone.html,v 1.4.2.1.4.4 2004/03/15 01:02:42 marka Exp --> +<!-- Id: dnssec-signzone.html,v 1.4.2.1.4.7 2004/08/22 23:38:58 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >dnssec-signzone</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,10 +35,10 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" +></A ><SPAN CLASS="APPLICATION" >dnssec-signzone</SPAN -></A ></H1 ><DIV CLASS="REFNAMEDIV" @@ -62,120 +62,96 @@ NAME="AEN13" ><B CLASS="COMMAND" >dnssec-signzone</B -> [<TT +> [<VAR CLASS="OPTION" ->-a</TT ->] [<TT +>-a</VAR +>] [<VAR CLASS="OPTION" ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->class</I -></TT -></TT ->] [<TT +>class</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-d <TT +>-d <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT -></TT ->] [<TT +>directory</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-e <TT +>-e <VAR CLASS="REPLACEABLE" -><I ->end-time</I -></TT -></TT ->] [<TT +>end-time</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-f <TT +>-f <VAR CLASS="REPLACEABLE" -><I ->output-file</I -></TT -></TT ->] [<TT +>output-file</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-g</TT ->] [<TT +>-g</VAR +>] [<VAR CLASS="OPTION" ->-h</TT ->] [<TT +>-h</VAR +>] [<VAR CLASS="OPTION" ->-k <TT +>-k <VAR CLASS="REPLACEABLE" -><I ->key</I -></TT -></TT ->] [<TT +>key</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-l <TT +>-l <VAR CLASS="REPLACEABLE" -><I ->domain</I -></TT -></TT ->] [<TT +>domain</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-i <TT +>-i <VAR CLASS="REPLACEABLE" -><I ->interval</I -></TT -></TT ->] [<TT +>interval</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-n <TT +>-n <VAR CLASS="REPLACEABLE" -><I ->nthreads</I -></TT -></TT ->] [<TT +>nthreads</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-o <TT +>-o <VAR CLASS="REPLACEABLE" -><I ->origin</I -></TT -></TT ->] [<TT +>origin</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-p</TT ->] [<TT +>-p</VAR +>] [<VAR CLASS="OPTION" ->-r <TT +>-r <VAR CLASS="REPLACEABLE" -><I ->randomdev</I -></TT -></TT ->] [<TT +>randomdev</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-s <TT +>-s <VAR CLASS="REPLACEABLE" -><I ->start-time</I -></TT -></TT ->] [<TT +>start-time</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-t</TT ->] [<TT +>-t</VAR +>] [<VAR CLASS="OPTION" ->-v <TT +>-v <VAR CLASS="REPLACEABLE" -><I ->level</I -></TT -></TT ->] [<TT +>level</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-z</TT +>-z</VAR >] {zonefile} [key...]</P ></DIV ><DIV @@ -189,26 +165,21 @@ NAME="AEN66" > <B CLASS="COMMAND" >dnssec-signzone</B -> signs a zone. It generates NSEC - and RRSIG records and produces a signed version of the zone. If there - is a <TT -CLASS="FILENAME" ->signedkey</TT -> file from the zone's parent, - the parent's signatures will be incorporated into the generated - signed zone file. 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 +> 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 <TT CLASS="FILENAME" ->signedkey</TT +>keyset</TT > file for each child zone. </P ></DIV ><DIV CLASS="REFSECT1" ><A -NAME="AEN72" +NAME="AEN71" ></A ><H2 >OPTIONS</H2 @@ -225,11 +196,9 @@ CLASS="VARIABLELIST" </P ></DD ><DT ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->class</I -></TT +>class</VAR ></DT ><DD ><P @@ -237,11 +206,9 @@ CLASS="REPLACEABLE" </P ></DD ><DT ->-k <TT +>-k <VAR CLASS="REPLACEABLE" -><I ->key</I -></TT +>key</VAR ></DT ><DD ><P @@ -250,11 +217,9 @@ CLASS="REPLACEABLE" </P ></DD ><DT ->-l <TT +>-l <VAR CLASS="REPLACEABLE" -><I ->domain</I -></TT +>domain</VAR ></DT ><DD ><P @@ -263,21 +228,19 @@ CLASS="REPLACEABLE" </P ></DD ><DT ->-d <TT +>-d <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT +>directory</VAR ></DT ><DD ><P > Look for <TT CLASS="FILENAME" ->signedkey</TT +>keyset</TT > files in - <TT + <VAR CLASS="OPTION" ->directory</TT +>directory</VAR > as the directory </P ></DD @@ -290,11 +253,9 @@ CLASS="OPTION" </P ></DD ><DT ->-s <TT +>-s <VAR CLASS="REPLACEABLE" -><I ->start-time</I -></TT +>start-time</VAR ></DT ><DD ><P @@ -304,43 +265,39 @@ CLASS="REPLACEABLE" 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 <TT + If no <VAR CLASS="OPTION" ->start-time</TT +>start-time</VAR > is specified, the current time minus 1 hour (to allow for clock skew) is used. </P ></DD ><DT ->-e <TT +>-e <VAR CLASS="REPLACEABLE" -><I ->end-time</I -></TT +>end-time</VAR ></DT ><DD ><P > Specify the date and time when the generated RRSIG records - expire. As with <TT + expire. As with <VAR CLASS="OPTION" ->start-time</TT +>start-time</VAR >, 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 <TT + indicated with now+N. If no <VAR CLASS="OPTION" ->end-time</TT +>end-time</VAR > is specified, 30 days from the start time is used as a default. </P ></DD ><DT ->-f <TT +>-f <VAR CLASS="REPLACEABLE" -><I ->output-file</I -></TT +>output-file</VAR ></DT ><DD ><P @@ -364,18 +321,16 @@ CLASS="COMMAND" </P ></DD ><DT ->-i <TT +>-i <VAR CLASS="REPLACEABLE" -><I ->interval</I -></TT +>interval</VAR ></DT ><DD ><P > When a previously signed zone is passed as input, records - may be resigned. The <TT + may be resigned. The <VAR CLASS="OPTION" ->interval</TT +>interval</VAR > option specifies the cycle interval as an offset from the current time (in seconds). If a RRSIG record expires after the @@ -385,12 +340,12 @@ CLASS="OPTION" ><P > The default cycle interval is one quarter of the difference between the signature end and start times. So if neither - <TT + <VAR CLASS="OPTION" ->end-time</TT -> or <TT +>end-time</VAR +> or <VAR CLASS="OPTION" ->start-time</TT +>start-time</VAR > are specified, <B CLASS="COMMAND" @@ -403,11 +358,9 @@ CLASS="COMMAND" </P ></DD ><DT ->-n <TT +>-n <VAR CLASS="REPLACEABLE" -><I ->ncpus</I -></TT +>ncpus</VAR ></DT ><DD ><P @@ -416,11 +369,9 @@ CLASS="REPLACEABLE" </P ></DD ><DT ->-o <TT +>-o <VAR CLASS="REPLACEABLE" -><I ->origin</I -></TT +>origin</VAR ></DT ><DD ><P @@ -439,11 +390,9 @@ CLASS="REPLACEABLE" </P ></DD ><DT ->-r <TT +>-r <VAR CLASS="REPLACEABLE" -><I ->randomdev</I -></TT +>randomdev</VAR ></DT ><DD ><P @@ -474,11 +423,9 @@ CLASS="FILENAME" </P ></DD ><DT ->-v <TT +>-v <VAR CLASS="REPLACEABLE" -><I ->level</I -></TT +>level</VAR ></DT ><DD ><P @@ -515,16 +462,14 @@ CLASS="REPLACEABLE" ><DIV CLASS="REFSECT1" ><A -NAME="AEN182" +NAME="AEN181" ></A ><H2 >EXAMPLE</H2 ><P -> The following command signs the <TT +> The following command signs the <KBD CLASS="USERINPUT" -><B ->example.com</B -></TT +>example.com</KBD > zone with the DSA key generated in the <B CLASS="COMMAND" @@ -533,23 +478,19 @@ CLASS="COMMAND" man page. The zone's keys must be in the zone. If there are <TT CLASS="FILENAME" ->signedkey</TT -> files associated with this zone - or any child zones, they must be in the current directory. - <TT +>keyset</TT +> files associated with child zones, + they must be in the current directory. + <KBD CLASS="USERINPUT" -><B ->example.com</B -></TT +>example.com</KBD >, the following command would be issued: </P ><P -> <TT +> <KBD CLASS="USERINPUT" -><B ->dnssec-signzone -o example.com db.example.com Kexample.com.+003+26160</B -></TT +>dnssec-signzone -o example.com db.example.com Kexample.com.+003+26160</KBD > </P ><P @@ -574,7 +515,7 @@ CLASS="FILENAME" ><DIV CLASS="REFSECT1" ><A -NAME="AEN196" +NAME="AEN195" ></A ><H2 >SEE ALSO</H2 @@ -586,13 +527,6 @@ CLASS="REFENTRYTITLE" >dnssec-keygen</SPAN >(8)</SPAN >, - <SPAN -CLASS="CITEREFENTRY" -><SPAN -CLASS="REFENTRYTITLE" ->dnssec-signkey</SPAN ->(8)</SPAN ->, <I CLASS="CITETITLE" >BIND 9 Administrator Reference Manual</I @@ -606,12 +540,12 @@ CLASS="CITETITLE" ><DIV CLASS="REFSECT1" ><A -NAME="AEN207" +NAME="AEN203" ></A ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/dist/bind/bin/named/Makefile.in b/dist/bind/bin/named/Makefile.in index 8f8a0da0fac..a692399573a 100644 --- a/dist/bind/bin/named/Makefile.in +++ b/dist/bind/bin/named/Makefile.in @@ -13,7 +13,7 @@ # 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.7 2004/03/08 04:04:18 marka Exp +# Id: Makefile.in,v 1.74.12.10 2004/08/21 06:22:40 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -85,9 +85,9 @@ SRCS = aclconf.c builtin.c client.c config.c control.c \ lwdgnba.c lwdgrbn.c lwdnoop.c lwsearch.c \ $(DBDRIVER_SRCS) -MANPAGES = named.8 lwresd.8 +MANPAGES = named.8 lwresd.8 named.conf.5 -HTMLPAGES = named.html lwresd.html +HTMLPAGES = named.html lwresd.html named.conf.html MANOBJS = ${MANPAGES} ${HTMLPAGES} @@ -106,7 +106,7 @@ config.@O@: config.c -c ${srcdir}/config.c named@EXEEXT@: ${OBJS} ${UOBJS} ${DEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \ ${OBJS} ${UOBJS} ${LIBS} lwresd@EXEEXT@: named@EXEEXT@ @@ -126,6 +126,6 @@ installdirs: $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${mandir}/man8 install:: named@EXEEXT@ lwresd@EXEEXT@ installdirs - ${LIBTOO_MODE_INSTALL} ${INSTALL_PROGRAM} named@EXEEXT@ ${DESTDIR}${sbindir} + ${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/dist/bind/bin/named/client.c b/dist/bind/bin/named/client.c index 429f3d1724e..ffb32bec54b 100644 --- a/dist/bind/bin/named/client.c +++ b/dist/bind/bin/named/client.c @@ -1,4 +1,4 @@ -/* $NetBSD: client.c,v 1.1.1.1 2004/05/17 23:43:21 christos Exp $ */ +/* $NetBSD: client.c,v 1.1.1.2 2004/11/06 23:53:33 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: client.c,v 1.176.2.13.4.21 2004/04/29 01:31:21 marka Exp */ +/* Id: client.c,v 1.176.2.13.4.22 2004/07/23 02:56:51 marka Exp */ #include <config.h> @@ -244,13 +244,20 @@ exit_check(ns_client_t *client) { * - 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->newstate == NS_CLIENTSTATE_FREED && client->view != NULL) + 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) { @@ -545,6 +552,7 @@ ns_client_endrequest(ns_client_t *client) { INSIST(client->nreads == 0); INSIST(client->nsends == 0); INSIST(client->nrecvs == 0); + INSIST(client->nupdates == 0); INSIST(client->state == NS_CLIENTSTATE_WORKING); CTRACE("endrequest"); @@ -1673,6 +1681,7 @@ client_create(ns_clientmgr_t *manager, ns_client_t **clientp) client->nreads = 0; client->nsends = 0; client->nrecvs = 0; + client->nupdates = 0; client->nctls = 0; client->references = 0; client->attributes = 0; diff --git a/dist/bind/bin/named/config.c b/dist/bind/bin/named/config.c index a76db990fe0..c71acc7c44a 100644 --- a/dist/bind/bin/named/config.c +++ b/dist/bind/bin/named/config.c @@ -1,4 +1,4 @@ -/* $NetBSD: config.c,v 1.1.1.1 2004/05/17 23:43:21 christos Exp $ */ +/* $NetBSD: config.c,v 1.1.1.2 2004/11/06 23:53:33 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: config.c,v 1.11.2.4.8.27 2004/04/20 14:12:08 marka Exp */ +/* Id: config.c,v 1.11.2.4.8.28 2004/08/28 05:41:42 marka Exp */ #include <config.h> @@ -165,6 +165,7 @@ options {\n\ #\n\ view \"_bind\" chaos {\n\ recursion no;\n\ + notify no;\n\ \n\ zone \"version.bind\" chaos {\n\ type master;\n\ diff --git a/dist/bind/bin/named/control.c b/dist/bind/bin/named/control.c index a1dde547a36..653a4c001ae 100644 --- a/dist/bind/bin/named/control.c +++ b/dist/bind/bin/named/control.c @@ -1,4 +1,4 @@ -/* $NetBSD: control.c,v 1.1.1.1 2004/05/17 23:43:21 christos Exp $ */ +/* $NetBSD: control.c,v 1.1.1.2 2004/11/06 23:53:33 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: control.c,v 1.7.2.2.2.10 2004/03/22 01:52:22 marka Exp */ +/* Id: control.c,v 1.7.2.2.2.10.4.1 2004/09/20 01:00:00 marka Exp */ #include <config.h> @@ -124,7 +124,8 @@ ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text) { 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)) { + } else if (command_compare(command, NS_COMMAND_UNFREEZE) || + command_compare(command, NS_COMMAND_THAW)) { 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); diff --git a/dist/bind/bin/named/include/named/client.h b/dist/bind/bin/named/include/named/client.h index 5db40550e99..ef93eb5c184 100644 --- a/dist/bind/bin/named/include/named/client.h +++ b/dist/bind/bin/named/include/named/client.h @@ -1,4 +1,4 @@ -/* $NetBSD: client.h,v 1.1.1.1 2004/05/17 23:43:24 christos Exp $ */ +/* $NetBSD: client.h,v 1.1.1.2 2004/11/06 23:53:37 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: client.h,v 1.60.2.2.10.7 2004/03/08 04:04:20 marka Exp */ +/* 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 @@ -96,6 +96,7 @@ struct ns_client { int nreads; int nsends; int nrecvs; + int nupdates; int nctls; int references; unsigned int attributes; diff --git a/dist/bind/bin/named/include/named/control.h b/dist/bind/bin/named/include/named/control.h index a727f9f9390..b5207678c25 100644 --- a/dist/bind/bin/named/include/named/control.h +++ b/dist/bind/bin/named/include/named/control.h @@ -1,4 +1,4 @@ -/* $NetBSD: control.h,v 1.1.1.1 2004/05/17 23:43:24 christos Exp $ */ +/* $NetBSD: control.h,v 1.1.1.2 2004/11/06 23:53:37 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: control.h,v 1.6.2.2.2.6 2004/03/08 04:04:20 marka Exp */ +/* Id: control.h,v 1.6.2.2.2.6.6.1 2004/09/20 01:00:01 marka Exp */ #ifndef NAMED_CONTROL_H #define NAMED_CONTROL_H 1 @@ -49,6 +49,7 @@ #define NS_COMMAND_STATUS "status" #define NS_COMMAND_FREEZE "freeze" #define NS_COMMAND_UNFREEZE "unfreeze" +#define NS_COMMAND_THAW "thaw" #define NS_COMMAND_RECURSING "recursing" #define NS_COMMAND_NULL "null" diff --git a/dist/bind/bin/named/interfacemgr.c b/dist/bind/bin/named/interfacemgr.c index f8d15666c32..5f86adaeffa 100644 --- a/dist/bind/bin/named/interfacemgr.c +++ b/dist/bind/bin/named/interfacemgr.c @@ -1,4 +1,4 @@ -/* $NetBSD: interfacemgr.c,v 1.1.1.1 2004/05/17 23:43:22 christos Exp $ */ +/* $NetBSD: interfacemgr.c,v 1.1.1.2 2004/11/06 23:53:33 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: interfacemgr.c,v 1.59.2.5.8.14 2004/04/29 01:31:21 marka Exp */ +/* Id: interfacemgr.c,v 1.59.2.5.8.15 2004/08/10 04:56:23 jinmei Exp */ #include <config.h> @@ -361,7 +361,7 @@ ns_interface_setup(ns_interfacemgr_t *mgr, isc_sockaddr_t *addr, if (result != ISC_R_SUCCESS) { /* * XXXRTH We don't currently have a way to easily stop - * dispatch service, so we return currently return + * dispatch service, so we currently return * ISC_R_SUCCESS (the UDP stuff will work even if TCP * creation failed). This will be fixed later. */ @@ -596,8 +596,8 @@ do_scan(ns_interfacemgr_t *mgr, ns_listenlist_t *ext_listen, } if (scan_ipv6 == ISC_TRUE && ipv6only && ipv6pktinfo) { for (le = ISC_LIST_HEAD(mgr->listenon6->elts); - le != NULL; - le = ISC_LIST_NEXT(le, link)) { + le != NULL; + le = ISC_LIST_NEXT(le, link)) { struct in6_addr in6a; if (!listenon_is_ip6_any(le)) diff --git a/dist/bind/bin/named/lwresd.8 b/dist/bind/bin/named/lwresd.8 index 7eb9362b708..eac23d5d61f 100644 --- a/dist/bind/bin/named/lwresd.8 +++ b/dist/bind/bin/named/lwresd.8 @@ -1,4 +1,4 @@ -.\" $NetBSD: lwresd.8,v 1.1.1.1 2004/05/17 23:43:22 christos Exp $ +.\" $NetBSD: lwresd.8,v 1.1.1.2 2004/11/06 23:53:34 christos Exp $ .\" .\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000, 2001 Internet Software Consortium. @@ -15,7 +15,7 @@ .\" 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.1 2004/03/06 07:41:39 marka Exp +.\" 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 @@ -139,4 +139,4 @@ The default process-id file. \fBresolver\fR(5). .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/dist/bind/bin/named/lwresd.docbook b/dist/bind/bin/named/lwresd.docbook index bda84255f48..e266735ab9a 100644 --- a/dist/bind/bin/named/lwresd.docbook +++ b/dist/bind/bin/named/lwresd.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwresd.docbook,v 1.6.208.1 2004/03/06 10:21:20 marka Exp --> +<!-- Id: lwresd.docbook,v 1.6.208.2 2004/06/03 02:24:57 marka Exp --> <refentry> <refentryinfo> @@ -286,7 +286,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/dist/bind/bin/named/lwresd.html b/dist/bind/bin/named/lwresd.html index 415a82c3315..8d5c96f0087 100644 --- a/dist/bind/bin/named/lwresd.html +++ b/dist/bind/bin/named/lwresd.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwresd.html,v 1.4.2.1.4.1 2004/03/06 10:21:20 marka Exp --> +<!-- Id: lwresd.html,v 1.4.2.1.4.3 2004/08/22 23:38:59 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwresd</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,10 +35,10 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" +></A ><SPAN CLASS="APPLICATION" >lwresd</SPAN -></A ></H1 ><DIV CLASS="REFNAMEDIV" @@ -62,82 +62,66 @@ NAME="AEN13" ><B CLASS="COMMAND" >lwresd</B -> [<TT +> [<VAR CLASS="OPTION" ->-C <TT +>-C <VAR CLASS="REPLACEABLE" -><I ->config-file</I -></TT -></TT ->] [<TT +>config-file</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-d <TT +>-d <VAR CLASS="REPLACEABLE" -><I ->debug-level</I -></TT -></TT ->] [<TT +>debug-level</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-f</TT ->] [<TT +>-f</VAR +>] [<VAR CLASS="OPTION" ->-g</TT ->] [<TT +>-g</VAR +>] [<VAR CLASS="OPTION" ->-i <TT +>-i <VAR CLASS="REPLACEABLE" -><I ->pid-file</I -></TT -></TT ->] [<TT +>pid-file</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-n <TT +>-n <VAR CLASS="REPLACEABLE" -><I ->#cpus</I -></TT -></TT ->] [<TT +>#cpus</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-P <TT +>-P <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT -></TT ->] [<TT +>port</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-p <TT +>-p <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT -></TT ->] [<TT +>port</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-s</TT ->] [<TT +>-s</VAR +>] [<VAR CLASS="OPTION" ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT -></TT ->] [<TT +>directory</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-u <TT +>-u <VAR CLASS="REPLACEABLE" -><I ->user</I -></TT -></TT ->] [<TT +>user</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-v</TT +>-v</VAR >]</P ></DIV ><DIV @@ -186,18 +170,18 @@ CLASS="COMMAND" CLASS="FILENAME" >/etc/resolv.conf</TT > contains any - <TT + <VAR CLASS="OPTION" ->nameserver</TT +>nameserver</VAR > entries, <B CLASS="COMMAND" >lwresd</B > sends recursive DNS queries to those servers. This is similar to the use of forwarders in a caching name server. If no - <TT + <VAR CLASS="OPTION" ->nameserver</TT +>nameserver</VAR > entries are present, or if forwarding fails, <B CLASS="COMMAND" @@ -220,19 +204,15 @@ NAME="AEN63" CLASS="VARIABLELIST" ><DL ><DT ->-C <TT +>-C <VAR CLASS="REPLACEABLE" -><I ->config-file</I -></TT +>config-file</VAR ></DT ><DD ><P -> Use <TT +> Use <VAR CLASS="REPLACEABLE" -><I ->config-file</I -></TT +>config-file</VAR > as the configuration file instead of the default, <TT @@ -242,19 +222,15 @@ CLASS="FILENAME" </P ></DD ><DT ->-d <TT +>-d <VAR CLASS="REPLACEABLE" -><I ->debug-level</I -></TT +>debug-level</VAR ></DT ><DD ><P -> Set the daemon's debug level to <TT +> Set the daemon's debug level to <VAR CLASS="REPLACEABLE" -><I ->debug-level</I -></TT +>debug-level</VAR >. Debugging traces from <B CLASS="COMMAND" @@ -282,19 +258,15 @@ CLASS="FILENAME" </P ></DD ><DT ->-n <TT +>-n <VAR CLASS="REPLACEABLE" -><I ->#cpus</I -></TT +>#cpus</VAR ></DT ><DD ><P -> Create <TT +> Create <VAR CLASS="REPLACEABLE" -><I ->#cpus</I -></TT +>#cpus</VAR > worker threads to take advantage of multiple CPUs. If not specified, <B @@ -307,38 +279,30 @@ CLASS="COMMAND" </P ></DD ><DT ->-P <TT +>-P <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT +>port</VAR ></DT ><DD ><P > Listen for lightweight resolver queries on port - <TT + <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT +>port</VAR >. If not specified, the default is port 921. </P ></DD ><DT ->-p <TT +>-p <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT +>port</VAR ></DT ><DD ><P -> Send DNS lookups to port <TT +> Send DNS lookups to port <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT +>port</VAR >. If not specified, the default is port 53. This provides a way of testing the lightweight resolver daemon with a @@ -370,22 +334,18 @@ CLASS="NOTE" ></DIV ></DD ><DT ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT +>directory</VAR ></DT ><DD ><P -> <TT +> <CODE CLASS="FUNCTION" ->chroot()</TT -> to <TT +>chroot()</CODE +> to <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT +>directory</VAR > after processing the command line arguments, but before reading the configuration file. @@ -410,14 +370,14 @@ ALIGN="CENTER" ALIGN="LEFT" ><P > This option should be used in conjunction with the - <TT + <VAR CLASS="OPTION" ->-u</TT +>-u</VAR > option, as chrooting a process running as root doesn't enhance security on most - systems; the way <TT + systems; the way <CODE CLASS="FUNCTION" ->chroot()</TT +>chroot()</CODE > is defined allows a process with root privileges to escape a chroot jail. @@ -428,22 +388,18 @@ CLASS="FUNCTION" ></DIV ></DD ><DT ->-u <TT +>-u <VAR CLASS="REPLACEABLE" -><I ->user</I -></TT +>user</VAR ></DT ><DD ><P -> <TT +> <CODE CLASS="FUNCTION" ->setuid()</TT -> to <TT +>setuid()</CODE +> to <VAR CLASS="REPLACEABLE" -><I ->user</I -></TT +>user</VAR > after completing privileged operations, such as creating sockets that listen on privileged ports. @@ -533,7 +489,7 @@ NAME="AEN162" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/dist/bind/bin/named/named.8 b/dist/bind/bin/named/named.8 index 7b8251f2612..190e5f4f1d4 100644 --- a/dist/bind/bin/named/named.8 +++ b/dist/bind/bin/named/named.8 @@ -1,4 +1,4 @@ -.\" $NetBSD: named.8,v 1.1.1.1 2004/05/17 23:43:22 christos Exp $ +.\" $NetBSD: named.8,v 1.1.1.2 2004/11/06 23:53:34 christos Exp $ .\" .\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium. @@ -15,7 +15,7 @@ .\" 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.2 2004/03/06 07:41:39 marka Exp +.\" 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 @@ -176,4 +176,4 @@ The default process-id file. \fIBIND 9 Administrator Reference Manual\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/dist/bind/bin/named/named.conf.5 b/dist/bind/bin/named/named.conf.5 new file mode 100644 index 00000000000..243de65246e --- /dev/null +++ b/dist/bind/bin/named/named.conf.5 @@ -0,0 +1,476 @@ +.\" $NetBSD: named.conf.5,v 1.1.1.1 2004/11/06 23:53:34 christos Exp $ +.\" +.\" 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/dist/bind/bin/named/named.conf.docbook b/dist/bind/bin/named/named.conf.docbook new file mode 100644 index 00000000000..86f33546e66 --- /dev/null +++ b/dist/bind/bin/named/named.conf.docbook @@ -0,0 +1,532 @@ +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> +<!-- + - 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.docbook,v 1.1.4.1 2004/08/20 22:02:38 marka Exp --> + +<refentry> + <refentryinfo> + <date>Aug 13, 2004</date> + </refentryinfo> + + <refmeta> + <refentrytitle><filename>named.conf</filename></refentrytitle> + <manvolnum>5</manvolnum> + <refmiscinfo>BIND9</refmiscinfo> + </refmeta> + + <refnamediv> + <refname><filename>named.conf</filename></refname> + <refpurpose>configuration file for named</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>named.conf</command> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>DESCRIPTION</title> + <para> + <filename>named.conf</filename> is the configuration file for + <command>named</command>. 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: + </para> + <para> + C style: /* */ + </para> + <para> + C++ style: // to end of line + </para> + <para> + Unix style: # to end of line + </para> + </refsect1> + +<refsect1> +<title>ACL</title> +<LITERALLAYOUT> +acl <replaceable>string</replaceable> { <replaceable>address_match_element</replaceable>; ... }; + +</LITERALLAYOUT> +</refsect1> + +<refsect1> +<title>KEY</title> +<LITERALLAYOUT> +key <replaceable>domain_name</replaceable> { + algorithm <replaceable>string</replaceable>; + secret <replaceable>string</replaceable>; +}; +</LITERALLAYOUT> +</refsect1> + +<refsect1> +<title>MASTERS</title> +<LITERALLAYOUT> +masters <replaceable>string</replaceable> <optional> port <replaceable>integer</replaceable> </optional> { + ( <replaceable>masters</replaceable> | <replaceable>ipv4_address</replaceable> <optional>port <replaceable>integer</replaceable></optional> | + <replaceable>ipv6_address</replaceable> <optional>port <replaceable>integer</replaceable></optional> ) <optional> key <replaceable>string</replaceable> </optional>; ... +}; +</LITERALLAYOUT> +</refsect1> + +<refsect1> +<title>SERVER</title> +<LITERALLAYOUT> +server ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> ) { + bogus <replaceable>boolean</replaceable>; + edns <replaceable>boolean</replaceable>; + provide-ixfr <replaceable>boolean</replaceable>; + request-ixfr <replaceable>boolean</replaceable>; + keys <replaceable>server_key</replaceable>; + transfers <replaceable>integer</replaceable>; + transfer-format ( many-answers | one-answer ); + transfer-source ( <replaceable>ipv4_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + transfer-source-v6 ( <replaceable>ipv6_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + + support-ixfr <replaceable>boolean</replaceable>; // obsolete +}; +</LITERALLAYOUT> +</refsect1> + +<refsect1> +<title>TRUSTED-KEYS</title> +<LITERALLAYOUT> +trusted-keys { + <replaceable>domain_name</replaceable> <replaceable>flags</replaceable> <replaceable>protocol</replaceable> <replaceable>algorithm</replaceable> <replaceable>key</replaceable>; ... +}; +</LITERALLAYOUT> +</refsect1> + +<refsect1> +<title>CONTROLS</title> +<LITERALLAYOUT> +controls { + inet ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional> + allow { <replaceable>address_match_element</replaceable>; ... } + <optional> keys { <replaceable>string</replaceable>; ... } </optional>; + unix <replaceable>unsupported</replaceable>; // not implemented +}; +</LITERALLAYOUT> +</refsect1> + +<refsect1> +<title>LOGGING</title> +<LITERALLAYOUT> +logging { + channel <replaceable>string</replaceable> { + file <replaceable>log_file</replaceable>; + syslog <replaceable>optional_facility</replaceable>; + null; + stderr; + severity <replaceable>log_severity</replaceable>; + print-time <replaceable>boolean</replaceable>; + print-severity <replaceable>boolean</replaceable>; + print-category <replaceable>boolean</replaceable>; + }; + category <replaceable>string</replaceable> { <replaceable>string</replaceable>; ... }; +}; +</LITERALLAYOUT> +</refsect1> + +<refsect1> +<title>LWRES</title> +<LITERALLAYOUT> +lwres { + listen-on <optional> port <replaceable>integer</replaceable> </optional> { + ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> ) <optional> port <replaceable>integer</replaceable> </optional>; ... + }; + view <replaceable>string</replaceable> <replaceable>optional_class</replaceable>; + search { <replaceable>string</replaceable>; ... }; + ndots <replaceable>integer</replaceable>; +}; +</LITERALLAYOUT> +</refsect1> + +<refsect1> +<title>OPTIONS</title> +<LITERALLAYOUT> +options { + avoid-v4-udp-ports { <replaceable>port</replaceable>; ... }; + avoid-v6-udp-ports { <replaceable>port</replaceable>; ... }; + blackhole { <replaceable>address_match_element</replaceable>; ... }; + coresize <replaceable>size</replaceable>; + datasize <replaceable>size</replaceable>; + directory <replaceable>quoted_string</replaceable>; + dump-file <replaceable>quoted_string</replaceable>; + files <replaceable>size</replaceable>; + heartbeat-interval <replaceable>integer</replaceable>; + host-statistics <replaceable>boolean</replaceable>; // not implemented + hostname ( <replaceable>quoted_string</replaceable> | none ); + interface-interval <replaceable>integer</replaceable>; + listen-on <optional> port <replaceable>integer</replaceable> </optional> { <replaceable>address_match_element</replaceable>; ... }; + listen-on-v6 <optional> port <replaceable>integer</replaceable> </optional> { <replaceable>address_match_element</replaceable>; ... }; + match-mapped-addresses <replaceable>boolean</replaceable>; + memstatistics-file <replaceable>quoted_string</replaceable>; + pid-file ( <replaceable>quoted_string</replaceable> | none ); + port <replaceable>integer</replaceable>; + querylog <replaceable>boolean</replaceable>; + recursing-file <replaceable>quoted_string</replaceable>; + random-device <replaceable>quoted_string</replaceable>; + recursive-clients <replaceable>integer</replaceable>; + serial-query-rate <replaceable>integer</replaceable>; + server-id ( <replaceable>quoted_string</replaceable> | none |; + stacksize <replaceable>size</replaceable>; + statistics-file <replaceable>quoted_string</replaceable>; + statistics-interval <replaceable>integer</replaceable>; // not yet implemented + tcp-clients <replaceable>integer</replaceable>; + tcp-listen-queue <replaceable>integer</replaceable>; + tkey-dhkey <replaceable>quoted_string</replaceable> <replaceable>integer</replaceable>; + tkey-gssapi-credential <replaceable>quoted_string</replaceable>; + tkey-domain <replaceable>quoted_string</replaceable>; + transfers-per-ns <replaceable>integer</replaceable>; + transfers-in <replaceable>integer</replaceable>; + transfers-out <replaceable>integer</replaceable>; + use-ixfr <replaceable>boolean</replaceable>; + version ( <replaceable>quoted_string</replaceable> | none ); + allow-recursion { <replaceable>address_match_element</replaceable>; ... }; + sortlist { <replaceable>address_match_element</replaceable>; ... }; + topology { <replaceable>address_match_element</replaceable>; ... }; // not implemented + auth-nxdomain <replaceable>boolean</replaceable>; // default changed + minimal-responses <replaceable>boolean</replaceable>; + recursion <replaceable>boolean</replaceable>; + rrset-order { + <optional> class <replaceable>string</replaceable> </optional> <optional> type <replaceable>string</replaceable> </optional> + <optional> name <replaceable>quoted_string</replaceable> </optional> <replaceable>string</replaceable> <replaceable>string</replaceable>; ... + }; + provide-ixfr <replaceable>boolean</replaceable>; + request-ixfr <replaceable>boolean</replaceable>; + rfc2308-type1 <replaceable>boolean</replaceable>; // not yet implemented + additional-from-auth <replaceable>boolean</replaceable>; + additional-from-cache <replaceable>boolean</replaceable>; + query-source <replaceable>querysource4</replaceable>; + query-source-v6 <replaceable>querysource6</replaceable>; + cleaning-interval <replaceable>integer</replaceable>; + min-roots <replaceable>integer</replaceable>; // not implemented + lame-ttl <replaceable>integer</replaceable>; + max-ncache-ttl <replaceable>integer</replaceable>; + max-cache-ttl <replaceable>integer</replaceable>; + transfer-format ( many-answers | one-answer ); + max-cache-size <replaceable>size_no_default</replaceable>; + check-names ( master | slave | response ) + ( fail | warn | ignore ); + cache-file <replaceable>quoted_string</replaceable>; + suppress-initial-notify <replaceable>boolean</replaceable>; // not yet implemented + preferred-glue <replaceable>string</replaceable>; + dual-stack-servers <optional> port <replaceable>integer</replaceable> </optional> { + ( <replaceable>quoted_string</replaceable> <optional>port <replaceable>integer</replaceable></optional> | + <replaceable>ipv4_address</replaceable> <optional>port <replaceable>integer</replaceable></optional> | + <replaceable>ipv6_address</replaceable> <optional>port <replaceable>integer</replaceable></optional> ); ... + } + edns-udp-size <replaceable>integer</replaceable>; + root-delegation-only <optional> exclude { <replaceable>quoted_string</replaceable>; ... } </optional>; + disable-algorithms <replaceable>string</replaceable> { <replaceable>string</replaceable>; ... }; + dnssec-enable <replaceable>boolean</replaceable>; + dnssec-lookaside <replaceable>string</replaceable> trust-anchor <replaceable>string</replaceable>; + dnssec-must-be-secure <replaceable>string</replaceable> <replaceable>boolean</replaceable>; + + dialup <replaceable>dialuptype</replaceable>; + ixfr-from-differences <replaceable>ixfrdiff</replaceable>; + + allow-query { <replaceable>address_match_element</replaceable>; ... }; + allow-transfer { <replaceable>address_match_element</replaceable>; ... }; + allow-update-forwarding { <replaceable>address_match_element</replaceable>; ... }; + + notify <replaceable>notifytype</replaceable>; + notify-source ( <replaceable>ipv4_address</replaceable> | * ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + notify-source-v6 ( <replaceable>ipv6_address</replaceable> | * ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + also-notify <optional> port <replaceable>integer</replaceable> </optional> { ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> ) + <optional> port <replaceable>integer</replaceable> </optional>; ... }; + allow-notify { <replaceable>address_match_element</replaceable>; ... }; + + forward ( first | only ); + forwarders <optional> port <replaceable>integer</replaceable> </optional> { + ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> ) <optional> port <replaceable>integer</replaceable> </optional>; ... + }; + + max-journal-size <replaceable>size_no_default</replaceable>; + max-transfer-time-in <replaceable>integer</replaceable>; + max-transfer-time-out <replaceable>integer</replaceable>; + max-transfer-idle-in <replaceable>integer</replaceable>; + max-transfer-idle-out <replaceable>integer</replaceable>; + max-retry-time <replaceable>integer</replaceable>; + min-retry-time <replaceable>integer</replaceable>; + max-refresh-time <replaceable>integer</replaceable>; + min-refresh-time <replaceable>integer</replaceable>; + multi-master <replaceable>boolean</replaceable>; + sig-validity-interval <replaceable>integer</replaceable>; + + transfer-source ( <replaceable>ipv4_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + transfer-source-v6 ( <replaceable>ipv6_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + + alt-transfer-source ( <replaceable>ipv4_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + alt-transfer-source-v6 ( <replaceable>ipv6_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + use-alt-transfer-source <replaceable>boolean</replaceable>; + + zone-statistics <replaceable>boolean</replaceable>; + key-directory <replaceable>quoted_string</replaceable>; + + allow-v6-synthesis { <replaceable>address_match_element</replaceable>; ... }; // obsolete + deallocate-on-exit <replaceable>boolean</replaceable>; // obsolete + fake-iquery <replaceable>boolean</replaceable>; // obsolete + fetch-glue <replaceable>boolean</replaceable>; // obsolete + has-old-clients <replaceable>boolean</replaceable>; // obsolete + maintain-ixfr-base <replaceable>boolean</replaceable>; // obsolete + max-ixfr-log-size <replaceable>size</replaceable>; // obsolete + multiple-cnames <replaceable>boolean</replaceable>; // obsolete + named-xfer <replaceable>quoted_string</replaceable>; // obsolete + serial-queries <replaceable>integer</replaceable>; // obsolete + treat-cr-as-space <replaceable>boolean</replaceable>; // obsolete + use-id-pool <replaceable>boolean</replaceable>; // obsolete +}; +</LITERALLAYOUT> +</refsect1> + +<refsect1> +<title>VIEW</title> +<LITERALLAYOUT> +view <replaceable>string</replaceable> <replaceable>optional_class</replaceable> { + match-clients { <replaceable>address_match_element</replaceable>; ... }; + match-destinations { <replaceable>address_match_element</replaceable>; ... }; + match-recursive-only <replaceable>boolean</replaceable>; + + key <replaceable>string</replaceable> { + algorithm <replaceable>string</replaceable>; + secret <replaceable>string</replaceable>; + }; + + zone <replaceable>string</replaceable> <replaceable>optional_class</replaceable> { + ... + }; + + server ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> ) { + ... + }; + + trusted-keys { + <replaceable>string</replaceable> <replaceable>integer</replaceable> <replaceable>integer</replaceable> <replaceable>integer</replaceable> <replaceable>quoted_string</replaceable>; ... + }; + + allow-recursion { <replaceable>address_match_element</replaceable>; ... }; + sortlist { <replaceable>address_match_element</replaceable>; ... }; + topology { <replaceable>address_match_element</replaceable>; ... }; // not implemented + auth-nxdomain <replaceable>boolean</replaceable>; // default changed + minimal-responses <replaceable>boolean</replaceable>; + recursion <replaceable>boolean</replaceable>; + rrset-order { + <optional> class <replaceable>string</replaceable> </optional> <optional> type <replaceable>string</replaceable> </optional> + <optional> name <replaceable>quoted_string</replaceable> </optional> <replaceable>string</replaceable> <replaceable>string</replaceable>; ... + }; + provide-ixfr <replaceable>boolean</replaceable>; + request-ixfr <replaceable>boolean</replaceable>; + rfc2308-type1 <replaceable>boolean</replaceable>; // not yet implemented + additional-from-auth <replaceable>boolean</replaceable>; + additional-from-cache <replaceable>boolean</replaceable>; + query-source <replaceable>querysource4</replaceable>; + query-source-v6 <replaceable>querysource6</replaceable>; + cleaning-interval <replaceable>integer</replaceable>; + min-roots <replaceable>integer</replaceable>; // not implemented + lame-ttl <replaceable>integer</replaceable>; + max-ncache-ttl <replaceable>integer</replaceable>; + max-cache-ttl <replaceable>integer</replaceable>; + transfer-format ( many-answers | one-answer ); + max-cache-size <replaceable>size_no_default</replaceable>; + check-names ( master | slave | response ) + ( fail | warn | ignore ); + cache-file <replaceable>quoted_string</replaceable>; + suppress-initial-notify <replaceable>boolean</replaceable>; // not yet implemented + preferred-glue <replaceable>string</replaceable>; + dual-stack-servers <optional> port <replaceable>integer</replaceable> </optional> { + ( <replaceable>quoted_string</replaceable> <optional>port <replaceable>integer</replaceable></optional> | + <replaceable>ipv4_address</replaceable> <optional>port <replaceable>integer</replaceable></optional> | + <replaceable>ipv6_address</replaceable> <optional>port <replaceable>integer</replaceable></optional> ); ... + }; + edns-udp-size <replaceable>integer</replaceable>; + root-delegation-only <optional> exclude { <replaceable>quoted_string</replaceable>; ... } </optional>; + disable-algorithms <replaceable>string</replaceable> { <replaceable>string</replaceable>; ... }; + dnssec-enable <replaceable>boolean</replaceable>; + dnssec-lookaside <replaceable>string</replaceable> trust-anchor <replaceable>string</replaceable>; + + dnssec-must-be-secure <replaceable>string</replaceable> <replaceable>boolean</replaceable>; + dialup <replaceable>dialuptype</replaceable>; + ixfr-from-differences <replaceable>ixfrdiff</replaceable>; + + allow-query { <replaceable>address_match_element</replaceable>; ... }; + allow-transfer { <replaceable>address_match_element</replaceable>; ... }; + allow-update-forwarding { <replaceable>address_match_element</replaceable>; ... }; + + notify <replaceable>notifytype</replaceable>; + notify-source ( <replaceable>ipv4_address</replaceable> | * ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + notify-source-v6 ( <replaceable>ipv6_address</replaceable> | * ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + also-notify <optional> port <replaceable>integer</replaceable> </optional> { ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> ) + <optional> port <replaceable>integer</replaceable> </optional>; ... }; + allow-notify { <replaceable>address_match_element</replaceable>; ... }; + + forward ( first | only ); + forwarders <optional> port <replaceable>integer</replaceable> </optional> { + ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> ) <optional> port <replaceable>integer</replaceable> </optional>; ... + }; + + max-journal-size <replaceable>size_no_default</replaceable>; + max-transfer-time-in <replaceable>integer</replaceable>; + max-transfer-time-out <replaceable>integer</replaceable>; + max-transfer-idle-in <replaceable>integer</replaceable>; + max-transfer-idle-out <replaceable>integer</replaceable>; + max-retry-time <replaceable>integer</replaceable>; + min-retry-time <replaceable>integer</replaceable>; + max-refresh-time <replaceable>integer</replaceable>; + min-refresh-time <replaceable>integer</replaceable>; + multi-master <replaceable>boolean</replaceable>; + sig-validity-interval <replaceable>integer</replaceable>; + + transfer-source ( <replaceable>ipv4_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + transfer-source-v6 ( <replaceable>ipv6_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + + alt-transfer-source ( <replaceable>ipv4_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + alt-transfer-source-v6 ( <replaceable>ipv6_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + use-alt-transfer-source <replaceable>boolean</replaceable>; + + zone-statistics <replaceable>boolean</replaceable>; + key-directory <replaceable>quoted_string</replaceable>; + + allow-v6-synthesis { <replaceable>address_match_element</replaceable>; ... }; // obsolete + fetch-glue <replaceable>boolean</replaceable>; // obsolete + maintain-ixfr-base <replaceable>boolean</replaceable>; // obsolete + max-ixfr-log-size <replaceable>size</replaceable>; // obsolete +}; +</LITERALLAYOUT> +</refsect1> + +<refsect1> +<title>ZONE</title> +<LITERALLAYOUT> +zone <replaceable>string</replaceable> <replaceable>optional_class</replaceable> { + type ( master | slave | stub | hint | + forward | delegation-only ); + file <replaceable>quoted_string</replaceable>; + + masters <optional> port <replaceable>integer</replaceable> </optional> { + ( <replaceable>masters</replaceable> | + <replaceable>ipv4_address</replaceable> <optional>port <replaceable>integer</replaceable></optional> | + <replaceable>ipv6_address</replaceable> <optional> port <replaceable>integer</replaceable> </optional> ) <optional> key <replaceable>string</replaceable> </optional>; ... + }; + + database <replaceable>string</replaceable>; + delegation-only <replaceable>boolean</replaceable>; + check-names ( fail | warn | ignore ); + dialup <replaceable>dialuptype</replaceable>; + ixfr-from-differences <replaceable>boolean</replaceable>; + + allow-query { <replaceable>address_match_element</replaceable>; ... }; + allow-transfer { <replaceable>address_match_element</replaceable>; ... }; + allow-update { <replaceable>address_match_element</replaceable>; ... }; + allow-update-forwarding { <replaceable>address_match_element</replaceable>; ... }; + update-policy { + ( grant | deny ) <replaceable>string</replaceable> + ( name | subdomain | wildcard | self ) <replaceable>string</replaceable> + <replaceable>rrtypelist</replaceable>; ... + }; + + notify <replaceable>notifytype</replaceable>; + notify-source ( <replaceable>ipv4_address</replaceable> | * ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + notify-source-v6 ( <replaceable>ipv6_address</replaceable> | * ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + also-notify <optional> port <replaceable>integer</replaceable> </optional> { ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> ) + <optional> port <replaceable>integer</replaceable> </optional>; ... }; + allow-notify { <replaceable>address_match_element</replaceable>; ... }; + + forward ( first | only ); + forwarders <optional> port <replaceable>integer</replaceable> </optional> { + ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> ) <optional> port <replaceable>integer</replaceable> </optional>; ... + }; + + max-journal-size <replaceable>size_no_default</replaceable>; + max-transfer-time-in <replaceable>integer</replaceable>; + max-transfer-time-out <replaceable>integer</replaceable>; + max-transfer-idle-in <replaceable>integer</replaceable>; + max-transfer-idle-out <replaceable>integer</replaceable>; + max-retry-time <replaceable>integer</replaceable>; + min-retry-time <replaceable>integer</replaceable>; + max-refresh-time <replaceable>integer</replaceable>; + min-refresh-time <replaceable>integer</replaceable>; + multi-master <replaceable>boolean</replaceable>; + sig-validity-interval <replaceable>integer</replaceable>; + + transfer-source ( <replaceable>ipv4_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + transfer-source-v6 ( <replaceable>ipv6_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + + alt-transfer-source ( <replaceable>ipv4_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + alt-transfer-source-v6 ( <replaceable>ipv6_address</replaceable> | * ) + <optional> port ( <replaceable>integer</replaceable> | * ) </optional>; + use-alt-transfer-source <replaceable>boolean</replaceable>; + + zone-statistics <replaceable>boolean</replaceable>; + key-directory <replaceable>quoted_string</replaceable>; + + ixfr-base <replaceable>quoted_string</replaceable>; // obsolete + ixfr-tmp-file <replaceable>quoted_string</replaceable>; // obsolete + maintain-ixfr-base <replaceable>boolean</replaceable>; // obsolete + max-ixfr-log-size <replaceable>size</replaceable>; // obsolete + pubkey <replaceable>integer</replaceable> <replaceable>integer</replaceable> <replaceable>integer</replaceable> <replaceable>quoted_string</replaceable>; // obsolete +}; +</LITERALLAYOUT> +</refsect1> + +<refsect1> +<title>FILES</title> +<para> +<filename>/etc/named.conf</filename> +</para> +</refsect1> + +<refsect1> +<title>SEE ALSO</title> +<para> +<citerefentry> +<refentrytitle>named</refentrytitle><manvolnum>8</manvolnum> +</citerefentry>, +<citerefentry> +<refentrytitle>rndc</refentrytitle><manvolnum>8</manvolnum> +</citerefentry>, +<citerefentry> +<refentrytitle>BIND 9 Adminstrators Reference Manual</refentrytitle> +</citerefentry>. +</para> +</refsect1> + +</refentry> +<!-- + - Local variables: + - mode: sgml + - End: +--> diff --git a/dist/bind/bin/named/named.conf.html b/dist/bind/bin/named/named.conf.html new file mode 100644 index 00000000000..12d923b4b16 --- /dev/null +++ b/dist/bind/bin/named/named.conf.html @@ -0,0 +1,1893 @@ +<!-- + - 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.html,v 1.1.4.3 2004/08/22 23:38:59 marka Exp --> + +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<HTML +><HEAD +><TITLE +>named.conf</TITLE +><META +NAME="GENERATOR" +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD +><BODY +CLASS="REFENTRY" +BGCOLOR="#FFFFFF" +TEXT="#000000" +LINK="#0000FF" +VLINK="#840084" +ALINK="#0000FF" +><H1 +><A +NAME="AEN1" +></A +><TT +CLASS="FILENAME" +>named.conf</TT +></H1 +><DIV +CLASS="REFNAMEDIV" +><A +NAME="AEN9" +></A +><H2 +>Name</H2 +><TT +CLASS="FILENAME" +>named.conf</TT +> -- configuration file for named</DIV +><DIV +CLASS="REFSYNOPSISDIV" +><A +NAME="AEN13" +></A +><H2 +>Synopsis</H2 +><P +><B +CLASS="COMMAND" +>named.conf</B +> </P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN16" +></A +><H2 +>DESCRIPTION</H2 +><P +> <TT +CLASS="FILENAME" +>named.conf</TT +> is the configuration file for + <B +CLASS="COMMAND" +>named</B +>. 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: + </P +><P +> C style: /* */ + </P +><P +> C++ style: // to end of line + </P +><P +> Unix style: # to end of line + </P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN24" +></A +><H2 +>ACL</H2 +><P +CLASS="LITERALLAYOUT" +>acl <VAR +CLASS="REPLACEABLE" +>string</VAR +> { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> </P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN29" +></A +><H2 +>KEY</H2 +><P +CLASS="LITERALLAYOUT" +>key <VAR +CLASS="REPLACEABLE" +>domain_name</VAR +> {<br> + algorithm <VAR +CLASS="REPLACEABLE" +>string</VAR +>;<br> + secret <VAR +CLASS="REPLACEABLE" +>string</VAR +>;<br> +};</P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN35" +></A +><H2 +>MASTERS</H2 +><P +CLASS="LITERALLAYOUT" +>masters <VAR +CLASS="REPLACEABLE" +>string</VAR +> [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] {<br> + ( <VAR +CLASS="REPLACEABLE" +>masters</VAR +> | <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> [<SPAN +CLASS="OPTIONAL" +>port <VAR +CLASS="REPLACEABLE" +>integer</VAR +></SPAN +>] |<br> + <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> [<SPAN +CLASS="OPTIONAL" +>port <VAR +CLASS="REPLACEABLE" +>integer</VAR +></SPAN +>] ) [<SPAN +CLASS="OPTIONAL" +> key <VAR +CLASS="REPLACEABLE" +>string</VAR +> </SPAN +>]; ...<br> +};</P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN50" +></A +><H2 +>SERVER</H2 +><P +CLASS="LITERALLAYOUT" +>server ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> ) {<br> + bogus <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + edns <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + provide-ixfr <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + request-ixfr <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + keys <VAR +CLASS="REPLACEABLE" +>server_key</VAR +>;<br> + transfers <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + transfer-format ( many-answers | one-answer );<br> + transfer-source ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + transfer-source-v6 ( <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> +<br> + support-ixfr <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // obsolete<br> +};</P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN68" +></A +><H2 +>TRUSTED-KEYS</H2 +><P +CLASS="LITERALLAYOUT" +>trusted-keys {<br> + <VAR +CLASS="REPLACEABLE" +>domain_name</VAR +> <VAR +CLASS="REPLACEABLE" +>flags</VAR +> <VAR +CLASS="REPLACEABLE" +>protocol</VAR +> <VAR +CLASS="REPLACEABLE" +>algorithm</VAR +> <VAR +CLASS="REPLACEABLE" +>key</VAR +>; ... <br> +};</P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN76" +></A +><H2 +>CONTROLS</H2 +><P +CLASS="LITERALLAYOUT" +>controls {<br> + inet ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>]<br> + allow { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... }<br> + [<SPAN +CLASS="OPTIONAL" +> keys { <VAR +CLASS="REPLACEABLE" +>string</VAR +>; ... } </SPAN +>];<br> + unix <VAR +CLASS="REPLACEABLE" +>unsupported</VAR +>; // not implemented<br> +};</P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN87" +></A +><H2 +>LOGGING</H2 +><P +CLASS="LITERALLAYOUT" +>logging {<br> + channel <VAR +CLASS="REPLACEABLE" +>string</VAR +> {<br> + file <VAR +CLASS="REPLACEABLE" +>log_file</VAR +>;<br> + syslog <VAR +CLASS="REPLACEABLE" +>optional_facility</VAR +>;<br> + null;<br> + stderr;<br> + severity <VAR +CLASS="REPLACEABLE" +>log_severity</VAR +>;<br> + print-time <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + print-severity <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + print-category <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + };<br> + category <VAR +CLASS="REPLACEABLE" +>string</VAR +> { <VAR +CLASS="REPLACEABLE" +>string</VAR +>; ... };<br> +};</P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN99" +></A +><H2 +>LWRES</H2 +><P +CLASS="LITERALLAYOUT" +>lwres {<br> + listen-on [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] {<br> + ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> ) [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>]; ...<br> + };<br> + view <VAR +CLASS="REPLACEABLE" +>string</VAR +> <VAR +CLASS="REPLACEABLE" +>optional_class</VAR +>;<br> + search { <VAR +CLASS="REPLACEABLE" +>string</VAR +>; ... };<br> + ndots <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> +};</P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN112" +></A +><H2 +>OPTIONS</H2 +><P +CLASS="LITERALLAYOUT" +>options {<br> + avoid-v4-udp-ports { <VAR +CLASS="REPLACEABLE" +>port</VAR +>; ... };<br> + avoid-v6-udp-ports { <VAR +CLASS="REPLACEABLE" +>port</VAR +>; ... };<br> + blackhole { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + coresize <VAR +CLASS="REPLACEABLE" +>size</VAR +>;<br> + datasize <VAR +CLASS="REPLACEABLE" +>size</VAR +>;<br> + directory <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> + dump-file <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> + files <VAR +CLASS="REPLACEABLE" +>size</VAR +>;<br> + heartbeat-interval <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + host-statistics <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // not implemented<br> + hostname ( <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +> | none );<br> + interface-interval <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + listen-on [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + listen-on-v6 [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + match-mapped-addresses <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + memstatistics-file <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> + pid-file ( <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +> | none );<br> + port <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + querylog <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + recursing-file <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> + random-device <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> + recursive-clients <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + serial-query-rate <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + server-id ( <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +> | none |;<br> + stacksize <VAR +CLASS="REPLACEABLE" +>size</VAR +>;<br> + statistics-file <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> + statistics-interval <VAR +CLASS="REPLACEABLE" +>integer</VAR +>; // not yet implemented<br> + tcp-clients <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + tcp-listen-queue <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + tkey-dhkey <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +> <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + tkey-gssapi-credential <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> + tkey-domain <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> + transfers-per-ns <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + transfers-in <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + transfers-out <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + use-ixfr <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + version ( <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +> | none );<br> + allow-recursion { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + sortlist { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + topology { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... }; // not implemented<br> + auth-nxdomain <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // default changed<br> + minimal-responses <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + recursion <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + rrset-order {<br> + [<SPAN +CLASS="OPTIONAL" +> class <VAR +CLASS="REPLACEABLE" +>string</VAR +> </SPAN +>] [<SPAN +CLASS="OPTIONAL" +> type <VAR +CLASS="REPLACEABLE" +>string</VAR +> </SPAN +>]<br> + [<SPAN +CLASS="OPTIONAL" +> name <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +> </SPAN +>] <VAR +CLASS="REPLACEABLE" +>string</VAR +> <VAR +CLASS="REPLACEABLE" +>string</VAR +>; ...<br> + };<br> + provide-ixfr <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + request-ixfr <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + rfc2308-type1 <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // not yet implemented<br> + additional-from-auth <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + additional-from-cache <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + query-source <VAR +CLASS="REPLACEABLE" +>querysource4</VAR +>;<br> + query-source-v6 <VAR +CLASS="REPLACEABLE" +>querysource6</VAR +>;<br> + cleaning-interval <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + min-roots <VAR +CLASS="REPLACEABLE" +>integer</VAR +>; // not implemented<br> + lame-ttl <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-ncache-ttl <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-cache-ttl <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + transfer-format ( many-answers | one-answer );<br> + max-cache-size <VAR +CLASS="REPLACEABLE" +>size_no_default</VAR +>;<br> + check-names ( master | slave | response )<br> + ( fail | warn | ignore );<br> + cache-file <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> + suppress-initial-notify <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // not yet implemented<br> + preferred-glue <VAR +CLASS="REPLACEABLE" +>string</VAR +>;<br> + dual-stack-servers [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] {<br> + ( <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +> [<SPAN +CLASS="OPTIONAL" +>port <VAR +CLASS="REPLACEABLE" +>integer</VAR +></SPAN +>] |<br> + <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> [<SPAN +CLASS="OPTIONAL" +>port <VAR +CLASS="REPLACEABLE" +>integer</VAR +></SPAN +>] |<br> + <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> [<SPAN +CLASS="OPTIONAL" +>port <VAR +CLASS="REPLACEABLE" +>integer</VAR +></SPAN +>] ); ...<br> + }<br> + edns-udp-size <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + root-delegation-only [<SPAN +CLASS="OPTIONAL" +> exclude { <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>; ... } </SPAN +>];<br> + disable-algorithms <VAR +CLASS="REPLACEABLE" +>string</VAR +> { <VAR +CLASS="REPLACEABLE" +>string</VAR +>; ... };<br> + dnssec-enable <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + dnssec-lookaside <VAR +CLASS="REPLACEABLE" +>string</VAR +> trust-anchor <VAR +CLASS="REPLACEABLE" +>string</VAR +>;<br> + dnssec-must-be-secure <VAR +CLASS="REPLACEABLE" +>string</VAR +> <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> +<br> + dialup <VAR +CLASS="REPLACEABLE" +>dialuptype</VAR +>;<br> + ixfr-from-differences <VAR +CLASS="REPLACEABLE" +>ixfrdiff</VAR +>;<br> +<br> + allow-query { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + allow-transfer { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + allow-update-forwarding { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> +<br> + notify <VAR +CLASS="REPLACEABLE" +>notifytype</VAR +>;<br> + notify-source ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | * ) [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + notify-source-v6 ( <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> | * ) [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + also-notify [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] { ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> )<br> + [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>]; ... };<br> + allow-notify { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> +<br> + forward ( first | only );<br> + forwarders [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] {<br> + ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> ) [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>]; ...<br> + };<br> +<br> + max-journal-size <VAR +CLASS="REPLACEABLE" +>size_no_default</VAR +>;<br> + max-transfer-time-in <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-transfer-time-out <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-transfer-idle-in <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-transfer-idle-out <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-retry-time <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + min-retry-time <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-refresh-time <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + min-refresh-time <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + multi-master <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + sig-validity-interval <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> +<br> + transfer-source ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + transfer-source-v6 ( <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> +<br> + alt-transfer-source ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + alt-transfer-source-v6 ( <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + use-alt-transfer-source <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> +<br> + zone-statistics <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + key-directory <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> +<br> + allow-v6-synthesis { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... }; // obsolete<br> + deallocate-on-exit <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // obsolete<br> + fake-iquery <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // obsolete<br> + fetch-glue <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // obsolete<br> + has-old-clients <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // obsolete<br> + maintain-ixfr-base <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // obsolete<br> + max-ixfr-log-size <VAR +CLASS="REPLACEABLE" +>size</VAR +>; // obsolete<br> + multiple-cnames <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // obsolete<br> + named-xfer <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>; // obsolete<br> + serial-queries <VAR +CLASS="REPLACEABLE" +>integer</VAR +>; // obsolete<br> + treat-cr-as-space <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // obsolete<br> + use-id-pool <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // obsolete<br> +};</P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN271" +></A +><H2 +>VIEW</H2 +><P +CLASS="LITERALLAYOUT" +>view <VAR +CLASS="REPLACEABLE" +>string</VAR +> <VAR +CLASS="REPLACEABLE" +>optional_class</VAR +> {<br> + match-clients { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + match-destinations { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + match-recursive-only <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> +<br> + key <VAR +CLASS="REPLACEABLE" +>string</VAR +> {<br> + algorithm <VAR +CLASS="REPLACEABLE" +>string</VAR +>;<br> + secret <VAR +CLASS="REPLACEABLE" +>string</VAR +>;<br> + };<br> +<br> + zone <VAR +CLASS="REPLACEABLE" +>string</VAR +> <VAR +CLASS="REPLACEABLE" +>optional_class</VAR +> {<br> + ...<br> + };<br> +<br> + server ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> ) {<br> + ...<br> + };<br> +<br> + trusted-keys {<br> + <VAR +CLASS="REPLACEABLE" +>string</VAR +> <VAR +CLASS="REPLACEABLE" +>integer</VAR +> <VAR +CLASS="REPLACEABLE" +>integer</VAR +> <VAR +CLASS="REPLACEABLE" +>integer</VAR +> <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>; ...<br> + };<br> +<br> + allow-recursion { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + sortlist { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + topology { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... }; // not implemented<br> + auth-nxdomain <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // default changed<br> + minimal-responses <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + recursion <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + rrset-order {<br> + [<SPAN +CLASS="OPTIONAL" +> class <VAR +CLASS="REPLACEABLE" +>string</VAR +> </SPAN +>] [<SPAN +CLASS="OPTIONAL" +> type <VAR +CLASS="REPLACEABLE" +>string</VAR +> </SPAN +>]<br> + [<SPAN +CLASS="OPTIONAL" +> name <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +> </SPAN +>] <VAR +CLASS="REPLACEABLE" +>string</VAR +> <VAR +CLASS="REPLACEABLE" +>string</VAR +>; ...<br> + };<br> + provide-ixfr <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + request-ixfr <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + rfc2308-type1 <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // not yet implemented<br> + additional-from-auth <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + additional-from-cache <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + query-source <VAR +CLASS="REPLACEABLE" +>querysource4</VAR +>;<br> + query-source-v6 <VAR +CLASS="REPLACEABLE" +>querysource6</VAR +>;<br> + cleaning-interval <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + min-roots <VAR +CLASS="REPLACEABLE" +>integer</VAR +>; // not implemented<br> + lame-ttl <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-ncache-ttl <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-cache-ttl <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + transfer-format ( many-answers | one-answer );<br> + max-cache-size <VAR +CLASS="REPLACEABLE" +>size_no_default</VAR +>;<br> + check-names ( master | slave | response )<br> + ( fail | warn | ignore );<br> + cache-file <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> + suppress-initial-notify <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // not yet implemented<br> + preferred-glue <VAR +CLASS="REPLACEABLE" +>string</VAR +>;<br> + dual-stack-servers [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] {<br> + ( <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +> [<SPAN +CLASS="OPTIONAL" +>port <VAR +CLASS="REPLACEABLE" +>integer</VAR +></SPAN +>] |<br> + <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> [<SPAN +CLASS="OPTIONAL" +>port <VAR +CLASS="REPLACEABLE" +>integer</VAR +></SPAN +>] |<br> + <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> [<SPAN +CLASS="OPTIONAL" +>port <VAR +CLASS="REPLACEABLE" +>integer</VAR +></SPAN +>] ); ...<br> + };<br> + edns-udp-size <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + root-delegation-only [<SPAN +CLASS="OPTIONAL" +> exclude { <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>; ... } </SPAN +>];<br> + disable-algorithms <VAR +CLASS="REPLACEABLE" +>string</VAR +> { <VAR +CLASS="REPLACEABLE" +>string</VAR +>; ... };<br> + dnssec-enable <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + dnssec-lookaside <VAR +CLASS="REPLACEABLE" +>string</VAR +> trust-anchor <VAR +CLASS="REPLACEABLE" +>string</VAR +>;<br> +<br> + dnssec-must-be-secure <VAR +CLASS="REPLACEABLE" +>string</VAR +> <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + dialup <VAR +CLASS="REPLACEABLE" +>dialuptype</VAR +>;<br> + ixfr-from-differences <VAR +CLASS="REPLACEABLE" +>ixfrdiff</VAR +>;<br> +<br> + allow-query { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + allow-transfer { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + allow-update-forwarding { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> +<br> + notify <VAR +CLASS="REPLACEABLE" +>notifytype</VAR +>;<br> + notify-source ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | * ) [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + notify-source-v6 ( <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> | * ) [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + also-notify [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] { ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> )<br> + [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>]; ... };<br> + allow-notify { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> +<br> + forward ( first | only );<br> + forwarders [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] {<br> + ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> ) [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>]; ...<br> + };<br> +<br> + max-journal-size <VAR +CLASS="REPLACEABLE" +>size_no_default</VAR +>;<br> + max-transfer-time-in <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-transfer-time-out <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-transfer-idle-in <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-transfer-idle-out <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-retry-time <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + min-retry-time <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-refresh-time <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + min-refresh-time <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + multi-master <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + sig-validity-interval <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> +<br> + transfer-source ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + transfer-source-v6 ( <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> +<br> + alt-transfer-source ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + alt-transfer-source-v6 ( <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + use-alt-transfer-source <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> +<br> + zone-statistics <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + key-directory <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> +<br> + allow-v6-synthesis { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... }; // obsolete<br> + fetch-glue <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // obsolete<br> + maintain-ixfr-base <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // obsolete<br> + max-ixfr-log-size <VAR +CLASS="REPLACEABLE" +>size</VAR +>; // obsolete<br> +};</P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN397" +></A +><H2 +>ZONE</H2 +><P +CLASS="LITERALLAYOUT" +>zone <VAR +CLASS="REPLACEABLE" +>string</VAR +> <VAR +CLASS="REPLACEABLE" +>optional_class</VAR +> {<br> + type ( master | slave | stub | hint |<br> + forward | delegation-only );<br> + file <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> +<br> + masters [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] {<br> + ( <VAR +CLASS="REPLACEABLE" +>masters</VAR +> |<br> + <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> [<SPAN +CLASS="OPTIONAL" +>port <VAR +CLASS="REPLACEABLE" +>integer</VAR +></SPAN +>] |<br> + <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] ) [<SPAN +CLASS="OPTIONAL" +> key <VAR +CLASS="REPLACEABLE" +>string</VAR +> </SPAN +>]; ...<br> + };<br> +<br> + database <VAR +CLASS="REPLACEABLE" +>string</VAR +>;<br> + delegation-only <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + check-names ( fail | warn | ignore );<br> + dialup <VAR +CLASS="REPLACEABLE" +>dialuptype</VAR +>;<br> + ixfr-from-differences <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> +<br> + allow-query { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + allow-transfer { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + allow-update { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + allow-update-forwarding { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> + update-policy {<br> + ( grant | deny ) <VAR +CLASS="REPLACEABLE" +>string</VAR +><br> + ( name | subdomain | wildcard | self ) <VAR +CLASS="REPLACEABLE" +>string</VAR +><br> + <VAR +CLASS="REPLACEABLE" +>rrtypelist</VAR +>; ...<br> + };<br> +<br> + notify <VAR +CLASS="REPLACEABLE" +>notifytype</VAR +>;<br> + notify-source ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | * ) [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + notify-source-v6 ( <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> | * ) [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + also-notify [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] { ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> )<br> + [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>]; ... };<br> + allow-notify { <VAR +CLASS="REPLACEABLE" +>address_match_element</VAR +>; ... };<br> +<br> + forward ( first | only );<br> + forwarders [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>] {<br> + ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> ) [<SPAN +CLASS="OPTIONAL" +> port <VAR +CLASS="REPLACEABLE" +>integer</VAR +> </SPAN +>]; ...<br> + };<br> +<br> + max-journal-size <VAR +CLASS="REPLACEABLE" +>size_no_default</VAR +>;<br> + max-transfer-time-in <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-transfer-time-out <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-transfer-idle-in <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-transfer-idle-out <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-retry-time <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + min-retry-time <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + max-refresh-time <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + min-refresh-time <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> + multi-master <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + sig-validity-interval <VAR +CLASS="REPLACEABLE" +>integer</VAR +>;<br> +<br> + transfer-source ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + transfer-source-v6 ( <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> +<br> + alt-transfer-source ( <VAR +CLASS="REPLACEABLE" +>ipv4_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + alt-transfer-source-v6 ( <VAR +CLASS="REPLACEABLE" +>ipv6_address</VAR +> | * )<br> + [<SPAN +CLASS="OPTIONAL" +> port ( <VAR +CLASS="REPLACEABLE" +>integer</VAR +> | * ) </SPAN +>];<br> + use-alt-transfer-source <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> +<br> + zone-statistics <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>;<br> + key-directory <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>;<br> +<br> + ixfr-base <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>; // obsolete<br> + ixfr-tmp-file <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>; // obsolete<br> + maintain-ixfr-base <VAR +CLASS="REPLACEABLE" +>boolean</VAR +>; // obsolete<br> + max-ixfr-log-size <VAR +CLASS="REPLACEABLE" +>size</VAR +>; // obsolete<br> + pubkey <VAR +CLASS="REPLACEABLE" +>integer</VAR +> <VAR +CLASS="REPLACEABLE" +>integer</VAR +> <VAR +CLASS="REPLACEABLE" +>integer</VAR +> <VAR +CLASS="REPLACEABLE" +>quoted_string</VAR +>; // obsolete<br> +};</P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN479" +></A +><H2 +>FILES</H2 +><P +><TT +CLASS="FILENAME" +>/etc/named.conf</TT +></P +></DIV +><DIV +CLASS="REFSECT1" +><A +NAME="AEN483" +></A +><H2 +>SEE ALSO</H2 +><P +><SPAN +CLASS="CITEREFENTRY" +><SPAN +CLASS="REFENTRYTITLE" +>named</SPAN +>(8)</SPAN +>, +<SPAN +CLASS="CITEREFENTRY" +><SPAN +CLASS="REFENTRYTITLE" +>rndc</SPAN +>(8)</SPAN +>, +<SPAN +CLASS="CITEREFENTRY" +><SPAN +CLASS="REFENTRYTITLE" +>BIND 9 Adminstrators Reference Manual</SPAN +></SPAN +>.</P +></DIV +></BODY +></HTML +> diff --git a/dist/bind/bin/named/named.docbook b/dist/bind/bin/named/named.docbook index 06bbfda723e..9eab3152629 100644 --- a/dist/bind/bin/named/named.docbook +++ b/dist/bind/bin/named/named.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: named.docbook,v 1.5.98.2 2004/03/06 10:21:20 marka Exp --> +<!-- Id: named.docbook,v 1.5.98.3 2004/06/03 02:24:57 marka Exp --> <refentry> <refentryinfo> @@ -356,7 +356,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/dist/bind/bin/named/named.html b/dist/bind/bin/named/named.html index b1c59e5b654..a3e55d9ca4a 100644 --- a/dist/bind/bin/named/named.html +++ b/dist/bind/bin/named/named.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: named.html,v 1.4.2.1.4.2 2004/03/06 10:21:20 marka Exp --> +<!-- Id: named.html,v 1.4.2.1.4.4 2004/08/22 23:38:59 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >named</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,10 +35,10 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" +></A ><SPAN CLASS="APPLICATION" >named</SPAN -></A ></H1 ><DIV CLASS="REFNAMEDIV" @@ -62,80 +62,66 @@ NAME="AEN13" ><B CLASS="COMMAND" >named</B -> [<TT +> [<VAR CLASS="OPTION" ->-4</TT ->] [<TT +>-4</VAR +>] [<VAR CLASS="OPTION" ->-6</TT ->] [<TT +>-6</VAR +>] [<VAR CLASS="OPTION" ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->config-file</I -></TT -></TT ->] [<TT +>config-file</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-d <TT +>-d <VAR CLASS="REPLACEABLE" -><I ->debug-level</I -></TT -></TT ->] [<TT +>debug-level</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-f</TT ->] [<TT +>-f</VAR +>] [<VAR CLASS="OPTION" ->-g</TT ->] [<TT +>-g</VAR +>] [<VAR CLASS="OPTION" ->-n <TT +>-n <VAR CLASS="REPLACEABLE" -><I ->#cpus</I -></TT -></TT ->] [<TT +>#cpus</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-p <TT +>-p <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT -></TT ->] [<TT +>port</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-s</TT ->] [<TT +>-s</VAR +>] [<VAR CLASS="OPTION" ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT -></TT ->] [<TT +>directory</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-u <TT +>-u <VAR CLASS="REPLACEABLE" -><I ->user</I -></TT -></TT ->] [<TT +>user</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-v</TT ->] [<TT +>-v</VAR +>] [<VAR CLASS="OPTION" ->-x <TT +>-x <VAR CLASS="REPLACEABLE" -><I ->cache-file</I -></TT -></TT +>cache-file</VAR +></VAR >]</P ></DIV ><DIV @@ -183,12 +169,12 @@ CLASS="VARIABLELIST" ><DD ><P > Use IPv4 only even if the host machine is capable of IPv6. - <TT + <VAR CLASS="OPTION" ->-4</TT -> and <TT +>-4</VAR +> and <VAR CLASS="OPTION" ->-6</TT +>-6</VAR > are mutually exclusive. </P @@ -198,30 +184,26 @@ CLASS="OPTION" ><DD ><P > Use IPv6 only even if the host machine is capable of IPv4. - <TT + <VAR CLASS="OPTION" ->-4</TT -> and <TT +>-4</VAR +> and <VAR CLASS="OPTION" ->-6</TT +>-6</VAR > are mutually exclusive. </P ></DD ><DT ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->config-file</I -></TT +>config-file</VAR ></DT ><DD ><P -> Use <TT +> Use <VAR CLASS="REPLACEABLE" -><I ->config-file</I -></TT +>config-file</VAR > as the configuration file instead of the default, <TT @@ -231,33 +213,27 @@ CLASS="FILENAME" ensure that reloading the configuration file continues to work after the server has changed its working directory due to to a possible - <TT + <VAR CLASS="OPTION" ->directory</TT +>directory</VAR > option in the configuration - file, <TT + file, <VAR CLASS="REPLACEABLE" -><I ->config-file</I -></TT +>config-file</VAR > should be an absolute pathname. </P ></DD ><DT ->-d <TT +>-d <VAR CLASS="REPLACEABLE" -><I ->debug-level</I -></TT +>debug-level</VAR ></DT ><DD ><P -> Set the daemon's debug level to <TT +> Set the daemon's debug level to <VAR CLASS="REPLACEABLE" -><I ->debug-level</I -></TT +>debug-level</VAR >. Debugging traces from <B CLASS="COMMAND" @@ -285,19 +261,15 @@ CLASS="FILENAME" </P ></DD ><DT ->-n <TT +>-n <VAR CLASS="REPLACEABLE" -><I ->#cpus</I -></TT +>#cpus</VAR ></DT ><DD ><P -> Create <TT +> Create <VAR CLASS="REPLACEABLE" -><I ->#cpus</I -></TT +>#cpus</VAR > worker threads to take advantage of multiple CPUs. If not specified, <B @@ -310,19 +282,15 @@ CLASS="COMMAND" </P ></DD ><DT ->-p <TT +>-p <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT +>port</VAR ></DT ><DD ><P -> Listen for queries on port <TT +> Listen for queries on port <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT +>port</VAR >. If not specified, the default is port 53. </P @@ -350,22 +318,18 @@ CLASS="NOTE" ></DIV ></DD ><DT ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT +>directory</VAR ></DT ><DD ><P -> <TT +> <CODE CLASS="FUNCTION" ->chroot()</TT -> to <TT +>chroot()</CODE +> to <VAR CLASS="REPLACEABLE" -><I ->directory</I -></TT +>directory</VAR > after processing the command line arguments, but before reading the configuration file. @@ -390,14 +354,14 @@ ALIGN="CENTER" ALIGN="LEFT" ><P > This option should be used in conjunction with the - <TT + <VAR CLASS="OPTION" ->-u</TT +>-u</VAR > option, as chrooting a process running as root doesn't enhance security on most - systems; the way <TT + systems; the way <CODE CLASS="FUNCTION" ->chroot()</TT +>chroot()</CODE > is defined allows a process with root privileges to escape a chroot jail. @@ -408,22 +372,18 @@ CLASS="FUNCTION" ></DIV ></DD ><DT ->-u <TT +>-u <VAR CLASS="REPLACEABLE" -><I ->user</I -></TT +>user</VAR ></DT ><DD ><P -> <TT +> <CODE CLASS="FUNCTION" ->setuid()</TT -> to <TT +>setuid()</CODE +> to <VAR CLASS="REPLACEABLE" -><I ->user</I -></TT +>user</VAR > after completing privileged operations, such as creating sockets that listen on privileged ports. @@ -440,14 +400,14 @@ CLASS="COMMAND" >named</B > uses the kernel's capability mechanism to drop all root privileges - except the ability to <TT + except the ability to <CODE CLASS="FUNCTION" ->bind()</TT +>bind()</CODE > to a privileged port and set process resource limits. - Unfortunately, this means that the <TT + Unfortunately, this means that the <VAR CLASS="OPTION" ->-u</TT +>-u</VAR > option only works when <B CLASS="COMMAND" @@ -455,9 +415,9 @@ CLASS="COMMAND" > 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 <TT + to be retained after <CODE CLASS="FUNCTION" ->setuid()</TT +>setuid()</CODE >. </P ></BLOCKQUOTE @@ -471,19 +431,15 @@ CLASS="FUNCTION" </P ></DD ><DT ->-x <TT +>-x <VAR CLASS="REPLACEABLE" -><I ->cache-file</I -></TT +>cache-file</VAR ></DT ><DD ><P -> Load data from <TT +> Load data from <VAR CLASS="REPLACEABLE" -><I ->cache-file</I -></TT +>cache-file</VAR > into the cache of the default view. </P @@ -661,7 +617,7 @@ NAME="AEN198" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/dist/bind/bin/named/notify.c b/dist/bind/bin/named/notify.c index 7279fec7dba..4bdd5d7142e 100644 --- a/dist/bind/bin/named/notify.c +++ b/dist/bind/bin/named/notify.c @@ -1,4 +1,4 @@ -/* $NetBSD: notify.c,v 1.1.1.1 2004/05/17 23:43:22 christos Exp $ */ +/* $NetBSD: notify.c,v 1.1.1.2 2004/11/06 23:53:34 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,11 +17,12 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: notify.c,v 1.24.2.2.2.6 2004/03/08 04:04:19 marka Exp */ +/* Id: notify.c,v 1.24.2.2.2.7 2004/08/28 06:25:30 marka Exp */ #include <config.h> #include <isc/log.h> +#include <isc/print.h> #include <dns/message.h> #include <dns/rdataset.h> diff --git a/dist/bind/bin/named/query.c b/dist/bind/bin/named/query.c index c11d31ab1ca..19b59ddaf0d 100644 --- a/dist/bind/bin/named/query.c +++ b/dist/bind/bin/named/query.c @@ -1,4 +1,4 @@ -/* $NetBSD: query.c,v 1.1.1.1 2004/05/17 23:43:23 christos Exp $ */ +/* $NetBSD: query.c,v 1.1.1.2 2004/11/06 23:53:35 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: query.c,v 1.198.2.13.4.27 2004/04/15 02:10:38 marka Exp */ +/* Id: query.c,v 1.198.2.13.4.30 2004/06/30 14:13:05 marka Exp */ #include <config.h> @@ -1787,7 +1787,7 @@ query_addds(ns_client_t *client, dns_db_t *db, dns_dbnode_t *node) { rdataset = query_newrdataset(client); sigrdataset = query_newrdataset(client); if (rdataset == NULL || sigrdataset == NULL) - return; + goto cleanup; /* * Look for the DS record, which may or may not be present. @@ -1841,13 +1841,16 @@ query_addwildcardproof(ns_client_t *client, dns_db_t *db, isc_buffer_t *dbuf, b; dns_name_t *fname; dns_rdataset_t *rdataset, *sigrdataset; - dns_fixedname_t tfixed; - dns_name_t *tname; + dns_fixedname_t wfixed; + dns_name_t *wname; dns_dbnode_t *node; unsigned int options; - unsigned int olabels, nlabels, i; - isc_boolean_t done; + 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; @@ -1855,87 +1858,107 @@ query_addwildcardproof(ns_client_t *client, dns_db_t *db, 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; - if (ispositive) { - /* - * 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) - 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); - } - - olabels = dns_name_countlabels(dns_db_origin(db)); - nlabels = dns_name_countlabels(name); - done = ISC_FALSE; - - for (i = nlabels - 1; i >= olabels && !done; i--) { - /* - * 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; - - dns_fixedname_init(&tfixed); - tname = dns_fixedname_name(&tfixed); - dns_name_split(name, i, NULL, tname); - result = dns_name_concatenate(dns_wildcardname, tname, tname, - NULL); - if (result != ISC_R_SUCCESS) - continue; - - result = dns_db_find(db, tname, NULL, dns_rdatatype_nsec, - client->query.dboptions, 0, &node, - fname, rdataset, sigrdataset); - if (node != NULL) - dns_db_detachnode(db, &node); - /* - * If this returns success, we've found the wildcard for a - * successful answer, so we're done. - */ - if (result == ISC_R_SUCCESS && ispositive) - break; - if (result == DNS_R_NXDOMAIN || result == DNS_R_EMPTYNAME) { - if (!ispositive && - dns_name_issubdomain(name, fname)) - done = ISC_TRUE; - query_addrrset(client, &fname, &rdataset, &sigrdataset, - dbuf, DNS_SECTION_AUTHORITY); + 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 (rdataset != NULL) - query_putrdataset(client, &rdataset); - if (sigrdataset != NULL) - query_putrdataset(client, &sigrdataset); - if (fname != NULL) - query_releasename(client, &fname); + 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); diff --git a/dist/bind/bin/named/server.c b/dist/bind/bin/named/server.c index 31fb6cda780..5b8798301a8 100644 --- a/dist/bind/bin/named/server.c +++ b/dist/bind/bin/named/server.c @@ -1,4 +1,4 @@ -/* $NetBSD: server.c,v 1.1.1.1 2004/05/17 23:43:23 christos Exp $ */ +/* $NetBSD: server.c,v 1.1.1.2 2004/11/06 23:53:36 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: server.c,v 1.339.2.15.2.53 2004/04/20 14:12:08 marka Exp */ +/* Id: server.c,v 1.339.2.15.2.56 2004/06/18 04:39:48 marka Exp */ #include <config.h> @@ -1173,14 +1173,42 @@ configure_view(dns_view_t *view, cfg_obj_t *config, cfg_obj_t *vconfig, obj = NULL; result = ns_config_get(maps, "dnssec-lookaside", &obj); if (result == ISC_R_SUCCESS) { - const char *dlv; - isc_buffer_t b; - dlv = cfg_obj_asstring(obj); - isc_buffer_init(&b, dlv, strlen(dlv)); - isc_buffer_add(&b, strlen(dlv)); - CHECK(dns_name_fromtext(dns_fixedname_name(&view->dlv_fixed), - &b, dns_rootname, ISC_TRUE, NULL)); - view->dlv = dns_fixedname_name(&view->dlv_fixed); + 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; @@ -1342,7 +1370,7 @@ configure_alternates(cfg_obj_t *config, dns_view_t *view, CHECK(dns_name_fromtext(name, &buffer, dns_rootname, ISC_FALSE, NULL)); - portobj = cfg_tuple_get(alternates, "port"); + portobj = cfg_tuple_get(alternate, "port"); if (cfg_obj_isuint32(portobj)) { isc_uint32_t val = cfg_obj_asuint32(portobj); if (val > ISC_UINT16_MAX) { @@ -2879,6 +2907,8 @@ shutdown_server(isc_task_t *task, isc_event_t *event) { 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); @@ -3030,8 +3060,6 @@ ns_server_destroy(ns_server_t **serverp) { INSIST(ISC_LIST_EMPTY(server->viewlist)); - dns_db_detach(&server->in_roothints); - dns_aclenv_destroy(&server->aclenv); isc_quota_destroy(&server->recursionquota); diff --git a/dist/bind/bin/named/tkeyconf.c b/dist/bind/bin/named/tkeyconf.c index d5512ec6b27..4afa02f137e 100644 --- a/dist/bind/bin/named/tkeyconf.c +++ b/dist/bind/bin/named/tkeyconf.c @@ -1,4 +1,4 @@ -/* $NetBSD: tkeyconf.c,v 1.1.1.1 2004/05/17 23:43:23 christos Exp $ */ +/* $NetBSD: tkeyconf.c,v 1.1.1.2 2004/11/06 23:53:36 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: tkeyconf.c,v 1.19.208.1 2004/03/06 10:21:21 marka Exp */ +/* Id: tkeyconf.c,v 1.19.208.2 2004/06/11 00:30:51 marka Exp */ #include <config.h> @@ -55,6 +55,7 @@ ns_tkeyctx_fromconfig(cfg_obj_t *options, isc_mem_t *mctx, isc_entropy_t *ectx, 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) @@ -71,9 +72,9 @@ ns_tkeyctx_fromconfig(cfg_obj_t *options, isc_mem_t *mctx, isc_entropy_t *ectx, 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, - DST_TYPE_PUBLIC|DST_TYPE_PRIVATE, - NULL, mctx, &tctx->dhkey)); + type, NULL, mctx, &tctx->dhkey)); } obj = NULL; diff --git a/dist/bind/bin/named/unix/os.c b/dist/bind/bin/named/unix/os.c index 85539acaab3..00ab60fd242 100644 --- a/dist/bind/bin/named/unix/os.c +++ b/dist/bind/bin/named/unix/os.c @@ -1,4 +1,4 @@ -/* $NetBSD: os.c,v 1.1.1.1 2004/05/17 23:43:25 christos Exp $ */ +/* $NetBSD: os.c,v 1.1.1.2 2004/11/06 23:53:37 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: os.c,v 1.46.2.4.8.15 2004/04/15 05:34:57 marka Exp */ +/* Id: os.c,v 1.46.2.4.8.16 2004/05/04 03:19:42 marka Exp */ #include <config.h> #include <stdarg.h> @@ -618,7 +618,7 @@ ns_os_shutdownmsg(char *command, isc_buffer_t *text) { n = snprintf((char *)isc_buffer_used(text), isc_buffer_availablelength(text), - "pid: %d", pid); + "pid: %ld", (long)pid); /* Only send a message if it is complete. */ if (n < isc_buffer_availablelength(text)) isc_buffer_add(text, n); diff --git a/dist/bind/bin/named/update.c b/dist/bind/bin/named/update.c index 55eeb0dd89a..bce65407fb6 100644 --- a/dist/bind/bin/named/update.c +++ b/dist/bind/bin/named/update.c @@ -1,4 +1,4 @@ -/* $NetBSD: update.c,v 1.1.1.1 2004/05/17 23:43:24 christos Exp $ */ +/* $NetBSD: update.c,v 1.1.1.2 2004/11/06 23:53:36 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: update.c,v 1.88.2.5.2.17 2004/04/15 02:10:39 marka Exp */ +/* Id: update.c,v 1.88.2.5.2.23 2004/07/23 02:56:52 marka Exp */ #include <config.h> @@ -241,7 +241,7 @@ update_log(ns_client_t *client, dns_zone_t *zone, static isc_result_t checkupdateacl(ns_client_t *client, dns_acl_t *acl, const char *message, - dns_name_t *zonename) + dns_name_t *zonename, isc_boolean_t slave) { char namebuf[DNS_NAME_FORMATSIZE]; char classbuf[DNS_RDATACLASS_FORMATSIZE]; @@ -249,7 +249,12 @@ checkupdateacl(ns_client_t *client, dns_acl_t *acl, const char *message, const char *msg = "denied"; isc_result_t result; - result = ns_client_checkaclsilent(client, acl, ISC_FALSE); + 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); @@ -852,7 +857,8 @@ temp_check(isc_mem_t *mctx, dns_diff_t *temp, dns_db_t *db, this name and type */ *typep = type = t->rdata.type; - if (type == dns_rdatatype_rrsig) + if (type == dns_rdatatype_rrsig || + type == dns_rdatatype_sig) covers = dns_rdata_covers(&t->rdata); else covers = 0; @@ -1101,14 +1107,16 @@ 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. */ - if (dns_rdata_compare(&rr->rdata, ctx->update_rr) == 0 && - rr->ttl == ctx->update_rr_ttl) { + 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); } /* @@ -1136,12 +1144,14 @@ add_rr_prepare_action(void *data, rr_t *rr) { &rr->rdata, &tuple)); dns_diff_append(&ctx->del_diff, &tuple); - 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); + 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); @@ -1964,6 +1974,8 @@ send_update_event(ns_client_t *client, dns_zone_t *zone) { evclient = NULL; ns_client_attach(client, &evclient); + INSIST(client->nupdates == 0); + client->nupdates++; event->ev_arg = evclient; dns_zone_gettask(zone, &zonetask); @@ -2049,7 +2061,7 @@ ns_update_start(ns_client_t *client, isc_result_t sigresult) { break; case dns_zone_slave: CHECK(checkupdateacl(client, dns_zone_getforwardacl(zone), - "update forwarding", zonename)); + "update forwarding", zonename, ISC_TRUE)); CHECK(send_forward_event(client, zone)); break; default: @@ -2258,9 +2270,10 @@ update_action(isc_task_t *task, isc_event_t *event) { result = ISC_R_SUCCESS; if (ssutable == NULL) CHECK(checkupdateacl(client, dns_zone_getupdateacl(zone), - "update", zonename)); + "update", zonename, ISC_FALSE)); else if (client->signer == NULL) - CHECK(checkupdateacl(client, NULL, "update", zonename)); + CHECK(checkupdateacl(client, NULL, "update", zonename, + ISC_FALSE)); if (dns_zone_getupdatedisabled(zone)) FAILC(DNS_R_REFUSED, "dynamic update temporarily disabled"); @@ -2469,8 +2482,9 @@ update_action(isc_task_t *task, isc_event_t *event) { 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)); + CHECK(foreach_rr(db, ver, name, rdata.type, + covers, add_rr_prepare_action, + &ctx)); if (ctx.ignore_add) { dns_diff_clear(&ctx.del_diff); @@ -2623,26 +2637,29 @@ update_action(isc_task_t *task, isc_event_t *event) { 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); + /* + * 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); + /* + * 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); + /* + * 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; @@ -2690,6 +2707,8 @@ updatedone_action(isc_task_t *task, isc_event_t *event) { 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); @@ -2705,6 +2724,8 @@ forward_fail(isc_task_t *task, isc_event_t *event) { UNUSED(task); + INSIST(client->nupdates > 0); + client->nupdates--; respond(client, DNS_R_SERVFAIL); ns_client_detach(&client); isc_event_free(&event); @@ -2735,6 +2756,8 @@ forward_done(isc_task_t *task, isc_event_t *event) { UNUSED(task); + INSIST(client->nupdates > 0); + client->nupdates--; ns_client_sendraw(client, uev->answer); dns_message_destroy(&uev->answer); isc_event_free(&event); @@ -2776,6 +2799,8 @@ send_forward_event(ns_client_t *client, dns_zone_t *zone) { evclient = NULL; ns_client_attach(client, &evclient); + INSIST(client->nupdates == 0); + client->nupdates++; event->ev_arg = evclient; dns_zone_gettask(zone, &zonetask); diff --git a/dist/bind/bin/nsupdate/Makefile.in b/dist/bind/bin/nsupdate/Makefile.in index b0a2d132f0c..4663ed20c2a 100644 --- a/dist/bind/bin/nsupdate/Makefile.in +++ b/dist/bind/bin/nsupdate/Makefile.in @@ -13,7 +13,7 @@ # 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.9 2004/03/08 09:04:15 marka Exp +# Id: Makefile.in,v 1.15.12.10 2004/07/20 07:01:49 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -64,7 +64,7 @@ MANOBJS = ${MANPAGES} ${HTMLPAGES} @BIND9_MAKE_RULES@ nsupdate@EXEEXT@: nsupdate.@O@ ${UOBJS} ${DEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ nsupdate.@O@ ${UOBJS} ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ nsupdate.@O@ ${UOBJS} ${LIBS} doc man:: ${MANOBJS} diff --git a/dist/bind/bin/nsupdate/nsupdate.html b/dist/bind/bin/nsupdate/nsupdate.html index 9d0c655e11d..ef622d443dc 100644 --- a/dist/bind/bin/nsupdate/nsupdate.html +++ b/dist/bind/bin/nsupdate/nsupdate.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: nsupdate.html,v 1.9.2.3.2.4 2004/03/08 04:04:23 marka Exp --> +<!-- Id: nsupdate.html,v 1.9.2.3.2.5 2004/08/22 23:38:59 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >nsupdate</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->nsupdate</A -></H1 +></A +>nsupdate</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -56,52 +56,42 @@ NAME="AEN11" ><B CLASS="COMMAND" >nsupdate</B -> [<TT +> [<VAR CLASS="OPTION" ->-d</TT ->] [<TT +>-d</VAR +>] [<VAR CLASS="OPTION" ->-y <TT +>-y <VAR CLASS="REPLACEABLE" -><I ->keyname:secret</I -></TT -></TT -> | <TT +>keyname:secret</VAR +></VAR +> | <VAR CLASS="OPTION" ->-k <TT +>-k <VAR CLASS="REPLACEABLE" -><I ->keyfile</I -></TT -></TT ->] [<TT +>keyfile</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->timeout</I -></TT -></TT ->] [<TT +>timeout</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-u <TT +>-u <VAR CLASS="REPLACEABLE" -><I ->udptimeout</I -></TT -></TT ->] [<TT +>udptimeout</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-r <TT +>-r <VAR CLASS="REPLACEABLE" -><I ->udpretries</I -></TT -></TT ->] [<TT +>udpretries</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-v</TT +>-v</VAR >] [filename]</P ></DIV ><DIV @@ -142,9 +132,9 @@ Requests are sent to the zone's master server. This is identified by the MNAME field of the zone's SOA record.</P ><P >The -<TT +<VAR CLASS="OPTION" ->-d</TT +>-d</VAR > option makes <B @@ -204,22 +194,22 @@ CLASS="COMMAND" >nsupdate</B > uses the -<TT +<VAR CLASS="OPTION" ->-y</TT +>-y</VAR > or -<TT +<VAR CLASS="OPTION" ->-k</TT +>-k</VAR > 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 -<TT +<VAR CLASS="OPTION" ->-k</TT +>-k</VAR > option, <B @@ -227,11 +217,9 @@ CLASS="COMMAND" >nsupdate</B > reads the shared secret from the file -<TT +<VAR CLASS="PARAMETER" -><I ->keyfile</I -></TT +>keyfile</VAR >, whose name is of the form <TT @@ -245,36 +233,30 @@ CLASS="FILENAME" >K{name}.+157.+{random}.key</TT > must also be present. When the -<TT +<VAR CLASS="OPTION" ->-y</TT +>-y</VAR > option is used, a signature is generated from -<TT +<VAR CLASS="PARAMETER" -><I ->keyname:secret.</I -></TT +>keyname:secret.</VAR > -<TT +<VAR CLASS="PARAMETER" -><I ->keyname</I -></TT +>keyname</VAR > is the name of the key, and -<TT +<VAR CLASS="PARAMETER" -><I ->secret</I -></TT +>secret</VAR > is the base64 encoded shared secret. Use of the -<TT +<VAR CLASS="OPTION" ->-y</TT +>-y</VAR > option is discouraged because the shared secret is supplied as a command line argument in clear text. @@ -288,9 +270,9 @@ CLASS="REFENTRYTITLE" > or in a history file maintained by the user's shell.</P ><P ->The <TT +>The <VAR CLASS="OPTION" ->-k</TT +>-k</VAR > 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.</P @@ -303,9 +285,9 @@ CLASS="COMMAND" 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 -<TT +<VAR CLASS="OPTION" ->-v</TT +>-v</VAR > option makes <B @@ -315,23 +297,23 @@ CLASS="COMMAND" use a TCP connection. This may be preferable when a batch of update requests is made.</P ><P ->The <TT +>The <VAR CLASS="OPTION" ->-t</TT +>-t</VAR > 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.</P ><P ->The <TT +>The <VAR CLASS="OPTION" ->-u</TT +>-u</VAR > 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.</P ><P ->The <TT +>The <VAR CLASS="OPTION" ->-r</TT +>-r</VAR > option sets the number of UDP retries. The default is 3. If zero only one update request will be made.</P ></DIV @@ -348,11 +330,9 @@ CLASS="COMMAND" >nsupdate</B > reads input from -<TT +<VAR CLASS="PARAMETER" -><I ->filename</I -></TT +>filename</VAR > or standard input. Each command is supplied on exactly one line of input. @@ -391,11 +371,9 @@ CLASS="COMMAND" ><DD ><P >Sends all dynamic update requests to the name server -<TT +<VAR CLASS="PARAMETER" -><I ->servername</I -></TT +>servername</VAR >. When no server statement is provided, <B @@ -405,18 +383,14 @@ CLASS="COMMAND" 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. -<TT +<VAR CLASS="PARAMETER" -><I ->port</I -></TT +>port</VAR > is the port number on -<TT +<VAR CLASS="PARAMETER" -><I ->servername</I -></TT +>servername</VAR > where the dynamic update requests get sent. If no port number is specified, the default DNS port number of 53 is @@ -432,11 +406,9 @@ CLASS="COMMAND" ><DD ><P >Sends all dynamic update requests using the local -<TT +<VAR CLASS="PARAMETER" -><I ->address</I -></TT +>address</VAR >. When no local statement is provided, @@ -445,11 +417,9 @@ CLASS="COMMAND" >nsupdate</B > will send updates using an address and port chosen by the system. -<TT +<VAR CLASS="PARAMETER" -><I ->port</I -></TT +>port</VAR > can additionally be used to make requests come from a specific port. If no port number is specified, the system will assign one. </P @@ -464,18 +434,14 @@ CLASS="COMMAND" ><DD ><P >Specifies that all updates are to be made to the zone -<TT +<VAR CLASS="PARAMETER" -><I ->zonename</I -></TT +>zonename</VAR >. If no -<TT +<VAR CLASS="PARAMETER" -><I ->zone</I -></TT +>zone</VAR > statement is provided, <B @@ -494,17 +460,13 @@ CLASS="COMMAND" ><DD ><P >Specify the default class. -If no <TT +If no <VAR CLASS="PARAMETER" -><I ->class</I -></TT +>class</VAR > is specified the default class is -<TT +<VAR CLASS="PARAMETER" -><I ->IN</I -></TT +>IN</VAR >.</P ></DD ><DT @@ -517,28 +479,24 @@ CLASS="COMMAND" ><DD ><P >Specifies that all updates are to be TSIG signed using the -<TT +<VAR CLASS="PARAMETER" -><I ->keyname</I -></TT -> <TT +>keyname</VAR +> <VAR CLASS="PARAMETER" -><I ->keysecret</I -></TT +>keysecret</VAR > pair. The <B CLASS="COMMAND" >key</B > command overrides any key specified on the command line via -<TT +<VAR CLASS="OPTION" ->-y</TT -> or <TT +>-y</VAR +> or <VAR CLASS="OPTION" ->-k</TT +>-k</VAR >.</P ></DD ><DT @@ -551,11 +509,9 @@ CLASS="COMMAND" ><DD ><P >Requires that no resource record of any type exists with name -<TT +<VAR CLASS="PARAMETER" -><I ->domain-name</I -></TT +>domain-name</VAR >.</P ></DD ><DT @@ -568,11 +524,9 @@ CLASS="COMMAND" ><DD ><P >Requires that -<TT +<VAR CLASS="PARAMETER" -><I ->domain-name</I -></TT +>domain-name</VAR > exists (has as at least one resource record, of any type).</P ></DD @@ -586,31 +540,23 @@ CLASS="COMMAND" ><DD ><P >Requires that no resource record exists of the specified -<TT +<VAR CLASS="PARAMETER" -><I ->type</I -></TT +>type</VAR >, -<TT +<VAR CLASS="PARAMETER" -><I ->class</I -></TT +>class</VAR > and -<TT +<VAR CLASS="PARAMETER" -><I ->domain-name</I -></TT +>domain-name</VAR >. If -<TT +<VAR CLASS="PARAMETER" -><I ->class</I -></TT +>class</VAR > is omitted, IN (internet) is assumed.</P ></DD @@ -624,32 +570,24 @@ CLASS="COMMAND" ><DD ><P >This requires that a resource record of the specified -<TT +<VAR CLASS="PARAMETER" -><I ->type</I -></TT +>type</VAR >, -<TT +<VAR CLASS="PARAMETER" -><I ->class</I -></TT +>class</VAR > and -<TT +<VAR CLASS="PARAMETER" -><I ->domain-name</I -></TT +>domain-name</VAR > must exist. If -<TT +<VAR CLASS="PARAMETER" -><I ->class</I -></TT +>class</VAR > is omitted, IN (internet) is assumed.</P ></DD @@ -663,61 +601,45 @@ CLASS="COMMAND" ><DD ><P >The -<TT +<VAR CLASS="PARAMETER" -><I ->data</I -></TT +>data</VAR > from each set of prerequisites of this form sharing a common -<TT +<VAR CLASS="PARAMETER" -><I ->type</I -></TT +>type</VAR >, -<TT +<VAR CLASS="PARAMETER" -><I ->class</I -></TT +>class</VAR >, and -<TT +<VAR CLASS="PARAMETER" -><I ->domain-name</I -></TT +>domain-name</VAR > 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 -<TT +<VAR CLASS="PARAMETER" -><I ->type</I -></TT +>type</VAR >, -<TT +<VAR CLASS="PARAMETER" -><I ->class</I -></TT +>class</VAR >, and -<TT +<VAR CLASS="PARAMETER" -><I ->domain-name</I -></TT +>domain-name</VAR >. The -<TT +<VAR CLASS="PARAMETER" -><I ->data</I -></TT +>data</VAR > are written in the standard text representation of the resource record's RDATA.</P @@ -732,40 +654,30 @@ CLASS="COMMAND" ><DD ><P >Deletes any resource records named -<TT +<VAR CLASS="PARAMETER" -><I ->domain-name</I -></TT +>domain-name</VAR >. If -<TT +<VAR CLASS="PARAMETER" -><I ->type</I -></TT +>type</VAR > and -<TT +<VAR CLASS="PARAMETER" -><I ->data</I -></TT +>data</VAR > is provided, only matching resource records will be removed. The internet class is assumed if -<TT +<VAR CLASS="PARAMETER" -><I ->class</I -></TT +>class</VAR > is not supplied. The -<TT +<VAR CLASS="PARAMETER" -><I ->ttl</I -></TT +>ttl</VAR > is ignored, and is only allowed for compatibility.</P ></DD @@ -779,24 +691,18 @@ CLASS="COMMAND" ><DD ><P >Adds a new resource record with the specified -<TT +<VAR CLASS="PARAMETER" -><I ->ttl</I -></TT +>ttl</VAR >, -<TT +<VAR CLASS="PARAMETER" -><I ->class</I -></TT +>class</VAR > and -<TT +<VAR CLASS="PARAMETER" -><I ->data</I -></TT +>data</VAR >.</P ></DD ><DT @@ -923,18 +829,18 @@ NAME="AEN268" CLASS="VARIABLELIST" ><DL ><DT -><TT +><CODE CLASS="CONSTANT" ->/etc/resolv.conf</TT +>/etc/resolv.conf</CODE ></DT ><DD ><P >used to identify default name server</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->K{name}.+157.+{random}.key</TT +>K{name}.+157.+{random}.key</CODE ></DT ><DD ><P @@ -948,9 +854,9 @@ CLASS="REFENTRYTITLE" >.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->K{name}.+157.+{random}.private</TT +>K{name}.+157.+{random}.private</CODE ></DT ><DD ><P diff --git a/dist/bind/bin/rndc/Makefile.in b/dist/bind/bin/rndc/Makefile.in index 84c0ed9b1cf..7a3b157dff0 100644 --- a/dist/bind/bin/rndc/Makefile.in +++ b/dist/bind/bin/rndc/Makefile.in @@ -13,7 +13,7 @@ # 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.7 2004/03/08 04:04:23 marka Exp +# Id: Makefile.in,v 1.32.2.3.8.8 2004/07/20 07:01:50 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -74,11 +74,11 @@ rndc-confgen.@O@: rndc-confgen.c -c ${srcdir}/rndc-confgen.c rndc@EXEEXT@: rndc.@O@ util.@O@ ${RNDCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ rndc.@O@ util.@O@ \ + ${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} -o $@ rndc-confgen.@O@ util.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ rndc-confgen.@O@ util.@O@ \ ${UOBJS} ${CONFLIBS} doc man:: ${MANOBJS} diff --git a/dist/bind/bin/rndc/rndc-confgen.8 b/dist/bind/bin/rndc/rndc-confgen.8 index 91f6c195d6d..18a56acd426 100644 --- a/dist/bind/bin/rndc/rndc-confgen.8 +++ b/dist/bind/bin/rndc/rndc-confgen.8 @@ -1,4 +1,4 @@ -.\" $NetBSD: rndc-confgen.8,v 1.1.1.1 2004/05/17 23:43:25 christos Exp $ +.\" $NetBSD: rndc-confgen.8,v 1.1.1.2 2004/11/06 23:53:38 christos Exp $ .\" .\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2001-2003 Internet Software Consortium. @@ -15,7 +15,7 @@ .\" 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.2 2004/03/06 07:41:40 marka Exp +.\" 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 @@ -139,4 +139,4 @@ run \fIBIND 9 Administrator Reference Manual\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/dist/bind/bin/rndc/rndc-confgen.docbook b/dist/bind/bin/rndc/rndc-confgen.docbook index 68dfa10b048..dc31f7f2663 100644 --- a/dist/bind/bin/rndc/rndc-confgen.docbook +++ b/dist/bind/bin/rndc/rndc-confgen.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: rndc-confgen.docbook,v 1.3.2.1.4.2 2004/03/06 10:21:32 marka Exp --> +<!-- Id: rndc-confgen.docbook,v 1.3.2.1.4.3 2004/06/03 02:24:58 marka Exp --> <refentry> <refentryinfo> @@ -260,7 +260,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/dist/bind/bin/rndc/rndc-confgen.html b/dist/bind/bin/rndc/rndc-confgen.html index b5a2bbeec8d..aa984f62c35 100644 --- a/dist/bind/bin/rndc/rndc-confgen.html +++ b/dist/bind/bin/rndc/rndc-confgen.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: rndc-confgen.html,v 1.3.2.5.2.2 2004/03/06 10:21:32 marka Exp --> +<!-- Id: rndc-confgen.html,v 1.3.2.5.2.4 2004/08/22 23:39:00 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >rndc-confgen</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,10 +35,10 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" +></A ><SPAN CLASS="APPLICATION" >rndc-confgen</SPAN -></A ></H1 ><DIV CLASS="REFNAMEDIV" @@ -62,76 +62,60 @@ NAME="AEN13" ><B CLASS="COMMAND" >rndc-confgen</B -> [<TT +> [<VAR CLASS="OPTION" ->-a</TT ->] [<TT +>-a</VAR +>] [<VAR CLASS="OPTION" ->-b <TT +>-b <VAR CLASS="REPLACEABLE" -><I ->keysize</I -></TT -></TT ->] [<TT +>keysize</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->keyfile</I -></TT -></TT ->] [<TT +>keyfile</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-h</TT ->] [<TT +>-h</VAR +>] [<VAR CLASS="OPTION" ->-k <TT +>-k <VAR CLASS="REPLACEABLE" -><I ->keyname</I -></TT -></TT ->] [<TT +>keyname</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-p <TT +>-p <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT -></TT ->] [<TT +>port</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-r <TT +>-r <VAR CLASS="REPLACEABLE" -><I ->randomfile</I -></TT -></TT ->] [<TT +>randomfile</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-s <TT +>-s <VAR CLASS="REPLACEABLE" -><I ->address</I -></TT -></TT ->] [<TT +>address</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->chrootdir</I -></TT -></TT ->] [<TT +>chrootdir</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-u <TT +>-u <VAR CLASS="REPLACEABLE" -><I ->user</I -></TT -></TT +>user</VAR +></VAR >]</P ></DIV ><DIV @@ -213,13 +197,13 @@ CLASS="FILENAME" CLASS="FILENAME" >/etc</TT > (or whatever - <TT + <VAR CLASS="VARNAME" ->sysconfdir</TT +>sysconfdir</VAR > - was specified as when <SPAN + was specified as when <ACRONYM CLASS="ACRONYM" ->BIND</SPAN +>BIND</ACRONYM > was built) that is read by both <B CLASS="COMMAND" @@ -290,11 +274,9 @@ CLASS="FILENAME" </P ></DD ><DT ->-b <TT +>-b <VAR CLASS="REPLACEABLE" -><I ->keysize</I -></TT +>keysize</VAR ></DT ><DD ><P @@ -303,11 +285,9 @@ CLASS="REPLACEABLE" </P ></DD ><DT ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->keyfile</I -></TT +>keyfile</VAR ></DT ><DD ><P @@ -333,28 +313,24 @@ CLASS="COMMAND" </P ></DD ><DT ->-k <TT +>-k <VAR CLASS="REPLACEABLE" -><I ->keyname</I -></TT +>keyname</VAR ></DT ><DD ><P > Specifies the key name of the rndc authentication key. This must be a valid domain name. - The default is <TT + The default is <CODE CLASS="CONSTANT" ->rndc-key</TT +>rndc-key</CODE >. </P ></DD ><DT ->-p <TT +>-p <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT +>port</VAR ></DT ><DD ><P @@ -370,11 +346,9 @@ CLASS="COMMAND" </P ></DD ><DT ->-r <TT +>-r <VAR CLASS="REPLACEABLE" -><I ->randomfile</I -></TT +>randomfile</VAR ></DT ><DD ><P @@ -399,11 +373,9 @@ CLASS="FILENAME" </P ></DD ><DT ->-s <TT +>-s <VAR CLASS="REPLACEABLE" -><I ->address</I -></TT +>address</VAR ></DT ><DD ><P @@ -420,11 +392,9 @@ CLASS="COMMAND" </P ></DD ><DT ->-t <TT +>-t <VAR CLASS="REPLACEABLE" -><I ->chrootdir</I -></TT +>chrootdir</VAR ></DT ><DD ><P @@ -448,11 +418,9 @@ CLASS="COMMAND" </P ></DD ><DT ->-u <TT +>-u <VAR CLASS="REPLACEABLE" -><I ->user</I -></TT +>user</VAR ></DT ><DD ><P @@ -489,11 +457,9 @@ CLASS="COMMAND" no manual configuration, run </P ><P -> <TT +> <KBD CLASS="USERINPUT" -><B ->rndc-confgen -a</B -></TT +>rndc-confgen -a</KBD > </P ><P @@ -515,11 +481,9 @@ CLASS="FILENAME" run </P ><P -> <TT +> <KBD CLASS="USERINPUT" -><B ->rndc-confgen</B -></TT +>rndc-confgen</KBD > </P ></DIV @@ -566,7 +530,7 @@ NAME="AEN173" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/dist/bind/bin/rndc/rndc.8 b/dist/bind/bin/rndc/rndc.8 index 707984112c5..de7e265eeef 100644 --- a/dist/bind/bin/rndc/rndc.8 +++ b/dist/bind/bin/rndc/rndc.8 @@ -1,4 +1,4 @@ -.\" $NetBSD: rndc.8,v 1.1.1.1 2004/05/17 23:43:26 christos Exp $ +.\" $NetBSD: rndc.8,v 1.1.1.2 2004/11/06 23:53:38 christos Exp $ .\" .\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000, 2001 Internet Software Consortium. @@ -15,7 +15,7 @@ .\" 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.1 2004/03/06 07:41:40 marka Exp +.\" 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 @@ -117,4 +117,4 @@ Several error messages could be clearer. \fIBIND 9 Administrator Reference Manual\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/dist/bind/bin/rndc/rndc.c b/dist/bind/bin/rndc/rndc.c index ff4e4a2f0ff..1329c8e176f 100644 --- a/dist/bind/bin/rndc/rndc.c +++ b/dist/bind/bin/rndc/rndc.c @@ -1,4 +1,4 @@ -/* $NetBSD: rndc.c,v 1.1.1.1 2004/05/17 23:43:26 christos Exp $ */ +/* $NetBSD: rndc.c,v 1.1.1.2 2004/11/06 23:53:38 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: rndc.c,v 1.77.2.5.2.12 2004/03/08 04:04:23 marka Exp */ +/* Id: rndc.c,v 1.77.2.5.2.12.6.1 2004/09/20 01:00:01 marka Exp */ /* * Principal Author: DCL @@ -101,7 +101,7 @@ command is one of the following:\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\ + thaw 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\ diff --git a/dist/bind/bin/rndc/rndc.conf.5 b/dist/bind/bin/rndc/rndc.conf.5 index 44fd85e0700..1e77c0b5d63 100644 --- a/dist/bind/bin/rndc/rndc.conf.5 +++ b/dist/bind/bin/rndc/rndc.conf.5 @@ -1,4 +1,4 @@ -.\" $NetBSD: rndc.conf.5,v 1.1.1.1 2004/05/17 23:43:26 christos Exp $ +.\" $NetBSD: rndc.conf.5,v 1.1.1.2 2004/11/06 23:53:38 christos Exp $ .\" .\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000, 2001 Internet Software Consortium. @@ -15,7 +15,7 @@ .\" 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.1 2004/03/06 07:41:40 marka Exp +.\" 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 @@ -141,4 +141,4 @@ BIND 9 Administrator Reference Manual for details. \fIBIND 9 Administrator Reference Manual\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/dist/bind/bin/rndc/rndc.conf.docbook b/dist/bind/bin/rndc/rndc.conf.docbook index 76915dccb05..424b658c686 100644 --- a/dist/bind/bin/rndc/rndc.conf.docbook +++ b/dist/bind/bin/rndc/rndc.conf.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: rndc.conf.docbook,v 1.4.206.1 2004/03/06 10:21:32 marka Exp --> +<!-- Id: rndc.conf.docbook,v 1.4.206.2 2004/06/03 02:24:58 marka Exp --> <refentry> <refentryinfo> @@ -196,7 +196,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/dist/bind/bin/rndc/rndc.conf.html b/dist/bind/bin/rndc/rndc.conf.html index 53455046994..7f8c98b2c57 100644 --- a/dist/bind/bin/rndc/rndc.conf.html +++ b/dist/bind/bin/rndc/rndc.conf.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: rndc.conf.html,v 1.5.2.1.4.1 2004/03/06 10:21:32 marka Exp --> +<!-- Id: rndc.conf.html,v 1.5.2.1.4.3 2004/08/22 23:39:00 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >rndc.conf</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,10 +35,10 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" +></A ><TT CLASS="FILENAME" >rndc.conf</TT -></A ></H1 ><DIV CLASS="REFNAMEDIV" @@ -111,86 +111,86 @@ CLASS="FILENAME" and a key statement. </P ><P -> The <TT +> The <VAR CLASS="OPTION" ->options</TT +>options</VAR > statement contains three clauses. - The <TT + The <VAR CLASS="OPTION" ->default-server</TT +>default-server</VAR > 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 <B CLASS="COMMAND" >rndc</B ->. The <TT +>. The <VAR CLASS="OPTION" ->default-key</TT +>default-key</VAR > clause is followed by the name of a key which is identified by - a <TT + a <VAR CLASS="OPTION" ->key</TT +>key</VAR > statement. If no - <TT + <VAR CLASS="OPTION" ->keyid</TT +>keyid</VAR > is provided on the rndc command line, - and no <TT + and no <VAR CLASS="OPTION" ->key</TT +>key</VAR > clause is found in a matching - <TT + <VAR CLASS="OPTION" ->server</TT +>server</VAR > statement, this default key will be used to authenticate the server's commands and responses. The - <TT + <VAR CLASS="OPTION" ->default-port</TT +>default-port</VAR > clause is followed by the port to connect to on the remote name server. If no - <TT + <VAR CLASS="OPTION" ->port</TT +>port</VAR > option is provided on the rndc command - line, and no <TT + line, and no <VAR CLASS="OPTION" ->port</TT +>port</VAR > clause is found in a - matching <TT + matching <VAR CLASS="OPTION" ->server</TT +>server</VAR > statement, this default port will be used to connect. </P ><P -> After the <TT +> After the <VAR CLASS="OPTION" ->server</TT +>server</VAR > keyword, the server statement includes a string which is the hostname or address for a name server. The statement has two possible clauses: - <TT + <VAR CLASS="OPTION" ->key</TT -> and <TT +>key</VAR +> and <VAR CLASS="OPTION" ->port</TT +>port</VAR >. The key name must match the name of a key statement in the file. The port number specifies the port to connect to. </P ><P -> The <TT +> The <VAR CLASS="OPTION" ->key</TT +>key</VAR > statement begins with an identifying string, the name of the key. The statement has two clauses. - <TT + <VAR CLASS="OPTION" ->algorithm</TT +>algorithm</VAR > identifies the encryption algorithm for <B CLASS="COMMAND" @@ -265,11 +265,9 @@ CLASS="COMMAND" >: </P ><P -> <TT +> <KBD CLASS="USERINPUT" -><B ->rndc-confgen</B -></TT +>rndc-confgen</KBD > </P ><P @@ -278,13 +276,13 @@ CLASS="FILENAME" >rndc.conf</TT > file, including the randomly generated key, will be written to the standard - output. Commented out <TT + output. Commented out <VAR CLASS="OPTION" ->key</TT +>key</VAR > and - <TT + <VAR CLASS="OPTION" ->controls</TT +>controls</VAR > statements for <TT CLASS="FILENAME" @@ -298,11 +296,9 @@ CLASS="COMMAND" >: </P ><P -> <TT +> <KBD CLASS="USERINPUT" -><B ->echo "known plaintext for a secret" | mmencode</B -></TT +>echo "known plaintext for a secret" | mmencode</KBD > </P ></DIV @@ -323,9 +319,9 @@ CLASS="FILENAME" CLASS="FILENAME" >named.conf</TT >. - See the sections on the <TT + See the sections on the <VAR CLASS="OPTION" ->controls</TT +>controls</VAR > statement in the BIND 9 Administrator Reference Manual for details. </P @@ -373,7 +369,7 @@ NAME="AEN91" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/dist/bind/bin/rndc/rndc.docbook b/dist/bind/bin/rndc/rndc.docbook index db36ea3fdbc..ce9c3738be7 100644 --- a/dist/bind/bin/rndc/rndc.docbook +++ b/dist/bind/bin/rndc/rndc.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: rndc.docbook,v 1.7.206.1 2004/03/06 10:21:32 marka Exp --> +<!-- Id: rndc.docbook,v 1.7.206.2 2004/06/03 02:24:58 marka Exp --> <refentry> <refentryinfo> @@ -214,7 +214,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/dist/bind/bin/rndc/rndc.html b/dist/bind/bin/rndc/rndc.html index 461a8982e24..40a19859e2a 100644 --- a/dist/bind/bin/rndc/rndc.html +++ b/dist/bind/bin/rndc/rndc.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: rndc.html,v 1.7.2.1.4.1 2004/03/06 10:21:32 marka Exp --> +<!-- Id: rndc.html,v 1.7.2.1.4.3 2004/08/22 23:39:00 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >rndc</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,10 +35,10 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" +></A ><SPAN CLASS="APPLICATION" >rndc</SPAN -></A ></H1 ><DIV CLASS="REFNAMEDIV" @@ -62,49 +62,39 @@ NAME="AEN13" ><B CLASS="COMMAND" >rndc</B -> [<TT +> [<VAR CLASS="OPTION" ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->config-file</I -></TT -></TT ->] [<TT +>config-file</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-k <TT +>-k <VAR CLASS="REPLACEABLE" -><I ->key-file</I -></TT -></TT ->] [<TT +>key-file</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-s <TT +>-s <VAR CLASS="REPLACEABLE" -><I ->server</I -></TT -></TT ->] [<TT +>server</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-p <TT +>-p <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT -></TT ->] [<TT +>port</VAR +></VAR +>] [<VAR CLASS="OPTION" ->-V</TT ->] [<TT +>-V</VAR +>] [<VAR CLASS="OPTION" ->-y <TT +>-y <VAR CLASS="REPLACEABLE" -><I ->key_id</I -></TT -></TT +>key_id</VAR +></VAR >] {command}</P ></DIV ><DIV @@ -175,19 +165,15 @@ NAME="AEN46" CLASS="VARIABLELIST" ><DL ><DT ->-c <TT +>-c <VAR CLASS="REPLACEABLE" -><I ->config-file</I -></TT +>config-file</VAR ></DT ><DD ><P -> Use <TT +> Use <VAR CLASS="REPLACEABLE" -><I ->config-file</I -></TT +>config-file</VAR > as the configuration file instead of the default, <TT @@ -197,19 +183,15 @@ CLASS="FILENAME" </P ></DD ><DT ->-k <TT +>-k <VAR CLASS="REPLACEABLE" -><I ->key-file</I -></TT +>key-file</VAR ></DT ><DD ><P -> Use <TT +> Use <VAR CLASS="REPLACEABLE" -><I ->key-file</I -></TT +>key-file</VAR > as the key file instead of the default, <TT @@ -220,29 +202,23 @@ CLASS="FILENAME" CLASS="FILENAME" >/etc/rndc.key</TT > will be used to authenticate - commands sent to the server if the <TT + commands sent to the server if the <VAR CLASS="REPLACEABLE" -><I ->config-file</I -></TT +>config-file</VAR > does not exist. </P ></DD ><DT ->-s <TT +>-s <VAR CLASS="REPLACEABLE" -><I ->server</I -></TT +>server</VAR ></DT ><DD ><P -> <TT +> <VAR CLASS="REPLACEABLE" -><I ->server</I -></TT +>server</VAR > is the name or address of the server which matches a server statement in the configuration file for @@ -256,20 +232,16 @@ CLASS="COMMAND" </P ></DD ><DT ->-p <TT +>-p <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT +>port</VAR ></DT ><DD ><P > Send commands to TCP port - <TT + <VAR CLASS="REPLACEABLE" -><I ->port</I -></TT +>port</VAR > instead of BIND 9's default control channel port, 953. </P @@ -282,34 +254,26 @@ CLASS="REPLACEABLE" </P ></DD ><DT ->-y <TT +>-y <VAR CLASS="REPLACEABLE" -><I ->keyid</I -></TT +>keyid</VAR ></DT ><DD ><P -> Use the key <TT +> Use the key <VAR CLASS="REPLACEABLE" -><I ->keyid</I -></TT +>keyid</VAR > from the configuration file. - <TT + <VAR CLASS="REPLACEABLE" -><I ->keyid</I -></TT +>keyid</VAR > must be known by named with the same algorithm and secret string in order for control message validation to succeed. - If no <TT + If no <VAR CLASS="REPLACEABLE" -><I ->keyid</I -></TT +>keyid</VAR > is specified, <B CLASS="COMMAND" @@ -357,9 +321,9 @@ CLASS="COMMAND" </P ><P > There is currently no way to provide the shared secret for a - <TT + <VAR CLASS="OPTION" ->key_id</TT +>key_id</VAR > without using the configuration file. </P ><P @@ -416,7 +380,7 @@ NAME="AEN118" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/dist/bind/bin/tests/Makefile.in b/dist/bind/bin/tests/Makefile.in index a0dd8f6f458..95de31ab45b 100644 --- a/dist/bind/bin/tests/Makefile.in +++ b/dist/bind/bin/tests/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.113.2.1.8.6 2004/03/08 02:07:41 marka Exp +# Id: Makefile.in,v 1.113.2.1.8.7 2004/07/20 07:01:50 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -133,154 +133,154 @@ SRCS = adb_test.c \ all_tests: ${XTARGETS} genrandom@EXEEXT@: genrandom.@O@ - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ genrandom.@O@ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ genrandom.@O@ adb_test@EXEEXT@: adb_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ adb_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ adb_test.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} nsecify@EXEEXT@: nsecify.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ nsecify.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ nsecify.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} byaddr_test@EXEEXT@: byaddr_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ byaddr_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ byaddr_test.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} byname_test@EXEEXT@: byname_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ byname_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ byname_test.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} lex_test@EXEEXT@: lex_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ lex_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ lex_test.@O@ \ ${ISCLIBS} ${LIBS} lfsr_test@EXEEXT@: lfsr_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ lfsr_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ lfsr_test.@O@ \ ${ISCLIBS} ${LIBS} log_test@EXEEXT@: log_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ log_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ log_test.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} name_test@EXEEXT@: name_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ name_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ name_test.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} hash_test@EXEEXT@: hash_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ hash_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ hash_test.@O@ \ ${ISCLIBS} ${LIBS} entropy_test@EXEEXT@: entropy_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ entropy_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ entropy_test.@O@ \ ${ISCLIBS} ${LIBS} entropy2_test@EXEEXT@: entropy2_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ entropy2_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ entropy2_test.@O@ \ ${ISCLIBS} ${LIBS} sock_test@EXEEXT@: sock_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ sock_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ sock_test.@O@ \ ${ISCLIBS} ${LIBS} sym_test@EXEEXT@: sym_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ sym_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ sym_test.@O@ \ ${ISCLIBS} ${LIBS} task_test@EXEEXT@: task_test.@O@ ${ISCDEPLIBS} - ${PURIFY} ${CC} ${CFLAGS} -o $@ task_test.@O@ \ + ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ task_test.@O@ \ ${ISCLIBS} ${LIBS} shutdown_test@EXEEXT@: shutdown_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ shutdown_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ shutdown_test.@O@ \ ${ISCLIBS} ${LIBS} timer_test@EXEEXT@: timer_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ timer_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ timer_test.@O@ \ ${ISCLIBS} ${LIBS} ratelimiter_test@EXEEXT@: ratelimiter_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ ratelimiter_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ ratelimiter_test.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} rbt_test@EXEEXT@: rbt_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ rbt_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ rbt_test.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} rdata_test@EXEEXT@: rdata_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ rdata_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ rdata_test.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} rwlock_test@EXEEXT@: rwlock_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ rwlock_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ rwlock_test.@O@ \ ${ISCLIBS} ${LIBS} wire_test@EXEEXT@: wire_test.@O@ printmsg.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ wire_test.@O@ printmsg.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ wire_test.@O@ printmsg.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} master_test@EXEEXT@: master_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ master_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ master_test.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} db_test@EXEEXT@: db_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ db_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ db_test.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} compress_test@EXEEXT@: compress_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ compress_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ compress_test.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} mempool_test@EXEEXT@: mempool_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ mempool_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ mempool_test.@O@ \ ${ISCLIBS} ${LIBS} serial_test@EXEEXT@: serial_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ serial_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ serial_test.@O@ \ ${ISCLIBS} ${LIBS} zone_test@EXEEXT@: zone_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ zone_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ zone_test.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} fsaccess_test@EXEEXT@: fsaccess_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ fsaccess_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ fsaccess_test.@O@ \ ${ISCLIBS} ${LIBS} inter_test@EXEEXT@: inter_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ inter_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ inter_test.@O@ \ ${ISCLIBS} ${LIBS} keyboard_test@EXEEXT@: keyboard_test.@O@ ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ keyboard_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ keyboard_test.@O@ \ ${ISCLIBS} ${LIBS} lwresconf_test@EXEEXT@: lwresconf_test.@O@ ${ISCDEPLIBS} ${LWRESDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ lwresconf_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ lwresconf_test.@O@ \ ${LWRESLIBS} ${ISCLIBS} ${LIBS} lwres_test@EXEEXT@: lwres_test.@O@ ${ISCDEPLIBS} ${LWRESDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ lwres_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ lwres_test.@O@ \ ${LWRESLIBS} ${ISCLIBS} ${LIBS} gxbn_test@EXEEXT@: gxbn_test.@O@ ${LWRESDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ gxbn_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ gxbn_test.@O@ \ ${LWRESLIBS} ${ISCLIBS} ${LIBS} gxba_test@EXEEXT@: gxba_test.@O@ ${LWRESDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ gxba_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ gxba_test.@O@ \ ${LWRESLIBS} ${ISCLIBS} ${LIBS} sig0_test@EXEEXT@: sig0_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ sig0_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ sig0_test.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} journalprint@EXEEXT@: journalprint.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ journalprint.@O@ \ + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ journalprint.@O@ \ ${DNSLIBS} ${ISCLIBS} ${LIBS} cfg_test@EXEEXT@: cfg_test.@O@ ${ISCCFGDEPLIBS} ${ISCDEPLIBS} - ${LIBTOOL_MODE_LINK} ${CC} ${CFLAGS} -o $@ cfg_test.@O@ \ + ${LIBTOOL_MODE_LINK} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ cfg_test.@O@ \ ${ISCCFGLIBS} ${DNSLIBS} ${ISCLIBS} ${LIBS} distclean:: diff --git a/dist/bind/bin/tests/db/Makefile.in b/dist/bind/bin/tests/db/Makefile.in index e9db0be2e1d..f0b94eed7ad 100644 --- a/dist/bind/bin/tests/db/Makefile.in +++ b/dist/bind/bin/tests/db/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.21.12.6 2004/03/08 04:04:28 marka Exp +# Id: Makefile.in,v 1.21.12.7 2004/07/20 07:01:50 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -45,7 +45,7 @@ TARGETS = t_db@EXEEXT@ @BIND9_MAKE_RULES@ t_db@EXEEXT@: t_db.@O@ ${DEPLIBS} ${TLIB} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_db.@O@ ${TLIB} ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_db.@O@ ${TLIB} ${LIBS} test: t_db@EXEEXT@ -@./t_db@EXEEXT@ -c @top_srcdir@/t_config -b @srcdir@ -a diff --git a/dist/bind/bin/tests/dst/Ktest.+001+00002.key b/dist/bind/bin/tests/dst/Ktest.+001+00002.key index 7a5ec2fabe5..a8b4b4d6a4d 100644 --- a/dist/bind/bin/tests/dst/Ktest.+001+00002.key +++ b/dist/bind/bin/tests/dst/Ktest.+001+00002.key @@ -1 +1 @@ -test. IN KEY 49152 2 1 +test. IN DNSKEY 49152 2 1 diff --git a/dist/bind/bin/tests/dst/Ktest.+001+54622.key b/dist/bind/bin/tests/dst/Ktest.+001+54622.key index 2d000cfc104..b0277e3381c 100644 --- a/dist/bind/bin/tests/dst/Ktest.+001+54622.key +++ b/dist/bind/bin/tests/dst/Ktest.+001+54622.key @@ -1 +1 @@ -test. IN KEY 257 3 1 AQPQjwSpaVzxIgRCpiUoozUQKGh2oX8NIFKDOvtxK+tn536OZg2cROKTlgGEHXJK9YHfW/6nzQULTVpb63P+SQMmjCCidb8IYyhItixRztVeJQ== +test. IN DNSKEY 257 3 1 AQPQjwSpaVzxIgRCpiUoozUQKGh2oX8NIFKDOvtxK+tn536OZg2cROKTlgGEHXJK9YHfW/6nzQULTVpb63P+SQMmjCCidb8IYyhItixRztVeJQ== diff --git a/dist/bind/bin/tests/dst/Ktest.+003+23616.key b/dist/bind/bin/tests/dst/Ktest.+003+23616.key index 44ad296d10b..958d5857fe3 100644 --- a/dist/bind/bin/tests/dst/Ktest.+003+23616.key +++ b/dist/bind/bin/tests/dst/Ktest.+003+23616.key @@ -1 +1 @@ -test. IN KEY 16641 3 3 ANp1//lqDlEfTavcFI+cyudNfgEz73V/K7fSDvkA0eDYcGg/kSvEjAEO/oLWCERltkuC55ZcM/mSv17WF1d/wR6kww/pLI9eXwkjftAYqs5sNxk+mbEGl6zwve9wq5z7IoTY5/J4l7XLCKftg/wGvrzXQhggIkRvEh3myhxd+ouILcpfvTIthWlTKiH59tSJpmgmiSMTE7nDYaf10iVRWN6DMSprgejiH05/fpmyZAt44tyAh4m1wXS5u4tam1PXDJYJozn7EfQ8e2weIv1yC+t6PHSx +test. IN DNSKEY 16641 3 3 ANp1//lqDlEfTavcFI+cyudNfgEz73V/K7fSDvkA0eDYcGg/kSvEjAEO/oLWCERltkuC55ZcM/mSv17WF1d/wR6kww/pLI9eXwkjftAYqs5sNxk+mbEGl6zwve9wq5z7IoTY5/J4l7XLCKftg/wGvrzXQhggIkRvEh3myhxd+ouILcpfvTIthWlTKiH59tSJpmgmiSMTE7nDYaf10iVRWN6DMSprgejiH05/fpmyZAt44tyAh4m1wXS5u4tam1PXDJYJozn7EfQ8e2weIv1yC+t6PHSx diff --git a/dist/bind/bin/tests/dst/Ktest.+003+49667.key b/dist/bind/bin/tests/dst/Ktest.+003+49667.key index 18ab1475eb8..fb73f570d51 100644 --- a/dist/bind/bin/tests/dst/Ktest.+003+49667.key +++ b/dist/bind/bin/tests/dst/Ktest.+003+49667.key @@ -1 +1 @@ -test. IN KEY 49152 2 3 +test. IN DNSKEY 49152 2 3 diff --git a/dist/bind/bin/tests/dst/Makefile.in b/dist/bind/bin/tests/dst/Makefile.in index 26cd5d8566e..889f03014f4 100644 --- a/dist/bind/bin/tests/dst/Makefile.in +++ b/dist/bind/bin/tests/dst/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.30.12.6 2004/03/08 04:04:29 marka Exp +# Id: Makefile.in,v 1.30.12.7 2004/07/20 07:01:51 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -45,10 +45,10 @@ SRCS = dst_test.c t_dst.c @BIND9_MAKE_RULES@ dst_test@EXEEXT@: dst_test.@O@ ${DEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ dst_test.@O@ ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ dst_test.@O@ ${LIBS} t_dst@EXEEXT@: t_dst.@O@ ${DEPLIBS} ${TLIB} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_dst.@O@ ${TLIB} ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_dst.@O@ ${TLIB} ${LIBS} test: t_dst@EXEEXT@ ../genrandom@EXEEXT@ 100 randomfile diff --git a/dist/bind/bin/tests/dst/dst_test.c b/dist/bind/bin/tests/dst/dst_test.c index 6b070ea42cf..bee280c2070 100644 --- a/dist/bind/bin/tests/dst/dst_test.c +++ b/dist/bind/bin/tests/dst/dst_test.c @@ -1,4 +1,4 @@ -/* $NetBSD: dst_test.c,v 1.1.1.1 2004/05/17 23:43:28 christos Exp $ */ +/* $NetBSD: dst_test.c,v 1.1.1.2 2004/11/06 23:53:40 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: dst_test.c,v 1.37.206.1 2004/03/06 10:21:43 marka Exp */ +/* Id: dst_test.c,v 1.37.206.2 2004/06/11 00:30:52 marka Exp */ #include <config.h> @@ -162,7 +162,7 @@ dh(dns_name_t *name1, int id1, dns_name_t *name2, int id2, isc_mem_t *mctx) { isc_region_t r1, r2; unsigned char array1[1024], array2[1024]; int alg = DST_ALG_DH; - int type = DST_TYPE_PUBLIC|DST_TYPE_PRIVATE; + int type = DST_TYPE_PUBLIC|DST_TYPE_PRIVATE|DST_TYPE_KEY; ret = dst_key_fromfile(name1, id1, alg, type, current, mctx, &key1); printf("read(%d) returned: %s\n", alg, isc_result_totext(ret)); diff --git a/dist/bind/bin/tests/dst/t_dst.c b/dist/bind/bin/tests/dst/t_dst.c index 4580c05a025..4ea80ebcf08 100644 --- a/dist/bind/bin/tests/dst/t_dst.c +++ b/dist/bind/bin/tests/dst/t_dst.c @@ -1,4 +1,4 @@ -/* $NetBSD: t_dst.c,v 1.1.1.1 2004/05/17 23:43:28 christos Exp $ */ +/* $NetBSD: t_dst.c,v 1.1.1.2 2004/11/06 23:53:40 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: t_dst.c,v 1.47.206.1 2004/03/06 10:21:43 marka Exp */ +/* Id: t_dst.c,v 1.47.206.2 2004/06/11 00:30:52 marka Exp */ #include <config.h> @@ -170,7 +170,7 @@ dh(dns_name_t *name1, int id1, dns_name_t *name2, int id2, isc_mem_t *mctx, char tmp[PATH_MAX + 1]; char *p; int alg = DST_ALG_DH; - int type = DST_TYPE_PUBLIC|DST_TYPE_PRIVATE; + int type = DST_TYPE_PUBLIC|DST_TYPE_PRIVATE|DST_TYPE_KEY; unsigned char array1[1024], array2[1024]; isc_buffer_t b1, b2; isc_region_t r1, r2; diff --git a/dist/bind/bin/tests/master/Makefile.in b/dist/bind/bin/tests/master/Makefile.in index 8ac8b83cf05..286f09ab6d1 100644 --- a/dist/bind/bin/tests/master/Makefile.in +++ b/dist/bind/bin/tests/master/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.20.12.6 2004/03/08 04:04:29 marka Exp +# Id: Makefile.in,v 1.20.12.7 2004/07/20 07:01:51 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -46,7 +46,7 @@ SRCS = t_master.c @BIND9_MAKE_RULES@ t_master@EXEEXT@: t_master.@O@ ${DEPLIBS} ${TLIB} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_master.@O@ ${TLIB} ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_master.@O@ ${TLIB} ${LIBS} test: t_master@EXEEXT@ -@ ./t_master@EXEEXT@ -c @top_srcdir@/t_config -b @srcdir@ -a diff --git a/dist/bind/bin/tests/mem/Makefile.in b/dist/bind/bin/tests/mem/Makefile.in index 4e6cfbd502a..591c9365b75 100644 --- a/dist/bind/bin/tests/mem/Makefile.in +++ b/dist/bind/bin/tests/mem/Makefile.in @@ -13,7 +13,7 @@ # 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.6 2004/03/08 09:04:16 marka Exp +# Id: Makefile.in,v 1.25.12.7 2004/07/20 07:01:51 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -43,7 +43,7 @@ SRCS = t_mem.c @BIND9_MAKE_RULES@ t_mem@EXEEXT@: t_mem.@O@ ${DEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_mem.@O@ ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_mem.@O@ ${LIBS} test: t_mem@EXEEXT@ -@./t_mem@EXEEXT@ -b @srcdir@ -q 300 -a diff --git a/dist/bind/bin/tests/names/Makefile.in b/dist/bind/bin/tests/names/Makefile.in index 36aae31868e..18f9bb3d4f7 100644 --- a/dist/bind/bin/tests/names/Makefile.in +++ b/dist/bind/bin/tests/names/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.20.12.6 2004/03/08 04:04:30 marka Exp +# Id: Makefile.in,v 1.20.12.7 2004/07/20 07:01:52 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -46,7 +46,7 @@ SRCS = t_names.c @BIND9_MAKE_RULES@ t_names@EXEEXT@: t_names.@O@ ${DEPLIBS} ${TLIB} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_names.@O@ ${TLIB} ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_names.@O@ ${TLIB} ${LIBS} test: t_names@EXEEXT@ -@./t_names@EXEEXT@ -c @top_srcdir@/t_config -b @srcdir@ -a diff --git a/dist/bind/bin/tests/net/Makefile.in b/dist/bind/bin/tests/net/Makefile.in index 0ae8e005d27..c07f5f6d924 100644 --- a/dist/bind/bin/tests/net/Makefile.in +++ b/dist/bind/bin/tests/net/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.9.12.5 2004/03/08 04:04:30 marka Exp +# Id: Makefile.in,v 1.9.12.6 2004/07/20 07:01:52 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -43,7 +43,7 @@ OBJS = driver.@O@ netaddr_multicast.@O@ sockaddr_multicast.@O@ @BIND9_MAKE_RULES@ t_net@EXEEXT@: ${OBJS} ${DEPLIBS} ${TLIB} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ ${OBJS} ${TLIB} ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ ${OBJS} ${TLIB} ${LIBS} test: t_net@EXEEXT@ -@./t_net@EXEEXT@ diff --git a/dist/bind/bin/tests/nsecify.c b/dist/bind/bin/tests/nsecify.c index 422998c18af..66e5007b1a0 100644 --- a/dist/bind/bin/tests/nsecify.c +++ b/dist/bind/bin/tests/nsecify.c @@ -1,4 +1,4 @@ -/* $NetBSD: nsecify.c,v 1.1.1.1 2004/05/17 23:43:27 christos Exp $ */ +/* $NetBSD: nsecify.c,v 1.1.1.2 2004/11/06 23:53:39 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,13 +17,14 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: nsecify.c,v 1.3.2.1 2004/03/08 02:07:41 marka Exp */ +/* Id: nsecify.c,v 1.3.2.2 2004/08/28 06:25:30 marka Exp */ #include <config.h> #include <stdlib.h> #include <isc/mem.h> +#include <isc/print.h> #include <isc/string.h> #include <dns/db.h> diff --git a/dist/bind/bin/tests/rbt/Makefile.in b/dist/bind/bin/tests/rbt/Makefile.in index fa643896325..2e485dd8ffa 100644 --- a/dist/bind/bin/tests/rbt/Makefile.in +++ b/dist/bind/bin/tests/rbt/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.20.12.6 2004/03/08 04:04:31 marka Exp +# Id: Makefile.in,v 1.20.12.7 2004/07/20 07:01:52 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -46,7 +46,7 @@ SRCS = t_rbt.c @BIND9_MAKE_RULES@ t_rbt@EXEEXT@: t_rbt.@O@ ${DEPLIBS} ${TLIB} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_rbt.@O@ ${TLIB} ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_rbt.@O@ ${TLIB} ${LIBS} test: t_rbt@EXEEXT@ -@./t_rbt@EXEEXT@ -c @top_srcdir@/t_config -b @srcdir@ -a diff --git a/dist/bind/bin/tests/rwlock_test.c b/dist/bind/bin/tests/rwlock_test.c index 87887c01c80..7eba349499d 100644 --- a/dist/bind/bin/tests/rwlock_test.c +++ b/dist/bind/bin/tests/rwlock_test.c @@ -1,4 +1,4 @@ -/* $NetBSD: rwlock_test.c,v 1.1.1.1 2004/05/17 23:43:27 christos Exp $ */ +/* $NetBSD: rwlock_test.c,v 1.1.1.2 2004/11/06 23:53:39 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: rwlock_test.c,v 1.20.206.1 2004/03/06 10:21:40 marka Exp */ +/* Id: rwlock_test.c,v 1.20.206.2 2004/08/28 06:25:31 marka Exp */ #include <config.h> @@ -25,6 +25,7 @@ #include <stdlib.h> #include <unistd.h> +#include <isc/print.h> #include <isc/thread.h> #include <isc/rwlock.h> #include <isc/string.h> diff --git a/dist/bind/bin/tests/shutdown_test.c b/dist/bind/bin/tests/shutdown_test.c index cc53d695b5a..2c0624f9538 100644 --- a/dist/bind/bin/tests/shutdown_test.c +++ b/dist/bind/bin/tests/shutdown_test.c @@ -1,4 +1,4 @@ -/* $NetBSD: shutdown_test.c,v 1.1.1.1 2004/05/17 23:43:27 christos Exp $ */ +/* $NetBSD: shutdown_test.c,v 1.1.1.2 2004/11/06 23:53:39 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: shutdown_test.c,v 1.18.12.4 2004/03/08 04:04:27 marka Exp */ +/* Id: shutdown_test.c,v 1.18.12.5 2004/08/28 06:25:31 marka Exp */ #include <config.h> @@ -26,6 +26,7 @@ #include <isc/app.h> #include <isc/mem.h> +#include <isc/print.h> #include <isc/task.h> #include <isc/time.h> #include <isc/timer.h> diff --git a/dist/bind/bin/tests/sock_test.c b/dist/bind/bin/tests/sock_test.c index cebfcb16f1d..5c3588ff6a9 100644 --- a/dist/bind/bin/tests/sock_test.c +++ b/dist/bind/bin/tests/sock_test.c @@ -1,4 +1,4 @@ -/* $NetBSD: sock_test.c,v 1.1.1.1 2004/05/17 23:43:27 christos Exp $ */ +/* $NetBSD: sock_test.c,v 1.1.1.2 2004/11/06 23:53:40 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: sock_test.c,v 1.47.12.3 2004/03/08 04:04:27 marka Exp */ +/* Id: sock_test.c,v 1.47.12.4 2004/08/28 06:25:32 marka Exp */ #include <config.h> @@ -26,6 +26,7 @@ #include <unistd.h> #include <isc/mem.h> +#include <isc/print.h> #include <isc/task.h> #include <isc/socket.h> #include <isc/timer.h> diff --git a/dist/bind/bin/tests/sockaddr/Makefile.in b/dist/bind/bin/tests/sockaddr/Makefile.in index 236a981ee29..b19be6a7a97 100644 --- a/dist/bind/bin/tests/sockaddr/Makefile.in +++ b/dist/bind/bin/tests/sockaddr/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.14.12.6 2004/03/08 09:04:16 marka Exp +# Id: Makefile.in,v 1.14.12.7 2004/07/20 07:01:53 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -43,7 +43,7 @@ SRCS = t_sockaddr.c @BIND9_MAKE_RULES@ t_sockaddr@EXEEXT@: t_sockaddr.@O@ ${DEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_sockaddr.@O@ ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_sockaddr.@O@ ${LIBS} test: t_sockaddr@EXEEXT@ -@./t_sockaddr@EXEEXT@ -b @srcdir@ -a diff --git a/dist/bind/bin/tests/system/dlv/clean.sh b/dist/bind/bin/tests/system/dlv/clean.sh new file mode 100644 index 00000000000..72c9ae829be --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/clean.sh @@ -0,0 +1,27 @@ +#!/bin/sh +# +# 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: clean.sh,v 1.2.4.1 2004/05/14 05:20:32 marka Exp + +rm -f random.data +rm -f ns*/named.run +rm -f ns3/K* +rm -f ns3/*.db +rm -f ns3/*.signed +rm -f ns3/dlvset-* +rm -f ns3/dsset-* +rm -f ns3/keyset-* +rm -f ns3/trusted.conf ns5/trusted.conf diff --git a/dist/bind/bin/tests/system/dlv/ns1/named.conf b/dist/bind/bin/tests/system/dlv/ns1/named.conf new file mode 100644 index 00000000000..4ddfd27233f --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns1/named.conf @@ -0,0 +1,35 @@ +/* + * 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,v 1.2.4.1 2004/05/14 05:20:35 marka Exp */ + +controls { /* empty */ }; + +options { + query-source address 10.53.0.1; + notify-source 10.53.0.1; + transfer-source 10.53.0.1; + port 5300; + pid-file "named.pid"; + listen-on { 10.53.0.1; }; + listen-on-v6 { none; }; + recursion no; + notify yes; + dnssec-enable no; +}; + +zone "." { type master; file "root.db"; }; +zone "rootservers.utld" { type master; file "rootservers.utld.db"; }; diff --git a/dist/bind/bin/tests/system/dlv/ns1/root.db b/dist/bind/bin/tests/system/dlv/ns1/root.db new file mode 100644 index 00000000000..9759428e694 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns1/root.db @@ -0,0 +1,24 @@ +; 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: root.db,v 1.2.4.1 2004/05/14 05:20:36 marka Exp + +$TTL 120 +@ SOA ns.rootservers.utld hostmaster.ns.rootservers.utld ( + 1 3600 1200 604800 60 ) +@ NS ns.rootservers.utld +ns A 10.53.0.1 +; +utld NS ns.utld +ns.utld A 10.53.0.2 diff --git a/dist/bind/bin/tests/system/dlv/ns1/rootservers.utld.db b/dist/bind/bin/tests/system/dlv/ns1/rootservers.utld.db new file mode 100644 index 00000000000..b609c6093a5 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns1/rootservers.utld.db @@ -0,0 +1,20 @@ +; 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: rootservers.utld.db,v 1.2.4.1 2004/05/14 05:20:38 marka Exp + +$TTL 120 +@ SOA ns hostmaster.ns 1 3600 1200 604800 60 +@ NS ns +ns A 10.53.0.1 diff --git a/dist/bind/bin/tests/system/dlv/ns2/hints b/dist/bind/bin/tests/system/dlv/ns2/hints new file mode 100644 index 00000000000..4031e25fb76 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns2/hints @@ -0,0 +1,18 @@ +; 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: hints,v 1.2.4.1 2004/05/14 05:20:39 marka Exp + +. 0 NS ns.rootservers.utld. +ns.rootservers.utld. 0 A 10.53.0.1 diff --git a/dist/bind/bin/tests/system/dlv/ns2/named.conf b/dist/bind/bin/tests/system/dlv/ns2/named.conf new file mode 100644 index 00000000000..9733b0c7fb4 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns2/named.conf @@ -0,0 +1,35 @@ +/* + * 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,v 1.2.4.1 2004/05/14 05:20:40 marka Exp */ + +controls { /* empty */ }; + +options { + query-source address 10.53.0.2; + notify-source 10.53.0.2; + transfer-source 10.53.0.2; + port 5300; + pid-file "named.pid"; + listen-on { 10.53.0.2; }; + listen-on-v6 { none; }; + recursion no; + notify yes; + dnssec-enable no; +}; + +zone "." { type hint; file "hints"; }; +zone "utld" { type master; file "utld.db"; }; diff --git a/dist/bind/bin/tests/system/dlv/ns2/utld.db b/dist/bind/bin/tests/system/dlv/ns2/utld.db new file mode 100644 index 00000000000..4bb71ef0c34 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns2/utld.db @@ -0,0 +1,56 @@ +; 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: utld.db,v 1.2.4.1 2004/05/14 05:20:41 marka Exp + +$TTL 120 +@ SOA ns hostmaster.ns 1 3600 1200 604800 60 +@ NS ns +ns A 10.53.0.2 +; +rootservers NS ns.rootservers +ns.rootservers A 10.53.0.1 +; +dlv NS ns.dlv +ns.dlv A 10.53.0.3 +; +child1 NS ns.child1 +ns.child1 A 10.53.0.3 +; +child2 NS ns.child2 +ns.child2 A 10.53.0.4 +; +child3 NS ns.child3 +ns.child3 A 10.53.0.3 +; +child4 NS ns.child4 +ns.child4 A 10.53.0.3 +; +child5 NS ns.child5 +ns.child5 A 10.53.0.3 +; +child6 NS ns.child6 +ns.child6 A 10.53.0.4 +; +child7 NS ns.child7 +ns.child7 A 10.53.0.3 +; +child8 NS ns.child8 +ns.child8 A 10.53.0.3 +; +child9 NS ns.child9 +ns.child9 A 10.53.0.3 +; +child10 NS ns.child10 +ns.child10 A 10.53.0.3 diff --git a/dist/bind/bin/tests/system/dlv/ns3/child.db.in b/dist/bind/bin/tests/system/dlv/ns3/child.db.in new file mode 100644 index 00000000000..69f87c12372 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns3/child.db.in @@ -0,0 +1,22 @@ +; 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: child.db.in,v 1.2.4.1 2004/05/14 05:20:42 marka Exp + +$TTL 120 +@ SOA ns hostmaster.ns 1 3600 1200 604800 60 +@ NS ns +ns A 10.53.0.3 +foo TXT foo +bar TXT bar diff --git a/dist/bind/bin/tests/system/dlv/ns3/dlv.db.in b/dist/bind/bin/tests/system/dlv/ns3/dlv.db.in new file mode 100644 index 00000000000..e54d7737b42 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns3/dlv.db.in @@ -0,0 +1,20 @@ +; 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: dlv.db.in,v 1.2.4.1 2004/05/14 05:20:42 marka Exp + +$TTL 120 +@ SOA ns hostmaster.ns 1 3600 1200 604800 60 +@ NS ns +ns A 10.53.0.3 diff --git a/dist/bind/bin/tests/system/dlv/ns3/hints b/dist/bind/bin/tests/system/dlv/ns3/hints new file mode 100644 index 00000000000..b7d30c38570 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns3/hints @@ -0,0 +1,18 @@ +; 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: hints,v 1.2.4.1 2004/05/14 05:20:43 marka Exp + +. 0 NS ns.rootservers.utld. +ns.rootservers.utld. 0 A 10.53.0.1 diff --git a/dist/bind/bin/tests/system/dlv/ns3/named.conf b/dist/bind/bin/tests/system/dlv/ns3/named.conf new file mode 100644 index 00000000000..d52f61aa79b --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns3/named.conf @@ -0,0 +1,43 @@ +/* + * 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,v 1.2.4.1 2004/05/14 05:20:44 marka Exp */ + +controls { /* empty */ }; + +options { + query-source address 10.53.0.3; + notify-source 10.53.0.3; + transfer-source 10.53.0.3; + port 5300; + pid-file "named.pid"; + listen-on { 10.53.0.3; }; + listen-on-v6 { none; }; + recursion no; + notify yes; + dnssec-enable yes; +}; + +zone "." { type hint; file "hints"; }; +zone "dlv.utld" { type master; file "dlv.signed"; }; +zone "child1.utld" { type master; file "child1.signed"; }; // dlv +zone "child3.utld" { type master; file "child3.signed"; }; // dlv +zone "child4.utld" { type master; file "child4.signed"; }; // dlv +zone "child5.utld" { type master; file "child5.signed"; }; // dlv +zone "child7.utld" { type master; file "child7.signed"; }; // no dlv +zone "child8.utld" { type master; file "child8.signed"; }; // no dlv +zone "child9.utld" { type master; file "child9.signed"; }; // dlv +zone "child10.utld" { type master; file "child.db.in"; }; // dlv unsigned diff --git a/dist/bind/bin/tests/system/dlv/ns3/sign.sh b/dist/bind/bin/tests/system/dlv/ns3/sign.sh new file mode 100644 index 00000000000..6739b2611d3 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns3/sign.sh @@ -0,0 +1,174 @@ +#!/bin/sh +# +# 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: sign.sh,v 1.2.4.1 2004/05/14 05:20:45 marka Exp + +SYSTEMTESTTOP=../.. +. $SYSTEMTESTTOP/conf.sh + +RANDFILE=../random.data +dlvsets= + +zone=child1.utld. +infile=child.db.in +zonefile=child1.utld.db +outfile=child1.signed +dlvzone=dlv.utld. +dlvsets="$dlvsets dlvset-$zone" + +keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone` +keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone` + +cat $infile $keyname1.key $keyname2.key >$zonefile + +$SIGNER -g -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null +echo "I: signed $zone" + + +zone=child3.utld. +infile=child.db.in +zonefile=child3.utld.db +outfile=child3.signed +dlvzone=dlv.utld. +dlvsets="$dlvsets dlvset-$zone" + +keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone` +keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone` + +cat $infile $keyname1.key $keyname2.key >$zonefile + +$SIGNER -g -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null +echo "I: signed $zone" + + +zone=child4.utld. +infile=child.db.in +zonefile=child4.utld.db +outfile=child4.signed +dlvzone=dlv.utld. +dlvsets="$dlvsets dlvset-$zone" + +keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone` +keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone` + +cat $infile $keyname1.key $keyname2.key >$zonefile + +$SIGNER -g -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null +echo "I: signed $zone" + + +zone=child5.utld. +infile=child.db.in +zonefile=child5.utld.db +outfile=child5.signed +dlvzone=dlv.utld. +dlvsets="$dlvsets dlvset-$zone" + +keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone` +keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone` + +cat $infile $keyname1.key $keyname2.key >$zonefile + +$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null +echo "I: signed $zone" + + +zone=child7.utld. +infile=child.db.in +zonefile=child7.utld.db +outfile=child7.signed +dlvzone=dlv.utld. + +keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone` +keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone` + +cat $infile $keyname1.key $keyname2.key >$zonefile + +$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null +echo "I: signed $zone" + + +zone=child8.utld. +infile=child.db.in +zonefile=child8.utld.db +outfile=child8.signed +dlvzone=dlv.utld. + +keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone` +keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone` + +cat $infile $keyname1.key $keyname2.key >$zonefile + +$SIGNER -g -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null +echo "I: signed $zone" + + +zone=child9.utld. +infile=child.db.in +zonefile=child9.utld.db +outfile=child9.signed +dlvzone=dlv.utld. +dlvsets="$dlvsets dlvset-$zone" + +keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone` +keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone` + +cat $infile $keyname1.key $keyname2.key >$zonefile + +$SIGNER -g -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null +echo "I: signed $zone" + +zone=child10.utld. +infile=child.db.in +zonefile=child10.utld.db +outfile=child10.signed +dlvzone=dlv.utld. +dlvsets="$dlvsets dlvset-$zone" + +keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone` +keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone` + +cat $infile $keyname1.key $keyname2.key >$zonefile + +$SIGNER -g -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null +echo "I: signed $zone" + + +zone=dlv.utld. +infile=dlv.db.in +zonefile=dlv.utld.db +outfile=dlv.signed +dlvzone=dlv.utld. + +keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone` +keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone` + +cat $infile $dlvsets $keyname1.key $keyname2.key >$zonefile + +$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null +echo "I: signed $zone" + + +cat $keyname2.key | $PERL -n -e ' +local ($dn, $class, $type, $flags, $proto, $alg, @rest) = split; +local $key = join("", @rest); +print <<EOF +trusted-keys { + "$dn" $flags $proto $alg "$key"; +}; +EOF +' > trusted.conf +cp trusted.conf ../ns5 diff --git a/dist/bind/bin/tests/system/dlv/ns4/child.db b/dist/bind/bin/tests/system/dlv/ns4/child.db new file mode 100644 index 00000000000..0d7f2b7421b --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns4/child.db @@ -0,0 +1,41 @@ +; 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: child.db,v 1.2.4.1 2004/05/14 05:20:46 marka Exp + +$TTL 120 +@ SOA ns hostmaster.ns 1 3600 1200 604800 60 +@ NS ns +ns A 10.53.0.3 +; +rootservers NS ns.rootservers +ns.rootservers A 10.53.0.1 +; +child1 NS ns.child1 +ns.child1 A 10.53.0.3 +; +child2 NS ns.child2 +ns.child2 A 10.53.0.4 +; +child3 NS ns.child3 +ns.child3 A 10.53.0.3 +; +child4 NS ns.child4 +ns.child4 A 10.53.0.3 +; +child5 NS ns.child5 +ns.child5 A 10.53.0.3 +; +child6 NS ns.child5 +ns.child6 A 10.53.0.4 diff --git a/dist/bind/bin/tests/system/dlv/ns4/hints b/dist/bind/bin/tests/system/dlv/ns4/hints new file mode 100644 index 00000000000..1345d016a5a --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns4/hints @@ -0,0 +1,18 @@ +; 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: hints,v 1.2.4.1 2004/05/14 05:20:47 marka Exp + +. 0 NS ns.rootservers.utld. +ns.rootservers.utld. 0 A 10.53.0.1 diff --git a/dist/bind/bin/tests/system/dlv/ns4/named.conf b/dist/bind/bin/tests/system/dlv/ns4/named.conf new file mode 100644 index 00000000000..91ee3eeb0a3 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns4/named.conf @@ -0,0 +1,36 @@ +/* + * 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,v 1.2.4.1 2004/05/14 05:20:47 marka Exp */ + +controls { /* empty */ }; + +options { + query-source address 10.53.0.4; + notify-source 10.53.0.4; + transfer-source 10.53.0.4; + port 5300; + pid-file "named.pid"; + listen-on { 10.53.0.4; }; + listen-on-v6 { none; }; + recursion no; + notify yes; + dnssec-enable no; +}; + +zone "." { type hint; file "hints"; }; +zone "child2.utld" { type master; file "child.db"; }; +zone "child6.utld" { type master; file "child.db"; }; diff --git a/dist/bind/bin/tests/system/dlv/ns5/hints b/dist/bind/bin/tests/system/dlv/ns5/hints new file mode 100644 index 00000000000..f9f4e58191b --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns5/hints @@ -0,0 +1,18 @@ +; 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: hints,v 1.2.4.1 2004/05/14 05:20:49 marka Exp + +. 0 NS ns.rootservers.utld. +ns.rootservers.utld. 0 A 10.53.0.1 diff --git a/dist/bind/bin/tests/system/dlv/ns5/named.conf b/dist/bind/bin/tests/system/dlv/ns5/named.conf new file mode 100644 index 00000000000..2f6e4091753 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns5/named.conf @@ -0,0 +1,64 @@ +/* + * 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,v 1.2.4.2 2004/06/04 02:32:56 marka Exp */ + +/* + * Choose a keyname that is unlikely to clash with any real key names. + * This allows it to be added to the system's rndc.conf with minimal + * likelyhood of collision. + * + * e.g. + * key "cc64b3d1db63fc88d7cb5d2f9f57d258" { + * algorithm hmac-md5; + * secret "34f88008d07deabbe65bd01f1d233d47"; + * }; + * + * server "10.53.0.5" { + * key cc64b3d1db63fc88d7cb5d2f9f57d258; + * port 5353; + * }; + * + * rndc -s 10.53.0.5 <command> + */ + +key "cc64b3d1db63fc88d7cb5d2f9f57d258" { + algorithm hmac-md5; + secret "34f88008d07deabbe65bd01f1d233d47"; +}; + +controls { + inet 10.53.0.5 port 5353 allow { any; } + keys { cc64b3d1db63fc88d7cb5d2f9f57d258; }; +}; + +include "trusted.conf"; + +options { + query-source address 10.53.0.5; + notify-source 10.53.0.5; + transfer-source 10.53.0.5; + port 5300; + pid-file "named.pid"; + listen-on { 10.53.0.5; }; + listen-on-v6 { none; }; + recursion yes; + notify yes; + dnssec-enable yes; + dnssec-lookaside "." trust-anchor "dlv.utld"; +}; + +zone "." { type hint; file "hints"; }; diff --git a/dist/bind/bin/tests/system/dlv/ns5/rndc.conf b/dist/bind/bin/tests/system/dlv/ns5/rndc.conf new file mode 100644 index 00000000000..22a1df2e482 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/ns5/rndc.conf @@ -0,0 +1,27 @@ +/* + * 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: rndc.conf,v 1.2.4.2 2004/08/19 04:40:58 marka Exp */ + +key "cc64b3d1db63fc88d7cb5d2f9f57d258" { + algorithm hmac-md5; + secret "34f88008d07deabbe65bd01f1d233d47"; +}; + +options { + default-server 10.53.0.5; + default-port 5353; +}; diff --git a/dist/bind/bin/tests/system/dlv/setup.sh b/dist/bind/bin/tests/system/dlv/setup.sh new file mode 100644 index 00000000000..1ca69bc2374 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/setup.sh @@ -0,0 +1,21 @@ +#!/bin/sh +# +# 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: setup.sh,v 1.2.4.1 2004/05/14 05:20:33 marka Exp + +../../genrandom 400 random.data + +(cd ns3 && sh -e sign.sh) diff --git a/dist/bind/bin/tests/system/dlv/tests.sh b/dist/bind/bin/tests/system/dlv/tests.sh new file mode 100644 index 00000000000..df8bf271583 --- /dev/null +++ b/dist/bind/bin/tests/system/dlv/tests.sh @@ -0,0 +1,19 @@ +#!/bin/sh +# +# 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: tests.sh,v 1.2.4.1 2004/05/14 05:20:34 marka Exp + +exit 0 diff --git a/dist/bind/bin/tests/system/dnssec/ns2/dlv.db.in b/dist/bind/bin/tests/system/dnssec/ns2/dlv.db.in index 94c2052c318..9c95de9847c 100644 --- a/dist/bind/bin/tests/system/dnssec/ns2/dlv.db.in +++ b/dist/bind/bin/tests/system/dnssec/ns2/dlv.db.in @@ -1,19 +1,18 @@ -; Copyright (C) 2000-2002 Internet Software Consortium. +; 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 INTERNET SOFTWARE CONSORTIUM -; DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL -; IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL -; INTERNET SOFTWARE CONSORTIUM 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. +; 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: dlv.db.in,v 1.1.4.1 2004/03/15 02:56:04 marka Exp +; Id: dlv.db.in,v 1.1.4.2 2004/08/19 04:41:06 marka Exp $TTL 300 ; 5 minutes @ IN SOA mname1. . ( diff --git a/dist/bind/bin/tests/system/dnssec/ns2/example.db.in b/dist/bind/bin/tests/system/dnssec/ns2/example.db.in index ba645ef9d17..07ed062ed13 100644 --- a/dist/bind/bin/tests/system/dnssec/ns2/example.db.in +++ b/dist/bind/bin/tests/system/dnssec/ns2/example.db.in @@ -13,7 +13,7 @@ ; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR ; PERFORMANCE OF THIS SOFTWARE. -; Id: example.db.in,v 1.8.12.4 2004/04/15 23:56:23 marka Exp +; Id: example.db.in,v 1.8.12.5 2004/05/05 01:32:15 marka Exp $TTL 300 ; 5 minutes @ IN SOA mname1. . ( @@ -70,6 +70,10 @@ dynamic A 10.53.0.3 mustbesecure NS ns.mustbesecure ns.mustbesecure A 10.53.0.3 +; A rfc2535 signed zone w/ CNAME +rfc2535 NS ns.rfc2535 +ns.rfc2535 A 10.53.0.3 + z A 10.0.0.26 keyless NS ns.keyless diff --git a/dist/bind/bin/tests/system/dnssec/ns2/named.conf b/dist/bind/bin/tests/system/dnssec/ns2/named.conf index 5b0119cc8e9..71f963ed181 100644 --- a/dist/bind/bin/tests/system/dnssec/ns2/named.conf +++ b/dist/bind/bin/tests/system/dnssec/ns2/named.conf @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: named.conf,v 1.17.12.5 2004/03/10 02:55:54 marka Exp */ +/* Id: named.conf,v 1.17.12.6 2004/05/05 01:32:15 marka Exp */ // NS2 @@ -62,4 +62,10 @@ zone "insecure.secure.example" { allow-update { any; }; }; +zone "rfc2335.example" { + type master; + file "rfc2335.example.db"; +}; + + include "trusted.conf"; diff --git a/dist/bind/bin/tests/system/dnssec/ns2/rfc2335.example.db b/dist/bind/bin/tests/system/dnssec/ns2/rfc2335.example.db new file mode 100644 index 00000000000..b8b477ea847 --- /dev/null +++ b/dist/bind/bin/tests/system/dnssec/ns2/rfc2335.example.db @@ -0,0 +1,103 @@ +; File written on Fri Apr 30 12:19:15 2004 +; dnssec_signzone version 9.2.4rc3 +rfc2335.example. 300 IN SOA mname1. . ( + 2000042407 ; serial + 20 ; refresh (20 seconds) + 20 ; retry (20 seconds) + 1814400 ; expire (3 weeks) + 3600 ; minimum (1 hour) + ) + 300 SIG SOA 1 2 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + nGPJKIzF7X/hMJbZURRz59UeEi/6HRxCn9Er + GqSnpw0Ea9Yx5Axu6sLKnF7jXlkZ6NHMCIpJ + +Lv+FDHXTs/dQg== ) + 300 NS ns.rfc2335.example. + 300 SIG NS 1 2 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + Q234AL9dJYMvxdWG33lpww6AJ3GplKp+ace7 + MUaj0oqDdkx4DtJF2XaP2xcqq7kTOObdQ8ES + vVxNThqOx7LFzg== ) + 300 KEY 256 3 1 ( + AQPZhzXIabI8y5ihWUw7F0WxN2MabnYWkOcV + Fn11NgaGSdjBSYPRMMwMCasD5N2KYPRUP83W + y8mj+ofcoW1FurcZ + ) ; key id = 47799 + 300 NXT a.rfc2335.example. NS SOA SIG KEY NXT + 300 SIG NXT 1 2 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + Y587mqNy6pBEfbsU6+weM2XRSqLwLwRT9Sl7 + oNuOK9kV3TR4R2M54m2S0MgJCXbRAwU+fF8Q + UbZkSTVe2N8Nyg== ) +a.rfc2335.example. 300 IN A 10.0.0.1 + 300 SIG A 1 3 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + FnfWrcw5ire8ut25504zti5l///BdDMUAkJZ + UCLFiTW4lBGMcq1pqz64zltDZXCgJ3xUeQ2i + nRt19/ZxO6Z1KA== ) + 300 NXT b.rfc2335.example. A SIG NXT + 300 SIG NXT 1 3 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + R6SpC3ndMVg4u/eZaaUsXSuMHV/hZXeaM/Op + bJLAe3KxMiOHfb6XgLy7wflAiC1xt6A9bWpy + kTc5T5gfic33kA== ) +b.rfc2335.example. 300 IN A 10.0.0.2 + 300 SIG A 1 3 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + zjRsYXMGyhDI6ipDtu8YXC9XPN+3hGamzzxL + 8uPE/LPo+x19MNdbzEgWzlajAf1/mkSGr2jN + BDMVBA5NMKpwAA== ) + 300 NXT d.rfc2335.example. A SIG NXT + 300 SIG NXT 1 3 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + aV87iZCYsC5Tqop827Zzb18TNqopGt0QynkR + gIF/lIHqZasNFRfaS1/nTnXdDKD8JS5IqxKb + oTJr5zswDAtCEw== ) +d.rfc2335.example. 300 IN A 10.0.0.4 + 300 SIG A 1 3 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + NsKyvhUYZxTbOTBX4YwxTxevI5iGBpULKwmt + +D4l00ME4XRygOVmiqVDTT9dF1EgjDxOdfMT + hSjtCh5M1b2f6g== ) + 300 NXT ns.rfc2335.example. A SIG NXT + 300 SIG NXT 1 3 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + OGqlvSDZIZdHYigh4UAFzXfPze7vcQfgj7sN + +cAeoh4BL1gpa00DqANCxowNCYluDk3ZCDwt + UHZEJa8ZjNvv4g== ) +ns.rfc2335.example. 300 IN A 10.53.0.3 + 300 SIG A 1 3 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + T6ZGeUWflLTku8jO23x/TeAPeUl8t0I18FCh + qHUZaHomLQasQ2jlZQn6cLpFd2uFJkBNxZ0G + I39aG7G1bObXdA== ) + 300 NXT x.rfc2335.example. A SIG NXT + 300 SIG NXT 1 3 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + l46mrf3/Ii5iRm3AiDjYeMg4ZXBgitHxXA2y + e/NhKpkxRRpCs7UQ94wT/RiSCjjK49E5FBe6 + 5bRxtWq0GI7zlg== ) +x.rfc2335.example. 300 IN CNAME a.rfc2335.example. + 300 SIG CNAME 1 3 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + L3IOluq+kboBd2gR2Mu54uJKCUzfmyHRiWKl + kfx+vuFr0I8mEHQRmJtouxNDrBzmzGp5vybK + SdabLWw0n6uQEA== ) + 300 NXT z.rfc2335.example. CNAME SIG NXT + 300 SIG NXT 1 3 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + CBKoJSkZzdpwiON7JS4yPFY5VVeBjfT19x/O + vx+5UK1JZUNKhTXWWgW1er+JlLzNf4Ot40+l + z9HUTyaeS0eWyw== ) +z.rfc2335.example. 300 IN A 10.0.0.26 + 300 SIG A 1 3 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + ccqjVHnehvVwlNNd4+7n/GzGlRjj+ul0gCT3 + X3950LTccxHsOFyjNNm8v/Ho/aurSYdqXEjY + jwmjC6elwkzB7A== ) + 300 NXT rfc2335.example. A SIG NXT + 300 SIG NXT 1 3 300 20040530021915 ( + 20040430021915 47799 rfc2335.example. + W42WoFyd9erysv8HjKo+CpHIH1x6+pAKwCDO + /hHnkEpQI3brewxl7cWOPYeA92Ns80Ody/ui + m2E28A5gnmWqPw== ) diff --git a/dist/bind/bin/tests/system/dnssec/ns3/named.conf b/dist/bind/bin/tests/system/dnssec/ns3/named.conf index 5beeec158ea..51a932bcdc1 100644 --- a/dist/bind/bin/tests/system/dnssec/ns3/named.conf +++ b/dist/bind/bin/tests/system/dnssec/ns3/named.conf @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: named.conf,v 1.18.12.6 2004/04/15 23:56:26 marka Exp */ +/* Id: named.conf,v 1.18.12.7 2004/05/05 01:32:16 marka Exp */ // NS3 @@ -79,4 +79,10 @@ zone "mustbesecure.example" { file "mustbesecure.example.db"; }; +zone "rfc2335.example" { + type slave; + masters { 10.53.0.2; }; + file "rfc2335.example.bk"; +}; + include "trusted.conf"; diff --git a/dist/bind/bin/tests/system/dnssec/ns6/named.conf b/dist/bind/bin/tests/system/dnssec/ns6/named.conf index 24bb9585996..c50d6ad49cf 100644 --- a/dist/bind/bin/tests/system/dnssec/ns6/named.conf +++ b/dist/bind/bin/tests/system/dnssec/ns6/named.conf @@ -14,7 +14,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: named.conf,v 1.5.2.2 2004/03/10 02:55:55 marka Exp */ +/* Id: named.conf,v 1.5.2.3 2004/06/04 02:32:57 marka Exp */ // NS6 @@ -32,7 +32,7 @@ options { notify yes; disable-algorithms . { DSA; }; dnssec-enable yes; - dnssec-lookaside dlv; + dnssec-lookaside . trust-anchor dlv; }; zone "." { diff --git a/dist/bind/bin/tests/system/dnssec/tests.sh b/dist/bind/bin/tests/system/dnssec/tests.sh index d6e753e3c6c..be3cc6916da 100644 --- a/dist/bind/bin/tests/system/dnssec/tests.sh +++ b/dist/bind/bin/tests/system/dnssec/tests.sh @@ -15,7 +15,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: tests.sh,v 1.33.12.4 2004/03/10 02:55:53 marka Exp +# Id: tests.sh,v 1.33.12.6 2004/05/18 03:06:24 marka Exp SYSTEMTESTTOP=.. . $SYSTEMTESTTOP/conf.sh @@ -441,11 +441,32 @@ n=`expr $n + 1` if [ $ret != 0 ]; then echo "I:failed"; fi status=`expr $status + $ret` -echo "I:checking dnssec-lookaside-validation works ($n)" +#echo "I:checking dnssec-lookaside-validation works ($n)" +#ret=0 +#$DIG $DIGOPTS private.secure.example. SOA @10.53.0.6 \ +# > dig.out.ns6.test$n || ret=1 +#grep "flags:.*ad.*QUERY" dig.out.ns6.test$n > /dev/null || ret=1 +#n=`expr $n + 1` +#if [ $ret != 0 ]; then echo "I:failed"; fi +#status=`expr $status + $ret` + +echo "I:checking that we can load a rfc2535 signed zone ($n)" ret=0 -$DIG $DIGOPTS private.secure.example. SOA @10.53.0.6 \ - > dig.out.ns6.test$n || ret=1 -grep "flags:.*ad.*QUERY" dig.out.ns6.test$n > /dev/null || ret=1 +$DIG $DIGOPTS rfc2535.example. SOA @10.53.0.2 \ + > dig.out.ns2.test$n || ret=1 +grep "status: NOERROR" dig.out.ns2.test$n > /dev/null || ret=1 +n=`expr $n + 1` +if [ $ret != 0 ]; then echo "I:failed"; fi +status=`expr $status + $ret` + +echo "I:checking that we can transfer a rfc2535 signed zone ($n)" +ret=0 +$DIG $DIGOPTS rfc2535.example. SOA @10.53.0.3 \ + > dig.out.ns3.test$n || ret=1 +grep "status: NOERROR" dig.out.ns3.test$n > /dev/null || ret=1 +n=`expr $n + 1` +if [ $ret != 0 ]; then echo "I:failed"; fi +status=`expr $status + $ret` # Run a minimal update test if possible. This is really just # a regression test for RT #2399; more tests should be added. diff --git a/dist/bind/bin/tests/system/lwresd/Makefile.in b/dist/bind/bin/tests/system/lwresd/Makefile.in index 9c39448e849..b0f943772b3 100644 --- a/dist/bind/bin/tests/system/lwresd/Makefile.in +++ b/dist/bind/bin/tests/system/lwresd/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.12.12.5 2004/03/08 04:04:37 marka Exp +# Id: Makefile.in,v 1.12.12.6 2004/07/20 07:01:53 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -49,7 +49,7 @@ SRCS = lwtest.c all: lwtest@EXEEXT@ lwtest@EXEEXT@: ${OBJS} ${DEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ ${OBJS} ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ ${OBJS} ${LIBS} clean distclean:: rm -f ${TARGETS} diff --git a/dist/bind/bin/tests/system/tkey/Makefile.in b/dist/bind/bin/tests/system/tkey/Makefile.in index 6a5845e48c5..55039955197 100644 --- a/dist/bind/bin/tests/system/tkey/Makefile.in +++ b/dist/bind/bin/tests/system/tkey/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.3.12.6 2004/03/08 09:04:17 marka Exp +# Id: Makefile.in,v 1.3.12.7 2004/07/20 07:01:54 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -50,10 +50,10 @@ SRCS = keycreate.c keydelete.c all: keycreate@EXEEXT@ keydelete@EXEEXT@ keycreate@EXEEXT@: ${CREATEOBJS} ${DEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ ${CREATEOBJS} ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ ${CREATEOBJS} ${LIBS} keydelete@EXEEXT@: ${DELETEOBJS} ${DEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ ${DELETEOBJS} ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ ${DELETEOBJS} ${LIBS} clean distclean:: rm -f ${TARGETS} diff --git a/dist/bind/bin/tests/system/tkey/keycreate.c b/dist/bind/bin/tests/system/tkey/keycreate.c index c58494d54d5..b21537e23f5 100644 --- a/dist/bind/bin/tests/system/tkey/keycreate.c +++ b/dist/bind/bin/tests/system/tkey/keycreate.c @@ -1,4 +1,4 @@ -/* $NetBSD: keycreate.c,v 1.1.1.1 2004/05/17 23:43:37 christos Exp $ */ +/* $NetBSD: keycreate.c,v 1.1.1.2 2004/11/06 23:53:52 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: keycreate.c,v 1.7.12.4 2004/03/08 09:04:17 marka Exp */ +/* Id: keycreate.c,v 1.7.12.5 2004/06/11 00:30:53 marka Exp */ #include <config.h> @@ -77,6 +77,7 @@ recvquery(isc_task_t *task, isc_event_t *event) { dns_message_t *query, *response; char keyname[256]; isc_buffer_t keynamebuf; + int type; UNUSED(task); @@ -117,8 +118,8 @@ recvquery(isc_task_t *task, isc_event_t *event) { CHECK("dst_key_buildfilename", result); printf("%.*s\n", (int)isc_buffer_usedlength(&keynamebuf), (char *)isc_buffer_base(&keynamebuf)); - result = dst_key_tofile(tsigkey->key, - DST_TYPE_PRIVATE | DST_TYPE_PUBLIC, ""); + type = DST_TYPE_PRIVATE | DST_TYPE_PUBLIC | DST_TYPE_KEY; + result = dst_key_tofile(tsigkey->key, type, ""); CHECK("dst_key_tofile", result); dns_message_destroy(&query); @@ -211,6 +212,7 @@ main(int argc, char *argv[]) { isc_logconfig_t *logconfig; isc_task_t *task; isc_result_t result; + int type; RUNCHECK(isc_app_start()); @@ -282,9 +284,8 @@ main(int argc, char *argv[]) { RUNCHECK(isc_app_onrun(mctx, task, sendquery, NULL)); ourkey = NULL; - result = dst_key_fromnamedfile(ourkeyname, - DST_TYPE_PUBLIC | DST_TYPE_PRIVATE, - mctx, &ourkey); + type = DST_TYPE_PUBLIC | DST_TYPE_PRIVATE | DST_TYPE_KEY; + result = dst_key_fromnamedfile(ourkeyname, type, mctx, &ourkey); CHECK("dst_key_fromnamedfile", result); isc_buffer_init(&nonce, noncedata, sizeof(noncedata)); diff --git a/dist/bind/bin/tests/system/tkey/keydelete.c b/dist/bind/bin/tests/system/tkey/keydelete.c index 00052017c9d..42cc6db9487 100644 --- a/dist/bind/bin/tests/system/tkey/keydelete.c +++ b/dist/bind/bin/tests/system/tkey/keydelete.c @@ -1,4 +1,4 @@ -/* $NetBSD: keydelete.c,v 1.1.1.1 2004/05/17 23:43:37 christos Exp $ */ +/* $NetBSD: keydelete.c,v 1.1.1.2 2004/11/06 23:53:52 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: keydelete.c,v 1.4.206.2 2004/03/08 02:07:49 marka Exp */ +/* Id: keydelete.c,v 1.4.206.3 2004/06/11 00:30:53 marka Exp */ #include <config.h> @@ -156,6 +156,7 @@ main(int argc, char **argv) { isc_logconfig_t *logconfig; isc_task_t *task; isc_result_t result; + int type; RUNCHECK(isc_app_start()); @@ -224,9 +225,8 @@ main(int argc, char **argv) { RUNCHECK(isc_app_onrun(mctx, task, sendquery, NULL)); dstkey = NULL; - result = dst_key_fromnamedfile(keyname, - DST_TYPE_PUBLIC | DST_TYPE_PRIVATE, - mctx, &dstkey); + type = DST_TYPE_PUBLIC | DST_TYPE_PRIVATE | DST_TYPE_KEY; + result = dst_key_fromnamedfile(keyname, type, mctx, &dstkey); CHECK("dst_key_fromnamedfile", result); result = dns_tsigkey_createfromkey(dst_key_name(dstkey), DNS_TSIG_HMACMD5_NAME, diff --git a/dist/bind/bin/tests/system/tkey/ns1/setup.sh b/dist/bind/bin/tests/system/tkey/ns1/setup.sh index a135ddcaa21..06c35eb9d25 100644 --- a/dist/bind/bin/tests/system/tkey/ns1/setup.sh +++ b/dist/bind/bin/tests/system/tkey/ns1/setup.sh @@ -15,11 +15,11 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: setup.sh,v 1.2.2.2.10.1 2004/03/06 10:22:35 marka Exp +# Id: setup.sh,v 1.2.2.2.10.2 2004/06/11 00:30:54 marka Exp RANDFILE=../random.data -keyname=`$KEYGEN -a DH -b 768 -n host -r $RANDFILE server` +keyname=`$KEYGEN -k -a DH -b 768 -n host -r $RANDFILE server` keyid=`echo $keyname | $PERL -p -e 's/^.*\+0*//;'` rm -f named.conf perl -p -e "s/KEYID/$keyid/;" < named.conf.in > named.conf diff --git a/dist/bind/bin/tests/system/tkey/tests.sh b/dist/bind/bin/tests/system/tkey/tests.sh index 180e66f48e3..7750c26ece0 100644 --- a/dist/bind/bin/tests/system/tkey/tests.sh +++ b/dist/bind/bin/tests/system/tkey/tests.sh @@ -15,7 +15,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: tests.sh,v 1.2.12.3 2004/03/08 09:04:17 marka Exp +# Id: tests.sh,v 1.2.12.4 2004/06/11 00:30:53 marka Exp SYSTEMTESTTOP=.. . $SYSTEMTESTTOP/conf.sh @@ -28,7 +28,7 @@ RANDFILE=random.data echo "I:generating new DH key" ret=0 -dhkeyname=`$KEYGEN -a DH -b 768 -n host -r $RANDFILE client` || ret=1 +dhkeyname=`$KEYGEN -k -a DH -b 768 -n host -r $RANDFILE client` || ret=1 if [ $ret != 0 ]; then echo "I:failed" echo "I:exit status: $status" diff --git a/dist/bind/bin/tests/tasks/Makefile.in b/dist/bind/bin/tests/tasks/Makefile.in index 46bf8a9db66..f58f3d0ea21 100644 --- a/dist/bind/bin/tests/tasks/Makefile.in +++ b/dist/bind/bin/tests/tasks/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.23.12.5 2004/03/08 09:04:20 marka Exp +# Id: Makefile.in,v 1.23.12.6 2004/07/20 07:01:54 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -43,7 +43,7 @@ SRCS = t_tasks.c @BIND9_MAKE_RULES@ t_tasks@EXEEXT@: t_tasks.@O@ ${DEPLIBS} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_tasks.@O@ ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_tasks.@O@ ${LIBS} test: t_tasks@EXEEXT@ -@./t_tasks@EXEEXT@ -c @top_srcdir@/t_config -b @srcdir@ -a diff --git a/dist/bind/bin/tests/tasks/t_tasks.c b/dist/bind/bin/tests/tasks/t_tasks.c index 202d7d1ffa3..e7d90b630c2 100644 --- a/dist/bind/bin/tests/tasks/t_tasks.c +++ b/dist/bind/bin/tests/tasks/t_tasks.c @@ -1,4 +1,4 @@ -/* $NetBSD: t_tasks.c,v 1.1.1.1 2004/05/17 23:43:38 christos Exp $ */ +/* $NetBSD: t_tasks.c,v 1.1.1.2 2004/11/06 23:54:09 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: t_tasks.c,v 1.29.12.4 2004/03/08 09:04:20 marka Exp */ +/* Id: t_tasks.c,v 1.29.12.5 2004/06/21 06:57:59 marka Exp */ #include <config.h> @@ -43,7 +43,7 @@ isc_boolean_t threaded = ISC_FALSE; static void require_threads(void) { t_info("This test requires threads\n"); - t_result(T_UNTESTED); + t_result(T_THREADONLY); return; } diff --git a/dist/bind/bin/tests/timers/Makefile.in b/dist/bind/bin/tests/timers/Makefile.in index 0812ae76763..5a87e10a06c 100644 --- a/dist/bind/bin/tests/timers/Makefile.in +++ b/dist/bind/bin/tests/timers/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.21.12.5 2004/03/08 09:04:20 marka Exp +# Id: Makefile.in,v 1.21.12.6 2004/07/20 07:01:54 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -43,7 +43,7 @@ SRCS = t_timers.c @BIND9_MAKE_RULES@ t_timers@EXEEXT@: t_timers.@O@ ${DEPLIBS} ${TLIB} - ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_timers.@O@ ${TLIB} ${LIBS} + ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_timers.@O@ ${TLIB} ${LIBS} test: t_timers@EXEEXT@ -@./t_timers@EXEEXT@ -c @top_srcdir@/t_config -b @srcdir@ -q 60 -a diff --git a/dist/bind/bin/tests/timers/t_timers.c b/dist/bind/bin/tests/timers/t_timers.c index 816fb64ec79..3549ac5c13d 100644 --- a/dist/bind/bin/tests/timers/t_timers.c +++ b/dist/bind/bin/tests/timers/t_timers.c @@ -1,4 +1,4 @@ -/* $NetBSD: t_timers.c,v 1.1.1.1 2004/05/17 23:43:38 christos Exp $ */ +/* $NetBSD: t_timers.c,v 1.1.1.2 2004/11/06 23:54:09 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: t_timers.c,v 1.22.206.1 2004/03/06 10:22:52 marka Exp */ +/* Id: t_timers.c,v 1.22.206.2 2004/06/21 06:57:59 marka Exp */ #include <config.h> @@ -57,7 +57,7 @@ static int Tx_nanoseconds; static void require_threads(void) { t_info("This test requires threads\n"); - t_result(T_UNTESTED); + t_result(T_THREADONLY); return; } diff --git a/dist/bind/bin/win32/BINDInstall/BINDInstallDlg.cpp b/dist/bind/bin/win32/BINDInstall/BINDInstallDlg.cpp index 814594e9b4d..8bfc5dd1aab 100644 --- a/dist/bind/bin/win32/BINDInstall/BINDInstallDlg.cpp +++ b/dist/bind/bin/win32/BINDInstall/BINDInstallDlg.cpp @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: BINDInstallDlg.cpp,v 1.6.2.6.2.7 2004/04/19 06:39:55 marka Exp */ +/* Id: BINDInstallDlg.cpp,v 1.6.2.6.2.10 2004/05/18 01:20:04 marka Exp */ /* * Copyright (c) 1999-2000 by Nortel Networks Corporation @@ -113,7 +113,10 @@ const FileData installFiles[] = {"msvcrt.dll", FileData::WinSystem, FileData::Critical, TRUE}, # endif #endif -#if _MSC_VER > 1200 +#if _MSC_VER >= 1310 + {"mfc71.dll", FileData::WinSystem, FileData::Critical, TRUE}, + {"msvcr71.dll", FileData::WinSystem, FileData::Critical, TRUE}, +#elif _MSC_VER > 1200 {"mfc70.dll", FileData::WinSystem, FileData::Critical, TRUE}, {"msvcr70.dll", FileData::WinSystem, FileData::Critical, TRUE}, #endif @@ -134,8 +137,6 @@ const FileData installFiles[] = {"nslookup.exe", FileData::BinDir, FileData::Normal, FALSE}, {"rndc-confgen.exe", FileData::BinDir, FileData::Normal, FALSE}, {"dnssec-keygen.exe", FileData::BinDir, FileData::Normal, FALSE}, - {"dnssec-makekeyset.exe", FileData::BinDir, FileData::Normal, FALSE}, - {"dnssec-signkey.exe", FileData::BinDir, FileData::Normal, FALSE}, {"dnssec-signzone.exe", FileData::BinDir, FileData::Normal, FALSE}, {"named-checkconf.exe", FileData::BinDir, FileData::Normal, FALSE}, {"named-checkzone.exe", FileData::BinDir, FileData::Normal, FALSE}, diff --git a/dist/bind/config.h.in b/dist/bind/config.h.in index 37a27a0556c..eb2d755e07f 100644 --- a/dist/bind/config.h.in +++ b/dist/bind/config.h.in @@ -16,7 +16,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: config.h.in,v 1.47.2.3.2.9 2004/03/14 23:55:14 marka Exp */ +/* Id: config.h.in,v 1.47.2.3.2.11 2004/09/01 07:18:30 marka Exp */ /*** *** This file is not to be included by any public header files, because @@ -137,6 +137,9 @@ int sigwait(const unsigned int *set, int *sig); /* Define if you are running under Compaq TruCluster.. */ #undef HAVE_TRUCLUSTER +/* Define if OpenSSL includes DSA support */ +#undef HAVE_OPENSSL_DSA + /* Define to 1 if you have the <dlfcn.h> header file. */ #undef HAVE_DLFCN_H @@ -158,6 +161,9 @@ int sigwait(const unsigned int *set, int *sig); /* Define to 1 if you have the `pthread' library (-lpthread). */ #undef HAVE_LIBPTHREAD +/* Define to 1 if you have the `scf' library (-lscf). */ +#undef HAVE_LIBSCF + /* Define to 1 if you have the `socket' library (-lsocket). */ #undef HAVE_LIBSOCKET diff --git a/dist/bind/configure b/dist/bind/configure index 698fe063e2e..f81ba95717d 100644 --- a/dist/bind/configure +++ b/dist/bind/configure @@ -14,7 +14,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. # -# Id: configure,v 1.284.2.19.2.19 2004/03/14 00:00:31 marka Exp +# Id: configure,v 1.284.2.19.2.26 2004/09/01 07:18:30 marka Exp # # Portions Copyright (C) 1996-2001 Nominum, Inc. # @@ -29,7 +29,7 @@ # 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. -# From configure.in Revision: 1.294.2.23.2.23 . +# From configure.in Revision: 1.294.2.23.2.30 . # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.59. # @@ -495,7 +495,7 @@ ac_includes_default="\ # include <unistd.h> #endif" -ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS subdirs build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_HAVELONGLONG ISC_PLATFORM_HAVELIFCONF ISC_PLATFORM_NEEDSYSSELECTH LWRES_PLATFORM_NEEDSYSSELECTH USE_OPENSSL DST_OPENSSL_INC USE_GSSAPI DST_GSSAPI_INC DNS_CRYPTO_LIBS ALWAYS_DEFINES ISC_PLATFORM_USETHREADS ISC_THREAD_DIR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK LIBBIND ISC_PLATFORM_HAVEIPV6 LWRES_PLATFORM_HAVEIPV6 ISC_PLATFORM_NEEDNETINETIN6H LWRES_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H LWRES_PLATFORM_NEEDNETINET6IN6H ISC_PLATFORM_HAVEINADDR6 LWRES_PLATFORM_HAVEINADDR6 ISC_PLATFORM_NEEDIN6ADDRANY LWRES_PLATFORM_NEEDIN6ADDRANY ISC_PLATFORM_NEEDIN6ADDRLOOPBACK LWRES_PLATFORM_NEEDIN6ADDRLOOPBACK ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C LWRES_HAVE_SIN6_SCOPE_ID ISC_PLATFORM_HAVESCOPEID ISC_PLATFORM_HAVEIF_LADDRREQ ISC_PLATFORM_HAVEIF_LADDRCONF ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON ISC_PLATFORM_HAVESALEN LWRES_PLATFORM_HAVESALEN ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_NEEDADDRINFO ISC_LWRES_NEEDRRSETINFO ISC_LWRES_SETHOSTENTINT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_GETNETBYADDRINADDR ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDMEMMOVE ISC_PLATFORM_NEEDSTRTOUL ISC_PLATFORM_NEEDSTRLCPY ISC_PLATFORM_NEEDSTRLCAT ISC_PLATFORM_NEEDSPRINTF ISC_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS ISC_PLATFORM_QUADFORMAT ISC_PLATFORM_RLIMITTYPE ISC_PLATFORM_USEDECLSPEC LWRES_PLATFORM_USEDECLSPEC ISC_PLATFORM_BRACEPTHREADONCEINIT ISC_PLATFORM_HAVEIFNAMETOINDEX OPENJADE JADETEX PDFJADETEX SGMLCATALOG HTMLSTYLE PRINTSTYLE XMLDCL DOCBOOK2MANSPEC BIND9_TOP_BUILDDIR BIND9_ISC_BUILDINCLUDE BIND9_ISCCC_BUILDINCLUDE BIND9_ISCCFG_BUILDINCLUDE BIND9_DNS_BUILDINCLUDE BIND9_LWRES_BUILDINCLUDE BIND9_BIND9_BUILDINCLUDE BIND9_VERSION LIBOBJS LTLIBOBJS' +ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS subdirs build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_HAVELONGLONG ISC_PLATFORM_HAVELIFCONF ISC_PLATFORM_NEEDSYSSELECTH LWRES_PLATFORM_NEEDSYSSELECTH USE_OPENSSL DST_OPENSSL_INC USE_GSSAPI DST_GSSAPI_INC DNS_CRYPTO_LIBS ALWAYS_DEFINES ISC_PLATFORM_USETHREADS ISC_THREAD_DIR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK LIBBIND ISC_PLATFORM_HAVEIPV6 LWRES_PLATFORM_HAVEIPV6 ISC_PLATFORM_NEEDNETINETIN6H LWRES_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H LWRES_PLATFORM_NEEDNETINET6IN6H ISC_PLATFORM_HAVEINADDR6 LWRES_PLATFORM_HAVEINADDR6 ISC_PLATFORM_NEEDIN6ADDRANY LWRES_PLATFORM_NEEDIN6ADDRANY ISC_PLATFORM_NEEDIN6ADDRLOOPBACK LWRES_PLATFORM_NEEDIN6ADDRLOOPBACK ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C LWRES_HAVE_SIN6_SCOPE_ID ISC_PLATFORM_HAVESCOPEID ISC_PLATFORM_HAVEIF_LADDRREQ ISC_PLATFORM_HAVEIF_LADDRCONF ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON ISC_PLATFORM_HAVESALEN LWRES_PLATFORM_HAVESALEN ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_NEEDADDRINFO ISC_LWRES_NEEDRRSETINFO ISC_LWRES_SETHOSTENTINT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_GETNETBYADDRINADDR ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDMEMMOVE ISC_PLATFORM_NEEDSTRTOUL ISC_PLATFORM_NEEDSTRLCPY ISC_PLATFORM_NEEDSTRLCAT ISC_PLATFORM_NEEDSPRINTF LWRES_PLATFORM_NEEDSPRINTF ISC_PLATFORM_NEEDVSNPRINTF LWRES_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS ISC_PLATFORM_QUADFORMAT ISC_PLATFORM_RLIMITTYPE ISC_PLATFORM_USEDECLSPEC LWRES_PLATFORM_USEDECLSPEC ISC_PLATFORM_BRACEPTHREADONCEINIT ISC_PLATFORM_HAVEIFNAMETOINDEX OPENJADE JADETEX PDFJADETEX SGMLCATALOG HTMLSTYLE PRINTSTYLE XMLDCL DOCBOOK2MANSPEC BIND9_TOP_BUILDDIR BIND9_ISC_BUILDINCLUDE BIND9_ISCCC_BUILDINCLUDE BIND9_ISCCFG_BUILDINCLUDE BIND9_DNS_BUILDINCLUDE BIND9_LWRES_BUILDINCLUDE BIND9_BIND9_BUILDINCLUDE BIND9_VERSION LIBOBJS LTLIBOBJS' ac_subst_files='BIND9_MAKE_INCLUDES BIND9_MAKE_RULES LIBISC_API LIBISCCC_API LIBISCCFG_API LIBDNS_API LIBBIND9_API LIBLWRES_API' # Initialize some variables set by options. @@ -4621,7 +4621,7 @@ if test "${with_openssl+set}" = set; then withval="$with_openssl" use_openssl="$withval" else - use_openssl="no" + use_openssl="auto" fi; case "$use_openssl" in @@ -4632,7 +4632,7 @@ echo "${ECHO_T}no" >&6 USE_OPENSSL="" ;; *) - if test "$use_openssl" = "yes" + 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" @@ -4651,18 +4651,31 @@ echo "${ECHO_T}not found" >&6 { { echo "$as_me:$LINENO: error: OpenSSL was not found in any of $openssldirs; use --with-openssl=/path" >&5 echo "$as_me: error: OpenSSL was not found in any of $openssldirs; use --with-openssl=/path" >&2;} { (exit 1); exit 1; }; } + elif test "$use_openssl" = "auto" + then + DST_OPENSSL_INC="" + USE_OPENSSL="" + echo "$as_me:$LINENO: result: not found" >&5 +echo "${ECHO_T}not found" >&6 + break fi fi USE_OPENSSL='-DOPENSSL' - 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 + 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 echo "$as_me:$LINENO: result: using openssl from $use_openssl/lib and $use_openssl/include" >&5 echo "${ECHO_T}using openssl from $use_openssl/lib and $use_openssl/include" >&6 @@ -5040,6 +5053,20 @@ rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftes fi fi + echo "$as_me:$LINENO: checking for OpenSSL DSA support" >&5 +echo $ECHO_N "checking for OpenSSL DSA support... $ECHO_C" >&6 + if test -f $use_openssl/include/openssl/dsa.h + then + cat >>confdefs.h <<\_ACEOF +#define HAVE_OPENSSL_DSA 1 +_ACEOF + + echo "$as_me:$LINENO: result: yes" >&5 +echo "${ECHO_T}yes" >&6 + else + echo "$as_me:$LINENO: result: no" >&5 +echo "${ECHO_T}no" >&6 + fi CFLAGS="$saved_cflags" LIBS="$saved_libs" ;; @@ -6606,6 +6633,84 @@ ISC_THREAD_DIR=$thread_dir # +# In solaris 10, SMF can manage named service +# + +echo "$as_me:$LINENO: checking for smf_enable_instance in -lscf" >&5 +echo $ECHO_N "checking for smf_enable_instance in -lscf... $ECHO_C" >&6 +if test "${ac_cv_lib_scf_smf_enable_instance+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + ac_check_lib_save_LIBS=$LIBS +LIBS="-lscf $LIBS" +cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ + +/* Override any gcc2 internal prototype to avoid an error. */ +#ifdef __cplusplus +extern "C" +#endif +/* We use char because int might match the return type of a gcc2 + builtin and then its argument prototype would still apply. */ +char smf_enable_instance (); +int +main () +{ +smf_enable_instance (); + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext conftest$ac_exeext +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 + (eval $ac_link) 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; } && + { ac_try='test -s conftest$ac_exeext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_cv_lib_scf_smf_enable_instance=yes +else + echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + +ac_cv_lib_scf_smf_enable_instance=no +fi +rm -f conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext +LIBS=$ac_check_lib_save_LIBS +fi +echo "$as_me:$LINENO: result: $ac_cv_lib_scf_smf_enable_instance" >&5 +echo "${ECHO_T}$ac_cv_lib_scf_smf_enable_instance" >&6 +if test $ac_cv_lib_scf_smf_enable_instance = yes; then + cat >>confdefs.h <<_ACEOF +#define HAVE_LIBSCF 1 +_ACEOF + + LIBS="-lscf $LIBS" + +fi + + +# # 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. @@ -7815,7 +7920,7 @@ ia64-*-hpux*) ;; *-*-irix6*) # Find out which ABI we are using. - echo '#line 7818 "configure"' > conftest.$ac_ext + echo '#line 7923 "configure"' > conftest.$ac_ext if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 (eval $ac_compile) 2>&5 ac_status=$? @@ -8805,7 +8910,7 @@ fi # Provide some information about the compiler. -echo "$as_me:8808:" \ +echo "$as_me:8913:" \ "checking for Fortran 77 compiler version" >&5 ac_compiler=`set X $ac_compile; echo $2` { (eval echo "$as_me:$LINENO: \"$ac_compiler --version </dev/null >&5\"") >&5 @@ -9843,11 +9948,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:9846: $lt_compile\"" >&5) + (eval echo "\"\$as_me:9951: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:9850: \$? = $ac_status" >&5 + echo "$as_me:9955: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -10076,11 +10181,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:10079: $lt_compile\"" >&5) + (eval echo "\"\$as_me:10184: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:10083: \$? = $ac_status" >&5 + echo "$as_me:10188: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -10136,11 +10241,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:10139: $lt_compile\"" >&5) + (eval echo "\"\$as_me:10244: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:10143: \$? = $ac_status" >&5 + echo "$as_me:10248: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -12320,7 +12425,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 12323 "configure" +#line 12428 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -12418,7 +12523,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 12421 "configure" +#line 12526 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -14601,11 +14706,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:14604: $lt_compile\"" >&5) + (eval echo "\"\$as_me:14709: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:14608: \$? = $ac_status" >&5 + echo "$as_me:14713: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -14661,11 +14766,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:14664: $lt_compile\"" >&5) + (eval echo "\"\$as_me:14769: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:14668: \$? = $ac_status" >&5 + echo "$as_me:14773: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -16022,7 +16127,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 16025 "configure" +#line 16130 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -16120,7 +16225,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 16123 "configure" +#line 16228 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -16947,11 +17052,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:16950: $lt_compile\"" >&5) + (eval echo "\"\$as_me:17055: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:16954: \$? = $ac_status" >&5 + echo "$as_me:17059: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -17007,11 +17112,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:17010: $lt_compile\"" >&5) + (eval echo "\"\$as_me:17115: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:17014: \$? = $ac_status" >&5 + echo "$as_me:17119: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -19045,11 +19150,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:19048: $lt_compile\"" >&5) + (eval echo "\"\$as_me:19153: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:19052: \$? = $ac_status" >&5 + echo "$as_me:19157: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -19278,11 +19383,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:19281: $lt_compile\"" >&5) + (eval echo "\"\$as_me:19386: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:19285: \$? = $ac_status" >&5 + echo "$as_me:19390: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -19338,11 +19443,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:19341: $lt_compile\"" >&5) + (eval echo "\"\$as_me:19446: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:19345: \$? = $ac_status" >&5 + echo "$as_me:19450: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -21522,7 +21627,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 21525 "configure" +#line 21630 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -21620,7 +21725,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 21623 "configure" +#line 21728 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -24603,7 +24708,7 @@ case $host in # 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 $use_getifaddrs = glibc + if test $use_getifaddrs = glibc then echo "$as_me:$LINENO: checking for getifaddrs" >&5 echo $ECHO_N "checking for getifaddrs... $ECHO_C" >&6 @@ -25426,17 +25531,20 @@ if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 ISC_PRINT_OBJS="print.$O" ISC_PRINT_SRCS="print.c" ISC_PLATFORM_NEEDSPRINTF="#define ISC_PLATFORM_NEEDSPRINTF" +LWRES_PLATFORM_NEEDSPRINTF="#define LWRES_PLATFORM_NEEDSPRINTF" else echo "$as_me: failed program was:" >&5 sed 's/^/| /' conftest.$ac_ext >&5 ISC_PLATFORM_NEEDSPRINTF="#undef ISC_PLATFORM_NEEDSPRINTF" + LWRES_PLATFORM_NEEDSPRINTF="#undef LWRES_PLATFORM_NEEDSPRINTF" fi rm -f conftest.err conftest.$ac_objext conftest.$ac_ext + echo "$as_me:$LINENO: checking for vsnprintf" >&5 echo $ECHO_N "checking for vsnprintf... $ECHO_C" >&6 if test "${ac_cv_func_vsnprintf+set}" = set; then @@ -25529,13 +25637,16 @@ echo "$as_me:$LINENO: result: $ac_cv_func_vsnprintf" >&5 echo "${ECHO_T}$ac_cv_func_vsnprintf" >&6 if test $ac_cv_func_vsnprintf = yes; then ISC_PLATFORM_NEEDVSNPRINTF="#undef ISC_PLATFORM_NEEDVSNPRINTF" + LWRES_PLATFORM_NEEDVSNPRINTF="#undef LWRES_PLATFORM_NEEDVSNPRINTF" else 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" fi + ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS $ISC_PRINT_OBJS" ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS $ISC_PRINT_SRCS" @@ -25640,12 +25751,15 @@ fi -# # Determine the printf format characters to use when printing -# values of type isc_int64_t. We make the assumption that platforms -# where a "long long" is the same size as a "long" (e.g., Alpha/OSF1) -# want "%ld" and everyone else can use "%lld". Win32 uses "%I64d", -# but that's defined elsewhere since we don't use configure on Win32. +# 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. # echo "$as_me:$LINENO: checking printf format modifier for 64-bit integers" >&5 echo $ECHO_N "checking printf format modifier for 64-bit integers... $ECHO_C" >&6 @@ -25660,7 +25774,17 @@ _ACEOF cat confdefs.h >>conftest.$ac_ext cat >>conftest.$ac_ext <<_ACEOF /* end confdefs.h. */ -main() { exit(!(sizeof(long long int) == sizeof(long int))); } + +#include <stdio.h> +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)); +} + _ACEOF rm -f conftest$ac_exeext if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 @@ -25673,18 +25797,18 @@ if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 ac_status=$? echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); }; }; then - echo "$as_me:$LINENO: result: l" >&5 -echo "${ECHO_T}l" >&6 - ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"' + echo "$as_me:$LINENO: result: ll" >&5 +echo "${ECHO_T}ll" >&6 + ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"' else echo "$as_me: program exited with status $ac_status" >&5 echo "$as_me: failed program was:" >&5 sed 's/^/| /' conftest.$ac_ext >&5 ( exit $ac_status ) -echo "$as_me:$LINENO: result: ll" >&5 -echo "${ECHO_T}ll" >&6 - ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"' +echo "$as_me:$LINENO: result: l" >&5 +echo "${ECHO_T}l" >&6 + ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"' fi rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftest.$ac_ext fi @@ -28048,7 +28172,9 @@ s,@ISC_PLATFORM_NEEDSTRTOUL@,$ISC_PLATFORM_NEEDSTRTOUL,;t t s,@ISC_PLATFORM_NEEDSTRLCPY@,$ISC_PLATFORM_NEEDSTRLCPY,;t t s,@ISC_PLATFORM_NEEDSTRLCAT@,$ISC_PLATFORM_NEEDSTRLCAT,;t t s,@ISC_PLATFORM_NEEDSPRINTF@,$ISC_PLATFORM_NEEDSPRINTF,;t t +s,@LWRES_PLATFORM_NEEDSPRINTF@,$LWRES_PLATFORM_NEEDSPRINTF,;t t s,@ISC_PLATFORM_NEEDVSNPRINTF@,$ISC_PLATFORM_NEEDVSNPRINTF,;t t +s,@LWRES_PLATFORM_NEEDVSNPRINTF@,$LWRES_PLATFORM_NEEDVSNPRINTF,;t t s,@ISC_EXTRA_OBJS@,$ISC_EXTRA_OBJS,;t t s,@ISC_EXTRA_SRCS@,$ISC_EXTRA_SRCS,;t t s,@ISC_PLATFORM_QUADFORMAT@,$ISC_PLATFORM_QUADFORMAT,;t t diff --git a/dist/bind/configure.in b/dist/bind/configure.in index c7926bc6cc0..8710d265a41 100644 --- a/dist/bind/configure.in +++ b/dist/bind/configure.in @@ -18,7 +18,7 @@ AC_DIVERT_PUSH(1)dnl esyscmd([sed "s/^/# /" COPYRIGHT])dnl AC_DIVERT_POP()dnl -AC_REVISION($Revision: 1.1.1.1 $) +AC_REVISION($Revision: 1.1.1.2 $) AC_INIT(lib/dns/name.c) AC_PREREQ(2.13) @@ -343,7 +343,7 @@ 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="no") + use_openssl="$withval", use_openssl="auto") case "$use_openssl" in no) @@ -352,7 +352,7 @@ case "$use_openssl" in USE_OPENSSL="" ;; *) - if test "$use_openssl" = "yes" + 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" @@ -369,18 +369,30 @@ case "$use_openssl" in 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' - 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 + 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" @@ -467,6 +479,14 @@ int main() { [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" ;; @@ -837,6 +857,11 @@ 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. @@ -1567,7 +1592,7 @@ case $host in # 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 $use_getifaddrs = glibc + if test $use_getifaddrs = glibc then AC_CHECK_FUNC(getifaddrs, AC_DEFINE(HAVE_GETIFADDRS)) else @@ -1655,17 +1680,23 @@ AC_TRY_COMPILE([ 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"] +[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"], + [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"]) + 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" @@ -1674,19 +1705,32 @@ 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. We make the assumption that platforms -# where a "long long" is the same size as a "long" (e.g., Alpha/OSF1) -# want "%ld" and everyone else can use "%lld". Win32 uses "%I64d", -# but that's defined elsewhere since we don't use configure on Win32. +# 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([main() { exit(!(sizeof(long long int) == sizeof(long int))); }], - [AC_MSG_RESULT(l) - ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'], +AC_TRY_RUN([ +#include <stdio.h> +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) diff --git a/dist/bind/contrib/idn/idnkit-1.0-src/lib/Makefile.in b/dist/bind/contrib/idn/idnkit-1.0-src/lib/Makefile.in index cc391862b79..8157404e729 100644 --- a/dist/bind/contrib/idn/idnkit-1.0-src/lib/Makefile.in +++ b/dist/bind/contrib/idn/idnkit-1.0-src/lib/Makefile.in @@ -1,4 +1,4 @@ -# Id: Makefile.in,v 1.1.1.1 2003/06/04 00:25:47 marka Exp +# Id: Makefile.in,v 1.1.1.1.32.1 2004/07/20 07:01:55 marka Exp # Copyright (c) 2000, 2002 Japan Network Information Center. # All rights reserved. # @@ -189,7 +189,7 @@ SAMPLES = idn.conf.sample idnalias.conf.sample $(LIBTOOL) --mode=compile $(CC) $(CFLAGS) -c $< .c.to: - $(CC) -o $@ -DTEST $(CFLAGS) -c $< + $(CC) -o $@ -DTEST $(CFLAGS) $(LDFLAGS) -c $< all: all-localdir all-subdirs @LITEONLY_TRUE@all-localdir: $(LITELIB).la $(SAMPLES) diff --git a/dist/bind/contrib/idn/idnkit-1.0-src/lib/tests/Makefile.in b/dist/bind/contrib/idn/idnkit-1.0-src/lib/tests/Makefile.in index 7777948d898..d30e0f34598 100644 --- a/dist/bind/contrib/idn/idnkit-1.0-src/lib/tests/Makefile.in +++ b/dist/bind/contrib/idn/idnkit-1.0-src/lib/tests/Makefile.in @@ -1,4 +1,4 @@ -# Id: Makefile.in,v 1.1.1.1 2003/06/04 00:26:46 marka Exp +# Id: Makefile.in,v 1.1.1.1.32.1 2004/07/20 07:01:55 marka Exp # Copyright (c) 2000, 2002 Japan Network Information Center. # All rights reserved. # @@ -300,5 +300,5 @@ testconfig.h: ../../include/config.h ../../include/config.h > testconfig.h iconvchk: iconvchk.c codeset.h - $(LIBTOOL) --mode=link $(CC) $(CFLAGS) -o $@ \ + $(LIBTOOL) --mode=link $(CC) $(CFLAGS) $(LDFLAGS) -o $@ \ $(srcdir)/iconvchk.c $(IDNLIB) $(ICONVLIB) diff --git a/dist/bind/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.3.0-patch b/dist/bind/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.3.0-patch index e94ce1bb806..342da9f8fb0 100644 --- a/dist/bind/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.3.0-patch +++ b/dist/bind/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.3.0-patch @@ -17,8 +17,8 @@ and install. Index: README.idnkit ---- /dev/null Thu Apr 29 13:00:41 2004 -+++ README.idnkit Thu Apr 29 12:56:35 2004 +--- /dev/null Wed Sep 1 17:46:18 2004 ++++ README.idnkit Wed Sep 1 17:36:14 2004 @@ -0,0 +1,113 @@ + + BIND-9 IDN patch @@ -136,18 +136,18 @@ Index: README.idnkit Index: config.h.in =================================================================== RCS file: /proj/cvs/prod/bind9/config.h.in,v -retrieving revision 1.47.2.3.2.9 -diff -U2 -r1.47.2.3.2.9 config.h.in ---- config.h.in 14 Mar 2004 23:55:14 -0000 1.47.2.3.2.9 -+++ config.h.in 29 Apr 2004 03:01:39 -0000 +retrieving revision 1.47.2.3.2.11 +diff -U2 -r1.47.2.3.2.11 config.h.in +--- config.h.in 1 Sep 2004 07:18:30 -0000 1.47.2.3.2.11 ++++ config.h.in 1 Sep 2004 07:47:48 -0000 @@ -17,5 +17,5 @@ */ --/* Id: config.h.in,v 1.47.2.3.2.9 2004/03/14 23:55:14 marka Exp */ -+/* Id: acconfig.h,v 1.35.2.4.2.7 2004/03/08 04:04:12 marka Exp */ +-/* Id: config.h.in,v 1.47.2.3.2.11 2004/09/01 07:18:30 marka Exp */ ++/* Id: acconfig.h,v 1.35.2.4.2.8 2004/05/21 08:24:04 marka Exp */ /*** -@@ -165,4 +165,7 @@ +@@ -171,4 +171,7 @@ #undef HAVE_LINUX_CAPABILITY_H +/* Define to 1 if you have the <locale.h> header file. */ @@ -155,7 +155,7 @@ diff -U2 -r1.47.2.3.2.9 config.h.in + /* Define to 1 if you have the <memory.h> header file. */ #undef HAVE_MEMORY_H -@@ -171,4 +174,7 @@ +@@ -177,4 +180,7 @@ #undef HAVE_NET_IF6_H +/* Define to 1 if you have the `setlocale' function. */ @@ -163,33 +163,33 @@ diff -U2 -r1.47.2.3.2.9 config.h.in + /* Define to 1 if you have the <stdint.h> header file. */ #undef HAVE_STDINT_H -@@ -234,4 +240,7 @@ +@@ -239,4 +245,7 @@ + /* Define to 1 if you can safely include both <sys/time.h> and <time.h>. */ #undef TIME_WITH_SYS_TIME - ++ +/* define if idnkit support is to be included. */ +#undef WITH_IDN -+ + /* Define to 1 if your processor stores words with the most significant byte - first (like Motorola and SPARC, unlike Intel and VAX). */ Index: configure =================================================================== RCS file: /proj/cvs/prod/bind9/configure,v -retrieving revision 1.284.2.19.2.19 -diff -U2 -r1.284.2.19.2.19 configure ---- configure 14 Mar 2004 00:00:31 -0000 1.284.2.19.2.19 -+++ configure 29 Apr 2004 03:02:43 -0000 +retrieving revision 1.284.2.19.2.26 +diff -U2 -r1.284.2.19.2.26 configure +--- configure 1 Sep 2004 07:18:30 -0000 1.284.2.19.2.26 ++++ configure 1 Sep 2004 07:49:43 -0000 @@ -15,5 +15,5 @@ # PERFORMANCE OF THIS SOFTWARE. # --# Id: configure,v 1.284.2.19.2.19 2004/03/14 00:00:31 marka Exp +-# Id: configure,v 1.284.2.19.2.26 2004/09/01 07:18:30 marka Exp +# Id: COPYRIGHT,v 1.6.2.2.8.2 2004/03/08 04:04:12 marka Exp # # Portions Copyright (C) 1996-2001 Nominum, Inc. @@ -496,5 +496,5 @@ #endif" --ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS subdirs build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_HAVELONGLONG ISC_PLATFORM_HAVELIFCONF ISC_PLATFORM_NEEDSYSSELECTH LWRES_PLATFORM_NEEDSYSSELECTH USE_OPENSSL DST_OPENSSL_INC USE_GSSAPI DST_GSSAPI_INC DNS_CRYPTO_LIBS ALWAYS_DEFINES ISC_PLATFORM_USETHREADS ISC_THREAD_DIR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK LIBBIND ISC_PLATFORM_HAVEIPV6 LWRES_PLATFORM_HAVEIPV6 ISC_PLATFORM_NEEDNETINETIN6H LWRES_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H LWRES_PLATFORM_NEEDNETINET6IN6H ISC_PLATFORM_HAVEINADDR6 LWRES_PLATFORM_HAVEINADDR6 ISC_PLATFORM_NEEDIN6ADDRANY LWRES_PLATFORM_NEEDIN6ADDRANY ISC_PLATFORM_NEEDIN6ADDRLOOPBACK LWRES_PLATFORM_NEEDIN6ADDRLOOPBACK ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C LWRES_HAVE_SIN6_SCOPE_ID ISC_PLATFORM_HAVESCOPEID ISC_PLATFORM_HAVEIF_LADDRREQ ISC_PLATFORM_HAVEIF_LADDRCONF ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON ISC_PLATFORM_HAVESALEN LWRES_PLATFORM_HAVESALEN ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_NEEDADDRINFO ISC_LWRES_NEEDRRSETINFO ISC_LWRES_SETHOSTENTINT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_GETNETBYADDRINADDR ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDMEMMOVE ISC_PLATFORM_NEEDSTRTOUL ISC_PLATFORM_NEEDSTRLCPY ISC_PLATFORM_NEEDSTRLCAT ISC_PLATFORM_NEEDSPRINTF ISC_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS ISC_PLATFORM_QUADFORMAT ISC_PLATFORM_RLIMITTYPE ISC_PLATFORM_USEDECLSPEC LWRES_PLATFORM_USEDECLSPEC ISC_PLATFORM_BRACEPTHREADONCEINIT ISC_PLATFORM_HAVEIFNAMETOINDEX OPENJADE JADETEX PDFJADETEX SGMLCATALOG HTMLSTYLE PRINTSTYLE XMLDCL DOCBOOK2MANSPEC BIND9_TOP_BUILDDIR BIND9_ISC_BUILDINCLUDE BIND9_ISCCC_BUILDINCLUDE BIND9_ISCCFG_BUILDINCLUDE BIND9_DNS_BUILDINCLUDE BIND9_LWRES_BUILDINCLUDE BIND9_BIND9_BUILDINCLUDE BIND9_VERSION LIBOBJS LTLIBOBJS' -+ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS subdirs build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_HAVELONGLONG ISC_PLATFORM_HAVELIFCONF ISC_PLATFORM_NEEDSYSSELECTH LWRES_PLATFORM_NEEDSYSSELECTH USE_OPENSSL DST_OPENSSL_INC USE_GSSAPI DST_GSSAPI_INC DNS_CRYPTO_LIBS ALWAYS_DEFINES ISC_PLATFORM_USETHREADS ISC_THREAD_DIR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK LIBBIND ISC_PLATFORM_HAVEIPV6 LWRES_PLATFORM_HAVEIPV6 ISC_PLATFORM_NEEDNETINETIN6H LWRES_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H LWRES_PLATFORM_NEEDNETINET6IN6H ISC_PLATFORM_HAVEINADDR6 LWRES_PLATFORM_HAVEINADDR6 ISC_PLATFORM_NEEDIN6ADDRANY LWRES_PLATFORM_NEEDIN6ADDRANY ISC_PLATFORM_NEEDIN6ADDRLOOPBACK LWRES_PLATFORM_NEEDIN6ADDRLOOPBACK ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C LWRES_HAVE_SIN6_SCOPE_ID ISC_PLATFORM_HAVESCOPEID ISC_PLATFORM_HAVEIF_LADDRREQ ISC_PLATFORM_HAVEIF_LADDRCONF ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON ISC_PLATFORM_HAVESALEN LWRES_PLATFORM_HAVESALEN ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_NEEDADDRINFO ISC_LWRES_NEEDRRSETINFO ISC_LWRES_SETHOSTENTINT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_GETNETBYADDRINADDR ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDMEMMOVE ISC_PLATFORM_NEEDSTRTOUL ISC_PLATFORM_NEEDSTRLCPY ISC_PLATFORM_NEEDSTRLCAT ISC_PLATFORM_NEEDSPRINTF ISC_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS ISC_PLATFORM_QUADFORMAT ISC_PLATFORM_RLIMITTYPE ISC_PLATFORM_USEDECLSPEC LWRES_PLATFORM_USEDECLSPEC ISC_PLATFORM_BRACEPTHREADONCEINIT ISC_PLATFORM_HAVEIFNAMETOINDEX OPENJADE JADETEX PDFJADETEX SGMLCATALOG HTMLSTYLE PRINTSTYLE XMLDCL DOCBOOK2MANSPEC IDNLIBS BIND9_TOP_BUILDDIR BIND9_ISC_BUILDINCLUDE BIND9_ISCCC_BUILDINCLUDE BIND9_ISCCFG_BUILDINCLUDE BIND9_DNS_BUILDINCLUDE BIND9_LWRES_BUILDINCLUDE BIND9_BIND9_BUILDINCLUDE BIND9_VERSION LIBOBJS LTLIBOBJS' +-ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS subdirs build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_HAVELONGLONG ISC_PLATFORM_HAVELIFCONF ISC_PLATFORM_NEEDSYSSELECTH LWRES_PLATFORM_NEEDSYSSELECTH USE_OPENSSL DST_OPENSSL_INC USE_GSSAPI DST_GSSAPI_INC DNS_CRYPTO_LIBS ALWAYS_DEFINES ISC_PLATFORM_USETHREADS ISC_THREAD_DIR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK LIBBIND ISC_PLATFORM_HAVEIPV6 LWRES_PLATFORM_HAVEIPV6 ISC_PLATFORM_NEEDNETINETIN6H LWRES_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H LWRES_PLATFORM_NEEDNETINET6IN6H ISC_PLATFORM_HAVEINADDR6 LWRES_PLATFORM_HAVEINADDR6 ISC_PLATFORM_NEEDIN6ADDRANY LWRES_PLATFORM_NEEDIN6ADDRANY ISC_PLATFORM_NEEDIN6ADDRLOOPBACK LWRES_PLATFORM_NEEDIN6ADDRLOOPBACK ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C LWRES_HAVE_SIN6_SCOPE_ID ISC_PLATFORM_HAVESCOPEID ISC_PLATFORM_HAVEIF_LADDRREQ ISC_PLATFORM_HAVEIF_LADDRCONF ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON ISC_PLATFORM_HAVESALEN LWRES_PLATFORM_HAVESALEN ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_NEEDADDRINFO ISC_LWRES_NEEDRRSETINFO ISC_LWRES_SETHOSTENTINT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_GETNETBYADDRINADDR ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDMEMMOVE ISC_PLATFORM_NEEDSTRTOUL ISC_PLATFORM_NEEDSTRLCPY ISC_PLATFORM_NEEDSTRLCAT ISC_PLATFORM_NEEDSPRINTF LWRES_PLATFORM_NEEDSPRINTF ISC_PLATFORM_NEEDVSNPRINTF LWRES_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS ISC_PLATFORM_QUADFORMAT ISC_PLATFORM_RLIMITTYPE ISC_PLATFORM_USEDECLSPEC LWRES_PLATFORM_USEDECLSPEC ISC_PLATFORM_BRACEPTHREADONCEINIT ISC_PLATFORM_HAVEIFNAMETOINDEX OPENJADE JADETEX PDFJADETEX SGMLCATALOG HTMLSTYLE PRINTSTYLE XMLDCL DOCBOOK2MANSPEC BIND9_TOP_BUILDDIR BIND9_ISC_BUILDINCLUDE BIND9_ISCCC_BUILDINCLUDE BIND9_ISCCFG_BUILDINCLUDE BIND9_DNS_BUILDINCLUDE BIND9_LWRES_BUILDINCLUDE BIND9_BIND9_BUILDINCLUDE BIND9_VERSION LIBOBJS LTLIBOBJS' ++ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS subdirs build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_HAVELONGLONG ISC_PLATFORM_HAVELIFCONF ISC_PLATFORM_NEEDSYSSELECTH LWRES_PLATFORM_NEEDSYSSELECTH USE_OPENSSL DST_OPENSSL_INC USE_GSSAPI DST_GSSAPI_INC DNS_CRYPTO_LIBS ALWAYS_DEFINES ISC_PLATFORM_USETHREADS ISC_THREAD_DIR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK LIBBIND ISC_PLATFORM_HAVEIPV6 LWRES_PLATFORM_HAVEIPV6 ISC_PLATFORM_NEEDNETINETIN6H LWRES_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H LWRES_PLATFORM_NEEDNETINET6IN6H ISC_PLATFORM_HAVEINADDR6 LWRES_PLATFORM_HAVEINADDR6 ISC_PLATFORM_NEEDIN6ADDRANY LWRES_PLATFORM_NEEDIN6ADDRANY ISC_PLATFORM_NEEDIN6ADDRLOOPBACK LWRES_PLATFORM_NEEDIN6ADDRLOOPBACK ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C LWRES_HAVE_SIN6_SCOPE_ID ISC_PLATFORM_HAVESCOPEID ISC_PLATFORM_HAVEIF_LADDRREQ ISC_PLATFORM_HAVEIF_LADDRCONF ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON ISC_PLATFORM_HAVESALEN LWRES_PLATFORM_HAVESALEN ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_NEEDADDRINFO ISC_LWRES_NEEDRRSETINFO ISC_LWRES_SETHOSTENTINT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_GETNETBYADDRINADDR ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDMEMMOVE ISC_PLATFORM_NEEDSTRTOUL ISC_PLATFORM_NEEDSTRLCPY ISC_PLATFORM_NEEDSTRLCAT ISC_PLATFORM_NEEDSPRINTF LWRES_PLATFORM_NEEDSPRINTF ISC_PLATFORM_NEEDVSNPRINTF LWRES_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS ISC_PLATFORM_QUADFORMAT ISC_PLATFORM_RLIMITTYPE ISC_PLATFORM_USEDECLSPEC LWRES_PLATFORM_USEDECLSPEC ISC_PLATFORM_BRACEPTHREADONCEINIT ISC_PLATFORM_HAVEIFNAMETOINDEX OPENJADE JADETEX PDFJADETEX SGMLCATALOG HTMLSTYLE PRINTSTYLE XMLDCL DOCBOOK2MANSPEC IDNLIBS BIND9_TOP_BUILDDIR BIND9_ISC_BUILDINCLUDE BIND9_ISCCC_BUILDINCLUDE BIND9_ISCCFG_BUILDINCLUDE BIND9_DNS_BUILDINCLUDE BIND9_LWRES_BUILDINCLUDE BIND9_BIND9_BUILDINCLUDE BIND9_VERSION LIBOBJS LTLIBOBJS' ac_subst_files='BIND9_MAKE_INCLUDES BIND9_MAKE_RULES LIBISC_API LIBISCCC_API LIBISCCFG_API LIBDNS_API LIBBIND9_API LIBLWRES_API' @@ -1081,4 +1081,8 @@ @@ -201,183 +201,183 @@ diff -U2 -r1.284.2.19.2.19 configure + --with-idnlib=ARG specify libidnkit Some influential environment variables: -@@ -7816,5 +7820,5 @@ +@@ -7921,5 +7925,5 @@ *-*-irix6*) # Find out which ABI we are using. -- echo '#line 7818 "configure"' > conftest.$ac_ext -+ echo '#line 7822 "configure"' > conftest.$ac_ext +- echo '#line 7923 "configure"' > conftest.$ac_ext ++ echo '#line 7927 "configure"' > conftest.$ac_ext if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 (eval $ac_compile) 2>&5 -@@ -8806,5 +8810,5 @@ +@@ -8911,5 +8915,5 @@ # Provide some information about the compiler. --echo "$as_me:8808:" \ -+echo "$as_me:8812:" \ +-echo "$as_me:8913:" \ ++echo "$as_me:8917:" \ "checking for Fortran 77 compiler version" >&5 ac_compiler=`set X $ac_compile; echo $2` -@@ -9844,9 +9848,9 @@ +@@ -9949,9 +9953,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:9846: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:9850: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:9951: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:9955: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 -- echo "$as_me:9850: \$? = $ac_status" >&5 -+ echo "$as_me:9854: \$? = $ac_status" >&5 +- echo "$as_me:9955: \$? = $ac_status" >&5 ++ echo "$as_me:9959: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized -@@ -10077,9 +10081,9 @@ +@@ -10182,9 +10186,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:10079: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:10083: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:10184: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:10188: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 -- echo "$as_me:10083: \$? = $ac_status" >&5 -+ echo "$as_me:10087: \$? = $ac_status" >&5 +- echo "$as_me:10188: \$? = $ac_status" >&5 ++ echo "$as_me:10192: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized -@@ -10137,9 +10141,9 @@ +@@ -10242,9 +10246,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:10139: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:10143: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:10244: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:10248: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 -- echo "$as_me:10143: \$? = $ac_status" >&5 -+ echo "$as_me:10147: \$? = $ac_status" >&5 +- echo "$as_me:10248: \$? = $ac_status" >&5 ++ echo "$as_me:10252: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then -@@ -12321,5 +12325,5 @@ +@@ -12426,5 +12430,5 @@ lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF --#line 12323 "configure" -+#line 12327 "configure" +-#line 12428 "configure" ++#line 12432 "configure" #include "confdefs.h" -@@ -12419,5 +12423,5 @@ +@@ -12524,5 +12528,5 @@ lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF --#line 12421 "configure" -+#line 12425 "configure" +-#line 12526 "configure" ++#line 12530 "configure" #include "confdefs.h" -@@ -14602,9 +14606,9 @@ +@@ -14707,9 +14711,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:14604: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:14608: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:14709: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:14713: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 -- echo "$as_me:14608: \$? = $ac_status" >&5 -+ echo "$as_me:14612: \$? = $ac_status" >&5 +- echo "$as_me:14713: \$? = $ac_status" >&5 ++ echo "$as_me:14717: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized -@@ -14662,9 +14666,9 @@ +@@ -14767,9 +14771,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:14664: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:14668: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:14769: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:14773: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 -- echo "$as_me:14668: \$? = $ac_status" >&5 -+ echo "$as_me:14672: \$? = $ac_status" >&5 +- echo "$as_me:14773: \$? = $ac_status" >&5 ++ echo "$as_me:14777: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then -@@ -16023,5 +16027,5 @@ +@@ -16128,5 +16132,5 @@ lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF --#line 16025 "configure" -+#line 16029 "configure" +-#line 16130 "configure" ++#line 16134 "configure" #include "confdefs.h" -@@ -16121,5 +16125,5 @@ +@@ -16226,5 +16230,5 @@ lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF --#line 16123 "configure" -+#line 16127 "configure" +-#line 16228 "configure" ++#line 16232 "configure" #include "confdefs.h" -@@ -16948,9 +16952,9 @@ +@@ -17053,9 +17057,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:16950: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:16954: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:17055: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:17059: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 -- echo "$as_me:16954: \$? = $ac_status" >&5 -+ echo "$as_me:16958: \$? = $ac_status" >&5 +- echo "$as_me:17059: \$? = $ac_status" >&5 ++ echo "$as_me:17063: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized -@@ -17008,9 +17012,9 @@ +@@ -17113,9 +17117,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:17010: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:17014: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:17115: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:17119: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 -- echo "$as_me:17014: \$? = $ac_status" >&5 -+ echo "$as_me:17018: \$? = $ac_status" >&5 +- echo "$as_me:17119: \$? = $ac_status" >&5 ++ echo "$as_me:17123: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then -@@ -19046,9 +19050,9 @@ +@@ -19151,9 +19155,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:19048: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:19052: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:19153: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:19157: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 -- echo "$as_me:19052: \$? = $ac_status" >&5 -+ echo "$as_me:19056: \$? = $ac_status" >&5 +- echo "$as_me:19157: \$? = $ac_status" >&5 ++ echo "$as_me:19161: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized -@@ -19279,9 +19283,9 @@ +@@ -19384,9 +19388,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:19281: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:19285: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:19386: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:19390: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 -- echo "$as_me:19285: \$? = $ac_status" >&5 -+ echo "$as_me:19289: \$? = $ac_status" >&5 +- echo "$as_me:19390: \$? = $ac_status" >&5 ++ echo "$as_me:19394: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized -@@ -19339,9 +19343,9 @@ +@@ -19444,9 +19448,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:19341: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:19345: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:19446: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:19450: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 -- echo "$as_me:19345: \$? = $ac_status" >&5 -+ echo "$as_me:19349: \$? = $ac_status" >&5 +- echo "$as_me:19450: \$? = $ac_status" >&5 ++ echo "$as_me:19454: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then -@@ -21523,5 +21527,5 @@ +@@ -21628,5 +21632,5 @@ lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF --#line 21525 "configure" -+#line 21529 "configure" +-#line 21630 "configure" ++#line 21634 "configure" #include "confdefs.h" -@@ -21621,5 +21625,5 @@ +@@ -21726,5 +21730,5 @@ lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF --#line 21623 "configure" -+#line 21627 "configure" +-#line 21728 "configure" ++#line 21732 "configure" #include "confdefs.h" -@@ -27186,4 +27190,354 @@ +@@ -27310,4 +27314,354 @@ # +# IDN support @@ -732,7 +732,7 @@ diff -U2 -r1.284.2.19.2.19 configure +# # Substitutions # -@@ -28066,4 +28420,5 @@ +@@ -28192,4 +28546,5 @@ s,@XMLDCL@,$XMLDCL,;t t s,@DOCBOOK2MANSPEC@,$DOCBOOK2MANSPEC,;t t +s,@IDNLIBS@,$IDNLIBS,;t t @@ -741,11 +741,11 @@ diff -U2 -r1.284.2.19.2.19 configure Index: configure.in =================================================================== RCS file: /proj/cvs/prod/bind9/configure.in,v -retrieving revision 1.294.2.23.2.23 -diff -U2 -r1.294.2.23.2.23 configure.in ---- configure.in 13 Mar 2004 23:59:10 -0000 1.294.2.23.2.23 -+++ configure.in 29 Apr 2004 03:02:47 -0000 -@@ -1994,4 +1994,80 @@ +retrieving revision 1.294.2.23.2.30 +diff -U2 -r1.294.2.23.2.30 configure.in +--- configure.in 1 Sep 2004 07:16:34 -0000 1.294.2.23.2.30 ++++ configure.in 1 Sep 2004 07:49:51 -0000 +@@ -2038,4 +2038,80 @@ # +# IDN support @@ -829,10 +829,10 @@ diff -U2 -r1.294.2.23.2.23 configure.in Index: bin/dig/Makefile.in =================================================================== RCS file: /proj/cvs/prod/bind9/bin/dig/Makefile.in,v -retrieving revision 1.25.12.10 -diff -U2 -r1.25.12.10 Makefile.in ---- bin/dig/Makefile.in 13 Apr 2004 05:47:32 -0000 1.25.12.10 -+++ bin/dig/Makefile.in 29 Apr 2004 03:02:48 -0000 +retrieving revision 1.25.12.12 +diff -U2 -r1.25.12.12 Makefile.in +--- bin/dig/Makefile.in 18 Aug 2004 23:25:57 -0000 1.25.12.12 ++++ bin/dig/Makefile.in 1 Sep 2004 07:49:52 -0000 @@ -46,5 +46,5 @@ LIBS = ${LWRESLIBS} ${DNSLIBS} ${BIND9LIBS} ${ISCLIBS} \ @@ -843,11 +843,11 @@ diff -U2 -r1.25.12.10 Makefile.in Index: bin/dig/dig.1 =================================================================== RCS file: /proj/cvs/prod/bind9/bin/dig/dig.1,v -retrieving revision 1.14.2.4.2.5 -diff -U2 -r1.14.2.4.2.5 dig.1 ---- bin/dig/dig.1 13 Apr 2004 04:11:03 -0000 1.14.2.4.2.5 -+++ bin/dig/dig.1 29 Apr 2004 03:02:49 -0000 -@@ -385,4 +385,15 @@ +retrieving revision 1.14.2.4.2.6 +diff -U2 -r1.14.2.4.2.6 dig.1 +--- bin/dig/dig.1 23 Jun 2004 09:11:01 -0000 1.14.2.4.2.6 ++++ bin/dig/dig.1 1 Sep 2004 07:49:54 -0000 +@@ -386,4 +386,15 @@ will not print the initial query when it looks up the NS records for isc.org. +.SH "IDN SUPPORT" @@ -866,11 +866,11 @@ diff -U2 -r1.14.2.4.2.5 dig.1 Index: bin/dig/dig.docbook =================================================================== RCS file: /proj/cvs/prod/bind9/bin/dig/dig.docbook,v -retrieving revision 1.4.2.7.4.8 -diff -U2 -r1.4.2.7.4.8 dig.docbook ---- bin/dig/dig.docbook 13 Apr 2004 03:00:05 -0000 1.4.2.7.4.8 -+++ bin/dig/dig.docbook 29 Apr 2004 03:02:51 -0000 -@@ -575,4 +575,19 @@ +retrieving revision 1.4.2.7.4.9 +diff -U2 -r1.4.2.7.4.9 dig.docbook +--- bin/dig/dig.docbook 23 Jun 2004 04:19:41 -0000 1.4.2.7.4.9 ++++ bin/dig/dig.docbook 1 Sep 2004 07:49:57 -0000 +@@ -578,4 +578,19 @@ <refsect1> +<title>IDN SUPPORT</title> @@ -893,12 +893,12 @@ diff -U2 -r1.4.2.7.4.8 dig.docbook Index: bin/dig/dighost.c =================================================================== RCS file: /proj/cvs/prod/bind9/bin/dig/dighost.c,v -retrieving revision 1.221.2.19.2.11 -diff -U2 -r1.221.2.19.2.11 dighost.c ---- bin/dig/dighost.c 13 Apr 2004 03:00:06 -0000 1.221.2.19.2.11 -+++ bin/dig/dighost.c 29 Apr 2004 03:03:00 -0000 -@@ -42,4 +42,15 @@ - #endif +retrieving revision 1.221.2.19.2.14 +diff -U2 -r1.221.2.19.2.14 dighost.c +--- bin/dig/dighost.c 30 Jun 2004 23:57:52 -0000 1.221.2.19.2.14 ++++ bin/dig/dighost.c 1 Sep 2004 07:50:24 -0000 +@@ -33,4 +33,15 @@ + #include <limits.h> +#ifdef HAVE_LOCALE_H +#include <locale.h> @@ -913,7 +913,7 @@ diff -U2 -r1.221.2.19.2.11 dighost.c + #include <dns/byaddr.h> #ifdef DIG_SIGCHASE -@@ -129,4 +140,16 @@ +@@ -120,4 +131,16 @@ int lookup_counter = 0; +#ifdef WITH_IDN @@ -930,7 +930,7 @@ diff -U2 -r1.221.2.19.2.11 dighost.c + /* * Exit Codes: -@@ -965,4 +988,8 @@ +@@ -956,4 +979,8 @@ copy_server_list(lwconf, &server_list); +#ifdef WITH_IDN @@ -939,7 +939,7 @@ diff -U2 -r1.221.2.19.2.11 dighost.c + if (keyfile[0] != 0) setup_file_key(); -@@ -1570,4 +1597,12 @@ +@@ -1568,4 +1595,12 @@ dns_compress_t cctx; char store[MXNAME]; +#ifdef WITH_IDN @@ -952,7 +952,7 @@ diff -U2 -r1.221.2.19.2.11 dighost.c +#endif REQUIRE(lookup != NULL); -@@ -1598,4 +1633,15 @@ +@@ -1596,4 +1631,15 @@ sizeof(lookup->onamespace)); +#ifdef WITH_IDN @@ -968,7 +968,7 @@ diff -U2 -r1.221.2.19.2.11 dighost.c + /* * If the name has too many dots, force the origin to be NULL -@@ -1606,4 +1652,11 @@ +@@ -1604,4 +1650,11 @@ */ /* XXX New search here? */ +#ifdef WITH_IDN @@ -980,7 +980,7 @@ diff -U2 -r1.221.2.19.2.11 dighost.c +#else if ((count_dots(lookup->textname) >= ndots) || !usesearch) lookup->origin = NULL; /* Force abs lookup */ -@@ -1611,5 +1664,27 @@ +@@ -1609,5 +1662,27 @@ lookup->origin = ISC_LIST_HEAD(search_list); } +#endif @@ -1008,7 +1008,7 @@ diff -U2 -r1.221.2.19.2.11 dighost.c +#endif debug("trying origin %s", lookup->origin->origin); result = dns_message_gettempname(lookup->sendmsg, -@@ -1656,4 +1731,13 @@ +@@ -1654,4 +1729,13 @@ dns_name_clone(dns_rootname, lookup->name); else { +#ifdef WITH_IDN @@ -1022,15 +1022,16 @@ diff -U2 -r1.221.2.19.2.11 dighost.c +#else len = strlen(lookup->textname); isc_buffer_init(&b, lookup->textname, len); -@@ -1663,4 +1747,5 @@ +@@ -1661,4 +1745,5 @@ ISC_FALSE, &lookup->namebuf); +#endif } if (result != ISC_R_SUCCESS) { -@@ -3154,4 +3239,102 @@ +@@ -3165,4 +3250,102 @@ + isc_mem_destroy(&mctx); } - ++ +#ifdef WITH_IDN +static void +initialize_idn(void) { @@ -1128,16 +1129,15 @@ diff -U2 -r1.221.2.19.2.11 dighost.c +} + +#endif /* WITH_IDN */ -+ - + Index: bin/dig/host.1 =================================================================== RCS file: /proj/cvs/prod/bind9/bin/dig/host.1,v retrieving revision 1.11.2.1.4.4 diff -U2 -r1.11.2.1.4.4 host.1 --- bin/dig/host.1 13 Apr 2004 04:11:03 -0000 1.11.2.1.4.4 -+++ bin/dig/host.1 29 Apr 2004 03:03:01 -0000 ++++ bin/dig/host.1 1 Sep 2004 07:50:24 -0000 @@ -128,4 +128,15 @@ will be set to the number of seconds given by the hardware's maximum value for an integer quantity. @@ -1160,7 +1160,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/host.docbook,v retrieving revision 1.2.2.2.4.5 diff -U2 -r1.2.2.2.4.5 host.docbook --- bin/dig/host.docbook 13 Apr 2004 01:26:26 -0000 1.2.2.2.4.5 -+++ bin/dig/host.docbook 29 Apr 2004 03:03:02 -0000 ++++ bin/dig/host.docbook 1 Sep 2004 07:50:27 -0000 @@ -192,4 +192,19 @@ <refsect1> @@ -1184,12 +1184,12 @@ diff -U2 -r1.2.2.2.4.5 host.docbook Index: lib/dns/name.c =================================================================== RCS file: /proj/cvs/prod/bind9/lib/dns/name.c,v -retrieving revision 1.127.2.7.2.10 -diff -U2 -r1.127.2.7.2.10 name.c ---- lib/dns/name.c 19 Apr 2004 21:55:38 -0000 1.127.2.7.2.10 -+++ lib/dns/name.c 29 Apr 2004 03:03:05 -0000 -@@ -180,4 +180,11 @@ - LIBDNS_EXTERNAL_DATA dns_name_t *dns_wildcardname = &wild; +retrieving revision 1.127.2.7.2.11 +diff -U2 -r1.127.2.7.2.11 name.c +--- lib/dns/name.c 1 Sep 2004 05:19:59 -0000 1.127.2.7.2.11 ++++ lib/dns/name.c 1 Sep 2004 07:50:35 -0000 +@@ -183,4 +183,11 @@ + dns_fullname_hash(dns_name_t *name, isc_boolean_t case_sensitive); +#ifdef WITH_IDN +/* @@ -1200,7 +1200,7 @@ diff -U2 -r1.127.2.7.2.10 name.c + static void set_offsets(const dns_name_t *name, unsigned char *offsets, -@@ -1193,4 +1200,7 @@ +@@ -1208,4 +1215,7 @@ unsigned int labels; isc_boolean_t saw_root = ISC_FALSE; +#ifdef WITH_IDN @@ -1208,7 +1208,7 @@ diff -U2 -r1.127.2.7.2.10 name.c +#endif /* -@@ -1331,4 +1341,9 @@ +@@ -1346,4 +1356,9 @@ isc_buffer_add(target, tlen - trem); +#ifdef WITH_IDN @@ -1218,7 +1218,7 @@ diff -U2 -r1.127.2.7.2.10 name.c + return (ISC_R_SUCCESS); } -@@ -2186,2 +2201,8 @@ +@@ -2201,2 +2216,8 @@ } +#ifdef WITH_IDN @@ -1230,10 +1230,10 @@ diff -U2 -r1.127.2.7.2.10 name.c Index: lib/dns/include/dns/name.h =================================================================== RCS file: /proj/cvs/prod/bind9/lib/dns/include/dns/name.h,v -retrieving revision 1.95.2.3.2.8 -diff -U2 -r1.95.2.3.2.8 name.h ---- lib/dns/include/dns/name.h 16 Mar 2004 12:57:17 -0000 1.95.2.3.2.8 -+++ lib/dns/include/dns/name.h 29 Apr 2004 03:03:07 -0000 +retrieving revision 1.95.2.3.2.11 +diff -U2 -r1.95.2.3.2.11 name.h +--- lib/dns/include/dns/name.h 1 Sep 2004 05:19:59 -0000 1.95.2.3.2.11 ++++ lib/dns/include/dns/name.h 1 Sep 2004 07:50:41 -0000 @@ -156,4 +156,15 @@ #define DNS_NAME_MAXWIRE 255 @@ -1250,9 +1250,10 @@ diff -U2 -r1.95.2.3.2.8 name.h + /*** *** Initialization -@@ -1113,4 +1124,12 @@ +@@ -1115,4 +1126,12 @@ + * */ - ++ +#ifdef WITH_IDN +void +dns_name_settotextfilter(dns_name_totextfilter_t proc); @@ -1260,6 +1261,5 @@ diff -U2 -r1.95.2.3.2.8 name.h + * Call 'proc' at the end of dns_name_totext. + */ +#endif /* WITH_IDN */ -+ + #define DNS_NAME_FORMATSIZE (DNS_NAME_MAXTEXT + 1) - /* diff --git a/dist/bind/contrib/nslint-2.1a3/Makefile.in b/dist/bind/contrib/nslint-2.1a3/Makefile.in index 6c366910d0b..9a7910f6142 100644 --- a/dist/bind/contrib/nslint-2.1a3/Makefile.in +++ b/dist/bind/contrib/nslint-2.1a3/Makefile.in @@ -17,7 +17,7 @@ # WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF # MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. # -# @(#) Id: Makefile.in,v 1.1 2001/12/21 04:12:02 marka Exp (LBL) +# @(#) Id: Makefile.in,v 1.1.204.1 2004/07/20 07:01:55 marka Exp (LBL) # # Various configurable paths (remember to edit Makefile.in, not Makefile) @@ -79,7 +79,7 @@ CLEANFILES = $(PROG) $(OBJ) $(GENSRC) $(PROG): $(OBJ) @rm -f $@ - $(CC) $(CFLAGS) -o $@ $(OBJ) $(LIBS) + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJ) $(LIBS) version.o: version.c version.c: $(srcdir)/VERSION diff --git a/dist/bind/contrib/queryperf/Makefile.in b/dist/bind/contrib/queryperf/Makefile.in index 2ed19a47363..6e16cad5f01 100644 --- a/dist/bind/contrib/queryperf/Makefile.in +++ b/dist/bind/contrib/queryperf/Makefile.in @@ -1,15 +1,23 @@ # Copyright (C) 2000, 2001 Nominum, Inc. All Rights Reserved. CC = @CC@ +LIBOBJS = @LIBOBJS@ LIBS = @LIBS@ DEFS = @DEFS@ -queryperf: queryperf.o - $(CC) $(CFLAGS) $(DEFS) queryperf.o $(LIBS) -lm -o queryperf +queryperf: queryperf.o $(LIBOBJS) + $(CC) $(CFLAGS) $(DEFS) $(LDFLAGS) queryperf.o $(LIBOBJS) $(LIBS) -lm -o queryperf queryperf.o: queryperf.c $(CC) $(CFLAGS) $(DEFS) -c queryperf.c +# under missing subdir +getaddrinfo.o: ./missing/getaddrinfo.c + $(CC) $(CFLAGS) -c ./missing/$*.c + +getnameinfo.o: ./missing/getnameinfo.c + $(CC) $(CFLAGS) -c ./missing/$*.c + clean: rm -f *.o queryperf diff --git a/dist/bind/contrib/queryperf/configure b/dist/bind/contrib/queryperf/configure index fb750cb1cc5..89f56978670 100755 --- a/dist/bind/contrib/queryperf/configure +++ b/dist/bind/contrib/queryperf/configure @@ -1,26 +1,273 @@ #! /bin/sh - # Guess values for system-dependent variables and create Makefiles. -# Generated automatically using autoconf version 2.13 -# Copyright (C) 1992, 93, 94, 95, 96 Free Software Foundation, Inc. +# Generated by GNU Autoconf 2.53. # +# Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002 +# Free Software Foundation, Inc. # This configure script is free software; the Free Software Foundation # gives unlimited permission to copy, distribute and modify it. -# Defaults: -ac_help= +if expr a : '\(a\)' >/dev/null 2>&1; then + as_expr=expr +else + as_expr=false +fi + + +## --------------------- ## +## M4sh Initialization. ## +## --------------------- ## + +# Be Bourne compatible +if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then + emulate sh + NULLCMD=: +elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1; then + set -o posix +fi + +# NLS nuisances. +# Support unset when possible. +if (FOO=FOO; unset FOO) >/dev/null 2>&1; then + as_unset=unset +else + as_unset=false +fi + +(set +x; test -n "`(LANG=C; export LANG) 2>&1`") && + { $as_unset LANG || test "${LANG+set}" != set; } || + { LANG=C; export LANG; } +(set +x; test -n "`(LC_ALL=C; export LC_ALL) 2>&1`") && + { $as_unset LC_ALL || test "${LC_ALL+set}" != set; } || + { LC_ALL=C; export LC_ALL; } +(set +x; test -n "`(LC_TIME=C; export LC_TIME) 2>&1`") && + { $as_unset LC_TIME || test "${LC_TIME+set}" != set; } || + { LC_TIME=C; export LC_TIME; } +(set +x; test -n "`(LC_CTYPE=C; export LC_CTYPE) 2>&1`") && + { $as_unset LC_CTYPE || test "${LC_CTYPE+set}" != set; } || + { LC_CTYPE=C; export LC_CTYPE; } +(set +x; test -n "`(LANGUAGE=C; export LANGUAGE) 2>&1`") && + { $as_unset LANGUAGE || test "${LANGUAGE+set}" != set; } || + { LANGUAGE=C; export LANGUAGE; } +(set +x; test -n "`(LC_COLLATE=C; export LC_COLLATE) 2>&1`") && + { $as_unset LC_COLLATE || test "${LC_COLLATE+set}" != set; } || + { LC_COLLATE=C; export LC_COLLATE; } +(set +x; test -n "`(LC_NUMERIC=C; export LC_NUMERIC) 2>&1`") && + { $as_unset LC_NUMERIC || test "${LC_NUMERIC+set}" != set; } || + { LC_NUMERIC=C; export LC_NUMERIC; } +(set +x; test -n "`(LC_MESSAGES=C; export LC_MESSAGES) 2>&1`") && + { $as_unset LC_MESSAGES || test "${LC_MESSAGES+set}" != set; } || + { LC_MESSAGES=C; export LC_MESSAGES; } + + +# Name of the executable. +as_me=`(basename "$0") 2>/dev/null || +$as_expr X/"$0" : '.*/\([^/][^/]*\)/*$' \| \ + X"$0" : 'X\(//\)$' \| \ + X"$0" : 'X\(/\)$' \| \ + . : '\(.\)' 2>/dev/null || +echo X/"$0" | + sed '/^.*\/\([^/][^/]*\)\/*$/{ s//\1/; q; } + /^X\/\(\/\/\)$/{ s//\1/; q; } + /^X\/\(\/\).*/{ s//\1/; q; } + s/.*/./; q'` + +# PATH needs CR, and LINENO needs CR and PATH. +# Avoid depending upon Character Ranges. +as_cr_letters='abcdefghijklmnopqrstuvwxyz' +as_cr_LETTERS='ABCDEFGHIJKLMNOPQRSTUVWXYZ' +as_cr_Letters=$as_cr_letters$as_cr_LETTERS +as_cr_digits='0123456789' +as_cr_alnum=$as_cr_Letters$as_cr_digits + +# The user is always right. +if test "${PATH_SEPARATOR+set}" != set; then + echo "#! /bin/sh" >conftest.sh + echo "exit 0" >>conftest.sh + chmod +x conftest.sh + if (PATH=".;."; conftest.sh) >/dev/null 2>&1; then + PATH_SEPARATOR=';' + else + PATH_SEPARATOR=: + fi + rm -f conftest.sh +fi + + + as_lineno_1=$LINENO + as_lineno_2=$LINENO + as_lineno_3=`(expr $as_lineno_1 + 1) 2>/dev/null` + test "x$as_lineno_1" != "x$as_lineno_2" && + test "x$as_lineno_3" = "x$as_lineno_2" || { + # Find who we are. Look in the path if we contain no path at all + # relative or not. + case $0 in + *[\\/]* ) as_myself=$0 ;; + *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR +for as_dir in $PATH +do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + test -r "$as_dir/$0" && as_myself=$as_dir/$0 && break +done + + ;; + esac + # We did not find ourselves, most probably we were run as `sh COMMAND' + # in which case we are not to be found in the path. + if test "x$as_myself" = x; then + as_myself=$0 + fi + if test ! -f "$as_myself"; then + { echo "$as_me: error: cannot find myself; rerun with an absolute path" >&2 + { (exit 1); exit 1; }; } + fi + case $CONFIG_SHELL in + '') + as_save_IFS=$IFS; IFS=$PATH_SEPARATOR +for as_dir in /bin$PATH_SEPARATOR/usr/bin$PATH_SEPARATOR$PATH +do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for as_base in sh bash ksh sh5; do + case $as_dir in + /*) + if ("$as_dir/$as_base" -c ' + as_lineno_1=$LINENO + as_lineno_2=$LINENO + as_lineno_3=`(expr $as_lineno_1 + 1) 2>/dev/null` + test "x$as_lineno_1" != "x$as_lineno_2" && + test "x$as_lineno_3" = "x$as_lineno_2" ') 2>/dev/null; then + CONFIG_SHELL=$as_dir/$as_base + export CONFIG_SHELL + exec "$CONFIG_SHELL" "$0" ${1+"$@"} + fi;; + esac + done +done +;; + esac + + # Create $as_me.lineno as a copy of $as_myself, but with $LINENO + # uniformly replaced by the line number. The first 'sed' inserts a + # line-number line before each line; the second 'sed' does the real + # work. The second script uses 'N' to pair each line-number line + # with the numbered line, and appends trailing '-' during + # substitution so that $LINENO is not a special case at line end. + # (Raja R Harinath suggested sed '=', and Paul Eggert wrote the + # second 'sed' script. Blame Lee E. McMahon for sed's syntax. :-) + sed '=' <$as_myself | + sed ' + N + s,$,-, + : loop + s,^\(['$as_cr_digits']*\)\(.*\)[$]LINENO\([^'$as_cr_alnum'_]\),\1\2\1\3, + t loop + s,-$,, + s,^['$as_cr_digits']*\n,, + ' >$as_me.lineno && + chmod +x $as_me.lineno || + { echo "$as_me: error: cannot create $as_me.lineno; rerun with a POSIX shell" >&2 + { (exit 1); exit 1; }; } + + # Don't try to exec as it changes $[0], causing all sort of problems + # (the dirname of $[0] is not the place where we might find the + # original and so on. Autoconf is especially sensible to this). + . ./$as_me.lineno + # Exit status is that of the last command. + exit +} + + +case `echo "testing\c"; echo 1,2,3`,`echo -n testing; echo 1,2,3` in + *c*,-n*) ECHO_N= ECHO_C=' +' ECHO_T=' ' ;; + *c*,* ) ECHO_N=-n ECHO_C= ECHO_T= ;; + *) ECHO_N= ECHO_C='\c' ECHO_T= ;; +esac + +if expr a : '\(a\)' >/dev/null 2>&1; then + as_expr=expr +else + as_expr=false +fi + +rm -f conf$$ conf$$.exe conf$$.file +echo >conf$$.file +if ln -s conf$$.file conf$$ 2>/dev/null; then + # We could just check for DJGPP; but this test a) works b) is more generic + # and c) will remain valid once DJGPP supports symlinks (DJGPP 2.04). + if test -f conf$$.exe; then + # Don't use ln at all; we don't have any links + as_ln_s='cp -p' + else + as_ln_s='ln -s' + fi +elif ln conf$$.file conf$$ 2>/dev/null; then + as_ln_s=ln +else + as_ln_s='cp -p' +fi +rm -f conf$$ conf$$.exe conf$$.file + +as_executable_p="test -f" + +# Sed expression to map a string onto a valid CPP name. +as_tr_cpp="sed y%*$as_cr_letters%P$as_cr_LETTERS%;s%[^_$as_cr_alnum]%_%g" + +# Sed expression to map a string onto a valid variable name. +as_tr_sh="sed y%*+%pp%;s%[^_$as_cr_alnum]%_%g" + + +# IFS +# We need space, tab and new line, in precisely that order. +as_nl=' +' +IFS=" $as_nl" + +# CDPATH. +$as_unset CDPATH || test "${CDPATH+set}" != set || { CDPATH=$PATH_SEPARATOR; export CDPATH; } + + +# Name of the host. +# hostname on some systems (SVR3.2, Linux) returns a bogus exit status, +# so uname gets run too. +ac_hostname=`(hostname || uname -n) 2>/dev/null | sed 1q` + +exec 6>&1 + +# +# Initializations. +# ac_default_prefix=/usr/local -# Any additions from configure.in: +cross_compiling=no +subdirs= +MFLAGS= +MAKEFLAGS= +SHELL=${CONFIG_SHELL-/bin/sh} + +# Maximum number of lines to put in a shell here document. +# This variable seems obsolete. It should probably be removed, and +# only ac_max_sed_lines should be used. +: ${ac_max_here_lines=38} + +# Identity of this package. +PACKAGE_NAME= +PACKAGE_TARNAME= +PACKAGE_VERSION= +PACKAGE_STRING= +PACKAGE_BUGREPORT= + +ac_unique_file="queryperf.c" # Initialize some variables set by options. +ac_init_help= +ac_init_version=false # The variables have the same names as the options, with # dashes changed to underlines. -build=NONE -cache_file=./config.cache +cache_file=/dev/null exec_prefix=NONE -host=NONE no_create= -nonopt=NONE no_recursion= prefix=NONE program_prefix=NONE @@ -29,10 +276,15 @@ program_transform_name=s,x,x, silent= site= srcdir= -target=NONE verbose= x_includes=NONE x_libraries=NONE + +# Installation directory options. +# These are left unexpanded so users can "make install exec_prefix=/foo" +# and all the variables that are supposed to be based on exec_prefix +# by default will actually change. +# Use braces instead of parens because sh, perl, etc. also accept them. bindir='${exec_prefix}/bin' sbindir='${exec_prefix}/sbin' libexecdir='${exec_prefix}/libexec' @@ -46,17 +298,9 @@ oldincludedir='/usr/include' infodir='${prefix}/info' mandir='${prefix}/man' -# Initialize some other variables. -subdirs= -MFLAGS= MAKEFLAGS= -SHELL=${CONFIG_SHELL-/bin/sh} -# Maximum number of lines to put in a shell here document. -ac_max_here_lines=12 - ac_prev= for ac_option do - # If the previous option needs an argument, assign it. if test -n "$ac_prev"; then eval "$ac_prev=\$ac_option" @@ -64,59 +308,59 @@ do continue fi - case "$ac_option" in - -*=*) ac_optarg=`echo "$ac_option" | sed 's/[-_a-zA-Z0-9]*=//'` ;; - *) ac_optarg= ;; - esac + ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'` # Accept the important Cygnus configure options, so we can diagnose typos. - case "$ac_option" in + case $ac_option in -bindir | --bindir | --bindi | --bind | --bin | --bi) ac_prev=bindir ;; -bindir=* | --bindir=* | --bindi=* | --bind=* | --bin=* | --bi=*) - bindir="$ac_optarg" ;; + bindir=$ac_optarg ;; -build | --build | --buil | --bui | --bu) - ac_prev=build ;; + ac_prev=build_alias ;; -build=* | --build=* | --buil=* | --bui=* | --bu=*) - build="$ac_optarg" ;; + build_alias=$ac_optarg ;; -cache-file | --cache-file | --cache-fil | --cache-fi \ | --cache-f | --cache- | --cache | --cach | --cac | --ca | --c) ac_prev=cache_file ;; -cache-file=* | --cache-file=* | --cache-fil=* | --cache-fi=* \ | --cache-f=* | --cache-=* | --cache=* | --cach=* | --cac=* | --ca=* | --c=*) - cache_file="$ac_optarg" ;; + cache_file=$ac_optarg ;; + + --config-cache | -C) + cache_file=config.cache ;; -datadir | --datadir | --datadi | --datad | --data | --dat | --da) ac_prev=datadir ;; -datadir=* | --datadir=* | --datadi=* | --datad=* | --data=* | --dat=* \ | --da=*) - datadir="$ac_optarg" ;; + datadir=$ac_optarg ;; -disable-* | --disable-*) - ac_feature=`echo $ac_option|sed -e 's/-*disable-//'` + ac_feature=`expr "x$ac_option" : 'x-*disable-\(.*\)'` # Reject names that are not valid shell variable names. - if test -n "`echo $ac_feature| sed 's/[-a-zA-Z0-9_]//g'`"; then - { echo "configure: error: $ac_feature: invalid feature name" 1>&2; exit 1; } - fi - ac_feature=`echo $ac_feature| sed 's/-/_/g'` - eval "enable_${ac_feature}=no" ;; + expr "x$ac_feature" : ".*[^-_$as_cr_alnum]" >/dev/null && + { echo "$as_me: error: invalid feature name: $ac_feature" >&2 + { (exit 1); exit 1; }; } + ac_feature=`echo $ac_feature | sed 's/-/_/g'` + eval "enable_$ac_feature=no" ;; -enable-* | --enable-*) - ac_feature=`echo $ac_option|sed -e 's/-*enable-//' -e 's/=.*//'` + ac_feature=`expr "x$ac_option" : 'x-*enable-\([^=]*\)'` # Reject names that are not valid shell variable names. - if test -n "`echo $ac_feature| sed 's/[-_a-zA-Z0-9]//g'`"; then - { echo "configure: error: $ac_feature: invalid feature name" 1>&2; exit 1; } - fi - ac_feature=`echo $ac_feature| sed 's/-/_/g'` - case "$ac_option" in - *=*) ;; + expr "x$ac_feature" : ".*[^-_$as_cr_alnum]" >/dev/null && + { echo "$as_me: error: invalid feature name: $ac_feature" >&2 + { (exit 1); exit 1; }; } + ac_feature=`echo $ac_feature | sed 's/-/_/g'` + case $ac_option in + *=*) ac_optarg=`echo "$ac_optarg" | sed "s/'/'\\\\\\\\''/g"`;; *) ac_optarg=yes ;; esac - eval "enable_${ac_feature}='$ac_optarg'" ;; + eval "enable_$ac_feature='$ac_optarg'" ;; -exec-prefix | --exec_prefix | --exec-prefix | --exec-prefi \ | --exec-pref | --exec-pre | --exec-pr | --exec-p | --exec- \ @@ -125,95 +369,47 @@ do -exec-prefix=* | --exec_prefix=* | --exec-prefix=* | --exec-prefi=* \ | --exec-pref=* | --exec-pre=* | --exec-pr=* | --exec-p=* | --exec-=* \ | --exec=* | --exe=* | --ex=*) - exec_prefix="$ac_optarg" ;; + exec_prefix=$ac_optarg ;; -gas | --gas | --ga | --g) # Obsolete; use --with-gas. with_gas=yes ;; - -help | --help | --hel | --he) - # Omit some internal or obsolete options to make the list less imposing. - # This message is too long to be a string in the A/UX 3.1 sh. - cat << EOF -Usage: configure [options] [host] -Options: [defaults in brackets after descriptions] -Configuration: - --cache-file=FILE cache test results in FILE - --help print this message - --no-create do not create output files - --quiet, --silent do not print \`checking...' messages - --version print the version of autoconf that created configure -Directory and file names: - --prefix=PREFIX install architecture-independent files in PREFIX - [$ac_default_prefix] - --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX - [same as prefix] - --bindir=DIR user executables in DIR [EPREFIX/bin] - --sbindir=DIR system admin executables in DIR [EPREFIX/sbin] - --libexecdir=DIR program executables in DIR [EPREFIX/libexec] - --datadir=DIR read-only architecture-independent data in DIR - [PREFIX/share] - --sysconfdir=DIR read-only single-machine data in DIR [PREFIX/etc] - --sharedstatedir=DIR modifiable architecture-independent data in DIR - [PREFIX/com] - --localstatedir=DIR modifiable single-machine data in DIR [PREFIX/var] - --libdir=DIR object code libraries in DIR [EPREFIX/lib] - --includedir=DIR C header files in DIR [PREFIX/include] - --oldincludedir=DIR C header files for non-gcc in DIR [/usr/include] - --infodir=DIR info documentation in DIR [PREFIX/info] - --mandir=DIR man documentation in DIR [PREFIX/man] - --srcdir=DIR find the sources in DIR [configure dir or ..] - --program-prefix=PREFIX prepend PREFIX to installed program names - --program-suffix=SUFFIX append SUFFIX to installed program names - --program-transform-name=PROGRAM - run sed PROGRAM on installed program names -EOF - cat << EOF -Host type: - --build=BUILD configure for building on BUILD [BUILD=HOST] - --host=HOST configure for HOST [guessed] - --target=TARGET configure for TARGET [TARGET=HOST] -Features and packages: - --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) - --enable-FEATURE[=ARG] include FEATURE [ARG=yes] - --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] - --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) - --x-includes=DIR X include files are in DIR - --x-libraries=DIR X library files are in DIR -EOF - if test -n "$ac_help"; then - echo "--enable and --with options recognized:$ac_help" - fi - exit 0 ;; + -help | --help | --hel | --he | -h) + ac_init_help=long ;; + -help=r* | --help=r* | --hel=r* | --he=r* | -hr*) + ac_init_help=recursive ;; + -help=s* | --help=s* | --hel=s* | --he=s* | -hs*) + ac_init_help=short ;; -host | --host | --hos | --ho) - ac_prev=host ;; + ac_prev=host_alias ;; -host=* | --host=* | --hos=* | --ho=*) - host="$ac_optarg" ;; + host_alias=$ac_optarg ;; -includedir | --includedir | --includedi | --included | --include \ | --includ | --inclu | --incl | --inc) ac_prev=includedir ;; -includedir=* | --includedir=* | --includedi=* | --included=* | --include=* \ | --includ=* | --inclu=* | --incl=* | --inc=*) - includedir="$ac_optarg" ;; + includedir=$ac_optarg ;; -infodir | --infodir | --infodi | --infod | --info | --inf) ac_prev=infodir ;; -infodir=* | --infodir=* | --infodi=* | --infod=* | --info=* | --inf=*) - infodir="$ac_optarg" ;; + infodir=$ac_optarg ;; -libdir | --libdir | --libdi | --libd) ac_prev=libdir ;; -libdir=* | --libdir=* | --libdi=* | --libd=*) - libdir="$ac_optarg" ;; + libdir=$ac_optarg ;; -libexecdir | --libexecdir | --libexecdi | --libexecd | --libexec \ | --libexe | --libex | --libe) ac_prev=libexecdir ;; -libexecdir=* | --libexecdir=* | --libexecdi=* | --libexecd=* | --libexec=* \ | --libexe=* | --libex=* | --libe=*) - libexecdir="$ac_optarg" ;; + libexecdir=$ac_optarg ;; -localstatedir | --localstatedir | --localstatedi | --localstated \ | --localstate | --localstat | --localsta | --localst \ @@ -222,19 +418,19 @@ EOF -localstatedir=* | --localstatedir=* | --localstatedi=* | --localstated=* \ | --localstate=* | --localstat=* | --localsta=* | --localst=* \ | --locals=* | --local=* | --loca=* | --loc=* | --lo=*) - localstatedir="$ac_optarg" ;; + localstatedir=$ac_optarg ;; -mandir | --mandir | --mandi | --mand | --man | --ma | --m) ac_prev=mandir ;; -mandir=* | --mandir=* | --mandi=* | --mand=* | --man=* | --ma=* | --m=*) - mandir="$ac_optarg" ;; + mandir=$ac_optarg ;; -nfp | --nfp | --nf) # Obsolete; use --without-fp. with_fp=no ;; -no-create | --no-create | --no-creat | --no-crea | --no-cre \ - | --no-cr | --no-c) + | --no-cr | --no-c | -n) no_create=yes ;; -no-recursion | --no-recursion | --no-recursio | --no-recursi \ @@ -248,26 +444,26 @@ EOF -oldincludedir=* | --oldincludedir=* | --oldincludedi=* | --oldincluded=* \ | --oldinclude=* | --oldinclud=* | --oldinclu=* | --oldincl=* | --oldinc=* \ | --oldin=* | --oldi=* | --old=* | --ol=* | --o=*) - oldincludedir="$ac_optarg" ;; + oldincludedir=$ac_optarg ;; -prefix | --prefix | --prefi | --pref | --pre | --pr | --p) ac_prev=prefix ;; -prefix=* | --prefix=* | --prefi=* | --pref=* | --pre=* | --pr=* | --p=*) - prefix="$ac_optarg" ;; + prefix=$ac_optarg ;; -program-prefix | --program-prefix | --program-prefi | --program-pref \ | --program-pre | --program-pr | --program-p) ac_prev=program_prefix ;; -program-prefix=* | --program-prefix=* | --program-prefi=* \ | --program-pref=* | --program-pre=* | --program-pr=* | --program-p=*) - program_prefix="$ac_optarg" ;; + program_prefix=$ac_optarg ;; -program-suffix | --program-suffix | --program-suffi | --program-suff \ | --program-suf | --program-su | --program-s) ac_prev=program_suffix ;; -program-suffix=* | --program-suffix=* | --program-suffi=* \ | --program-suff=* | --program-suf=* | --program-su=* | --program-s=*) - program_suffix="$ac_optarg" ;; + program_suffix=$ac_optarg ;; -program-transform-name | --program-transform-name \ | --program-transform-nam | --program-transform-na \ @@ -284,7 +480,7 @@ EOF | --program-transfo=* | --program-transf=* \ | --program-trans=* | --program-tran=* \ | --progr-tra=* | --program-tr=* | --program-t=*) - program_transform_name="$ac_optarg" ;; + program_transform_name=$ac_optarg ;; -q | -quiet | --quiet | --quie | --qui | --qu | --q \ | -silent | --silent | --silen | --sile | --sil) @@ -294,7 +490,7 @@ EOF ac_prev=sbindir ;; -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \ | --sbi=* | --sb=*) - sbindir="$ac_optarg" ;; + sbindir=$ac_optarg ;; -sharedstatedir | --sharedstatedir | --sharedstatedi \ | --sharedstated | --sharedstate | --sharedstat | --sharedsta \ @@ -305,58 +501,57 @@ EOF | --sharedstated=* | --sharedstate=* | --sharedstat=* | --sharedsta=* \ | --sharedst=* | --shareds=* | --shared=* | --share=* | --shar=* \ | --sha=* | --sh=*) - sharedstatedir="$ac_optarg" ;; + sharedstatedir=$ac_optarg ;; -site | --site | --sit) ac_prev=site ;; -site=* | --site=* | --sit=*) - site="$ac_optarg" ;; + site=$ac_optarg ;; -srcdir | --srcdir | --srcdi | --srcd | --src | --sr) ac_prev=srcdir ;; -srcdir=* | --srcdir=* | --srcdi=* | --srcd=* | --src=* | --sr=*) - srcdir="$ac_optarg" ;; + srcdir=$ac_optarg ;; -sysconfdir | --sysconfdir | --sysconfdi | --sysconfd | --sysconf \ | --syscon | --sysco | --sysc | --sys | --sy) ac_prev=sysconfdir ;; -sysconfdir=* | --sysconfdir=* | --sysconfdi=* | --sysconfd=* | --sysconf=* \ | --syscon=* | --sysco=* | --sysc=* | --sys=* | --sy=*) - sysconfdir="$ac_optarg" ;; + sysconfdir=$ac_optarg ;; -target | --target | --targe | --targ | --tar | --ta | --t) - ac_prev=target ;; + ac_prev=target_alias ;; -target=* | --target=* | --targe=* | --targ=* | --tar=* | --ta=* | --t=*) - target="$ac_optarg" ;; + target_alias=$ac_optarg ;; -v | -verbose | --verbose | --verbos | --verbo | --verb) verbose=yes ;; - -version | --version | --versio | --versi | --vers) - echo "configure generated by autoconf version 2.13" - exit 0 ;; + -version | --version | --versio | --versi | --vers | -V) + ac_init_version=: ;; -with-* | --with-*) - ac_package=`echo $ac_option|sed -e 's/-*with-//' -e 's/=.*//'` + ac_package=`expr "x$ac_option" : 'x-*with-\([^=]*\)'` # Reject names that are not valid shell variable names. - if test -n "`echo $ac_package| sed 's/[-_a-zA-Z0-9]//g'`"; then - { echo "configure: error: $ac_package: invalid package name" 1>&2; exit 1; } - fi + expr "x$ac_package" : ".*[^-_$as_cr_alnum]" >/dev/null && + { echo "$as_me: error: invalid package name: $ac_package" >&2 + { (exit 1); exit 1; }; } ac_package=`echo $ac_package| sed 's/-/_/g'` - case "$ac_option" in - *=*) ;; + case $ac_option in + *=*) ac_optarg=`echo "$ac_optarg" | sed "s/'/'\\\\\\\\''/g"`;; *) ac_optarg=yes ;; esac - eval "with_${ac_package}='$ac_optarg'" ;; + eval "with_$ac_package='$ac_optarg'" ;; -without-* | --without-*) - ac_package=`echo $ac_option|sed -e 's/-*without-//'` + ac_package=`expr "x$ac_option" : 'x-*without-\(.*\)'` # Reject names that are not valid shell variable names. - if test -n "`echo $ac_package| sed 's/[-a-zA-Z0-9_]//g'`"; then - { echo "configure: error: $ac_package: invalid package name" 1>&2; exit 1; } - fi - ac_package=`echo $ac_package| sed 's/-/_/g'` - eval "with_${ac_package}=no" ;; + expr "x$ac_package" : ".*[^-_$as_cr_alnum]" >/dev/null && + { echo "$as_me: error: invalid package name: $ac_package" >&2 + { (exit 1); exit 1; }; } + ac_package=`echo $ac_package | sed 's/-/_/g'` + eval "with_$ac_package=no" ;; --x) # Obsolete; use --with-x. @@ -367,99 +562,110 @@ EOF ac_prev=x_includes ;; -x-includes=* | --x-includes=* | --x-include=* | --x-includ=* | --x-inclu=* \ | --x-incl=* | --x-inc=* | --x-in=* | --x-i=*) - x_includes="$ac_optarg" ;; + x_includes=$ac_optarg ;; -x-libraries | --x-libraries | --x-librarie | --x-librari \ | --x-librar | --x-libra | --x-libr | --x-lib | --x-li | --x-l) ac_prev=x_libraries ;; -x-libraries=* | --x-libraries=* | --x-librarie=* | --x-librari=* \ | --x-librar=* | --x-libra=* | --x-libr=* | --x-lib=* | --x-li=* | --x-l=*) - x_libraries="$ac_optarg" ;; + x_libraries=$ac_optarg ;; - -*) { echo "configure: error: $ac_option: invalid option; use --help to show usage" 1>&2; exit 1; } + -*) { echo "$as_me: error: unrecognized option: $ac_option +Try \`$0 --help' for more information." >&2 + { (exit 1); exit 1; }; } ;; + *=*) + ac_envvar=`expr "x$ac_option" : 'x\([^=]*\)='` + # Reject names that are not valid shell variable names. + expr "x$ac_envvar" : ".*[^_$as_cr_alnum]" >/dev/null && + { echo "$as_me: error: invalid variable name: $ac_envvar" >&2 + { (exit 1); exit 1; }; } + ac_optarg=`echo "$ac_optarg" | sed "s/'/'\\\\\\\\''/g"` + eval "$ac_envvar='$ac_optarg'" + export $ac_envvar ;; + *) - if test -n "`echo $ac_option| sed 's/[-a-z0-9.]//g'`"; then - echo "configure: warning: $ac_option: invalid host type" 1>&2 - fi - if test "x$nonopt" != xNONE; then - { echo "configure: error: can only configure for one host and one target at a time" 1>&2; exit 1; } - fi - nonopt="$ac_option" + # FIXME: should be removed in autoconf 3.0. + echo "$as_me: WARNING: you should use --build, --host, --target" >&2 + expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null && + echo "$as_me: WARNING: invalid host type: $ac_option" >&2 + : ${build_alias=$ac_option} ${host_alias=$ac_option} ${target_alias=$ac_option} ;; esac done if test -n "$ac_prev"; then - { echo "configure: error: missing argument to --`echo $ac_prev | sed 's/_/-/g'`" 1>&2; exit 1; } + ac_option=--`echo $ac_prev | sed 's/_/-/g'` + { echo "$as_me: error: missing argument to $ac_option" >&2 + { (exit 1); exit 1; }; } fi -trap 'rm -fr conftest* confdefs* core core.* *.core $ac_clean_files; exit 1' 1 2 15 - -# File descriptor usage: -# 0 standard input -# 1 file creation -# 2 errors and warnings -# 3 some systems may open it to /dev/tty -# 4 used on the Kubota Titan -# 6 checking for... messages and results -# 5 compiler messages saved in config.log -if test "$silent" = yes; then - exec 6>/dev/null -else - exec 6>&1 -fi -exec 5>./config.log - -echo "\ -This file contains any messages produced by compilers while -running configure, to aid debugging if configure makes a mistake. -" 1>&5 +# Be sure to have absolute paths. +for ac_var in exec_prefix prefix +do + eval ac_val=$`echo $ac_var` + case $ac_val in + [\\/$]* | ?:[\\/]* | NONE | '' ) ;; + *) { echo "$as_me: error: expected an absolute directory name for --$ac_var: $ac_val" >&2 + { (exit 1); exit 1; }; };; + esac +done -# Strip out --no-create and --no-recursion so they do not pile up. -# Also quote any args containing shell metacharacters. -ac_configure_args= -for ac_arg +# Be sure to have absolute paths. +for ac_var in bindir sbindir libexecdir datadir sysconfdir sharedstatedir \ + localstatedir libdir includedir oldincludedir infodir mandir do - case "$ac_arg" in - -no-create | --no-create | --no-creat | --no-crea | --no-cre \ - | --no-cr | --no-c) ;; - -no-recursion | --no-recursion | --no-recursio | --no-recursi \ - | --no-recurs | --no-recur | --no-recu | --no-rec | --no-re | --no-r) ;; - *" "*|*" "*|*[\[\]\~\#\$\^\&\*\(\)\{\}\\\|\;\<\>\?]*) - ac_configure_args="$ac_configure_args '$ac_arg'" ;; - *) ac_configure_args="$ac_configure_args $ac_arg" ;; + eval ac_val=$`echo $ac_var` + case $ac_val in + [\\/$]* | ?:[\\/]* ) ;; + *) { echo "$as_me: error: expected an absolute directory name for --$ac_var: $ac_val" >&2 + { (exit 1); exit 1; }; };; esac done -# NLS nuisances. -# Only set these to C if already set. These must not be set unconditionally -# because not all systems understand e.g. LANG=C (notably SCO). -# Fixing LC_MESSAGES prevents Solaris sh from translating var values in `set'! -# Non-C LC_CTYPE values break the ctype check. -if test "${LANG+set}" = set; then LANG=C; export LANG; fi -if test "${LC_ALL+set}" = set; then LC_ALL=C; export LC_ALL; fi -if test "${LC_MESSAGES+set}" = set; then LC_MESSAGES=C; export LC_MESSAGES; fi -if test "${LC_CTYPE+set}" = set; then LC_CTYPE=C; export LC_CTYPE; fi +# There might be people who depend on the old broken behavior: `$host' +# used to hold the argument of --host etc. +# FIXME: To remove some day. +build=$build_alias +host=$host_alias +target=$target_alias + +# FIXME: To remove some day. +if test "x$host_alias" != x; then + if test "x$build_alias" = x; then + cross_compiling=maybe + echo "$as_me: WARNING: If you wanted to set the --build type, don't use --host. + If a cross compiler is detected then cross compile mode will be used." >&2 + elif test "x$build_alias" != "x$host_alias"; then + cross_compiling=yes + fi +fi -# confdefs.h avoids OS command line length limits that DEFS can exceed. -rm -rf conftest* confdefs.h -# AIX cpp loses on an empty file, so make sure it contains at least a newline. -echo > confdefs.h +ac_tool_prefix= +test -n "$host_alias" && ac_tool_prefix=$host_alias- + +test "$silent" = yes && exec 6>/dev/null -# A filename unique to this package, relative to the directory that -# configure is in, which we can look for to find out if srcdir is correct. -ac_unique_file=queryperf.c # Find the source files, if location was not specified. if test -z "$srcdir"; then ac_srcdir_defaulted=yes # Try the directory containing this script, then its parent. - ac_prog=$0 - ac_confdir=`echo $ac_prog|sed 's%/[^/][^/]*$%%'` - test "x$ac_confdir" = "x$ac_prog" && ac_confdir=. + ac_confdir=`(dirname "$0") 2>/dev/null || +$as_expr X"$0" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \ + X"$0" : 'X\(//\)[^/]' \| \ + X"$0" : 'X\(//\)$' \| \ + X"$0" : 'X\(/\)' \| \ + . : '\(.\)' 2>/dev/null || +echo X"$0" | + sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/; q; } + /^X\(\/\/\)[^/].*/{ s//\1/; q; } + /^X\(\/\/\)$/{ s//\1/; q; } + /^X\(\/\).*/{ s//\1/; q; } + s/.*/./; q'` srcdir=$ac_confdir if test ! -r $srcdir/$ac_unique_file; then srcdir=.. @@ -469,13 +675,357 @@ else fi if test ! -r $srcdir/$ac_unique_file; then if test "$ac_srcdir_defaulted" = yes; then - { echo "configure: error: can not find sources in $ac_confdir or .." 1>&2; exit 1; } + { echo "$as_me: error: cannot find sources ($ac_unique_file) in $ac_confdir or .." >&2 + { (exit 1); exit 1; }; } else - { echo "configure: error: can not find sources in $srcdir" 1>&2; exit 1; } + { echo "$as_me: error: cannot find sources ($ac_unique_file) in $srcdir" >&2 + { (exit 1); exit 1; }; } fi fi -srcdir=`echo "${srcdir}" | sed 's%\([^/]\)/*$%\1%'` +srcdir=`echo "$srcdir" | sed 's%\([^\\/]\)[\\/]*$%\1%'` +ac_env_build_alias_set=${build_alias+set} +ac_env_build_alias_value=$build_alias +ac_cv_env_build_alias_set=${build_alias+set} +ac_cv_env_build_alias_value=$build_alias +ac_env_host_alias_set=${host_alias+set} +ac_env_host_alias_value=$host_alias +ac_cv_env_host_alias_set=${host_alias+set} +ac_cv_env_host_alias_value=$host_alias +ac_env_target_alias_set=${target_alias+set} +ac_env_target_alias_value=$target_alias +ac_cv_env_target_alias_set=${target_alias+set} +ac_cv_env_target_alias_value=$target_alias +ac_env_CC_set=${CC+set} +ac_env_CC_value=$CC +ac_cv_env_CC_set=${CC+set} +ac_cv_env_CC_value=$CC +ac_env_CFLAGS_set=${CFLAGS+set} +ac_env_CFLAGS_value=$CFLAGS +ac_cv_env_CFLAGS_set=${CFLAGS+set} +ac_cv_env_CFLAGS_value=$CFLAGS +ac_env_LDFLAGS_set=${LDFLAGS+set} +ac_env_LDFLAGS_value=$LDFLAGS +ac_cv_env_LDFLAGS_set=${LDFLAGS+set} +ac_cv_env_LDFLAGS_value=$LDFLAGS +ac_env_CPPFLAGS_set=${CPPFLAGS+set} +ac_env_CPPFLAGS_value=$CPPFLAGS +ac_cv_env_CPPFLAGS_set=${CPPFLAGS+set} +ac_cv_env_CPPFLAGS_value=$CPPFLAGS + +# +# Report the --help message. +# +if test "$ac_init_help" = "long"; then + # Omit some internal or obsolete options to make the list less imposing. + # This message is too long to be a string in the A/UX 3.1 sh. + cat <<_ACEOF +\`configure' configures this package to adapt to many kinds of systems. + +Usage: $0 [OPTION]... [VAR=VALUE]... + +To assign environment variables (e.g., CC, CFLAGS...), specify them as +VAR=VALUE. See below for descriptions of some of the useful variables. + +Defaults for the options are specified in brackets. + +Configuration: + -h, --help display this help and exit + --help=short display options specific to this package + --help=recursive display the short help of all the included packages + -V, --version display version information and exit + -q, --quiet, --silent do not print \`checking...' messages + --cache-file=FILE cache test results in FILE [disabled] + -C, --config-cache alias for \`--cache-file=config.cache' + -n, --no-create do not create output files + --srcdir=DIR find the sources in DIR [configure dir or \`..'] + +_ACEOF + + cat <<_ACEOF +Installation directories: + --prefix=PREFIX install architecture-independent files in PREFIX + [$ac_default_prefix] + --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX + [PREFIX] + +By default, \`make install' will install all the files in +\`$ac_default_prefix/bin', \`$ac_default_prefix/lib' etc. You can specify +an installation prefix other than \`$ac_default_prefix' using \`--prefix', +for instance \`--prefix=\$HOME'. + +For better control, use the options below. + +Fine tuning of the installation directories: + --bindir=DIR user executables [EPREFIX/bin] + --sbindir=DIR system admin executables [EPREFIX/sbin] + --libexecdir=DIR program executables [EPREFIX/libexec] + --datadir=DIR read-only architecture-independent data [PREFIX/share] + --sysconfdir=DIR read-only single-machine data [PREFIX/etc] + --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] + --localstatedir=DIR modifiable single-machine data [PREFIX/var] + --libdir=DIR object code libraries [EPREFIX/lib] + --includedir=DIR C header files [PREFIX/include] + --oldincludedir=DIR C header files for non-gcc [/usr/include] + --infodir=DIR info documentation [PREFIX/info] + --mandir=DIR man documentation [PREFIX/man] +_ACEOF + + cat <<\_ACEOF +_ACEOF +fi + +if test -n "$ac_init_help"; then + + cat <<\_ACEOF + +Some influential environment variables: + CC C compiler command + CFLAGS C compiler flags + LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a + nonstandard directory <lib dir> + CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have + headers in a nonstandard directory <include dir> + +Use these variables to override the choices made by `configure' or to help +it to find libraries and programs with nonstandard names/locations. + +_ACEOF +fi + +if test "$ac_init_help" = "recursive"; then + # If there are subdirs, report their specific --help. + ac_popdir=`pwd` + for ac_dir in : $ac_subdirs_all; do test "x$ac_dir" = x: && continue + test -d $ac_dir || continue + ac_builddir=. + +if test "$ac_dir" != .; then + ac_dir_suffix=/`echo "$ac_dir" | sed 's,^\.[\\/],,'` + # A "../" for each directory in $ac_dir_suffix. + ac_top_builddir=`echo "$ac_dir_suffix" | sed 's,/[^\\/]*,../,g'` +else + ac_dir_suffix= ac_top_builddir= +fi + +case $srcdir in + .) # No --srcdir option. We are building in place. + ac_srcdir=. + if test -z "$ac_top_builddir"; then + ac_top_srcdir=. + else + ac_top_srcdir=`echo $ac_top_builddir | sed 's,/$,,'` + fi ;; + [\\/]* | ?:[\\/]* ) # Absolute path. + ac_srcdir=$srcdir$ac_dir_suffix; + ac_top_srcdir=$srcdir ;; + *) # Relative path. + ac_srcdir=$ac_top_builddir$srcdir$ac_dir_suffix + ac_top_srcdir=$ac_top_builddir$srcdir ;; +esac +# Don't blindly perform a `cd "$ac_dir"/$ac_foo && pwd` since $ac_foo can be +# absolute. +ac_abs_builddir=`cd "$ac_dir" && cd $ac_builddir && pwd` +ac_abs_top_builddir=`cd "$ac_dir" && cd $ac_top_builddir && pwd` +ac_abs_srcdir=`cd "$ac_dir" && cd $ac_srcdir && pwd` +ac_abs_top_srcdir=`cd "$ac_dir" && cd $ac_top_srcdir && pwd` + + cd $ac_dir + # Check for guested configure; otherwise get Cygnus style configure. + if test -f $ac_srcdir/configure.gnu; then + echo + $SHELL $ac_srcdir/configure.gnu --help=recursive + elif test -f $ac_srcdir/configure; then + echo + $SHELL $ac_srcdir/configure --help=recursive + elif test -f $ac_srcdir/configure.ac || + test -f $ac_srcdir/configure.in; then + echo + $ac_configure --help + else + echo "$as_me: WARNING: no configuration information is in $ac_dir" >&2 + fi + cd $ac_popdir + done +fi + +test -n "$ac_init_help" && exit 0 +if $ac_init_version; then + cat <<\_ACEOF + +Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002 +Free Software Foundation, Inc. +This configure script is free software; the Free Software Foundation +gives unlimited permission to copy, distribute and modify it. +_ACEOF + exit 0 +fi +exec 5>config.log +cat >&5 <<_ACEOF +This file contains any messages produced by compilers while +running configure, to aid debugging if configure makes a mistake. + +It was created by $as_me, which was +generated by GNU Autoconf 2.53. Invocation command line was + + $ $0 $@ + +_ACEOF +{ +cat <<_ASUNAME +## --------- ## +## Platform. ## +## --------- ## + +hostname = `(hostname || uname -n) 2>/dev/null | sed 1q` +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 || echo unknown` +/bin/uname -X = `(/bin/uname -X) 2>/dev/null || echo unknown` + +/bin/arch = `(/bin/arch) 2>/dev/null || echo unknown` +/usr/bin/arch -k = `(/usr/bin/arch -k) 2>/dev/null || echo unknown` +/usr/convex/getsysinfo = `(/usr/convex/getsysinfo) 2>/dev/null || echo unknown` +hostinfo = `(hostinfo) 2>/dev/null || echo unknown` +/bin/machine = `(/bin/machine) 2>/dev/null || echo unknown` +/usr/bin/oslevel = `(/usr/bin/oslevel) 2>/dev/null || echo unknown` +/bin/universe = `(/bin/universe) 2>/dev/null || echo unknown` + +_ASUNAME + +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR +for as_dir in $PATH +do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + echo "PATH: $as_dir" +done + +} >&5 + +cat >&5 <<_ACEOF + + +## ----------- ## +## Core tests. ## +## ----------- ## +_ACEOF + + +# Keep a trace of the command line. +# Strip out --no-create and --no-recursion so they do not pile up. +# Also quote any args containing shell meta-characters. +ac_configure_args= +ac_sep= +for ac_arg +do + case $ac_arg in + -no-create | --no-create | --no-creat | --no-crea | --no-cre \ + | --no-cr | --no-c | -n ) continue ;; + -no-recursion | --no-recursion | --no-recursio | --no-recursi \ + | --no-recurs | --no-recur | --no-recu | --no-rec | --no-re | --no-r) + continue ;; + *" "*|*" "*|*[\[\]\~\#\$\^\&\*\(\)\{\}\\\|\;\<\>\?\"\']*) + ac_arg=`echo "$ac_arg" | sed "s/'/'\\\\\\\\''/g"` ;; + esac + case " $ac_configure_args " in + *" '$ac_arg' "*) ;; # Avoid dups. Use of quotes ensures accuracy. + *) ac_configure_args="$ac_configure_args$ac_sep'$ac_arg'" + ac_sep=" " ;; + esac + # Get rid of the leading space. +done + +# When interrupted or exit'd, cleanup temporary files, and complete +# config.log. We remove comments because anyway the quotes in there +# would cause problems or look ugly. +# WARNING: Be sure not to use single quotes in there, as some shells, +# such as our DU 5.0 friend, will then `close' the trap. +trap 'exit_status=$? + # Save into config.log some information that might help in debugging. + { + echo + cat <<\_ASBOX +## ---------------- ## +## Cache variables. ## +## ---------------- ## +_ASBOX + echo + # The following way of writing the cache mishandles newlines in values, +{ + (set) 2>&1 | + case `(ac_space='"'"' '"'"'; set | grep ac_space) 2>&1` in + *ac_space=\ *) + sed -n \ + "s/'"'"'/'"'"'\\\\'"'"''"'"'/g; + s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1='"'"'\\2'"'"'/p" + ;; + *) + sed -n \ + "s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1=\\2/p" + ;; + esac; +} + echo + if test -s confdefs.h; then + cat <<\_ASBOX +## ----------- ## +## confdefs.h. ## +## ----------- ## +_ASBOX + echo + sed "/^$/d" confdefs.h + echo + fi + test "$ac_signal" != 0 && + echo "$as_me: caught signal $ac_signal" + echo "$as_me: exit $exit_status" + } >&5 + rm -f core core.* *.core && + rm -rf conftest* confdefs* conf$$* $ac_clean_files && + exit $exit_status + ' 0 +for ac_signal in 1 2 13 15; do + trap 'ac_signal='$ac_signal'; { (exit 1); exit 1; }' $ac_signal +done +ac_signal=0 + +# confdefs.h avoids OS command line length limits that DEFS can exceed. +rm -rf conftest* confdefs.h +# AIX cpp loses on an empty file, so make sure it contains at least a newline. +echo >confdefs.h + +# Predefined preprocessor variables. + +cat >>confdefs.h <<_ACEOF +#define PACKAGE_NAME "$PACKAGE_NAME" +_ACEOF + + +cat >>confdefs.h <<_ACEOF +#define PACKAGE_TARNAME "$PACKAGE_TARNAME" +_ACEOF + + +cat >>confdefs.h <<_ACEOF +#define PACKAGE_VERSION "$PACKAGE_VERSION" +_ACEOF + + +cat >>confdefs.h <<_ACEOF +#define PACKAGE_STRING "$PACKAGE_STRING" +_ACEOF + + +cat >>confdefs.h <<_ACEOF +#define PACKAGE_BUGREPORT "$PACKAGE_BUGREPORT" +_ACEOF + + +# Let the site file select an alternate cache file if it wants to. # Prefer explicitly selected file to automatically selected ones. if test -z "$CONFIG_SITE"; then if test "x$prefix" != xNONE; then @@ -486,252 +1036,729 @@ if test -z "$CONFIG_SITE"; then fi for ac_site_file in $CONFIG_SITE; do if test -r "$ac_site_file"; then - echo "loading site script $ac_site_file" + { echo "$as_me:$LINENO: loading site script $ac_site_file" >&5 +echo "$as_me: loading site script $ac_site_file" >&6;} + sed 's/^/| /' "$ac_site_file" >&5 . "$ac_site_file" fi done if test -r "$cache_file"; then - echo "loading cache $cache_file" - . $cache_file + # Some versions of bash will fail to source /dev/null (special + # files actually), so we avoid doing that. + if test -f "$cache_file"; then + { echo "$as_me:$LINENO: loading cache $cache_file" >&5 +echo "$as_me: loading cache $cache_file" >&6;} + case $cache_file in + [\\/]* | ?:[\\/]* ) . $cache_file;; + *) . ./$cache_file;; + esac + fi else - echo "creating cache $cache_file" - > $cache_file + { echo "$as_me:$LINENO: creating cache $cache_file" >&5 +echo "$as_me: creating cache $cache_file" >&6;} + >$cache_file +fi + +# Check that the precious variables saved in the cache have kept the same +# value. +ac_cache_corrupted=false +for ac_var in `(set) 2>&1 | + sed -n 's/^ac_env_\([a-zA-Z_0-9]*\)_set=.*/\1/p'`; do + eval ac_old_set=\$ac_cv_env_${ac_var}_set + eval ac_new_set=\$ac_env_${ac_var}_set + eval ac_old_val="\$ac_cv_env_${ac_var}_value" + eval ac_new_val="\$ac_env_${ac_var}_value" + case $ac_old_set,$ac_new_set in + set,) + { echo "$as_me:$LINENO: error: \`$ac_var' was set to \`$ac_old_val' in the previous run" >&5 +echo "$as_me: error: \`$ac_var' was set to \`$ac_old_val' in the previous run" >&2;} + ac_cache_corrupted=: ;; + ,set) + { echo "$as_me:$LINENO: error: \`$ac_var' was not set in the previous run" >&5 +echo "$as_me: error: \`$ac_var' was not set in the previous run" >&2;} + ac_cache_corrupted=: ;; + ,);; + *) + if test "x$ac_old_val" != "x$ac_new_val"; then + { echo "$as_me:$LINENO: error: \`$ac_var' has changed since the previous run:" >&5 +echo "$as_me: error: \`$ac_var' has changed since the previous run:" >&2;} + { echo "$as_me:$LINENO: former value: $ac_old_val" >&5 +echo "$as_me: former value: $ac_old_val" >&2;} + { echo "$as_me:$LINENO: current value: $ac_new_val" >&5 +echo "$as_me: current value: $ac_new_val" >&2;} + ac_cache_corrupted=: + fi;; + esac + # Pass precious variables to config.status. + if test "$ac_new_set" = set; then + case $ac_new_val in + *" "*|*" "*|*[\[\]\~\#\$\^\&\*\(\)\{\}\\\|\;\<\>\?\"\']*) + ac_arg=$ac_var=`echo "$ac_new_val" | sed "s/'/'\\\\\\\\''/g"` ;; + *) ac_arg=$ac_var=$ac_new_val ;; + esac + case " $ac_configure_args " in + *" '$ac_arg' "*) ;; # Avoid dups. Use of quotes ensures accuracy. + *) ac_configure_args="$ac_configure_args '$ac_arg'" ;; + esac + fi +done +if $ac_cache_corrupted; then + { echo "$as_me:$LINENO: error: changes in the environment can compromise the build" >&5 +echo "$as_me: error: changes in the environment can compromise the build" >&2;} + { { echo "$as_me:$LINENO: error: run \`make distclean' and/or \`rm $cache_file' and start over" >&5 +echo "$as_me: error: run \`make distclean' and/or \`rm $cache_file' and start over" >&2;} + { (exit 1); exit 1; }; } fi ac_ext=c -# CFLAGS is not in ac_cpp because -g, -O, etc. are not valid cpp options. ac_cpp='$CPP $CPPFLAGS' -ac_compile='${CC-cc} -c $CFLAGS $CPPFLAGS conftest.$ac_ext 1>&5' -ac_link='${CC-cc} -o conftest${ac_exeext} $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS 1>&5' -cross_compiling=$ac_cv_prog_cc_cross - -ac_exeext= -ac_objext=o -if (echo "testing\c"; echo 1,2,3) | grep c >/dev/null; then - # Stardent Vistra SVR4 grep lacks -e, says ghazi@caip.rutgers.edu. - if (echo -n testing; echo 1,2,3) | sed s/-n/xn/ | grep xn >/dev/null; then - ac_n= ac_c=' -' ac_t=' ' - else - ac_n=-n ac_c= ac_t= +ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5' +ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5' +ac_compiler_gnu=$ac_cv_c_compiler_gnu + + + + + + + + + + + + + + + + + + + + + +ac_ext=c +ac_cpp='$CPP $CPPFLAGS' +ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5' +ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5' +ac_compiler_gnu=$ac_cv_c_compiler_gnu +if test -n "$ac_tool_prefix"; then + # Extract the first word of "${ac_tool_prefix}gcc", so it can be a program name with args. +set dummy ${ac_tool_prefix}gcc; ac_word=$2 +echo "$as_me:$LINENO: checking for $ac_word" >&5 +echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 +if test "${ac_cv_prog_CC+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + if test -n "$CC"; then + ac_cv_prog_CC="$CC" # Let the user override the test. +else +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR +for as_dir in $PATH +do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for ac_exec_ext in '' $ac_executable_extensions; do + if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then + ac_cv_prog_CC="${ac_tool_prefix}gcc" + echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 + break 2 fi +done +done + +fi +fi +CC=$ac_cv_prog_CC +if test -n "$CC"; then + echo "$as_me:$LINENO: result: $CC" >&5 +echo "${ECHO_T}$CC" >&6 else - ac_n= ac_c='\c' ac_t= + echo "$as_me:$LINENO: result: no" >&5 +echo "${ECHO_T}no" >&6 fi +fi +if test -z "$ac_cv_prog_CC"; then + ac_ct_CC=$CC + # Extract the first word of "gcc", so it can be a program name with args. +set dummy gcc; ac_word=$2 +echo "$as_me:$LINENO: checking for $ac_word" >&5 +echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 +if test "${ac_cv_prog_ac_ct_CC+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + if test -n "$ac_ct_CC"; then + ac_cv_prog_ac_ct_CC="$ac_ct_CC" # Let the user override the test. +else +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR +for as_dir in $PATH +do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for ac_exec_ext in '' $ac_executable_extensions; do + if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then + ac_cv_prog_ac_ct_CC="gcc" + echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 + break 2 + fi +done +done +fi +fi +ac_ct_CC=$ac_cv_prog_ac_ct_CC +if test -n "$ac_ct_CC"; then + echo "$as_me:$LINENO: result: $ac_ct_CC" >&5 +echo "${ECHO_T}$ac_ct_CC" >&6 +else + echo "$as_me:$LINENO: result: no" >&5 +echo "${ECHO_T}no" >&6 +fi + CC=$ac_ct_CC +else + CC="$ac_cv_prog_CC" +fi - -# Extract the first word of "gcc", so it can be a program name with args. -set dummy gcc; ac_word=$2 -echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:531: checking for $ac_word" >&5 -if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 +if test -z "$CC"; then + if test -n "$ac_tool_prefix"; then + # Extract the first word of "${ac_tool_prefix}cc", so it can be a program name with args. +set dummy ${ac_tool_prefix}cc; ac_word=$2 +echo "$as_me:$LINENO: checking for $ac_word" >&5 +echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 +if test "${ac_cv_prog_CC+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 else if test -n "$CC"; then ac_cv_prog_CC="$CC" # Let the user override the test. else - IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":" - ac_dummy="$PATH" - for ac_dir in $ac_dummy; do - test -z "$ac_dir" && ac_dir=. - if test -f $ac_dir/$ac_word; then - ac_cv_prog_CC="gcc" - break - fi - done - IFS="$ac_save_ifs" +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR +for as_dir in $PATH +do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for ac_exec_ext in '' $ac_executable_extensions; do + if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then + ac_cv_prog_CC="${ac_tool_prefix}cc" + echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 + break 2 + fi +done +done + fi fi -CC="$ac_cv_prog_CC" +CC=$ac_cv_prog_CC if test -n "$CC"; then - echo "$ac_t""$CC" 1>&6 + echo "$as_me:$LINENO: result: $CC" >&5 +echo "${ECHO_T}$CC" >&6 else - echo "$ac_t""no" 1>&6 + echo "$as_me:$LINENO: result: no" >&5 +echo "${ECHO_T}no" >&6 fi +fi +if test -z "$ac_cv_prog_CC"; then + ac_ct_CC=$CC + # Extract the first word of "cc", so it can be a program name with args. +set dummy cc; ac_word=$2 +echo "$as_me:$LINENO: checking for $ac_word" >&5 +echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 +if test "${ac_cv_prog_ac_ct_CC+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + if test -n "$ac_ct_CC"; then + ac_cv_prog_ac_ct_CC="$ac_ct_CC" # Let the user override the test. +else +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR +for as_dir in $PATH +do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for ac_exec_ext in '' $ac_executable_extensions; do + if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then + ac_cv_prog_ac_ct_CC="cc" + echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 + break 2 + fi +done +done + +fi +fi +ac_ct_CC=$ac_cv_prog_ac_ct_CC +if test -n "$ac_ct_CC"; then + echo "$as_me:$LINENO: result: $ac_ct_CC" >&5 +echo "${ECHO_T}$ac_ct_CC" >&6 +else + echo "$as_me:$LINENO: result: no" >&5 +echo "${ECHO_T}no" >&6 +fi + + CC=$ac_ct_CC +else + CC="$ac_cv_prog_CC" +fi + +fi if test -z "$CC"; then # Extract the first word of "cc", so it can be a program name with args. set dummy cc; ac_word=$2 -echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:561: checking for $ac_word" >&5 -if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 +echo "$as_me:$LINENO: checking for $ac_word" >&5 +echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 +if test "${ac_cv_prog_CC+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 else if test -n "$CC"; then ac_cv_prog_CC="$CC" # Let the user override the test. else - IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":" ac_prog_rejected=no - ac_dummy="$PATH" - for ac_dir in $ac_dummy; do - test -z "$ac_dir" && ac_dir=. - if test -f $ac_dir/$ac_word; then - if test "$ac_dir/$ac_word" = "/usr/ucb/cc"; then - ac_prog_rejected=yes - continue - fi - ac_cv_prog_CC="cc" - break - fi - done - IFS="$ac_save_ifs" +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR +for as_dir in $PATH +do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for ac_exec_ext in '' $ac_executable_extensions; do + if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then + if test "$as_dir/$ac_word$ac_exec_ext" = "/usr/ucb/cc"; then + ac_prog_rejected=yes + continue + fi + ac_cv_prog_CC="cc" + echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 + break 2 + fi +done +done + if test $ac_prog_rejected = yes; then # We found a bogon in the path, so make sure we never use it. set dummy $ac_cv_prog_CC shift - if test $# -gt 0; then + if test $# != 0; then # We chose a different compiler from the bogus one. # However, it has the same basename, so the bogon will be chosen # first if we set CC to just the basename; use the full file name. shift - set dummy "$ac_dir/$ac_word" "$@" + set dummy "$as_dir/$ac_word" ${1+"$@"} shift ac_cv_prog_CC="$@" fi fi fi fi -CC="$ac_cv_prog_CC" +CC=$ac_cv_prog_CC if test -n "$CC"; then - echo "$ac_t""$CC" 1>&6 + echo "$as_me:$LINENO: result: $CC" >&5 +echo "${ECHO_T}$CC" >&6 else - echo "$ac_t""no" 1>&6 + echo "$as_me:$LINENO: result: no" >&5 +echo "${ECHO_T}no" >&6 fi - if test -z "$CC"; then - case "`uname -s`" in - *win32* | *WIN32*) - # Extract the first word of "cl", so it can be a program name with args. -set dummy cl; ac_word=$2 -echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:612: checking for $ac_word" >&5 -if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 +fi +if test -z "$CC"; then + if test -n "$ac_tool_prefix"; then + for ac_prog in cl + do + # Extract the first word of "$ac_tool_prefix$ac_prog", so it can be a program name with args. +set dummy $ac_tool_prefix$ac_prog; ac_word=$2 +echo "$as_me:$LINENO: checking for $ac_word" >&5 +echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 +if test "${ac_cv_prog_CC+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 else if test -n "$CC"; then ac_cv_prog_CC="$CC" # Let the user override the test. else - IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":" - ac_dummy="$PATH" - for ac_dir in $ac_dummy; do - test -z "$ac_dir" && ac_dir=. - if test -f $ac_dir/$ac_word; then - ac_cv_prog_CC="cl" - break - fi - done - IFS="$ac_save_ifs" +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR +for as_dir in $PATH +do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for ac_exec_ext in '' $ac_executable_extensions; do + if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then + ac_cv_prog_CC="$ac_tool_prefix$ac_prog" + echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 + break 2 + fi +done +done + fi fi -CC="$ac_cv_prog_CC" +CC=$ac_cv_prog_CC if test -n "$CC"; then - echo "$ac_t""$CC" 1>&6 + echo "$as_me:$LINENO: result: $CC" >&5 +echo "${ECHO_T}$CC" >&6 else - echo "$ac_t""no" 1>&6 + echo "$as_me:$LINENO: result: no" >&5 +echo "${ECHO_T}no" >&6 fi - ;; - esac + + test -n "$CC" && break + done +fi +if test -z "$CC"; then + ac_ct_CC=$CC + for ac_prog in cl +do + # Extract the first word of "$ac_prog", so it can be a program name with args. +set dummy $ac_prog; ac_word=$2 +echo "$as_me:$LINENO: checking for $ac_word" >&5 +echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6 +if test "${ac_cv_prog_ac_ct_CC+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + if test -n "$ac_ct_CC"; then + ac_cv_prog_ac_ct_CC="$ac_ct_CC" # Let the user override the test. +else +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR +for as_dir in $PATH +do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for ac_exec_ext in '' $ac_executable_extensions; do + if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then + ac_cv_prog_ac_ct_CC="$ac_prog" + echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5 + break 2 fi - test -z "$CC" && { echo "configure: error: no acceptable cc found in \$PATH" 1>&2; exit 1; } +done +done + fi +fi +ac_ct_CC=$ac_cv_prog_ac_ct_CC +if test -n "$ac_ct_CC"; then + echo "$as_me:$LINENO: result: $ac_ct_CC" >&5 +echo "${ECHO_T}$ac_ct_CC" >&6 +else + echo "$as_me:$LINENO: result: no" >&5 +echo "${ECHO_T}no" >&6 +fi + + test -n "$ac_ct_CC" && break +done -echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works""... $ac_c" 1>&6 -echo "configure:644: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works" >&5 + CC=$ac_ct_CC +fi -ac_ext=c -# CFLAGS is not in ac_cpp because -g, -O, etc. are not valid cpp options. -ac_cpp='$CPP $CPPFLAGS' -ac_compile='${CC-cc} -c $CFLAGS $CPPFLAGS conftest.$ac_ext 1>&5' -ac_link='${CC-cc} -o conftest${ac_exeext} $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS 1>&5' -cross_compiling=$ac_cv_prog_cc_cross +fi -cat > conftest.$ac_ext << EOF -#line 655 "configure" +test -z "$CC" && { { echo "$as_me:$LINENO: error: no acceptable C compiler found in \$PATH" >&5 +echo "$as_me: error: no acceptable C compiler found in \$PATH" >&2;} + { (exit 1); exit 1; }; } + +# Provide some information about the compiler. +echo "$as_me:$LINENO:" \ + "checking for C compiler version" >&5 +ac_compiler=`set X $ac_compile; echo $2` +{ (eval echo "$as_me:$LINENO: \"$ac_compiler --version </dev/null >&5\"") >&5 + (eval $ac_compiler --version </dev/null >&5) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } +{ (eval echo "$as_me:$LINENO: \"$ac_compiler -v </dev/null >&5\"") >&5 + (eval $ac_compiler -v </dev/null >&5) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } +{ (eval echo "$as_me:$LINENO: \"$ac_compiler -V </dev/null >&5\"") >&5 + (eval $ac_compiler -V </dev/null >&5) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } + +cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" #include "confdefs.h" -main(){return(0);} -EOF -if { (eval echo configure:660: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then - ac_cv_prog_cc_works=yes - # If we can't run a trivial program, we are probably using a cross compiler. - if (./conftest; exit) 2>/dev/null; then - ac_cv_prog_cc_cross=no +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ + + ; + return 0; +} +_ACEOF +ac_clean_files_save=$ac_clean_files +ac_clean_files="$ac_clean_files a.out a.exe" +# Try to create an executable without -o first, disregard a.out. +# It will help us diagnose broken compilers, and finding out an intuition +# of exeext. +echo "$as_me:$LINENO: checking for C compiler default output" >&5 +echo $ECHO_N "checking for C compiler default output... $ECHO_C" >&6 +ac_link_default=`echo "$ac_link" | sed 's/ -o *conftest[^ ]*//'` +if { (eval echo "$as_me:$LINENO: \"$ac_link_default\"") >&5 + (eval $ac_link_default) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; then + # Find the output, starting from the most likely. This scheme is +# not robust to junk in `.', hence go to wildcards (a.*) only as a last +# resort. + +# Be careful to initialize this variable, since it used to be cached. +# Otherwise an old cache value of `no' led to `EXEEXT = no' in a Makefile. +ac_cv_exeext= +for ac_file in `ls a_out.exe a.exe conftest.exe 2>/dev/null; + ls a.out conftest 2>/dev/null; + ls a.* conftest.* 2>/dev/null`; do + case $ac_file in + *.$ac_ext | *.o | *.obj | *.xcoff | *.tds | *.d | *.pdb | *.xSYM ) ;; + a.out ) # We found the default executable, but exeext='' is most + # certainly right. + break;; + *.* ) ac_cv_exeext=`expr "$ac_file" : '[^.]*\(\..*\)'` + # FIXME: I believe we export ac_cv_exeext for Libtool --akim. + export ac_cv_exeext + break;; + * ) break;; + esac +done +else + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +{ { echo "$as_me:$LINENO: error: C compiler cannot create executables" >&5 +echo "$as_me: error: C compiler cannot create executables" >&2;} + { (exit 77); exit 77; }; } +fi + +ac_exeext=$ac_cv_exeext +echo "$as_me:$LINENO: result: $ac_file" >&5 +echo "${ECHO_T}$ac_file" >&6 + +# Check the compiler produces executables we can run. If not, either +# the compiler is broken, or we cross compile. +echo "$as_me:$LINENO: checking whether the C compiler works" >&5 +echo $ECHO_N "checking whether the C compiler works... $ECHO_C" >&6 +# FIXME: These cross compiler hacks should be removed for Autoconf 3.0 +# If not cross compiling, check that we can run a simple program. +if test "$cross_compiling" != yes; then + if { ac_try='./$ac_file' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + cross_compiling=no else - ac_cv_prog_cc_cross=yes + if test "$cross_compiling" = maybe; then + cross_compiling=yes + else + { { echo "$as_me:$LINENO: error: cannot run C compiled programs. +If you meant to cross compile, use \`--host'." >&5 +echo "$as_me: error: cannot run C compiled programs. +If you meant to cross compile, use \`--host'." >&2;} + { (exit 1); exit 1; }; } + fi fi +fi +echo "$as_me:$LINENO: result: yes" >&5 +echo "${ECHO_T}yes" >&6 + +rm -f a.out a.exe conftest$ac_cv_exeext +ac_clean_files=$ac_clean_files_save +# Check the compiler produces executables we can run. If not, either +# the compiler is broken, or we cross compile. +echo "$as_me:$LINENO: checking whether we are cross compiling" >&5 +echo $ECHO_N "checking whether we are cross compiling... $ECHO_C" >&6 +echo "$as_me:$LINENO: result: $cross_compiling" >&5 +echo "${ECHO_T}$cross_compiling" >&6 + +echo "$as_me:$LINENO: checking for suffix of executables" >&5 +echo $ECHO_N "checking for suffix of executables... $ECHO_C" >&6 +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 + (eval $ac_link) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; then + # If both `conftest.exe' and `conftest' are `present' (well, observable) +# catch `conftest.exe'. For instance with Cygwin, `ls conftest' will +# work properly (i.e., refer to `conftest.exe'), while it won't with +# `rm'. +for ac_file in `(ls conftest.exe; ls conftest; ls conftest.*) 2>/dev/null`; do + case $ac_file in + *.$ac_ext | *.o | *.obj | *.xcoff | *.tds | *.d | *.pdb ) ;; + *.* ) ac_cv_exeext=`expr "$ac_file" : '[^.]*\(\..*\)'` + export ac_cv_exeext + break;; + * ) break;; + esac +done else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - ac_cv_prog_cc_works=no + { { echo "$as_me:$LINENO: error: cannot compute suffix of executables: cannot compile and link" >&5 +echo "$as_me: error: cannot compute suffix of executables: cannot compile and link" >&2;} + { (exit 1); exit 1; }; } fi -rm -fr conftest* -ac_ext=c -# CFLAGS is not in ac_cpp because -g, -O, etc. are not valid cpp options. -ac_cpp='$CPP $CPPFLAGS' -ac_compile='${CC-cc} -c $CFLAGS $CPPFLAGS conftest.$ac_ext 1>&5' -ac_link='${CC-cc} -o conftest${ac_exeext} $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS 1>&5' -cross_compiling=$ac_cv_prog_cc_cross - -echo "$ac_t""$ac_cv_prog_cc_works" 1>&6 -if test $ac_cv_prog_cc_works = no; then - { echo "configure: error: installation or configuration problem: C compiler cannot create executables." 1>&2; exit 1; } -fi -echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler""... $ac_c" 1>&6 -echo "configure:686: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler" >&5 -echo "$ac_t""$ac_cv_prog_cc_cross" 1>&6 -cross_compiling=$ac_cv_prog_cc_cross - -echo $ac_n "checking whether we are using GNU C""... $ac_c" 1>&6 -echo "configure:691: checking whether we are using GNU C" >&5 -if eval "test \"`echo '$''{'ac_cv_prog_gcc'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - cat > conftest.c <<EOF -#ifdef __GNUC__ - yes; + +rm -f conftest$ac_cv_exeext +echo "$as_me:$LINENO: result: $ac_cv_exeext" >&5 +echo "${ECHO_T}$ac_cv_exeext" >&6 + +rm -f conftest.$ac_ext +EXEEXT=$ac_cv_exeext +ac_exeext=$EXEEXT +echo "$as_me:$LINENO: checking for suffix of object files" >&5 +echo $ECHO_N "checking for suffix of object files... $ECHO_C" >&6 +if test "${ac_cv_objext+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" +#include "confdefs.h" + +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } #endif -EOF -if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:700: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then - ac_cv_prog_gcc=yes +int +main () +{ + + ; + return 0; +} +_ACEOF +rm -f conftest.o conftest.obj +if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 + (eval $ac_compile) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; then + for ac_file in `(ls conftest.o conftest.obj; ls conftest.*) 2>/dev/null`; do + case $ac_file in + *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb ) ;; + *) ac_cv_objext=`expr "$ac_file" : '.*\.\(.*\)'` + break;; + esac +done else - ac_cv_prog_gcc=no + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +{ { echo "$as_me:$LINENO: error: cannot compute suffix of object files: cannot compile" >&5 +echo "$as_me: error: cannot compute suffix of object files: cannot compile" >&2;} + { (exit 1); exit 1; }; } fi + +rm -f conftest.$ac_cv_objext conftest.$ac_ext fi +echo "$as_me:$LINENO: result: $ac_cv_objext" >&5 +echo "${ECHO_T}$ac_cv_objext" >&6 +OBJEXT=$ac_cv_objext +ac_objext=$OBJEXT +echo "$as_me:$LINENO: checking whether we are using the GNU C compiler" >&5 +echo $ECHO_N "checking whether we are using the GNU C compiler... $ECHO_C" >&6 +if test "${ac_cv_c_compiler_gnu+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" +#include "confdefs.h" -echo "$ac_t""$ac_cv_prog_gcc" 1>&6 +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ +#ifndef __GNUC__ + choke me +#endif -if test $ac_cv_prog_gcc = yes; then - GCC=yes + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 + (eval $ac_compile) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest.$ac_objext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_compiler_gnu=yes else - GCC= + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +ac_compiler_gnu=no fi +rm -f conftest.$ac_objext conftest.$ac_ext +ac_cv_c_compiler_gnu=$ac_compiler_gnu -ac_test_CFLAGS="${CFLAGS+set}" -ac_save_CFLAGS="$CFLAGS" -CFLAGS= -echo $ac_n "checking whether ${CC-cc} accepts -g""... $ac_c" 1>&6 -echo "configure:719: checking whether ${CC-cc} accepts -g" >&5 -if eval "test \"`echo '$''{'ac_cv_prog_cc_g'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 +fi +echo "$as_me:$LINENO: result: $ac_cv_c_compiler_gnu" >&5 +echo "${ECHO_T}$ac_cv_c_compiler_gnu" >&6 +GCC=`test $ac_compiler_gnu = yes && echo yes` +ac_test_CFLAGS=${CFLAGS+set} +ac_save_CFLAGS=$CFLAGS +CFLAGS="-g" +echo "$as_me:$LINENO: checking whether $CC accepts -g" >&5 +echo $ECHO_N "checking whether $CC accepts -g... $ECHO_C" >&6 +if test "${ac_cv_prog_cc_g+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 else - echo 'void f(){}' > conftest.c -if test -z "`${CC-cc} -g -c conftest.c 2>&1`"; then + cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" +#include "confdefs.h" + +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ + + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 + (eval $ac_compile) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest.$ac_objext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then ac_cv_prog_cc_g=yes else - ac_cv_prog_cc_g=no + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +ac_cv_prog_cc_g=no fi -rm -f conftest* - +rm -f conftest.$ac_objext conftest.$ac_ext fi - -echo "$ac_t""$ac_cv_prog_cc_g" 1>&6 +echo "$as_me:$LINENO: result: $ac_cv_prog_cc_g" >&5 +echo "${ECHO_T}$ac_cv_prog_cc_g" >&6 if test "$ac_test_CFLAGS" = set; then - CFLAGS="$ac_save_CFLAGS" + CFLAGS=$ac_save_CFLAGS elif test $ac_cv_prog_cc_g = yes; then if test "$GCC" = yes; then CFLAGS="-g -O2" @@ -745,452 +1772,1512 @@ else CFLAGS= fi fi +# Some people use a C++ compiler to compile C. Since we use `exit', +# in C++ we need to declare it. In case someone uses the same compiler +# for both compiling C and C++ we need to have the C++ compiler decide +# the declaration of exit, since it's the most demanding environment. +cat >conftest.$ac_ext <<_ACEOF +#ifndef __cplusplus + choke me +#endif +_ACEOF +rm -f conftest.$ac_objext +if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 + (eval $ac_compile) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest.$ac_objext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + for ac_declaration in \ + ''\ + '#include <stdlib.h>' \ + 'extern "C" void std::exit (int) throw (); using std::exit;' \ + 'extern "C" void std::exit (int); using std::exit;' \ + 'extern "C" void exit (int) throw ();' \ + 'extern "C" void exit (int);' \ + 'void exit (int);' +do + cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" +#include "confdefs.h" +#include <stdlib.h> +$ac_declaration +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ +exit (42); + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 + (eval $ac_compile) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest.$ac_objext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + : +else + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +continue +fi +rm -f conftest.$ac_objext conftest.$ac_ext + cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" +#include "confdefs.h" +$ac_declaration +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ +exit (42); + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 + (eval $ac_compile) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest.$ac_objext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + break +else + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +fi +rm -f conftest.$ac_objext conftest.$ac_ext +done +rm -f conftest* +if test -n "$ac_declaration"; then + echo '#ifdef __cplusplus' >>confdefs.h + echo $ac_declaration >>confdefs.h + echo '#endif' >>confdefs.h +fi +else + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +fi +rm -f conftest.$ac_objext conftest.$ac_ext +ac_ext=c +ac_cpp='$CPP $CPPFLAGS' +ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5' +ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5' +ac_compiler_gnu=$ac_cv_c_compiler_gnu -echo $ac_n "checking for library containing res_mkquery""... $ac_c" 1>&6 -echo "configure:755: checking for library containing res_mkquery" >&5 -if eval "test \"`echo '$''{'ac_cv_search_res_mkquery'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 + + + +echo "$as_me:$LINENO: checking for library containing res_mkquery" >&5 +echo $ECHO_N "checking for library containing res_mkquery... $ECHO_C" >&6 +if test "${ac_cv_search_res_mkquery+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 else - ac_func_search_save_LIBS="$LIBS" -ac_cv_search_res_mkquery="no" -cat > conftest.$ac_ext <<EOF -#line 762 "configure" + ac_func_search_save_LIBS=$LIBS +ac_cv_search_res_mkquery=no +cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" #include "confdefs.h" + /* Override any gcc2 internal prototype to avoid an error. */ +#ifdef __cplusplus +extern "C" +#endif /* We use char because int might match the return type of a gcc2 - builtin and then its argument prototype would still apply. */ -char res_mkquery(); - -int main() { -res_mkquery() -; return 0; } -EOF -if { (eval echo configure:773: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then - rm -rf conftest* + builtin and then its argument prototype would still apply. */ +char res_mkquery (); +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ +res_mkquery (); + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext conftest$ac_exeext +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 + (eval $ac_link) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest$ac_exeext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then ac_cv_search_res_mkquery="none required" else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 fi -rm -f conftest* -test "$ac_cv_search_res_mkquery" = "no" && for i in resolv bind; do -LIBS="-l$i $ac_func_search_save_LIBS" -cat > conftest.$ac_ext <<EOF -#line 784 "configure" +rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext +if test "$ac_cv_search_res_mkquery" = no; then + for ac_lib in resolv bind; do + LIBS="-l$ac_lib $ac_func_search_save_LIBS" + cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" #include "confdefs.h" + /* Override any gcc2 internal prototype to avoid an error. */ +#ifdef __cplusplus +extern "C" +#endif /* We use char because int might match the return type of a gcc2 - builtin and then its argument prototype would still apply. */ -char res_mkquery(); - -int main() { -res_mkquery() -; return 0; } -EOF -if { (eval echo configure:795: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then - rm -rf conftest* - ac_cv_search_res_mkquery="-l$i" + builtin and then its argument prototype would still apply. */ +char res_mkquery (); +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ +res_mkquery (); + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext conftest$ac_exeext +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 + (eval $ac_link) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest$ac_exeext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_cv_search_res_mkquery="-l$ac_lib" break else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 fi -rm -f conftest* -done -LIBS="$ac_func_search_save_LIBS" +rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext + done fi - -echo "$ac_t""$ac_cv_search_res_mkquery" 1>&6 -if test "$ac_cv_search_res_mkquery" != "no"; then +LIBS=$ac_func_search_save_LIBS +fi +echo "$as_me:$LINENO: result: $ac_cv_search_res_mkquery" >&5 +echo "${ECHO_T}$ac_cv_search_res_mkquery" >&6 +if test "$ac_cv_search_res_mkquery" != no; then test "$ac_cv_search_res_mkquery" = "none required" || LIBS="$ac_cv_search_res_mkquery $LIBS" - -else : - -fi; -echo $ac_n "checking for socket in -lsocket""... $ac_c" 1>&6 -echo "configure:816: checking for socket in -lsocket" >&5 -ac_lib_var=`echo socket'_'socket | sed 'y%./+-%__p_%'` -if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - ac_save_LIBS="$LIBS" + +fi + + +echo "$as_me:$LINENO: checking for socket in -lsocket" >&5 +echo $ECHO_N "checking for socket in -lsocket... $ECHO_C" >&6 +if test "${ac_cv_lib_socket_socket+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + ac_check_lib_save_LIBS=$LIBS LIBS="-lsocket $LIBS" -cat > conftest.$ac_ext <<EOF -#line 824 "configure" +cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" #include "confdefs.h" + /* Override any gcc2 internal prototype to avoid an error. */ +#ifdef __cplusplus +extern "C" +#endif /* We use char because int might match the return type of a gcc2 - builtin and then its argument prototype would still apply. */ -char socket(); - -int main() { -socket() -; return 0; } -EOF -if { (eval echo configure:835: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then - rm -rf conftest* - eval "ac_cv_lib_$ac_lib_var=yes" -else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -rf conftest* - eval "ac_cv_lib_$ac_lib_var=no" + builtin and then its argument prototype would still apply. */ +char socket (); +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ +socket (); + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext conftest$ac_exeext +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 + (eval $ac_link) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest$ac_exeext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_cv_lib_socket_socket=yes +else + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +ac_cv_lib_socket_socket=no fi -rm -f conftest* -LIBS="$ac_save_LIBS" - +rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext +LIBS=$ac_check_lib_save_LIBS fi -if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then - echo "$ac_t""yes" 1>&6 - ac_tr_lib=HAVE_LIB`echo socket | sed -e 's/[^a-zA-Z0-9_]/_/g' \ - -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/'` - cat >> confdefs.h <<EOF -#define $ac_tr_lib 1 -EOF +echo "$as_me:$LINENO: result: $ac_cv_lib_socket_socket" >&5 +echo "${ECHO_T}$ac_cv_lib_socket_socket" >&6 +if test $ac_cv_lib_socket_socket = yes; then + cat >>confdefs.h <<_ACEOF +#define HAVE_LIBSOCKET 1 +_ACEOF LIBS="-lsocket $LIBS" -else - echo "$ac_t""no" 1>&6 fi -echo $ac_n "checking for inet_ntoa in -lnsl""... $ac_c" 1>&6 -echo "configure:863: checking for inet_ntoa in -lnsl" >&5 -ac_lib_var=`echo nsl'_'inet_ntoa | sed 'y%./+-%__p_%'` -if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 + +echo "$as_me:$LINENO: checking for inet_ntoa in -lnsl" >&5 +echo $ECHO_N "checking for inet_ntoa in -lnsl... $ECHO_C" >&6 +if test "${ac_cv_lib_nsl_inet_ntoa+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 else - ac_save_LIBS="$LIBS" + ac_check_lib_save_LIBS=$LIBS LIBS="-lnsl $LIBS" -cat > conftest.$ac_ext <<EOF -#line 871 "configure" +cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" #include "confdefs.h" + /* Override any gcc2 internal prototype to avoid an error. */ +#ifdef __cplusplus +extern "C" +#endif /* We use char because int might match the return type of a gcc2 - builtin and then its argument prototype would still apply. */ -char inet_ntoa(); - -int main() { -inet_ntoa() -; return 0; } -EOF -if { (eval echo configure:882: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then - rm -rf conftest* - eval "ac_cv_lib_$ac_lib_var=yes" -else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -rf conftest* - eval "ac_cv_lib_$ac_lib_var=no" + builtin and then its argument prototype would still apply. */ +char inet_ntoa (); +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ +inet_ntoa (); + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext conftest$ac_exeext +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 + (eval $ac_link) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest$ac_exeext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_cv_lib_nsl_inet_ntoa=yes +else + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +ac_cv_lib_nsl_inet_ntoa=no fi -rm -f conftest* -LIBS="$ac_save_LIBS" - +rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext +LIBS=$ac_check_lib_save_LIBS fi -if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then - echo "$ac_t""yes" 1>&6 - ac_tr_lib=HAVE_LIB`echo nsl | sed -e 's/[^a-zA-Z0-9_]/_/g' \ - -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/'` - cat >> confdefs.h <<EOF -#define $ac_tr_lib 1 -EOF +echo "$as_me:$LINENO: result: $ac_cv_lib_nsl_inet_ntoa" >&5 +echo "${ECHO_T}$ac_cv_lib_nsl_inet_ntoa" >&6 +if test $ac_cv_lib_nsl_inet_ntoa = yes; then + cat >>confdefs.h <<_ACEOF +#define HAVE_LIBNSL 1 +_ACEOF LIBS="-lnsl $LIBS" +fi + + +for ac_func in gethostbyname2 +do +as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh` +echo "$as_me:$LINENO: checking for $ac_func" >&5 +echo $ECHO_N "checking for $ac_func... $ECHO_C" >&6 +if eval "test \"\${$as_ac_var+set}\" = set"; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" +#include "confdefs.h" +/* System header to define __stub macros and hopefully few prototypes, + which can conflict with char $ac_func (); below. */ +#include <assert.h> +/* Override any gcc2 internal prototype to avoid an error. */ +#ifdef __cplusplus +extern "C" +#endif +/* We use char because int might match the return type of a gcc2 + builtin and then its argument prototype would still apply. */ +char $ac_func (); +char (*f) (); + +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ +/* The GNU C library defines this for functions which it implements + to always fail with ENOSYS. Some functions are actually named + something starting with __ and the normal name is an alias. */ +#if defined (__stub_$ac_func) || defined (__stub___$ac_func) +choke me +#else +f = $ac_func; +#endif + + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext conftest$ac_exeext +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 + (eval $ac_link) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest$ac_exeext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + eval "$as_ac_var=yes" +else + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +eval "$as_ac_var=no" +fi +rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext +fi +echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_var'}'`" >&5 +echo "${ECHO_T}`eval echo '${'$as_ac_var'}'`" >&6 +if test `eval echo '${'$as_ac_var'}'` = yes; then + cat >>confdefs.h <<_ACEOF +#define `echo "HAVE_$ac_func" | $as_tr_cpp` 1 +_ACEOF + +fi +done + +echo "$as_me:$LINENO: checking for getaddrinfo" >&5 +echo $ECHO_N "checking for getaddrinfo... $ECHO_C" >&6 +if test "${ac_cv_func_getaddrinfo+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" +#include "confdefs.h" +/* System header to define __stub macros and hopefully few prototypes, + which can conflict with char getaddrinfo (); below. */ +#include <assert.h> +/* Override any gcc2 internal prototype to avoid an error. */ +#ifdef __cplusplus +extern "C" +#endif +/* We use char because int might match the return type of a gcc2 + builtin and then its argument prototype would still apply. */ +char getaddrinfo (); +char (*f) (); + +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ +/* The GNU C library defines this for functions which it implements + to always fail with ENOSYS. Some functions are actually named + something starting with __ and the normal name is an alias. */ +#if defined (__stub_getaddrinfo) || defined (__stub___getaddrinfo) +choke me +#else +f = getaddrinfo; +#endif + + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext conftest$ac_exeext +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 + (eval $ac_link) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest$ac_exeext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_cv_func_getaddrinfo=yes +else + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +ac_cv_func_getaddrinfo=no +fi +rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext +fi +echo "$as_me:$LINENO: result: $ac_cv_func_getaddrinfo" >&5 +echo "${ECHO_T}$ac_cv_func_getaddrinfo" >&6 +if test $ac_cv_func_getaddrinfo = yes; then + cat >>confdefs.h <<\_ACEOF +#define HAVE_GETADDRINFO 1 +_ACEOF + +else + LIBOBJS="$LIBOBJS getaddrinfo.$ac_objext" +fi + +echo "$as_me:$LINENO: checking for getnameinfo" >&5 +echo $ECHO_N "checking for getnameinfo... $ECHO_C" >&6 +if test "${ac_cv_func_getnameinfo+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" +#include "confdefs.h" +/* System header to define __stub macros and hopefully few prototypes, + which can conflict with char getnameinfo (); below. */ +#include <assert.h> +/* Override any gcc2 internal prototype to avoid an error. */ +#ifdef __cplusplus +extern "C" +#endif +/* We use char because int might match the return type of a gcc2 + builtin and then its argument prototype would still apply. */ +char getnameinfo (); +char (*f) (); + +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ +/* The GNU C library defines this for functions which it implements + to always fail with ENOSYS. Some functions are actually named + something starting with __ and the normal name is an alias. */ +#if defined (__stub_getnameinfo) || defined (__stub___getnameinfo) +choke me +#else +f = getnameinfo; +#endif + + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext conftest$ac_exeext +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 + (eval $ac_link) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest$ac_exeext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_cv_func_getnameinfo=yes +else + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +ac_cv_func_getnameinfo=no +fi +rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext +fi +echo "$as_me:$LINENO: result: $ac_cv_func_getnameinfo" >&5 +echo "${ECHO_T}$ac_cv_func_getnameinfo" >&6 +if test $ac_cv_func_getnameinfo = yes; then + cat >>confdefs.h <<\_ACEOF +#define HAVE_GETNAMEINFO 1 +_ACEOF + else - echo "$ac_t""no" 1>&6 + LIBOBJS="$LIBOBJS getnameinfo.$ac_objext" fi -echo $ac_n "checking for socklen_t""... $ac_c" 1>&6 -echo "configure:910: checking for socklen_t" >&5 -if eval "test \"`echo '$''{'ac_cv_type_socklen_t'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 + +echo "$as_me:$LINENO: checking for socklen_t" >&5 +echo $ECHO_N "checking for socklen_t... $ECHO_C" >&6 +if test "${ac_cv_type_socklen_t+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 else - - cat > conftest.$ac_ext <<EOF -#line 916 "configure" + + cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" #include "confdefs.h" #include <sys/types.h> #include <sys/socket.h> -int main() { +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ socklen_t len = 42; return len; -; return 0; } -EOF -if { (eval echo configure:924: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then - rm -rf conftest* + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 + (eval $ac_compile) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest.$ac_objext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then ac_cv_type_socklen_t=yes else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -rf conftest* - ac_cv_type_socklen_t=no + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +ac_cv_type_socklen_t=no fi -rm -f conftest* +rm -f conftest.$ac_objext conftest.$ac_ext fi - -echo "$ac_t""$ac_cv_type_socklen_t" 1>&6 +echo "$as_me:$LINENO: result: $ac_cv_type_socklen_t" >&5 +echo "${ECHO_T}$ac_cv_type_socklen_t" >&6 if test $ac_cv_type_socklen_t != yes; then - cat >> confdefs.h <<\EOF + cat >>confdefs.h <<\_ACEOF #define socklen_t int -EOF +_ACEOF + + fi + +echo "$as_me:$LINENO: checking for sa_len" >&5 +echo $ECHO_N "checking for sa_len... $ECHO_C" >&6 +if test "${ac_cv_sa_len+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + + cat >conftest.$ac_ext <<_ACEOF +#line $LINENO "configure" +#include "confdefs.h" +#include <sys/types.h> + #include <sys/socket.h> +#ifdef F77_DUMMY_MAIN +# ifdef __cplusplus + extern "C" +# endif + int F77_DUMMY_MAIN() { return 1; } +#endif +int +main () +{ +struct sockaddr sa; sa.sa_len = 0; + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 + (eval $ac_compile) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -s conftest.$ac_objext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_cv_sa_len=yes +else + echo "$as_me: failed program was:" >&5 +cat conftest.$ac_ext >&5 +ac_cv_sa_len=no +fi +rm -f conftest.$ac_objext conftest.$ac_ext + +fi +echo "$as_me:$LINENO: result: $ac_cv_sa_len" >&5 +echo "${ECHO_T}$ac_cv_sa_len" >&6 + if test $ac_cv_sa_len = yes; then + cat >>confdefs.h <<\_ACEOF +#define HAVE_SA_LEN 1 +_ACEOF fi -trap '' 1 2 15 -cat > confcache <<\EOF +ac_config_files="$ac_config_files Makefile" +cat >confcache <<\_ACEOF # This file is a shell script that caches the results of configure # tests run on this system so they can be shared between configure -# scripts and configure runs. It is not useful on other systems. -# If it contains results you don't want to keep, you may remove or edit it. +# scripts and configure runs, see configure's option --config-cache. +# It is not useful on other systems. If it contains results you don't +# want to keep, you may remove or edit it. # -# By default, configure uses ./config.cache as the cache file, -# creating it if it does not exist already. You can give configure -# the --cache-file=FILE option to use a different cache file; that is -# what configure does when it calls configure scripts in -# subdirectories, so they share the cache. -# Giving --cache-file=/dev/null disables caching, for debugging configure. -# config.status only pays attention to the cache file if you give it the -# --recheck option to rerun configure. +# config.status only pays attention to the cache file if you give it +# the --recheck option to rerun configure. # -EOF +# `ac_cv_env_foo' variables (set or unset) will be overriden when +# loading this file, other *unset* `ac_cv_foo' will be assigned the +# following values. + +_ACEOF + # The following way of writing the cache mishandles newlines in values, # but we know of no workaround that is simple, portable, and efficient. # So, don't put newlines in cache variables' values. # Ultrix sh set writes to stderr and can't be redirected directly, # and sets the high bit in the cache file unless we assign to the vars. -(set) 2>&1 | - case `(ac_space=' '; set | grep ac_space) 2>&1` in - *ac_space=\ *) - # `set' does not quote correctly, so add quotes (double-quote substitution - # turns \\\\ into \\, and sed turns \\ into \). - sed -n \ - -e "s/'/'\\\\''/g" \ - -e "s/^\\([a-zA-Z0-9_]*_cv_[a-zA-Z0-9_]*\\)=\\(.*\\)/\\1=\${\\1='\\2'}/p" - ;; - *) - # `set' quotes correctly as required by POSIX, so do not add quotes. - sed -n -e 's/^\([a-zA-Z0-9_]*_cv_[a-zA-Z0-9_]*\)=\(.*\)/\1=${\1=\2}/p' - ;; - esac >> confcache -if cmp -s $cache_file confcache; then - : -else +{ + (set) 2>&1 | + case `(ac_space=' '; set | grep ac_space) 2>&1` in + *ac_space=\ *) + # `set' does not quote correctly, so add quotes (double-quote + # substitution turns \\\\ into \\, and sed turns \\ into \). + sed -n \ + "s/'/'\\\\''/g; + s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1='\\2'/p" + ;; + *) + # `set' quotes correctly as required by POSIX, so do not add quotes. + sed -n \ + "s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1=\\2/p" + ;; + esac; +} | + sed ' + t clear + : clear + s/^\([^=]*\)=\(.*[{}].*\)$/test "${\1+set}" = set || &/ + t end + /^ac_cv_env/!s/^\([^=]*\)=\(.*\)$/\1=${\1=\2}/ + : end' >>confcache +if cmp -s $cache_file confcache; then :; else if test -w $cache_file; then - echo "updating cache $cache_file" - cat confcache > $cache_file + test "x$cache_file" != "x/dev/null" && echo "updating cache $cache_file" + cat confcache >$cache_file else echo "not updating unwritable cache $cache_file" fi fi rm -f confcache -trap 'rm -fr conftest* confdefs* core core.* *.core $ac_clean_files; exit 1' 1 2 15 - test "x$prefix" = xNONE && prefix=$ac_default_prefix # Let make expand exec_prefix. test "x$exec_prefix" = xNONE && exec_prefix='${prefix}' -# Any assignment to VPATH causes Sun make to only execute -# the first set of double-colon rules, so remove it if not needed. -# If there is a colon in the path, we need to keep it. +# VPATH may cause trouble with some makes, so we remove $(srcdir), +# ${srcdir} and @srcdir@ from VPATH if srcdir is ".", strip leading and +# trailing colons and then remove the whole line if VPATH becomes empty +# (actually we leave an empty line to preserve line numbers). if test "x$srcdir" = x.; then - ac_vpsub='/^[ ]*VPATH[ ]*=[^:]*$/d' + ac_vpsub='/^[ ]*VPATH[ ]*=/{ +s/:*\$(srcdir):*/:/; +s/:*\${srcdir}:*/:/; +s/:*@srcdir@:*/:/; +s/^\([^=]*=[ ]*\):*/\1/; +s/:*$//; +s/^[^=]*=[ ]*$//; +}' fi -trap 'rm -f $CONFIG_STATUS conftest*; exit 1' 1 2 15 - # Transform confdefs.h into DEFS. # Protect against shell expansion while executing Makefile rules. # Protect against Makefile macro expansion. -cat > conftest.defs <<\EOF -s%#define \([A-Za-z_][A-Za-z0-9_]*\) *\(.*\)%-D\1=\2%g -s%[ `~#$^&*(){}\\|;'"<>?]%\\&%g -s%\[%\\&%g -s%\]%\\&%g -s%\$%$$%g -EOF -DEFS=`sed -f conftest.defs confdefs.h | tr '\012' ' '` -rm -f conftest.defs - - -# Without the "./", some shells look in PATH for config.status. -: ${CONFIG_STATUS=./config.status} +# +# If the first sed substitution is executed (which looks for macros that +# take arguments), then we branch to the quote section. Otherwise, +# look for a macro that doesn't take arguments. +cat >confdef2opt.sed <<\_ACEOF +t clear +: clear +s,^[ ]*#[ ]*define[ ][ ]*\([^ (][^ (]*([^)]*)\)[ ]*\(.*\),-D\1=\2,g +t quote +s,^[ ]*#[ ]*define[ ][ ]*\([^ ][^ ]*\)[ ]*\(.*\),-D\1=\2,g +t quote +d +: quote +s,[ `~#$^&*(){}\\|;'"<>?],\\&,g +s,\[,\\&,g +s,\],\\&,g +s,\$,$$,g +p +_ACEOF +# We use echo to avoid assuming a particular line-breaking character. +# The extra dot is to prevent the shell from consuming trailing +# line-breaks from the sub-command output. A line-break within +# single-quotes doesn't work because, if this script is created in a +# platform that uses two characters for line-breaks (e.g., DOS), tr +# would break. +ac_LF_and_DOT=`echo; echo .` +DEFS=`sed -n -f confdef2opt.sed confdefs.h | tr "$ac_LF_and_DOT" ' .'` +rm -f confdef2opt.sed -echo creating $CONFIG_STATUS -rm -f $CONFIG_STATUS -cat > $CONFIG_STATUS <<EOF -#! /bin/sh -# Generated automatically by configure. + + +: ${CONFIG_STATUS=./config.status} +ac_clean_files_save=$ac_clean_files +ac_clean_files="$ac_clean_files $CONFIG_STATUS" +{ echo "$as_me:$LINENO: creating $CONFIG_STATUS" >&5 +echo "$as_me: creating $CONFIG_STATUS" >&6;} +cat >$CONFIG_STATUS <<_ACEOF +#! $SHELL +# Generated by $as_me. # Run this file to recreate the current configuration. -# This directory was configured as follows, -# on host `(hostname || uname -n) 2>/dev/null | sed 1q`: -# -# $0 $ac_configure_args -# # Compiler output produced by configure, useful for debugging -# configure, is in ./config.log if it exists. +# configure, is in config.log if it exists. -ac_cs_usage="Usage: $CONFIG_STATUS [--recheck] [--version] [--help]" -for ac_option -do - case "\$ac_option" in - -recheck | --recheck | --rechec | --reche | --rech | --rec | --re | --r) - echo "running \${CONFIG_SHELL-/bin/sh} $0 $ac_configure_args --no-create --no-recursion" - exec \${CONFIG_SHELL-/bin/sh} $0 $ac_configure_args --no-create --no-recursion ;; - -version | --version | --versio | --versi | --vers | --ver | --ve | --v) - echo "$CONFIG_STATUS generated by autoconf version 2.13" - exit 0 ;; - -help | --help | --hel | --he | --h) - echo "\$ac_cs_usage"; exit 0 ;; - *) echo "\$ac_cs_usage"; exit 1 ;; - esac -done +debug=false +SHELL=\${CONFIG_SHELL-$SHELL} +_ACEOF -ac_given_srcdir=$srcdir +cat >>$CONFIG_STATUS <<\_ACEOF -trap 'rm -fr `echo "Makefile" | sed "s/:[^ ]*//g"` conftest*; exit 1' 1 2 15 -EOF -cat >> $CONFIG_STATUS <<EOF +## --------------------- ## +## M4sh Initialization. ## +## --------------------- ## -# Protect against being on the right side of a sed subst in config.status. -sed 's/%@/@@/; s/@%/@@/; s/%g\$/@g/; /@g\$/s/[\\\\&%]/\\\\&/g; - s/@@/%@/; s/@@/@%/; s/@g\$/%g/' > conftest.subs <<\\CEOF -$ac_vpsub -$extrasub -s%@SHELL@%$SHELL%g -s%@CFLAGS@%$CFLAGS%g -s%@CPPFLAGS@%$CPPFLAGS%g -s%@CXXFLAGS@%$CXXFLAGS%g -s%@FFLAGS@%$FFLAGS%g -s%@DEFS@%$DEFS%g -s%@LDFLAGS@%$LDFLAGS%g -s%@LIBS@%$LIBS%g -s%@exec_prefix@%$exec_prefix%g -s%@prefix@%$prefix%g -s%@program_transform_name@%$program_transform_name%g -s%@bindir@%$bindir%g -s%@sbindir@%$sbindir%g -s%@libexecdir@%$libexecdir%g -s%@datadir@%$datadir%g -s%@sysconfdir@%$sysconfdir%g -s%@sharedstatedir@%$sharedstatedir%g -s%@localstatedir@%$localstatedir%g -s%@libdir@%$libdir%g -s%@includedir@%$includedir%g -s%@oldincludedir@%$oldincludedir%g -s%@infodir@%$infodir%g -s%@mandir@%$mandir%g -s%@CC@%$CC%g +# Be Bourne compatible +if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then + emulate sh + NULLCMD=: +elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1; then + set -o posix +fi -CEOF -EOF - -cat >> $CONFIG_STATUS <<\EOF - -# Split the substitutions into bite-sized pieces for seds with -# small command number limits, like on Digital OSF/1 and HP-UX. -ac_max_sed_cmds=90 # Maximum number of lines to put in a sed script. -ac_file=1 # Number of current file. -ac_beg=1 # First line for current file. -ac_end=$ac_max_sed_cmds # Line after last line for current file. -ac_more_lines=: -ac_sed_cmds="" -while $ac_more_lines; do - if test $ac_beg -gt 1; then - sed "1,${ac_beg}d; ${ac_end}q" conftest.subs > conftest.s$ac_file - else - sed "${ac_end}q" conftest.subs > conftest.s$ac_file - fi - if test ! -s conftest.s$ac_file; then - ac_more_lines=false - rm -f conftest.s$ac_file +# NLS nuisances. +# Support unset when possible. +if (FOO=FOO; unset FOO) >/dev/null 2>&1; then + as_unset=unset +else + as_unset=false +fi + +(set +x; test -n "`(LANG=C; export LANG) 2>&1`") && + { $as_unset LANG || test "${LANG+set}" != set; } || + { LANG=C; export LANG; } +(set +x; test -n "`(LC_ALL=C; export LC_ALL) 2>&1`") && + { $as_unset LC_ALL || test "${LC_ALL+set}" != set; } || + { LC_ALL=C; export LC_ALL; } +(set +x; test -n "`(LC_TIME=C; export LC_TIME) 2>&1`") && + { $as_unset LC_TIME || test "${LC_TIME+set}" != set; } || + { LC_TIME=C; export LC_TIME; } +(set +x; test -n "`(LC_CTYPE=C; export LC_CTYPE) 2>&1`") && + { $as_unset LC_CTYPE || test "${LC_CTYPE+set}" != set; } || + { LC_CTYPE=C; export LC_CTYPE; } +(set +x; test -n "`(LANGUAGE=C; export LANGUAGE) 2>&1`") && + { $as_unset LANGUAGE || test "${LANGUAGE+set}" != set; } || + { LANGUAGE=C; export LANGUAGE; } +(set +x; test -n "`(LC_COLLATE=C; export LC_COLLATE) 2>&1`") && + { $as_unset LC_COLLATE || test "${LC_COLLATE+set}" != set; } || + { LC_COLLATE=C; export LC_COLLATE; } +(set +x; test -n "`(LC_NUMERIC=C; export LC_NUMERIC) 2>&1`") && + { $as_unset LC_NUMERIC || test "${LC_NUMERIC+set}" != set; } || + { LC_NUMERIC=C; export LC_NUMERIC; } +(set +x; test -n "`(LC_MESSAGES=C; export LC_MESSAGES) 2>&1`") && + { $as_unset LC_MESSAGES || test "${LC_MESSAGES+set}" != set; } || + { LC_MESSAGES=C; export LC_MESSAGES; } + + +# Name of the executable. +as_me=`(basename "$0") 2>/dev/null || +$as_expr X/"$0" : '.*/\([^/][^/]*\)/*$' \| \ + X"$0" : 'X\(//\)$' \| \ + X"$0" : 'X\(/\)$' \| \ + . : '\(.\)' 2>/dev/null || +echo X/"$0" | + sed '/^.*\/\([^/][^/]*\)\/*$/{ s//\1/; q; } + /^X\/\(\/\/\)$/{ s//\1/; q; } + /^X\/\(\/\).*/{ s//\1/; q; } + s/.*/./; q'` + +# PATH needs CR, and LINENO needs CR and PATH. +# Avoid depending upon Character Ranges. +as_cr_letters='abcdefghijklmnopqrstuvwxyz' +as_cr_LETTERS='ABCDEFGHIJKLMNOPQRSTUVWXYZ' +as_cr_Letters=$as_cr_letters$as_cr_LETTERS +as_cr_digits='0123456789' +as_cr_alnum=$as_cr_Letters$as_cr_digits + +# The user is always right. +if test "${PATH_SEPARATOR+set}" != set; then + echo "#! /bin/sh" >conftest.sh + echo "exit 0" >>conftest.sh + chmod +x conftest.sh + if (PATH=".;."; conftest.sh) >/dev/null 2>&1; then + PATH_SEPARATOR=';' else - if test -z "$ac_sed_cmds"; then - ac_sed_cmds="sed -f conftest.s$ac_file" - else - ac_sed_cmds="$ac_sed_cmds | sed -f conftest.s$ac_file" - fi - ac_file=`expr $ac_file + 1` - ac_beg=$ac_end - ac_end=`expr $ac_end + $ac_max_sed_cmds` + PATH_SEPARATOR=: fi -done -if test -z "$ac_sed_cmds"; then - ac_sed_cmds=cat + rm -f conftest.sh fi -EOF -cat >> $CONFIG_STATUS <<EOF -CONFIG_FILES=\${CONFIG_FILES-"Makefile"} -EOF -cat >> $CONFIG_STATUS <<\EOF -for ac_file in .. $CONFIG_FILES; do if test "x$ac_file" != x..; then - # Support "outfile[:infile[:infile...]]", defaulting infile="outfile.in". - case "$ac_file" in - *:*) ac_file_in=`echo "$ac_file"|sed 's%[^:]*:%%'` - ac_file=`echo "$ac_file"|sed 's%:.*%%'` ;; - *) ac_file_in="${ac_file}.in" ;; + as_lineno_1=$LINENO + as_lineno_2=$LINENO + as_lineno_3=`(expr $as_lineno_1 + 1) 2>/dev/null` + test "x$as_lineno_1" != "x$as_lineno_2" && + test "x$as_lineno_3" = "x$as_lineno_2" || { + # Find who we are. Look in the path if we contain no path at all + # relative or not. + case $0 in + *[\\/]* ) as_myself=$0 ;; + *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR +for as_dir in $PATH +do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + test -r "$as_dir/$0" && as_myself=$as_dir/$0 && break +done + + ;; + esac + # We did not find ourselves, most probably we were run as `sh COMMAND' + # in which case we are not to be found in the path. + if test "x$as_myself" = x; then + as_myself=$0 + fi + if test ! -f "$as_myself"; then + { { echo "$as_me:$LINENO: error: cannot find myself; rerun with an absolute path" >&5 +echo "$as_me: error: cannot find myself; rerun with an absolute path" >&2;} + { (exit 1); exit 1; }; } + fi + case $CONFIG_SHELL in + '') + as_save_IFS=$IFS; IFS=$PATH_SEPARATOR +for as_dir in /bin$PATH_SEPARATOR/usr/bin$PATH_SEPARATOR$PATH +do + IFS=$as_save_IFS + test -z "$as_dir" && as_dir=. + for as_base in sh bash ksh sh5; do + case $as_dir in + /*) + if ("$as_dir/$as_base" -c ' + as_lineno_1=$LINENO + as_lineno_2=$LINENO + as_lineno_3=`(expr $as_lineno_1 + 1) 2>/dev/null` + test "x$as_lineno_1" != "x$as_lineno_2" && + test "x$as_lineno_3" = "x$as_lineno_2" ') 2>/dev/null; then + CONFIG_SHELL=$as_dir/$as_base + export CONFIG_SHELL + exec "$CONFIG_SHELL" "$0" ${1+"$@"} + fi;; + esac + done +done +;; esac - # Adjust a relative srcdir, top_srcdir, and INSTALL for subdirectories. + # Create $as_me.lineno as a copy of $as_myself, but with $LINENO + # uniformly replaced by the line number. The first 'sed' inserts a + # line-number line before each line; the second 'sed' does the real + # work. The second script uses 'N' to pair each line-number line + # with the numbered line, and appends trailing '-' during + # substitution so that $LINENO is not a special case at line end. + # (Raja R Harinath suggested sed '=', and Paul Eggert wrote the + # second 'sed' script. Blame Lee E. McMahon for sed's syntax. :-) + sed '=' <$as_myself | + sed ' + N + s,$,-, + : loop + s,^\(['$as_cr_digits']*\)\(.*\)[$]LINENO\([^'$as_cr_alnum'_]\),\1\2\1\3, + t loop + s,-$,, + s,^['$as_cr_digits']*\n,, + ' >$as_me.lineno && + chmod +x $as_me.lineno || + { { echo "$as_me:$LINENO: error: cannot create $as_me.lineno; rerun with a POSIX shell" >&5 +echo "$as_me: error: cannot create $as_me.lineno; rerun with a POSIX shell" >&2;} + { (exit 1); exit 1; }; } + + # Don't try to exec as it changes $[0], causing all sort of problems + # (the dirname of $[0] is not the place where we might find the + # original and so on. Autoconf is especially sensible to this). + . ./$as_me.lineno + # Exit status is that of the last command. + exit +} + + +case `echo "testing\c"; echo 1,2,3`,`echo -n testing; echo 1,2,3` in + *c*,-n*) ECHO_N= ECHO_C=' +' ECHO_T=' ' ;; + *c*,* ) ECHO_N=-n ECHO_C= ECHO_T= ;; + *) ECHO_N= ECHO_C='\c' ECHO_T= ;; +esac + +if expr a : '\(a\)' >/dev/null 2>&1; then + as_expr=expr +else + as_expr=false +fi - # Remove last slash and all that follows it. Not all systems have dirname. - ac_dir=`echo $ac_file|sed 's%/[^/][^/]*$%%'` - if test "$ac_dir" != "$ac_file" && test "$ac_dir" != .; then - # The file is in a subdirectory. - test ! -d "$ac_dir" && mkdir "$ac_dir" - ac_dir_suffix="/`echo $ac_dir|sed 's%^\./%%'`" - # A "../" for each directory in $ac_dir_suffix. - ac_dots=`echo $ac_dir_suffix|sed 's%/[^/]*%../%g'` +rm -f conf$$ conf$$.exe conf$$.file +echo >conf$$.file +if ln -s conf$$.file conf$$ 2>/dev/null; then + # We could just check for DJGPP; but this test a) works b) is more generic + # and c) will remain valid once DJGPP supports symlinks (DJGPP 2.04). + if test -f conf$$.exe; then + # Don't use ln at all; we don't have any links + as_ln_s='cp -p' else - ac_dir_suffix= ac_dots= + as_ln_s='ln -s' fi +elif ln conf$$.file conf$$ 2>/dev/null; then + as_ln_s=ln +else + as_ln_s='cp -p' +fi +rm -f conf$$ conf$$.exe conf$$.file - case "$ac_given_srcdir" in - .) srcdir=. - if test -z "$ac_dots"; then top_srcdir=. - else top_srcdir=`echo $ac_dots|sed 's%/$%%'`; fi ;; - /*) srcdir="$ac_given_srcdir$ac_dir_suffix"; top_srcdir="$ac_given_srcdir" ;; - *) # Relative path. - srcdir="$ac_dots$ac_given_srcdir$ac_dir_suffix" - top_srcdir="$ac_dots$ac_given_srcdir" ;; +as_executable_p="test -f" + +# Sed expression to map a string onto a valid CPP name. +as_tr_cpp="sed y%*$as_cr_letters%P$as_cr_LETTERS%;s%[^_$as_cr_alnum]%_%g" + +# Sed expression to map a string onto a valid variable name. +as_tr_sh="sed y%*+%pp%;s%[^_$as_cr_alnum]%_%g" + + +# IFS +# We need space, tab and new line, in precisely that order. +as_nl=' +' +IFS=" $as_nl" + +# CDPATH. +$as_unset CDPATH || test "${CDPATH+set}" != set || { CDPATH=$PATH_SEPARATOR; export CDPATH; } + +exec 6>&1 + +# Open the log real soon, to keep \$[0] and so on meaningful, and to +# report actual input values of CONFIG_FILES etc. instead of their +# values after options handling. Logging --version etc. is OK. +exec 5>>config.log +{ + echo + sed 'h;s/./-/g;s/^.../## /;s/...$/ ##/;p;x;p;x' <<_ASBOX +## Running $as_me. ## +_ASBOX +} >&5 +cat >&5 <<_CSEOF + +This file was extended by $as_me, which was +generated by GNU Autoconf 2.53. Invocation command line was + + CONFIG_FILES = $CONFIG_FILES + CONFIG_HEADERS = $CONFIG_HEADERS + CONFIG_LINKS = $CONFIG_LINKS + CONFIG_COMMANDS = $CONFIG_COMMANDS + $ $0 $@ + +_CSEOF +echo "on `(hostname || uname -n) 2>/dev/null | sed 1q`" >&5 +echo >&5 +_ACEOF + +# Files that config.status was made for. +if test -n "$ac_config_files"; then + echo "config_files=\"$ac_config_files\"" >>$CONFIG_STATUS +fi + +if test -n "$ac_config_headers"; then + echo "config_headers=\"$ac_config_headers\"" >>$CONFIG_STATUS +fi + +if test -n "$ac_config_links"; then + echo "config_links=\"$ac_config_links\"" >>$CONFIG_STATUS +fi + +if test -n "$ac_config_commands"; then + echo "config_commands=\"$ac_config_commands\"" >>$CONFIG_STATUS +fi + +cat >>$CONFIG_STATUS <<\_ACEOF + +ac_cs_usage="\ +\`$as_me' instantiates files from templates according to the +current configuration. + +Usage: $0 [OPTIONS] [FILE]... + + -h, --help print this help, then exit + -V, --version print version number, then exit + -d, --debug don't remove temporary files + --recheck update $as_me by reconfiguring in the same conditions + --file=FILE[:TEMPLATE] + instantiate the configuration file FILE + +Configuration files: +$config_files + +Report bugs to <bug-autoconf@gnu.org>." +_ACEOF + +cat >>$CONFIG_STATUS <<_ACEOF +ac_cs_version="\\ +config.status +configured by $0, generated by GNU Autoconf 2.53, + with options \\"`echo "$ac_configure_args" | sed 's/[\\""\`\$]/\\\\&/g'`\\" + +Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001 +Free Software Foundation, Inc. +This config.status script is free software; the Free Software Foundation +gives unlimited permission to copy, distribute and modify it." +srcdir=$srcdir +_ACEOF + +cat >>$CONFIG_STATUS <<\_ACEOF +# If no file are specified by the user, then we need to provide default +# value. By we need to know if files were specified by the user. +ac_need_defaults=: +while test $# != 0 +do + case $1 in + --*=*) + ac_option=`expr "x$1" : 'x\([^=]*\)='` + ac_optarg=`expr "x$1" : 'x[^=]*=\(.*\)'` + shift + set dummy "$ac_option" "$ac_optarg" ${1+"$@"} + shift + ;; + -*);; + *) # This is not an option, so the user has probably given explicit + # arguments. + ac_need_defaults=false;; esac + case $1 in + # Handling of the options. +_ACEOF +cat >>$CONFIG_STATUS <<_ACEOF + -recheck | --recheck | --rechec | --reche | --rech | --rec | --re | --r) + echo "running $SHELL $0 " $ac_configure_args " --no-create --no-recursion" + exec $SHELL $0 $ac_configure_args --no-create --no-recursion ;; +_ACEOF +cat >>$CONFIG_STATUS <<\_ACEOF + --version | --vers* | -V ) + echo "$ac_cs_version"; exit 0 ;; + --he | --h) + # Conflict between --help and --header + { { echo "$as_me:$LINENO: error: ambiguous option: $1 +Try \`$0 --help' for more information." >&5 +echo "$as_me: error: ambiguous option: $1 +Try \`$0 --help' for more information." >&2;} + { (exit 1); exit 1; }; };; + --help | --hel | -h ) + echo "$ac_cs_usage"; exit 0 ;; + --debug | --d* | -d ) + debug=: ;; + --file | --fil | --fi | --f ) + shift + CONFIG_FILES="$CONFIG_FILES $1" + ac_need_defaults=false;; + --header | --heade | --head | --hea ) + shift + CONFIG_HEADERS="$CONFIG_HEADERS $1" + ac_need_defaults=false;; + + # This is an error. + -*) { { echo "$as_me:$LINENO: error: unrecognized option: $1 +Try \`$0 --help' for more information." >&5 +echo "$as_me: error: unrecognized option: $1 +Try \`$0 --help' for more information." >&2;} + { (exit 1); exit 1; }; } ;; + + *) ac_config_targets="$ac_config_targets $1" ;; - echo creating "$ac_file" - rm -f "$ac_file" - configure_input="Generated automatically from `echo $ac_file_in|sed 's%.*/%%'` by configure." - case "$ac_file" in - *Makefile*) ac_comsub="1i\\ -# $configure_input" ;; - *) ac_comsub= ;; esac + shift +done + +_ACEOF - ac_file_inputs=`echo $ac_file_in|sed -e "s%^%$ac_given_srcdir/%" -e "s%:% $ac_given_srcdir/%g"` - sed -e "$ac_comsub -s%@configure_input@%$configure_input%g -s%@srcdir@%$srcdir%g -s%@top_srcdir@%$top_srcdir%g -" $ac_file_inputs | (eval "$ac_sed_cmds") > $ac_file -fi; done -rm -f conftest.s* -EOF -cat >> $CONFIG_STATUS <<EOF -EOF -cat >> $CONFIG_STATUS <<\EOF -exit 0 -EOF + +cat >>$CONFIG_STATUS <<\_ACEOF +for ac_config_target in $ac_config_targets +do + case "$ac_config_target" in + # Handling of arguments. + "Makefile" ) CONFIG_FILES="$CONFIG_FILES Makefile" ;; + *) { { echo "$as_me:$LINENO: error: invalid argument: $ac_config_target" >&5 +echo "$as_me: error: invalid argument: $ac_config_target" >&2;} + { (exit 1); exit 1; }; };; + esac +done + +# If the user did not use the arguments to specify the items to instantiate, +# then the envvar interface is used. Set only those that are not. +# We use the long form for the default assignment because of an extremely +# bizarre bug on SunOS 4.1.3. +if $ac_need_defaults; then + test "${CONFIG_FILES+set}" = set || CONFIG_FILES=$config_files +fi + +# Create a temporary directory, and hook for its removal unless debugging. +$debug || +{ + trap 'exit_status=$?; rm -rf $tmp && exit $exit_status' 0 + trap '{ (exit 1); exit 1; }' 1 2 13 15 +} + +# Create a (secure) tmp directory for tmp files. +: ${TMPDIR=/tmp} +{ + tmp=`(umask 077 && mktemp -d -q "$TMPDIR/csXXXXXX") 2>/dev/null` && + test -n "$tmp" && test -d "$tmp" +} || +{ + tmp=$TMPDIR/cs$$-$RANDOM + (umask 077 && mkdir $tmp) +} || +{ + echo "$me: cannot create a temporary directory in $TMPDIR" >&2 + { (exit 1); exit 1; } +} + +_ACEOF + +cat >>$CONFIG_STATUS <<_ACEOF + +# +# CONFIG_FILES section. +# + +# No need to generate the scripts if there are no CONFIG_FILES. +# This happens for instance when ./config.status config.h +if test -n "\$CONFIG_FILES"; then + # Protect against being on the right side of a sed subst in config.status. + sed 's/,@/@@/; s/@,/@@/; s/,;t t\$/@;t t/; /@;t t\$/s/[\\\\&,]/\\\\&/g; + s/@@/,@/; s/@@/@,/; s/@;t t\$/,;t t/' >\$tmp/subs.sed <<\\CEOF +s,@SHELL@,$SHELL,;t t +s,@PATH_SEPARATOR@,$PATH_SEPARATOR,;t t +s,@PACKAGE_NAME@,$PACKAGE_NAME,;t t +s,@PACKAGE_TARNAME@,$PACKAGE_TARNAME,;t t +s,@PACKAGE_VERSION@,$PACKAGE_VERSION,;t t +s,@PACKAGE_STRING@,$PACKAGE_STRING,;t t +s,@PACKAGE_BUGREPORT@,$PACKAGE_BUGREPORT,;t t +s,@exec_prefix@,$exec_prefix,;t t +s,@prefix@,$prefix,;t t +s,@program_transform_name@,$program_transform_name,;t t +s,@bindir@,$bindir,;t t +s,@sbindir@,$sbindir,;t t +s,@libexecdir@,$libexecdir,;t t +s,@datadir@,$datadir,;t t +s,@sysconfdir@,$sysconfdir,;t t +s,@sharedstatedir@,$sharedstatedir,;t t +s,@localstatedir@,$localstatedir,;t t +s,@libdir@,$libdir,;t t +s,@includedir@,$includedir,;t t +s,@oldincludedir@,$oldincludedir,;t t +s,@infodir@,$infodir,;t t +s,@mandir@,$mandir,;t t +s,@build_alias@,$build_alias,;t t +s,@host_alias@,$host_alias,;t t +s,@target_alias@,$target_alias,;t t +s,@DEFS@,$DEFS,;t t +s,@ECHO_C@,$ECHO_C,;t t +s,@ECHO_N@,$ECHO_N,;t t +s,@ECHO_T@,$ECHO_T,;t t +s,@LIBS@,$LIBS,;t t +s,@CC@,$CC,;t t +s,@CFLAGS@,$CFLAGS,;t t +s,@LDFLAGS@,$LDFLAGS,;t t +s,@CPPFLAGS@,$CPPFLAGS,;t t +s,@ac_ct_CC@,$ac_ct_CC,;t t +s,@EXEEXT@,$EXEEXT,;t t +s,@OBJEXT@,$OBJEXT,;t t +s,@LIBOBJS@,$LIBOBJS,;t t +CEOF + +_ACEOF + + cat >>$CONFIG_STATUS <<\_ACEOF + # Split the substitutions into bite-sized pieces for seds with + # small command number limits, like on Digital OSF/1 and HP-UX. + ac_max_sed_lines=48 + ac_sed_frag=1 # Number of current file. + ac_beg=1 # First line for current file. + ac_end=$ac_max_sed_lines # Line after last line for current file. + ac_more_lines=: + ac_sed_cmds= + while $ac_more_lines; do + if test $ac_beg -gt 1; then + sed "1,${ac_beg}d; ${ac_end}q" $tmp/subs.sed >$tmp/subs.frag + else + sed "${ac_end}q" $tmp/subs.sed >$tmp/subs.frag + fi + if test ! -s $tmp/subs.frag; then + ac_more_lines=false + else + # The purpose of the label and of the branching condition is to + # speed up the sed processing (if there are no `@' at all, there + # is no need to browse any of the substitutions). + # These are the two extra sed commands mentioned above. + (echo ':t + /@[a-zA-Z_][a-zA-Z_0-9]*@/!b' && cat $tmp/subs.frag) >$tmp/subs-$ac_sed_frag.sed + if test -z "$ac_sed_cmds"; then + ac_sed_cmds="sed -f $tmp/subs-$ac_sed_frag.sed" + else + ac_sed_cmds="$ac_sed_cmds | sed -f $tmp/subs-$ac_sed_frag.sed" + fi + ac_sed_frag=`expr $ac_sed_frag + 1` + ac_beg=$ac_end + ac_end=`expr $ac_end + $ac_max_sed_lines` + fi + done + if test -z "$ac_sed_cmds"; then + ac_sed_cmds=cat + fi +fi # test -n "$CONFIG_FILES" + +_ACEOF +cat >>$CONFIG_STATUS <<\_ACEOF +for ac_file in : $CONFIG_FILES; do test "x$ac_file" = x: && continue + # Support "outfile[:infile[:infile...]]", defaulting infile="outfile.in". + case $ac_file in + - | *:- | *:-:* ) # input from stdin + cat >$tmp/stdin + ac_file_in=`echo "$ac_file" | sed 's,[^:]*:,,'` + ac_file=`echo "$ac_file" | sed 's,:.*,,'` ;; + *:* ) ac_file_in=`echo "$ac_file" | sed 's,[^:]*:,,'` + ac_file=`echo "$ac_file" | sed 's,:.*,,'` ;; + * ) ac_file_in=$ac_file.in ;; + esac + + # Compute @srcdir@, @top_srcdir@, and @INSTALL@ for subdirectories. + ac_dir=`(dirname "$ac_file") 2>/dev/null || +$as_expr X"$ac_file" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \ + X"$ac_file" : 'X\(//\)[^/]' \| \ + X"$ac_file" : 'X\(//\)$' \| \ + X"$ac_file" : 'X\(/\)' \| \ + . : '\(.\)' 2>/dev/null || +echo X"$ac_file" | + sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/; q; } + /^X\(\/\/\)[^/].*/{ s//\1/; q; } + /^X\(\/\/\)$/{ s//\1/; q; } + /^X\(\/\).*/{ s//\1/; q; } + s/.*/./; q'` + { case "$ac_dir" in + [\\/]* | ?:[\\/]* ) as_incr_dir=;; + *) as_incr_dir=.;; +esac +as_dummy="$ac_dir" +for as_mkdir_dir in `IFS='/\\'; set X $as_dummy; shift; echo "$@"`; do + case $as_mkdir_dir in + # Skip DOS drivespec + ?:) as_incr_dir=$as_mkdir_dir ;; + *) + as_incr_dir=$as_incr_dir/$as_mkdir_dir + test -d "$as_incr_dir" || + mkdir "$as_incr_dir" || + { { echo "$as_me:$LINENO: error: cannot create \"$ac_dir\"" >&5 +echo "$as_me: error: cannot create \"$ac_dir\"" >&2;} + { (exit 1); exit 1; }; } + ;; + esac +done; } + + ac_builddir=. + +if test "$ac_dir" != .; then + ac_dir_suffix=/`echo "$ac_dir" | sed 's,^\.[\\/],,'` + # A "../" for each directory in $ac_dir_suffix. + ac_top_builddir=`echo "$ac_dir_suffix" | sed 's,/[^\\/]*,../,g'` +else + ac_dir_suffix= ac_top_builddir= +fi + +case $srcdir in + .) # No --srcdir option. We are building in place. + ac_srcdir=. + if test -z "$ac_top_builddir"; then + ac_top_srcdir=. + else + ac_top_srcdir=`echo $ac_top_builddir | sed 's,/$,,'` + fi ;; + [\\/]* | ?:[\\/]* ) # Absolute path. + ac_srcdir=$srcdir$ac_dir_suffix; + ac_top_srcdir=$srcdir ;; + *) # Relative path. + ac_srcdir=$ac_top_builddir$srcdir$ac_dir_suffix + ac_top_srcdir=$ac_top_builddir$srcdir ;; +esac +# Don't blindly perform a `cd "$ac_dir"/$ac_foo && pwd` since $ac_foo can be +# absolute. +ac_abs_builddir=`cd "$ac_dir" && cd $ac_builddir && pwd` +ac_abs_top_builddir=`cd "$ac_dir" && cd $ac_top_builddir && pwd` +ac_abs_srcdir=`cd "$ac_dir" && cd $ac_srcdir && pwd` +ac_abs_top_srcdir=`cd "$ac_dir" && cd $ac_top_srcdir && pwd` + + + + if test x"$ac_file" != x-; then + { echo "$as_me:$LINENO: creating $ac_file" >&5 +echo "$as_me: creating $ac_file" >&6;} + rm -f "$ac_file" + fi + # Let's still pretend it is `configure' which instantiates (i.e., don't + # use $as_me), people would be surprised to read: + # /* config.h. Generated by config.status. */ + if test x"$ac_file" = x-; then + configure_input= + else + configure_input="$ac_file. " + fi + configure_input=$configure_input"Generated from `echo $ac_file_in | + sed 's,.*/,,'` by configure." + + # First look for the input files in the build tree, otherwise in the + # src tree. + ac_file_inputs=`IFS=: + for f in $ac_file_in; do + case $f in + -) echo $tmp/stdin ;; + [\\/$]*) + # Absolute (can't be DOS-style, as IFS=:) + test -f "$f" || { { echo "$as_me:$LINENO: error: cannot find input file: $f" >&5 +echo "$as_me: error: cannot find input file: $f" >&2;} + { (exit 1); exit 1; }; } + echo $f;; + *) # Relative + if test -f "$f"; then + # Build tree + echo $f + elif test -f "$srcdir/$f"; then + # Source tree + echo $srcdir/$f + else + # /dev/null tree + { { echo "$as_me:$LINENO: error: cannot find input file: $f" >&5 +echo "$as_me: error: cannot find input file: $f" >&2;} + { (exit 1); exit 1; }; } + fi;; + esac + done` || { (exit 1); exit 1; } +_ACEOF +cat >>$CONFIG_STATUS <<_ACEOF + sed "$ac_vpsub +$extrasub +_ACEOF +cat >>$CONFIG_STATUS <<\_ACEOF +:t +/@[a-zA-Z_][a-zA-Z_0-9]*@/!b +s,@configure_input@,$configure_input,;t t +s,@srcdir@,$ac_srcdir,;t t +s,@abs_srcdir@,$ac_abs_srcdir,;t t +s,@top_srcdir@,$ac_top_srcdir,;t t +s,@abs_top_srcdir@,$ac_abs_top_srcdir,;t t +s,@builddir@,$ac_builddir,;t t +s,@abs_builddir@,$ac_abs_builddir,;t t +s,@top_builddir@,$ac_top_builddir,;t t +s,@abs_top_builddir@,$ac_abs_top_builddir,;t t +" $ac_file_inputs | (eval "$ac_sed_cmds") >$tmp/out + rm -f $tmp/stdin + if test x"$ac_file" != x-; then + mv $tmp/out $ac_file + else + cat $tmp/out + rm -f $tmp/out + fi + +done +_ACEOF + +cat >>$CONFIG_STATUS <<\_ACEOF + +{ (exit 0); exit 0; } +_ACEOF chmod +x $CONFIG_STATUS -rm -fr confdefs* $ac_clean_files -test "$no_create" = yes || ${CONFIG_SHELL-/bin/sh} $CONFIG_STATUS || exit 1 +ac_clean_files=$ac_clean_files_save + + +# configure is writing to config.log, and then calls config.status. +# config.status does its own redirection, appending to config.log. +# Unfortunately, on DOS this fails, as config.log is still kept open +# by configure, so config.status won't be able to write to it; its +# output is simply discarded. So we exec the FD to /dev/null, +# effectively closing config.log, so it can be properly (re)opened and +# appended to by config.status. When coming back to configure, we +# need to make the FD available again. +if test "$no_create" != yes; then + ac_cs_success=: + exec 5>/dev/null + $SHELL $CONFIG_STATUS || ac_cs_success=false + exec 5>>config.log + # Use ||, not &&, to avoid exiting from the if with $? = 1, which + # would make configure fail if this is the last instruction. + $ac_cs_success || { (exit 1); exit 1; } +fi diff --git a/dist/bind/contrib/queryperf/configure.in b/dist/bind/contrib/queryperf/configure.in index 1b7737fad59..efbd9462c19 100644 --- a/dist/bind/contrib/queryperf/configure.in +++ b/dist/bind/contrib/queryperf/configure.in @@ -36,9 +36,31 @@ AC_DEFUN(AC_TYPE_SOCKLEN_T, fi ]) -AC_SEARCH_LIBS(res_mkquery, resolv bind); +AC_DEFUN(AC_SA_LEN, +[AC_CACHE_CHECK([for sa_len], ac_cv_sa_len, +[ + AC_TRY_COMPILE( + [#include <sys/types.h> + #include <sys/socket.h>], + [struct sockaddr sa; sa.sa_len = 0;], + ac_cv_sa_len=yes, + ac_cv_sa_len=no) +]) + if test $ac_cv_sa_len = yes; then + AC_DEFINE(HAVE_SA_LEN) + fi +]) + +AC_SEARCH_LIBS(res_mkquery, resolv bind) AC_CHECK_LIB(socket, socket) AC_CHECK_LIB(nsl, inet_ntoa) +AC_CHECK_FUNCS(gethostbyname2) +AC_CHECK_FUNC(getaddrinfo, + AC_DEFINE(HAVE_GETADDRINFO), AC_LIBOBJ(getaddrinfo)) +AC_CHECK_FUNC(getnameinfo, + AC_DEFINE(HAVE_GETNAMEINFO), AC_LIBOBJ(getnameinfo)) + AC_TYPE_SOCKLEN_T +AC_SA_LEN AC_OUTPUT(Makefile) diff --git a/dist/bind/contrib/queryperf/missing/addrinfo.h b/dist/bind/contrib/queryperf/missing/addrinfo.h new file mode 100644 index 00000000000..a44aa72022b --- /dev/null +++ b/dist/bind/contrib/queryperf/missing/addrinfo.h @@ -0,0 +1,91 @@ +/* $NetBSD: addrinfo.h,v 1.1.1.1 2004/11/06 23:54:25 christos Exp $ */ + +/* + * 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: addrinfo.h,v 1.2.4.2 2004/08/19 04:41:13 marka Exp */ + +#ifndef HAVE_GETADDRINFO + +/* + * Error return codes from getaddrinfo() + */ +#define EAI_ADDRFAMILY 1 /* address family for hostname not supported */ +#define EAI_AGAIN 2 /* temporary failure in name resolution */ +#define EAI_BADFLAGS 3 /* invalid value for ai_flags */ +#define EAI_FAIL 4 /* non-recoverable failure in name resolution */ +#define EAI_FAMILY 5 /* ai_family not supported */ +#define EAI_MEMORY 6 /* memory allocation failure */ +#define EAI_NODATA 7 /* no address associated with hostname */ +#define EAI_NONAME 8 /* hostname nor servname provided, or not known */ +#define EAI_SERVICE 9 /* servname not supported for ai_socktype */ +#define EAI_SOCKTYPE 10 /* ai_socktype not supported */ +#define EAI_SYSTEM 11 /* system error returned in errno */ +#define EAI_BADHINTS 12 +#define EAI_PROTOCOL 13 +#define EAI_MAX 14 + +/* + * Flag values for getaddrinfo() + */ +#define AI_PASSIVE 0x00000001 /* get address to use bind() */ +#define AI_CANONNAME 0x00000002 /* fill ai_canonname */ +#define AI_NUMERICHOST 0x00000004 /* prevent name resolution */ +/* valid flags for addrinfo */ +#define AI_MASK (AI_PASSIVE | AI_CANONNAME | AI_NUMERICHOST) + +#define AI_ALL 0x00000100 /* IPv6 and IPv4-mapped (with AI_V4MAPPED) */ +#define AI_V4MAPPED_CFG 0x00000200 /* accept IPv4-mapped if kernel supports */ +#define AI_ADDRCONFIG 0x00000400 /* only if any address is assigned */ +#define AI_V4MAPPED 0x00000800 /* accept IPv4-mapped IPv6 address */ +/* special recommended flags for getipnodebyname */ +#define AI_DEFAULT (AI_V4MAPPED_CFG | AI_ADDRCONFIG) + +/* + * Constants for getnameinfo() + */ +#define NI_MAXHOST 1025 +#define NI_MAXSERV 32 + +/* + * Flag values for getnameinfo() + */ +#define NI_NOFQDN 0x00000001 +#define NI_NUMERICHOST 0x00000002 +#define NI_NAMEREQD 0x00000004 +#define NI_NUMERICSERV 0x00000008 +#define NI_DGRAM 0x00000010 + +struct addrinfo { + int ai_flags; /* AI_PASSIVE, AI_CANONNAME */ + int ai_family; /* PF_xxx */ + int ai_socktype; /* SOCK_xxx */ + int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ + size_t ai_addrlen; /* length of ai_addr */ + char *ai_canonname; /* canonical name for hostname */ + struct sockaddr *ai_addr; /* binary address */ + struct addrinfo *ai_next; /* next structure in linked list */ +}; + +struct sockaddr_storage { + u_char __ss_len; + u_char __ss_family; + u_char fill[126]; +}; + +extern void freehostent(struct hostent *); +extern char *gai_strerror(int); +#endif diff --git a/dist/bind/contrib/queryperf/missing/getaddrinfo.c b/dist/bind/contrib/queryperf/missing/getaddrinfo.c new file mode 100644 index 00000000000..be0761e308f --- /dev/null +++ b/dist/bind/contrib/queryperf/missing/getaddrinfo.c @@ -0,0 +1,623 @@ +/* $NetBSD: getaddrinfo.c,v 1.1.1.1 2004/11/06 23:54:25 christos Exp $ */ + +/* + * 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: getaddrinfo.c,v 1.2.4.2 2004/08/19 04:41:13 marka Exp */ + +#include <sys/types.h> +#include <sys/param.h> +#include <sys/socket.h> +#include <netinet/in.h> +#include <arpa/inet.h> +#include <arpa/nameser.h> +#include <netdb.h> +#include <resolv.h> +#include <string.h> +#include <stdlib.h> +#include <stddef.h> +#include <ctype.h> +#include <unistd.h> + +#include "addrinfo.h" + +#define SUCCESS 0 +#define ANY 0 +#define YES 1 +#define NO 0 + +static const char in_addrany[] = { 0, 0, 0, 0 }; +static const char in6_addrany[] = { + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 +}; +static const char in_loopback[] = { 127, 0, 0, 1 }; +static const char in6_loopback[] = { + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1 +}; + +struct sockinet { + u_char si_len; + u_char si_family; + u_short si_port; +}; + +static struct afd { + int a_af; + int a_addrlen; + int a_socklen; + int a_off; + const char *a_addrany; + const char *a_loopback; +} afdl [] = { +#ifdef INET6 +#define N_INET6 0 + {PF_INET6, sizeof(struct in6_addr), + sizeof(struct sockaddr_in6), + offsetof(struct sockaddr_in6, sin6_addr), + in6_addrany, in6_loopback}, +#define N_INET 1 +#else +#define N_INET 0 +#endif + {PF_INET, sizeof(struct in_addr), + sizeof(struct sockaddr_in), + offsetof(struct sockaddr_in, sin_addr), + in_addrany, in_loopback}, + {0, 0, 0, 0, NULL, NULL}, +}; + +#ifdef INET6 +#define PTON_MAX 16 +#else +#define PTON_MAX 4 +#endif + + +static int get_name(const char *, struct afd *, + struct addrinfo **, char *, struct addrinfo *, + int); +static int get_addr(const char *, int, struct addrinfo **, + struct addrinfo *, int); +static int get_addr0(const char *, int, struct addrinfo **, + struct addrinfo *, int); +static int str_isnumber(const char *); + +static char *ai_errlist[] = { + "Success", + "Address family for hostname not supported", /* EAI_ADDRFAMILY */ + "Temporary failure in name resolution", /* EAI_AGAIN */ + "Invalid value for ai_flags", /* EAI_BADFLAGS */ + "Non-recoverable failure in name resolution", /* EAI_FAIL */ + "ai_family not supported", /* EAI_FAMILY */ + "Memory allocation failure", /* EAI_MEMORY */ + "No address associated with hostname", /* EAI_NODATA */ + "hostname nor servname provided, or not known",/* EAI_NONAME */ + "servname not supported for ai_socktype", /* EAI_SERVICE */ + "ai_socktype not supported", /* EAI_SOCKTYPE */ + "System error returned in errno", /* EAI_SYSTEM */ + "Invalid value for hints", /* EAI_BADHINTS */ + "Resolved protocol is unknown", /* EAI_PROTOCOL */ + "Unknown error", /* EAI_MAX */ +}; + +#define GET_CANONNAME(ai, str) \ +if (pai->ai_flags & AI_CANONNAME) {\ + if (((ai)->ai_canonname = (char *)malloc(strlen(str) + 1)) != NULL) {\ + strcpy((ai)->ai_canonname, (str));\ + } else {\ + error = EAI_MEMORY;\ + goto free;\ + }\ +} + +#ifdef HAVE_SA_LEN +#define SET_AILEN(ai,l) (ai)->ai_addr->sa_len = (ai)->ai_addrlen = (l) +#else +#define SET_AILEN(ai,l) (ai)->ai_addrlen = (l) +#endif + +#define GET_AI(ai, afd, addr, port) {\ + char *p;\ + if (((ai) = (struct addrinfo *)malloc(sizeof(struct addrinfo) +\ + ((afd)->a_socklen)))\ + == NULL) {\ + error = EAI_MEMORY;\ + goto free;\ + }\ + memcpy(ai, pai, sizeof(struct addrinfo));\ + (ai)->ai_addr = (struct sockaddr *)((ai) + 1);\ + memset((ai)->ai_addr, 0, (afd)->a_socklen);\ + SET_AILEN((ai), (afd)->a_socklen);\ + (ai)->ai_addr->sa_family = (ai)->ai_family = (afd)->a_af;\ + ((struct sockinet *)(ai)->ai_addr)->si_port = port;\ + p = (char *)((ai)->ai_addr);\ + memcpy(p + (afd)->a_off, (addr), (afd)->a_addrlen);\ +} + +#define ERR(err) { error = (err); goto bad; } + +char * +gai_strerror(ecode) + int ecode; +{ + if (ecode < 0 || ecode > EAI_MAX) + ecode = EAI_MAX; + return ai_errlist[ecode]; +} + +void +freeaddrinfo(ai) + struct addrinfo *ai; +{ + struct addrinfo *next; + + do { + next = ai->ai_next; + if (ai->ai_canonname) + free(ai->ai_canonname); + /* no need to free(ai->ai_addr) */ + free(ai); + } while ((ai = next) != NULL); +} + +static int +str_isnumber(p) + const char *p; +{ + char *q = (char *)p; + while (*q) { + if (! isdigit(*q)) + return NO; + q++; + } + return YES; +} + +int +getaddrinfo(hostname, servname, hints, res) + const char *hostname, *servname; + const struct addrinfo *hints; + struct addrinfo **res; +{ + struct addrinfo sentinel; + struct addrinfo *top = NULL; + struct addrinfo *cur; + int i, error = 0; + char pton[PTON_MAX]; + struct addrinfo ai; + struct addrinfo *pai; + u_short port; + + /* initialize file static vars */ + sentinel.ai_next = NULL; + cur = &sentinel; + pai = &ai; + pai->ai_flags = 0; + pai->ai_family = PF_UNSPEC; + pai->ai_socktype = ANY; + pai->ai_protocol = ANY; + pai->ai_addrlen = 0; + pai->ai_canonname = NULL; + pai->ai_addr = NULL; + pai->ai_next = NULL; + port = ANY; + + if (hostname == NULL && servname == NULL) + return EAI_NONAME; + if (hints) { + /* error check for hints */ + if (hints->ai_addrlen || hints->ai_canonname || + hints->ai_addr || hints->ai_next) + ERR(EAI_BADHINTS); /* xxx */ + if (hints->ai_flags & ~AI_MASK) + ERR(EAI_BADFLAGS); + switch (hints->ai_family) { + case PF_UNSPEC: + case PF_INET: +#ifdef INET6 + case PF_INET6: +#endif + break; + default: + ERR(EAI_FAMILY); + } + memcpy(pai, hints, sizeof(*pai)); + switch (pai->ai_socktype) { + case ANY: + switch (pai->ai_protocol) { + case ANY: + break; + case IPPROTO_UDP: + pai->ai_socktype = SOCK_DGRAM; + break; + case IPPROTO_TCP: + pai->ai_socktype = SOCK_STREAM; + break; + default: + pai->ai_socktype = SOCK_RAW; + break; + } + break; + case SOCK_RAW: + break; + case SOCK_DGRAM: + if (pai->ai_protocol != IPPROTO_UDP && + pai->ai_protocol != ANY) + ERR(EAI_BADHINTS); /*xxx*/ + pai->ai_protocol = IPPROTO_UDP; + break; + case SOCK_STREAM: + if (pai->ai_protocol != IPPROTO_TCP && + pai->ai_protocol != ANY) + ERR(EAI_BADHINTS); /*xxx*/ + pai->ai_protocol = IPPROTO_TCP; + break; + default: + ERR(EAI_SOCKTYPE); + break; + } + } + + /* + * service port + */ + if (servname) { + if (str_isnumber(servname)) { + if (pai->ai_socktype == ANY) { + /* caller accept *ANY* socktype */ + pai->ai_socktype = SOCK_DGRAM; + pai->ai_protocol = IPPROTO_UDP; + } + port = htons(atoi(servname)); + } else { + struct servent *sp; + char *proto; + + proto = NULL; + switch (pai->ai_socktype) { + case ANY: + proto = NULL; + break; + case SOCK_DGRAM: + proto = "udp"; + break; + case SOCK_STREAM: + proto = "tcp"; + break; + default: + fprintf(stderr, "panic!\n"); + break; + } + if ((sp = getservbyname(servname, proto)) == NULL) + ERR(EAI_SERVICE); + port = sp->s_port; + if (pai->ai_socktype == ANY) { + if (strcmp(sp->s_proto, "udp") == 0) { + pai->ai_socktype = SOCK_DGRAM; + pai->ai_protocol = IPPROTO_UDP; + } else if (strcmp(sp->s_proto, "tcp") == 0) { + pai->ai_socktype = SOCK_STREAM; + pai->ai_protocol = IPPROTO_TCP; + } else + ERR(EAI_PROTOCOL); /*xxx*/ + } + } + } + + /* + * hostname == NULL. + * passive socket -> anyaddr (0.0.0.0 or ::) + * non-passive socket -> localhost (127.0.0.1 or ::1) + */ + if (hostname == NULL) { + struct afd *afd; + int s; + + for (afd = &afdl[0]; afd->a_af; afd++) { + if (!(pai->ai_family == PF_UNSPEC + || pai->ai_family == afd->a_af)) { + continue; + } + + /* + * filter out AFs that are not supported by the kernel + * XXX errno? + */ + s = socket(afd->a_af, SOCK_DGRAM, 0); + if (s < 0) + continue; + close(s); + + if (pai->ai_flags & AI_PASSIVE) { + GET_AI(cur->ai_next, afd, afd->a_addrany, port); + /* xxx meaningless? + * GET_CANONNAME(cur->ai_next, "anyaddr"); + */ + } else { + GET_AI(cur->ai_next, afd, afd->a_loopback, + port); + /* xxx meaningless? + * GET_CANONNAME(cur->ai_next, "localhost"); + */ + } + cur = cur->ai_next; + } + top = sentinel.ai_next; + if (top) + goto good; + else + ERR(EAI_FAMILY); + } + + /* hostname as numeric name */ + for (i = 0; afdl[i].a_af; i++) { + if (inet_pton(afdl[i].a_af, hostname, pton) == 1) { + u_long v4a; + u_char pfx; + + switch (afdl[i].a_af) { + case AF_INET: + v4a = ntohl(((struct in_addr *)pton)->s_addr); + if (IN_MULTICAST(v4a) || IN_EXPERIMENTAL(v4a)) + pai->ai_flags &= ~AI_CANONNAME; + v4a >>= IN_CLASSA_NSHIFT; + if (v4a == 0 || v4a == IN_LOOPBACKNET) + pai->ai_flags &= ~AI_CANONNAME; + break; +#ifdef INET6 + case AF_INET6: + pfx = ((struct in6_addr *)pton)->s6_addr[0]; + if (pfx == 0 || pfx == 0xfe || pfx == 0xff) + pai->ai_flags &= ~AI_CANONNAME; + break; +#endif + } + + if (pai->ai_family == afdl[i].a_af || + pai->ai_family == PF_UNSPEC) { + if (! (pai->ai_flags & AI_CANONNAME)) { + GET_AI(top, &afdl[i], pton, port); + goto good; + } + /* + * if AI_CANONNAME and if reverse lookup + * fail, return ai anyway to pacify + * calling application. + * + * XXX getaddrinfo() is a name->address + * translation function, and it looks strange + * that we do addr->name translation here. + */ + get_name(pton, &afdl[i], &top, pton, pai, port); + goto good; + } else + ERR(EAI_FAMILY); /*xxx*/ + } + } + + if (pai->ai_flags & AI_NUMERICHOST) + ERR(EAI_NONAME); + + /* hostname as alphabetical name */ + error = get_addr(hostname, pai->ai_family, &top, pai, port); + if (error == 0) { + if (top) { + good: + *res = top; + return SUCCESS; + } else + error = EAI_FAIL; + } + free: + if (top) + freeaddrinfo(top); + bad: + *res = NULL; + return error; +} + +static int +get_name(addr, afd, res, numaddr, pai, port0) + const char *addr; + struct afd *afd; + struct addrinfo **res; + char *numaddr; + struct addrinfo *pai; + int port0; +{ + u_short port = port0 & 0xffff; + struct hostent *hp; + struct addrinfo *cur; + int error = 0; + hp = gethostbyaddr(addr, afd->a_addrlen, afd->a_af); + if (hp && hp->h_name && hp->h_name[0] && hp->h_addr_list[0]) { + GET_AI(cur, afd, hp->h_addr_list[0], port); + GET_CANONNAME(cur, hp->h_name); + } else + GET_AI(cur, afd, numaddr, port); + + *res = cur; + return SUCCESS; + free: + if (cur) + freeaddrinfo(cur); + + /* bad: */ + *res = NULL; + return error; +} + +static int +get_addr(hostname, af, res0, pai, port0) + const char *hostname; + int af; + struct addrinfo **res0; + struct addrinfo *pai; + int port0; +{ + int i, error, ekeep; + struct addrinfo *cur; + struct addrinfo **res; + int retry; + int s; + + res = res0; + ekeep = 0; + error = 0; + for (i = 0; afdl[i].a_af; i++) { + retry = 0; + if (af == AF_UNSPEC) { + /* + * filter out AFs that are not supported by the kernel + * XXX errno? + */ + s = socket(afdl[i].a_af, SOCK_DGRAM, 0); + if (s < 0) + continue; + close(s); + } else { + if (af != afdl[i].a_af) + continue; + } + /* It is WRONG, we need getipnodebyname(). */ +again: + error = get_addr0(hostname, afdl[i].a_af, res, pai, port0); + switch (error) { + case EAI_AGAIN: + if (++retry < 3) + goto again; + /* FALL THROUGH*/ + default: + if (ekeep == 0) + ekeep = error; + break; + } + if (*res) { + /* make chain of addrs */ + for (cur = *res; + cur && cur->ai_next; + cur = cur->ai_next) + ; + if (!cur) + return EAI_FAIL; + res = &cur->ai_next; + } + } + + /* if we got something, it's okay */ + if (*res0) + return 0; + + return error ? error : ekeep; +} + +static int +get_addr0(hostname, af, res, pai, port0) + const char *hostname; + int af; + struct addrinfo **res; + struct addrinfo *pai; + int port0; +{ + u_short port = port0 & 0xffff; + struct addrinfo sentinel; + struct hostent *hp; + struct addrinfo *top, *cur; + struct afd *afd; + int i, error = 0, h_error; + char *ap; + + top = NULL; + sentinel.ai_next = NULL; + cur = &sentinel; + +#ifdef HAVE_GETHOSTBYNAME2 + if (af == AF_UNSPEC) { + error = EAI_FAIL; + goto bad; + } + hp = gethostbyname2(hostname, af); +#else + if (af != AF_UNSPEC && af != AF_INET) { + error = EAI_FAIL; + goto bad; + } + hp = gethostbyname(hostname); +#endif + h_error = h_errno; + + if (hp == NULL) { + switch (h_error) { + case HOST_NOT_FOUND: + case NO_DATA: + error = EAI_NODATA; + break; + case TRY_AGAIN: + error = EAI_AGAIN; + break; + case NO_RECOVERY: + case NETDB_INTERNAL: + default: + error = EAI_FAIL; + break; + } + goto bad; + } + + if ((hp->h_name == NULL) || (hp->h_name[0] == 0) || + (hp->h_addr_list[0] == NULL)) + ERR(EAI_FAIL); + + for (i = 0; (ap = hp->h_addr_list[i]) != NULL; i++) { + switch (af) { +#ifdef INET6 + case AF_INET6: + afd = &afdl[N_INET6]; + break; +#endif +#ifndef INET6 + default: /* AF_UNSPEC */ +#endif + case AF_INET: + afd = &afdl[N_INET]; + break; +#ifdef INET6 + default: /* AF_UNSPEC */ + if (IN6_IS_ADDR_V4MAPPED((struct in6_addr *)ap)) { + ap += sizeof(struct in6_addr) - + sizeof(struct in_addr); + afd = &afdl[N_INET]; + } else + afd = &afdl[N_INET6]; + break; +#endif + } + GET_AI(cur->ai_next, afd, ap, port); + if (cur == &sentinel) { + top = cur->ai_next; + GET_CANONNAME(top, hp->h_name); + } + cur = cur->ai_next; + } + *res = top; + return SUCCESS; + free: + if (top) + freeaddrinfo(top); + bad: + *res = NULL; + return error; +} diff --git a/dist/bind/contrib/queryperf/missing/getnameinfo.c b/dist/bind/contrib/queryperf/missing/getnameinfo.c new file mode 100644 index 00000000000..e2154134a81 --- /dev/null +++ b/dist/bind/contrib/queryperf/missing/getnameinfo.c @@ -0,0 +1,217 @@ +/* $NetBSD: getnameinfo.c,v 1.1.1.1 2004/11/06 23:54:25 christos Exp $ */ + +/* + * 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: getnameinfo.c,v 1.2.4.2 2004/08/19 04:41:13 marka Exp */ + +/* + * Issues to be discussed: + * - Thread safe-ness must be checked + * - Return values. There seems to be no standard for return value (RFC2553) + * but INRIA implementation returns EAI_xxx defined for getaddrinfo(). + */ + +#include <sys/types.h> +#include <sys/socket.h> +#include <netinet/in.h> +#include <arpa/inet.h> +#include <arpa/nameser.h> +#include <netdb.h> +#include <resolv.h> +#include <string.h> +#include <stddef.h> + +#include "addrinfo.h" + +#define SUCCESS 0 +#define ANY 0 +#define YES 1 +#define NO 0 + +static struct afd { + int a_af; + int a_addrlen; + int a_socklen; + int a_off; +} afdl [] = { +#ifdef INET6 + {PF_INET6, sizeof(struct in6_addr), sizeof(struct sockaddr_in6), + offsetof(struct sockaddr_in6, sin6_addr)}, +#endif + {PF_INET, sizeof(struct in_addr), sizeof(struct sockaddr_in), + offsetof(struct sockaddr_in, sin_addr)}, + {0, 0, 0}, +}; + +struct sockinet { + u_char si_len; + u_char si_family; + u_short si_port; +}; + +#define ENI_NOSOCKET 0 +#define ENI_NOSERVNAME 1 +#define ENI_NOHOSTNAME 2 +#define ENI_MEMORY 3 +#define ENI_SYSTEM 4 +#define ENI_FAMILY 5 +#define ENI_SALEN 6 + +int +getnameinfo(sa, salen, host, hostlen, serv, servlen, flags) + const struct sockaddr *sa; + size_t salen; + char *host; + size_t hostlen; + char *serv; + size_t servlen; + int flags; +{ + struct afd *afd; + struct servent *sp; + struct hostent *hp; + u_short port; + int family, len, i; + char *addr, *p; + u_long v4a; + int h_error; + char numserv[512]; + char numaddr[512]; + + if (sa == NULL) + return ENI_NOSOCKET; + +#ifdef HAVE_SA_LEN + len = sa->sa_len; + if (len != salen) return ENI_SALEN; +#else + len = salen; +#endif + + family = sa->sa_family; + for (i = 0; afdl[i].a_af; i++) + if (afdl[i].a_af == family) { + afd = &afdl[i]; + goto found; + } + return ENI_FAMILY; + + found: + if (len != afd->a_socklen) return ENI_SALEN; + + port = ((struct sockinet *)sa)->si_port; /* network byte order */ + addr = (char *)sa + afd->a_off; + + if (serv == NULL || servlen == 0) { + /* what we should do? */ + } else if (flags & NI_NUMERICSERV) { + snprintf(numserv, sizeof(numserv), "%d", ntohs(port)); + if (strlen(numserv) > servlen) + return ENI_MEMORY; + strcpy(serv, numserv); + } else { + sp = getservbyport(port, (flags & NI_DGRAM) ? "udp" : "tcp"); + if (sp) { + if (strlen(sp->s_name) > servlen) + return ENI_MEMORY; + strcpy(serv, sp->s_name); + } else + return ENI_NOSERVNAME; + } + + switch (sa->sa_family) { + case AF_INET: + v4a = ntohl(((struct sockaddr_in *)sa)->sin_addr.s_addr); + if (IN_MULTICAST(v4a) || IN_EXPERIMENTAL(v4a)) + flags |= NI_NUMERICHOST; + v4a >>= IN_CLASSA_NSHIFT; + if (v4a == 0 || v4a == IN_LOOPBACKNET) + flags |= NI_NUMERICHOST; + break; +#ifdef INET6 + case AF_INET6: + { + struct sockaddr_in6 *sin6; + sin6 = (struct sockaddr_in6 *)sa; + switch (sin6->sin6_addr.s6_addr[0]) { + case 0x00: + if (IN6_IS_ADDR_V4MAPPED(&sin6->sin6_addr)) + ; + else if (IN6_IS_ADDR_LOOPBACK(&sin6->sin6_addr)) + ; + else + flags |= NI_NUMERICHOST; + break; + default: + if (IN6_IS_ADDR_LINKLOCAL(&sin6->sin6_addr)) + flags |= NI_NUMERICHOST; + else if (IN6_IS_ADDR_MULTICAST(&sin6->sin6_addr)) + flags |= NI_NUMERICHOST; + break; + } + } + break; +#endif + } + if (host == NULL || hostlen == 0) { + /* what should we do? */ + } else if (flags & NI_NUMERICHOST) { + /* NUMERICHOST and NAMEREQD conflicts with each other */ + if (flags & NI_NAMEREQD) + return ENI_NOHOSTNAME; + if (inet_ntop(afd->a_af, addr, numaddr, sizeof(numaddr)) + == NULL) + return ENI_SYSTEM; + if (strlen(numaddr) > hostlen) + return ENI_MEMORY; + strcpy(host, numaddr); + } else { +#ifdef USE_GETIPNODEBY + hp = getipnodebyaddr(addr, afd->a_addrlen, afd->a_af, &h_error); +#else + hp = gethostbyaddr(addr, afd->a_addrlen, afd->a_af); + h_error = h_errno; +#endif + + if (hp) { + if (flags & NI_NOFQDN) { + p = strchr(hp->h_name, '.'); + if (p) *p = '\0'; + } + if (strlen(hp->h_name) > hostlen) { +#ifdef USE_GETIPNODEBY + freehostent(hp); +#endif + return ENI_MEMORY; + } + strcpy(host, hp->h_name); +#ifdef USE_GETIPNODEBY + freehostent(hp); +#endif + } else { + if (flags & NI_NAMEREQD) + return ENI_NOHOSTNAME; + if (inet_ntop(afd->a_af, addr, numaddr, sizeof(numaddr)) + == NULL) + return ENI_NOHOSTNAME; + if (strlen(numaddr) > hostlen) + return ENI_MEMORY; + strcpy(host, numaddr); + } + } + return SUCCESS; +} diff --git a/dist/bind/contrib/queryperf/queryperf.c b/dist/bind/contrib/queryperf/queryperf.c index deb41ee405b..892880e097a 100644 --- a/dist/bind/contrib/queryperf/queryperf.c +++ b/dist/bind/contrib/queryperf/queryperf.c @@ -1,4 +1,4 @@ -/* $NetBSD: queryperf.c,v 1.1.1.1 2004/05/17 23:43:53 christos Exp $ */ +/* $NetBSD: queryperf.c,v 1.1.1.2 2004/11/06 23:54:25 christos Exp $ */ /* * Copyright (C) 2000, 2001 Nominum, Inc. @@ -20,7 +20,7 @@ /*** *** DNS Query Performance Testing Tool (queryperf.c) *** - *** Version Id: queryperf.c,v 1.1.1.2.2.5.4.1 2003/10/21 06:24:14 marka Exp + *** Version Id: queryperf.c,v 1.1.1.2.2.5.4.3 2004/06/21 00:45:30 marka Exp *** *** Stephen Jacob <sj@nominum.com> ***/ @@ -41,14 +41,18 @@ #include <math.h> #include <errno.h> +#ifndef HAVE_GETADDRINFO +#include "missing/addrinfo.h" +#endif + /* * Configuration defaults */ #define DEF_MAX_QUERIES_OUTSTANDING 20 #define DEF_QUERY_TIMEOUT 5 /* in seconds */ -#define DEF_SERVER_TO_QUERY "localhost" -#define DEF_SERVER_PORT 53 +#define DEF_SERVER_TO_QUERY "127.0.0.1" +#define DEF_SERVER_PORT "53" #define DEF_BUFFER_SIZE 32 /* in k */ /* @@ -77,13 +81,13 @@ enum directives_enum { V_SERVER, V_PORT, V_MAXQUERIES, V_MAXWAIT }; #define QTYPE_STRINGS { \ "A", "NS", "MD", "MF", "CNAME", "SOA", "MB", "MG", \ "MR", "NULL", "WKS", "PTR", "HINFO", "MINFO", "MX", "TXT", \ - "AAAA", "SRV", "A6", "AXFR", "MAILB", "MAILA", "*", "ANY" \ + "AAAA", "SRV", "NAPTR", "A6", "AXFR", "MAILB", "MAILA", "*", "ANY" \ } #define QTYPE_CODES { \ 1, 2, 3, 4, 5, 6, 7, 8, \ 9, 10, 11, 12, 13, 14, 15, 16, \ - 28, 33, 38, 252, 253, 254, 255, 255 \ + 28, 33, 35, 38, 252, 253, 254, 255, 255 \ } #define RCODE_STRINGS { \ @@ -118,11 +122,13 @@ unsigned int query_timeout = DEF_QUERY_TIMEOUT; int ignore_config_changes = FALSE; unsigned int socket_bufsize = DEF_BUFFER_SIZE; +int family = AF_UNSPEC; int use_stdin = TRUE; char *datafile_name; /* init NULL */ char *server_to_query; /* init NULL */ -unsigned int server_port = DEF_SERVER_PORT; +char *server_port; /* init NULL */ +struct addrinfo *server_ai; /* init NULL */ int run_only_once = FALSE; int use_timelimit = FALSE; @@ -156,8 +162,8 @@ struct timeval time_of_end_of_run; struct query_status *status; /* init NULL */ unsigned int query_status_allocated; /* init 0 */ -int query_socket; /* init 0 */ -struct sockaddr_in qaddr; +int query_socket = -1; +int socket4 = -1, socket6 = -1; static char *rcode_strings[] = RCODE_STRINGS; @@ -182,7 +188,7 @@ void show_startup_info(void) { printf("\n" "DNS Query Performance Testing Tool\n" -"Version: Id: queryperf.c,v 1.1.1.2.2.5.4.1 2003/10/21 06:24:14 marka Exp\n" +"Version: Id: queryperf.c,v 1.1.1.2.2.5.4.3 2004/06/21 00:45:30 marka Exp\n" "\n"); } @@ -195,17 +201,18 @@ show_usage(void) { fprintf(stderr, "\n" "Usage: queryperf [-d datafile] [-s server_addr] [-p port] [-q num_queries]\n" -" [-b bufsize] [-t timeout] [-n] [-l limit] [-1]\n" +" [-b bufsize] [-t timeout] [-n] [-l limit] [-f family] [-1]\n" " [-e] [-D] [-c] [-v] [-h]\n" " -d specifies the input data file (default: stdin)\n" " -s sets the server to query (default: %s)\n" -" -p sets the port on which to query the server (default: %u)\n" +" -p sets the port on which to query the server (default: %s)\n" " -q specifies the maximum number of queries outstanding (default: %d)\n" " -t specifies the timeout for query completion in seconds (default: %d)\n" " -n causes configuration changes to be ignored\n" " -l specifies how a limit for how long to run tests in seconds (no default)\n" " -1 run through input only once (default: multiple iff limit given)\n" " -b set input/output buffer size in kilobytes (default: %d k)\n" +" -f specify address family of DNS transport, inet or inet6 (default: any)\n" " -e enable EDNS 0\n" " -D set the DNSSEC OK bit (implies EDNS)\n" " -c print the number of packets with each rcode\n" @@ -289,14 +296,7 @@ set_server(char *new_name) { return (-1); } - if ((server_he = gethostbyname(new_name)) == NULL) { - fprintf(stderr, "Error: gethostbyname(\"%s\") failed\n", - new_name); - return (-1); - } - strcpy(server_to_query, new_name); - qaddr.sin_addr = *((struct in_addr *)server_he->h_addr); return (0); } @@ -309,16 +309,64 @@ set_server(char *new_name) { * Return a non-negative integer otherwise */ int -set_server_port(unsigned int new_port) { - if (new_port > MAX_PORT) +set_server_port(char *new_port) { + unsigned int uint_val; + + if ((is_uint(new_port, &uint_val)) != TRUE) + return (-1); + + if (uint_val && uint_val > MAX_PORT) return (-1); else { - server_port = new_port; - qaddr.sin_port = htons(server_port); + if (server_port != NULL && new_port != NULL && + strcmp(server_port, new_port) == 0) + return (0); + + free(server_port); + server_port = NULL; + + if ((server_port = malloc(strlen(new_port) + 1)) == NULL) { + fprintf(stderr, + "Error allocating memory for server port: " + "%s\n", new_port); + return (-1); + } + + strcpy(server_port, new_port); + return (0); } } +int +set_server_sa(void) { + struct addrinfo hints, *res; + static struct protoent *proto; + int error; + + if (proto == NULL && (proto = getprotobyname("udp")) == NULL) { + fprintf(stderr, "Error: getprotobyname call failed"); + return (-1); + } + + memset(&hints, 0, sizeof(hints)); + hints.ai_family = family; + hints.ai_socktype = SOCK_DGRAM; + hints.ai_protocol = proto->p_proto; + if ((error = getaddrinfo(server_to_query, server_port, + &hints, &res)) != 0) { + fprintf(stderr, "Error: getaddrinfo(%s, %s) failed\n", + server_to_query, server_port); + return (-1); + } + + /* replace the server's addrinfo */ + if (server_ai != NULL) + freeaddrinfo(server_ai); + server_ai = res; + return (0); +} + /* * is_digit: * Tests if a character is a digit @@ -427,8 +475,23 @@ parse_args(int argc, char **argv) { int c; unsigned int uint_arg_val; - while ((c = getopt(argc, argv, "q:t:nd:s:p:1l:b:eDcvh")) != -1) { + while ((c = getopt(argc, argv, "f:q:t:nd:s:p:1l:b:eDcvh")) != -1) { switch (c) { + case 'f': + if (strcmp(optarg, "inet") == 0) + family = AF_INET; +#ifdef AF_INET6 + else if (strcmp(optarg, "inet6") == 0) + family = AF_INET6; +#endif + else if (strcmp(optarg, "any") == 0) + family = AF_UNSPEC; + else { + fprintf(stderr, "Invalid address family: %s\n", + optarg); + return (-1); + } + break; case 'q': if (is_uint(optarg, &uint_arg_val) == TRUE) { set_max_queries(uint_arg_val); @@ -478,7 +541,7 @@ parse_args(int argc, char **argv) { if (is_uint(optarg, &uint_arg_val) == TRUE && uint_arg_val < MAX_PORT) { - set_server_port(uint_arg_val); + set_server_port(optarg); portset = TRUE; } else { fprintf(stderr, "Option requires a positive " @@ -584,39 +647,54 @@ close_datafile(void) { /* * open_socket: - * Open a socket for the queries + * Open a socket for the queries. When we have an active socket already, + * close it and open a new one. * * Return -1 on failure - * Return a non-negative integer otherwise + * Return the socket identifier */ int open_socket(void) { int sock; - struct protoent *proto; - struct sockaddr_in bind_addr; int ret; int bufsize; - - bind_addr.sin_family = AF_INET; - bind_addr.sin_port = htons(0); /* Have bind allocate a random port */ - bind_addr.sin_addr.s_addr = htonl(INADDR_ANY); - bzero(&(bind_addr.sin_zero), 8); - - if ((proto = getprotobyname("udp")) == NULL) { - fprintf(stderr, "Error: getprotobyname call failed"); + struct addrinfo hints, *res; + + memset(&hints, 0, sizeof(hints)); + hints.ai_family = server_ai->ai_family; + hints.ai_socktype = server_ai->ai_socktype; + hints.ai_protocol = server_ai->ai_protocol; + hints.ai_flags = AI_PASSIVE; + + if ((ret = getaddrinfo(NULL, "0", &hints, &res)) != 0) { + fprintf(stderr, + "Error: getaddrinfo for bind socket failed: %s\n", + gai_strerror(ret)); return (-1); } - if ((sock = socket(PF_INET, SOCK_DGRAM, proto->p_proto)) == -1) { + if ((sock = socket(res->ai_family, SOCK_DGRAM, + res->ai_protocol)) == -1) { fprintf(stderr, "Error: socket call failed"); - return (-1); + goto fail; } - if (bind(sock, (struct sockaddr *)&bind_addr, sizeof(struct sockaddr)) - == -1) { - fprintf(stderr, "Error: bind call failed"); - return (-1); +#if defined(AF_INET6) && defined(IPV6_V6ONLY) + if (res->ai_family == AF_INET6) { + int on = 1; + + if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, + &on, sizeof(on)) == -1) { + fprintf(stderr, + "Warning: setsockopt(IPV6_V6ONLY) failed\n"); + } } +#endif + + if (bind(sock, res->ai_addr, res->ai_addrlen) == -1) + fprintf(stderr, "Error: bind call failed"); + + freeaddrinfo(res); bufsize = 1024 * socket_bufsize; @@ -630,33 +708,81 @@ open_socket(void) { if (ret < 0) fprintf(stderr, "Warning: setsockbuf(SO_SNDBUF) failed\n"); - query_socket = sock; - - return (0); + return (sock); + + fail: + if (res) + freeaddrinfo(res); + return (-1); } /* * close_socket: - * Close the query socket + * Close the query socket(s) * * Return -1 on failure * Return a non-negative integer otherwise */ int close_socket(void) { - if (query_socket != 0) { - if (close(query_socket) != 0) { - fprintf(stderr, "Error: unable to close socket\n"); + if (socket4 != -1) { + if (close(socket4) != 0) { + fprintf(stderr, + "Error: unable to close IPv4 socket\n"); return (-1); } } - query_socket = 0; + if (socket6 != -1) { + if (close(socket6) != 0) { + fprintf(stderr, + "Error: unable to close IPv6 socket\n"); + return (-1); + } + } + + query_socket = -1; return (0); } /* + * change_socket: + * Choose an appropriate socket according to the address family of the + * current server. Open a new socket if necessary. + * + * Return -1 on failure + * Return the socket identifier + */ +int +change_socket(void) { + int s, *sockp; + + switch (server_ai->ai_family) { + case AF_INET: + sockp = &socket4; + break; +#ifdef AF_INET6 + case AF_INET6: + sockp = &socket6; + break; +#endif + default: + fprintf(stderr, "unexpected address family: %d\n", + server_ai->ai_family); + exit(1); + } + + if (*sockp == -1) { + if ((s = open_socket()) == -1) + return (-1); + *sockp = s; + } + + return (*sockp); +} + +/* * setup: * Set configuration options from command line arguments * Open datafile ready for reading @@ -666,11 +792,6 @@ close_socket(void) { */ int setup(int argc, char **argv) { - qaddr.sin_family = AF_INET; - qaddr.sin_port = htons(0); - qaddr.sin_addr.s_addr = htonl(INADDR_ANY); - bzero(&(qaddr.sin_zero), 8); - set_input_stdin(); if (set_max_queries(DEF_MAX_QUERIES_OUTSTANDING) == -1) { @@ -699,7 +820,10 @@ setup(int argc, char **argv) { if (open_datafile() == -1) return (-1); - if (open_socket() == -1) + if (set_server_sa() == -1) + return (-1); + + if ((query_socket = change_socket()) == -1) return (-1); return (0); @@ -735,7 +859,7 @@ difftv(struct timeval tv1, struct timeval tv2) { diff = (double)diff_sec + ((double)diff_usec / 1000000.0); - return diff; + return (diff); } /* @@ -877,6 +1001,7 @@ update_config(char *config_change_desc) { unsigned int uint_val; int directive_number; int check; + int old_af; if (ignore_config_changes == TRUE) { fprintf(stderr, "Ignoring configuration change: %s", @@ -930,9 +1055,29 @@ update_config(char *config_change_desc) { return; } - if (set_server(config_value) == -1) + if (set_server(config_value) == -1) { fprintf(stderr, "Set server error: unable to change " "the server name to '%s'\n", config_value); + return; + } + + old_af = server_ai->ai_family; + if (set_server_sa() == -1) { + fprintf(stderr, "Set server error: unable to resolve " + "a new server '%s'\n", + config_value); + return; + } + if (old_af != server_ai->ai_family) { + if ((query_socket = change_socket()) == -1) { + /* XXX: this is fatal */ + fprintf(stderr, "Set server error: " + "unable to open a new socket " + "for '%s'\n", config_value); + exit(1); + } + } + break; case V_PORT: @@ -945,9 +1090,15 @@ update_config(char *config_change_desc) { check = is_uint(config_value, &uint_val); if ((check == TRUE) && (uint_val > 0)) { - if (set_server_port(uint_val) == -1) { + if (set_server_port(config_value) == -1) { fprintf(stderr, "Invalid config: Bad value for" " %s: %s\n", directive, config_value); + } else { + if (set_server_sa() == -1) { + fprintf(stderr, + "Failed to set a new port\n"); + return; + } } } else fprintf(stderr, "Invalid config: Bad value for " @@ -1100,7 +1251,7 @@ dispatch_query(unsigned short int id, char *dom, int qt) { packet_buffer[1] = id_ptr[1]; bytes_sent = sendto(query_socket, packet_buffer, buffer_len, 0, - (struct sockaddr *)&qaddr, sockaddrlen); + server_ai->ai_addr, server_ai->ai_addrlen); if (bytes_sent == -1) { fprintf(stderr, "Failed to send query packet: %s %d\n", dom, qt); @@ -1123,6 +1274,7 @@ send_query(char *query_desc) { static unsigned short int use_query_id = 0; static int qname_len = MAX_DOMAIN_LEN; static char domain[MAX_DOMAIN_LEN + 1]; + char serveraddr[NI_MAXHOST]; int query_type; unsigned int count; @@ -1134,14 +1286,30 @@ send_query(char *query_desc) { } if (dispatch_query(use_query_id, domain, query_type) == -1) { - fprintf(stderr, "Error sending query: %s\n", query_desc); + char *addrstr; + + if (getnameinfo(server_ai->ai_addr, server_ai->ai_addrlen, + serveraddr, sizeof(serveraddr), NULL, 0, + NI_NUMERICHOST) == 0) { + addrstr = serveraddr; + } else + addrstr = "???"; /* XXX: this should not happen */ + fprintf(stderr, "Error sending query to %s: %s\n", + addrstr, query_desc); return; } if (setup_phase == TRUE) { set_timenow(&time_of_first_query); setup_phase = FALSE; - printf("[Status] Sending queries\n"); + if (getnameinfo(server_ai->ai_addr, server_ai->ai_addrlen, + serveraddr, sizeof(serveraddr), NULL, 0, + NI_NUMERICHOST) != 0) { + fprintf(stderr, "Error printing server address\n"); + return; + } + printf("[Status] Sending queries (beginning with %s)\n", + serveraddr); } /* Find the first slot in status[] that is not in use */ @@ -1166,39 +1334,6 @@ send_query(char *query_desc) { } /* - * data_available: - * Is there data available on the given file descriptor? - * - * Return TRUE if there is - * Return FALSE otherwise - */ -int -data_available(int fd, double wait) { - fd_set read_fds; - struct timeval tv; - int retval; - - /* Set list of file descriptors */ - FD_ZERO(&read_fds); - FD_SET(fd, &read_fds); - - if ((wait > 0.0) && (wait < (double)LONG_MAX)) { - tv.tv_sec = (long)floor(wait); - tv.tv_usec = (long)(1000000.0 * (wait - floor(wait))); - } else { - tv.tv_sec = 0; - tv.tv_usec = 0; - } - - retval = select(fd + 1, &read_fds, NULL, NULL, &tv); - - if (FD_ISSET(fd, &read_fds)) - return (TRUE); - else - return (FALSE); -} - -/* * register_response: * Register receipt of a query * @@ -1238,15 +1373,18 @@ register_response(unsigned short int id, unsigned int rcode) { */ void process_single_response(int sockfd) { - static struct sockaddr_in from_addr; + struct sockaddr_storage from_addr_ss; + struct sockaddr *from_addr; static unsigned char in_buf[MAX_BUFFER_LEN]; int numbytes, addr_len, resp_id; int flags; - addr_len = sizeof(struct sockaddr); + memset(&from_addr_ss, 0, sizeof(from_addr_ss)); + from_addr = (struct sockaddr *)&from_addr_ss; + addr_len = sizeof(from_addr_ss); if ((numbytes = recvfrom(sockfd, in_buf, MAX_BUFFER_LEN, - 0, (struct sockaddr *)&from_addr, &addr_len)) == -1) { + 0, from_addr, &addr_len)) == -1) { fprintf(stderr, "Error receiving datagram\n"); return; } @@ -1258,6 +1396,55 @@ process_single_response(int sockfd) { } /* + * data_available: + * Is there data available on the given file descriptor? + * + * Return TRUE if there is + * Return FALSE otherwise + */ +int +data_available(double wait) { + fd_set read_fds; + struct timeval tv; + int retval; + int available = FALSE; + int maxfd = -1; + + /* Set list of file descriptors */ + FD_ZERO(&read_fds); + if (socket4 != -1) { + FD_SET(socket4, &read_fds); + maxfd = socket4; + } + if (socket6 != -1) { + FD_SET(socket6, &read_fds); + if (maxfd == -1 || maxfd < socket6) + maxfd = socket6; + } + + if ((wait > 0.0) && (wait < (double)LONG_MAX)) { + tv.tv_sec = (long)floor(wait); + tv.tv_usec = (long)(1000000.0 * (wait - floor(wait))); + } else { + tv.tv_sec = 0; + tv.tv_usec = 0; + } + + retval = select(maxfd + 1, &read_fds, NULL, NULL, &tv); + + if (socket4 != -1 && FD_ISSET(socket4, &read_fds)) { + available = TRUE; + process_single_response(socket4); + } + if (socket6 != -1 && FD_ISSET(socket6, &read_fds)) { + available = TRUE; + process_single_response(socket6); + } + + return (available); +} + +/* * process_responses: * Go through any/all received responses and remove them from the list of * open queries (set in_use = FALSE for their entry in status[]), also @@ -1276,11 +1463,9 @@ process_responses(void) { first_packet_wait = 0.0; } - if (data_available(query_socket, first_packet_wait) == TRUE) { - process_single_response(query_socket); - - while (data_available(query_socket, 0.0) == TRUE) - process_single_response(query_socket); + if (data_available(first_packet_wait) == TRUE) { + while (data_available(0.0) == TRUE) + ; } } @@ -1395,9 +1580,10 @@ print_statistics(void) { printf("\n"); - printf(" Started at: %s", ctime(&start_time.tv_sec)); + printf(" Started at: %s", + ctime((const time_t *)&start_time.tv_sec)); printf(" Finished at: %s", - ctime(&time_of_end_of_run.tv_sec)); + ctime((const time_t *)&time_of_end_of_run.tv_sec)); printf(" Ran for: %.6lf seconds\n", run_time); printf("\n"); diff --git a/dist/bind/contrib/sdb/ldap/INSTALL.ldap b/dist/bind/contrib/sdb/ldap/INSTALL.ldap index e3801ed2585..91511296257 100644 --- a/dist/bind/contrib/sdb/ldap/INSTALL.ldap +++ b/dist/bind/contrib/sdb/ldap/INSTALL.ldap @@ -1,12 +1,12 @@ -This is the INSTALL file for 0.9. See +This is the INSTALL file for 1.0-beta. See http://www.venaas.no/ldap/bind-sdb/ for updates or other information. BUILDING You need the source for BIND 9.1.0 or newer (for zone transfers you will need at least 9.1.1rc3 due to a bug). Basically you need to follow -the instructions in doc/misc/sdb, if my instructions doesn't make sense, -please have a look at that as well. +the instructions in doc/misc/sdb, if my instructions don't make sense, +please have a look at those as well. Copy ldapdb.c to bin/named and ldapdb.h to bin/named/include in the source tree. @@ -22,11 +22,19 @@ Finally you need to edit bin/named/main.c. Below where it says it says "xxdb_init();" add the line "ldapdb_init();", and finally below where it says "xxdb_clear();", add "ldapdb_clear();". -Now you should hopefully be able to build it. If you get an error -message about ldap_memfree() not being defined, you're probably -using an LDAP library with the interface defined in RFC 1823. To -build, uncomment the #define RFC1823API line near the top of ldapdb.c. +Now you should hopefully be able to build as usual; first configure +and then make. If you get an error message about ldap_memfree() not +being defined, you're probably using an LDAP library with the +interface defined in RFC 1823. To build, uncomment the "#define +LDAPDB_RFC1823API" line near the top of ldapdb.c. +Also, if you're using an LDAPv2 only server, you need to change +the line "#define LDAPDB_LDAP_VERSION 3" in ldapdb.c. Simply +replace 3 with 2. Instead of editing the file, you may define +LDAPDB_LDAP_VERSION yourself. + +If you want to use TLS, you need to uncommed the #define LDAPDB_TLS" +line near the top of ldapdb.c. CONFIGURING @@ -34,26 +42,42 @@ Before you do any configuring of LDAP stuff, please try to configure and start bind as usual to see if things work. To do anything useful, you need to store a zone in some LDAP server. -From this release on, you must use a schema called dNSZone. Note that -it relies on some attribute definitions in the Cosine schema, so that -must be included as well. The Cosine schema probably comes with your -LDAP server. You can find dNSZone and further details on how to store -the data in your LDAP server at -http://www.venaas.no/ldap/bind-sdb/ - -For an example, have a look at my venaas.com zone. Try a subtree search -for objectClass=* at -ldap ldap://129.241.20.67/dc=venaas,dc=com,o=DNS,dc=venaas,dc=no - -To use it with BIND, I've added the following to named.conf: +You must use a schema called dNSZone. Note that it relies on some +attribute definitions in the Cosine schema, so that must be included +as well. The Cosine schema probably comes with your LDAP server. You +can find dNSZone and further details on how to store the data in your +LDAP server at http://www.venaas.no/ldap/bind-sdb/ + +To make BIND use a zone stored in LDAP, you will have to put something +like this in named.conf: + zone "venaas.com" { type master; - database "ldap ldap://129.241.20.67/dc=venaas,dc=com,o=DNS,dc=venaas,dc=no 172800"; + database "ldap ldap://158.38.160.245/dc=venaas,dc=com,o=DNS,dc=venaas,dc=no 172800"; }; When doing lookups BIND will do a sub-tree search below the base in the URL. The number 172800 is the TTL which will be used for all entries that -haven't got the dNSTTL attribute. It is also possible to add an filter to -the URL, say ldap://host/base???(o=internal) +haven't got the dNSTTL attribute. It is also possible to add a filter to +the URL, say "ldap://host/base???(o=internal)". + +Version 1.0 also has support for simple LDAP bind, that is, binding to +LDAP using plain text authentication. The bind dn and password is coded +into the URL as extensions, according to RFC 2255. If you want simple +bind with say dn "cn=Manager,dc=venaas,dc=no" and password "secret", the +URL will be something like this: + +ldap://158.38.160.245/dc=venaas,dc=com,o=DNS,dc=venaas,dc=no????!bindname=cn=Manager%2cdc=venaas%2cdc=no,!x-bindpw=secret + +This URL may also include a filter part if you need it. Note that in +the bind dn, "," is hex-escaped as "%2c". This is necessary since "," +is the separator between the extension elements. The "!" in front of +"bindname" and "x-bindpw" can be omitted if you prefer. "x-bindpw" is +not standardized, but it's used by several other LDAP applications. See +RFC 2255 for details. + +Finally, if you enabled TLS when compiling, you can also use TLS if +you like. To do this you use the extension "x-tls", e.g. +ldap://158.38.160.245/dc=venaas,dc=com,o=DNS,dc=venaas,dc=no????!bindname=cn=Manager%2cdc=venaas%2cdc=no,!x-bindpw=secret,x-tls -Stig Venaas <venaas@uninett.no> 2002-04-17 +Stig Venaas <venaas@uninett.no> 2004-08-15 diff --git a/dist/bind/contrib/sdb/ldap/README.ldap b/dist/bind/contrib/sdb/ldap/README.ldap index 10d65872557..b4ea18ab462 100644 --- a/dist/bind/contrib/sdb/ldap/README.ldap +++ b/dist/bind/contrib/sdb/ldap/README.ldap @@ -1,7 +1,15 @@ This is an attempt at an LDAP back-end for BIND 9 using the new simplified -database interface "sdb". This is the nineth release (0.9) and seems to -be pretty stable. Note that since version 0.4 a new schema is used. -It is not backwards compatible with versions before 0.4. +database interface "sdb". This is release 1.0-beta and should be pretty +stable. Note that since version 0.4 a new schema is used. It is not +backwards compatible with versions before 0.4. + +1.0-beta fixes a large memory leak. An extension x-tls for enabling TLS +has been added. + +1.0-alpha uses LDAPv3 by default and also supports LDAP simple bind. That +is, one can use plain text password for authentication. The bind dn and +password is coded into the URL using extensions bindname and x-bindpw +per RFC 2255. In 0.9 the code has been cleaned up a bit and should be slightly faster than previous versions. It also fixes an error with zone transfers (AXFR) @@ -37,4 +45,4 @@ contact me. See also http://www.venaas.no/ldap/bind-sdb/ for information. See INSTALL for how to build, install and use. -Stig Venaas <venaas@uninett.no> 2001-12-29 +Stig Venaas <venaas@uninett.no> 2004-08-15 diff --git a/dist/bind/contrib/sdb/ldap/ldapdb.c b/dist/bind/contrib/sdb/ldap/ldapdb.c index d8b83ffac1e..11cd33550af 100644 --- a/dist/bind/contrib/sdb/ldap/ldapdb.c +++ b/dist/bind/contrib/sdb/ldap/ldapdb.c @@ -1,20 +1,33 @@ -/* $NetBSD: ldapdb.c,v 1.1.1.1 2004/05/17 23:43:51 christos Exp $ */ +/* $NetBSD: ldapdb.c,v 1.1.1.2 2004/11/06 23:54:22 christos Exp $ */ /* - * ldapdb.c version 0.9 + * ldapdb.c version 1.0-beta * - * Copyright (C) 2002 Stig Venaas + * Copyright (C) 2002, 2004 Stig Venaas * * 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. + * + * Contributors: Jeremy C. McDermond + */ + +/* + * If you want to use TLS, uncomment the define below */ +/* #define LDAPDB_TLS */ /* * If you are using an old LDAP API uncomment the define below. Only do this * if you know what you're doing or get compilation errors on ldap_memfree(). + * This also forces LDAPv2. */ -/* #define RFC1823API */ +/* #define LDAPDB_RFC1823API */ + +/* Using LDAPv3 by default, change this if you want v2 */ +#ifndef LDAPDB_LDAP_VERSION +#define LDAPDB_LDAP_VERSION 3 +#endif #include <config.h> @@ -57,6 +70,11 @@ struct ldapdb_data { char *filterone; int filteronelen; char *filtername; + char *bindname; + char *bindpw; +#ifdef LDAPDB_TLS + int tls; +#endif }; /* used by ldapdb_getconn */ @@ -162,7 +180,7 @@ ldapdb_getconn(struct ldapdb_data *data) conndata = malloc(sizeof(*conndata)); if (conndata == NULL) return (NULL); - (char *)conndata->index = data->hostport; + conndata->index = data->hostport; conndata->size = strlen(data->hostport); conndata->data = NULL; ldapdb_insert((struct ldapdb_entry **)&threaddata->data, @@ -175,12 +193,27 @@ ldapdb_getconn(struct ldapdb_data *data) static void ldapdb_bind(struct ldapdb_data *data, LDAP **ldp) { +#ifndef LDAPDB_RFC1823API + const int ver = LDAPDB_LDAP_VERSION; +#endif + if (*ldp != NULL) ldap_unbind(*ldp); *ldp = ldap_open(data->hostname, data->portno); if (*ldp == NULL) return; - if (ldap_simple_bind_s(*ldp, NULL, NULL) != LDAP_SUCCESS) { + +#ifndef LDAPDB_RFC1823API + ldap_set_option(*ldp, LDAP_OPT_PROTOCOL_VERSION, &ver); +#endif + +#ifdef LDAPDB_TLS + if (data->tls) { + ldap_start_tls_s(*ldp, NULL, NULL); + } +#endif + + if (ldap_simple_bind_s(*ldp, data->bindname, data->bindpw) != LDAP_SUCCESS) { ldap_unbind(*ldp); *ldp = NULL; } @@ -193,9 +226,9 @@ ldapdb_search(const char *zone, const char *name, void *dbdata, void *retdata) isc_result_t result = ISC_R_NOTFOUND; LDAP **ldp; LDAPMessage *res, *e; - char *fltr, *a, **vals, **names = NULL; + char *fltr, *a, **vals = NULL, **names = NULL; char type[64]; -#ifdef RFC1823API +#ifdef LDAPDB_RFC1823API void *ptr; #else BerElement *ptr; @@ -280,7 +313,7 @@ ldapdb_search(const char *zone, const char *name, void *dbdata, void *retdata) *s = toupper(*s); s = strstr(a, "RECORD"); if ((s == NULL) || (s == a) || (s - a >= (signed int)sizeof(type))) { -#ifndef RFC1823API +#ifndef LDAPDB_RFC1823API ldap_memfree(a); #endif continue; @@ -304,7 +337,7 @@ ldapdb_search(const char *zone, const char *name, void *dbdata, void *retdata) isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, ISC_LOG_ERROR, "LDAP sdb zone '%s': dns_sdb_put... failed for %s", zone, vals[i]); ldap_value_free(vals); -#ifndef RFC1823API +#ifndef LDAPDB_RFC1823API ldap_memfree(a); if (ptr != NULL) ber_free(ptr, 0); @@ -317,21 +350,23 @@ ldapdb_search(const char *zone, const char *name, void *dbdata, void *retdata) } ldap_value_free(vals); } -#ifndef RFC1823API +#ifndef LDAPDB_RFC1823API ldap_memfree(a); #endif } -#ifndef RFC1823API +#ifndef LDAPDB_RFC1823API if (ptr != NULL) ber_free(ptr, 0); #endif if (name == NULL) ldap_value_free(names); - /* cleanup this result */ + /* free this result */ ldap_msgfree(res); } + /* free final result */ + ldap_msgfree(res); return (result); } @@ -373,7 +408,56 @@ unhex(char *in) return in; } +/* returns 0 for ok, -1 for bad syntax, -2 for unknown critical extension */ +static int +parseextensions(char *extensions, struct ldapdb_data *data) +{ + char *s, *next, *name, *value; + int critical; + + while (extensions != NULL) { + s = strchr(extensions, ','); + if (s != NULL) { + *s++ = '\0'; + next = s; + } else { + next = NULL; + } + + if (*extensions != '\0') { + s = strchr(extensions, '='); + if (s != NULL) { + *s++ = '\0'; + value = *s != '\0' ? s : NULL; + } else { + value = NULL; + } + name = extensions; + critical = *name == '!'; + if (critical) { + name++; + } + if (*name == '\0') { + return -1; + } + + if (!strcasecmp(name, "bindname")) { + data->bindname = value; + } else if (!strcasecmp(name, "x-bindpw")) { + data->bindpw = value; +#ifdef LDAPDB_TLS + } else if (!strcasecmp(name, "x-tls")) { + data->tls = value == NULL || !strcasecmp(value, "true"); +#endif + } else if (critical) { + return -2; + } + } + extensions = next; + } + return 0; +} static void free_data(struct ldapdb_data *data) @@ -395,7 +479,7 @@ ldapdb_create(const char *zone, int argc, char **argv, void *driverdata, void **dbdata) { struct ldapdb_data *data; - char *s, *filter = NULL; + char *s, *filter = NULL, *extensions = NULL; int defaultttl; UNUSED(driverdata); @@ -441,6 +525,15 @@ ldapdb_create(const char *zone, int argc, char **argv, s = strchr(s, '?'); if (s != NULL) { *s++ = '\0'; + /* extensions */ + extensions = s; + s = strchr(s, '?'); + if (s != NULL) { + *s++ = '\0'; + } + if (*extensions == '\0') { + extensions = NULL; + } } if (*filter == '\0') { filter = NULL; @@ -451,15 +544,37 @@ ldapdb_create(const char *zone, int argc, char **argv, if (*data->base == '\0') { data->base = NULL; } + } + + /* parse extensions */ + if (extensions != NULL) { + int err; - if ((data->base != NULL && unhex(data->base) == NULL) || (filter != NULL && unhex(filter) == NULL)) { + err = parseextensions(extensions, data); + if (err < 0) { + /* err should be -1 or -2 */ free_data(data); - isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, ISC_LOG_ERROR, - "LDAP sdb zone '%s': bad hex values", zone); + if (err == -1) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, ISC_LOG_ERROR, + "LDAP sdb zone '%s': URL: extension syntax error", zone); + } else if (err == -2) { + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, ISC_LOG_ERROR, + "LDAP sdb zone '%s': URL: unknown critical extension", zone); + } return (ISC_R_FAILURE); } } + if ((data->base != NULL && unhex(data->base) == NULL) || + (filter != NULL && unhex(filter) == NULL) || + (data->bindname != NULL && unhex(data->bindname) == NULL) || + (data->bindpw != NULL && unhex(data->bindpw) == NULL)) { + free_data(data); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, ISC_LOG_ERROR, + "LDAP sdb zone '%s': URL: bad hex values", zone); + return (ISC_R_FAILURE); + } + /* compute filterall and filterone once and for all */ if (filter == NULL) { data->filteralllen = strlen(zone) + strlen("(zoneName=)") + 1; diff --git a/dist/bind/doc/arm/Bv9ARM-book.xml b/dist/bind/doc/arm/Bv9ARM-book.xml index ace940f4a15..2dbd4e0693f 100644 --- a/dist/bind/doc/arm/Bv9ARM-book.xml +++ b/dist/bind/doc/arm/Bv9ARM-book.xml @@ -2,7 +2,7 @@ <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN" "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"> -<!-- File: Id: Bv9ARM-book.xml,v 1.155.2.27.2.40 2004/04/15 23:56:27 marka Exp --> +<!-- File: Id: Bv9ARM-book.xml,v 1.155.2.27.2.49 2004/08/16 00:55:29 marka Exp --> <book> <title>BIND 9 Administrator Reference Manual</title> @@ -989,7 +989,7 @@ protocol is specified in RFC 1996. <command>zone</command> statement.</para> <para>Updating of secure zones (zones using DNSSEC) follows - RFC 3007: SIG and NXT records affected by updates are automatically + 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.</para> @@ -1433,8 +1433,8 @@ allow-update { key host1-host2. ;}; <title>DNSSEC</title> <para>Cryptographic authentication of DNS information is possible - through the DNS Security (<emphasis>DNSSEC</emphasis>) extensions, - defined in RFC 2535. This section describes the creation and use + through the DNS Security (<emphasis>DNSSEC-bis</emphasis>) extensions, + defined in RFC <TBA>. This section describes the creation and use of DNSSEC signed zones.</para> <para>In order to set up a DNSSEC secure zone, there are a series @@ -1443,15 +1443,17 @@ allow-update { key host1-host2. ;}; that are used in this process, which are explained in more detail below. In all cases, the <option>-h</option> option prints a full list of parameters. Note that the DNSSEC tools require the - keyset and signedkey files to be in the working directory or the + keyset files to be in the working directory or the directory specified by the <option>-h</option> option, and - that the tools shipped with BIND 9.0.x are not fully compatible + that the tools shipped with BIND 9.2.x and earlier are not compatible with the current ones.</para> <para>There must also be communication with the administrators of - the parent and/or child zone to transmit keys and signatures. A - zone's security status must be indicated by the parent zone for a - DNSSEC capable resolver to trust its data.</para> + 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 <literal>DS</literal> record at the delegation + point.</para> <para>For other servers to trust data in this zone, they must either be statically configured with this zone's zone key or the @@ -1470,16 +1472,16 @@ allow-update { key host1-host2. ;}; <command>ZONE</command>, 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 - these are RSASHA1 and DSA.</para> + the only one is RSASHA1.</para> - <para>The following command will generate a 768 bit DSA key for + <para>The following command will generate a 768 bit RSASHA1 key for the <filename>child.example</filename> zone:</para> - <para><userinput>dnssec-keygen -a DSA -b 768 -n ZONE child.example.</userinput></para> + <para><userinput>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</userinput></para> <para>Two output files will be produced: - <filename>Kchild.example.+003+12345.key</filename> and - <filename>Kchild.example.+003+12345.private</filename> (where + <filename>Kchild.example.+005+12345.key</filename> and + <filename>Kchild.example.+005+12345.private</filename> (where 12345 is an example of a key tag). The key file names contain the key name (<filename>child.example.</filename>), algorithm (3 is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in this case). @@ -1498,78 +1500,18 @@ allow-update { key host1-host2. ;}; </sect2> <sect2> - <title>Creating a Keyset</title> - - <para>The <command>dnssec-makekeyset</command> program is used - to create a key set from one or more keys.</para> - - <para>Once the zone keys have been generated, a key set must be - built for transmission to the administrator of the parent zone, - so that the parent zone can sign the keys with its own zone key - and correctly indicate the security status of this zone. When - building a key set, the list of keys to be included and the TTL - of the set must be specified, and the desired signature validity - period of the parent's signature may also be specified.</para> - - <para>The list of keys to be inserted into the key set may also - included non-zone keys present at the top of the zone. - <command>dnssec-makekeyset</command> may also be used at other - names in the zone.</para> - - <para>The following command generates a key set containing the - above key and another key similarly generated, with a TTL of - 3600 and a signature validity period of 10 days starting from - now.</para> - -<para><userinput>dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 Kchild.example.+003+23456</userinput></para> - - <para>One output file is produced: - <filename>keyset-child.example.</filename>. This file should be - transmitted to the parent to be signed. It includes the keys, - as well as signatures over the key set generated by the zone - keys themselves, which are used to prove ownership of the - private keys and encode the desired validity period.</para> - - </sect2> - <sect2> - <title>Signing the Child's Keyset</title> - - <para>The <command>dnssec-signkey</command> program is used to - sign one child's keyset.</para> - - <para>If the <filename>child.example</filename> zone has any - delegations which are secure, for example, - <filename>grand.child.example</filename>, the - <filename>child.example</filename> administrator should receive - keyset files for each secure subzone. These keys must be signed - by this zone's zone keys.</para> - - <para>The following command signs the child's key set with the - zone keys:</para> - -<para><userinput>dnssec-signkey keyset-grand.child.example. Kchild.example.+003+12345 Kchild.example.+003+23456</userinput></para> - - <para>One output file is produced: - <filename>signedkey-grand.child.example.</filename>. This file - should be both transmitted back to the child and retained. It - includes all keys (the child's keys) from the keyset file and - signatures generated by this zone's zone keys.</para> - - </sect2> - <sect2> <title>Signing the Zone</title> <para>The <command>dnssec-signzone</command> program is used to sign a zone.</para> - <para>Any <filename>signedkey</filename> files corresponding to - secure subzones should be present, as well as a - <filename>signedkey</filename> file for this zone generated by - the parent (if there is one). The zone signer will generate - <literal>NXT</literal> and <literal>SIG</literal> records for - the zone, as well as incorporate the zone key signature from the - parent and indicate the security status at all delegation - points.</para> + <para>Any <filename>keyset</filename> files corresponding + to secure subzones should be present. The zone signer will + generate <literal>NSEC</literal> and <literal>RRSIG</literal> + records for the zone, as well as <literal>DS</literal> for + the child zones if <literal>'-d'</literal> is specified. + If <literal>'-d'</literal> is not specified then DS RRsets for + the secure child zones need to be added manually.</para> <para>The following command signs the zone, assuming it is in a file called <filename>zone.child.example</filename>. By @@ -1583,6 +1525,12 @@ allow-update { key host1-host2. ;}; should be referenced by <filename>named.conf</filename> as the input file for the zone.</para> + <para><command>dnssec-signzone</command> will also produce a + keyset and dsset files and optionally a dlvset file. These + are used to provide the parent zone administators with the + <literal>DNSKEYs</literal> (or their corresponding <literal>DS</literal> + records) that are the secure entry point to the zone.</para> + </sect2> <sect2><title>Configuring Servers</title> @@ -1641,7 +1589,7 @@ statement, as described later in this document. </para> <programlisting> $ORIGIN example.com. -host 3600 IN AAAA 2001:4f8:201:1860:42::1 +host 3600 IN AAAA 2001:db8::1 </programlisting> <para>It is recommended that IPv4-in-IPv6 mapped addresses not @@ -1657,11 +1605,11 @@ host 3600 IN AAAA 2001:4f8:201:1860:42::1 <literal>ip6.arpa.</literal> is appended to the resulting name. For example, the following would provide reverse name lookup for a host with address - <literal>2001:4f8:201:1860:42::1</literal>.</para> + <literal>2001:db8::1</literal>.</para> <programlisting> -$ORIGIN 0.6.8.1.1.0.2.0.8.f.4.0.1.0.0.2.ip6.arpa. -1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0 14400 IN PTR host.example.com. +$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. </programlisting> </sect2> </sect1> @@ -1764,7 +1712,7 @@ in <varname>dotted_decimal</varname> notation.</para></entry> </row> <row rowsep = "0"> <entry colname = "1"><para><varname>ip6_addr</varname></para></entry> -<entry colname = "2"><para>An IPv6 address, such as <command>2001:ffff::200:f8ff:fe01:9742</command>. +<entry colname = "2"><para>An IPv6 address, such as <command>2001:db8::1234</command>. IPv6 scoped addresses that have ambiguity on their scope zones must be disambiguated by an appropriate zone ID with the percent character (`%') as delimiter. @@ -2632,7 +2580,16 @@ the <command>null</command> channel.</para></entry> At startup, specifing the category <command>queries</command> will also enable query logging unless <command>querylog</command> option has been specified. -</para></entry> +</para> +<para> +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).</para> +<programlisting><computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput> +<computeroutput>client ::1#62537: query: www.example.net IN AAAA -SE</computeroutput> +</programlisting> +</entry> </row> <row rowsep = "0"> <entry colname = "1"><para><command>dispatch</command></para></entry> @@ -2758,7 +2715,7 @@ statement in the <filename>named.conf</filename> file:</para> <optional> use-id-pool <replaceable>yes_or_no</replaceable>; </optional> <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable>; </optional> <optional> dnssec-enable <replaceable>yes_or_no</replaceable>; </optional> - <optional> dnssec-lookaside <replaceable>domain</replaceable>; </optional> + <optional> dnssec-lookaside <replaceable>domain</replaceable> trust-anchor <replaceable>domain</replaceable>; </optional> <optional> dnssec-must-be-secure <replaceable>domain yes_or_no</replaceable>; </optional> <optional> forward ( <replaceable>only</replaceable> | <replaceable>first</replaceable> ); </optional> <optional> forwarders { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional> @@ -2985,10 +2942,12 @@ Only the most specific will be applied. <listitem><para> When set <command>dnssec-lookaside</command> provides the validator with an alternate method to validate DNSKEY records at the -top of a zone. When set the domain specified by -<command>dnssec-lookaside</command> is appended to DNSKEY's -name and a DLV record is looked up. If the DLV record validates -a DNSKEY (similarly to the way a DS record does) the DNSKEY RRset is deemed to be trusted. +top of a zone. When a DNSKEY is at or below a domain specified by the +deepest <command>dnssec-lookaside</command>, 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. </para></listitem></varlistentry> <varlistentry><term><command>dnssec-must-be-secure</command></term> @@ -3416,8 +3375,8 @@ or have a different <command>forward only/first</command> behavior, or not forward at all, see <xref linkend="zone_statement_grammar"/>.</para> </sect3> -<sect3><title>6 to 4 Servers</title> -<para>6 to 4 servers are used as servers of last resort to work around +<sect3><title>Dual-stack Servers</title> +<para>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.</para> @@ -3534,28 +3493,40 @@ listen-on port 1234 { !1.2.3.4; 1.2/16; }; <para>If no <command>listen-on</command> is specified, the server will listen on port 53 on all interfaces.</para> -<para>By default, the server does not bind a separate socket to each -IPv6 interface address as it does for IPv4. Instead, it listens on the -IPv6 wildcard address. -Alternatively, a list of IPv6 addresses can be specified, in which case -the server listens on a separate socket for each specified address.</para> +<para>The <command>listen-on-v6</command> option is used to +specify the interfaces and the ports on which the server will listen +for incoming queries sent using IPv6.</para> + +<para>When <programlisting>{ any; }</programlisting> is specified +as the <varname>address_match_list</varname> for the +<command>listen-on-v6</command> 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.</para> + +<para>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.</para> <para>Multiple <command>listen-on-v6</command> options can be used. For example,</para> <programlisting>listen-on-v6 { any; }; -listen-on-v6 port 1234 { !3ffe::/16; any; }; +listen-on-v6 port 1234 { !2001:db8::/32; any; }; </programlisting> <para>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 -3ffe::/16 (with separate sockets for each matched address.)</para> +2001:db8::/32 (with separate sockets for each matched address.)</para> <para>To make the server not listen on any IPv6 address, use</para> <programlisting>listen-on-v6 { none; }; </programlisting> -<para>If no <command>listen-on-v6</command> statement is specified, +<para>If no <command>listen-on-v6</command> option is specified, the server will not listen on any IPv6 address.</para></sect3> <sect3><title>Query Address</title> @@ -3563,7 +3534,7 @@ the server will not listen on any IPv6 address.</para></sect3> query other name servers. <command>query-source</command> specifies the address and port used for such queries. For queries sent over IPv6, there is a separate <command>query-source-v6</command> option. - If <command>address</command> is <command>*</command> or is omitted, +If <command>address</command> is <command>*</command> or is omitted, a wildcard IP address (<command>INADDR_ANY</command>) will be used. If <command>port</command> is <command>*</command> or is omitted, a random unprivileged port will be used, <command>avoid-v4-udp-ports</command> @@ -3577,6 +3548,9 @@ query-source-v6 address * port *; is used for both UDP and TCP queries, but the port applies only to UDP queries. TCP queries always use a random unprivileged port.</para></note> +<note> +<para>See also <command>transfer-source</command> and +<command>notify-source</command>.</para></note> </sect3> <sect3 id="zone_transfers"><title>Zone Transfers</title> @@ -4752,10 +4726,9 @@ The default is the empty list.</para> <varlistentry><term><command>check-names</command></term> <listitem><para> -This option was used in BIND 8 to restrict the character set of -domain names in master files and/or DNS responses received from the -network. BIND 9 does not restrict the character set of domain names -and does not implement the <command>check-names</command> option. +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. </para> </listitem></varlistentry> @@ -6006,7 +5979,7 @@ 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:</para> -<para><command>2001:4f8:201:9:a00:20ff:fe81:2b32</command></para> +<para><command>2001:db8:201:9:a00:20ff:fe81:2b32</command></para> <para>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 diff --git a/dist/bind/doc/arm/Bv9ARM.ch01.html b/dist/bind/doc/arm/Bv9ARM.ch01.html index c79a1fcf36d..5b3659e6101 100644 --- a/dist/bind/doc/arm/Bv9ARM.ch01.html +++ b/dist/bind/doc/arm/Bv9ARM.ch01.html @@ -1,11 +1,11 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >Introduction </TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"><LINK +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REL="HOME" TITLE="BIND 9 Administrator Reference Manual" HREF="Bv9ARM.html"><LINK @@ -70,8 +70,8 @@ CLASS="chapter" ><H1 ><A NAME="ch01" ->Chapter 1. Introduction </A -></H1 +></A +>Chapter 1. Introduction </H1 ><DIV CLASS="TOC" ><DL @@ -97,24 +97,24 @@ HREF="Bv9ARM.ch01.html#AEN42" ><DT >1.4. <A HREF="Bv9ARM.ch01.html#AEN107" ->The Domain Name System (<SPAN +>The Domain Name System (<ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM >)</A ></DT ></DL ></DIV ><P ->The Internet Domain Name System (<SPAN +>The Internet Domain Name System (<ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM >) consists of the syntax to specify the names of entities in the Internet in a hierarchical manner, the rules used for delegating authority over names, and the system implementation that actually maps names to Internet - addresses. <SPAN + addresses. <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > data is maintained in a group of distributed hierarchical databases.</P ><DIV @@ -126,19 +126,19 @@ NAME="AEN15" >1.1. Scope of Document</A ></H1 ><P ->The Berkeley Internet Name Domain (<SPAN +>The Berkeley Internet Name Domain (<ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM >) 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 (<SPAN + care of the Internet Software Consortium (<ACRONYM CLASS="acronym" ->ISC</SPAN +>ISC</ACRONYM >) - <SPAN + <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > version 9 software package for system administrators.</P ><P @@ -160,12 +160,12 @@ CLASS="emphasis" >Section 1</I ></SPAN > introduces - the basic <SPAN + the basic <ACRONYM CLASS="acronym" ->DNS</SPAN -> and <SPAN +>DNS</ACRONYM +> and <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > concepts. <SPAN CLASS="emphasis" ><I @@ -173,9 +173,9 @@ CLASS="emphasis" >Section 2</I ></SPAN > - describes resource requirements for running <SPAN + describes resource requirements for running <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > in various environments. Information in <SPAN CLASS="emphasis" @@ -192,9 +192,9 @@ CLASS="emphasis" ></SPAN > in its presentation and is organized functionally, to aid in the process of installing the - <SPAN + <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 software. The task-oriented section is followed by <SPAN CLASS="emphasis" @@ -211,9 +211,9 @@ CLASS="emphasis" >Section 5</I ></SPAN > - describes the <SPAN + describes the <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 lightweight resolver. The contents of <SPAN CLASS="emphasis" @@ -253,9 +253,9 @@ CLASS="emphasis" >Bibliography</I ></SPAN > and - historic information related to <SPAN + historic information related to <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > and the Domain Name System.</P ></DIV @@ -272,11 +272,11 @@ NAME="AEN42" conventions:</P ><DIV CLASS="informaltable" +><P +></P ><A NAME="AEN45" ></A -><P -></P ><TABLE CELLPADDING="3" BORDER="1" @@ -284,9 +284,6 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="288" -ALIGN="LEFT" -VALIGN="MIDDLE" > <P ><SPAN CLASS="emphasis" @@ -298,9 +295,6 @@ describe:</I ></P ></TD ><TD -WIDTH="252" -ALIGN="LEFT" -VALIGN="MIDDLE" > <P ><SPAN CLASS="emphasis" @@ -313,17 +307,11 @@ CLASS="emphasis" ></TR ><TR ><TD -WIDTH="288" -ALIGN="LEFT" -VALIGN="MIDDLE" > <P >a pathname, filename, URL, hostname, mailing list name, or new term or concept</P ></TD ><TD -WIDTH="252" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><TT CLASS="filename" @@ -333,42 +321,28 @@ CLASS="filename" ></TR ><TR ><TD -WIDTH="288" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >literal user input</P ></TD ><TD -WIDTH="252" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><KBD CLASS="userinput" -><B ->Fixed Width Bold</B -></TT +>Fixed Width Bold</KBD ></P ></TD ></TR ><TR ><TD -WIDTH="288" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >program output</P ></TD ><TD -WIDTH="252" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><SAMP CLASS="computeroutput" ->Fixed Width</TT +>Fixed Width</SAMP ></P ></TD ></TR @@ -379,16 +353,16 @@ CLASS="computeroutput" ></DIV ><P >The following conventions are used in descriptions of the -<SPAN +<ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > configuration file:<DIV CLASS="informaltable" +><P +></P ><A NAME="AEN77" ></A -><P -></P ><TABLE CELLPADDING="3" BORDER="1" @@ -396,9 +370,6 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="288" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><SPAN CLASS="emphasis" @@ -410,9 +381,6 @@ describe:</I ></P ></TD ><TD -WIDTH="252" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><SPAN CLASS="emphasis" @@ -425,54 +393,36 @@ CLASS="emphasis" ></TR ><TR ><TD -WIDTH="288" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >keywords</P ></TD ><TD -WIDTH="252" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->Fixed Width</TT +>Fixed Width</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="288" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >variables</P ></TD ><TD -WIDTH="252" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->Fixed Width</TT +>Fixed Width</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="288" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Optional input</P ></TD ><TD -WIDTH="252" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >[<SPAN CLASS="optional" @@ -493,24 +443,24 @@ CLASS="sect1" CLASS="sect1" ><A NAME="AEN107" ->1.4. The Domain Name System (<SPAN +>1.4. The Domain Name System (<ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM >)</A ></H1 ><P >The purpose of this document is to explain the installation -and upkeep of the <SPAN +and upkeep of the <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > software package, and we begin by reviewing the fundamentals of the Domain Name System -(<SPAN +(<ACRONYM CLASS="acronym" ->DNS</SPAN ->) as they relate to <SPAN +>DNS</ACRONYM +>) as they relate to <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM >. </P ><DIV @@ -542,9 +492,9 @@ CLASS="emphasis" >name servers</I ></SPAN > and interprets the responses. -The <SPAN +The <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 software distribution contains a name server, <B CLASS="command" @@ -604,30 +554,30 @@ CLASS="emphasis" >Example, Inc.</I ></SPAN > could be -<TT +<VAR CLASS="literal" ->mail.example.com</TT +>mail.example.com</VAR >, -where <TT +where <VAR CLASS="literal" ->com</TT +>com</VAR > is the top level domain to which -<TT +<VAR CLASS="literal" ->ourhost.example.com</TT +>ourhost.example.com</VAR > belongs, -<TT +<VAR CLASS="literal" ->example</TT +>example</VAR > is -a subdomain of <TT +a subdomain of <VAR CLASS="literal" ->com</TT +>com</VAR >, and -<TT +<VAR CLASS="literal" ->ourhost</TT +>ourhost</VAR > is the name of the host.</P ><P @@ -664,9 +614,9 @@ CLASS="emphasis" CLASS="emphasis" >resource records</I ></SPAN -> (<SPAN +> (<ACRONYM CLASS="acronym" ->RR</SPAN +>RR</ACRONYM >s). Some of the supported resource record types are described in <A @@ -707,9 +657,9 @@ CLASS="emphasis" >.</P ><P >As we stated previously, a zone is a point of delegation in -the <SPAN +the <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > tree. A zone consists of those contiguous parts of the domain tree for which a name server has complete information and over which @@ -726,36 +676,36 @@ CLASS="emphasis" parent zone, which should be matched by equivalent NS records at the root of the delegated zone.</P ><P ->For instance, consider the <TT +>For instance, consider the <VAR CLASS="literal" ->example.com</TT +>example.com</VAR > domain which includes names -such as <TT +such as <VAR CLASS="literal" ->host.aaa.example.com</TT +>host.aaa.example.com</VAR > and -<TT +<VAR CLASS="literal" ->host.bbb.example.com</TT +>host.bbb.example.com</VAR > even though -the <TT +the <VAR CLASS="literal" ->example.com</TT +>example.com</VAR > zone includes -only delegations for the <TT +only delegations for the <VAR CLASS="literal" ->aaa.example.com</TT +>aaa.example.com</VAR > and -<TT +<VAR CLASS="literal" ->bbb.example.com</TT +>bbb.example.com</VAR > 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 <SPAN +name servers. Every name in the <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > tree is a <SPAN CLASS="emphasis" @@ -783,9 +733,9 @@ not intuitive and we suggest that you read RFCs 1033, 1034 and 1035 to gain a complete understanding of this difficult and subtle topic.</P ><P ->Though <SPAN +>Though <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > is called a "domain name server", it deals primarily in terms of zones. The master and slave declarations in the <TT @@ -1056,14 +1006,14 @@ 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 <SPAN +of internal <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > servers and an Internet firewall. Servers unable to pass packets through the firewall would forward to the server -that can do it, and that server would query the Internet <SPAN +that can do it, and that server would query the Internet <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > servers on the internal server's behalf. An added benefit of using the forwarding feature is that the central machine develops a much more complete @@ -1080,9 +1030,9 @@ NAME="AEN218" >1.4.6. Name Servers in Multiple Roles</A ></H2 ><P ->The <SPAN +>The <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > name server can simultaneously act as a master for some zones, a slave for other zones, and as a caching (recursive) server for a set of local clients.</P @@ -1169,9 +1119,9 @@ VALIGN="top" WIDTH="33%" ALIGN="right" VALIGN="top" -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > Resource Requirements</TD ></TR ></TABLE diff --git a/dist/bind/doc/arm/Bv9ARM.ch02.html b/dist/bind/doc/arm/Bv9ARM.ch02.html index 8e4e686147b..0b293c7edfd 100644 --- a/dist/bind/doc/arm/Bv9ARM.ch02.html +++ b/dist/bind/doc/arm/Bv9ARM.ch02.html @@ -1,11 +1,11 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >BIND Resource Requirements</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"><LINK +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REL="HOME" TITLE="BIND 9 Administrator Reference Manual" HREF="Bv9ARM.html"><LINK @@ -70,11 +70,11 @@ CLASS="chapter" ><H1 ><A NAME="ch02" ->Chapter 2. <SPAN +></A +>Chapter 2. <ACRONYM CLASS="acronym" ->BIND</SPAN -> Resource Requirements</A -></H1 +>BIND</ACRONYM +> Resource Requirements</H1 ><DIV CLASS="TOC" ><DL @@ -118,25 +118,25 @@ NAME="AEN228" >2.1. Hardware requirements</A ></H1 ><P -><SPAN +><ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > hardware requirements have traditionally been quite modest. For many installations, servers that have been pensioned off from -active duty have performed admirably as <SPAN +active duty have performed admirably as <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > servers.</P ><P ->The DNSSEC and IPv6 features of <SPAN +>The DNSSEC and IPv6 features of <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 may prove to be quite CPU intensive however, so organizations that make heavy use of these features may wish to consider larger systems for these applications. -<SPAN +<ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 is fully multithreaded, allowing full utilization of multiprocessor systems for installations that need it.</P ></DIV @@ -149,9 +149,9 @@ NAME="AEN236" >2.2. CPU Requirements</A ></H1 ><P ->CPU requirements for <SPAN +>CPU requirements for <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 range from i486-class machines for serving of static zones without caching, to enterprise-class machines if you intend to process many dynamic updates and DNSSEC @@ -172,9 +172,9 @@ CLASS="command" >max-cache-size</B > 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 <SPAN +at the expense of reducing cache hit rates and causing more <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > traffic. It is still good practice to have enough memory to load all zone and cache data into memory — unfortunately, the best way @@ -212,9 +212,9 @@ NAME="AEN248" >2.5. Supported Operating Systems</A ></H1 ><P ->ISC <SPAN +>ISC <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 compiles and runs on a large number of Unix-like operating system and on Windows NT / 2000. For an up-to-date list of supported systems, see the README file in the top level directory diff --git a/dist/bind/doc/arm/Bv9ARM.ch03.html b/dist/bind/doc/arm/Bv9ARM.ch03.html index f73d942d0ed..204d64ced91 100644 --- a/dist/bind/doc/arm/Bv9ARM.ch03.html +++ b/dist/bind/doc/arm/Bv9ARM.ch03.html @@ -1,11 +1,11 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >Name Server Configuration</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"><LINK +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REL="HOME" TITLE="BIND 9 Administrator Reference Manual" HREF="Bv9ARM.html"><LINK @@ -70,8 +70,8 @@ CLASS="chapter" ><H1 ><A NAME="ch03" ->Chapter 3. Name Server Configuration</A -></H1 +></A +>Chapter 3. Name Server Configuration</H1 ><DIV CLASS="TOC" ><DL @@ -203,9 +203,9 @@ NAME="AEN268" ></H1 ><P >A primitive form of load balancing can be achieved in -the <SPAN +the <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > by using multiple A records for one name.</P ><P >For example, if you have three WWW servers with network addresses @@ -214,11 +214,11 @@ following means that clients will connect to each machine one third of the time:</P ><DIV CLASS="informaltable" +><P +></P ><A NAME="AEN273" ></A -><P -></P ><TABLE CELLPADDING="3" BORDER="1" @@ -226,188 +226,128 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Name</P ></TD ><TD -WIDTH="48" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >TTL</P ></TD ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >CLASS</P ></TD ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >TYPE</P ></TD ><TD -WIDTH="195" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Resource Record (RR) Data</P ></TD ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->www</TT +>www</VAR ></P ></TD ><TD -WIDTH="48" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->600</TT +>600</VAR ></P ></TD ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->IN</TT +>IN</VAR ></P ></TD ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->A</TT +>A</VAR ></P ></TD ><TD -WIDTH="195" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->10.0.0.1</TT +>10.0.0.1</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="48" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->600</TT +>600</VAR ></P ></TD ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->IN</TT +>IN</VAR ></P ></TD ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->A</TT +>A</VAR ></P ></TD ><TD -WIDTH="195" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->10.0.0.2</TT +>10.0.0.2</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="48" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->600</TT +>600</VAR ></P ></TD ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->IN</TT +>IN</VAR ></P ></TD ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->A</TT +>A</VAR ></P ></TD ><TD -WIDTH="195" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->10.0.0.3</TT +>10.0.0.3</VAR ></P ></TD ></TR @@ -417,9 +357,9 @@ CLASS="literal" ></P ></DIV ><P ->When a resolver queries for these records, <SPAN +>When a resolver queries for these records, <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > will rotate them and respond to the query with the records in a different order. In the example above, clients will randomly receive @@ -442,9 +382,9 @@ HREF="Bv9ARM.ch06.html#rrset_ordering" ></A >. This substatement is not supported in - <SPAN + <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9, and only the ordering scheme described above is available.</P ></DIV @@ -517,41 +457,27 @@ from the command line.</P ><B CLASS="command" >dig</B -> [@<TT +> [@<VAR CLASS="replaceable" -><I ->server</I -></TT ->] <TT +>server</VAR +>] <VAR CLASS="replaceable" -><I ->domain</I -></TT -> [<TT +>domain</VAR +> [<VAR CLASS="replaceable" -><I ->query-type</I -></TT ->] [<TT +>query-type</VAR +>] [<VAR CLASS="replaceable" -><I ->query-class</I -></TT ->] [+<TT +>query-class</VAR +>] [+<VAR CLASS="replaceable" -><I ->query-option</I -></TT ->] [-<TT +>query-option</VAR +>] [-<VAR CLASS="replaceable" -><I ->dig-option</I -></TT ->] [%<TT +>dig-option</VAR +>] [%<VAR CLASS="replaceable" -><I ->comment</I -></TT +>comment</VAR >]</P ><P >The usual simple use of dig will take the form</P @@ -585,41 +511,27 @@ can be extended with the use of options.</P ><B CLASS="command" >host</B -> [-aCdlrTwv] [-c <TT +> [-aCdlrTwv] [-c <VAR CLASS="replaceable" -><I ->class</I -></TT ->] [-N <TT +>class</VAR +>] [-N <VAR CLASS="replaceable" -><I ->ndots</I -></TT ->] [-t <TT +>ndots</VAR +>] [-t <VAR CLASS="replaceable" -><I ->type</I -></TT ->] [-W <TT +>type</VAR +>] [-W <VAR CLASS="replaceable" -><I ->timeout</I -></TT ->] [-R <TT +>timeout</VAR +>] [-R <VAR CLASS="replaceable" -><I ->retries</I -></TT ->] <TT +>retries</VAR +>] <VAR CLASS="replaceable" -><I ->hostname</I -></TT -> [<TT +>hostname</VAR +> [<VAR CLASS="replaceable" -><I ->server</I -></TT +>server</VAR >]</P ><P >For more information and a list of available commands and @@ -647,11 +559,9 @@ the name and requested information for a host or domain.</P ><B CLASS="command" >nslookup</B -> [-option...] [<TT +> [-option...] [<VAR CLASS="replaceable" -><I ->host-to-find</I -></TT +>host-to-find</VAR > | - [server]]</P ><P >Interactive mode is entered when no arguments are given (the @@ -695,10 +605,10 @@ CLASS="variablelist" ><DT ><A NAME="named-checkconf" +></A ><B CLASS="command" >named-checkconf</B -></A ></DT ><DD ><P @@ -714,25 +624,21 @@ CLASS="filename" ><B CLASS="command" >named-checkconf</B -> [-t <TT +> [-t <VAR CLASS="replaceable" -><I ->directory</I -></TT ->] [<TT +>directory</VAR +>] [<VAR CLASS="replaceable" -><I ->filename</I -></TT +>filename</VAR >]</P ></DD ><DT ><A NAME="named-checkzone" +></A ><B CLASS="command" >named-checkzone</B -></A ></DT ><DD ><P @@ -745,30 +651,24 @@ CLASS="command" ><B CLASS="command" >named-checkzone</B -> [-dq] [-c <TT +> [-dq] [-c <VAR CLASS="replaceable" -><I ->class</I -></TT ->] <TT +>class</VAR +>] <VAR CLASS="replaceable" -><I ->zone</I -></TT -> [<TT +>zone</VAR +> [<VAR CLASS="replaceable" -><I ->filename</I -></TT +>filename</VAR >]</P ></DD ><DT ><A NAME="rndc" +></A ><B CLASS="command" >rndc</B -></A ></DT ><DD ><P @@ -787,36 +687,24 @@ CLASS="command" ><B CLASS="command" >rndc</B -> [-c <TT +> [-c <VAR CLASS="replaceable" -><I ->config</I -></TT ->] [-s <TT +>config</VAR +>] [-s <VAR CLASS="replaceable" -><I ->server</I -></TT ->] [-p <TT +>server</VAR +>] [-p <VAR CLASS="replaceable" -><I ->port</I -></TT ->] [-y <TT +>port</VAR +>] [-y <VAR CLASS="replaceable" -><I ->key</I -></TT ->] <TT +>key</VAR +>] <VAR CLASS="replaceable" -><I ->command</I -></TT -> [<TT +>command</VAR +> [<VAR CLASS="replaceable" -><I ->command</I -></TT +>command</VAR >...]</P ><P ><B @@ -829,147 +717,113 @@ CLASS="command" CLASS="variablelist" ><DL ><DT -><TT +><KBD CLASS="userinput" -><B ->reload</B -></TT +>reload</KBD ></DT ><DD ><P >Reload configuration file and zones.</P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->reload <TT +>reload <VAR CLASS="replaceable" -><I ->zone</I -></TT +>zone</VAR > [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->class</I -></TT +>class</VAR > [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->view</I -></TT +>view</VAR ></SPAN >]</SPAN ->]</B -></TT +>]</KBD ></DT ><DD ><P >Reload the given zone.</P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->refresh <TT +>refresh <VAR CLASS="replaceable" -><I ->zone</I -></TT +>zone</VAR > [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->class</I -></TT +>class</VAR > [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->view</I -></TT +>view</VAR ></SPAN >]</SPAN ->]</B -></TT +>]</KBD ></DT ><DD ><P >Schedule zone maintenance for the given zone.</P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->retransfer <TT +>retransfer <VAR CLASS="replaceable" -><I ->zone</I -></TT +>zone</VAR > [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->class</I -></TT +>class</VAR > [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->view</I -></TT +>view</VAR ></SPAN >]</SPAN ->]</B -></TT +>]</KBD ></DT ><DD ><P >Retransfer the given zone from the master.</P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->freeze <TT +>freeze <VAR CLASS="replaceable" -><I ->zone</I -></TT +>zone</VAR > [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->class</I -></TT +>class</VAR > [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->view</I -></TT +>view</VAR ></SPAN >]</SPAN ->]</B -></TT +>]</KBD ></DT ><DD ><P @@ -980,34 +834,26 @@ CLASS="replaceable" be refused while the zone is frozen.</P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->unfreeze <TT +>unfreeze <VAR CLASS="replaceable" -><I ->zone</I -></TT +>zone</VAR > [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->class</I -></TT +>class</VAR > [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->view</I -></TT +>view</VAR ></SPAN >]</SPAN ->]</B -></TT +>]</KBD ></DT ><DD ><P @@ -1017,11 +863,9 @@ CLASS="replaceable" will no longer be refused.</P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->reconfig</B -></TT +>reconfig</KBD ></DT ><DD ><P @@ -1036,22 +880,18 @@ CLASS="command" </P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->stats</B -></TT +>stats</KBD ></DT ><DD ><P >Write server statistics to the statistics file.</P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->querylog</B -></TT +>querylog</KBD ></DT ><DD ><P @@ -1077,22 +917,18 @@ CLASS="filename" >.</P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->dumpdb</B -></TT +>dumpdb</KBD ></DT ><DD ><P >Dump the server's caches to the dump file. </P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->stop</B -></TT +>stop</KBD ></DT ><DD ><P @@ -1102,11 +938,9 @@ CLASS="userinput" of the updated zones.</P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->halt</B -></TT +>halt</KBD ></DT ><DD ><P @@ -1116,27 +950,21 @@ CLASS="userinput" is restarted.</P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->trace</B -></TT +>trace</KBD ></DT ><DD ><P >Increment the servers debugging level by one. </P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->trace <TT +>trace <VAR CLASS="replaceable" -><I ->level</I -></TT -></B -></TT +>level</VAR +></KBD ></DT ><DD ><P @@ -1144,33 +972,27 @@ CLASS="replaceable" value.</P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->notrace</B -></TT +>notrace</KBD ></DT ><DD ><P >Sets the server's debugging level to 0.</P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->flush</B -></TT +>flush</KBD ></DT ><DD ><P >Flushes the server's cache.</P ></DD ><DT -><TT +><KBD CLASS="userinput" -><B ->status</B -></TT +>status</KBD ></DT ><DD ><P @@ -1188,9 +1010,9 @@ explicit root zone configured.</P ></DL ></DIV ><P ->In <SPAN +>In <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9.2, <B CLASS="command" >rndc</B @@ -1225,9 +1047,9 @@ CLASS="command" CLASS="filename" >/etc/rndc.conf</TT >, but an alternate -location can be specified with the <TT +location can be specified with the <VAR CLASS="option" ->-c</TT +>-c</VAR > option. If the configuration file is not found, <B @@ -1238,13 +1060,13 @@ CLASS="command" CLASS="filename" >/etc/rndc.key</TT > (or whatever -<TT +<VAR CLASS="varname" ->sysconfdir</TT +>sysconfdir</VAR > was defined when -the <SPAN +the <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > build was configured). The <TT CLASS="filename" @@ -1304,9 +1126,9 @@ CLASS="command" >default-server</B > takes a host name or address argument and represents the server that will -be contacted if no <TT +be contacted if no <VAR CLASS="option" ->-s</TT +>-s</VAR > option is provided on the command line. <B @@ -1347,19 +1169,15 @@ CLASS="command" CLASS="command" >key</B > statement in named.conf. -The keyword <TT +The keyword <KBD CLASS="userinput" -><B ->key</B -></TT +>key</KBD > is followed by a key name, which must be a valid domain name, though it need not actually be hierarchical; thus, -a string like "<TT +a string like "<KBD CLASS="userinput" -><B ->rndc_key</B -></TT +>rndc_key</KBD >" is a valid name. The <B CLASS="command" @@ -1373,11 +1191,9 @@ CLASS="command" >secret</B >. While the configuration parser will accept any string as the argument -to algorithm, currently only the string "<TT +to algorithm, currently only the string "<KBD CLASS="userinput" -><B ->hmac-md5</B -></TT +>hmac-md5</KBD >" has any meaning. The secret is a base-64 encoded string.</P ><P @@ -1389,11 +1205,9 @@ defined using the <B CLASS="command" >key</B > statement with a server. -The keyword <TT +The keyword <KBD CLASS="userinput" -><B ->server</B -></TT +>server</KBD > is followed by a host name or address. The <B CLASS="command" @@ -1440,14 +1254,12 @@ CLASS="filename" >, would allow the command:</P ><P -><TT +><SAMP CLASS="prompt" ->$ </TT -><TT +>$ </SAMP +><KBD CLASS="userinput" -><B ->rndc reload</B -></TT +>rndc reload</KBD ></P ><P >to connect to 127.0.0.1 port 953 and cause the name server @@ -1461,9 +1273,9 @@ CLASS="programlisting" </PRE ><P >and it had an identical key statement for -<TT +<VAR CLASS="literal" ->rndc_key</TT +>rndc_key</VAR >.</P ><P >Running the <B @@ -1518,11 +1330,11 @@ CLASS="command" > command.</P ><DIV CLASS="informaltable" +><P +></P ><A NAME="AEN683" ></A -><P -></P ><TABLE CELLPADDING="3" BORDER="1" @@ -1530,9 +1342,6 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="108" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1540,9 +1349,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="384" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Causes the server to read <TT CLASS="filename" @@ -1553,9 +1359,6 @@ reload the database. </P ></TR ><TR ><TD -WIDTH="108" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1563,18 +1366,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="384" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Causes the server to clean up and exit.</P ></TD ></TR ><TR ><TD -WIDTH="108" -ALIGN="LEFT" -VALIGN="MIDDLE" > <P ><B CLASS="command" @@ -1583,9 +1380,6 @@ CLASS="command" > </TD ><TD -WIDTH="384" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Causes the server to clean up and exit.</P ></TD @@ -1642,9 +1436,9 @@ ACCESSKEY="N" WIDTH="33%" ALIGN="left" VALIGN="top" -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > Resource Requirements</TD ><TD WIDTH="34%" diff --git a/dist/bind/doc/arm/Bv9ARM.ch04.html b/dist/bind/doc/arm/Bv9ARM.ch04.html index 496c45b43fa..a1f90b4c512 100644 --- a/dist/bind/doc/arm/Bv9ARM.ch04.html +++ b/dist/bind/doc/arm/Bv9ARM.ch04.html @@ -1,11 +1,11 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >Advanced DNS Features</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"><LINK +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REL="HOME" TITLE="BIND 9 Administrator Reference Manual" HREF="Bv9ARM.html"><LINK @@ -70,8 +70,8 @@ CLASS="chapter" ><H1 ><A NAME="ch04" ->Chapter 4. Advanced DNS Features</A -></H1 +></A +>Chapter 4. Advanced DNS Features</H1 ><DIV CLASS="TOC" ><DL @@ -121,10 +121,10 @@ HREF="Bv9ARM.ch04.html#DNSSEC" ></DT ><DT >4.9. <A -HREF="Bv9ARM.ch04.html#AEN1019" ->IPv6 Support in <SPAN +HREF="Bv9ARM.ch04.html#AEN1001" +>IPv6 Support in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9</A ></DT ></DL @@ -138,9 +138,9 @@ NAME="notify" >4.1. Notify</A ></H1 ><P -><SPAN +><ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > NOTIFY is a mechanism that allows master servers to notify their slave servers of changes to a zone's data. In response to a <B @@ -150,9 +150,9 @@ CLASS="command" slave will check to see that its version of the zone is the current version and, if not, initiate a zone transfer.</P ><P -><SPAN +><ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > For more information about <B @@ -209,7 +209,7 @@ CLASS="command" > statement.</P ><P >Updating of secure zones (zones using DNSSEC) follows - RFC 3007: SIG and NXT records affected by updates are automatically + 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.</P @@ -261,11 +261,9 @@ CLASS="command" to the zone using <B CLASS="command" ->rndc freeze <TT +>rndc freeze <VAR CLASS="replaceable" -><I ->zone</I -></TT +>zone</VAR ></B >. This will also remove the zone's <TT @@ -275,11 +273,9 @@ CLASS="filename" and update the master file. Edit the zone file. Run <B CLASS="command" ->rndc unfreeze <TT +>rndc unfreeze <VAR CLASS="replaceable" -><I ->zone</I -></TT +>zone</VAR ></B > to reload the changed zone and re-enable dynamic updates.</P @@ -302,9 +298,9 @@ HREF="Bv9ARM.ch09.html#proposed_standards" >Proposed Standards</A >.</P ><P ->When acting as a master, <SPAN +>When acting as a master, <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 supports IXFR for those zones where the necessary change history information is available. These @@ -316,17 +312,15 @@ transfer (AXFR), IXFR is supported only if the option CLASS="command" >ixfr-from-differences</B > is set -to <TT +to <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD >. </P ><P ->When acting as a slave, <SPAN +>When acting as a slave, <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 will attempt to use IXFR unless it is explicitly disabled. For more information about disabling @@ -381,9 +375,9 @@ CLASS="emphasis" >Example, Inc.</I ></SPAN > -(<TT +(<VAR CLASS="literal" ->example.com</TT +>example.com</VAR >) has several corporate sites that have an internal network with reserved Internet Protocol (IP) space and an external demilitarized zone (DMZ), @@ -495,9 +489,9 @@ internal hosts.</P >Here's an example of a wildcard MX record:</P ><PRE CLASS="programlisting" -><TT +><VAR CLASS="literal" ->* IN MX 10 external1.example.com.</TT +>* IN MX 10 external1.example.com.</VAR ></PRE ><P >Now that they accept mail on behalf of anything in the internal @@ -534,24 +528,24 @@ internal clients will now be able to:</P ><UL ><LI ><P ->Look up any hostnames in the <TT +>Look up any hostnames in the <VAR CLASS="literal" ->site1</TT +>site1</VAR > and -<TT +<VAR CLASS="literal" ->site2.example.com</TT +>site2.example.com</VAR > zones.</P ></LI ><LI ><P ->Look up any hostnames in the <TT +>Look up any hostnames in the <VAR CLASS="literal" ->site1.internal</TT +>site1.internal</VAR > and -<TT +<VAR CLASS="literal" ->site2.internal</TT +>site2.internal</VAR > domains.</P ></LI ><LI @@ -570,24 +564,24 @@ CLASS="literal" ><UL ><LI ><P ->Look up any hostnames in the <TT +>Look up any hostnames in the <VAR CLASS="literal" ->site1</TT +>site1</VAR > and -<TT +<VAR CLASS="literal" ->site2.example.com</TT +>site2.example.com</VAR > zones.</P ></LI ><LI ><P ->Exchange mail with anyone in the <TT +>Exchange mail with anyone in the <VAR CLASS="literal" ->site1</TT +>site1</VAR > and -<TT +<VAR CLASS="literal" ->site2.example.com</TT +>site2.example.com</VAR > zones.</P ></LI ></UL @@ -605,9 +599,9 @@ CLASS="programlisting" > acl internals { 172.16.72.0/24; 192.168.1.0/24; }; -acl externals { <TT +acl externals { <VAR CLASS="varname" ->bastion-ips-go-here</TT +>bastion-ips-go-here</VAR >; }; options { @@ -615,9 +609,9 @@ options { ... forward only; forwarders { // forward to external servers - <TT + <VAR CLASS="varname" ->bastion-ips-go-here</TT +>bastion-ips-go-here</VAR >; }; allow-transfer { none; }; // sample allow-transfer (no one) @@ -719,25 +713,25 @@ NAME="tsig" ></H1 ><P >This is a short guide to setting up Transaction SIGnatures -(TSIG) based transaction security in <SPAN +(TSIG) based transaction security in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM >. It describes changes to the configuration file as well as what changes are required for different features, including the process of creating transaction -keys and using transaction signatures with <SPAN +keys and using transaction signatures with <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM >.</P ><P -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > primarily supports TSIG for server to server communication. This includes zone transfer, notify, and recursive query messages. -Resolvers based on newer versions of <SPAN +Resolvers based on newer versions of <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8 have limited support for TSIG.</P ><P @@ -749,13 +743,13 @@ for TSIG.</P CLASS="command" >nsupdate</B > - program supports TSIG via the <TT + program supports TSIG via the <VAR CLASS="option" ->-k</TT +>-k</VAR > and - <TT + <VAR CLASS="option" ->-y</TT +>-y</VAR > command line options.</P ><DIV CLASS="sect2" @@ -796,11 +790,9 @@ are easier to read. Note that the maximum key length is 512 bits; keys longer than that will be digested with MD5 to produce a 128 bit key.</P ><P -><TT +><KBD CLASS="userinput" -><B ->dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</B -></TT +>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</KBD ></P ><P >The key is in the file <TT @@ -808,18 +800,18 @@ CLASS="filename" >Khost1-host2.+157+00000.private</TT >. Nothing directly uses this file, but the base-64 encoded string -following "<TT +following "<VAR CLASS="literal" ->Key:</TT +>Key:</VAR >" can be extracted from the file and used as a shared secret:</P ><PRE CLASS="programlisting" >Key: La/E5CjG9O+os1jq0a2jdA==</PRE ><P ->The string "<TT +>The string "<VAR CLASS="literal" ->La/E5CjG9O+os1jq0a2jdA==</TT +>La/E5CjG9O+os1jq0a2jdA==</VAR >" can be used as the shared secret.</P ></DIV @@ -890,9 +882,9 @@ CLASS="programlisting" }; </PRE ><P ->The algorithm, hmac-md5, is the only one supported by <SPAN +>The algorithm, hmac-md5, is the only one supported by <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM >. The secret is the one generated above. Since this is a secret, it is recommended that either <TT @@ -1003,9 +995,9 @@ NAME="AEN900" >4.5.5. TSIG Key Based Access Control</A ></H2 ><P -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > allows IP addresses and ranges to be specified in ACL definitions and <B @@ -1087,9 +1079,9 @@ CLASS="command" CLASS="command" >TKEY</B > that specify how the key is - generated or assigned. <SPAN + generated or assigned. <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 implements only one of these modes, the Diffie-Hellman key exchange. Both hosts are required to have @@ -1145,9 +1137,9 @@ NAME="AEN932" >4.7. SIG(0)</A ></H1 ><P -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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 @@ -1161,9 +1153,9 @@ CLASS="acronym" >SIG(0) signing of multiple-message TCP streams is not supported.</P ><P ->The only tool shipped with <SPAN +>The only tool shipped with <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 that generates SIG(0) signed messages is <B CLASS="command" @@ -1184,36 +1176,41 @@ NAME="DNSSEC" CLASS="emphasis" ><I CLASS="emphasis" ->DNSSEC</I +>DNSSEC-bis</I ></SPAN >) extensions, - defined in RFC 2535. This section describes the creation and use + defined in RFC <TBA>. This section describes the creation and use of DNSSEC signed zones.</P ><P >In order to set up a DNSSEC secure zone, there are a series - of steps which must be followed. <SPAN + of steps which must be followed. <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 ships with several tools that are used in this process, which are explained in more detail - below. In all cases, the <TT + below. In all cases, the <VAR CLASS="option" ->-h</TT +>-h</VAR > option prints a full list of parameters. Note that the DNSSEC tools require the - keyset and signedkey files to be in the working directory or the - directory specified by the <TT + keyset files to be in the working directory or the + directory specified by the <VAR CLASS="option" ->-h</TT +>-h</VAR > option, and - that the tools shipped with BIND 9.0.x are not fully compatible + that the tools shipped with BIND 9.2.x and earlier are not compatible with the current ones.</P ><P >There must also be communication with the administrators of - the parent and/or child zone to transmit keys and signatures. A - zone's security status must be indicated by the parent zone for a - DNSSEC capable resolver to trust its data.</P + 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 <VAR +CLASS="literal" +>DS</VAR +> record at the delegation + point.</P ><P >For other servers to trust data in this zone, they must either be statically configured with this zone's zone key or the @@ -1223,7 +1220,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN951" +NAME="AEN952" >4.8.1. Generating Keys</A ></H2 ><P @@ -1243,29 +1240,27 @@ CLASS="command" >, 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 - these are RSASHA1 and DSA.</P + the only one is RSASHA1.</P ><P ->The following command will generate a 768 bit DSA key for +>The following command will generate a 768 bit RSASHA1 key for the <TT CLASS="filename" >child.example</TT > zone:</P ><P -><TT +><KBD CLASS="userinput" -><B ->dnssec-keygen -a DSA -b 768 -n ZONE child.example.</B -></TT +>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</KBD ></P ><P >Two output files will be produced: <TT CLASS="filename" ->Kchild.example.+003+12345.key</TT +>Kchild.example.+005+12345.key</TT > and <TT CLASS="filename" ->Kchild.example.+003+12345.private</TT +>Kchild.example.+005+12345.private</TT > (where 12345 is an example of a key tag). The key file names contain the key name (<TT @@ -1303,111 +1298,8 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN971" ->4.8.2. Creating a Keyset</A -></H2 -><P ->The <B -CLASS="command" ->dnssec-makekeyset</B -> program is used - to create a key set from one or more keys.</P -><P ->Once the zone keys have been generated, a key set must be - built for transmission to the administrator of the parent zone, - so that the parent zone can sign the keys with its own zone key - and correctly indicate the security status of this zone. When - building a key set, the list of keys to be included and the TTL - of the set must be specified, and the desired signature validity - period of the parent's signature may also be specified.</P -><P ->The list of keys to be inserted into the key set may also - included non-zone keys present at the top of the zone. - <B -CLASS="command" ->dnssec-makekeyset</B -> may also be used at other - names in the zone.</P -><P ->The following command generates a key set containing the - above key and another key similarly generated, with a TTL of - 3600 and a signature validity period of 10 days starting from - now.</P -><P -><TT -CLASS="userinput" -><B ->dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 Kchild.example.+003+23456</B -></TT -></P -><P ->One output file is produced: - <TT -CLASS="filename" ->keyset-child.example.</TT ->. This file should be - transmitted to the parent to be signed. It includes the keys, - as well as signatures over the key set generated by the zone - keys themselves, which are used to prove ownership of the - private keys and encode the desired validity period.</P -></DIV -><DIV -CLASS="sect2" -><H2 -CLASS="sect2" -><A -NAME="AEN983" ->4.8.3. Signing the Child's Keyset</A -></H2 -><P ->The <B -CLASS="command" ->dnssec-signkey</B -> program is used to - sign one child's keyset.</P -><P ->If the <TT -CLASS="filename" ->child.example</TT -> zone has any - delegations which are secure, for example, - <TT -CLASS="filename" ->grand.child.example</TT ->, the - <TT -CLASS="filename" ->child.example</TT -> administrator should receive - keyset files for each secure subzone. These keys must be signed - by this zone's zone keys.</P -><P ->The following command signs the child's key set with the - zone keys:</P -><P -><TT -CLASS="userinput" -><B ->dnssec-signkey keyset-grand.child.example. Kchild.example.+003+12345 Kchild.example.+003+23456</B -></TT -></P -><P ->One output file is produced: - <TT -CLASS="filename" ->signedkey-grand.child.example.</TT ->. This file - should be both transmitted back to the child and retained. It - includes all keys (the child's keys) from the keyset file and - signatures generated by this zone's zone keys.</P -></DIV -><DIV -CLASS="sect2" -><H2 -CLASS="sect2" -><A -NAME="AEN996" ->4.8.4. Signing the Zone</A +NAME="AEN972" +>4.8.2. Signing the Zone</A ></H2 ><P >The <B @@ -1418,24 +1310,29 @@ CLASS="command" ><P >Any <TT CLASS="filename" ->signedkey</TT -> files corresponding to - secure subzones should be present, as well as a - <TT -CLASS="filename" ->signedkey</TT -> file for this zone generated by - the parent (if there is one). The zone signer will generate - <TT +>keyset</TT +> files corresponding + to secure subzones should be present. The zone signer will + generate <VAR CLASS="literal" ->NXT</TT -> and <TT +>NSEC</VAR +> and <VAR +CLASS="literal" +>RRSIG</VAR +> + records for the zone, as well as <VAR +CLASS="literal" +>DS</VAR +> for + the child zones if <VAR +CLASS="literal" +>'-d'</VAR +> is specified. + If <VAR CLASS="literal" ->SIG</TT -> records for - the zone, as well as incorporate the zone key signature from the - parent and indicate the security status at all delegation - points.</P +>'-d'</VAR +> is not specified then DS RRsets for + the secure child zones need to be added manually.</P ><P >The following command signs the zone, assuming it is in a file called <TT @@ -1445,11 +1342,9 @@ CLASS="filename" default, all zone keys which have an available private key are used to generate signatures.</P ><P -><TT +><KBD CLASS="userinput" -><B ->dnssec-signzone -o child.example zone.child.example</B -></TT +>dnssec-signzone -o child.example zone.child.example</KBD ></P ><P >One output file is produced: @@ -1462,23 +1357,38 @@ CLASS="filename" >named.conf</TT > as the input file for the zone.</P +><P +><B +CLASS="command" +>dnssec-signzone</B +> will also produce a + keyset and dsset files and optionally a dlvset file. These + are used to provide the parent zone administators with the + <VAR +CLASS="literal" +>DNSKEYs</VAR +> (or their corresponding <VAR +CLASS="literal" +>DS</VAR +> + records) that are the secure entry point to the zone.</P ></DIV ><DIV CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1012" ->4.8.5. Configuring Servers</A +NAME="AEN994" +>4.8.3. Configuring Servers</A ></H2 ><P ->Unlike <SPAN +>Unlike <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8, -<SPAN +<ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 does not verify signatures on load, so zone keys for authoritative zones do not need to be specified in the configuration file.</P @@ -1496,42 +1406,42 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN1019" ->4.9. IPv6 Support in <SPAN +NAME="AEN1001" +>4.9. IPv6 Support in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9</A ></H1 ><P -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 fully supports all currently defined forms of IPv6 name to address and address to name lookups. It will also use IPv6 addresses to make queries when running on an IPv6 capable system.</P ><P ->For forward lookups, <SPAN +>For forward lookups, <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 supports only AAAA records. The use of A6 records is deprecated by RFC 3363, and the - support for forward lookups in <SPAN + support for forward lookups in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 is removed accordingly. - However, authoritative <SPAN + However, authoritative <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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.</P ><P ->For IPv6 reverse lookups, <SPAN +>For IPv6 reverse lookups, <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 supports the traditional "nibble" format used in the <SPAN @@ -1548,21 +1458,21 @@ CLASS="emphasis" >ip6.int</I ></SPAN > domain. - <SPAN + <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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 <SPAN + Any applications in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 do not understand the format any more, and will return an error if given. - In particular, an authoritative <SPAN + In particular, an authoritative <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 name server rejects to load a zone file containing binary labels.</P ><P @@ -1576,7 +1486,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1037" +NAME="AEN1019" >4.9.1. Address Lookups Using AAAA Records</A ></H2 ><P @@ -1586,14 +1496,14 @@ NAME="AEN1037" ><PRE CLASS="programlisting" > $ORIGIN example.com. -host 3600 IN AAAA 2001:4f8:201:1860:42::1 +host 3600 IN AAAA 2001:db8::1 </PRE ><P >It is recommended that IPv4-in-IPv6 mapped addresses not be used. If a host has an IPv4 address, use an A record, not - a AAAA, with <TT + a AAAA, with <VAR CLASS="literal" ->::ffff:192.168.42.1</TT +>::ffff:192.168.42.1</VAR > as the address.</P ></DIV @@ -1602,26 +1512,26 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1043" +NAME="AEN1025" >4.9.2. Address to Name Lookups Using Nibble Format</A ></H2 ><P >When looking up an address in nibble format, the address components are simply reversed, just as in IPv4, and - <TT + <VAR CLASS="literal" ->ip6.arpa.</TT +>ip6.arpa.</VAR > is appended to the resulting name. For example, the following would provide reverse name lookup for a host with address - <TT + <VAR CLASS="literal" ->2001:4f8:201:1860:42::1</TT +>2001:db8::1</VAR >.</P ><PRE CLASS="programlisting" -> $ORIGIN 0.6.8.1.1.0.2.0.8.f.4.0.1.0.0.2.ip6.arpa. -1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0 14400 IN PTR host.example.com. +> $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. </PRE ></DIV ></DIV @@ -1680,9 +1590,9 @@ VALIGN="top" WIDTH="33%" ALIGN="right" VALIGN="top" ->The <SPAN +>The <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 Lightweight Resolver</TD ></TR ></TABLE diff --git a/dist/bind/doc/arm/Bv9ARM.ch05.html b/dist/bind/doc/arm/Bv9ARM.ch05.html index 1153c053d41..2ae7f2ec130 100644 --- a/dist/bind/doc/arm/Bv9ARM.ch05.html +++ b/dist/bind/doc/arm/Bv9ARM.ch05.html @@ -1,11 +1,11 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >The BIND 9 Lightweight Resolver</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"><LINK +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REL="HOME" TITLE="BIND 9 Administrator Reference Manual" HREF="Bv9ARM.html"><LINK @@ -70,11 +70,11 @@ CLASS="chapter" ><H1 ><A NAME="ch05" ->Chapter 5. The <SPAN +></A +>Chapter 5. The <ACRONYM CLASS="acronym" ->BIND</SPAN -> 9 Lightweight Resolver</A -></H1 +>BIND</ACRONYM +> 9 Lightweight Resolver</H1 ><DIV CLASS="TOC" ><DL @@ -84,7 +84,7 @@ CLASS="TOC" ></DT ><DT >5.1. <A -HREF="Bv9ARM.ch05.html#AEN1052" +HREF="Bv9ARM.ch05.html#AEN1034" >The Lightweight Resolver Library</A ></DT ><DT @@ -99,7 +99,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN1052" +NAME="AEN1034" >5.1. The Lightweight Resolver Library</A ></H1 ><P @@ -113,9 +113,9 @@ 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.</P ><P ->Instead, <SPAN +>Instead, <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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 @@ -253,9 +253,9 @@ VALIGN="top" WIDTH="33%" ALIGN="right" VALIGN="top" -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 Configuration Reference</TD ></TR ></TABLE diff --git a/dist/bind/doc/arm/Bv9ARM.ch06.html b/dist/bind/doc/arm/Bv9ARM.ch06.html index d8ab5775469..a83ec38ef3f 100644 --- a/dist/bind/doc/arm/Bv9ARM.ch06.html +++ b/dist/bind/doc/arm/Bv9ARM.ch06.html @@ -1,11 +1,11 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >BIND 9 Configuration Reference</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"><LINK +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REL="HOME" TITLE="BIND 9 Administrator Reference Manual" HREF="Bv9ARM.html"><LINK @@ -70,11 +70,11 @@ CLASS="chapter" ><H1 ><A NAME="ch06" ->Chapter 6. <SPAN +></A +>Chapter 6. <ACRONYM CLASS="acronym" ->BIND</SPAN -> 9 Configuration Reference</A -></H1 +>BIND</ACRONYM +> 9 Configuration Reference</H1 ><DIV CLASS="TOC" ><DL @@ -94,38 +94,38 @@ HREF="Bv9ARM.ch06.html#Configuration_File_Grammar" ></DT ><DT >6.3. <A -HREF="Bv9ARM.ch06.html#AEN4019" +HREF="Bv9ARM.ch06.html#AEN4015" >Zone File</A ></DT ></DL ></DIV ><P -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 configuration is broadly similar -to <SPAN +to <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8; however, there are a few new areas -of configuration, such as views. <SPAN +of configuration, such as views. <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > -8 configuration files should work with few alterations in <SPAN +8 configuration files should work with few alterations in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9, although more complex configurations should be reviewed to check if they can be more efficiently implemented using the new features -found in <SPAN +found in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9.</P ><P -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 4 configuration files can be converted to the new format using the shell script <TT @@ -141,18 +141,18 @@ NAME="configuration_file_elements" >6.1. Configuration File Elements</A ></H1 ><P ->Following is a list of elements used throughout the <SPAN +>Following is a list of elements used throughout the <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > configuration file documentation:</P ><DIV CLASS="informaltable" -><A -NAME="AEN1094" -></A ><P ></P +><A +NAME="AEN1076" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -160,23 +160,17 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->acl_name</TT +>acl_name</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ->The name of an <TT +>The name of an <VAR CLASS="varname" ->address_match_list</TT +>address_match_list</VAR > as defined by the <B CLASS="command" @@ -186,34 +180,28 @@ CLASS="command" ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->address_match_list</TT +>address_match_list</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ->A list of one or more <TT +>A list of one or more <VAR CLASS="varname" ->ip_addr</TT +>ip_addr</VAR >, -<TT +<VAR CLASS="varname" ->ip_prefix</TT ->, <TT +>ip_prefix</VAR +>, <VAR CLASS="varname" ->key_id</TT +>key_id</VAR >, -or <TT +or <VAR CLASS="varname" ->acl_name</TT +>acl_name</VAR > elements, see <A HREF="Bv9ARM.ch06.html#address_match_lists" @@ -223,42 +211,30 @@ HREF="Bv9ARM.ch06.html#address_match_lists" ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->domain_name</TT +>domain_name</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >A quoted string which will be used as -a DNS name, for example "<TT +a DNS name, for example "<VAR CLASS="literal" ->my.test.domain</TT +>my.test.domain</VAR >".</P ></TD ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->dotted_decimal</TT +>dotted_decimal</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >One to four integers valued 0 through 255 separated by dots (`.'), such as <B @@ -276,46 +252,34 @@ CLASS="command" ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->ip4_addr</TT +>ip4_addr</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >An IPv4 address with exactly four elements -in <TT +in <VAR CLASS="varname" ->dotted_decimal</TT +>dotted_decimal</VAR > notation.</P ></TD ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->ip6_addr</TT +>ip6_addr</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >An IPv6 address, such as <B CLASS="command" ->2001:ffff::200:f8ff:fe01:9742</B +>2001:db8::1234</B >. IPv6 scoped addresses that have ambiguity on their scope zones must be disambiguated by an appropriate zone ID with the percent character @@ -344,52 +308,40 @@ ambiguity, and need to be disambiguated.</P ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->ip_addr</TT +>ip_addr</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ->An <TT +>An <VAR CLASS="varname" ->ip4_addr</TT -> or <TT +>ip4_addr</VAR +> or <VAR CLASS="varname" ->ip6_addr</TT +>ip6_addr</VAR >.</P ></TD ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->ip_port</TT +>ip_port</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ->An IP port <TT +>An IP port <VAR CLASS="varname" ->number</TT +>number</VAR >. -<TT +<VAR CLASS="varname" ->number</TT +>number</VAR > 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 @@ -398,28 +350,22 @@ select a random high-numbered port.</P ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->ip_prefix</TT +>ip_prefix</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ->An IP network specified as an <TT +>An IP network specified as an <VAR CLASS="varname" ->ip_addr</TT +>ip_addr</VAR >, followed by a slash (`/') and then the number of bits in the netmask. -Trailing zeros in a <TT +Trailing zeros in a <VAR CLASS="varname" ->ip_addr</TT +>ip_addr</VAR > may omitted. For example, <B CLASS="command" @@ -446,65 +392,47 @@ CLASS="command" ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->key_id</TT +>key_id</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ->A <TT +>A <VAR CLASS="varname" ->domain_name</TT +>domain_name</VAR > representing the name of a shared key, to be used for transaction security.</P ></TD ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->key_list</TT +>key_list</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ->A list of one or more <TT +>A list of one or more <VAR CLASS="varname" ->key_id</TT +>key_id</VAR >s, separated by semicolons and ending with a semicolon.</P ></TD ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->number</TT +>number</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >A non-negative 32 bit integer (i.e., a number between 0 and 4294967295, inclusive). @@ -514,19 +442,13 @@ be limited by the context in which it is used.</P ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->path_name</TT +>path_name</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >A quoted string which will be used as a pathname, such as <TT @@ -537,212 +459,148 @@ CLASS="filename" ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->size_spec</TT +>size_spec</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ->A number, the word <TT +>A number, the word <KBD CLASS="userinput" -><B ->unlimited</B -></TT +>unlimited</KBD >, -or the word <TT +or the word <KBD CLASS="userinput" -><B ->default</B -></TT +>default</KBD >.</P ><P -> An <TT +> An <VAR CLASS="varname" ->unlimited</TT -> <TT +>unlimited</VAR +> <VAR CLASS="varname" ->size_spec</TT +>size_spec</VAR > requests unlimited -use, or the maximum available amount. A <TT +use, or the maximum available amount. A <VAR CLASS="varname" ->default size_spec</TT +>default size_spec</VAR > uses the limit that was in force when the server was started.</P ><P ->A <TT +>A <VAR CLASS="varname" ->number</TT +>number</VAR > can -optionally be followed by a scaling factor: <TT +optionally be followed by a scaling factor: <KBD CLASS="userinput" -><B ->K</B -></TT -> or <TT +>K</KBD +> or <KBD CLASS="userinput" -><B ->k</B -></TT +>k</KBD > for -kilobytes, <TT +kilobytes, <KBD CLASS="userinput" -><B ->M</B -></TT -> or <TT +>M</KBD +> or <KBD CLASS="userinput" -><B ->m</B -></TT +>m</KBD > for -megabytes, and <TT +megabytes, and <KBD CLASS="userinput" -><B ->G</B -></TT -> or <TT +>G</KBD +> or <KBD CLASS="userinput" -><B ->g</B -></TT +>g</KBD > for gigabytes, which scale by 1024, 1024*1024, and 1024*1024*1024 respectively.</P > <P >The value must be representable as a 64-bit unsigned integer (0 to 18446744073709551615, inclusive). -Using <TT +Using <VAR CLASS="varname" ->unlimited</TT +>unlimited</VAR > is the best way to safely set a really large number.</P ></TD ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->yes_or_no</TT +>yes_or_no</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ->Either <TT +>Either <KBD CLASS="userinput" -><B ->yes</B -></TT -> or <TT +>yes</KBD +> or <KBD CLASS="userinput" -><B ->no</B -></TT +>no</KBD >. -The words <TT +The words <KBD CLASS="userinput" -><B ->true</B -></TT -> and <TT +>true</KBD +> and <KBD CLASS="userinput" -><B ->false</B -></TT +>false</KBD > are -also accepted, as are the numbers <TT +also accepted, as are the numbers <KBD CLASS="userinput" -><B ->1</B -></TT -> and <TT +>1</KBD +> and <KBD CLASS="userinput" -><B ->0</B -></TT +>0</KBD >.</P ></TD ></TR ><TR ><TD -WIDTH="178" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->dialup_option</TT +>dialup_option</VAR ></P ></TD ><TD -WIDTH="362" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ->One of <TT +>One of <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD >, -<TT +<KBD CLASS="userinput" -><B ->no</B -></TT ->, <TT +>no</KBD +>, <KBD CLASS="userinput" -><B ->notify</B -></TT +>notify</KBD >, -<TT +<KBD CLASS="userinput" -><B ->notify-passive</B -></TT ->, <TT +>notify-passive</KBD +>, <KBD CLASS="userinput" -><B ->refresh</B -></TT +>refresh</KBD > or -<TT +<KBD CLASS="userinput" -><B ->passive</B -></TT +>passive</KBD >. -When used in a zone, <TT +When used in a zone, <KBD CLASS="userinput" -><B ->notify-passive</B -></TT +>notify-passive</KBD >, -<TT +<KBD CLASS="userinput" -><B ->refresh</B -></TT ->, and <TT +>refresh</KBD +>, and <KBD CLASS="userinput" -><B ->passive</B -></TT +>passive</KBD > are restricted to slave and stub zones.</P ></TD @@ -765,22 +623,22 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN1259" +NAME="AEN1241" >6.1.1.1. Syntax</A ></H3 ><PRE CLASS="programlisting" -><TT +><VAR CLASS="varname" ->address_match_list</TT +>address_match_list</VAR > = address_match_list_element ; [<SPAN CLASS="optional" > address_match_list_element; ... </SPAN >] -<TT +<VAR CLASS="varname" ->address_match_list_element</TT +>address_match_list_element</VAR > = [<SPAN CLASS="optional" > ! </SPAN @@ -796,7 +654,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN1267" +NAME="AEN1249" >6.1.1.2. Definition and Usage</A ></H3 ><P @@ -910,17 +768,17 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1298" +NAME="AEN1280" >6.1.2. Comment Syntax</A ></H2 ><P ->The <SPAN +>The <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 comment syntax allows for comments to appear -anywhere that white space may appear in a <SPAN +anywhere that white space may appear in a <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > configuration file. To appeal to programmers of all kinds, they can be written in the C, C++, or shell/perl style.</P @@ -929,29 +787,29 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN1303" +NAME="AEN1285" >6.1.2.1. Syntax</A ></H3 ><P ><PRE CLASS="programlisting" ->/* This is a <SPAN +>/* This is a <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > comment as in C */</PRE > <PRE CLASS="programlisting" ->// This is a <SPAN +>// This is a <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > comment as in C++</PRE > <PRE CLASS="programlisting" -># This is a <SPAN +># This is a <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > comment as in common UNIX shells and perl</PRE > </P @@ -961,14 +819,14 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN1312" +NAME="AEN1294" >6.1.2.2. Definition and Usage</A ></H3 ><P >Comments may appear anywhere that whitespace may appear in -a <SPAN +a <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > configuration file.</P ><P >C-style comments start with the two characters /* (slash, @@ -1004,9 +862,9 @@ CLASS="programlisting" ></P ><P >Shell-style (or perl-style, if you prefer) comments start -with the character <TT +with the character <VAR CLASS="literal" ->#</TT +>#</VAR > (number sign) and continue to the end of the physical line, as in C++ comments.</P ><P @@ -1059,9 +917,9 @@ NAME="Configuration_File_Grammar" >6.2. Configuration File Grammar</A ></H1 ><P ->A <SPAN +>A <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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 @@ -1071,11 +929,11 @@ CLASS="acronym" >The following statements are supported:</P ><DIV CLASS="informaltable" -><A -NAME="AEN1336" -></A ><P ></P +><A +NAME="AEN1318" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -1083,9 +941,6 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="128" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1093,9 +948,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="363" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >defines a named IP address matching list, for access control and other uses.</P @@ -1103,9 +955,6 @@ matching list, for access control and other uses.</P ></TR ><TR ><TD -WIDTH="128" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1113,9 +962,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="363" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >declares control channels to be used by the <B @@ -1126,9 +972,6 @@ CLASS="command" ></TR ><TR ><TD -WIDTH="128" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1136,18 +979,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="363" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >includes a file.</P ></TD ></TR ><TR ><TD -WIDTH="128" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1155,9 +992,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="363" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >specifies key information for use in authentication and authorization using TSIG.</P @@ -1165,9 +999,6 @@ authentication and authorization using TSIG.</P ></TR ><TR ><TD -WIDTH="128" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1175,9 +1006,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="363" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >specifies what the server logs, and where the log messages are sent.</P @@ -1185,9 +1013,6 @@ the log messages are sent.</P ></TR ><TR ><TD -WIDTH="128" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1195,9 +1020,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="363" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >configures <B CLASS="command" @@ -1211,9 +1033,6 @@ CLASS="command" ></TR ><TR ><TD -WIDTH="128" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1221,9 +1040,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="363" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >defines a named masters list for inclusion in stub and slave zone masters clauses.</P @@ -1231,9 +1047,6 @@ inclusion in stub and slave zone masters clauses.</P ></TR ><TR ><TD -WIDTH="128" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1241,9 +1054,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="363" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >controls global server configuration options and sets defaults for other statements.</P @@ -1251,9 +1061,6 @@ options and sets defaults for other statements.</P ></TR ><TR ><TD -WIDTH="128" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1261,9 +1068,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="363" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >sets certain configuration options on a per-server basis.</P @@ -1271,9 +1075,6 @@ a per-server basis.</P ></TR ><TR ><TD -WIDTH="128" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1281,18 +1082,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="363" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >defines trusted DNSSEC keys.</P ></TD ></TR ><TR ><TD -WIDTH="128" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1300,18 +1095,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="363" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >defines a view.</P ></TD ></TR ><TR ><TD -WIDTH="128" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1319,9 +1108,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="363" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >defines a zone.</P ></TD @@ -1346,7 +1132,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1419" +NAME="AEN1401" >6.2.1. <B CLASS="command" >acl</B @@ -1392,11 +1178,11 @@ CLASS="command" >The following ACLs are built-in:</P ><DIV CLASS="informaltable" -><A -NAME="AEN1432" -></A ><P ></P +><A +NAME="AEN1414" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -1404,9 +1190,6 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="108" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1414,18 +1197,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="384" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Matches all hosts.</P ></TD ></TR ><TR ><TD -WIDTH="108" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1433,18 +1210,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="384" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Matches no hosts.</P ></TD ></TR ><TR ><TD -WIDTH="108" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1452,9 +1223,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="384" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Matches the IPv4 and IPv6 addresses of all network interfaces on the system.</P @@ -1462,9 +1230,6 @@ interfaces on the system.</P ></TR ><TR ><TD -WIDTH="108" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -1472,9 +1237,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="384" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Matches any host on an IPv4 or IPv6 network for which the system has an interface. @@ -1502,7 +1264,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1463" +NAME="AEN1445" >6.2.3. <B CLASS="command" >controls</B @@ -1517,17 +1279,13 @@ CLASS="command" inet ( ip_addr | * ) [<SPAN CLASS="optional" > port ip_port </SPAN ->] allow { <TT +>] allow { <VAR CLASS="replaceable" -><I -> address_match_list </I -></TT +> address_match_list </VAR > } - keys { <TT + keys { <VAR CLASS="replaceable" -><I -> key_list </I -></TT +> key_list </VAR > }; [<SPAN CLASS="optional" @@ -1577,38 +1335,38 @@ CLASS="command" CLASS="command" >ip_addr</B > - of <TT + of <VAR CLASS="literal" ->*</TT +>*</VAR > 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 <B CLASS="command" >ip_addr</B -> of <TT +> of <VAR CLASS="literal" ->::</TT +>::</VAR >. If you will only use <B CLASS="command" >rndc</B > on the local host, - using the loopback address (<TT + using the loopback address (<VAR CLASS="literal" ->127.0.0.1</TT +>127.0.0.1</VAR > - or <TT + or <VAR CLASS="literal" ->::1</TT +>::1</VAR >) is recommended for maximum security. </P ><P > If no port is specified, port 953 - is used. "<TT + is used. "<VAR CLASS="literal" ->*</TT +>*</VAR >" cannot be used for <B CLASS="command" @@ -1700,23 +1458,21 @@ CLASS="filename" <TT CLASS="filename" >/etc</TT -> (or whatever <TT +> (or whatever <VAR CLASS="varname" ->sysconfdir</TT +>sysconfdir</VAR > -was specified as when <SPAN +was specified as when <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > was built). To create a <TT CLASS="filename" >rndc.key</TT > file, run -<TT +<KBD CLASS="userinput" -><B ->rndc-confgen -a</B -></TT +>rndc-confgen -a</KBD >. </P ><P @@ -1724,9 +1480,9 @@ CLASS="userinput" CLASS="filename" >rndc.key</TT > feature was created to - ease the transition of systems from <SPAN + ease the transition of systems from <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8, which did not have digital signatures on its command channel messages and thus did not have a <B @@ -1734,13 +1490,13 @@ CLASS="command" >keys</B > clause. -It makes it possible to use an existing <SPAN +It makes it possible to use an existing <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8 -configuration file in <SPAN +configuration file in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 unchanged, and still have <B CLASS="command" @@ -1750,11 +1506,9 @@ CLASS="command" CLASS="command" >ndc</B > worked in BIND 8, simply by executing the -command <TT +command <KBD CLASS="userinput" -><B ->rndc-confgen -a</B -></TT +>rndc-confgen -a</KBD > after BIND 9 is installed. </P @@ -1764,9 +1518,9 @@ CLASS="filename" >rndc.key</TT > feature is only intended to allow the backward-compatible usage of - <SPAN + <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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 @@ -1794,18 +1548,18 @@ CLASS="filename" > and make it group readable by a group that contains the users who should have access.</P ><P ->The UNIX control channel type of <SPAN +>The UNIX control channel type of <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8 is not supported - in <SPAN + in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9, and is not expected to be added in future releases. If it is present in the controls statement from a - <SPAN + <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8 configuration file, it is ignored and a warning is logged.</P ><P @@ -1824,7 +1578,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1542" +NAME="AEN1524" >6.2.5. <B CLASS="command" >include</B @@ -1832,11 +1586,9 @@ CLASS="command" ></H2 ><PRE CLASS="programlisting" ->include <TT +>include <VAR CLASS="replaceable" -><I ->filename</I -></TT +>filename</VAR >;</PRE ></DIV ><DIV @@ -1844,7 +1596,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1547" +NAME="AEN1529" >6.2.6. <B CLASS="command" >include</B @@ -1873,7 +1625,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1554" +NAME="AEN1536" >6.2.7. <B CLASS="command" >key</B @@ -1881,23 +1633,17 @@ CLASS="command" ></H2 ><PRE CLASS="programlisting" ->key <TT +>key <VAR CLASS="replaceable" -><I ->key_id</I -></TT +>key_id</VAR > { - algorithm <TT + algorithm <VAR CLASS="replaceable" -><I ->string</I -></TT +>string</VAR >; - secret <TT + secret <VAR CLASS="replaceable" -><I ->string</I -></TT +>string</VAR >; }; </PRE @@ -1907,7 +1653,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1561" +NAME="AEN1543" >6.2.8. <B CLASS="command" >key</B @@ -1953,11 +1699,9 @@ HREF="Bv9ARM.ch06.html#controls_statement_definition_and_usage" must be defined at the top level. </P ><P ->The <TT +>The <VAR CLASS="replaceable" -><I ->key_id</I -></TT +>key_id</VAR >, also known as the key name, is a domain name uniquely identifying the key. It can be used in a <B @@ -1969,23 +1713,19 @@ 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.</P ><P ->The <TT +>The <VAR CLASS="replaceable" -><I ->algorithm_id</I -></TT +>algorithm_id</VAR > is a string that specifies a security/authentication algorithm. The only algorithm currently supported with TSIG authentication is -<TT +<VAR CLASS="literal" ->hmac-md5</TT +>hmac-md5</VAR >. The -<TT +<VAR CLASS="replaceable" -><I ->secret_string</I -></TT +>secret_string</VAR > is the secret to be used by the algorithm, and is treated as a base-64 encoded string.</P @@ -1995,7 +1735,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1581" +NAME="AEN1563" >6.2.9. <B CLASS="command" >logging</B @@ -2010,50 +1750,40 @@ CLASS="command" [ <B CLASS="command" >channel</B -> <TT +> <VAR CLASS="replaceable" -><I ->channel_name</I -></TT +>channel_name</VAR > { ( <B CLASS="command" >file</B -> <TT +> <VAR CLASS="replaceable" -><I ->path name</I -></TT +>path name</VAR > [ <B CLASS="command" >versions</B -> ( <TT +> ( <VAR CLASS="replaceable" -><I ->number</I -></TT -> | <TT +>number</VAR +> | <VAR CLASS="literal" ->unlimited</TT +>unlimited</VAR > ) ] [ <B CLASS="command" >size</B -> <TT +> <VAR CLASS="replaceable" -><I ->size spec</I -></TT +>size spec</VAR > ] | <B CLASS="command" >syslog</B -> <TT +> <VAR CLASS="replaceable" -><I ->syslog_facility</I -></TT +>syslog_facility</VAR > | <B CLASS="command" @@ -2066,84 +1796,76 @@ CLASS="command" [ <B CLASS="command" >severity</B -> (<TT +> (<VAR CLASS="option" ->critical</TT -> | <TT +>critical</VAR +> | <VAR CLASS="option" ->error</TT -> | <TT +>error</VAR +> | <VAR CLASS="option" ->warning</TT -> | <TT +>warning</VAR +> | <VAR CLASS="option" ->notice</TT +>notice</VAR > | - <TT + <VAR CLASS="option" ->info</TT -> | <TT +>info</VAR +> | <VAR CLASS="option" ->debug</TT -> [ <TT +>debug</VAR +> [ <VAR CLASS="replaceable" -><I ->level</I -></TT -> ] | <TT +>level</VAR +> ] | <VAR CLASS="option" ->dynamic</TT +>dynamic</VAR > ); ] [ <B CLASS="command" >print-category</B -> <TT +> <VAR CLASS="option" ->yes</TT -> or <TT +>yes</VAR +> or <VAR CLASS="option" ->no</TT +>no</VAR >; ] [ <B CLASS="command" >print-severity</B -> <TT +> <VAR CLASS="option" ->yes</TT -> or <TT +>yes</VAR +> or <VAR CLASS="option" ->no</TT +>no</VAR >; ] [ <B CLASS="command" >print-time</B -> <TT +> <VAR CLASS="option" ->yes</TT -> or <TT +>yes</VAR +> or <VAR CLASS="option" ->no</TT +>no</VAR >; ] }; ] [ <B CLASS="command" >category</B -> <TT +> <VAR CLASS="replaceable" -><I ->category_name</I -></TT +>category_name</VAR > { - <TT + <VAR CLASS="replaceable" -><I ->channel_name</I -></TT -> ; [ <TT +>channel_name</VAR +> ; [ <VAR CLASS="replaceable" -><I ->channel_nam</I -></TT +>channel_nam</VAR >e ; ... ] }; ] ... @@ -2155,7 +1877,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1621" +NAME="AEN1603" >6.2.10. <B CLASS="command" >logging</B @@ -2194,13 +1916,13 @@ CLASS="programlisting" }; </PRE ><P ->In <SPAN +>In <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9, the logging configuration is only established when -the entire configuration file has been parsed. In <SPAN +the entire configuration file has been parsed. In <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8, it was established as soon as the <B CLASS="command" @@ -2208,9 +1930,9 @@ CLASS="command" > 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 "<TT +channels, or to standard error if the "<VAR CLASS="option" ->-g</TT +>-g</VAR >" option was specified.</P ><DIV @@ -2218,7 +1940,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN1637" +NAME="AEN1619" >6.2.10.1. The <B CLASS="command" >channel</B @@ -2520,9 +2242,9 @@ level is set either by starting the <B CLASS="command" >named</B > server -with the <TT +with the <VAR CLASS="option" ->-d</TT +>-d</VAR > flag followed by a positive integer, or by running <B CLASS="command" @@ -2587,9 +2309,9 @@ CLASS="command" > options are on:</P ><P -><TT +><SAMP CLASS="computeroutput" ->28-Feb-2000 15:05:32.863 general: notice: running</TT +>28-Feb-2000 15:05:32.863 general: notice: running</SAMP ></P ><P >There are four predefined channels that are used for @@ -2645,9 +2367,9 @@ CLASS="filename" > in the server's working directory.</P ><P ->For security reasons, when the "<TT +>For security reasons, when the "<VAR CLASS="option" ->-u</TT +>-u</VAR >" command line option is used, the <TT CLASS="filename" @@ -2662,9 +2384,9 @@ CLASS="command" >named</B > is starting up and still running as root is discarded. If you need -to capture this output, you must run the server with the "<TT +to capture this output, you must run the server with the "<VAR CLASS="option" ->-g</TT +>-g</VAR >" option and redirect standard error to a file.</P ><P @@ -2725,17 +2447,17 @@ category notify { null; }; ><P >Following are the available categories and brief descriptions of the types of log information they contain. More -categories may be added in future <SPAN +categories may be added in future <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > releases.</P ><DIV CLASS="informaltable" -><A -NAME="AEN1761" -></A ><P ></P +><A +NAME="AEN1743" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -2743,9 +2465,6 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -2753,9 +2472,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The default category defines the logging options for those categories where no specific configuration has been @@ -2764,9 +2480,6 @@ defined.</P ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -2774,9 +2487,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The catch-all. Many things still aren't classified into categories, and they all end up here.</P @@ -2784,9 +2494,6 @@ classified into categories, and they all end up here.</P ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -2794,9 +2501,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Messages relating to the databases used internally by the name server to store zone and cache data.</P @@ -2804,9 +2508,6 @@ internally by the name server to store zone and cache data.</P ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -2814,18 +2515,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Approval and denial of requests.</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -2833,18 +2528,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Configuration file parsing and processing.</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -2852,9 +2541,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >DNS resolution, such as the recursive lookups performed on behalf of clients by a caching name server.</P @@ -2862,9 +2548,6 @@ lookups performed on behalf of clients by a caching name server.</P ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -2872,18 +2555,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Zone transfers the server is receiving.</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -2891,18 +2568,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Zone transfers the server is sending.</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -2910,18 +2581,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The NOTIFY protocol.</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -2929,18 +2594,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Processing of client requests.</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -2948,9 +2607,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Messages that named was unable to determine the class of or for which there was no matching <B @@ -2970,9 +2626,6 @@ CLASS="command" ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -2980,18 +2633,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Network operations.</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -2999,18 +2646,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Dynamic updates.</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -3018,18 +2659,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Approval and denial of update requests.</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -3037,9 +2672,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Specify where queries should be logged to.</P > @@ -3054,13 +2686,29 @@ CLASS="command" > option has been specified. </P -></TD +> +<P +> 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).</P +> +<PRE +CLASS="programlisting" +><SAMP +CLASS="computeroutput" +>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</SAMP +> +<SAMP +CLASS="computeroutput" +>client ::1#62537: query: www.example.net IN AAAA -SE</SAMP +> +</PRE +> +</TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -3068,9 +2716,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Dispatching of incoming packets to the server modules where they are to be processed. @@ -3079,9 +2724,6 @@ server modules where they are to be processed. ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -3089,9 +2731,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >DNSSEC and TSIG protocol processing. </P @@ -3099,9 +2738,6 @@ VALIGN="MIDDLE" ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -3109,9 +2745,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Lame servers. These are misconfigurations in remote servers, discovered by BIND 9 when trying to query @@ -3121,9 +2754,6 @@ those servers during resolution. ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -3131,9 +2761,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Delegation only. Logs queries that have have been forced to NXDOMAIN as the result of a delegation-only zone or @@ -3156,7 +2783,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1887" +NAME="AEN1873" >6.2.11. <B CLASS="command" >lwres</B @@ -3179,70 +2806,54 @@ CLASS="command" > { [<SPAN CLASS="optional" -> listen-on { <TT +> listen-on { <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; ... </SPAN >] }; </SPAN >] [<SPAN CLASS="optional" -> view <TT +> view <VAR CLASS="replaceable" -><I ->view_name</I -></TT +>view_name</VAR >; </SPAN >] [<SPAN CLASS="optional" -> search { <TT +> search { <VAR CLASS="replaceable" -><I ->domain_name</I -></TT +>domain_name</VAR > ; [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->domain_name</I -></TT +>domain_name</VAR > ; ... </SPAN >] }; </SPAN >] [<SPAN CLASS="optional" -> ndots <TT +> ndots <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] }; @@ -3253,7 +2864,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1911" +NAME="AEN1897" >6.2.12. <B CLASS="command" >lwres</B @@ -3327,7 +2938,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1930" +NAME="AEN1916" >6.2.13. <B CLASS="command" >masters</B @@ -3338,44 +2949,32 @@ CLASS="programlisting" > <B CLASS="command" >masters</B -> <TT +> <VAR CLASS="replaceable" -><I ->name</I -></TT +>name</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN ->] { ( <TT +>] { ( <VAR CLASS="replaceable" -><I ->masters_list</I -></TT -> | <TT +>masters_list</VAR +> | <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] [<SPAN CLASS="optional" ->key <TT +>key <VAR CLASS="replaceable" -><I ->key</I -></TT +>key</VAR ></SPAN >] ) ; [<SPAN CLASS="optional" @@ -3388,7 +2987,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1945" +NAME="AEN1931" >6.2.14. <B CLASS="command" >masters</B @@ -3406,7 +3005,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1950" +NAME="AEN1936" >6.2.15. <B CLASS="command" >options</B @@ -3426,336 +3025,261 @@ CLASS="programlisting" >options { [<SPAN CLASS="optional" -> version <TT +> version <VAR CLASS="replaceable" -><I ->version_string</I -></TT +>version_string</VAR >; </SPAN >] [<SPAN CLASS="optional" -> hostname <TT +> hostname <VAR CLASS="replaceable" -><I ->hostname_string</I -></TT +>hostname_string</VAR >; </SPAN >] [<SPAN CLASS="optional" -> server-id <TT +> server-id <VAR CLASS="replaceable" -><I ->server_id_string</I -></TT +>server_id_string</VAR >; </SPAN >] [<SPAN CLASS="optional" -> directory <TT +> directory <VAR CLASS="replaceable" -><I ->path_name</I -></TT +>path_name</VAR >; </SPAN >] [<SPAN CLASS="optional" -> key-directory <TT +> key-directory <VAR CLASS="replaceable" -><I ->path_name</I -></TT +>path_name</VAR >; </SPAN >] [<SPAN CLASS="optional" -> named-xfer <TT +> named-xfer <VAR CLASS="replaceable" -><I ->path_name</I -></TT +>path_name</VAR >; </SPAN >] [<SPAN CLASS="optional" -> tkey-domain <TT +> tkey-domain <VAR CLASS="replaceable" -><I ->domainname</I -></TT +>domainname</VAR >; </SPAN >] [<SPAN CLASS="optional" -> tkey-dhkey <TT +> tkey-dhkey <VAR CLASS="replaceable" -><I ->key_name</I -></TT -> <TT +>key_name</VAR +> <VAR CLASS="replaceable" -><I ->key_tag</I -></TT +>key_tag</VAR >; </SPAN >] [<SPAN CLASS="optional" -> dump-file <TT +> dump-file <VAR CLASS="replaceable" -><I ->path_name</I -></TT +>path_name</VAR >; </SPAN >] [<SPAN CLASS="optional" -> memstatistics-file <TT +> memstatistics-file <VAR CLASS="replaceable" -><I ->path_name</I -></TT +>path_name</VAR >; </SPAN >] [<SPAN CLASS="optional" -> pid-file <TT +> pid-file <VAR CLASS="replaceable" -><I ->path_name</I -></TT +>path_name</VAR >; </SPAN >] [<SPAN CLASS="optional" -> statistics-file <TT +> statistics-file <VAR CLASS="replaceable" -><I ->path_name</I -></TT +>path_name</VAR >; </SPAN >] [<SPAN CLASS="optional" -> zone-statistics <TT +> zone-statistics <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> auth-nxdomain <TT +> auth-nxdomain <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> deallocate-on-exit <TT +> deallocate-on-exit <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> dialup <TT +> dialup <VAR CLASS="replaceable" -><I ->dialup_option</I -></TT +>dialup_option</VAR >; </SPAN >] [<SPAN CLASS="optional" -> fake-iquery <TT +> fake-iquery <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> fetch-glue <TT +> fetch-glue <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> flush-zones-on-shutdown <TT +> flush-zones-on-shutdown <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> has-old-clients <TT +> has-old-clients <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> host-statistics <TT +> host-statistics <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> minimal-responses <TT +> minimal-responses <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> multiple-cnames <TT +> multiple-cnames <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> notify <TT +> notify <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT -> | <TT +>yes_or_no</VAR +> | <VAR CLASS="replaceable" -><I ->explicit</I -></TT +>explicit</VAR >; </SPAN >] [<SPAN CLASS="optional" -> recursion <TT +> recursion <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> rfc2308-type1 <TT +> rfc2308-type1 <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> use-id-pool <TT +> use-id-pool <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> maintain-ixfr-base <TT +> maintain-ixfr-base <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> dnssec-enable <TT +> dnssec-enable <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> dnssec-lookaside <TT +> dnssec-lookaside <VAR CLASS="replaceable" -><I ->domain</I -></TT +>domain</VAR +> trust-anchor <VAR +CLASS="replaceable" +>domain</VAR >; </SPAN >] [<SPAN CLASS="optional" -> dnssec-must-be-secure <TT +> dnssec-must-be-secure <VAR CLASS="replaceable" -><I ->domain yes_or_no</I -></TT +>domain yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> forward ( <TT +> forward ( <VAR CLASS="replaceable" -><I ->only</I -></TT -> | <TT +>only</VAR +> | <VAR CLASS="replaceable" -><I ->first</I -></TT +>first</VAR > ); </SPAN >] [<SPAN CLASS="optional" -> forwarders { <TT +> forwarders { <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; ... </SPAN >] }; </SPAN @@ -3764,216 +3288,160 @@ CLASS="replaceable" CLASS="optional" > dual-stack-servers [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN ->] { ( <TT +>] { ( <VAR CLASS="replaceable" -><I ->domain_name</I -></TT +>domain_name</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN ->] | <TT +>] | <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ) ; ... }; </SPAN >] [<SPAN CLASS="optional" -> check-names ( <TT +> check-names ( <VAR CLASS="replaceable" -><I ->master</I -></TT -> | <TT +>master</VAR +> | <VAR CLASS="replaceable" -><I ->slave</I -></TT -> | <TT +>slave</VAR +> | <VAR CLASS="replaceable" -><I -> response</I -></TT -> )( <TT +> response</VAR +> )( <VAR CLASS="replaceable" -><I ->warn</I -></TT -> | <TT +>warn</VAR +> | <VAR CLASS="replaceable" -><I ->fail</I -></TT -> | <TT +>fail</VAR +> | <VAR CLASS="replaceable" -><I ->ignore</I -></TT +>ignore</VAR > ); </SPAN >] [<SPAN CLASS="optional" -> allow-notify { <TT +> allow-notify { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > }; </SPAN >] [<SPAN CLASS="optional" -> allow-query { <TT +> allow-query { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > }; </SPAN >] [<SPAN CLASS="optional" -> allow-transfer { <TT +> allow-transfer { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > }; </SPAN >] [<SPAN CLASS="optional" -> allow-recursion { <TT +> allow-recursion { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > }; </SPAN >] [<SPAN CLASS="optional" -> allow-update-forwarding { <TT +> allow-update-forwarding { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > }; </SPAN >] [<SPAN CLASS="optional" -> allow-v6-synthesis { <TT +> allow-v6-synthesis { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > }; </SPAN >] [<SPAN CLASS="optional" -> blackhole { <TT +> blackhole { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > }; </SPAN >] [<SPAN CLASS="optional" -> avoid-v4-udp-ports { <TT +> avoid-v4-udp-ports { <VAR CLASS="replaceable" -><I ->port_list</I -></TT +>port_list</VAR > }; </SPAN >] [<SPAN CLASS="optional" -> avoid-v6-udp-ports { <TT +> avoid-v6-udp-ports { <VAR CLASS="replaceable" -><I ->port_list</I -></TT +>port_list</VAR > }; </SPAN >] [<SPAN CLASS="optional" > listen-on [<SPAN CLASS="optional" -> port <TT +> port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR > </SPAN ->] { <TT +>] { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > }; </SPAN >] [<SPAN CLASS="optional" > listen-on-v6 [<SPAN CLASS="optional" -> port <TT +> port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR > </SPAN ->] { <TT +>] { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > }; </SPAN >] [<SPAN CLASS="optional" > query-source [<SPAN CLASS="optional" -> address ( <TT +> address ( <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT -> | <TT +>ip_addr</VAR +> | <VAR CLASS="replaceable" -><I ->*</I -></TT +>*</VAR > ) </SPAN >] [<SPAN CLASS="optional" -> port ( <TT +> port ( <VAR CLASS="replaceable" -><I ->ip_port</I -></TT -> | <TT +>ip_port</VAR +> | <VAR CLASS="replaceable" -><I ->*</I -></TT +>*</VAR > ) </SPAN >]; </SPAN >] @@ -3981,676 +3449,524 @@ CLASS="replaceable" CLASS="optional" > query-source-v6 [<SPAN CLASS="optional" -> address ( <TT +> address ( <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT -> | <TT +>ip_addr</VAR +> | <VAR CLASS="replaceable" -><I ->*</I -></TT +>*</VAR > ) </SPAN >] [<SPAN CLASS="optional" -> port ( <TT +> port ( <VAR CLASS="replaceable" -><I ->ip_port</I -></TT -> | <TT +>ip_port</VAR +> | <VAR CLASS="replaceable" -><I ->*</I -></TT +>*</VAR > ) </SPAN >]; </SPAN >] [<SPAN CLASS="optional" -> max-transfer-time-in <TT +> max-transfer-time-in <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> max-transfer-time-out <TT +> max-transfer-time-out <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> max-transfer-idle-in <TT +> max-transfer-idle-in <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> max-transfer-idle-out <TT +> max-transfer-idle-out <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> tcp-clients <TT +> tcp-clients <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> recursive-clients <TT +> recursive-clients <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> serial-query-rate <TT +> serial-query-rate <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> serial-queries <TT +> serial-queries <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> tcp-listen-queue <TT +> tcp-listen-queue <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> transfer-format <TT +> transfer-format <VAR CLASS="replaceable" -><I ->( one-answer | many-answers )</I -></TT +>( one-answer | many-answers )</VAR >; </SPAN >] [<SPAN CLASS="optional" -> transfers-in <TT +> transfers-in <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> transfers-out <TT +> transfers-out <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> transfers-per-ns <TT +> transfers-per-ns <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> transfer-source (<TT +> transfer-source (<VAR CLASS="replaceable" -><I ->ip4_addr</I -></TT -> | <TT +>ip4_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> transfer-source-v6 (<TT +> transfer-source-v6 (<VAR CLASS="replaceable" -><I ->ip6_addr</I -></TT -> | <TT +>ip6_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> alt-transfer-source (<TT +> alt-transfer-source (<VAR CLASS="replaceable" -><I ->ip4_addr</I -></TT -> | <TT +>ip4_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> alt-transfer-source-v6 (<TT +> alt-transfer-source-v6 (<VAR CLASS="replaceable" -><I ->ip6_addr</I -></TT -> | <TT +>ip6_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> use-alt-transfer-source <TT +> use-alt-transfer-source <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> notify-source (<TT +> notify-source (<VAR CLASS="replaceable" -><I ->ip4_addr</I -></TT -> | <TT +>ip4_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> notify-source-v6 (<TT +> notify-source-v6 (<VAR CLASS="replaceable" -><I ->ip6_addr</I -></TT -> | <TT +>ip6_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> also-notify { <TT +> also-notify { <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; ... </SPAN >] }; </SPAN >] [<SPAN CLASS="optional" -> max-ixfr-log-size <TT +> max-ixfr-log-size <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> max-journal-size <TT +> max-journal-size <VAR CLASS="replaceable" -><I ->size_spec</I -></TT +>size_spec</VAR >; </SPAN >] [<SPAN CLASS="optional" -> coresize <TT +> coresize <VAR CLASS="replaceable" -><I ->size_spec</I -></TT +>size_spec</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> datasize <TT +> datasize <VAR CLASS="replaceable" -><I ->size_spec</I -></TT +>size_spec</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> files <TT +> files <VAR CLASS="replaceable" -><I ->size_spec</I -></TT +>size_spec</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> stacksize <TT +> stacksize <VAR CLASS="replaceable" -><I ->size_spec</I -></TT +>size_spec</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> cleaning-interval <TT +> cleaning-interval <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> heartbeat-interval <TT +> heartbeat-interval <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> interface-interval <TT +> interface-interval <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> statistics-interval <TT +> statistics-interval <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> topology { <TT +> topology { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > }</SPAN >]; [<SPAN CLASS="optional" -> sortlist { <TT +> sortlist { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > }</SPAN >]; [<SPAN CLASS="optional" -> rrset-order { <TT +> rrset-order { <VAR CLASS="replaceable" -><I ->order_spec</I -></TT +>order_spec</VAR > ; [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->order_spec</I -></TT +>order_spec</VAR > ; ... </SPAN >] </SPAN >] }; [<SPAN CLASS="optional" -> lame-ttl <TT +> lame-ttl <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> max-ncache-ttl <TT +> max-ncache-ttl <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> max-cache-ttl <TT +> max-cache-ttl <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> sig-validity-interval <TT +> sig-validity-interval <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> min-roots <TT +> min-roots <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" -> use-ixfr <TT +> use-ixfr <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> provide-ixfr <TT +> provide-ixfr <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> request-ixfr <TT +> request-ixfr <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> treat-cr-as-space <TT +> treat-cr-as-space <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> min-refresh-time <TT +> min-refresh-time <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> max-refresh-time <TT +> max-refresh-time <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> min-retry-time <TT +> min-retry-time <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> max-retry-time <TT +> max-retry-time <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> port <TT +> port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR >; </SPAN >] [<SPAN CLASS="optional" -> additional-from-auth <TT +> additional-from-auth <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> additional-from-cache <TT +> additional-from-cache <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> random-device <TT +> random-device <VAR CLASS="replaceable" -><I ->path_name</I -></TT +>path_name</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> max-cache-size <TT +> max-cache-size <VAR CLASS="replaceable" -><I ->size_spec</I -></TT +>size_spec</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> match-mapped-addresses <TT +> match-mapped-addresses <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> preferred-glue ( <TT +> preferred-glue ( <VAR CLASS="replaceable" -><I ->A</I -></TT -> | <TT +>A</VAR +> | <VAR CLASS="replaceable" -><I ->AAAA</I -></TT -> | <TT +>AAAA</VAR +> | <VAR CLASS="replaceable" -><I ->NONE</I -></TT +>NONE</VAR > ); </SPAN >] [<SPAN CLASS="optional" -> edns-udp-size <TT +> edns-udp-size <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR >; </SPAN >] [<SPAN CLASS="optional" > root-delegation-only [<SPAN CLASS="optional" -> exclude { <TT +> exclude { <VAR CLASS="replaceable" -><I ->namelist</I -></TT +>namelist</VAR > } </SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> querylog <TT +> querylog <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; </SPAN >] }; [<SPAN CLASS="optional" -> disable-algorithms <TT +> disable-algorithms <VAR CLASS="replaceable" -><I ->domain</I -></TT -> { <TT +>domain</VAR +> { <VAR CLASS="replaceable" -><I ->algorithm</I -></TT +>algorithm</VAR >; [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->algorithm</I -></TT +>algorithm</VAR >; </SPAN >] }; </SPAN >] @@ -4672,9 +3988,9 @@ CLASS="command" CLASS="command" >options</B > statement sets up global options -to be used by <SPAN +to be used by <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM >. This statement may appear only once in a configuration file. If there is no <B CLASS="command" @@ -4734,17 +4050,17 @@ CLASS="emphasis" >This option is obsolete.</I ></SPAN > -It was used in <SPAN +It was used in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8 to specify the pathname to the <B CLASS="command" >named-xfer</B > program. -In <SPAN +In <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9, no separate <B CLASS="command" >named-xfer</B @@ -4768,21 +4084,21 @@ CLASS="command" >TKEY</B > exchange, it may or may not specify the desired name for the key. If present, the name of the shared -key will be "<TT +key will be "<VAR CLASS="varname" ->client specified part</TT +>client specified part</VAR >" + -"<TT +"<VAR CLASS="varname" ->tkey-domain</TT +>tkey-domain</VAR >". -Otherwise, the name of the shared key will be "<TT +Otherwise, the name of the shared key will be "<VAR CLASS="varname" >random hex -digits</TT ->" + "<TT +digits</VAR +>" + "<VAR CLASS="varname" ->tkey-domain</TT +>tkey-domain</VAR >". In most cases, the <B CLASS="command" @@ -4982,13 +4298,15 @@ CLASS="command" >dnssec-lookaside</B > provides the validator with an alternate method to validate DNSKEY records at the -top of a zone. When set the domain specified by -<B +top of a zone. When a DNSKEY is at or below a domain specified by the +deepest <B CLASS="command" >dnssec-lookaside</B -> is appended to DNSKEY's -name and a DLV record is looked up. If the DLV record validates -a DNSKEY (similarly to the way a DS record does) the DNSKEY RRset is deemed to be trusted. +>, 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. </P ></DD ><DT @@ -4999,18 +4317,14 @@ CLASS="command" ><DD ><P > Specify heirachies which must / may not be secure (signed and validated). -If <TT +If <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD > then named will only accept answers if they are secure. -If <TT +If <KBD CLASS="userinput" -><B ->no</B -></TT +>no</KBD > then normal dnssec validation applies allowing for insecure answers to be accepted. The specified domain must be under a <B @@ -5045,31 +4359,25 @@ CLASS="command" ></DT ><DD ><P ->If <TT +>If <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD >, then the <B CLASS="command" >AA</B > bit is always set on NXDOMAIN responses, even if the server is not actually -authoritative. The default is <TT +authoritative. The default is <KBD CLASS="userinput" -><B ->no</B -></TT +>no</KBD >; this is -a change from <SPAN +a change from <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8. If you are using very old DNS software, you -may need to set it to <TT +may need to set it to <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD >.</P ></DD ><DT @@ -5079,13 +4387,13 @@ CLASS="command" ></DT ><DD ><P ->This option was used in <SPAN +>This option was used in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8 to enable checking -for memory leaks on exit. <SPAN +for memory leaks on exit. <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 ignores the option and always performs the checks.</P ></DD @@ -5096,11 +4404,9 @@ CLASS="command" ></DT ><DD ><P ->If <TT +>If <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD >, 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 @@ -5111,11 +4417,9 @@ CLASS="command" >heartbeat-interval</B > and hopefully during the one call. It also suppresses some of the normal -zone maintenance traffic. The default is <TT +zone maintenance traffic. The default is <KBD CLASS="userinput" -><B ->no</B -></TT +>no</KBD >.</P ><P >The <B @@ -5159,43 +4463,35 @@ CLASS="command" NOTIFY requests.</P ><P >Finer control can be achieved by using -<TT +<KBD CLASS="userinput" -><B ->notify</B -></TT +>notify</KBD > which only sends NOTIFY messages, -<TT +<KBD CLASS="userinput" -><B ->notify-passive</B -></TT +>notify-passive</KBD > which sends NOTIFY messages and -suppresses the normal refresh queries, <TT +suppresses the normal refresh queries, <KBD CLASS="userinput" -><B ->refresh</B -></TT +>refresh</KBD > which suppresses normal refresh processing and sends refresh queries when the <B CLASS="command" >heartbeat-interval</B > expires, and -<TT +<KBD CLASS="userinput" -><B ->passive</B -></TT +>passive</KBD > which just disables normal refresh processing.</P ><DIV CLASS="informaltable" -><A -NAME="AEN2403" -></A ><P ></P +><A +NAME="AEN2390" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -5203,39 +4499,24 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >dialup mode</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >normal refresh</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >heart-beat refresh</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >heart-beat notify</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -5243,32 +4524,20 @@ CLASS="command" > (default)</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >yes</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >no</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >no</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -5276,32 +4545,20 @@ CLASS="command" ></P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >no</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >yes</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >yes</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -5309,32 +4566,20 @@ CLASS="command" ></P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >yes</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >no</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >yes</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -5342,32 +4587,20 @@ CLASS="command" ></P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >no</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >yes</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >no</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -5375,32 +4608,20 @@ CLASS="command" ></P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >no</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >no</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >no</P ></TD ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -5408,23 +4629,14 @@ CLASS="command" ></P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >no</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >no</P ></TD ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >yes</P ></TD @@ -5448,14 +4660,14 @@ CLASS="command" ></DT ><DD ><P ->In <SPAN +>In <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8, this option enabled simulating the obsolete DNS query type -IQUERY. <SPAN +IQUERY. <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 never does IQUERY simulation. </P ></DD @@ -5467,11 +4679,9 @@ CLASS="command" ><DD ><P >This option is obsolete. -In BIND 8, <TT +In BIND 8, <KBD CLASS="userinput" -><B ->fetch-glue yes</B -></TT +>fetch-glue yes</KBD > caused the server to attempt to fetch glue resource records it didn't have when constructing the additional @@ -5490,11 +4700,9 @@ flush / do not flush any pending zone writes. The default is <B CLASS="command" >flush-zones-on-shutdown</B -> <TT +> <KBD CLASS="userinput" -><B ->no</B -></TT +>no</KBD >. </P ></DD @@ -5506,41 +4714,35 @@ CLASS="command" ><DD ><P >This option was incorrectly implemented -in <SPAN +in <ACRONYM CLASS="acronym" ->BIND</SPAN -> 8, and is ignored by <SPAN +>BIND</ACRONYM +> 8, and is ignored by <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9. To achieve the intended effect of <B CLASS="command" >has-old-clients</B -> <TT +> <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD >, specify the two separate options <B CLASS="command" >auth-nxdomain</B -> <TT +> <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD > and <B CLASS="command" >rfc2308-type1</B -> <TT +> <KBD CLASS="userinput" -><B ->no</B -></TT +>no</KBD > instead. </P ></DD @@ -5570,23 +4772,21 @@ CLASS="emphasis" >This option is obsolete</I ></SPAN >. - It was used in <SPAN + It was used in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8 to determine whether a transaction log was -kept for Incremental Zone Transfer. <SPAN +kept for Incremental Zone Transfer. <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 maintains a transaction log whenever possible. If you need to disable outgoing incremental zone transfers, use <B CLASS="command" >provide-ixfr</B -> <TT +> <KBD CLASS="userinput" -><B ->no</B -></TT +>no</KBD >. </P ></DD @@ -5597,20 +4797,16 @@ CLASS="command" ></DT ><DD ><P ->If <TT +>If <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD >, 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 <TT +The default is <KBD CLASS="userinput" -><B ->no</B -></TT +>no</KBD >. </P ></DD @@ -5621,14 +4817,14 @@ CLASS="command" ></DT ><DD ><P ->This option was used in <SPAN +>This option was used in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8 to allow a domain name to have multiple CNAME records in violation of the -DNS standards. <SPAN +DNS standards. <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9.2 always strictly enforces the CNAME rules both in master files and dynamic updates. </P @@ -5640,11 +4836,9 @@ CLASS="command" ></DT ><DD ><P ->If <TT +>If <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD > (the default), DNS NOTIFY messages are sent when a zone the server is authoritative for changes, see <A @@ -5659,21 +4853,17 @@ CLASS="command" > option. </P ><P -> If <TT +> If <KBD CLASS="userinput" -><B ->explicit</B -></TT +>explicit</KBD >, notifies are sent only to servers explicitly listed using <B CLASS="command" >also-notify</B >. -If <TT +If <KBD CLASS="userinput" -><B ->no</B -></TT +>no</KBD >, no notifies are sent. </P ><P @@ -5699,20 +4889,16 @@ CLASS="command" ></DT ><DD ><P ->If <TT +>If <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD >, 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 <TT +referral response. The default is <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD >. Note that setting <B CLASS="command" @@ -5735,18 +4921,14 @@ CLASS="command" ></DT ><DD ><P ->Setting this to <TT +>Setting this to <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD > will cause the server to send NS records along with the SOA record for negative -answers. The default is <TT +answers. The default is <KBD CLASS="userinput" -><B ->no</B -></TT +>no</KBD >.</P ><DIV CLASS="note" @@ -5755,9 +4937,9 @@ CLASS="note" ><P ><B >Note: </B ->Not yet implemented in <SPAN +>Not yet implemented in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9.</P ></BLOCKQUOTE ></DIV @@ -5776,9 +4958,9 @@ CLASS="emphasis" >This option is obsolete</I ></SPAN >. -<SPAN +<ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 always allocates query IDs from a pool. </P ></DD @@ -5789,11 +4971,9 @@ CLASS="command" ></DT ><DD ><P ->If <TT +>If <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD >, the server will collect statistical data on all zones (unless specifically turned off on a per-zone basis by specifying <B @@ -5889,9 +5069,9 @@ CLASS="command" ></DT ><DD ><P ->This option was used in <SPAN +>This option was used in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8 to make the server treat carriage return ("<B CLASS="command" @@ -5899,9 +5079,9 @@ CLASS="command" >") 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 <SPAN +on an NT or DOS machine. In <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9, both UNIX "<B CLASS="command" >\n</B @@ -5927,11 +5107,9 @@ answering queries which have additional data, or when following CNAME and DNAME chains. </P ><P -> When both of these options are set to <TT +> When both of these options are set to <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD > (the default) and a query is being answered from authoritative data (a zone @@ -5946,17 +5124,17 @@ at the possible expense of additional queries to resolve what would otherwise be provided in the additional section. </P ><P -> For example, if a query asks for an MX record for host <TT +> For example, if a query asks for an MX record for host <VAR CLASS="literal" ->foo.example.com</TT +>foo.example.com</VAR >, -and the record found is "<TT +and the record found is "<VAR CLASS="literal" ->MX 10 mail.example.net</TT +>MX 10 mail.example.net</VAR >", normally the address -records (A and AAAA) for <TT +records (A and AAAA) for <VAR CLASS="literal" ->mail.example.net</TT +>mail.example.net</VAR > will be provided as well, if known, even though they are not in the example.com zone. Setting these options to <B @@ -6010,11 +5188,9 @@ CLASS="command" ></DT ><DD ><P ->If <TT +>If <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD >, then an IPv4-mapped IPv6 address will match any address match list entries that match the corresponding IPv4 address. @@ -6063,11 +5239,9 @@ CLASS="command" > 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 <TT +has. The default is <KBD CLASS="userinput" -><B ->no</B -></TT +>no</KBD >. </P ></DD @@ -6078,18 +5252,14 @@ CLASS="command" ></DT ><DD ><P -> Enable DNSSEC support in named. Unless set to <TT +> Enable DNSSEC support in named. Unless set to <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD > named behaves as if it does not support DNSSEC. -The default is <TT +The default is <KBD CLASS="userinput" -><B ->no</B -></TT +>no</KBD >. </P ></DD @@ -6119,7 +5289,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2682" +NAME="AEN2669" >6.2.16.2. Forwarding</A ></H3 ><P @@ -6143,15 +5313,15 @@ CLASS="command" ><DD ><P >This option is only meaningful if the -forwarders list is not empty. A value of <TT +forwarders list is not empty. A value of <VAR CLASS="varname" ->first</TT +>first</VAR >, 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 <TT +the answer itself. If <VAR CLASS="varname" ->only</TT +>only</VAR > is specified, the server will only query the forwarders. </P @@ -6187,11 +5357,11 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2701" ->6.2.16.3. 6 to 4 Servers</A +NAME="AEN2688" +>6.2.16.3. Dual-stack Servers</A ></H3 ><P ->6 to 4 servers are used as servers of last resort to work around +>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.</P ><P @@ -6312,31 +5482,23 @@ CLASS="command" ><P >Specifies which hosts are allowed to submit Dynamic DNS updates to slave zones to be forwarded to the -master. The default is <TT +master. The default is <KBD CLASS="userinput" -><B ->{ none; }</B -></TT +>{ none; }</KBD >, which means that no update forwarding will be performed. To enable update forwarding, specify -<TT +<KBD CLASS="userinput" -><B ->allow-update-forwarding { any; };</B -></TT +>allow-update-forwarding { any; };</KBD >. -Specifying values other than <TT +Specifying values other than <KBD CLASS="userinput" -><B ->{ none; }</B -></TT +>{ none; }</KBD > or -<TT +<KBD CLASS="userinput" -><B ->{ any; }</B -></TT +>{ any; }</KBD > is usually counterproductive, since the responsibility for update access control should rest with the master server, not the slaves.</P @@ -6394,11 +5556,9 @@ CLASS="command" ><P >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 <TT +from these addresses will not be responded to. The default is <KBD CLASS="userinput" -><B ->none</B -></TT +>none</KBD >.</P ></DD ></DL @@ -6409,7 +5569,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2768" +NAME="AEN2755" >6.2.16.5. Interfaces</A ></H3 ><P @@ -6421,9 +5581,9 @@ CLASS="command" CLASS="command" >listen-on</B > takes -an optional port, and an <TT +an optional port, and an <VAR CLASS="varname" ->address_match_list</TT +>address_match_list</VAR >. The server will listen on all interfaces allowed by the address match list. If a port is not specified, port 53 will be used.</P @@ -6449,11 +5609,35 @@ CLASS="command" > is specified, the server will listen on port 53 on all interfaces.</P ><P ->By default, the server does not bind a separate socket to each -IPv6 interface address as it does for IPv4. Instead, it listens on the -IPv6 wildcard address. -Alternatively, a list of IPv6 addresses can be specified, in which case -the server listens on a separate socket for each specified address.</P +>The <B +CLASS="command" +>listen-on-v6</B +> option is used to +specify the interfaces and the ports on which the server will listen +for incoming queries sent using IPv6.</P +><P +>When <PRE +CLASS="programlisting" +>{ any; }</PRE +> is specified +as the <VAR +CLASS="varname" +>address_match_list</VAR +> for the +<B +CLASS="command" +>listen-on-v6</B +> 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.</P +><P +>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.</P ><P >Multiple <B CLASS="command" @@ -6463,13 +5647,13 @@ For example,</P ><PRE CLASS="programlisting" >listen-on-v6 { any; }; -listen-on-v6 port 1234 { !3ffe::/16; any; }; +listen-on-v6 port 1234 { !2001:db8::/32; any; }; </PRE ><P >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 -3ffe::/16 (with separate sockets for each matched address.)</P +2001:db8::/32 (with separate sockets for each matched address.)</P ><P >To make the server not listen on any IPv6 address, use</P ><PRE @@ -6480,7 +5664,7 @@ CLASS="programlisting" >If no <B CLASS="command" >listen-on-v6</B -> statement is specified, +> option is specified, the server will not listen on any IPv6 address.</P ></DIV ><DIV @@ -6488,7 +5672,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2789" +NAME="AEN2782" >6.2.16.6. Query Address</A ></H3 ><P @@ -6502,7 +5686,7 @@ IPv6, there is a separate <B CLASS="command" >query-source-v6</B > option. - If <B +If <B CLASS="command" >address</B > is <B @@ -6550,6 +5734,23 @@ UDP queries. TCP queries always use a random unprivileged port.</P ></BLOCKQUOTE ></DIV +><DIV +CLASS="note" +><BLOCKQUOTE +CLASS="note" +><P +><B +>Note: </B +>See also <B +CLASS="command" +>transfer-source</B +> and +<B +CLASS="command" +>notify-source</B +>.</P +></BLOCKQUOTE +></DIV ></DIV ><DIV CLASS="sect3" @@ -6560,9 +5761,9 @@ NAME="zone_transfers" >6.2.16.7. Zone Transfers</A ></H3 ><P -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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.</P @@ -6729,16 +5930,16 @@ CLASS="command" >many-answers</B > is more efficient, but is only supported by relatively new slave servers, -such as <SPAN +such as <ACRONYM CLASS="acronym" ->BIND</SPAN -> 9, <SPAN +>BIND</ACRONYM +> 9, <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8.x and patched -versions of <SPAN +versions of <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 4.9.5. The default is <B CLASS="command" @@ -6762,9 +5963,9 @@ CLASS="command" ><DD ><P >The maximum number of inbound zone transfers -that can be running concurrently. The default value is <TT +that can be running concurrently. The default value is <VAR CLASS="literal" ->10</TT +>10</VAR >. Increasing <B CLASS="command" @@ -6781,9 +5982,9 @@ CLASS="command" ><P >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 <TT +of the limit will be refused. The default value is <VAR CLASS="literal" ->10</TT +>10</VAR >.</P ></DD ><DT @@ -6795,9 +5996,9 @@ CLASS="command" ><P >The maximum number of inbound zone transfers that can be concurrently transferring from a given remote name server. -The default value is <TT +The default value is <VAR CLASS="literal" ->2</TT +>2</VAR >. Increasing <B CLASS="command" >transfers-per-ns</B @@ -6979,7 +6180,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2951" +NAME="AEN2948" >6.2.16.8. Bad UDP Port Lists</A ></H3 ><P @@ -7003,7 +6204,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2956" +NAME="AEN2953" >6.2.16.9. Operating System Resource Limits</A ></H3 ><P @@ -7051,9 +6252,9 @@ CLASS="command" ><DD ><P >The maximum size of a core dump. The default -is <TT +is <VAR CLASS="literal" ->default</TT +>default</VAR >.</P ></DD ><DT @@ -7064,9 +6265,9 @@ CLASS="command" ><DD ><P >The maximum amount of data memory the server -may use. The default is <TT +may use. The default is <VAR CLASS="literal" ->default</TT +>default</VAR >. This is a hard limit on server memory usage. If the server attempts to allocate memory in excess of this @@ -7096,9 +6297,9 @@ CLASS="command" ><DD ><P >The maximum number of files the server -may have open concurrently. The default is <TT +may have open concurrently. The default is <VAR CLASS="literal" ->unlimited</TT +>unlimited</VAR >. </P ></DD @@ -7110,9 +6311,9 @@ CLASS="command" ><DD ><P >The maximum amount of stack memory the server -may use. The default is <TT +may use. The default is <VAR CLASS="literal" ->default</TT +>default</VAR >.</P ></DD ></DL @@ -7123,7 +6324,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2993" +NAME="AEN2990" >6.2.16.10. Server Resource Limits</A ></H3 ><P @@ -7165,9 +6366,9 @@ HREF="Bv9ARM.ch04.html#journal" >). When the journal file approaches the specified size, some of the oldest transactions in the journal will be automatically removed. The default is -<TT +<VAR CLASS="literal" ->unlimited</TT +>unlimited</VAR >.</P ></DD ><DT @@ -7179,9 +6380,9 @@ CLASS="command" ><P >The maximum number of simultaneous recursive lookups the server will perform on behalf of clients. The default is -<TT +<VAR CLASS="literal" ->1000</TT +>1000</VAR >. Because each recursing client uses a fair bit of memory, on the order of 20 kilobytes, the value of the <B @@ -7200,9 +6401,9 @@ CLASS="command" ><P >The maximum number of simultaneous client TCP connections that the server will accept. -The default is <TT +The default is <VAR CLASS="literal" ->100</TT +>100</VAR >.</P ></DD ><DT @@ -7217,9 +6418,9 @@ 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 <TT +view. The default is <VAR CLASS="literal" ->unlimited</TT +>unlimited</VAR >, meaning that records are purged from the cache only when their TTLs expire. </P @@ -7246,7 +6447,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN3034" +NAME="AEN3031" >6.2.16.11. Periodic Task Intervals</A ></H3 ><P @@ -7329,9 +6530,9 @@ CLASS="note" ><P ><B >Note: </B ->Not yet implemented in <SPAN +>Not yet implemented in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM >9.</P ></BLOCKQUOTE ></DIV @@ -7395,9 +6596,9 @@ CLASS="note" CLASS="command" >topology</B > option -is not implemented in <SPAN +is not implemented in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9. </P ></BLOCKQUOTE @@ -7516,9 +6717,9 @@ CLASS="programlisting" ><P >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 <SPAN +to the behavior of the address sort in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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 @@ -7566,34 +6767,26 @@ CLASS="command" CLASS="programlisting" >[<SPAN CLASS="optional" -> class <TT +> class <VAR CLASS="replaceable" -><I ->class_name</I -></TT +>class_name</VAR > </SPAN >][<SPAN CLASS="optional" -> type <TT +> type <VAR CLASS="replaceable" -><I ->type_name</I -></TT +>type_name</VAR > </SPAN >][<SPAN CLASS="optional" -> name <TT +> name <VAR CLASS="replaceable" -><I ->"domain_name"</I -></TT +>"domain_name"</VAR ></SPAN >] - order <TT + order <VAR CLASS="replaceable" -><I ->ordering</I -></TT +>ordering</VAR > </PRE ><P @@ -7616,11 +6809,11 @@ CLASS="command" > are:</P ><DIV CLASS="informaltable" -><A -NAME="AEN3122" -></A ><P ></P +><A +NAME="AEN3119" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -7628,9 +6821,6 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -7638,9 +6828,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="360" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Records are returned in the order they are defined in the zone file.</P @@ -7648,9 +6835,6 @@ are defined in the zone file.</P ></TR ><TR ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -7658,18 +6842,12 @@ CLASS="command" ></P ></TD ><TD -WIDTH="360" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Records are returned in some random order.</P ></TD ></TR ><TR ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -7677,9 +6855,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="360" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Records are returned in a round-robin order.</P @@ -7701,9 +6876,9 @@ CLASS="programlisting" </PRE ><P >will cause any responses for type A records in class IN that -have "<TT +have "<VAR CLASS="literal" ->host.example.com</TT +>host.example.com</VAR >" as a suffix, to always be returned in random order. All other records are returned in cyclic order.</P ><P @@ -7723,9 +6898,9 @@ CLASS="note" CLASS="command" >rrset-order</B > statement -is not yet fully implemented in <SPAN +is not yet fully implemented in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9. BIND 9 currently does not support "fixed" ordering. </P @@ -7761,13 +6936,13 @@ CLASS="emphasis" >NOT</B ></SPAN > recommended.) -Default is <TT +Default is <VAR CLASS="literal" ->600</TT +>600</VAR > (10 minutes). Maximum value is -<TT +<VAR CLASS="literal" ->1800</TT +>1800</VAR > (30 minutes).</P ></DD ><DT @@ -7787,9 +6962,9 @@ in seconds. The default <B CLASS="command" >max-ncache-ttl</B -> is <TT +> is <VAR CLASS="literal" ->10800</TT +>10800</VAR > seconds (3 hours). <B CLASS="command" @@ -7820,11 +6995,9 @@ CLASS="command" ><P >The minimum number of root servers that is required for a request for the root servers to be accepted. Default -is <TT +is <KBD CLASS="userinput" -><B ->2</B -></TT +>2</KBD >.</P ><DIV CLASS="note" @@ -7833,9 +7006,9 @@ CLASS="note" ><P ><B >Note: </B ->Not implemented in <SPAN +>Not implemented in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM >9.</P ></BLOCKQUOTE ></DIV @@ -7853,9 +7026,9 @@ of dynamic updates (<A HREF="Bv9ARM.ch04.html#dynamic_update" >Section 4.2</A >) -will expire. The default is <TT +will expire. The default is <VAR CLASS="literal" ->30</TT +>30</VAR > days. The maximum value is 10 years (3660 days). The signature inception time is unconditionally set to one hour before the current time @@ -7922,9 +7095,9 @@ NAME="builtin" ><P >The server provides some helpful diagnostic information through a number of built-in zones under the -pseudo-top-level-domain <TT +pseudo-top-level-domain <VAR CLASS="literal" ->bind</TT +>bind</VAR > in the <B CLASS="command" @@ -7969,9 +7142,9 @@ CLASS="command" ><DD ><P >The version the server should report -via a query of the name <TT +via a query of the name <VAR CLASS="literal" ->version.bind</TT +>version.bind</VAR > with type <B CLASS="command" @@ -8067,14 +7240,14 @@ NAME="statsfile" >6.2.16.17. The Statistics File</A ></H3 ><P ->The statistics file generated by <SPAN +>The statistics file generated by <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 is similar, but not identical, to that -generated by <SPAN +generated by <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8. </P ><P @@ -8098,11 +7271,11 @@ number is identical to the number in the beginning line.</P >The following statistics counters are maintained:</P ><DIV CLASS="informaltable" -><A -NAME="AEN3266" -></A ><P ></P +><A +NAME="AEN3263" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -8110,9 +7283,6 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -8120,9 +7290,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The number of successful queries made to the server or zone. A successful query @@ -8132,9 +7299,6 @@ one answer RR.</P ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -8142,9 +7306,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The number of queries which resulted in referral responses.</P @@ -8152,9 +7313,6 @@ in referral responses.</P ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -8162,9 +7320,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The number of queries which resulted in NOERROR responses with no data.</P @@ -8172,9 +7327,6 @@ NOERROR responses with no data.</P ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -8182,9 +7334,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The number of queries which resulted in NXDOMAIN responses.</P @@ -8192,9 +7341,6 @@ of queries which resulted in NXDOMAIN responses.</P ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -8202,9 +7348,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The number of queries which resulted in a failure response other than those above.</P @@ -8212,9 +7355,6 @@ failure response other than those above.</P ></TR ><TR ><TD -WIDTH="110" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -8222,9 +7362,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="322" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The number of queries which caused the server to perform recursion in order to find the final answer.</P @@ -8278,118 +7415,94 @@ CLASS="command" ></H2 ><PRE CLASS="programlisting" ->server <TT +>server <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > { [<SPAN CLASS="optional" -> bogus <TT +> bogus <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> provide-ixfr <TT +> provide-ixfr <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> request-ixfr <TT +> request-ixfr <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> edns <TT +> edns <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> transfers <TT +> transfers <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> transfer-format <TT +> transfer-format <VAR CLASS="replaceable" -><I ->( one-answer | many-answers )</I -></TT +>( one-answer | many-answers )</VAR > ; ]</SPAN >] [<SPAN CLASS="optional" -> keys <TT +> keys <VAR CLASS="replaceable" -><I >{ string ; [<SPAN CLASS="optional" > string ; [<SPAN CLASS="optional" >...</SPAN >]</SPAN ->] }</I -></TT +>] }</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> transfer-source (<TT +> transfer-source (<VAR CLASS="replaceable" -><I ->ip4_addr</I -></TT -> | <TT +>ip4_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> transfer-source-v6 (<TT +> transfer-source-v6 (<VAR CLASS="replaceable" -><I ->ip6_addr</I -></TT -> | <TT +>ip6_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] @@ -8526,16 +7639,16 @@ as many resource records as possible into a message. <B CLASS="command" >many-answers</B > is -more efficient, but is only known to be understood by <SPAN +more efficient, but is only known to be understood by <ACRONYM CLASS="acronym" ->BIND</SPAN -> 9, <SPAN +>BIND</ACRONYM +> 9, <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > -8.x, and patched versions of <SPAN +8.x, and patched versions of <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 4.9.5. You can specify which method to use for a server with the <B CLASS="command" @@ -8633,7 +7746,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN3405" +NAME="AEN3402" >6.2.19. <B CLASS="command" >trusted-keys</B @@ -8642,59 +7755,39 @@ CLASS="command" ><PRE CLASS="programlisting" >trusted-keys { - <TT + <VAR CLASS="replaceable" -><I ->string</I -></TT -> <TT +>string</VAR +> <VAR CLASS="replaceable" -><I ->number</I -></TT -> <TT +>number</VAR +> <VAR CLASS="replaceable" -><I ->number</I -></TT -> <TT +>number</VAR +> <VAR CLASS="replaceable" -><I ->number</I -></TT -> <TT +>number</VAR +> <VAR CLASS="replaceable" -><I ->string</I -></TT +>string</VAR > ; [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->string</I -></TT -> <TT +>string</VAR +> <VAR CLASS="replaceable" -><I ->number</I -></TT -> <TT +>number</VAR +> <VAR CLASS="replaceable" -><I ->number</I -></TT -> <TT +>number</VAR +> <VAR CLASS="replaceable" -><I ->number</I -></TT -> <TT +>number</VAR +> <VAR CLASS="replaceable" -><I ->string</I -></TT +>string</VAR > ; [<SPAN CLASS="optional" >...</SPAN @@ -8708,7 +7801,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN3421" +NAME="AEN3418" >6.2.20. <B CLASS="command" >trusted-keys</B @@ -8751,55 +7844,41 @@ CLASS="command" ></H2 ><PRE CLASS="programlisting" ->view <TT +>view <VAR CLASS="replaceable" -><I ->view_name</I -></TT +>view_name</VAR > [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->class</I -></TT +>class</VAR ></SPAN >] { - match-clients { <TT + match-clients { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > } ; - match-destinations { <TT + match-destinations { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > } ; - match-recursive-only <TT + match-recursive-only <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->view_option</I -></TT +>view_option</VAR >; ...</SPAN >] [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->zone_statement</I -></TT +>zone_statement</VAR >; ...</SPAN >] }; @@ -8810,7 +7889,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN3443" +NAME="AEN3440" >6.2.22. <B CLASS="command" >view</B @@ -8821,9 +7900,9 @@ CLASS="command" CLASS="command" >view</B > statement is a powerful new feature -of <SPAN +of <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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.</P @@ -8834,17 +7913,17 @@ CLASS="command" > 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 -<TT +<VAR CLASS="varname" ->address_match_list</TT +>address_match_list</VAR > of the view's <B CLASS="command" >match-clients</B > clause and its destination IP address matches -the <TT +the <VAR CLASS="varname" ->address_match_list</TT +>address_match_list</VAR > of the view's <B CLASS="command" @@ -9003,18 +8082,14 @@ Statement Grammar</A ></H2 ><PRE CLASS="programlisting" ->zone <TT +>zone <VAR CLASS="replaceable" -><I ->zone_name</I -></TT +>zone_name</VAR > [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->class</I -></TT +>class</VAR ></SPAN >] [<SPAN CLASS="optional" @@ -9022,47 +8097,37 @@ CLASS="optional" type ( master | slave | hint | stub | forward | delegation-only ) ; [<SPAN CLASS="optional" -> allow-notify { <TT +> allow-notify { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > } ; </SPAN >] [<SPAN CLASS="optional" -> allow-query { <TT +> allow-query { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > } ; </SPAN >] [<SPAN CLASS="optional" -> allow-transfer { <TT +> allow-transfer { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > } ; </SPAN >] [<SPAN CLASS="optional" -> allow-update { <TT +> allow-update { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > } ; </SPAN >] [<SPAN CLASS="optional" -> update-policy { <TT +> update-policy { <VAR CLASS="replaceable" -><I ->update_policy_rule</I -></TT +>update_policy_rule</VAR > [<SPAN CLASS="optional" >...</SPAN @@ -9070,191 +8135,151 @@ CLASS="optional" >] [<SPAN CLASS="optional" -> allow-update-forwarding { <TT +> allow-update-forwarding { <VAR CLASS="replaceable" -><I ->address_match_list</I -></TT +>address_match_list</VAR > } ; </SPAN >] [<SPAN CLASS="optional" -> also-notify { <TT +> also-notify { <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; ... </SPAN >] }; </SPAN >] [<SPAN CLASS="optional" -> check-names (<TT +> check-names (<CODE CLASS="constant" ->warn</TT ->|<TT +>warn</CODE +>|<CODE CLASS="constant" ->fail</TT ->|<TT +>fail</CODE +>|<CODE CLASS="constant" ->ignore</TT +>ignore</CODE >) ; </SPAN >] [<SPAN CLASS="optional" -> dialup <TT +> dialup <VAR CLASS="replaceable" -><I ->dialup_option</I -></TT +>dialup_option</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> delegation-only <TT +> delegation-only <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> file <TT +> file <VAR CLASS="replaceable" -><I ->string</I -></TT +>string</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> forward (<TT +> forward (<CODE CLASS="constant" ->only</TT ->|<TT +>only</CODE +>|<CODE CLASS="constant" ->first</TT +>first</CODE >) ; </SPAN >] [<SPAN CLASS="optional" -> forwarders { <TT +> forwarders { <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; ... </SPAN >] }; </SPAN >] [<SPAN CLASS="optional" -> ixfr-base <TT +> ixfr-base <VAR CLASS="replaceable" -><I ->string</I -></TT +>string</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> ixfr-tmp-file <TT +> ixfr-tmp-file <VAR CLASS="replaceable" -><I ->string</I -></TT +>string</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> maintain-ixfr-base <TT +> maintain-ixfr-base <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; </SPAN >] [<SPAN CLASS="optional" > masters [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN ->] { ( <TT +>] { ( <VAR CLASS="replaceable" -><I ->masters_list</I -></TT -> | <TT +>masters_list</VAR +> | <VAR CLASS="replaceable" -><I ->ip_addr</I -></TT +>ip_addr</VAR > [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] [<SPAN CLASS="optional" ->key <TT +>key <VAR CLASS="replaceable" -><I ->key</I -></TT +>key</VAR ></SPAN >] ) ; [<SPAN CLASS="optional" @@ -9263,295 +8288,229 @@ CLASS="optional" >] [<SPAN CLASS="optional" -> max-ixfr-log-size <TT +> max-ixfr-log-size <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> max-transfer-idle-in <TT +> max-transfer-idle-in <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> max-transfer-idle-out <TT +> max-transfer-idle-out <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> max-transfer-time-in <TT +> max-transfer-time-in <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> max-transfer-time-out <TT +> max-transfer-time-out <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> notify <TT +> notify <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT -> | <TT +>yes_or_no</VAR +> | <VAR CLASS="replaceable" -><I ->explicit</I -></TT +>explicit</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> pubkey <TT +> pubkey <VAR CLASS="replaceable" -><I ->number</I -></TT -> <TT +>number</VAR +> <VAR CLASS="replaceable" -><I ->number</I -></TT -> <TT +>number</VAR +> <VAR CLASS="replaceable" -><I ->number</I -></TT -> <TT +>number</VAR +> <VAR CLASS="replaceable" -><I ->string</I -></TT +>string</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> transfer-source (<TT +> transfer-source (<VAR CLASS="replaceable" -><I ->ip4_addr</I -></TT -> | <TT +>ip4_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> transfer-source-v6 (<TT +> transfer-source-v6 (<VAR CLASS="replaceable" -><I ->ip6_addr</I -></TT -> | <TT +>ip6_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> alt-transfer-source (<TT +> alt-transfer-source (<VAR CLASS="replaceable" -><I ->ip4_addr</I -></TT -> | <TT +>ip4_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> alt-transfer-source-v6 (<TT +> alt-transfer-source-v6 (<VAR CLASS="replaceable" -><I ->ip6_addr</I -></TT -> | <TT +>ip6_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> use-alt-transfer-source <TT +> use-alt-transfer-source <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR >; </SPAN >] [<SPAN CLASS="optional" -> notify-source (<TT +> notify-source (<VAR CLASS="replaceable" -><I ->ip4_addr</I -></TT -> | <TT +>ip4_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> notify-source-v6 (<TT +> notify-source-v6 (<VAR CLASS="replaceable" -><I ->ip6_addr</I -></TT -> | <TT +>ip6_addr</VAR +> | <CODE CLASS="constant" ->*</TT +>*</CODE >) [<SPAN CLASS="optional" ->port <TT +>port <VAR CLASS="replaceable" -><I ->ip_port</I -></TT +>ip_port</VAR ></SPAN >] ; </SPAN >] [<SPAN CLASS="optional" -> zone-statistics <TT +> zone-statistics <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> sig-validity-interval <TT +> sig-validity-interval <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> database <TT +> database <VAR CLASS="replaceable" -><I ->string</I -></TT +>string</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> min-refresh-time <TT +> min-refresh-time <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> max-refresh-time <TT +> max-refresh-time <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> min-retry-time <TT +> min-retry-time <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> max-retry-time <TT +> max-retry-time <VAR CLASS="replaceable" -><I ->number</I -></TT +>number</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> multi-master <TT +> multi-master <VAR CLASS="replaceable" -><I ->yes_or_no</I -></TT +>yes_or_no</VAR > ; </SPAN >] [<SPAN CLASS="optional" -> key-directory <TT +> key-directory <VAR CLASS="replaceable" -><I ->path_name</I -></TT +>path_name</VAR >; </SPAN >] @@ -9564,7 +8523,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN3617" +NAME="AEN3614" >6.2.24. <B CLASS="command" >zone</B @@ -9575,16 +8534,16 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN3620" +NAME="AEN3617" >6.2.24.1. Zone Types</A ></H3 ><DIV CLASS="informaltable" -><A -NAME="AEN3622" -></A ><P ></P +><A +NAME="AEN3619" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -9592,19 +8551,13 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="87" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->master</TT +>master</VAR ></P ></TD ><TD -WIDTH="405" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The server has a master copy of the data for the zone and will be able to provide authoritative answers for @@ -9613,19 +8566,13 @@ it.</P ></TR ><TR ><TD -WIDTH="87" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->slave</TT +>slave</VAR ></P ></TD ><TD -WIDTH="405" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >A slave zone is a replica of a master zone. The <B @@ -9645,9 +8592,9 @@ 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 <TT +a slave server for the zone <VAR CLASS="literal" ->example.com</TT +>example.com</VAR > might place the zone contents into a file called <TT @@ -9664,26 +8611,20 @@ a single directory.)</P ></TR ><TR ><TD -WIDTH="87" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->stub</TT +>stub</VAR ></P ></TD ><TD -WIDTH="405" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >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 <SPAN +they are a feature specific to the <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > implementation. </P > @@ -9697,20 +8638,20 @@ CLASS="filename" >. This usage is not recommended for new configurations, and BIND 9 supports it only in a limited way. -In <SPAN +In <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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. <SPAN +only in the master server for the parent zone. <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 never mixes together zone data from different zones in this -way. Therefore, if a <SPAN +way. Therefore, if a <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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 @@ -9722,9 +8663,9 @@ configured.</P 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 -<TT +<VAR CLASS="literal" ->10.in-addr.arpa</TT +>10.in-addr.arpa</VAR > to use a set of internal name servers as the authoritative servers for that domain.</P @@ -9733,19 +8674,13 @@ servers for that domain.</P ></TR ><TR ><TD -WIDTH="87" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->forward</TT +>forward</VAR ></P ></TD ><TD -WIDTH="405" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >A "forward zone" is a way to configure forwarding on a per-domain basis. A <B @@ -9788,19 +8723,13 @@ servers as set globally) you need to re-specify the global forwarders.</P ></TR ><TR ><TD -WIDTH="87" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->hint</TT +>hint</VAR ></P ></TD ><TD -WIDTH="405" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The initial set of root name servers is specified using a "hint zone". When the server starts up, it uses @@ -9812,19 +8741,13 @@ Classes other than IN have no built-in defaults hints.</P ></TR ><TR ><TD -WIDTH="87" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->delegation-only</TT +>delegation-only</VAR ></P ></TD ><TD -WIDTH="405" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >This is used to enforce the delegation only status of infrastructure zones (e.g. COM, NET, ORG). Any answer that @@ -9833,9 +8756,9 @@ section will be treated as NXDOMAIN. This does not apply to the zone apex. This SHOULD NOT be applied to leaf zones.</P > <P -><TT +><VAR CLASS="varname" ->delegation-only</TT +>delegation-only</VAR > has no effect on answers received from forwarders.</P ></TD @@ -9851,37 +8774,37 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN3685" +NAME="AEN3682" >6.2.24.2. Class</A ></H3 ><P >The zone's name may optionally be followed by a class. If -a class is not specified, class <TT +a class is not specified, class <VAR CLASS="literal" ->IN</TT -> (for <TT +>IN</VAR +> (for <VAR CLASS="varname" ->Internet</TT +>Internet</VAR >), is assumed. This is correct for the vast majority of cases.</P ><P ->The <TT +>The <VAR CLASS="literal" ->hesiod</TT +>hesiod</VAR > 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 -<TT +<VAR CLASS="literal" ->HS</TT +>HS</VAR > is a synonym for hesiod.</P ><P >Another MIT development is CHAOSnet, a LAN protocol created -in the mid-1970s. Zone data for it can be specified with the <TT +in the mid-1970s. Zone data for it can be specified with the <VAR CLASS="literal" ->CHAOS</TT +>CHAOS</VAR > class.</P ></DIV ><DIV @@ -9889,7 +8812,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN3695" +NAME="AEN3692" >6.2.24.3. Zone Options</A ></H3 ><P @@ -10003,9 +8926,9 @@ CLASS="command" >notify</B > is active for this zone. The set of machines that will receive a -<TT +<VAR CLASS="literal" ->DNS NOTIFY</TT +>DNS NOTIFY</VAR > 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 @@ -10031,13 +8954,9 @@ CLASS="command" ></DT ><DD ><P -> This option was used in BIND 8 to restrict the character set of -domain names in master files and/or DNS responses received from the -network. BIND 9 does not restrict the character set of domain names -and does not implement the <B -CLASS="command" ->check-names</B -> option. +> 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. </P ></DD ><DT @@ -10057,11 +8976,9 @@ 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.</P ><P ->The default is <TT +>The default is <KBD CLASS="userinput" -><B ->"rbt"</B -></TT +>"rbt"</KBD >, BIND 9's native in-memory red-black-tree database. This database does not take arguments.</P ><P @@ -10093,11 +9010,9 @@ CLASS="command" ><DD ><P >The flag only applies to hint and stub zones. If set -to <TT +to <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD > then the zone will also be treated as if it is also a delegation-only type zone. </P @@ -10141,14 +9056,14 @@ CLASS="command" ></DT ><DD ><P ->Was used in <SPAN +>Was used in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8 to specify the name of the transaction log (journal) file for dynamic update and IXFR. -<SPAN +<ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 ignores the option and constructs the name of the journal file by appending "<TT CLASS="filename" @@ -10163,13 +9078,13 @@ CLASS="command" ></DT ><DD ><P ->Was an undocumented option in <SPAN +>Was an undocumented option in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 8. -Ignored in <SPAN +Ignored in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9.</P ></DD ><DT @@ -10259,14 +9174,14 @@ CLASS="command" ></DT ><DD ><P ->In <SPAN +>In <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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. <SPAN +zones when they are loaded from disk. <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 does not verify signatures on load and ignores the option.</P ></DD @@ -10277,11 +9192,9 @@ CLASS="command" ></DT ><DD ><P ->If <TT +>If <KBD CLASS="userinput" -><B ->yes</B -></TT +>yes</KBD >, the server will keep statistical information for this zone, which can be dumped to the <B @@ -10506,9 +9419,9 @@ NAME="dynamic_update_policies" >6.2.24.4. Dynamic Update Policies</A ></H3 ><P -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 supports two alternative methods of granting clients the right to perform dynamic updates to a zone, configured by the <B @@ -10524,18 +9437,18 @@ CLASS="command" CLASS="command" >allow-update</B > clause works the same -way as in previous versions of <SPAN +way as in previous versions of <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM >. It grants given clients the permission to update any record of any name in the zone.</P ><P >The <B CLASS="command" >update-policy</B -> clause is new in <SPAN +> clause is new in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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 @@ -10571,28 +9484,20 @@ CLASS="command" > | <B CLASS="command" >deny</B -> ) <TT +> ) <VAR CLASS="replaceable" -><I ->identity</I -></TT -> <TT +>identity</VAR +> <VAR CLASS="replaceable" -><I ->nametype</I -></TT -> <TT +>nametype</VAR +> <VAR CLASS="replaceable" -><I ->name</I -></TT +>name</VAR > [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->types</I -></TT +>types</VAR > </SPAN >] </PRE @@ -10608,49 +9513,43 @@ the types specified in the type field.</P 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 <TT +TKEY exchange. When the <VAR CLASS="replaceable" -><I ->identity</I -></TT +>identity</VAR > field specifies a wildcard name, it is subject to DNS wildcard expansion, so the rule will apply -to multiple identities. The <TT +to multiple identities. The <VAR CLASS="replaceable" -><I ->identity</I -></TT +>identity</VAR > field must contain a fully qualified domain name.</P ><P ->The <TT +>The <VAR CLASS="replaceable" -><I ->nametype</I -></TT +>nametype</VAR > field has 4 values: -<TT +<VAR CLASS="varname" ->name</TT ->, <TT +>name</VAR +>, <VAR CLASS="varname" ->subdomain</TT +>subdomain</VAR >, -<TT +<VAR CLASS="varname" ->wildcard</TT ->, and <TT +>wildcard</VAR +>, and <VAR CLASS="varname" ->self</TT +>self</VAR >. </P ><DIV CLASS="informaltable" -><A -NAME="AEN3978" -></A ><P ></P +><A +NAME="AEN3974" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -10658,77 +9557,53 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="79" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->name</TT +>name</VAR ></P ></TD ><TD -WIDTH="353" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Exact-match semantics. This rule matches when the name being updated is identical to the contents of the -<TT +<VAR CLASS="replaceable" -><I ->name</I -></TT +>name</VAR > field.</P ></TD ></TR ><TR ><TD -WIDTH="79" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->subdomain</TT +>subdomain</VAR ></P ></TD ><TD -WIDTH="353" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >This rule matches when the name being updated is a subdomain of, or identical to, the contents of the -<TT +<VAR CLASS="replaceable" -><I ->name</I -></TT +>name</VAR > field.</P ></TD ></TR ><TR ><TD -WIDTH="79" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->wildcard</TT +>wildcard</VAR ></P ></TD ><TD -WIDTH="353" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ->The <TT +>The <VAR CLASS="replaceable" -><I ->name</I -></TT +>name</VAR > field is subject to DNS wildcard expansion, and this rule matches when the name being updated name is a valid expansion of the wildcard.</P @@ -10736,53 +9611,39 @@ being updated name is a valid expansion of the wildcard.</P ></TR ><TR ><TD -WIDTH="79" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="varname" ->self</TT +>self</VAR ></P ></TD ><TD -WIDTH="353" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >This rule matches when the name being updated -matches the contents of the <TT +matches the contents of the <VAR CLASS="replaceable" -><I ->identity</I -></TT +>identity</VAR > field. -The <TT +The <VAR CLASS="replaceable" -><I ->name</I -></TT +>name</VAR > field is ignored, but should be -the same as the <TT +the same as the <VAR CLASS="replaceable" -><I ->identity</I -></TT +>identity</VAR > field. The -<TT +<VAR CLASS="varname" ->self</TT +>self</VAR > 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 <TT +to be updated. The <VAR CLASS="replaceable" -><I ->identity</I -></TT +>identity</VAR > would be -specified as <TT +specified as <CODE CLASS="constant" ->*</TT +>*</CODE > in this case.</P ></TD ></TR @@ -10792,11 +9653,9 @@ CLASS="constant" ></P ></DIV ><P ->In all cases, the <TT +>In all cases, the <VAR CLASS="replaceable" -><I ->name</I -></TT +>name</VAR > field must specify a fully qualified domain name.</P ><P @@ -10814,7 +9673,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN4019" +NAME="AEN4015" >6.3. Zone File</A ></H1 ><DIV @@ -10835,7 +9694,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN4024" +NAME="AEN4020" >6.3.1.1. Resource Records</A ></H3 ><P @@ -10857,11 +9716,11 @@ HREF="Bv9ARM.ch06.html#rrset_ordering" >The components of a Resource Record are:</P ><DIV CLASS="informaltable" -><A -NAME="AEN4030" -></A ><P ></P +><A +NAME="AEN4026" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -10869,32 +9728,20 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="96" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >owner name</P ></TD ><TD -WIDTH="336" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >the domain name where the RR is found.</P ></TD ></TR ><TR ><TD -WIDTH="96" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >type</P ></TD ><TD -WIDTH="336" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >an encoded 16 bit value that specifies the type of the resource record.</P @@ -10902,16 +9749,10 @@ the type of the resource record.</P ></TR ><TR ><TD -WIDTH="96" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >TTL</P ></TD ><TD -WIDTH="336" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >the time to live of the RR. This field is a 32 bit integer in units of seconds, and is primarily used by @@ -10921,16 +9762,10 @@ be cached before it should be discarded.</P ></TR ><TR ><TD -WIDTH="96" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >class</P ></TD ><TD -WIDTH="336" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >an encoded 16 bit value that identifies a protocol family or instance of a protocol.</P @@ -10938,16 +9773,10 @@ a protocol family or instance of a protocol.</P ></TR ><TR ><TD -WIDTH="96" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >RDATA</P ></TD ><TD -WIDTH="336" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >the resource data. The format of the data is type (and sometimes class) specific.</P @@ -10968,11 +9797,11 @@ CLASS="emphasis" > of valid RRs:</P ><DIV CLASS="informaltable" -><A -NAME="AEN4062" -></A ><P ></P +><A +NAME="AEN4058" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -10980,16 +9809,10 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >A</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >a host address. In the IN class, this is a 32-bit IP address. Described in RFC 1035.</P @@ -10997,32 +9820,20 @@ VALIGN="MIDDLE" ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >AAAA</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >IPv6 address. Described in RFC 1886.</P ></TD ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >A6</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >IPv6 address. This can be a partial address (a suffix) and an indirection to the name where the rest of the @@ -11031,16 +9842,10 @@ address (the prefix) can be found. Experimental. Described in RFC 2874.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >AFSDB</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >location of AFS database servers. Experimental. Described in RFC 1183.</P @@ -11048,16 +9853,10 @@ Experimental. Described in RFC 1183.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >APL</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >address prefix list. Experimental. Described in RFC 3123.</P @@ -11065,16 +9864,10 @@ Described in RFC 3123.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >CERT</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >holds a digital certificate. Described in RFC 2538.</P @@ -11082,16 +9875,10 @@ Described in RFC 2538.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >CNAME</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >identifies the canonical name of an alias. Described in RFC 1035.</P @@ -11099,16 +9886,10 @@ Described in RFC 1035.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >DNAME</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Replaces the domain name specified with another name to be looked up, effectively aliasing an entire @@ -11119,32 +9900,20 @@ Described in RFC 2672.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >GPOS</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Specifies the global position. Superseded by LOC.</P ></TD ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >HINFO</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >identifies the CPU and OS used by a host. Described in RFC 1035.</P @@ -11152,16 +9921,10 @@ Described in RFC 1035.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >ISDN</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >representation of ISDN addresses. Experimental. Described in RFC 1183.</P @@ -11169,16 +9932,10 @@ Experimental. Described in RFC 1183.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >KEY</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >stores a public key associated with a DNS name. Described in RFC 2535.</P @@ -11186,16 +9943,10 @@ DNS name. Described in RFC 2535.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >KX</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >identifies a key exchanger for this DNS name. Described in RFC 2230.</P @@ -11203,16 +9954,10 @@ DNS name. Described in RFC 2230.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >LOC</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >for storing GPS info. Described in RFC 1876. Experimental.</P @@ -11220,16 +9965,10 @@ Experimental.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >MX</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >identifies a mail exchange for the domain. a 16 bit preference value (lower is better) @@ -11239,32 +9978,20 @@ Described in RFC 974, RFC 1035.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >NAPTR</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >name authority pointer. Described in RFC 2915.</P ></TD ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >NSAP</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >a network service access point. Described in RFC 1706.</P @@ -11272,16 +9999,10 @@ Described in RFC 1706.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >NS</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >the authoritative name server for the domain. Described in RFC 1035.</P @@ -11289,16 +10010,10 @@ domain. Described in RFC 1035.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >NXT</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >used in DNSSEC to securely indicate that RRs with an owner name in a certain name interval do not exist in @@ -11308,16 +10023,10 @@ Described in RFC 2535.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >PTR</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >a pointer to another part of the domain name space. Described in RFC 1035.</P @@ -11325,16 +10034,10 @@ name space. Described in RFC 1035.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >PX</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >provides mappings between RFC 822 and X.400 addresses. Described in RFC 2163.</P @@ -11342,16 +10045,10 @@ addresses. Described in RFC 2163.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >RP</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >information on persons responsible for the domain. Experimental. Described in RFC 1183.</P @@ -11359,16 +10056,10 @@ for the domain. Experimental. Described in RFC 1183.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >RT</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >route-through binding for hosts that do not have their own direct wide area network addresses. @@ -11377,16 +10068,10 @@ Experimental. Described in RFC 1183.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >SIG</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >("signature") contains data authenticated in the secure DNS. Described in RFC 2535.</P @@ -11394,16 +10079,10 @@ in the secure DNS. Described in RFC 2535.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >SOA</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >identifies the start of a zone of authority. Described in RFC 1035.</P @@ -11411,16 +10090,10 @@ Described in RFC 1035.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >SRV</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >information about well known network services (replaces WKS). Described in RFC 2782.</P @@ -11428,32 +10101,20 @@ services (replaces WKS). Described in RFC 2782.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >TXT</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >text records. Described in RFC 1035.</P ></TD ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >WKS</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >information about which well known network services, such as SMTP, that a domain supports. Historical. @@ -11462,16 +10123,10 @@ network services, such as SMTP, that a domain supports. Historical. ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >X25</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >representation of X.25 network addresses. Experimental. Described in RFC 1183.</P @@ -11493,11 +10148,11 @@ CLASS="emphasis" are currently valid in the DNS:</P ><DIV CLASS="informaltable" -><A -NAME="AEN4214" -></A ><P ></P +><A +NAME="AEN4210" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -11505,55 +10160,37 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >IN</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The Internet.</P ></TD ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >CH</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P > 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., -<TT +<VAR CLASS="literal" ->version.bind</TT +>version.bind</VAR >. </P ></TD ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >HS</P ></TD ><TD -WIDTH="348" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P > Hesiod, an information service developed by MIT's Project Athena. It is used to share information @@ -11596,7 +10233,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN4238" +NAME="AEN4234" >6.3.1.2. Textual expression of RRs</A ></H3 ><P @@ -11625,11 +10262,11 @@ knowledge of the typical representation for the data.</P >For example, we might show the RRs carried in a message as:</P ><DIV CLASS="informaltable" -><A -NAME="AEN4245" -></A ><P ></P +><A +NAME="AEN4241" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -11637,184 +10274,130 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="133" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->ISI.EDU.</TT +>ISI.EDU.</VAR ></P ></TD ><TD -WIDTH="98" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->MX</TT +>MX</VAR ></P ></TD ><TD -WIDTH="202" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->10 VENERA.ISI.EDU.</TT +>10 VENERA.ISI.EDU.</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="133" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="98" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->MX</TT +>MX</VAR ></P ></TD ><TD -WIDTH="202" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->10 VAXA.ISI.EDU</TT +>10 VAXA.ISI.EDU</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="133" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->VENERA.ISI.EDU</TT +>VENERA.ISI.EDU</VAR ></P ></TD ><TD -WIDTH="98" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->A</TT +>A</VAR ></P ></TD ><TD -WIDTH="202" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->128.9.0.32</TT +>128.9.0.32</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="133" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="98" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->A</TT +>A</VAR ></P ></TD ><TD -WIDTH="202" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->10.1.0.52</TT +>10.1.0.52</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="133" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->VAXA.ISI.EDU</TT +>VAXA.ISI.EDU</VAR ></P ></TD ><TD -WIDTH="98" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->A</TT +>A</VAR ></P ></TD ><TD -WIDTH="202" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->10.2.0.27</TT +>10.2.0.27</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="133" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="98" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->A</TT +>A</VAR ></P ></TD ><TD -WIDTH="202" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->128.9.0.33</TT +>128.9.0.33</VAR ></P ></TD ></TR @@ -11834,11 +10417,11 @@ domain names.</P >Similarly we might see:</P ><DIV CLASS="informaltable" -><A -NAME="AEN4311" -></A ><P ></P +><A +NAME="AEN4307" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -11846,65 +10429,47 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="143" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->XX.LCS.MIT.EDU. IN</TT +>XX.LCS.MIT.EDU. IN</VAR ></P ></TD ><TD -WIDTH="102" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->A</TT +>A</VAR ></P ></TD ><TD -WIDTH="198" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->10.0.0.44</TT +>10.0.0.44</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="143" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->CH</TT +>CH</VAR ></P ></TD ><TD -WIDTH="102" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->A</TT +>A</VAR ></P ></TD ><TD -WIDTH="198" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->MIT.EDU. 2420</TT +>MIT.EDU. 2420</VAR ></P ></TD ></TR @@ -11914,9 +10479,9 @@ CLASS="literal" ></P ></DIV ><P ->This example shows two addresses for <TT +>This example shows two addresses for <VAR CLASS="literal" ->XX.LCS.MIT.EDU</TT +>XX.LCS.MIT.EDU</VAR >, each of a different class.</P ></DIV @@ -11926,7 +10491,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4339" +NAME="AEN4335" >6.3.2. Discussion of MX Records</A ></H2 ><P @@ -11961,11 +10526,11 @@ the mail will be delivered to the server specified in the MX record pointed to by the CNAME.</P ><DIV CLASS="informaltable" -><A -NAME="AEN4345" -></A ><P ></P +><A +NAME="AEN4341" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -11973,248 +10538,173 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="164" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->example.com.</TT +>example.com.</VAR ></P ></TD ><TD -WIDTH="43" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->IN</TT +>IN</VAR ></P ></TD ><TD -WIDTH="43" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->MX</TT +>MX</VAR ></P ></TD ><TD -WIDTH="94" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->10</TT +>10</VAR ></P ></TD ><TD -WIDTH="149" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->mail.example.com.</TT +>mail.example.com.</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="164" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="43" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->IN</TT +>IN</VAR ></P ></TD ><TD -WIDTH="43" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->MX</TT +>MX</VAR ></P ></TD ><TD -WIDTH="94" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->10</TT +>10</VAR ></P ></TD ><TD -WIDTH="149" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->mail2.example.com.</TT +>mail2.example.com.</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="164" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="43" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->IN</TT +>IN</VAR ></P ></TD ><TD -WIDTH="43" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->MX</TT +>MX</VAR ></P ></TD ><TD -WIDTH="94" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->20</TT +>20</VAR ></P ></TD ><TD -WIDTH="149" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->mail.backup.org.</TT +>mail.backup.org.</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="164" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->mail.example.com.</TT +>mail.example.com.</VAR ></P ></TD ><TD -WIDTH="43" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->IN</TT +>IN</VAR ></P ></TD ><TD -WIDTH="43" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->A</TT +>A</VAR ></P ></TD ><TD -WIDTH="94" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->10.0.0.1</TT +>10.0.0.1</VAR ></P ></TD ><TD -WIDTH="149" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ></TR ><TR ><TD -WIDTH="164" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->mail2.example.com.</TT +>mail2.example.com.</VAR ></P ></TD ><TD -WIDTH="43" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->IN</TT +>IN</VAR ></P ></TD ><TD -WIDTH="43" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->A</TT +>A</VAR ></P ></TD ><TD -WIDTH="94" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->10.0.0.2</TT +>10.0.0.2</VAR ></P ></TD ><TD -WIDTH="149" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD @@ -12227,17 +10717,17 @@ VALIGN="MIDDLE" ><P >For example:</P ><P ->Mail delivery will be attempted to <TT +>Mail delivery will be attempted to <VAR CLASS="literal" ->mail.example.com</TT +>mail.example.com</VAR > and -<TT +<VAR CLASS="literal" ->mail2.example.com</TT +>mail2.example.com</VAR > (in -any order), and if neither of those succeed, delivery to <TT +any order), and if neither of those succeed, delivery to <VAR CLASS="literal" ->mail.backup.org</TT +>mail.backup.org</VAR > will be attempted.</P ></DIV @@ -12257,11 +10747,11 @@ should be discarded. The following three types of TTL are currently used in a zone file.</P ><DIV CLASS="informaltable" -><A -NAME="AEN4437" -></A ><P ></P +><A +NAME="AEN4433" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -12269,16 +10759,10 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >SOA</P ></TD ><TD -WIDTH="420" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The last field in the SOA is the negative caching TTL. This controls how long other servers will cache no-such-domain @@ -12290,16 +10774,10 @@ negative caching is 3 hours (3h).</P ></TR ><TR ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >$TTL</P ></TD ><TD -WIDTH="420" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >The $TTL directive at the top of the zone file (before the SOA) gives a default TTL for every RR without @@ -12308,16 +10786,10 @@ a specific TTL set.</P ></TR ><TR ><TD -WIDTH="72" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >RR TTLs</P ></TD ><TD -WIDTH="420" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Each RR can have a TTL as the second field in the RR, which will control how long other servers can cache @@ -12331,9 +10803,9 @@ the it.</P ></DIV ><P >All of these TTLs default to units of seconds, though units -can be explicitly specified, for example, <TT +can be explicitly specified, for example, <VAR CLASS="literal" ->1h30m</TT +>1h30m</VAR >. </P ></DIV ><DIV @@ -12341,7 +10813,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4460" +NAME="AEN4456" >6.3.4. Inverse Mapping in IPv4</A ></H2 ><P @@ -12367,11 +10839,11 @@ CLASS="optional" >] domain:</P ><DIV CLASS="informaltable" -><A -NAME="AEN4465" -></A ><P ></P +><A +NAME="AEN4461" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -12379,45 +10851,33 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="108" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->$ORIGIN</TT +>$ORIGIN</VAR ></P ></TD ><TD -WIDTH="384" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->2.1.10.in-addr.arpa</TT +>2.1.10.in-addr.arpa</VAR ></P ></TD ></TR ><TR ><TD -WIDTH="108" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->3</TT +>3</VAR ></P ></TD ><TD -WIDTH="384" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P -><TT +><VAR CLASS="literal" ->IN PTR foo.example.com.</TT +>IN PTR foo.example.com.</VAR ></P ></TD ></TR @@ -12448,7 +10908,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4487" +NAME="AEN4483" >6.3.5. Other Zone File Directives</A ></H2 ><P @@ -12473,7 +10933,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN4494" +NAME="AEN4490" >6.3.5.1. The <B CLASS="command" >$ORIGIN</B @@ -12484,18 +10944,14 @@ CLASS="command" CLASS="command" >$ORIGIN </B -><TT +><VAR CLASS="replaceable" -><I ->domain-name</I -></TT +>domain-name</VAR > [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->comment</I -></TT +>comment</VAR ></SPAN >]</P ><P @@ -12507,9 +10963,9 @@ be appended to any unqualified records. When a zone is first read in there is an implicit <B CLASS="command" >$ORIGIN</B -> <<TT +> <<VAR CLASS="varname" ->zone-name</TT +>zone-name</VAR >><B CLASS="command" >.</B @@ -12524,18 +10980,18 @@ CLASS="command" > argument if it is not absolute.</P ><PRE CLASS="programlisting" -><TT +><VAR CLASS="literal" >$ORIGIN example.com. -WWW CNAME MAIN-SERVER</TT +WWW CNAME MAIN-SERVER</VAR ></PRE ><P >is equivalent to</P ><PRE CLASS="programlisting" -><TT +><VAR CLASS="literal" ->WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</TT +>WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</VAR ></PRE ></DIV ><DIV @@ -12543,7 +10999,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN4514" +NAME="AEN4510" >6.3.5.2. The <B CLASS="command" >$INCLUDE</B @@ -12554,26 +11010,20 @@ CLASS="command" CLASS="command" >$INCLUDE</B > -<TT +<VAR CLASS="replaceable" -><I ->filename</I -></TT +>filename</VAR > [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->origin</I -></TT +>origin</VAR > </SPAN >] [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->comment</I -></TT +>comment</VAR > </SPAN >]</P ><P @@ -12625,7 +11075,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN4534" +NAME="AEN4530" >6.3.5.3. The <B CLASS="command" >$TTL</B @@ -12636,18 +11086,14 @@ CLASS="command" CLASS="command" >$TTL</B > -<TT +<VAR CLASS="replaceable" -><I ->default-ttl</I -></TT +>default-ttl</VAR > [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->comment</I -></TT +>comment</VAR > </SPAN >]</P ><P @@ -12665,10 +11111,10 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4545" ->6.3.6. <SPAN +NAME="AEN4541" +>6.3.6. <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > Master File Extension: the <B CLASS="command" >$GENERATE</B @@ -12678,49 +11124,35 @@ CLASS="command" >Syntax: <B CLASS="command" >$GENERATE</B -> <TT +> <VAR CLASS="replaceable" -><I ->range</I -></TT -> <TT +>range</VAR +> <VAR CLASS="replaceable" -><I ->lhs</I -></TT +>lhs</VAR > [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->ttl</I -></TT +>ttl</VAR ></SPAN >] [<SPAN CLASS="optional" -><TT +><VAR CLASS="replaceable" -><I ->class</I -></TT +>class</VAR ></SPAN ->] <TT +>] <VAR CLASS="replaceable" -><I ->type</I -></TT -> <TT +>type</VAR +> <VAR CLASS="replaceable" -><I ->rhs</I -></TT +>rhs</VAR > [<SPAN CLASS="optional" -> <TT +> <VAR CLASS="replaceable" -><I ->comment</I -></TT +>comment</VAR > </SPAN >]</P ><P @@ -12737,17 +11169,17 @@ sub /24 reverse delegations described in RFC 2317: Classless IN-ADDR.ARPA delegation.</P ><PRE CLASS="programlisting" -><TT +><VAR CLASS="literal" >$ORIGIN 0.0.192.IN-ADDR.ARPA. $GENERATE 1-2 0 NS SERVER$.EXAMPLE. -$GENERATE 1-127 $ CNAME $.0</TT +$GENERATE 1-127 $ CNAME $.0</VAR ></PRE ><P >is equivalent to</P ><PRE CLASS="programlisting" -><TT +><VAR CLASS="literal" >0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE. 0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE. @@ -12755,15 +11187,15 @@ CLASS="literal" 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. -</TT +</VAR ></PRE ><DIV CLASS="informaltable" -><A -NAME="AEN4569" -></A ><P ></P +><A +NAME="AEN4565" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -12771,9 +11203,6 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -12781,9 +11210,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="408" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >This can be one of two forms: start-stop or start-stop/step. If the first form is used then step is set to @@ -12792,9 +11218,6 @@ or start-stop/step. If the first form is used then step is set to ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -12802,9 +11225,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="408" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -12889,9 +11309,6 @@ recognized a indicating a literal $ in the output.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -12899,9 +11316,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="408" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -12923,9 +11337,6 @@ CLASS="command" ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -12933,9 +11344,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="408" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -12957,9 +11365,6 @@ CLASS="command" ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -12967,9 +11372,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="408" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >At present the only supported types are PTR, CNAME, DNAME, A, AAAA and NS.</P @@ -12977,9 +11379,6 @@ PTR, CNAME, DNAME, A, AAAA and NS.</P ></TR ><TR ><TD -WIDTH="84" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><B CLASS="command" @@ -12987,9 +11386,6 @@ CLASS="command" ></P ></TD ><TD -WIDTH="408" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >rhs is a domain name. It is processed similarly to lhs.</P @@ -13004,9 +11400,9 @@ similarly to lhs.</P >The <B CLASS="command" >$GENERATE</B -> directive is a <SPAN +> directive is a <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > extension and not part of the standard zone file format.</P ><P @@ -13058,9 +11454,9 @@ ACCESSKEY="N" WIDTH="33%" ALIGN="left" VALIGN="top" ->The <SPAN +>The <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 Lightweight Resolver</TD ><TD WIDTH="34%" @@ -13071,9 +11467,9 @@ VALIGN="top" WIDTH="33%" ALIGN="right" VALIGN="top" -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 Security Considerations</TD ></TR ></TABLE diff --git a/dist/bind/doc/arm/Bv9ARM.ch07.html b/dist/bind/doc/arm/Bv9ARM.ch07.html index 68312509f66..a7c47077387 100644 --- a/dist/bind/doc/arm/Bv9ARM.ch07.html +++ b/dist/bind/doc/arm/Bv9ARM.ch07.html @@ -1,11 +1,11 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >BIND 9 Security Considerations</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"><LINK +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REL="HOME" TITLE="BIND 9 Administrator Reference Manual" HREF="Bv9ARM.html"><LINK @@ -70,11 +70,11 @@ CLASS="chapter" ><H1 ><A NAME="ch07" ->Chapter 7. <SPAN +></A +>Chapter 7. <ACRONYM CLASS="acronym" ->BIND</SPAN -> 9 Security Considerations</A -></H1 +>BIND</ACRONYM +> 9 Security Considerations</H1 ><DIV CLASS="TOC" ><DL @@ -89,7 +89,7 @@ HREF="Bv9ARM.ch07.html#Access_Control_Lists" ></DT ><DT >7.2. <A -HREF="Bv9ARM.ch07.html#AEN4662" +HREF="Bv9ARM.ch07.html#AEN4658" ><B CLASS="command" >chroot</B @@ -197,7 +197,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN4662" +NAME="AEN4658" >7.2. <B CLASS="command" >chroot</B @@ -208,9 +208,9 @@ CLASS="command" UNIX servers)</A ></H1 ><P ->On UNIX servers, it is possible to run <SPAN +>On UNIX servers, it is possible to run <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > in a <SPAN CLASS="emphasis" ><I @@ -221,37 +221,35 @@ CLASS="emphasis" (<B CLASS="command" >chroot()</B ->) by specifying the "<TT +>) by specifying the "<VAR CLASS="option" ->-t</TT +>-t</VAR >" -option. This can help improve system security by placing <SPAN +option. This can help improve system security by placing <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > in a "sandbox", which will limit the damage done if a server is compromised.</P ><P ->Another useful feature in the UNIX version of <SPAN +>Another useful feature in the UNIX version of <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > is the -ability to run the daemon as an unprivileged user ( <TT +ability to run the daemon as an unprivileged user ( <VAR CLASS="option" ->-u</TT -> <TT +>-u</VAR +> <VAR CLASS="replaceable" -><I ->user</I -></TT +>user</VAR > ). We suggest running as an unprivileged user when using the <B CLASS="command" >chroot</B > feature.</P ><P ->Here is an example command line to load <SPAN +>Here is an example command line to load <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > in a <B CLASS="command" >chroot()</B @@ -268,18 +266,16 @@ CLASS="command" > to user 202:</P ><P -><TT +><KBD CLASS="userinput" -><B ->/usr/local/bin/named -u 202 -t /var/named</B -></TT +>/usr/local/bin/named -u 202 -t /var/named</KBD ></P ><DIV CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4685" +NAME="AEN4681" >7.2.1. The <B CLASS="command" >chroot</B @@ -296,13 +292,13 @@ CLASS="filename" >/var/named</TT >), you will need to set up an environment that includes everything -<SPAN +<ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > needs to run. -From <SPAN +From <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM >'s point of view, <TT CLASS="filename" >/var/named</TT @@ -355,7 +351,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4703" +NAME="AEN4699" >7.2.2. Using the <B CLASS="command" >setuid</B @@ -375,9 +371,9 @@ CLASS="command" >chown</B > utility (to set the user id and/or group id) on files -to which you want <SPAN +to which you want <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > to write. Note that if the <B CLASS="command" @@ -398,9 +394,9 @@ NAME="dynamic_update_security" ><P >Access to the dynamic update facility should be strictly limited. In earlier versions of -<SPAN +<ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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 <B @@ -482,9 +478,9 @@ ACCESSKEY="N" WIDTH="33%" ALIGN="left" VALIGN="top" -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 Configuration Reference</TD ><TD WIDTH="34%" diff --git a/dist/bind/doc/arm/Bv9ARM.ch08.html b/dist/bind/doc/arm/Bv9ARM.ch08.html index 72e1b2a8139..fe173a8f47a 100644 --- a/dist/bind/doc/arm/Bv9ARM.ch08.html +++ b/dist/bind/doc/arm/Bv9ARM.ch08.html @@ -1,11 +1,11 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >Troubleshooting</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"><LINK +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REL="HOME" TITLE="BIND 9 Administrator Reference Manual" HREF="Bv9ARM.html"><LINK @@ -70,8 +70,8 @@ CLASS="chapter" ><H1 ><A NAME="ch08" ->Chapter 8. Troubleshooting</A -></H1 +></A +>Chapter 8. Troubleshooting</H1 ><DIV CLASS="TOC" ><DL @@ -81,17 +81,17 @@ CLASS="TOC" ></DT ><DT >8.1. <A -HREF="Bv9ARM.ch08.html#AEN4724" +HREF="Bv9ARM.ch08.html#AEN4720" >Common Problems</A ></DT ><DT >8.2. <A -HREF="Bv9ARM.ch08.html#AEN4729" +HREF="Bv9ARM.ch08.html#AEN4725" >Incrementing and Changing the Serial Number</A ></DT ><DT >8.3. <A -HREF="Bv9ARM.ch08.html#AEN4734" +HREF="Bv9ARM.ch08.html#AEN4730" >Where Can I Get Help?</A ></DT ></DL @@ -101,7 +101,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN4724" +NAME="AEN4720" >8.1. Common Problems</A ></H1 ><DIV @@ -109,7 +109,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4726" +NAME="AEN4722" >8.1.1. It's not working; how can I figure out what's wrong?</A ></H2 ><P @@ -125,7 +125,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN4729" +NAME="AEN4725" >8.2. Incrementing and Changing the Serial Number</A ></H1 ><P @@ -154,39 +154,39 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN4734" +NAME="AEN4730" >8.3. Where Can I Get Help?</A ></H1 ><P ->The Internet Software Consortium (<SPAN +>The Internet Software Consortium (<ACRONYM CLASS="acronym" ->ISC</SPAN +>ISC</ACRONYM >) offers a wide range - of support and service agreements for <SPAN + of support and service agreements for <ACRONYM CLASS="acronym" ->BIND</SPAN -> and <SPAN +>BIND</ACRONYM +> and <ACRONYM CLASS="acronym" ->DHCP</SPAN +>DHCP</ACRONYM > servers. Four levels of premium support are available and each level includes - support for all <SPAN + support for all <ACRONYM CLASS="acronym" ->ISC</SPAN +>ISC</ACRONYM > programs, significant discounts on products and training, and a recognized priority on bug fixes and - non-funded feature requests. In addition, <SPAN + non-funded feature requests. In addition, <ACRONYM CLASS="acronym" ->ISC</SPAN +>ISC</ACRONYM > offers a standard support agreement package which includes services ranging from bug fix announcements to remote support. It also includes training in - <SPAN + <ACRONYM CLASS="acronym" ->BIND</SPAN -> and <SPAN +>BIND</ACRONYM +> and <ACRONYM CLASS="acronym" ->DHCP</SPAN +>DHCP</ACRONYM >.</P ><P >To discuss arrangements for support, contact @@ -195,9 +195,9 @@ HREF="mailto:info@isc.org" TARGET="_top" >info@isc.org</A > or visit the - <SPAN + <ACRONYM CLASS="acronym" ->ISC</SPAN +>ISC</ACRONYM > web page at <A HREF="http://www.isc.org/services/support/" TARGET="_top" @@ -250,9 +250,9 @@ ACCESSKEY="N" WIDTH="33%" ALIGN="left" VALIGN="top" -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 Security Considerations</TD ><TD WIDTH="34%" diff --git a/dist/bind/doc/arm/Bv9ARM.ch09.html b/dist/bind/doc/arm/Bv9ARM.ch09.html index 0de54ed6026..130257c2411 100644 --- a/dist/bind/doc/arm/Bv9ARM.ch09.html +++ b/dist/bind/doc/arm/Bv9ARM.ch09.html @@ -1,11 +1,11 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >Appendices</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"><LINK +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REL="HOME" TITLE="BIND 9 Administrator Reference Manual" HREF="Bv9ARM.html"><LINK @@ -63,8 +63,8 @@ CLASS="appendix" ><H1 ><A NAME="ch09" ->Appendix A. Appendices</A -></H1 +></A +>Appendix A. Appendices</H1 ><DIV CLASS="TOC" ><DL @@ -74,15 +74,15 @@ CLASS="TOC" ></DT ><DT >A.1. <A -HREF="Bv9ARM.ch09.html#AEN4750" +HREF="Bv9ARM.ch09.html#AEN4746" >Acknowledgments</A ></DT ><DT >A.2. <A HREF="Bv9ARM.ch09.html#historical_dns_information" ->General <SPAN +>General <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Reference Information</A ></DT ><DT @@ -97,7 +97,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN4750" +NAME="AEN4746" >A.1. Acknowledgments</A ></H1 ><DIV @@ -105,13 +105,13 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4752" ->A.1.1. A Brief History of the <SPAN +NAME="AEN4748" +>A.1.1. A Brief History of the <ACRONYM CLASS="acronym" ->DNS</SPAN -> and <SPAN +>DNS</ACRONYM +> and <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM ></A ></H2 ><P @@ -126,9 +126,9 @@ CLASS="acronym" 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 <SPAN + became the standards upon which all <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > implementations are built. </P @@ -137,80 +137,80 @@ CLASS="acronym" 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 <SPAN +Center (SRI-NIC). A <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > server for Unix machines, the Berkeley Internet -Name Domain (<SPAN +Name Domain (<ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM >) 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 <SPAN +(DARPA). Versions of <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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 <SPAN +Painter, David Riggle and Songnian Zhou made up the initial <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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 <SPAN +employee on loan to the CSRG, worked on <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > for 2 years, from 1985 -to 1987. Many other people also contributed to <SPAN +to 1987. Many other people also contributed to <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > development during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, -Mike Muuss, Jim Bloom and Mike Schwartz. <SPAN +Mike Muuss, Jim Bloom and Mike Schwartz. <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > maintenance was subsequently handled by Mike Karels and O. Kure.</P ><P -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > versions 4.9 and 4.9.1 were released by Digital Equipment Corporation (now Compaq Computer Corporation). Paul Vixie, then -a DEC employee, became <SPAN +a DEC employee, became <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM >'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.</P ><P -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > Version 4.9.2 was sponsored by Vixie Enterprises. Paul -Vixie became <SPAN +Vixie became <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM >'s principal architect/programmer.</P ><P -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 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 <SPAN +Paul Vixie released the first production-ready version of <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > version 8 in May 1997.</P ><P -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > development work is made possible today by the sponsorship of several corporations, and by the tireless work efforts of numerous individuals.</P @@ -222,9 +222,9 @@ CLASS="sect1" CLASS="sect1" ><A NAME="historical_dns_information" ->A.2. General <SPAN +>A.2. General <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Reference Information</A ></H1 ><DIV @@ -237,9 +237,9 @@ NAME="ipv6addresses" ></H2 ><P >IPv6 addresses are 128-bit identifiers for interfaces and -sets of interfaces which were introduced in the <SPAN +sets of interfaces which were introduced in the <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > to facilitate scalable Internet routing. There are three types of addresses: <SPAN CLASS="emphasis" @@ -268,11 +268,11 @@ Unicast address scheme. For more information, see RFC 2374.</P >The aggregatable global Unicast address format is as follows:</P ><DIV CLASS="informaltable" -><A -NAME="AEN4788" -></A ><P ></P +><A +NAME="AEN4784" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -280,88 +280,52 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="46" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >3</P ></TD ><TD -WIDTH="48" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >13</P ></TD ><TD -WIDTH="50" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >8</P ></TD ><TD -WIDTH="70" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >24</P ></TD ><TD -WIDTH="129" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >16</P ></TD ><TD -WIDTH="243" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >64 bits</P ></TD ></TR ><TR ><TD -WIDTH="46" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >FP</P ></TD ><TD -WIDTH="48" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >TLA ID</P ></TD ><TD -WIDTH="50" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >RES</P ></TD ><TD -WIDTH="70" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >NLA ID</P ></TD ><TD -WIDTH="129" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >SLA ID</P ></TD ><TD -WIDTH="243" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Interface ID</P ></TD @@ -369,111 +333,67 @@ VALIGN="MIDDLE" ><TR ><TD COLSPAN="4" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><------ Public Topology ------></P ></TD ><TD -WIDTH="129" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="243" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ></TR ><TR ><TD -WIDTH="46" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="48" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="50" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="70" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="129" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><-Site Topology-></P ></TD ><TD -WIDTH="243" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ></TR ><TR ><TD -WIDTH="46" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="48" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="50" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="70" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="129" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ></P ></TD ><TD -WIDTH="243" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P ><------ Interface Identifier ------></P ></TD @@ -487,11 +407,11 @@ VALIGN="MIDDLE" >Where <DIV CLASS="informaltable" -><A -NAME="AEN4857" -></A ><P ></P +><A +NAME="AEN4853" +></A ><TABLE CELLPADDING="3" BORDER="1" @@ -499,138 +419,84 @@ CLASS="CALSTABLE" ><TBODY ><TR ><TD -WIDTH="132" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >FP</P ></TD ><TD -WIDTH="24" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >=</P ></TD ><TD -WIDTH="336" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Format Prefix (001)</P ></TD ></TR ><TR ><TD -WIDTH="132" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >TLA ID</P ></TD ><TD -WIDTH="24" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >=</P ></TD ><TD -WIDTH="336" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Top-Level Aggregation Identifier</P ></TD ></TR ><TR ><TD -WIDTH="132" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >RES</P ></TD ><TD -WIDTH="24" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >=</P ></TD ><TD -WIDTH="336" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Reserved for future use</P ></TD ></TR ><TR ><TD -WIDTH="132" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >NLA ID</P ></TD ><TD -WIDTH="24" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >=</P ></TD ><TD -WIDTH="336" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Next-Level Aggregation Identifier</P ></TD ></TR ><TR ><TD -WIDTH="132" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >SLA ID</P ></TD ><TD -WIDTH="24" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >=</P ></TD ><TD -WIDTH="336" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Site-Level Aggregation Identifier</P ></TD ></TR ><TR ><TD -WIDTH="132" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >INTERFACE ID</P ></TD ><TD -WIDTH="24" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >=</P ></TD ><TD -WIDTH="336" -ALIGN="LEFT" -VALIGN="MIDDLE" ><P >Interface Identifier</P ></TD @@ -688,7 +554,7 @@ of a block may be omitted, for example:</P ><P ><B CLASS="command" ->2001:4f8:201:9:a00:20ff:fe81:2b32</B +>2001:db8:201:9:a00:20ff:fe81:2b32</B ></P ><P >IPv6 address specifications are likely to contain long strings @@ -715,9 +581,9 @@ NAME="rfcs" ></H2 ><P >Specification documents for the Internet protocol suite, including -the <SPAN +the <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM >, 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 @@ -725,17 +591,13 @@ Steering Group (IESG). RFCs can be obtained online via FTP at <A HREF="ftp://www.isi.edu/in-notes/" TARGET="_top" ->ftp://www.isi.edu/in-notes/RFC<TT +>ftp://www.isi.edu/in-notes/RFC<VAR CLASS="replaceable" -><I ->xxx</I -></TT +>xxx</VAR >.txt</A -> (where <TT +> (where <VAR CLASS="replaceable" -><I ->xxx</I -></TT +>xxx</VAR > is the number of the RFC). RFCs are also available via the Web at <A @@ -746,19 +608,19 @@ TARGET="_top" </P ><H3 ><A -NAME="AEN4925" +NAME="AEN4921" >Bibliography</A ></H3 ><H2 CLASS="bibliodiv" ><A -NAME="AEN4926" +NAME="AEN4922" >Standards</A ></H2 ><DIV CLASS="biblioentry" ><A -NAME="AEN4928" +NAME="AEN4924" ></A ><P >[RFC974] <SPAN @@ -769,13 +631,13 @@ CLASS="AUTHOR" >, January 1986.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN4935" +NAME="AEN4931" ></A ><P >[RFC1034] <SPAN @@ -786,13 +648,13 @@ CLASS="AUTHOR" >, November 1987.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN4942" +NAME="AEN4938" ></A ><P >[RFC1035] <SPAN @@ -804,7 +666,7 @@ Specification</I >, November 1987.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><H2 @@ -816,67 +678,67 @@ NAME="proposed_standards" ><DIV CLASS="biblioentry" ><A -NAME="AEN4951" +NAME="AEN4947" ></A ><P >[RFC2181] <SPAN CLASS="AUTHOR" >R., R. Bush Elz</SPAN >, <I ->Clarifications to the <SPAN +>Clarifications to the <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Specification</I >, July 1997.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN4959" +NAME="AEN4955" ></A ><P >[RFC2308] <SPAN CLASS="AUTHOR" >M. Andrews</SPAN >, <I ->Negative Caching of <SPAN +>Negative Caching of <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Queries</I >, March 1998.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN4967" +NAME="AEN4963" ></A ><P >[RFC1995] <SPAN CLASS="AUTHOR" >M. Ohta</SPAN >, <I ->Incremental Zone Transfer in <SPAN +>Incremental Zone Transfer in <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM ></I >, August 1996.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN4975" +NAME="AEN4971" ></A ><P >[RFC1996] <SPAN @@ -887,13 +749,13 @@ CLASS="AUTHOR" >, August 1996.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN4982" +NAME="AEN4978" ></A ><P >[RFC2136] <SPAN @@ -913,13 +775,13 @@ CLASS="AUTHOR" >, April 1997.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN4999" +NAME="AEN4995" ></A ><P >[RFC2845] <SPAN @@ -935,26 +797,26 @@ CLASS="AUTHOR" CLASS="AUTHOR" >and B. Wellington</SPAN >, <I ->Secret Key Transaction Authentication for <SPAN +>Secret Key Transaction Authentication for <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > (TSIG)</I >, May 2000.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><H2 CLASS="bibliodiv" ><A -NAME="AEN5018" +NAME="AEN5014" >Proposed Standards Still Under Development</A ></H2 ><DIV CLASS="biblioentry" ><A -NAME="AEN5023" +NAME="AEN5019" ></A ><P >[RFC1886] <SPAN @@ -964,20 +826,20 @@ CLASS="AUTHOR" CLASS="AUTHOR" >and C. Huitema</SPAN >, <I -><SPAN +><ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Extensions to support IP version 6</I >, December 1995.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5035" +NAME="AEN5031" ></A ><P >[RFC2065] <SPAN @@ -991,13 +853,13 @@ CLASS="AUTHOR" >, January 1997.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5047" +NAME="AEN5043" ></A ><P >[RFC2137] <SPAN @@ -1008,42 +870,42 @@ CLASS="AUTHOR" >, April 1997.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><H2 CLASS="bibliodiv" ><A -NAME="AEN5055" ->Other Important RFCs About <SPAN +NAME="AEN5051" +>Other Important RFCs About <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Implementation</A ></H2 ><DIV CLASS="biblioentry" ><A -NAME="AEN5058" +NAME="AEN5054" ></A ><P >[RFC1535] <SPAN CLASS="AUTHOR" >E. Gavron</SPAN >, <I ->A Security Problem and Proposed Correction With Widely Deployed <SPAN +>A Security Problem and Proposed Correction With Widely Deployed <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Software.</I >, October 1993.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5066" +NAME="AEN5062" ></A ><P >[RFC1536] <SPAN @@ -1062,20 +924,20 @@ CLASS="AUTHOR" CLASS="AUTHOR" >and S. Miller</SPAN >, <I ->Common <SPAN +>Common <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Implementation Errors and Suggested Fixes</I >, October 1993.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5087" +NAME="AEN5083" ></A ><P >[RFC1982] <SPAN @@ -1089,19 +951,19 @@ CLASS="AUTHOR" >, August 1996.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><H2 CLASS="bibliodiv" ><A -NAME="AEN5098" +NAME="AEN5094" >Resource Record Types</A ></H2 ><DIV CLASS="biblioentry" ><A -NAME="AEN5100" +NAME="AEN5096" ></A ><P >[RFC1183] <SPAN @@ -1117,20 +979,20 @@ CLASS="AUTHOR" CLASS="AUTHOR" >and P. Mockapetris</SPAN >, <I ->New <SPAN +>New <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > RR Definitions</I >, October 1990.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5118" +NAME="AEN5114" ></A ><P >[RFC1706] <SPAN @@ -1140,20 +1002,20 @@ CLASS="AUTHOR" CLASS="AUTHOR" >and R. Colella</SPAN >, <I -><SPAN +><ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > NSAP Resource Records</I >, October 1994.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5130" +NAME="AEN5126" ></A ><P >[RFC2168] <SPAN @@ -1168,13 +1030,13 @@ the Domain Name System</I >, June 1997.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5141" +NAME="AEN5137" ></A ><P >[RFC1876] <SPAN @@ -1195,13 +1057,13 @@ Name System</I >, January 1996.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5158" +NAME="AEN5154" ></A ><P >[RFC2052] <SPAN @@ -1211,91 +1073,91 @@ CLASS="AUTHOR" CLASS="AUTHOR" >and P. Vixie</SPAN >, <I ->A <SPAN +>A <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > RR for Specifying the Location of Services.</I >, October 1996.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5170" +NAME="AEN5166" ></A ><P >[RFC2163] <SPAN CLASS="AUTHOR" >A. Allocchio</SPAN >, <I ->Using the Internet <SPAN +>Using the Internet <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > to Distribute MIXER Conformant Global Address Mapping</I >, January 1998.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5178" +NAME="AEN5174" ></A ><P >[RFC2230] <SPAN CLASS="AUTHOR" >R. Atkinson</SPAN >, <I ->Key Exchange Delegation Record for the <SPAN +>Key Exchange Delegation Record for the <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM ></I >, October 1997.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><H2 CLASS="bibliodiv" ><A -NAME="AEN5186" -><SPAN +NAME="AEN5182" +><ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > and the Internet</A ></H2 ><DIV CLASS="biblioentry" ><A -NAME="AEN5189" +NAME="AEN5185" ></A ><P >[RFC1101] <SPAN CLASS="AUTHOR" >P. V. Mockapetris</SPAN >, <I -><SPAN +><ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Encoding of Network Names and Other Types</I >, April 1989.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5197" +NAME="AEN5193" ></A ><P >[RFC1123] <SPAN @@ -1306,13 +1168,13 @@ CLASS="AUTHOR" >, October 1989.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5204" +NAME="AEN5200" ></A ><P >[RFC1591] <SPAN @@ -1323,13 +1185,13 @@ CLASS="AUTHOR" >, March 1994.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5211" +NAME="AEN5207" ></A ><P >[RFC2317] <SPAN @@ -1346,62 +1208,62 @@ CLASS="AUTHOR" >, March 1998.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><H2 CLASS="bibliodiv" ><A -NAME="AEN5225" -><SPAN +NAME="AEN5221" +><ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Operations</A ></H2 ><DIV CLASS="biblioentry" ><A -NAME="AEN5228" +NAME="AEN5224" ></A ><P >[RFC1537] <SPAN CLASS="AUTHOR" >P. Beertema</SPAN >, <I ->Common <SPAN +>Common <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Data File Configuration Errors</I >, October 1993.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5236" +NAME="AEN5232" ></A ><P >[RFC1912] <SPAN CLASS="AUTHOR" >D. Barr</SPAN >, <I ->Common <SPAN +>Common <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Operational and Configuration Errors</I >, February 1996.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5244" +NAME="AEN5240" ></A ><P >[RFC2010] <SPAN @@ -1415,13 +1277,13 @@ CLASS="AUTHOR" >, October 1996.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5255" +NAME="AEN5251" ></A ><P >[RFC2219] <SPAN @@ -1431,29 +1293,29 @@ CLASS="AUTHOR" CLASS="AUTHOR" >and R. Wright</SPAN >, <I ->Use of <SPAN +>Use of <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Aliases for Network Services.</I >, October 1997.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><H2 CLASS="bibliodiv" ><A -NAME="AEN5267" ->Other <SPAN +NAME="AEN5263" +>Other <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM >-related RFCs</A ></H2 ><DIV CLASS="biblioentry" ><A -NAME="AEN5273" +NAME="AEN5269" ></A ><P >[RFC1464] <SPAN @@ -1464,53 +1326,53 @@ CLASS="AUTHOR" >, May 1993.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5280" +NAME="AEN5276" ></A ><P >[RFC1713] <SPAN CLASS="AUTHOR" >A. Romao</SPAN >, <I ->Tools for <SPAN +>Tools for <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Debugging</I >, November 1994.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5288" +NAME="AEN5284" ></A ><P >[RFC1794] <SPAN CLASS="AUTHOR" >T. Brisco</SPAN >, <I -><SPAN +><ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Support for Load Balancing</I >, April 1995.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5296" +NAME="AEN5292" ></A ><P >[RFC2240] <SPAN @@ -1521,13 +1383,13 @@ CLASS="AUTHOR" >, November 1997.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5303" +NAME="AEN5299" ></A ><P >[RFC2345] <SPAN @@ -1544,13 +1406,13 @@ CLASS="AUTHOR" >, May 1998.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><DIV CLASS="biblioentry" ><A -NAME="AEN5317" +NAME="AEN5313" ></A ><P >[RFC2352] <SPAN @@ -1561,19 +1423,19 @@ CLASS="AUTHOR" >, May 1998.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ><H2 CLASS="bibliodiv" ><A -NAME="AEN5324" +NAME="AEN5320" >Obsolete and Unimplemented Experimental RRs</A ></H2 ><DIV CLASS="biblioentry" ><A -NAME="AEN5326" +NAME="AEN5322" ></A ><P >[RFC1712] <SPAN @@ -1589,15 +1451,15 @@ CLASS="AUTHOR" CLASS="AUTHOR" >and D. Baldoni</SPAN >, <I -><SPAN +><ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Encoding of Geographical Location</I >, November 1994.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ></DIV @@ -1624,23 +1486,23 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN5347" ->A.3.3. Other Documents About <SPAN +NAME="AEN5343" +>A.3.3. Other Documents About <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM ></A ></H2 ><P ></P ><H3 ><A -NAME="AEN5351" +NAME="AEN5347" >Bibliography</A ></H3 ><DIV CLASS="biblioentry" ><A -NAME="AEN5352" +NAME="AEN5348" ></A ><P ><SPAN @@ -1650,17 +1512,17 @@ CLASS="AUTHOR" CLASS="AUTHOR" >and Cricket Liu</SPAN >, <I -><SPAN +><ACRONYM CLASS="acronym" ->DNS</SPAN -> and <SPAN +>DNS</ACRONYM +> and <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM ></I >, 1998.</P ><DIV CLASS="BIBLIOENTRYBLOCK" -STYLE="margin-left=0.5in" +STYLE="margin-left: 0.5in" ></DIV ></DIV ></DIV diff --git a/dist/bind/doc/arm/Bv9ARM.html b/dist/bind/doc/arm/Bv9ARM.html index 65c1012d986..bf8b49e9679 100644 --- a/dist/bind/doc/arm/Bv9ARM.html +++ b/dist/bind/doc/arm/Bv9ARM.html @@ -1,11 +1,11 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >BIND 9 Administrator Reference Manual</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"><LINK +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REL="NEXT" TITLE="Introduction " HREF="Bv9ARM.ch01.html"></HEAD @@ -31,10 +31,10 @@ NAME="AEN1" ></H1 ><P CLASS="copyright" ->Copyright © 2004 by Internet Systems Consortium, Inc. ("ISC")</P +>Copyright © 2004 Internet Systems Consortium, Inc. ("ISC")</P ><P CLASS="copyright" ->Copyright © 2000-2003 by Internet Software Consortium</P +>Copyright © 2000-2003 Internet Software Consortium</P ><HR></DIV ><DIV CLASS="TOC" @@ -68,9 +68,9 @@ HREF="Bv9ARM.ch01.html#AEN42" ><DT >1.4. <A HREF="Bv9ARM.ch01.html#AEN107" ->The Domain Name System (<SPAN +>The Domain Name System (<ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM >)</A ></DT ><DD @@ -112,9 +112,9 @@ HREF="Bv9ARM.ch01.html#AEN218" ><DT >2. <A HREF="Bv9ARM.ch02.html" -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > Resource Requirements</A ></DT ><DD @@ -292,49 +292,39 @@ HREF="Bv9ARM.ch04.html#DNSSEC" ><DL ><DT >4.8.1. <A -HREF="Bv9ARM.ch04.html#AEN951" +HREF="Bv9ARM.ch04.html#AEN952" >Generating Keys</A ></DT ><DT >4.8.2. <A -HREF="Bv9ARM.ch04.html#AEN971" ->Creating a Keyset</A -></DT -><DT ->4.8.3. <A -HREF="Bv9ARM.ch04.html#AEN983" ->Signing the Child's Keyset</A -></DT -><DT ->4.8.4. <A -HREF="Bv9ARM.ch04.html#AEN996" +HREF="Bv9ARM.ch04.html#AEN972" >Signing the Zone</A ></DT ><DT ->4.8.5. <A -HREF="Bv9ARM.ch04.html#AEN1012" +>4.8.3. <A +HREF="Bv9ARM.ch04.html#AEN994" >Configuring Servers</A ></DT ></DL ></DD ><DT >4.9. <A -HREF="Bv9ARM.ch04.html#AEN1019" ->IPv6 Support in <SPAN +HREF="Bv9ARM.ch04.html#AEN1001" +>IPv6 Support in <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9</A ></DT ><DD ><DL ><DT >4.9.1. <A -HREF="Bv9ARM.ch04.html#AEN1037" +HREF="Bv9ARM.ch04.html#AEN1019" >Address Lookups Using AAAA Records</A ></DT ><DT >4.9.2. <A -HREF="Bv9ARM.ch04.html#AEN1043" +HREF="Bv9ARM.ch04.html#AEN1025" >Address to Name Lookups Using Nibble Format</A ></DT ></DL @@ -344,16 +334,16 @@ HREF="Bv9ARM.ch04.html#AEN1043" ><DT >5. <A HREF="Bv9ARM.ch05.html" ->The <SPAN +>The <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 Lightweight Resolver</A ></DT ><DD ><DL ><DT >5.1. <A -HREF="Bv9ARM.ch05.html#AEN1052" +HREF="Bv9ARM.ch05.html#AEN1034" >The Lightweight Resolver Library</A ></DT ><DT @@ -366,9 +356,9 @@ HREF="Bv9ARM.ch05.html#lwresd" ><DT >6. <A HREF="Bv9ARM.ch06.html" -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 Configuration Reference</A ></DT ><DD @@ -387,7 +377,7 @@ HREF="Bv9ARM.ch06.html#address_match_lists" ></DT ><DT >6.1.2. <A -HREF="Bv9ARM.ch06.html#AEN1298" +HREF="Bv9ARM.ch06.html#AEN1280" >Comment Syntax</A ></DT ></DL @@ -401,7 +391,7 @@ HREF="Bv9ARM.ch06.html#Configuration_File_Grammar" ><DL ><DT >6.2.1. <A -HREF="Bv9ARM.ch06.html#AEN1419" +HREF="Bv9ARM.ch06.html#AEN1401" ><B CLASS="command" >acl</B @@ -418,7 +408,7 @@ Usage</A ></DT ><DT >6.2.3. <A -HREF="Bv9ARM.ch06.html#AEN1463" +HREF="Bv9ARM.ch06.html#AEN1445" ><B CLASS="command" >controls</B @@ -434,7 +424,7 @@ CLASS="command" ></DT ><DT >6.2.5. <A -HREF="Bv9ARM.ch06.html#AEN1542" +HREF="Bv9ARM.ch06.html#AEN1524" ><B CLASS="command" >include</B @@ -442,7 +432,7 @@ CLASS="command" ></DT ><DT >6.2.6. <A -HREF="Bv9ARM.ch06.html#AEN1547" +HREF="Bv9ARM.ch06.html#AEN1529" ><B CLASS="command" >include</B @@ -450,7 +440,7 @@ CLASS="command" ></DT ><DT >6.2.7. <A -HREF="Bv9ARM.ch06.html#AEN1554" +HREF="Bv9ARM.ch06.html#AEN1536" ><B CLASS="command" >key</B @@ -458,7 +448,7 @@ CLASS="command" ></DT ><DT >6.2.8. <A -HREF="Bv9ARM.ch06.html#AEN1561" +HREF="Bv9ARM.ch06.html#AEN1543" ><B CLASS="command" >key</B @@ -466,7 +456,7 @@ CLASS="command" ></DT ><DT >6.2.9. <A -HREF="Bv9ARM.ch06.html#AEN1581" +HREF="Bv9ARM.ch06.html#AEN1563" ><B CLASS="command" >logging</B @@ -474,7 +464,7 @@ CLASS="command" ></DT ><DT >6.2.10. <A -HREF="Bv9ARM.ch06.html#AEN1621" +HREF="Bv9ARM.ch06.html#AEN1603" ><B CLASS="command" >logging</B @@ -482,7 +472,7 @@ CLASS="command" ></DT ><DT >6.2.11. <A -HREF="Bv9ARM.ch06.html#AEN1887" +HREF="Bv9ARM.ch06.html#AEN1873" ><B CLASS="command" >lwres</B @@ -490,7 +480,7 @@ CLASS="command" ></DT ><DT >6.2.12. <A -HREF="Bv9ARM.ch06.html#AEN1911" +HREF="Bv9ARM.ch06.html#AEN1897" ><B CLASS="command" >lwres</B @@ -498,7 +488,7 @@ CLASS="command" ></DT ><DT >6.2.13. <A -HREF="Bv9ARM.ch06.html#AEN1930" +HREF="Bv9ARM.ch06.html#AEN1916" ><B CLASS="command" >masters</B @@ -506,7 +496,7 @@ CLASS="command" ></DT ><DT >6.2.14. <A -HREF="Bv9ARM.ch06.html#AEN1945" +HREF="Bv9ARM.ch06.html#AEN1931" ><B CLASS="command" >masters</B @@ -514,7 +504,7 @@ CLASS="command" ></DT ><DT >6.2.15. <A -HREF="Bv9ARM.ch06.html#AEN1950" +HREF="Bv9ARM.ch06.html#AEN1936" ><B CLASS="command" >options</B @@ -546,7 +536,7 @@ CLASS="command" ></DT ><DT >6.2.19. <A -HREF="Bv9ARM.ch06.html#AEN3405" +HREF="Bv9ARM.ch06.html#AEN3402" ><B CLASS="command" >trusted-keys</B @@ -554,7 +544,7 @@ CLASS="command" ></DT ><DT >6.2.20. <A -HREF="Bv9ARM.ch06.html#AEN3421" +HREF="Bv9ARM.ch06.html#AEN3418" ><B CLASS="command" >trusted-keys</B @@ -571,7 +561,7 @@ CLASS="command" ></DT ><DT >6.2.22. <A -HREF="Bv9ARM.ch06.html#AEN3443" +HREF="Bv9ARM.ch06.html#AEN3440" ><B CLASS="command" >view</B @@ -588,7 +578,7 @@ Statement Grammar</A ></DT ><DT >6.2.24. <A -HREF="Bv9ARM.ch06.html#AEN3617" +HREF="Bv9ARM.ch06.html#AEN3614" ><B CLASS="command" >zone</B @@ -598,7 +588,7 @@ CLASS="command" ></DD ><DT >6.3. <A -HREF="Bv9ARM.ch06.html#AEN4019" +HREF="Bv9ARM.ch06.html#AEN4015" >Zone File</A ></DT ><DD @@ -610,7 +600,7 @@ HREF="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them" ></DT ><DT >6.3.2. <A -HREF="Bv9ARM.ch06.html#AEN4339" +HREF="Bv9ARM.ch06.html#AEN4335" >Discussion of MX Records</A ></DT ><DT @@ -620,20 +610,20 @@ HREF="Bv9ARM.ch06.html#Setting_TTLs" ></DT ><DT >6.3.4. <A -HREF="Bv9ARM.ch06.html#AEN4460" +HREF="Bv9ARM.ch06.html#AEN4456" >Inverse Mapping in IPv4</A ></DT ><DT >6.3.5. <A -HREF="Bv9ARM.ch06.html#AEN4487" +HREF="Bv9ARM.ch06.html#AEN4483" >Other Zone File Directives</A ></DT ><DT >6.3.6. <A -HREF="Bv9ARM.ch06.html#AEN4545" -><SPAN +HREF="Bv9ARM.ch06.html#AEN4541" +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > Master File Extension: the <B CLASS="command" >$GENERATE</B @@ -646,9 +636,9 @@ CLASS="command" ><DT >7. <A HREF="Bv9ARM.ch07.html" -><SPAN +><ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM > 9 Security Considerations</A ></DT ><DD @@ -660,7 +650,7 @@ HREF="Bv9ARM.ch07.html#Access_Control_Lists" ></DT ><DT >7.2. <A -HREF="Bv9ARM.ch07.html#AEN4662" +HREF="Bv9ARM.ch07.html#AEN4658" ><B CLASS="command" >chroot</B @@ -674,7 +664,7 @@ UNIX servers)</A ><DL ><DT >7.2.1. <A -HREF="Bv9ARM.ch07.html#AEN4685" +HREF="Bv9ARM.ch07.html#AEN4681" >The <B CLASS="command" >chroot</B @@ -682,7 +672,7 @@ CLASS="command" ></DT ><DT >7.2.2. <A -HREF="Bv9ARM.ch07.html#AEN4703" +HREF="Bv9ARM.ch07.html#AEN4699" >Using the <B CLASS="command" >setuid</B @@ -706,26 +696,26 @@ HREF="Bv9ARM.ch08.html" ><DL ><DT >8.1. <A -HREF="Bv9ARM.ch08.html#AEN4724" +HREF="Bv9ARM.ch08.html#AEN4720" >Common Problems</A ></DT ><DD ><DL ><DT >8.1.1. <A -HREF="Bv9ARM.ch08.html#AEN4726" +HREF="Bv9ARM.ch08.html#AEN4722" >It's not working; how can I figure out what's wrong?</A ></DT ></DL ></DD ><DT >8.2. <A -HREF="Bv9ARM.ch08.html#AEN4729" +HREF="Bv9ARM.ch08.html#AEN4725" >Incrementing and Changing the Serial Number</A ></DT ><DT >8.3. <A -HREF="Bv9ARM.ch08.html#AEN4734" +HREF="Bv9ARM.ch08.html#AEN4730" >Where Can I Get Help?</A ></DT ></DL @@ -739,20 +729,20 @@ HREF="Bv9ARM.ch09.html" ><DL ><DT >A.1. <A -HREF="Bv9ARM.ch09.html#AEN4750" +HREF="Bv9ARM.ch09.html#AEN4746" >Acknowledgments</A ></DT ><DD ><DL ><DT >A.1.1. <A -HREF="Bv9ARM.ch09.html#AEN4752" ->A Brief History of the <SPAN +HREF="Bv9ARM.ch09.html#AEN4748" +>A Brief History of the <ACRONYM CLASS="acronym" ->DNS</SPAN -> and <SPAN +>DNS</ACRONYM +> and <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM ></A ></DT ></DL @@ -760,9 +750,9 @@ CLASS="acronym" ><DT >A.2. <A HREF="Bv9ARM.ch09.html#historical_dns_information" ->General <SPAN +>General <ACRONYM CLASS="acronym" ->DNS</SPAN +>DNS</ACRONYM > Reference Information</A ></DT ><DD @@ -793,10 +783,10 @@ HREF="Bv9ARM.ch09.html#internet_drafts" ></DT ><DT >A.3.3. <A -HREF="Bv9ARM.ch09.html#AEN5347" ->Other Documents About <SPAN +HREF="Bv9ARM.ch09.html#AEN5343" +>Other Documents About <ACRONYM CLASS="acronym" ->BIND</SPAN +>BIND</ACRONYM ></A ></DT ></DL diff --git a/dist/bind/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt b/dist/bind/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt new file mode 100644 index 00000000000..09776618f2a --- /dev/null +++ b/dist/bind/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) + <draft-ietf-dnsext-dhcid-rr-08.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 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/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt new file mode 100644 index 00000000000..0783e7b26e1 --- /dev/null +++ b/dist/bind/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 <anything>: An <anything> 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/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt new file mode 100644 index 00000000000..5728b35c9ba --- /dev/null +++ b/dist/bind/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 <SNAME, SCLASS>, + but does not contain any RRsets that exactly match <SNAME, SCLASS, + STYPE>. + + Name Error: The zone does not contain any RRsets that match <SNAME, + SCLASS> either exactly or via wildcard name expansion. + + Wildcard Answer: The zone does not contain any RRsets that exactly + match <SNAME, SCLASS> but does contain an RRset that matches + <SNAME, SCLASS, STYPE> via wildcard name expansion. + + Wildcard No Data: The zone does not contain any RRsets that exactly + match <SNAME, SCLASS>, does contain one or more RRsets that match + <SNAME, SCLASS> via wildcard name expansion, but does not contain + any RRsets that match <SNAME, SCLASS, STYPE> 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 <SNAME, SCLASS, STYPE> 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 <SNAME, SCLASS> but contains no + RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST + include the NSEC RR for <SNAME, SCLASS> 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 <SNAME, SCLASS> + 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 <SNAME, + SCLASS>; and + o An NSEC RR proving that the zone contains no RRsets that would + match <SNAME, SCLASS> 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 <SNAME, + SCLASS> but does contain an RRset which matches <SNAME, SCLASS, + STYPE> 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 <SNAME, SCLASS>. 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 <SNAME, SCLASS>, and while the zone does + contain RRsets which match <SNAME, SCLASS> 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 <SNAME, SCLASS> 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 <SNAME, SCLASS>. + + 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 <QNAME, QTYPE, QCLASS>, but in cases such as the response + form described in Section 3.1.3.2 the appropriate cache index will be + the double <QNAME,QCLASS>. + + 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 <QNAME, QTYPE, QCLASS> 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/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt new file mode 100644 index 00000000000..79a17284357 --- /dev/null +++ b/dist/bind/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/dist/bind/doc/draft/draft-ietf-dnsext-insensitive-04.txt b/dist/bind/doc/draft/draft-ietf-dnsext-insensitive-04.txt new file mode 100644 index 00000000000..4cfd417804d --- /dev/null +++ b/dist/bind/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 + ------ ---- ------ ----- ---- ------------- ------------- + <draft-ietf-dnsext-insensitive-04.txt> + + 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", + <http://www.unicode.org/unicode/standard/standard.html>. + + + +-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/dist/bind/doc/draft/draft-ietf-dnsext-interop3597-01.txt b/dist/bind/doc/draft/draft-ietf-dnsext-interop3597-01.txt new file mode 100644 index 00000000000..123d3cc0961 --- /dev/null +++ b/dist/bind/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/dist/bind/doc/draft/draft-ietf-dnsext-mdns-33.txt b/dist/bind/doc/draft/draft-ietf-dnsext-mdns-33.txt new file mode 100644 index 00000000000..8dcacc8bb9e --- /dev/null +++ b/dist/bind/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 +<draft-ietf-dnsext-mdns-33.txt> 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/dist/bind/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt b/dist/bind/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt new file mode 100644 index 00000000000..1133b0c87d4 --- /dev/null +++ b/dist/bind/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 + ---- --- ---- --------- ----------- + <draft-ietf-dnsext-tsig-sha-00.txt> + + +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 <namedroppers@ops.ietf.org>. + + 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/dist/bind/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt b/dist/bind/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt new file mode 100644 index 00000000000..04815175fdb --- /dev/null +++ b/dist/bind/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/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt b/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt new file mode 100644 index 00000000000..42c3c0b7c7e --- /dev/null +++ b/dist/bind/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/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt b/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt new file mode 100644 index 00000000000..b14f711d531 --- /dev/null +++ b/dist/bind/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/dist/bind/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt b/dist/bind/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt new file mode 100644 index 00000000000..2311ee6c18a --- /dev/null +++ b/dist/bind/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/dist/bind/doc/draft/draft-ietf-dnsop-respsize-01.txt b/dist/bind/doc/draft/draft-ietf-dnsop-respsize-01.txt new file mode 100644 index 00000000000..f6ece882103 --- /dev/null +++ b/dist/bind/doc/draft/draft-ietf-dnsop-respsize-01.txt @@ -0,0 +1,485 @@ + DNSOP Working Group Paul Vixie, ISC (Ed.) + INTERNET-DRAFT Akira Kato, WIDE + <draft-ietf-dnsop-respsize-01.txt> 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/dist/bind/doc/draft/draft-ietf-dnsop-serverid-02.txt b/dist/bind/doc/draft/draft-ietf-dnsop-serverid-02.txt new file mode 100644 index 00000000000..b593c57179e --- /dev/null +++ b/dist/bind/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/dist/bind/doc/draft/update b/dist/bind/doc/draft/update index 766f15b08e6..6ac20904ab2 100644 --- a/dist/bind/doc/draft/update +++ b/dist/bind/doc/draft/update @@ -1,4 +1,5 @@ #!/bin/sh +commit= for i do z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'` @@ -34,9 +35,12 @@ do then rm $old cvs delete $old - else - old= + commit="$commit $old" fi - cvs commit -m "new draft" $i $old + commit="$commit $i" fi done +if test -n "$commit" +then + cvs commit -m "new draft" $commit +fi diff --git a/dist/bind/doc/misc/ipv6 b/dist/bind/doc/misc/ipv6 index 21c90eedaf1..735f3dcaaaf 100644 --- a/dist/bind/doc/misc/ipv6 +++ b/dist/bind/doc/misc/ipv6 @@ -29,27 +29,40 @@ 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 +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 +::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. -In bind9, we always bind to the ipv6 wildcard port for both TCP and -UDP, and specific addresses for ipv4 sockets. This causes some -interesting behavior depending on the system implementation of ipv6. +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 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. +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 @@ -90,11 +103,11 @@ packets. RELEVANT RFCs ------------- -2373: IP Version 6 Addressing Architecture +3513: Internet Protocol Version 6 (IPv6) Addressing Architecture -2553: Basic Socket Interface Extensions for IPv6 +3493: Basic Socket Interface Extensions for IPv6 -draft-ietf-ipngwg-rfc2292bis-01: Advanced Sockets API for IPv6 (draft) +3542: Advanced Sockets Application Program Interface (API) for IPv6 -Id: ipv6,v 1.5.206.1 2004/03/06 13:16:19 marka Exp +Id: ipv6,v 1.5.206.4 2004/08/10 04:28:15 jinmei Exp diff --git a/dist/bind/doc/misc/options b/dist/bind/doc/misc/options index 8eec93f4cae..f77e4940c58 100644 --- a/dist/bind/doc/misc/options +++ b/dist/bind/doc/misc/options @@ -82,7 +82,7 @@ options { root-delegation-only [ exclude { <quoted_string>; ... } ]; disable-algorithms <string> { <string>; ... }; dnssec-enable <boolean>; - dnssec-lookaside <string>; + dnssec-lookaside <string> trust-anchor <string>; dnssec-must-be-secure <string> <boolean>; allow-query { <address_match_element>; ... }; allow-transfer { <address_match_element>; ... }; @@ -262,7 +262,7 @@ view <string> <optional_class> { root-delegation-only [ exclude { <quoted_string>; ... } ]; disable-algorithms <string> { <string>; ... }; dnssec-enable <boolean>; - dnssec-lookaside <string>; + dnssec-lookaside <string> trust-anchor <string>; dnssec-must-be-secure <string> <boolean>; allow-query { <address_match_element>; ... }; allow-transfer { <address_match_element>; ... }; diff --git a/dist/bind/doc/rfc/index b/dist/bind/doc/rfc/index index fd66d2472ce..fb72ccc314d 100644 --- a/dist/bind/doc/rfc/index +++ b/dist/bind/doc/rfc/index @@ -61,8 +61,9 @@ 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 +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) @@ -89,3 +90,5 @@ 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/dist/bind/doc/rfc/rfc3833.txt b/dist/bind/doc/rfc/rfc3833.txt new file mode 100644 index 00000000000..8ce4d34e341 --- /dev/null +++ b/dist/bind/doc/rfc/rfc3833.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group D. Atkins +Request for Comments: 3833 IHTFP Consulting +Category: Informational R. Austein + ISC + August 2004 + + + Threat Analysis of the Domain Name System (DNS) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + Although the DNS Security Extensions (DNSSEC) have been under + development for most of the last decade, the IETF has never written + down the specific set of threats against which DNSSEC is designed to + protect. Among other drawbacks, this cart-before-the-horse situation + has made it difficult to determine whether DNSSEC meets its design + goals, since its design goals are not well specified. This note + attempts to document some of the known threats to the DNS, and, in + doing so, attempts to measure to what extent (if any) DNSSEC is a + useful tool in defending against these threats. + +1. Introduction + + The earliest organized work on DNSSEC within the IETF was an open + design team meeting organized by members of the DNS working group in + November 1993 at the 28th IETF meeting in Houston. The broad + outlines of DNSSEC as we know it today are already clear in Jim + Galvin's summary of the results of that meeting [Galvin93]: + + - While some participants in the meeting were interested in + protecting against disclosure of DNS data to unauthorized parties, + the design team made an explicit decision that "DNS data is + `public'", and ruled all threats of data disclosure explicitly out + of scope for DNSSEC. + + - While some participants in the meeting were interested in + authentication of DNS clients and servers as a basis for access + control, this work was also ruled out of scope for DNSSEC per se. + + + +Atkins & Austein Informational [Page 1] + +RFC 3833 DNS Threat Analysis August 2004 + + + - Backwards compatibility and co-existence with "insecure DNS" was + listed as an explicit requirement. + + - The resulting list of desired security services was + 1) data integrity, and + 2) data origin authentication. + + - The design team noted that a digital signature mechanism would + support the desired services. + + While a number of detail decisions were yet to be made (and in some + cases remade after implementation experience) over the subsequent + decade, the basic model and design goals have remained fixed. + + Nowhere, however, does any of the DNSSEC work attempt to specify in + any detail the sorts of attacks against which DNSSEC is intended to + protect, or the reasons behind the list of desired security services + that came out of the Houston meeting. For that, we have to go back + to a paper originally written by Steve Bellovin in 1990 but not + published until 1995, for reasons that Bellovin explained in the + paper's epilogue [Bellovin95]. + + While it may seem a bit strange to publish the threat analysis a + decade after starting work on the protocol designed to defend against + it, that is, nevertheless, what this note attempts to do. Better + late than never. + + This note assumes that the reader is familiar with both the DNS and + with DNSSEC, and does not attempt to provide a tutorial on either. + The DNS documents most relevant to the subject of this note are: + [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308], + [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535]. + + For purposes of discussion, this note uses the term "DNSSEC" to refer + to the core hierarchical public key and signature mechanism specified + in the DNSSEC documents, and refers to TKEY and TSIG as separate + mechanisms, even though channel security mechanisms such as TKEY and + TSIG are also part of the larger problem of "securing DNS" and thus + are often considered part of the overall set of "DNS security + extensions". This is an arbitrary distinction that in part reflects + the way in which the protocol has evolved (introduction of a + putatively simpler channel security model for certain operations such + as zone transfers and dynamic update requests), and perhaps should be + changed in a future revision of this note. + + + + + + + +Atkins & Austein Informational [Page 2] + +RFC 3833 DNS Threat Analysis August 2004 + + +2. Known Threats + + There are several distinct classes of threats to the DNS, most of + which are DNS-related instances of more general problems, but a few + of which are specific to peculiarities of the DNS protocol. + +2.1. Packet Interception + + Some of the simplest threats against DNS are various forms of packet + interception: monkey-in-the-middle attacks, eavesdropping on requests + combined with spoofed responses that beat the real response back to + the resolver, and so forth. In any of these scenarios, the attacker + can simply tell either party (usually the resolver) whatever it wants + that party to believe. While packet interception attacks are far + from unique to DNS, DNS's usual behavior of sending an entire query + or response in a single unsigned, unencrypted UDP packet makes these + attacks particularly easy for any bad guy with the ability to + intercept packets on a shared or transit network. + + To further complicate things, the DNS query the attacker intercepts + may just be a means to an end for the attacker: the attacker might + even choose to return the correct result in the answer section of a + reply message while using other parts of the message to set the stage + for something more complicated, for example, a name chaining attack + (see section 2.3). + + While it certainly would be possible to sign DNS messages using a + channel security mechanism such as TSIG or IPsec, or even to encrypt + them using IPsec, this would not be a very good solution for + interception attacks. First, this approach would impose a fairly + high processing cost per DNS message, as well as a very high cost + associated with establishing and maintaining bilateral trust + relationships between all the parties that might be involved in + resolving any particular query. For heavily used name servers (such + as the servers for the root zone), this cost would almost certainly + be prohibitively high. Even more important, however, is that the + underlying trust model in such a design would be wrong, since at best + it would only provide a hop-by-hop integrity check on DNS messages + and would not provide any sort of end-to-end integrity check between + the producer of DNS data (the zone administrator) and the consumer of + DNS data (the application that triggered the query). + + By contrast, DNSSEC (when used properly) does provide an end-to-end + data integrity check, and is thus a much better solution for this + class of problems during basic DNS lookup operations. + + + + + + +Atkins & Austein Informational [Page 3] + +RFC 3833 DNS Threat Analysis August 2004 + + + TSIG does have its place in corners of the DNS protocol where there's + a specific trust relationship between a particular client and a + particular server, such as zone transfer, dynamic update, or a + resolver (stub or otherwise) that is not going to check all the + DNSSEC signatures itself. + + Note that DNSSEC does not provide any protection against modification + of the DNS message header, so any properly paranoid resolver must: + + - Perform all of the DNSSEC signature checking on its own, + + - Use TSIG (or some equivalent mechanism) to ensure the integrity of + its communication with whatever name servers it chooses to trust, + or + + - Resign itself to the possibility of being attacked via packet + interception (and via other techniques discussed below). + +2.2. ID Guessing and Query Prediction + + Since DNS is for the most part used over UDP/IP, it is relatively + easy for an attacker to generate packets which will match the + transport protocol parameters. The ID field in the DNS header is + only a 16-bit field and the server UDP port associated with DNS is a + well-known value, so there are only 2**32 possible combinations of ID + and client UDP port for a given client and server. This is not a + particularly large range, and is not sufficient to protect against a + brute force search; furthermore, in practice both the client UDP port + and the ID can often be predicted from previous traffic, and it is + not uncommon for the client port to be a known fixed value as well + (due to firewalls or other restrictions), thus frequently reducing + the search space to a range smaller than 2**16. + + By itself, ID guessing is not enough to allow an attacker to inject + bogus data, but combined with knowledge (or guesses) about QNAMEs and + QTYPEs for which a resolver might be querying, this leaves the + resolver only weakly defended against injection of bogus responses. + + Since this attack relies on predicting a resolver's behavior, it's + most likely to be successful when the victim is in a known state, + whether because the victim rebooted recently, or because the victim's + behavior has been influenced by some other action by the attacker, or + because the victim is responding (in a predictable way) to some third + party action known to the attacker. + + + + + + + +Atkins & Austein Informational [Page 4] + +RFC 3833 DNS Threat Analysis August 2004 + + + This attack is both more and less difficult for the attacker than the + simple interception attack described above: more difficult, because + the attack only works when the attacker guesses correctly; less + difficult, because the attacker doesn't need to be on a transit or + shared network. + + In most other respects, this attack is similar to a packet + interception attack. A resolver that checks DNSSEC signatures will + be able to detect the forged response; resolvers that do not perform + DNSSEC signature checking themselves should use TSIG or some + equivalent mechanism to ensure the integrity of their communication + with a recursive name server that does perform DNSSEC signature + checking. + +2.3. Name Chaining + + Perhaps the most interesting class of DNS-specific threats are the + name chaining attacks. These are a subset of a larger class of + name-based attacks, sometimes called "cache poisoning" attacks. Most + name-based attacks can be partially mitigated by the long-standing + defense of checking RRs in response messages for relevance to the + original query, but such defenses do not catch name chaining attacks. + There are several variations on the basic attack, but what they all + have in common is that they all involve DNS RRs whose RDATA portion + (right hand side) includes a DNS name (or, in a few cases, something + that is not a DNS name but which directly maps to a DNS name). Any + such RR is, at least in principle, a hook that lets an attacker feed + bad data into a victim's cache, thus potentially subverting + subsequent decisions based on DNS names. + + The worst examples in this class of RRs are CNAME, NS, and DNAME RRs + because they can redirect a victim's query to a location of the + attacker's choosing. RRs like MX and SRV are somewhat less + dangerous, but in principle they can also be used to trigger further + lookups at a location of the attacker's choosing. Address RR types + such as A or AAAA don't have DNS names in their RDATA, but since the + IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of + IPv4 and IPv6 addresses, these record types can also be used in a + name chaining attack. + + The general form of a name chaining attack is something like this: + + - Victim issues a query, perhaps at the instigation of the attacker + or some third party; in some cases the query itself may be + unrelated to the name under attack (that is, the attacker is just + using this query as a means to inject false information about some + other name). + + + + +Atkins & Austein Informational [Page 5] + +RFC 3833 DNS Threat Analysis August 2004 + + + - Attacker injects response, whether via packet interception, query + guessing, or by being a legitimate name server that's involved at + some point in the process of answering the query that the victim + issued. + + - Attacker's response includes one or more RRs with DNS names in + their RDATA; depending on which particular form this attack takes, + the object may be to inject false data associated with those names + into the victim's cache via the Additional section of this + response, or may be to redirect the next stage of the query to a + server of the attacker's choosing (in order to inject more complex + lies into the victim's cache than will fit easily into a single + response, or in order to place the lies in the Authority or Answer + section of a response where they will have a better chance of + sneaking past a resolver's defenses). + + Any attacker who can insert resource records into a victim's cache + can almost certainly do some kind of damage, so there are cache + poisoning attacks which are not name chaining attacks in the sense + discussed here. However, in the case of name chaining attacks, the + cause and effect relationship between the initial attack and the + eventual result may be significantly more complex than in the other + forms of cache poisoning, so name chaining attacks merit special + attention. + + The common thread in all of the name chaining attacks is that + response messages allow the attacker to introduce arbitrary DNS names + of the attacker's choosing and provide further information that the + attacker claims is associated with those names; unless the victim has + better knowledge of the data associated with those names, the victim + is going to have a hard time defending against this class of attacks. + + This class of attack is particularly insidious given that it's quite + easy for an attacker to provoke a victim into querying for a + particular name of the attacker's choosing, for example, by embedding + a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail + to the victim. If the victim's mail reading program attempts to + follow such a link, the result will be a DNS query for a name chosen + by the attacker. + + DNSSEC should provide a good defense against most (all?) variations + on this class of attack. By checking signatures, a resolver can + determine whether the data associated with a name really was inserted + by the delegated authority for that portion of the DNS name space. + More precisely, a resolver can determine whether the entity that + injected the data had access to an allegedly secret key whose + + + + + +Atkins & Austein Informational [Page 6] + +RFC 3833 DNS Threat Analysis August 2004 + + + corresponding public key appears at an expected location in the DNS + name space with an expected chain of parental signatures that start + with a public key of which the resolver has prior knowledge. + + DNSSEC signatures do not cover glue records, so there's still a + possibility of a name chaining attack involving glue, but with DNSSEC + it is possible to detect the attack by temporarily accepting the glue + in order to fetch the signed authoritative version of the same data, + then checking the signatures on the authoritative version. + +2.4. Betrayal By Trusted Server + + Another variation on the packet interception attack is the trusted + server that turns out not to be so trustworthy, whether by accident + or by intent. Many client machines are only configured with stub + resolvers, and use trusted servers to perform all of their DNS + queries on their behalf. In many cases the trusted server is + furnished by the user's ISP and advertised to the client via DHCP or + PPP options. Besides accidental betrayal of this trust relationship + (via server bugs, successful server break-ins, etc), the server + itself may be configured to give back answers that are not what the + user would expect, whether in an honest attempt to help the user or + to promote some other goal such as furthering a business partnership + between the ISP and some third party. + + This problem is particularly acute for frequent travelers who carry + their own equipment and expect it to work in much the same way + wherever they go. Such travelers need trustworthy DNS service + without regard to who operates the network into which their equipment + is currently plugged or what brand of middle boxes the local + infrastructure might use. + + While the obvious solution to this problem would be for the client to + choose a more trustworthy server, in practice this may not be an + option for the client. In many network environments a client machine + has only a limited set of recursive name servers from which to + choose, and none of them may be particularly trustworthy. In extreme + cases, port filtering or other forms of packet interception may + prevent the client host from being able to run an iterative resolver + even if the owner of the client machine is willing and able to do so. + Thus, while the initial source of this problem is not a DNS protocol + attack per se, this sort of betrayal is a threat to DNS clients, and + simply switching to a different recursive name server is not an + adequate defense. + + Viewed strictly from the DNS protocol standpoint, the only difference + between this sort of betrayal and a packet interception attack is + that in this case the client has voluntarily sent its request to the + + + +Atkins & Austein Informational [Page 7] + +RFC 3833 DNS Threat Analysis August 2004 + + + attacker. The defense against this is the same as with a packet + interception attack: the resolver must either check DNSSEC signatures + itself or use TSIG (or equivalent) to authenticate the server that it + has chosen to trust. Note that use of TSIG does not by itself + guarantee that a name server is at all trustworthy: all TSIG can do + is help a resolver protect its communication with a name server that + it has already decided to trust for other reasons. Protecting a + resolver's communication with a server that's giving out bogus + answers is not particularly useful. + + Also note that if the stub resolver does not trust the name server + that is doing work on its behalf and wants to check the DNSSEC + signatures itself, the resolver really does need to have independent + knowledge of the DNSSEC public key(s) it needs in order to perform + the check. Usually the public key for the root zone is enough, but + in some cases knowledge of additional keys may also be appropriate. + + It is difficult to escape the conclusion that a properly paranoid + resolver must always perform its own signature checking, and that + this rule even applies to stub resolvers. + +2.5. Denial of Service + + As with any network service (or, indeed, almost any service of any + kind in any domain of discourse), DNS is vulnerable to denial of + service attacks. DNSSEC does not help this, and may in fact make the + problem worse for resolvers that check signatures, since checking + signatures both increases the processing cost per DNS message and in + some cases can also increase the number of messages needed to answer + a query. TSIG (and similar mechanisms) have equivalent problems. + + DNS servers are also at risk of being used as denial of service + amplifiers, since DNS response packets tend to be significantly + longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help + here either. + +2.6. Authenticated Denial of Domain Names + + Much discussion has taken place over the question of authenticated + denial of domain names. The particular question is whether there is + a requirement for authenticating the non-existence of a name. The + issue is whether the resolver should be able to detect when an + attacker removes RRs from a response. + + General paranoia aside, the existence of RR types whose absence + causes an action other than immediate failure (such as missing MX and + SRV RRs, which fail over to A RRs) constitutes a real threat. + Arguably, in some cases, even the absence of an RR might be + + + +Atkins & Austein Informational [Page 8] + +RFC 3833 DNS Threat Analysis August 2004 + + + considered a problem. The question remains: how serious is this + threat? Clearly the threat does exist; general paranoia says that + some day it'll be on the front page of some major newspaper, even if + we cannot conceive of a plausible scenario involving this attack + today. This implies that some mitigation of this risk is required. + + Note that it's necessary to prove the non-existence of applicable + wildcard RRs as part of the authenticated denial mechanism, and that, + in a zone that is more than one label deep, such a proof may require + proving the non-existence of multiple discrete sets of wildcard RRs. + + DNSSEC does include mechanisms which make it possible to determine + which authoritative names exist in a zone, and which authoritative + resource record types exist at those names. The DNSSEC protections + do not cover non-authoritative data such as glue records. + +2.7. Wildcards + + Much discussion has taken place over whether and how to provide data + integrity and data origin authentication for "wildcard" DNS names. + Conceptually, RRs with wildcard names are patterns for synthesizing + RRs on the fly according to the matching rules described in section + 4.3.2 of RFC 1034. While the rules that control the behavior of + wildcard names have a few quirks that can make them a trap for the + unwary zone administrator, it's clear that a number of sites make + heavy use of wildcard RRs, particularly wildcard MX RRs. + + In order to provide the desired services for wildcard RRs, we need to + do two things: + + - We need a way to attest to the existence of the wildcard RR itself + (that is, we need to show that the synthesis rule exists), and + + - We need a way to attest to the non-existence of any RRs which, if + they existed, would make the wildcard RR irrelevant according to + the synthesis rules that govern the way in which wildcard RRs are + used (that is, we need to show that the synthesis rule is + applicable). + + Note that this makes the wildcard mechanisms dependent upon the + authenticated denial mechanism described in the previous section. + + DNSSEC includes mechanisms along the lines described above, which + make it possible for a resolver to verify that a name server applied + the wildcard expansion rules correctly when generating an answer. + + + + + + +Atkins & Austein Informational [Page 9] + +RFC 3833 DNS Threat Analysis August 2004 + + +3. Weaknesses of DNSSEC + + DNSSEC has some problems of its own: + + - DNSSEC is complex to implement and includes some nasty edge cases + at the zone cuts that require very careful coding. Testbed + experience to date suggests that trivial zone configuration errors + or expired keys can cause serious problems for a DNSSEC-aware + resolver, and that the current protocol's error reporting + capabilities may leave something to be desired. + + - DNSSEC significantly increases the size of DNS response packets; + among other issues, this makes DNSSEC-aware DNS servers even more + effective as denial of service amplifiers. + + - DNSSEC answer validation increases the resolver's work load, since + a DNSSEC-aware resolver will need to perform signature validation + and in some cases will also need to issue further queries. This + increased workload will also increase the time it takes to get an + answer back to the original DNS client, which is likely to trigger + both timeouts and re-queries in some cases. Arguably, many current + DNS clients are already too impatient even before taking the + further delays that DNSSEC will impose into account, but that topic + is beyond the scope of this note. + + - Like DNS itself, DNSSEC's trust model is almost totally + hierarchical. While DNSSEC does allow resolvers to have special + additional knowledge of public keys beyond those for the root, in + the general case the root key is the one that matters. Thus any + compromise in any of the zones between the root and a particular + target name can damage DNSSEC's ability to protect the integrity of + data owned by that target name. This is not a change, since + insecure DNS has the same model. + + - Key rollover at the root is really hard. Work to date has not even + come close to adequately specifying how the root key rolls over, or + even how it's configured in the first place. + + - DNSSEC creates a requirement of loose time synchronization between + the validating resolver and the entity creating the DNSSEC + signatures. Prior to DNSSEC, all time-related actions in DNS could + be performed by a machine that only knew about "elapsed" or + "relative" time. Because the validity period of a DNSSEC signature + is based on "absolute" time, a validating resolver must have the + same concept of absolute time as the zone signer in order to + determine whether the signature is within its validity period or + has expired. An attacker that can change a resolver's opinion of + the current absolute time can fool the resolver using expired + + + +Atkins & Austein Informational [Page 10] + +RFC 3833 DNS Threat Analysis August 2004 + + + signatures. An attacker that can change the zone signer's opinion + of the current absolute time can fool the zone signer into + generating signatures whose validity period does not match what the + signer intended. + + - The possible existence of wildcard RRs in a zone complicates the + authenticated denial mechanism considerably. For most of the + decade that DNSSEC has been under development these issues were + poorly understood. At various times there have been questions as + to whether the authenticated denial mechanism is completely + airtight and whether it would be worthwhile to optimize the + authenticated denial mechanism for the common case in which + wildcards are not present in a zone. However, the main problem is + just the inherent complexity of the wildcard mechanism itself. + This complexity probably makes the code for generating and checking + authenticated denial attestations somewhat fragile, but since the + alternative of giving up wildcards entirely is not practical due to + widespread use, we are going to have to live with wildcards. The + question just becomes one of whether or not the proposed + optimizations would make DNSSEC's mechanisms more or less fragile. + + - Even with DNSSEC, the class of attacks discussed in section 2.4 is + not easy to defeat. In order for DNSSEC to be effective in this + case, it must be possible to configure the resolver to expect + certain categories of DNS records to be signed. This may require + manual configuration of the resolver, especially during the initial + DNSSEC rollout period when the resolver cannot reasonably expect + the root and TLD zones to be signed. + +4. Topics for Future Work + + This section lists a few subjects not covered above which probably + need additional study, additional mechanisms, or both. + +4.1. Interactions With Other Protocols + + The above discussion has concentrated exclusively on attacks within + the boundaries of the DNS protocol itself, since those are (some of) + the problems against which DNSSEC was intended to protect. There + are, however, other potential problems at the boundaries where DNS + interacts with other protocols. + +4.2. Securing DNS Dynamic Update + + DNS dynamic update opens a number of potential problems when combined + with DNSSEC. Dynamic update of a non-secure zone can use TSIG to + authenticate the updating client to the server. While TSIG does not + scale very well (it requires manual configuration of shared keys + + + +Atkins & Austein Informational [Page 11] + +RFC 3833 DNS Threat Analysis August 2004 + + + between the DNS name server and each TSIG client), it works well in a + limited or closed environment such as a DHCP server updating a local + DNS name server. + + Major issues arise when trying to use dynamic update on a secure + zone. TSIG can similarly be used in a limited fashion to + authenticate the client to the server, but TSIG only protects DNS + transactions, not the actual data, and the TSIG is not inserted into + the DNS zone, so resolvers cannot use the TSIG as a way of verifying + the changes to the zone. This means that either: + + a) The updating client must have access to a zone-signing key in + order to sign the update before sending it to the server, or + + b) The DNS name server must have access to an online zone-signing key + in order to sign the update. + + In either case, a zone-signing key must be available to create signed + RRsets to place in the updated zone. The fact that this key must be + online (or at least available) is a potential security risk. + + Dynamic update also requires an update to the SERIAL field of the + zone's SOA RR. In theory, this could also be handled via either of + the above options, but in practice (a) would almost certainly be + extremely fragile, so (b) is the only workable mechanism. + + There are other threats in terms of describing the policy of who can + make what changes to which RRsets in the zone. The current access + control scheme in Secure Dynamic Update is fairly limited. There is + no way to give fine-grained access to updating DNS zone information + to multiple entities, each of whom may require different kinds of + access. For example, Alice may need to be able to add new nodes to + the zone or change existing nodes, but not remove them; Bob may need + to be able to remove zones but not add them; Carol may need to be + able to add, remove, or modify nodes, but only A records. + + Scaling properties of the key management problem here are a + particular concern that needs more study. + +4.3. Securing DNS Zone Replication + + As discussed in previous sections, DNSSEC per se attempts to provide + data integrity and data origin authentication services on top of the + normal DNS query protocol. Using the terminology discussed in + [RFC3552], DNSSEC provides "object security" for the normal DNS query + protocol. For purposes of replicating entire DNS zones, however, + DNSSEC does not provide object security, because zones include + unsigned NS RRs and glue at delegation points. Use of TSIG to + + + +Atkins & Austein Informational [Page 12] + +RFC 3833 DNS Threat Analysis August 2004 + + + protect zone transfer (AXFR or IXFR) operations provides "channel + security", but still does not provide object security for complete + zones. The trust relationships involved in zone transfer are still + very much a hop-by-hop matter of name server operators trusting other + name server operators rather than an end-to-end matter of name server + operators trusting zone administrators. + + Zone object security was not an explicit design goal of DNSSEC, so + failure to provide this service should not be a surprise. + Nevertheless, there are some zone replication scenarios for which + this would be a very useful additional service, so this seems like a + useful area for future work. In theory it should not be difficult to + add zone object security as a backwards compatible enhancement to the + existing DNSSEC model, but the DNSEXT WG has not yet discussed either + the desirability of or the requirements for such an enhancement. + +5. Conclusion + + Based on the above analysis, the DNSSEC extensions do appear to solve + a set of problems that do need to be solved, and are worth deploying. + +Security Considerations + + This entire document is about security considerations of the DNS. + The authors believe that deploying DNSSEC will help to address some, + but not all, of the known threats to the DNS. + +Acknowledgments + + This note is based both on previous published works by others and on + a number of discussions both public and private over a period of many + years, but particular thanks go to + + Jaap Akkerhuis, + Steve Bellovin, + Dan Bernstein, + Randy Bush, + Steve Crocker, + Olafur Gudmundsson, + Russ Housley, + Rip Loomis, + Allison Mankin, + Paul Mockapetris, + Thomas Narten + Mans Nilsson, + Pekka Savola, + Paul Vixie, + Xunhua Wang, + + + +Atkins & Austein Informational [Page 13] + +RFC 3833 DNS Threat Analysis August 2004 + + + and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working + groups whose names and contributions the authors have forgotten, none + of whom are responsible for what the authors did with their ideas. + + As with any work of this nature, the authors of this note acknowledge + that we are standing on the toes of those who have gone before us. + Readers interested in this subject may also wish to read + [Bellovin95], [Schuba93], and [Vixie95]. + +Normative 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. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, October 1989. + + [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. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for + DNS (TSIG)", RFC 2845, May 2000. + + [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS + (TKEY RR)", RFC 2930, September 2000. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC2535] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + + + + + + + + + + +Atkins & Austein Informational [Page 14] + +RFC 3833 DNS Threat Analysis August 2004 + + +Informative References + + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC + Text on Security Considerations", BCP 72, RFC 3552, July + 2003. + + [Bellovin95] Bellovin, S., "Using the Domain Name System for System + Break-Ins", Proceedings of the Fifth Usenix Unix + Security Symposium, June 1995. + + [Galvin93] Design team meeting summary message posted to dns- + security@tis.com mailing list by Jim Galvin on 19 + November 1993. + + [Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name + System Protocol", Master's thesis, Purdue University + Department of Computer Sciences, August 1993. + + [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of + the Fifth Usenix Unix Security Symposium, June 1995. + +Authors' Addresses + + Derek Atkins + IHTFP Consulting, Inc. + 6 Farragut Ave + Somerville, MA 02144 + USA + + EMail: derek@ihtfp.com + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + + + + + + + + + + +Atkins & Austein Informational [Page 15] + +RFC 3833 DNS Threat Analysis August 2004 + + +Full 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. + + 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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Atkins & Austein Informational [Page 16] + diff --git a/dist/bind/doc/rfc/rfc3845.txt b/dist/bind/doc/rfc/rfc3845.txt new file mode 100644 index 00000000000..9887a20af0b --- /dev/null +++ b/dist/bind/doc/rfc/rfc3845.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group J. Schlyter, Ed. +Request for Comments: 3845 August 2004 +Updates: 3755, 2535 +Category: Standards Track + + + DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document redefines the wire format of the "Type Bit Map" field + in the DNS NextSECure (NSEC) resource record RDATA format to cover + the full resource record (RR) type space. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 2 + 2.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . 3 + 2.1.1. The Next Domain Name Field . . . . . . . . . . . 3 + 2.1.2. The List of Type Bit Map(s) Field . . . . . . . 3 + 2.1.3. Inclusion of Wildcard Names in NSEC RDATA . . . 4 + 2.2. The NSEC RR Presentation Format . . . . . . . . . . . . 4 + 2.3. NSEC RR Example . . . . . . . . . . . . . . . . . . . . 5 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 + 5.2. Informative References . . . . . . . . . . . . . . . . . 6 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 + 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 + + + + + + + +Schlyter, Ed. Standards Track [Page 1] + +RFC 3845 DNSSEC NSEC RDATA Format August 2004 + + +1. Introduction + + The DNS [6][7] NSEC [5] Resource Record (RR) is used for + authenticated proof of the non-existence of DNS owner names and + types. The NSEC RR is based on the NXT RR as described in RFC 2535 + [2], and is similar except for the name and typecode. The RDATA + format for the NXT RR has the limitation in that the RDATA could only + carry information about the existence of the first 127 types. RFC + 2535 did reserve a bit to specify an extension mechanism, but the + mechanism was never actually defined. + + In order to avoid needing to develop an extension mechanism into a + deployed base of DNSSEC aware servers and resolvers once the first + 127 type codes are allocated, this document redefines the wire format + of the "Type Bit Map" field in the NSEC RDATA to cover the full RR + type space. + + This document introduces a new format for the type bit map. The + properties of the type bit map format are that it can cover the full + possible range of typecodes, that it is relatively economical in the + amount of space it uses for the common case of a few types with an + owner name, that it can represent owner names with all possible types + present in packets of approximately 8.5 kilobytes, and that the + representation is simple to implement. Efficient searching of the + type bitmap for the presence of certain types is not a requirement. + + For convenience and completeness, this document presents the syntax + and semantics for the NSEC RR based on the specification in RFC 2535 + [2] and as updated by RFC 3755 [5], thereby not introducing changes + except for the syntax of the type bit map. + + This document updates RFC 2535 [2] and RFC 3755 [5]. + + 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 BCP 14, RFC 2119 [1]. + +2. The NSEC Resource Record + + The NSEC resource record lists two separate things: the owner name of + the next RRset in the canonical ordering of the zone, and the set of + RR types present at the NSEC RR's owner name. The complete set of + NSEC RRs in a zone indicate which RRsets exist in a zone, and form a + chain of owner names in the zone. This information is used to + provide authenticated denial of existence for DNS data, as described + in RFC 2535 [2]. + + The type value for the NSEC RR is 47. + + + +Schlyter, Ed. Standards Track [Page 2] + +RFC 3845 DNSSEC NSEC RDATA Format August 2004 + + + The NSEC RR RDATA format is class independent and defined for all + classes. + + The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching [8]. + +2.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 / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / List of Type Bit Map(s) / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.1.1. The Next Domain Name Field + + The Next Domain Name field contains the owner name of the next RR in + the canonical ordering of the zone. The value of the Next Domain + Name field in the last NSEC record in the zone is the name of the + zone apex (the owner name of the zone's SOA RR). + + A sender MUST NOT use DNS name compression on the Next Domain Name + field when transmitting an NSEC RR. + + Owner names of RRsets that are 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. + +2.1.2. The List of Type Bit Map(s) Field + + 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. + + Window blocks are present in the NSEC RR RDATA in increasing + numerical order. + + "|" denotes concatenation + + Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + + + + +Schlyter, Ed. Standards Track [Page 3] + +RFC 3845 DNSSEC NSEC RDATA Format August 2004 + + + 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, and bit 2 to RR type 258. If a bit is + set to 1, it indicates that an RRset of that type is present for the + NSEC RR's owner name. If a bit is set to 0, it indicates that no + RRset of that type is present for the NSEC RR's owner name. + + Since bit 0 in window block 0 refers to the non-existing RR type 0, + it MUST be set to 0. After verification, the validator MUST ignore + the value of bit 0 in window block 0. + + Bits representing Meta-TYPEs or QTYPEs, as specified in RFC 2929 [3] + (section 3.1), or within the range reserved for assignment only to + QTYPEs and Meta-TYPEs MUST be set to 0, 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 + interpreted as zero octets. + +2.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. + RFC 2535 [2] describes the impact of wildcards on authenticated + denial of existence. + +2.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 List of Type Bit Map(s) Field is represented as a sequence of RR + type mnemonics. When the mnemonic is not known, the TYPE + representation as described in RFC 3597 [4] (section 5) MUST be used. + + + + + + + + +Schlyter, Ed. Standards Track [Page 4] + +RFC 3845 DNSSEC NSEC RDATA Format August 2004 + + +2.3. NSEC RR Example + + The following NSEC RR identifies the RRsets associated with + alfa.example.com. and 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: + + 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 resolver can authenticate this NSEC record, it + could be used to prove that beta.example.com does not exist, or could + be used to prove that there is no AAAA record associated with + alfa.example.com. Authenticated denial of existence is discussed in + RFC 2535 [2]. + +3. IANA Considerations + + This document introduces no new IANA considerations, because all of + the protocol parameters used in this document have already been + assigned by RFC 3755 [5]. + +4. Security Considerations + + The update of the RDATA format and encoding does not affect the + security of the use of NSEC RRs. + + + + + + + + + +Schlyter, Ed. Standards Track [Page 5] + +RFC 3845 DNSSEC NSEC RDATA Format August 2004 + + +5. References + +5.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [3] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain + Name System (DNS) IANA Considerations", BCP 42, RFC 2929, + September 2000. + + [4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) + Types", RFC 3597, September 2003. + + [5] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer + (DS)", RFC 3755, May 2004. + +5.2. Informative References + + [6] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [7] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC + 2308, March 1998. + +6. Acknowledgements + + The encoding described in this document was initially proposed by + Mark Andrews. Other encodings where proposed by David Blacka and + Michael Graff. + +7. Author's Address + + Jakob Schlyter (editor) + NIC-SE + Box 5774 + Stockholm SE-114 87 + Sweden + + EMail: jakob@nic.se + URI: http://www.nic.se/ + + + + +Schlyter, Ed. Standards Track [Page 6] + +RFC 3845 DNSSEC NSEC RDATA Format August 2004 + + +8. Full 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. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE + 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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Schlyter, Ed. Standards Track [Page 7] + diff --git a/dist/bind/lib/bind/Makefile.in b/dist/bind/lib/bind/Makefile.in index 5ce2fa32c18..8d39bc5a02c 100644 --- a/dist/bind/lib/bind/Makefile.in +++ b/dist/bind/lib/bind/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.12.2.5.2.4 2004/03/06 08:13:21 marka Exp +# Id: Makefile.in,v 1.12.2.5.2.5 2004/07/20 07:01:56 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -100,7 +100,7 @@ libbind.@SA@: ${OBJS} libbind.la: ${OBJS} ${LIBTOOL_MODE_LINK} \ - ${CC} ${ALL_CFLAGS} -o libbind.la -rpath ${libdir} \ + ${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libbind.la -rpath ${libdir} \ -version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \ ${OBJS} ${LIBS} diff --git a/dist/bind/lib/bind/api b/dist/bind/lib/bind/api index c4b9059729e..3a72afa2cde 100644 --- a/dist/bind/lib/bind/api +++ b/dist/bind/lib/bind/api @@ -1,3 +1,3 @@ LIBINTERFACE = 3 -LIBREVISION = 2 +LIBREVISION = 7 LIBAGE = 0 diff --git a/dist/bind/lib/bind/configure b/dist/bind/lib/bind/configure index dd7cddb6f34..54c6c1097b2 100644 --- a/dist/bind/lib/bind/configure +++ b/dist/bind/lib/bind/configure @@ -1,5 +1,5 @@ #! /bin/sh -# From configure.in Revision: 1.83.2.5.2.1 . +# From configure.in Revision: 1.83.2.5.2.3 . # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.59. # @@ -464,7 +464,7 @@ ac_includes_default="\ # include <unistd.h> #endif" -ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_NEEDSYSSELECTH WANT_IRS_GR WANT_IRS_GR_OBJS WANT_IRS_PW WANT_IRS_PW_OBJS WANT_IRS_NIS WANT_IRS_NIS_OBJS WANT_IRS_NISGR_OBJS WANT_IRS_NISPW_OBJS WANT_IRS_DBPW_OBJS ALWAYS_DEFINES DO_PTHREADS WANT_IRS_THREADSGR_OBJS WANT_IRS_THREADSPW_OBJS WANT_IRS_THREADS_OBJS ISC_THREAD_DIR DAEMON_OBJS NEED_DAEMON STRSEP_OBJS NEED_STRSEP NEED_STRERROR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK HAS_INET6_STRUCTS ISC_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H HAS_IN_ADDR6 NEED_IN6ADDR_ANY ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C HAVE_SIN6_SCOPE_ID HAVE_SOCKADDR_STORAGE ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON HAVE_SA_LEN HAVE_MINIMUM_IFREQ BSD_COMP SOLARIS_BITTYPES USE_FIONBIO_IOCTL PORT_DIR PORT_INCLUDE ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO NEED_PSELECT NEED_GETTIMEOFDAY HAVE_STRNDUP ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS USE_SYSERROR_LIST ISC_PLATFORM_QUADFORMAT ISC_SOCKLEN_T GETGROUPLIST_ARGS NET_R_ARGS NET_R_BAD NET_R_COPY NET_R_COPY_ARGS NET_R_OK NET_R_SETANSWER NET_R_RETURN GETNETBYADDR_ADDR_T NETENT_DATA NET_R_ENT_ARGS NET_R_SET_RESULT NET_R_SET_RETURN NET_R_END_RESULT NET_R_END_RETURN GROUP_R_ARGS GROUP_R_BAD GROUP_R_OK GROUP_R_RETURN GROUP_R_END_RESULT GROUP_R_END_RETURN GROUP_R_ENT_ARGS GROUP_R_SET_RESULT GROUP_R_SET_RETURN HOST_R_ARGS HOST_R_BAD HOST_R_COPY HOST_R_COPY_ARGS HOST_R_ERRNO HOST_R_OK HOST_R_RETURN HOST_R_SETANSWER HOSTENT_DATA HOST_R_END_RESULT HOST_R_END_RETURN HOST_R_ENT_ARGS HOST_R_SET_RESULT HOST_R_SET_RETURN SETPWENT_VOID SETGRENT_VOID NGR_R_ARGS NGR_R_BAD NGR_R_COPY NGR_R_COPY_ARGS NGR_R_OK NGR_R_RETURN NGR_R_PRIVATE NGR_R_END_RESULT NGR_R_END_RETURN NGR_R_ENT_ARGS NGR_R_SET_RESULT NGR_R_SET_RETURN PROTO_R_ARGS PROTO_R_BAD PROTO_R_COPY PROTO_R_COPY_ARGS PROTO_R_OK PROTO_R_SETANSWER PROTO_R_RETURN PROTO_R_END_RESULT PROTO_R_END_RETURN PROTO_R_ENT_ARGS PROTO_R_SET_RESULT PROTO_R_SET_RETURN PASS_R_ARGS PASS_R_BAD PASS_R_COPY PASS_R_COPY_ARGS PASS_R_OK PASS_R_RETURN PASS_R_END_RESULT PASS_R_END_RETURN PASS_R_ENT_ARGS PASS_R_SET_RESULT PASS_R_SET_RETURN SERV_R_ARGS SERV_R_BAD SERV_R_COPY SERV_R_COPY_ARGS SERV_R_OK SERV_R_SETANSWER SERV_R_RETURN SERV_R_END_RESULT SERV_R_END_RETURN SERV_R_ENT_ARGS SERV_R_SET_RESULT SERV_R_SET_RETURN SETNETGRENT_ARGS INNETGR_ARGS ISC_PLATFORM_BRACEPTHREADONCEINIT BIND9_TOP_BUILDDIR BIND9_VERSION LIBOBJS LTLIBOBJS' +ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_NEEDSYSSELECTH WANT_IRS_GR WANT_IRS_GR_OBJS WANT_IRS_PW WANT_IRS_PW_OBJS WANT_IRS_NIS WANT_IRS_NIS_OBJS WANT_IRS_NISGR_OBJS WANT_IRS_NISPW_OBJS WANT_IRS_DBPW_OBJS ALWAYS_DEFINES DO_PTHREADS WANT_IRS_THREADSGR_OBJS WANT_IRS_THREADSPW_OBJS WANT_IRS_THREADS_OBJS USE_IFNAMELINKID ISC_THREAD_DIR DAEMON_OBJS NEED_DAEMON STRSEP_OBJS NEED_STRSEP NEED_STRERROR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK HAS_INET6_STRUCTS ISC_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H HAS_IN_ADDR6 NEED_IN6ADDR_ANY ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C HAVE_SIN6_SCOPE_ID HAVE_SOCKADDR_STORAGE ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON HAVE_SA_LEN HAVE_MINIMUM_IFREQ BSD_COMP SOLARIS_BITTYPES USE_FIONBIO_IOCTL PORT_DIR PORT_INCLUDE ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO NEED_PSELECT NEED_GETTIMEOFDAY HAVE_STRNDUP ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS USE_SYSERROR_LIST ISC_PLATFORM_QUADFORMAT ISC_SOCKLEN_T GETGROUPLIST_ARGS NET_R_ARGS NET_R_BAD NET_R_COPY NET_R_COPY_ARGS NET_R_OK NET_R_SETANSWER NET_R_RETURN GETNETBYADDR_ADDR_T NETENT_DATA NET_R_ENT_ARGS NET_R_SET_RESULT NET_R_SET_RETURN NET_R_END_RESULT NET_R_END_RETURN GROUP_R_ARGS GROUP_R_BAD GROUP_R_OK GROUP_R_RETURN GROUP_R_END_RESULT GROUP_R_END_RETURN GROUP_R_ENT_ARGS GROUP_R_SET_RESULT GROUP_R_SET_RETURN HOST_R_ARGS HOST_R_BAD HOST_R_COPY HOST_R_COPY_ARGS HOST_R_ERRNO HOST_R_OK HOST_R_RETURN HOST_R_SETANSWER HOSTENT_DATA HOST_R_END_RESULT HOST_R_END_RETURN HOST_R_ENT_ARGS HOST_R_SET_RESULT HOST_R_SET_RETURN SETPWENT_VOID SETGRENT_VOID NGR_R_ARGS NGR_R_BAD NGR_R_COPY NGR_R_COPY_ARGS NGR_R_OK NGR_R_RETURN NGR_R_PRIVATE NGR_R_END_RESULT NGR_R_END_RETURN NGR_R_ENT_ARGS NGR_R_SET_RESULT NGR_R_SET_RETURN PROTO_R_ARGS PROTO_R_BAD PROTO_R_COPY PROTO_R_COPY_ARGS PROTO_R_OK PROTO_R_SETANSWER PROTO_R_RETURN PROTO_R_END_RESULT PROTO_R_END_RETURN PROTO_R_ENT_ARGS PROTO_R_SET_RESULT PROTO_R_SET_RETURN PASS_R_ARGS PASS_R_BAD PASS_R_COPY PASS_R_COPY_ARGS PASS_R_OK PASS_R_RETURN PASS_R_END_RESULT PASS_R_END_RETURN PASS_R_ENT_ARGS PASS_R_SET_RESULT PASS_R_SET_RETURN SERV_R_ARGS SERV_R_BAD SERV_R_COPY SERV_R_COPY_ARGS SERV_R_OK SERV_R_SETANSWER SERV_R_RETURN SERV_R_END_RESULT SERV_R_END_RETURN SERV_R_ENT_ARGS SERV_R_SET_RESULT SERV_R_SET_RETURN SETNETGRENT_ARGS INNETGR_ARGS ISC_PLATFORM_BRACEPTHREADONCEINIT BIND9_TOP_BUILDDIR BIND9_VERSION LIBOBJS LTLIBOBJS' ac_subst_files='BIND9_INCLUDES BIND9_MAKE_RULES LIBBIND_API' # Initialize some variables set by options. @@ -5716,6 +5716,104 @@ fi +echo "$as_me:$LINENO: checking for if_nametoindex" >&5 +echo $ECHO_N "checking for if_nametoindex... $ECHO_C" >&6 +if test "${ac_cv_func_if_nametoindex+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ +/* Define if_nametoindex to an innocuous variant, in case <limits.h> declares if_nametoindex. + For example, HP-UX 11i <limits.h> declares gettimeofday. */ +#define if_nametoindex innocuous_if_nametoindex + +/* System header to define __stub macros and hopefully few prototypes, + which can conflict with char if_nametoindex (); below. + Prefer <limits.h> to <assert.h> if __STDC__ is defined, since + <limits.h> exists even on freestanding compilers. */ + +#ifdef __STDC__ +# include <limits.h> +#else +# include <assert.h> +#endif + +#undef if_nametoindex + +/* Override any gcc2 internal prototype to avoid an error. */ +#ifdef __cplusplus +extern "C" +{ +#endif +/* We use char because int might match the return type of a gcc2 + builtin and then its argument prototype would still apply. */ +char if_nametoindex (); +/* The GNU C library defines this for functions which it implements + to always fail with ENOSYS. Some functions are actually named + something starting with __ and the normal name is an alias. */ +#if defined (__stub_if_nametoindex) || defined (__stub___if_nametoindex) +choke me +#else +char (*f) () = if_nametoindex; +#endif +#ifdef __cplusplus +} +#endif + +int +main () +{ +return f != if_nametoindex; + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext conftest$ac_exeext +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 + (eval $ac_link) 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; } && + { ac_try='test -s conftest$ac_exeext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_cv_func_if_nametoindex=yes +else + echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + +ac_cv_func_if_nametoindex=no +fi +rm -f conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext +fi +echo "$as_me:$LINENO: result: $ac_cv_func_if_nametoindex" >&5 +echo "${ECHO_T}$ac_cv_func_if_nametoindex" >&6 +if test $ac_cv_func_if_nametoindex = yes; then + USE_IFNAMELINKID="#define USE_IFNAMELINKID 1" +else + USE_IFNAMELINKID="#undef USE_IFNAMELINKID" +fi + + + ISC_THREAD_DIR=$thread_dir @@ -7197,7 +7295,7 @@ ia64-*-hpux*) ;; *-*-irix6*) # Find out which ABI we are using. - echo '#line 7200 "configure"' > conftest.$ac_ext + echo '#line 7298 "configure"' > conftest.$ac_ext if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 (eval $ac_compile) 2>&5 ac_status=$? @@ -8187,7 +8285,7 @@ fi # Provide some information about the compiler. -echo "$as_me:8190:" \ +echo "$as_me:8288:" \ "checking for Fortran 77 compiler version" >&5 ac_compiler=`set X $ac_compile; echo $2` { (eval echo "$as_me:$LINENO: \"$ac_compiler --version </dev/null >&5\"") >&5 @@ -9225,11 +9323,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:9228: $lt_compile\"" >&5) + (eval echo "\"\$as_me:9326: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:9232: \$? = $ac_status" >&5 + echo "$as_me:9330: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -9458,11 +9556,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:9461: $lt_compile\"" >&5) + (eval echo "\"\$as_me:9559: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:9465: \$? = $ac_status" >&5 + echo "$as_me:9563: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -9518,11 +9616,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:9521: $lt_compile\"" >&5) + (eval echo "\"\$as_me:9619: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:9525: \$? = $ac_status" >&5 + echo "$as_me:9623: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -11702,7 +11800,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 11705 "configure" +#line 11803 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -11800,7 +11898,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 11803 "configure" +#line 11901 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -13983,11 +14081,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:13986: $lt_compile\"" >&5) + (eval echo "\"\$as_me:14084: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:13990: \$? = $ac_status" >&5 + echo "$as_me:14088: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -14043,11 +14141,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:14046: $lt_compile\"" >&5) + (eval echo "\"\$as_me:14144: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:14050: \$? = $ac_status" >&5 + echo "$as_me:14148: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -15404,7 +15502,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 15407 "configure" +#line 15505 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -15502,7 +15600,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 15505 "configure" +#line 15603 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -16329,11 +16427,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:16332: $lt_compile\"" >&5) + (eval echo "\"\$as_me:16430: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:16336: \$? = $ac_status" >&5 + echo "$as_me:16434: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -16389,11 +16487,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:16392: $lt_compile\"" >&5) + (eval echo "\"\$as_me:16490: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:16396: \$? = $ac_status" >&5 + echo "$as_me:16494: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -18427,11 +18525,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:18430: $lt_compile\"" >&5) + (eval echo "\"\$as_me:18528: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:18434: \$? = $ac_status" >&5 + echo "$as_me:18532: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -18660,11 +18758,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:18663: $lt_compile\"" >&5) + (eval echo "\"\$as_me:18761: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:18667: \$? = $ac_status" >&5 + echo "$as_me:18765: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -18720,11 +18818,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:18723: $lt_compile\"" >&5) + (eval echo "\"\$as_me:18821: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:18727: \$? = $ac_status" >&5 + echo "$as_me:18825: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -20904,7 +21002,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 20907 "configure" +#line 21005 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -21002,7 +21100,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 21005 "configure" +#line 21103 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -31057,6 +31155,7 @@ s,@DO_PTHREADS@,$DO_PTHREADS,;t t s,@WANT_IRS_THREADSGR_OBJS@,$WANT_IRS_THREADSGR_OBJS,;t t s,@WANT_IRS_THREADSPW_OBJS@,$WANT_IRS_THREADSPW_OBJS,;t t s,@WANT_IRS_THREADS_OBJS@,$WANT_IRS_THREADS_OBJS,;t t +s,@USE_IFNAMELINKID@,$USE_IFNAMELINKID,;t t s,@ISC_THREAD_DIR@,$ISC_THREAD_DIR,;t t s,@DAEMON_OBJS@,$DAEMON_OBJS,;t t s,@NEED_DAEMON@,$NEED_DAEMON,;t t diff --git a/dist/bind/lib/bind/configure.in b/dist/bind/lib/bind/configure.in index 16709a6c9d6..7e9d7c1c748 100644 --- a/dist/bind/lib/bind/configure.in +++ b/dist/bind/lib/bind/configure.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -AC_REVISION($Revision: 1.1.1.1 $) +AC_REVISION($Revision: 1.1.1.2 $) AC_INIT(resolv/herror.c) AC_PREREQ(2.13) @@ -526,6 +526,11 @@ AC_SUBST(WANT_IRS_THREADSGR_OBJS) AC_SUBST(WANT_IRS_THREADSPW_OBJS) AC_SUBST(WANT_IRS_THREADS_OBJS) +AC_CHECK_FUNC(if_nametoindex, + [USE_IFNAMELINKID="#define USE_IFNAMELINKID 1"], + [USE_IFNAMELINKID="#undef USE_IFNAMELINKID"]) +AC_SUBST(USE_IFNAMELINKID) + ISC_THREAD_DIR=$thread_dir AC_SUBST(ISC_THREAD_DIR) diff --git a/dist/bind/lib/bind/include/arpa/nameser_compat.h b/dist/bind/lib/bind/include/arpa/nameser_compat.h index 03abb91ff4b..34b4875bb7d 100644 --- a/dist/bind/lib/bind/include/arpa/nameser_compat.h +++ b/dist/bind/lib/bind/include/arpa/nameser_compat.h @@ -1,4 +1,4 @@ -/* $NetBSD: nameser_compat.h,v 1.1.1.1 2004/05/17 23:44:41 christos Exp $ */ +/* $NetBSD: nameser_compat.h,v 1.1.1.2 2004/11/06 23:55:25 christos Exp $ */ /* Copyright (c) 1983, 1989 * The Regents of the University of California. All rights reserved. @@ -34,7 +34,7 @@ /* * from nameser.h 8.1 (Berkeley) 6/2/93 - * Id: nameser_compat.h,v 1.1.2.3.4.1 2004/03/09 08:33:30 marka Exp + * Id: nameser_compat.h,v 1.1.2.3.4.2 2004/07/01 04:43:41 marka Exp */ #ifndef _ARPA_NAMESER_COMPAT_ @@ -67,7 +67,7 @@ defined(__hppa) || defined(__hp9000) || \ defined(__hp9000s300) || defined(__hp9000s700) || \ defined(__hp3000s900) || defined(__hpux) || defined(MPE) || \ - defined (BIT_ZERO_ON_LEFT) || defined(m68k) || \ + defined (BIT_ZERO_ON_LEFT) || defined(m68k) || defined(__sparc) || \ (defined(__Lynx__) && \ (defined(__68k__) || defined(__sparc__) || defined(__powerpc__))) #define BYTE_ORDER BIG_ENDIAN diff --git a/dist/bind/lib/bind/include/resolv.h b/dist/bind/lib/bind/include/resolv.h index a559b38b91c..940ef62f878 100644 --- a/dist/bind/lib/bind/include/resolv.h +++ b/dist/bind/lib/bind/include/resolv.h @@ -1,4 +1,4 @@ -/* $NetBSD: resolv.h,v 1.1.1.1 2004/05/17 23:44:41 christos Exp $ */ +/* $NetBSD: resolv.h,v 1.1.1.2 2004/11/06 23:55:25 christos Exp $ */ /* * Copyright (c) 1983, 1987, 1989 @@ -52,7 +52,7 @@ /* * @(#)resolv.h 8.1 (Berkeley) 6/2/93 - * Id: resolv.h,v 1.7.2.11.4.1 2004/03/09 08:33:29 marka Exp + * Id: resolv.h,v 1.7.2.11.4.2 2004/06/25 00:41:05 marka Exp */ #ifndef _RESOLV_H_ @@ -256,6 +256,7 @@ union res_sockaddr_union { #define RES_BLAST 0x00020000 /* blast all recursive servers */ #define RES_NOTLDQUERY 0x00100000 /* don't unqualified name as a tld */ #define RES_USE_DNSSEC 0x00200000 /* use DNSSEC using OK bit in OPT */ +/* #define RES_DEBUG2 0x00400000 */ /* nslookup internal */ /* KAME extensions: use higher bit to avoid conflict with ISC use */ #define RES_USE_DNAME 0x10000000 /* use DNAME */ #define RES_USE_EDNS0 0x40000000 /* use EDNS0 if configured */ diff --git a/dist/bind/lib/bind/irs/dns_ho.c b/dist/bind/lib/bind/irs/dns_ho.c index 554cd8a569e..eeaf984f42b 100644 --- a/dist/bind/lib/bind/irs/dns_ho.c +++ b/dist/bind/lib/bind/irs/dns_ho.c @@ -1,4 +1,4 @@ -/* $NetBSD: dns_ho.c,v 1.1.1.1 2004/05/17 23:44:42 christos Exp $ */ +/* $NetBSD: dns_ho.c,v 1.1.1.2 2004/11/06 23:55:26 christos Exp $ */ /* * Copyright (c) 1985, 1988, 1993 @@ -54,7 +54,7 @@ /* BIND Id: gethnamaddr.c,v 8.15 1996/05/22 04:56:30 vixie Exp $ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "Id: dns_ho.c,v 1.5.2.7.4.3 2004/03/17 01:13:34 marka Exp"; +static const char rcsid[] = "Id: dns_ho.c,v 1.5.2.7.4.5 2004/08/24 00:32:15 marka Exp"; #endif /* LIBC_SCCS and not lint */ /* Imports. */ @@ -416,38 +416,44 @@ ho_byaddr(struct irs_ho *this, const void *addr, int len, int af) break; case AF_INET6: if (q->action != RESTGT_IGNORE) { + const char *nibsuff = res_get_nibblesuffix(pvt->res); qp = q->qname; for (n = IN6ADDRSZ - 1; n >= 0; n--) { i = SPRINTF((qp, "%x.%x.", uaddr[n] & 0xf, (uaddr[n] >> 4) & 0xf)); - if (i < 0) + if (i != 4) abort(); qp += i; } -#ifdef HAVE_STRLCAT - strlcat(q->qname, res_get_nibblesuffix(pvt->res), - sizeof(q->qname)); -#else - strcpy(qp, res_get_nibblesuffix(pvt->res)); -#endif + if (strlen(q->qname) + strlen(nibsuff) + 1 > + sizeof q->qname) { + errno = ENAMETOOLONG; + RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL); + hp = NULL; + goto cleanup; + } + strcpy(qp, nibsuff); /* (checked) */ } if (q2->action != RESTGT_IGNORE) { + const char *nibsuff2 = res_get_nibblesuffix2(pvt->res); qp = q2->qname; for (n = IN6ADDRSZ - 1; n >= 0; n--) { i = SPRINTF((qp, "%x.%x.", uaddr[n] & 0xf, (uaddr[n] >> 4) & 0xf)); - if (i < 0) + if (i != 4) abort(); qp += i; } -#ifdef HAVE_STRLCAT - strlcat(q->qname, res_get_nibblesuffix2(pvt->res), - sizeof(q->qname)); -#else - strcpy(qp, res_get_nibblesuffix2(pvt->res)); -#endif + if (strlen(q2->qname) + strlen(nibsuff2) + 1 > + sizeof q2->qname) { + errno = ENAMETOOLONG; + RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL); + hp = NULL; + goto cleanup; + } + strcpy(qp, nibsuff2); /* (checked) */ } break; default: @@ -822,11 +828,7 @@ gethostans(struct irs_ho *this, had_error++; continue; } -#ifdef HAVE_STRLCPY - strlcpy(bp, tbuf, ep - bp); -#else - strcpy(bp, tbuf); -#endif + strcpy(bp, tbuf); /* (checked) */ pvt->host.h_name = bp; hname = bp; bp += n; @@ -858,11 +860,7 @@ gethostans(struct irs_ho *this, had_error++; continue; } -#ifdef HAVE_STRLCPY - strlcpy(bp, tbuf, ep - bp); -#else - strcpy(bp, tbuf); -#endif + strcpy(bp, tbuf); /* (checked) */ tname = bp; bp += n; continue; @@ -998,11 +996,7 @@ gethostans(struct irs_ho *this, n = strlen(qname) + 1; /* for the \0 */ if (n > (ep - bp) || n >= MAXHOSTNAMELEN) goto no_recovery; -#ifdef HAVE_STRLCPY - strlcpy(bp, qname, ep - bp); -#else - strcpy(bp, qname); -#endif + strcpy(bp, qname); /* (checked) */ pvt->host.h_name = bp; bp += n; } diff --git a/dist/bind/lib/bind/irs/dns_nw.c b/dist/bind/lib/bind/irs/dns_nw.c index 51d775121a5..38513776d41 100644 --- a/dist/bind/lib/bind/irs/dns_nw.c +++ b/dist/bind/lib/bind/irs/dns_nw.c @@ -1,4 +1,4 @@ -/* $NetBSD: dns_nw.c,v 1.1.1.1 2004/05/17 23:44:42 christos Exp $ */ +/* $NetBSD: dns_nw.c,v 1.1.1.2 2004/11/06 23:55:26 christos Exp $ */ /* * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC") @@ -18,7 +18,7 @@ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "Id: dns_nw.c,v 1.3.2.4.4.2 2004/03/17 00:29:48 marka Exp"; +static const char rcsid[] = "Id: dns_nw.c,v 1.3.2.4.4.3 2004/05/17 07:48:56 marka Exp"; #endif /* LIBC_SCCS and not lint */ /* Imports. */ @@ -351,12 +351,7 @@ get1101answer(struct irs_nw *this, RES_SET_H_ERRNO(pvt->res, NO_RECOVERY); return (NULL); } -#ifdef HAVE_STRLCPY - strlcpy(bp, name, ep - bp); - pvt->net.n_name = bp; -#else - pvt->net.n_name = strcpy(bp, name); -#endif + pvt->net.n_name = strcpy(bp, name); /* (checked) */ bp += n; } break; diff --git a/dist/bind/lib/bind/irs/gen_gr.c b/dist/bind/lib/bind/irs/gen_gr.c index 0499e8e8ea4..91a305d2fb9 100644 --- a/dist/bind/lib/bind/irs/gen_gr.c +++ b/dist/bind/lib/bind/irs/gen_gr.c @@ -1,4 +1,4 @@ -/* $NetBSD: gen_gr.c,v 1.1.1.1 2004/05/17 23:44:42 christos Exp $ */ +/* $NetBSD: gen_gr.c,v 1.1.1.2 2004/11/06 23:55:26 christos Exp $ */ /* * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC") @@ -18,7 +18,7 @@ */ #if !defined(LINT) && !defined(CODECENTER) -static const char rcsid[] = "Id: gen_gr.c,v 1.4.2.1.4.1 2004/03/09 08:33:35 marka Exp"; +static const char rcsid[] = "Id: gen_gr.c,v 1.4.2.1.4.2 2004/05/17 07:48:56 marka Exp"; #endif /* Imports */ @@ -85,7 +85,7 @@ static void gr_res_set(struct irs_gr *, struct __res_state *, void (*)(void *)); -static void grmerge(struct irs_gr *gr, const struct group *src, +static int grmerge(struct irs_gr *gr, const struct group *src, int preserve); static int countvec(char **vec); @@ -94,6 +94,10 @@ static int countnew(char **old, char **new); static size_t sizenew(char **old, char **new); static int newgid(int, gid_t *, gid_t); +/* Macros */ + +#define FREE_IF(x) do { if ((x) != NULL) { free(x); (x) = NULL; } } while (0) + /* Public */ struct irs_gr * @@ -173,7 +177,8 @@ gr_byname(struct irs_gr *this, const char *name) { gr = rule->inst->gr; tval = (*gr->byname)(gr, name); if (tval) { - grmerge(this, tval, dirty++); + if (!grmerge(this, tval, dirty++)) + return (NULL); if (!(rule->flags & IRS_MERGE)) break; } else { @@ -199,7 +204,8 @@ gr_bygid(struct irs_gr *this, gid_t gid) { gr = rule->inst->gr; tval = (*gr->bygid)(gr, gid); if (tval) { - grmerge(this, tval, dirty++); + if (!grmerge(this, tval, dirty++)) + return (NULL); if (!(rule->flags & IRS_MERGE)) break; } else { @@ -323,7 +329,7 @@ gr_res_set(struct irs_gr *this, struct __res_state *res, /* Private. */ -static void +static int grmerge(struct irs_gr *this, const struct group *src, int preserve) { struct pvt *pvt = (struct pvt *)this->private; char *cp, **m, **p, *oldmembuf, *ep; @@ -334,9 +340,9 @@ grmerge(struct irs_gr *this, const struct group *src, int preserve) { pvt->group.gr_gid = src->gr_gid; if (pvt->nmemb < 1) { m = malloc(sizeof *m); - if (!m) { + if (m == NULL) { /* No harm done, no work done. */ - return; + return (0); } pvt->group.gr_mem = m; pvt->nmemb = 1; @@ -353,9 +359,9 @@ grmerge(struct irs_gr *this, const struct group *src, int preserve) { n = ndst + nnew + 1; if ((size_t)n > pvt->nmemb) { m = realloc(pvt->group.gr_mem, n * sizeof *m); - if (!m) { + if (m == NULL) { /* No harm done, no work done. */ - return; + return (0); } pvt->group.gr_mem = m; pvt->nmemb = n; @@ -373,13 +379,13 @@ grmerge(struct irs_gr *this, const struct group *src, int preserve) { } if (n == 0) { /* No work to do. */ - return; + return (1); } used = preserve ? pvt->membufsize : 0; cp = malloc(used + n); - if (!cp) { + if (cp == NULL) { /* No harm done, no work done. */ - return; + return (0); } ep = cp + used + n; if (used != 0) @@ -403,12 +409,13 @@ grmerge(struct irs_gr *this, const struct group *src, int preserve) { if (isnew(pvt->group.gr_mem, *m)) { *p++ = cp; *p = NULL; -#ifdef HAVE_STRLCPY - strlcpy(cp, *m, ep - cp); -#else - strcpy(cp, *m); -#endif - cp += strlen(cp) + 1; + n = strlen(*m) + 1; + if (n > ep - cp) { + FREE_IF(oldmembuf); + return (0); + } + strcpy(cp, *m); /* (checked) */ + cp += n; } if (preserve) { pvt->group.gr_name = pvt->membuf + @@ -417,23 +424,26 @@ grmerge(struct irs_gr *this, const struct group *src, int preserve) { (pvt->group.gr_passwd - oldmembuf); } else { pvt->group.gr_name = cp; -#ifdef HAVE_STRLCPY - strlcpy(cp, src->gr_name, ep - cp); -#else - strcpy(cp, src->gr_name); -#endif - cp += strlen(src->gr_name) + 1; + n = strlen(src->gr_name) + 1; + if (n > ep - cp) { + FREE_IF(oldmembuf); + return (0); + } + strcpy(cp, src->gr_name); /* (checked) */ + cp += n; + pvt->group.gr_passwd = cp; -#ifdef HAVE_STRLCPY - strlcpy(cp, src->gr_passwd, ep - cp); -#else - strcpy(cp, src->gr_passwd); -#endif - cp += strlen(src->gr_passwd) + 1; + n = strlen(src->gr_passwd) + 1; + if (n > ep - cp) { + FREE_IF(oldmembuf); + return (0); + } + strcpy(cp, src->gr_passwd); /* (checked) */ + cp += n; } - if (oldmembuf != NULL) - free(oldmembuf); + FREE_IF(oldmembuf); INSIST(cp >= pvt->membuf && cp <= &pvt->membuf[pvt->membufsize]); + return (1); } static int diff --git a/dist/bind/lib/bind/irs/getaddrinfo.c b/dist/bind/lib/bind/irs/getaddrinfo.c index e4bb2ae8fba..bb80ca63ec2 100644 --- a/dist/bind/lib/bind/irs/getaddrinfo.c +++ b/dist/bind/lib/bind/irs/getaddrinfo.c @@ -1,4 +1,4 @@ -/* $NetBSD: getaddrinfo.c,v 1.1.1.1 2004/05/17 23:44:42 christos Exp $ */ +/* $NetBSD: getaddrinfo.c,v 1.1.1.2 2004/11/06 23:55:26 christos Exp $ */ /* $KAME: getaddrinfo.c,v 1.14 2001/01/06 09:41:15 jinmei Exp $ */ @@ -939,11 +939,7 @@ copy_ai(pai) free(ai); return NULL; } -#ifdef HAVE_STRLCPY - strlcpy(ai->ai_canonname, pai->ai_canonname, l); -#else - strncpy(ai->ai_canonname, pai->ai_canonname, l); -#endif + strcpy(ai->ai_canonname, pai->ai_canonname); /* (checked) */ } else { /* just to make sure */ ai->ai_canonname = NULL; @@ -1098,7 +1094,8 @@ ip6_str2scopeid(char *scope, struct sockaddr_in6 *sin6, return (0); #ifdef USE_IFNAMELINKID - if (IN6_IS_ADDR_LINKLOCAL(a6) || IN6_IS_ADDR_MC_LINKLOCAL(a6)) { + if (IN6_IS_ADDR_LINKLOCAL(a6) || IN6_IS_ADDR_MC_LINKLOCAL(a6) || + IN6_IS_ADDR_MC_NODELOCAL(a6)) { /* * Using interface names as link indices can be allowed * only when we can assume a one-to-one mappings between @@ -1106,6 +1103,7 @@ ip6_str2scopeid(char *scope, struct sockaddr_in6 *sin6, */ scopeid = if_nametoindex(scope); if (scopeid == 0) + goto trynumeric; *scopeidp = scopeid; return (1); } diff --git a/dist/bind/lib/bind/irs/gethostent_r.c b/dist/bind/lib/bind/irs/gethostent_r.c index 70fd6e8cc09..1985eb4842c 100644 --- a/dist/bind/lib/bind/irs/gethostent_r.c +++ b/dist/bind/lib/bind/irs/gethostent_r.c @@ -1,4 +1,4 @@ -/* $NetBSD: gethostent_r.c,v 1.1.1.1 2004/05/17 23:44:42 christos Exp $ */ +/* $NetBSD: gethostent_r.c,v 1.1.1.2 2004/11/06 23:55:26 christos Exp $ */ /* * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC") @@ -18,7 +18,7 @@ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "Id: gethostent_r.c,v 1.4.206.2 2004/04/22 03:32:06 marka Exp"; +static const char rcsid[] = "Id: gethostent_r.c,v 1.4.206.3 2004/09/01 02:03:07 marka Exp"; #endif /* LIBC_SCCS and not lint */ #include <port_before.h> @@ -49,7 +49,7 @@ gethostbyname_r(const char *name, struct hostent *hptr, HOST_R_ARGS) { HOST_R_ERRNO; #ifdef HOST_R_SETANSWER - if (he == NULL || (n = copy_hostent(he, hptr, HOST_R_COPY)) == 0) + if (he == NULL || (n = copy_hostent(he, hptr, HOST_R_COPY)) != 0) *answerp = NULL; else *answerp = hptr; @@ -74,7 +74,7 @@ gethostbyaddr_r(const char *addr, int len, int type, HOST_R_ERRNO; #ifdef HOST_R_SETANSWER - if (he == NULL || (n = copy_hostent(he, hptr, HOST_R_COPY)) == 0) + if (he == NULL || (n = copy_hostent(he, hptr, HOST_R_COPY)) != 0) *answerp = NULL; else *answerp = hptr; @@ -104,7 +104,7 @@ gethostent_r(struct hostent *hptr, HOST_R_ARGS) { HOST_R_ERRNO; #ifdef HOST_R_SETANSWER - if (he == NULL || (n = copy_hostent(he, hptr, HOST_R_COPY)) == 0) + if (he == NULL || (n = copy_hostent(he, hptr, HOST_R_COPY)) != 0) *answerp = NULL; else *answerp = hptr; diff --git a/dist/bind/lib/bind/irs/getnameinfo.c b/dist/bind/lib/bind/irs/getnameinfo.c index 757d3802ad4..4a51774e48e 100644 --- a/dist/bind/lib/bind/irs/getnameinfo.c +++ b/dist/bind/lib/bind/irs/getnameinfo.c @@ -1,4 +1,4 @@ -/* $NetBSD: getnameinfo.c,v 1.1.1.1 2004/05/17 23:44:43 christos Exp $ */ +/* $NetBSD: getnameinfo.c,v 1.1.1.2 2004/11/06 23:55:27 christos Exp $ */ /* * Issues to be discussed: @@ -156,7 +156,7 @@ getnameinfo(sa, salen, host, hostlen, serv, servlen, flags) switch (sa->sa_family) { case AF_INET: - if (ntohl(*(const u_long *)addr) >> IN_CLASSA_NSHIFT == 0) + if (ntohl(*(const u_int32_t *)addr) >> IN_CLASSA_NSHIFT == 0) flags |= NI_NUMERICHOST; break; case AF_INET6: diff --git a/dist/bind/lib/bind/irs/hesiod.c b/dist/bind/lib/bind/irs/hesiod.c index 672d5efda59..ef540e04ad4 100644 --- a/dist/bind/lib/bind/irs/hesiod.c +++ b/dist/bind/lib/bind/irs/hesiod.c @@ -1,7 +1,7 @@ -/* $NetBSD: hesiod.c,v 1.1.1.1 2004/05/17 23:44:43 christos Exp $ */ +/* $NetBSD: hesiod.c,v 1.1.1.2 2004/11/06 23:55:27 christos Exp $ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "Id: hesiod.c,v 1.1.2.1.4.2 2004/03/17 01:49:41 marka Exp"; +static const char rcsid[] = "Id: hesiod.c,v 1.1.2.1.4.3 2004/05/17 07:48:56 marka Exp"; #endif /* @@ -94,19 +94,14 @@ hesiod_init(void **context) { /* * Use compiled in defaults. */ - ctx->LHS = malloc(strlen(DEF_LHS)+1); - ctx->RHS = malloc(strlen(DEF_RHS)+1); - if (ctx->LHS == 0 || ctx->RHS == 0) { + ctx->LHS = malloc(strlen(DEF_LHS) + 1); + ctx->RHS = malloc(strlen(DEF_RHS) + 1); + if (ctx->LHS == NULL || ctx->RHS == NULL) { errno = ENOMEM; goto cleanup; } -#ifdef HAVE_STRLCPY - strlcpy(ctx->LHS, DEF_LHS, strlen(DEF_LHS) + 1); - strlcpy(ctx->RHS, DEF_RHS, strlen(DEF_RHS) + 1); -#else - strcpy(ctx->LHS, DEF_LHS); - strcpy(ctx->RHS, DEF_RHS); -#endif + strcpy(ctx->LHS, DEF_LHS); /* (checked) */ + strcpy(ctx->RHS, DEF_RHS); /* (checked) */ #else goto cleanup; #endif @@ -125,22 +120,10 @@ hesiod_init(void **context) { goto cleanup; } if (cp[0] == '.') { -#ifdef HAVE_STRLCPY - strlcpy(ctx->RHS, cp, RHSlen); -#else - strcpy(ctx->RHS, cp); -#endif + strcpy(ctx->RHS, cp); /* (checked) */ } else { -#ifdef HAVE_STRLCPY - strlcpy(ctx->RHS, ".", RHSlen); -#else - strcpy(ctx->RHS, "."); -#endif -#ifdef HAVE_STRLCAT - strlcat(ctx->RHS, cp, RHSlen); -#else - strcat(ctx->RHS, cp); -#endif + strcpy(ctx->RHS, "."); /* (checked) */ + strcat(ctx->RHS, cp); /* (checked) */ } } diff --git a/dist/bind/lib/bind/nameser/ns_name.c b/dist/bind/lib/bind/nameser/ns_name.c index fc86a33bed7..1a9dcb20740 100644 --- a/dist/bind/lib/bind/nameser/ns_name.c +++ b/dist/bind/lib/bind/nameser/ns_name.c @@ -1,4 +1,4 @@ -/* $NetBSD: ns_name.c,v 1.1.1.1 2004/05/17 23:44:46 christos Exp $ */ +/* $NetBSD: ns_name.c,v 1.1.1.2 2004/11/06 23:55:32 christos Exp $ */ /* * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC") @@ -18,7 +18,7 @@ */ #ifndef lint -static const char rcsid[] = "Id: ns_name.c,v 1.3.2.4.4.1 2004/03/09 08:33:44 marka Exp"; +static const char rcsid[] = "Id: ns_name.c,v 1.3.2.4.4.2 2004/05/04 03:27:47 marka Exp"; #endif #include "port_before.h" @@ -77,9 +77,11 @@ static int dn_find(const u_char *, const u_char *, const u_char * const *, const u_char * const *); static int encode_bitsring(const char **, const char *, - char **, char **, const char *); + unsigned char **, unsigned char **, + unsigned const char *); static int labellen(const u_char *); -static int decode_bitstring(const char **, char *, const char *); +static int decode_bitstring(const unsigned char **, + char *, const char *); /* Public. */ @@ -134,7 +136,7 @@ ns_name_ntop(const u_char *src, char *dst, size_t dstsiz) errno = EINVAL; return(-1); } - if ((m = decode_bitstring((const char **)&cp, dn, eom)) < 0) + if ((m = decode_bitstring(&cp, dn, eom)) < 0) { errno = EMSGSIZE; return(-1); @@ -214,11 +216,8 @@ ns_name_pton(const char *src, u_char *dst, size_t dstsiz) errno = EINVAL; /* ??? */ return(-1); } - if ((e = encode_bitsring(&src, - cp + 2, - (char **)&label, - (char **)&bp, - (const char *)eom)) + if ((e = encode_bitsring(&src, cp + 2, + &label, &bp, eom)) != 0) { errno = e; return(-1); @@ -790,9 +789,9 @@ dn_find(const u_char *domain, const u_char *msg, } static int -decode_bitstring(const char **cpp, char *dn, const char *eom) +decode_bitstring(const unsigned char **cpp, char *dn, const char *eom) { - const char *cp = *cpp; + const unsigned char *cp = *cpp; char *beg = dn, tc; int b, blen, plen, i; @@ -838,12 +837,13 @@ decode_bitstring(const char **cpp, char *dn, const char *eom) } static int -encode_bitsring(const char **bp, const char *end, char **labelp, - char ** dst, const char *eom) +encode_bitsring(const char **bp, const char *end, unsigned char **labelp, + unsigned char ** dst, unsigned const char *eom) { int afterslash = 0; const char *cp = *bp; - char *tp, c; + unsigned char *tp; + char c; const char *beg_blen; char *end_blen = NULL; int value = 0, count = 0, tbcount = 0, blen = 0; diff --git a/dist/bind/lib/bind/nameser/ns_print.c b/dist/bind/lib/bind/nameser/ns_print.c index 5b49672e91c..6bf0c3ae3de 100644 --- a/dist/bind/lib/bind/nameser/ns_print.c +++ b/dist/bind/lib/bind/nameser/ns_print.c @@ -1,4 +1,4 @@ -/* $NetBSD: ns_print.c,v 1.1.1.1 2004/05/17 23:44:46 christos Exp $ */ +/* $NetBSD: ns_print.c,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC") @@ -18,7 +18,7 @@ */ #ifndef lint -static const char rcsid[] = "Id: ns_print.c,v 1.3.2.1.4.4 2004/03/17 01:13:36 marka Exp"; +static const char rcsid[] = "Id: ns_print.c,v 1.3.2.1.4.5 2004/07/28 20:16:45 marka Exp"; #endif /* Import. */ @@ -147,8 +147,6 @@ ns_sprintrrf(const u_char *msg, size_t msglen, addlen(x, &buf, &buflen); len = SPRINTF((tmp, " %s %s", p_class(class), p_type(type))); T(addstr(tmp, len, &buf, &buflen)); - if (rdlen == 0U) - return (buf - obuf); T(spaced = addtab(x + len, 16, spaced, &buf, &buflen)); /* @@ -709,7 +707,8 @@ ns_sprintrrf(const u_char *msg, size_t msglen, int n, m; char *p; - len = SPRINTF((tmp, "\\# %u (\t; %s", edata - rdata, comment)); + len = SPRINTF((tmp, "\\# %u%s\t; %s", edata - rdata, + rdlen != 0 ? " (" : "", comment)); T(addstr(tmp, len, &buf, &buflen)); while (rdata < edata) { p = tmp; diff --git a/dist/bind/lib/bind/port/aix32/include/sys/cdefs.h b/dist/bind/lib/bind/port/aix32/include/sys/cdefs.h index 5c43a903201..cd84342a093 100644 --- a/dist/bind/lib/bind/port/aix32/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/aix32/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:46 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/04/11 01:30:12 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:36 marka Exp */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/aix4/include/sys/cdefs.h b/dist/bind/lib/bind/port/aix4/include/sys/cdefs.h index 9e440940c95..efe7982b9c7 100644 --- a/dist/bind/lib/bind/port/aix4/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/aix4/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:46 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/05/10 04:23:15 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:37 marka Exp */ #ifndef _CDEFS_H_ @@ -132,7 +132,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/aux3/include/sys/cdefs.h b/dist/bind/lib/bind/port/aux3/include/sys/cdefs.h index 2cb1e61817b..bbc6d00afbb 100644 --- a/dist/bind/lib/bind/port/aux3/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/aux3/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:46 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * Copyright (c) 1991, 1993 @@ -116,7 +116,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/cygwin/include/sys/cdefs.h b/dist/bind/lib/bind/port/cygwin/include/sys/cdefs.h index 7f4ecdfa1cd..e70d6bd055f 100644 --- a/dist/bind/lib/bind/port/cygwin/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/cygwin/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:46 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1.150.1 2003/10/21 05:21:08 marka Exp + * Id: cdefs.h,v 1.1.150.2 2004/07/19 05:53:39 marka Exp */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/hpux/include/sys/cdefs.h b/dist/bind/lib/bind/port/hpux/include/sys/cdefs.h index 83f716670af..1e8539e162e 100644 --- a/dist/bind/lib/bind/port/hpux/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/hpux/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:46 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/04/09 09:17:16 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:40 marka Exp */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/hpux10/include/sys/cdefs.h b/dist/bind/lib/bind/port/hpux10/include/sys/cdefs.h index c46c6179023..1e8539e162e 100644 --- a/dist/bind/lib/bind/port/hpux10/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/hpux10/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:46 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/05/17 06:25:49 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:40 marka Exp */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/hpux9/include/sys/cdefs.h b/dist/bind/lib/bind/port/hpux9/include/sys/cdefs.h index 0246e7afbd8..62a512fca6f 100644 --- a/dist/bind/lib/bind/port/hpux9/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/hpux9/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:46 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/05/17 06:25:50 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:41 marka Exp */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/irix/include/sys/cdefs.h b/dist/bind/lib/bind/port/irix/include/sys/cdefs.h index 0246e7afbd8..3c4a167cdba 100644 --- a/dist/bind/lib/bind/port/irix/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/irix/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:46 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/05/17 06:25:50 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:42 marka Exp */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/lynxos/include/sys/cdefs.h b/dist/bind/lib/bind/port/lynxos/include/sys/cdefs.h index 981f8b41285..5464e896f6f 100644 --- a/dist/bind/lib/bind/port/lynxos/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/lynxos/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:46 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/05/17 06:25:51 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:43 marka Exp */ #ifndef _CDEFS_H_ @@ -131,7 +131,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/mpe/include/sys/cdefs.h b/dist/bind/lib/bind/port/mpe/include/sys/cdefs.h index 30da532ffa8..fd549ad23b9 100644 --- a/dist/bind/lib/bind/port/mpe/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/mpe/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:46 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/05/17 06:25:51 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:44 marka Exp */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/next/include/sys/cdefs.h b/dist/bind/lib/bind/port/next/include/sys/cdefs.h index 1a5c2f3b6ff..be59bb24b0a 100644 --- a/dist/bind/lib/bind/port/next/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/next/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:47 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/05/17 06:25:55 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:48 marka Exp */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/qnx/include/sys/cdefs.h b/dist/bind/lib/bind/port/qnx/include/sys/cdefs.h index 484dddf65e4..2675c203d7e 100644 --- a/dist/bind/lib/bind/port/qnx/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/qnx/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:46 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * Copyright (c) 1991, 1993 @@ -108,8 +108,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || \ - (__GNUC__ == 2 && __GNUC_MINOR__ < 5) +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/sco42/include/sys/cdefs.h b/dist/bind/lib/bind/port/sco42/include/sys/cdefs.h index 8fc7547e3d2..c94c9d1f126 100644 --- a/dist/bind/lib/bind/port/sco42/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/sco42/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:47 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/05/17 06:25:57 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:50 marka Exp */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/solaris/include/sys/cdefs.h b/dist/bind/lib/bind/port/solaris/include/sys/cdefs.h index b4272bc13e8..c94c9d1f126 100644 --- a/dist/bind/lib/bind/port/solaris/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/solaris/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:47 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/04/02 06:29:20 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:50 marka Exp */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/sunos/include/sys/cdefs.h b/dist/bind/lib/bind/port/sunos/include/sys/cdefs.h index 5550957e0d4..8a268cb23b1 100644 --- a/dist/bind/lib/bind/port/sunos/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/sunos/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:47 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/05/17 06:25:58 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:51 marka Exp */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/unixware20/include/sys/cdefs.h b/dist/bind/lib/bind/port/unixware20/include/sys/cdefs.h index 678bd9f8bba..38672bd4561 100644 --- a/dist/bind/lib/bind/port/unixware20/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/unixware20/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:47 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/05/17 06:26:00 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:52 marka Exp */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port/unixware212/include/sys/cdefs.h b/dist/bind/lib/bind/port/unixware212/include/sys/cdefs.h index 44a1704cdfe..5aa04f6ac2f 100644 --- a/dist/bind/lib/bind/port/unixware212/include/sys/cdefs.h +++ b/dist/bind/lib/bind/port/unixware212/include/sys/cdefs.h @@ -1,4 +1,4 @@ -/* $NetBSD: cdefs.h,v 1.1.1.1 2004/05/17 23:44:47 christos Exp $ */ +/* $NetBSD: cdefs.h,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * ++Copyright++ 1991, 1993 @@ -57,7 +57,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * Id: cdefs.h,v 1.1 2001/05/17 06:26:01 marka Exp + * Id: cdefs.h,v 1.1.206.1 2004/07/19 05:53:53 marka Exp */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/dist/bind/lib/bind/port_after.h.in b/dist/bind/lib/bind/port_after.h.in index 9095982ec8f..6d5f4dca667 100644 --- a/dist/bind/lib/bind/port_after.h.in +++ b/dist/bind/lib/bind/port_after.h.in @@ -26,6 +26,7 @@ @USE_SYSERROR_LIST@ @INNETGR_ARGS@ @SETNETGRENT_ARGS@ +@USE_IFNAMELINKID@ /* XXX sunos and cygwin needs O_NDELAY */ #define PORT_NONBLOCK O_NONBLOCK diff --git a/dist/bind/lib/bind/resolv/res_debug.c b/dist/bind/lib/bind/resolv/res_debug.c index 91a1b001a53..cc4e18d7f6a 100644 --- a/dist/bind/lib/bind/resolv/res_debug.c +++ b/dist/bind/lib/bind/resolv/res_debug.c @@ -1,4 +1,4 @@ -/* $NetBSD: res_debug.c,v 1.1.1.1 2004/05/17 23:44:47 christos Exp $ */ +/* $NetBSD: res_debug.c,v 1.1.1.2 2004/11/06 23:55:33 christos Exp $ */ /* * Copyright (c) 1985 @@ -97,7 +97,7 @@ #if defined(LIBC_SCCS) && !defined(lint) static const char sccsid[] = "@(#)res_debug.c 8.1 (Berkeley) 6/4/93"; -static const char rcsid[] = "Id: res_debug.c,v 1.3.2.5.4.4 2004/04/13 06:53:20 marka Exp"; +static const char rcsid[] = "Id: res_debug.c,v 1.3.2.5.4.5 2004/07/28 20:16:46 marka Exp"; #endif /* LIBC_SCCS and not lint */ #include "port_before.h" @@ -551,7 +551,7 @@ p_type(int type) { result = sym_ntos(__p_type_syms, type, &success); if (success) return (result); - if (type < 0 || type > 0xfff) + if (type < 0 || type > 0xffff) return ("BADTYPE"); sprintf(typebuf, "TYPE%d", type); return (typebuf); @@ -587,7 +587,7 @@ p_class(int class) { result = sym_ntos(__p_class_syms, class, &success); if (success) return (result); - if (class < 0 || class > 0xfff) + if (class < 0 || class > 0xffff) return ("BADCLASS"); sprintf(classbuf, "CLASS%d", class); return (classbuf); diff --git a/dist/bind/lib/bind/resolv/res_mkupdate.c b/dist/bind/lib/bind/resolv/res_mkupdate.c index 926925e7606..bf7174caca9 100644 --- a/dist/bind/lib/bind/resolv/res_mkupdate.c +++ b/dist/bind/lib/bind/resolv/res_mkupdate.c @@ -1,4 +1,4 @@ -/* $NetBSD: res_mkupdate.c,v 1.1.1.1 2004/05/17 23:44:47 christos Exp $ */ +/* $NetBSD: res_mkupdate.c,v 1.1.1.2 2004/11/06 23:55:34 christos Exp $ */ /* * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC") @@ -23,7 +23,7 @@ */ #if !defined(lint) && !defined(SABER) -static const char rcsid[] = "Id: res_mkupdate.c,v 1.1.2.1.4.2 2004/03/16 12:34:19 marka Exp"; +static const char rcsid[] = "Id: res_mkupdate.c,v 1.1.2.1.4.3 2004/06/03 04:44:48 marka Exp"; #endif /* not lint */ #include "port_before.h" @@ -352,13 +352,13 @@ res_nmkupdate(res_state statp, ns_updrec *rrecp_in, u_char *buf, int buflen) { bm[i] = 0; while (getword_str(buf2, sizeof buf2, &startp, endp)) { - if ((n1 = res_servicenumber(buf2)) <= 0) + if ((n = res_servicenumber(buf2)) <= 0) return (-1); - if (n1 < MAXPORT) { - bm[n1/8] |= (0x80>>(n1%8)); - if (n1 > maxbm) - maxbm = n1; + if (n < MAXPORT) { + bm[n/8] |= (0x80>>(n%8)); + if ((unsigned)n > maxbm) + maxbm = n; } else return (-1); } diff --git a/dist/bind/lib/bind/resolv/res_send.c b/dist/bind/lib/bind/resolv/res_send.c index f9a2b309fe0..fb2e447b693 100644 --- a/dist/bind/lib/bind/resolv/res_send.c +++ b/dist/bind/lib/bind/resolv/res_send.c @@ -1,4 +1,4 @@ -/* $NetBSD: res_send.c,v 1.1.1.1 2004/05/17 23:44:48 christos Exp $ */ +/* $NetBSD: res_send.c,v 1.1.1.2 2004/11/06 23:55:34 christos Exp $ */ /* * Copyright (c) 1985, 1989, 1993 @@ -72,7 +72,7 @@ #if defined(LIBC_SCCS) && !defined(lint) static const char sccsid[] = "@(#)res_send.c 8.1 (Berkeley) 6/4/93"; -static const char rcsid[] = "Id: res_send.c,v 1.5.2.2.4.3 2004/04/12 06:54:59 marka Exp"; +static const char rcsid[] = "Id: res_send.c,v 1.5.2.2.4.5 2004/08/10 02:19:56 marka Exp"; #endif /* LIBC_SCCS and not lint */ /* @@ -174,7 +174,8 @@ res_ourserver_p(const res_state statp, const struct sockaddr *sa) { if (srv6->sin6_family == in6p->sin6_family && srv6->sin6_port == in6p->sin6_port && #ifdef HAVE_SIN6_SCOPE_ID - srv6->sin6_scope_id == in6p->sin6_scope_id && + (srv6->sin6_scope_id == 0 || + srv6->sin6_scope_id == in6p->sin6_scope_id) && #endif (IN6_IS_ADDR_UNSPECIFIED(&srv6->sin6_addr) || IN6_ARE_ADDR_EQUAL(&srv6->sin6_addr, &in6p->sin6_addr))) @@ -658,7 +659,7 @@ send_vc(res_state statp, len = INT16SZ; while ((n = read(statp->_vcsock, (char *)cp, (int)len)) > 0) { cp += n; - if ((len -= n) <= 0) + if ((len -= n) == 0) break; } if (n <= 0) { diff --git a/dist/bind/lib/bind9/Makefile.in b/dist/bind/lib/bind9/Makefile.in index a179b1e5713..368f06a5a7f 100644 --- a/dist/bind/lib/bind9/Makefile.in +++ b/dist/bind/lib/bind9/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.2.200.5 2004/03/08 09:04:26 marka Exp +# Id: Makefile.in,v 1.2.200.6 2004/07/20 07:01:57 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -59,7 +59,7 @@ libbind9.@SA@: ${OBJS} libbind9.la: ${OBJS} ${LIBTOOL_MODE_LINK} \ - ${CC} ${ALL_CFLAGS} -o libbind9.la -rpath ${libdir} \ + ${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libbind9.la -rpath ${libdir} \ -version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \ ${OBJS} ${LIBS} diff --git a/dist/bind/lib/bind9/api b/dist/bind/lib/bind9/api index 06977fcb711..dbaaf58cca8 100644 --- a/dist/bind/lib/bind9/api +++ b/dist/bind/lib/bind9/api @@ -1,3 +1,3 @@ LIBINTERFACE = 0 -LIBREVISION = 1 +LIBREVISION = 4 LIBAGE = 0 diff --git a/dist/bind/lib/bind9/check.c b/dist/bind/lib/bind9/check.c index 4e70b5f0797..53c79b3468f 100644 --- a/dist/bind/lib/bind9/check.c +++ b/dist/bind/lib/bind9/check.c @@ -1,4 +1,4 @@ -/* $NetBSD: check.c,v 1.1.1.1 2004/05/17 23:44:48 christos Exp $ */ +/* $NetBSD: check.c,v 1.1.1.2 2004/11/06 23:55:34 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: check.c,v 1.37.6.25 2004/04/15 23:56:28 marka Exp */ +/* Id: check.c,v 1.37.6.28 2004/07/29 00:08:08 marka Exp */ #include <config.h> @@ -282,6 +282,39 @@ disabled_algorithms(cfg_obj_t *disabled, isc_log_t *logctx) { } static isc_result_t +nameexist(cfg_obj_t *obj, const char *name, int value, isc_symtab_t *symtab, + const char *fmt, isc_log_t *logctx, isc_mem_t *mctx) +{ + char *key; + const char *file; + unsigned int line; + isc_result_t result; + isc_symvalue_t symvalue; + + key = isc_mem_strdup(mctx, name); + if (key == NULL) + return (ISC_R_NOMEMORY); + symvalue.as_pointer = obj; + result = isc_symtab_define(symtab, key, value, symvalue, + isc_symexists_reject); + if (result == ISC_R_EXISTS) { + RUNTIME_CHECK(isc_symtab_lookup(symtab, key, value, + &symvalue) == ISC_R_SUCCESS); + file = cfg_obj_file(symvalue.as_pointer); + line = cfg_obj_line(symvalue.as_pointer); + + if (file == NULL) + file = "<unknown file>"; + cfg_obj_log(obj, logctx, ISC_LOG_ERROR, fmt, key, file, line); + isc_mem_free(mctx, key); + result = ISC_R_EXISTS; + } else if (result != ISC_R_SUCCESS) { + isc_mem_free(mctx, key); + } + return (result); +} + +static isc_result_t mustbesecure(cfg_obj_t *secure, isc_symtab_t *symtab, isc_log_t *logctx, isc_mem_t *mctx) { @@ -292,9 +325,6 @@ mustbesecure(cfg_obj_t *secure, isc_symtab_t *symtab, isc_log_t *logctx, dns_name_t *name; isc_buffer_t b; isc_result_t result = ISC_R_SUCCESS; - isc_result_t tresult; - isc_symvalue_t symvalue; - char *key; dns_fixedname_init(&fixed); name = dns_fixedname_name(&fixed); @@ -302,42 +332,16 @@ mustbesecure(cfg_obj_t *secure, isc_symtab_t *symtab, isc_log_t *logctx, str = cfg_obj_asstring(obj); isc_buffer_init(&b, str, strlen(str)); isc_buffer_add(&b, strlen(str)); - tresult = dns_name_fromtext(name, &b, dns_rootname, ISC_FALSE, NULL); - if (tresult != ISC_R_SUCCESS) { + result = dns_name_fromtext(name, &b, dns_rootname, ISC_FALSE, NULL); + if (result != ISC_R_SUCCESS) { cfg_obj_log(obj, logctx, ISC_LOG_ERROR, "bad domain name '%s'", str); - result = tresult; } else { - dns_name_format(name, namebuf, sizeof(namebuf)); - key = isc_mem_strdup(mctx, namebuf); - if (key == NULL) - return (ISC_R_NOMEMORY); - symvalue.as_pointer = secure; - tresult = isc_symtab_define(symtab, key, 1, symvalue, - isc_symexists_reject); - if (tresult == ISC_R_EXISTS) { - const char *file; - unsigned int line; - - RUNTIME_CHECK(isc_symtab_lookup(symtab, key, 1, - &symvalue) == ISC_R_SUCCESS); - isc_mem_free(mctx, key); - file = cfg_obj_file(symvalue.as_pointer); - line = cfg_obj_line(symvalue.as_pointer); - - if (file == NULL) - file = "<unknown file>"; - - cfg_obj_log(secure, logctx, ISC_LOG_ERROR, - "dnssec-must-be-secure '%s': already " - "exists previous definition: %s:%u", - namebuf, file, line); - result = tresult; - } else if (tresult != ISC_R_SUCCESS) { - isc_mem_free(mctx, key); - result = tresult; - } + result = nameexist(secure, namebuf, 1, symtab, + "dnssec-must-be-secure '%s': already " + "exists previous definition: %s:%u", + logctx, mctx); } return (result); } @@ -355,6 +359,7 @@ check_options(cfg_obj_t *options, isc_log_t *logctx, isc_mem_t *mctx) { unsigned int i; cfg_obj_t *obj = NULL; cfg_listelt_t *element; + isc_symtab_t *symtab = NULL; static intervaltable intervals[] = { { "cleaning-interval", 60, 28 * 24 * 60 }, /* 28 days */ @@ -460,21 +465,70 @@ check_options(cfg_obj_t *options, isc_log_t *logctx, isc_mem_t *mctx) { obj = NULL; (void)cfg_map_get(options, "dnssec-lookaside", &obj); if (obj != NULL) { - dns_fixedname_t fixedname; - const char *dlv; - isc_buffer_t b; - - dlv = cfg_obj_asstring(obj); - dns_fixedname_init(&fixedname); - isc_buffer_init(&b, dlv, strlen(dlv)); - isc_buffer_add(&b, strlen(dlv)); - tresult = dns_name_fromtext(dns_fixedname_name(&fixedname), &b, - dns_rootname, ISC_TRUE, NULL); - if (tresult != ISC_R_SUCCESS) { - cfg_obj_log(obj, logctx, ISC_LOG_ERROR, - "bad domain name '%s'", dlv); + tresult = isc_symtab_create(mctx, 100, freekey, mctx, + ISC_TRUE, &symtab); + if (tresult != ISC_R_SUCCESS) result = tresult; + for (element = cfg_list_first(obj); + element != NULL; + element = cfg_list_next(element)) + { + dns_fixedname_t fixedname; + dns_name_t *name; + const char *dlv; + isc_buffer_t b; + + obj = cfg_listelt_value(element); + + dlv = cfg_obj_asstring(cfg_tuple_get(obj, "domain")); + dns_fixedname_init(&fixedname); + name = dns_fixedname_name(&fixedname); + isc_buffer_init(&b, dlv, strlen(dlv)); + isc_buffer_add(&b, strlen(dlv)); + tresult = dns_name_fromtext(name, &b, dns_rootname, + ISC_TRUE, NULL); + if (tresult != ISC_R_SUCCESS) { + cfg_obj_log(obj, logctx, ISC_LOG_ERROR, + "bad domain name '%s'", dlv); + result = tresult; + } + if (symtab != NULL) { + tresult = nameexist(obj, dlv, 1, symtab, + "dnssec-lookaside '%s': " + "already exists previous " + "definition: %s:%u", + logctx, mctx); + if (tresult != ISC_R_SUCCESS && + result == ISC_R_SUCCESS) + result = tresult; + } + /* + * XXXMPA to be removed when multiple lookaside + * namespaces are supported. + */ + if (!dns_name_equal(dns_rootname, name)) { + cfg_obj_log(obj, logctx, ISC_LOG_ERROR, + "dnssec-lookaside '%s': " + "non-root not yet supported", dlv); + if (result == ISC_R_SUCCESS) + result = ISC_R_FAILURE; + } + dlv = cfg_obj_asstring(cfg_tuple_get(obj, + "trust-anchor")); + dns_fixedname_init(&fixedname); + isc_buffer_init(&b, dlv, strlen(dlv)); + isc_buffer_add(&b, strlen(dlv)); + tresult = dns_name_fromtext(name, &b, dns_rootname, + ISC_TRUE, NULL); + if (tresult != ISC_R_SUCCESS) { + cfg_obj_log(obj, logctx, ISC_LOG_ERROR, + "bad domain name '%s'", dlv); + if (result == ISC_R_SUCCESS) + result = tresult; + } } + if (symtab != NULL) + isc_symtab_destroy(&symtab); } /* @@ -645,7 +699,6 @@ check_zoneconf(cfg_obj_t *zconfig, cfg_obj_t *config, isc_symtab_t *symtab, unsigned int ztype; cfg_obj_t *zoptions; cfg_obj_t *obj = NULL; - isc_symvalue_t symvalue; isc_result_t result = ISC_R_SUCCESS; isc_result_t tresult; unsigned int i; @@ -760,48 +813,22 @@ check_zoneconf(cfg_obj_t *zconfig, cfg_obj_t *config, isc_symtab_t *symtab, dns_fixedname_init(&fixedname); isc_buffer_init(&b, zname, strlen(zname)); isc_buffer_add(&b, strlen(zname)); - result = dns_name_fromtext(dns_fixedname_name(&fixedname), &b, + tresult = dns_name_fromtext(dns_fixedname_name(&fixedname), &b, dns_rootname, ISC_TRUE, NULL); if (result != ISC_R_SUCCESS) { cfg_obj_log(zconfig, logctx, ISC_LOG_ERROR, "zone '%s': is not a valid name", zname); - result = ISC_R_FAILURE; + tresult = ISC_R_FAILURE; } else { char namebuf[DNS_NAME_FORMATSIZE]; - char *key; dns_name_format(dns_fixedname_name(&fixedname), namebuf, sizeof(namebuf)); - key = isc_mem_strdup(mctx, namebuf); - if (key == NULL) - return (ISC_R_NOMEMORY); - symvalue.as_pointer = zconfig; - tresult = isc_symtab_define(symtab, key, - ztype == HINTZONE ? 1 : 2, - symvalue, isc_symexists_reject); - if (tresult == ISC_R_EXISTS) { - const char *file; - unsigned int line; - - RUNTIME_CHECK(isc_symtab_lookup(symtab, key, - ztype == HINTZONE ? 1 : 2, - &symvalue) == ISC_R_SUCCESS); - isc_mem_free(mctx, key); - file = cfg_obj_file(symvalue.as_pointer); - line = cfg_obj_line(symvalue.as_pointer); - - if (file == NULL) - file = "<unknown file>"; - cfg_obj_log(zconfig, logctx, ISC_LOG_ERROR, - "zone '%s': already exists " - "previous definition: %s:%u", - zname, file, line); - result = ISC_R_FAILURE; - } else if (tresult != ISC_R_SUCCESS) { - isc_mem_free(mctx, key); - - return (tresult); - } + tresult = nameexist(zconfig, namebuf, ztype == HINTZONE ? 1 : 2, + symtab, "zone '%s': already exists " + "previous definition: %s:%u", logctx, mctx); + if (tresult != ISC_R_SUCCESS) + result = tresult; } /* @@ -1177,6 +1204,7 @@ bind9_check_namedconf(cfg_obj_t *config, isc_log_t *logctx, isc_mem_t *mctx) { cfg_listelt_t *velement; isc_result_t result = ISC_R_SUCCESS; isc_result_t tresult; + isc_symtab_t *symtab = NULL; static const char *builtin[] = { "localhost", "localnets", "any", "none"}; @@ -1218,6 +1246,9 @@ bind9_check_namedconf(cfg_obj_t *config, isc_log_t *logctx, isc_mem_t *mctx) { } } + tresult = isc_symtab_create(mctx, 100, NULL, NULL, ISC_TRUE, &symtab); + if (tresult != ISC_R_SUCCESS) + result = tresult; for (velement = cfg_list_first(views); velement != NULL; velement = cfg_list_next(velement)) @@ -1228,6 +1259,8 @@ bind9_check_namedconf(cfg_obj_t *config, isc_log_t *logctx, isc_mem_t *mctx) { cfg_obj_t *vclassobj = cfg_tuple_get(view, "class"); dns_rdataclass_t vclass = dns_rdataclass_in; isc_result_t tresult = ISC_R_SUCCESS; + const char *key = cfg_obj_asstring(vname); + isc_symvalue_t symvalue; if (cfg_obj_isstring(vclassobj)) { isc_textregion_t r; @@ -1240,12 +1273,43 @@ bind9_check_namedconf(cfg_obj_t *config, isc_log_t *logctx, isc_mem_t *mctx) { "view '%s': invalid class %s", cfg_obj_asstring(vname), r.base); } + if (tresult == ISC_R_SUCCESS && symtab != NULL) { + symvalue.as_pointer = view; + tresult = isc_symtab_define(symtab, key, vclass, + symvalue, + isc_symexists_reject); + if (tresult == ISC_R_EXISTS) { + const char *file; + unsigned int line; + RUNTIME_CHECK(isc_symtab_lookup(symtab, key, + vclass, &symvalue) == ISC_R_SUCCESS); + file = cfg_obj_file(symvalue.as_pointer); + line = cfg_obj_line(symvalue.as_pointer); + cfg_obj_log(view, logctx, ISC_LOG_ERROR, + "view '%s': already exists " + "previous definition: %s:%u", + key, file, line); + result = tresult; + } else if (result != ISC_R_SUCCESS) { + result = tresult; + } else if ((strcasecmp(key, "_bind") == 0 && + vclass == dns_rdataclass_ch) || + (strcasecmp(key, "_default") == 0 && + vclass == dns_rdataclass_in)) { + cfg_obj_log(view, logctx, ISC_LOG_ERROR, + "attempt to redefine builtin view " + "'%s'", key); + result = ISC_R_EXISTS; + } + } if (tresult == ISC_R_SUCCESS) tresult = check_viewconf(config, voptions, vclass, logctx, mctx); if (tresult != ISC_R_SUCCESS) result = ISC_R_FAILURE; } + if (symtab != NULL) + isc_symtab_destroy(&symtab); if (views != NULL && options != NULL) { obj = NULL; diff --git a/dist/bind/lib/bind9/getaddresses.c b/dist/bind/lib/bind9/getaddresses.c index 2b379b102f5..58745eb4d7e 100644 --- a/dist/bind/lib/bind9/getaddresses.c +++ b/dist/bind/lib/bind9/getaddresses.c @@ -1,4 +1,4 @@ -/* $NetBSD: getaddresses.c,v 1.1.1.1 2004/05/17 23:44:48 christos Exp $ */ +/* $NetBSD: getaddresses.c,v 1.1.1.2 2004/11/06 23:55:34 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: getaddresses.c,v 1.13.126.4 2004/03/08 09:04:27 marka Exp */ +/* Id: getaddresses.c,v 1.13.126.5 2004/05/15 03:46:12 jinmei Exp */ #include <config.h> #include <string.h> @@ -25,6 +25,7 @@ #include <isc/net.h> #include <isc/netaddr.h> #include <isc/netdb.h> +#include <isc/netscope.h> #include <isc/result.h> #include <isc/sockaddr.h> #include <isc/util.h> @@ -69,19 +70,67 @@ bind9_getaddresses(const char *hostname, in_port_t port, have_ipv4 = (isc_net_probeipv4() == ISC_R_SUCCESS); have_ipv6 = (isc_net_probeipv6() == ISC_R_SUCCESS); - if (inet_pton(AF_INET6, hostname, &in6) == 1) { - if (!have_ipv6) - return (ISC_R_FAMILYNOSUPPORT); - isc_sockaddr_fromin6(&addrs[0], &in6, port); - *addrcount = 1; - return (ISC_R_SUCCESS); - } else if (inet_pton(AF_INET, hostname, &in4) == 1) { + /* + * Try IPv4, then IPv6. In order to handle the extended format + * for IPv6 scoped addresses (address%scope_ID), we'll use a local + * working buffer of 128 bytes. The length is an ad-hoc value, but + * should be enough for this purpose; the buffer can contain a string + * of at least 80 bytes for scope_ID in addition to any IPv6 numeric + * addresses (up to 46 bytes), the delimiter character and the + * terminating NULL character. + */ + if (inet_pton(AF_INET, hostname, &in4) == 1) { if (have_ipv4) isc_sockaddr_fromin(&addrs[0], &in4, port); else isc_sockaddr_v6fromin(&addrs[0], &in4, port); *addrcount = 1; return (ISC_R_SUCCESS); + } else if (strlen(hostname) <= 127) { + char tmpbuf[128], *d; + isc_uint32_t zone = 0; + + strcpy(tmpbuf, hostname); + d = strchr(tmpbuf, '%'); + if (d != NULL) + *d = '\0'; + + if (inet_pton(AF_INET6, tmpbuf, &in6) == 1) { + isc_netaddr_t na; + + if (!have_ipv6) + return (ISC_R_FAMILYNOSUPPORT); + + if (d != NULL) { +#ifdef ISC_PLATFORM_HAVESCOPEID + isc_result_t result; + + result = isc_netscope_pton(AF_INET6, d + 1, + &in6, &zone); + + if (result != ISC_R_SUCCESS) + return (result); +#else + /* + * The extended format is specified while the + * system does not provide the ability to use + * it. Throw an explicit error instead of + * ignoring the specified value. + */ + return (ISC_R_BADADDRESSFORM); +#endif + } + + isc_netaddr_fromin6(&na, &in6); + isc_netaddr_setzone(&na, zone); + isc_sockaddr_fromnetaddr(&addrs[0], + (const isc_netaddr_t *)&na, + port); + + *addrcount = 1; + return (ISC_R_SUCCESS); + + } } #ifdef USE_GETADDRINFO memset(&hints, 0, sizeof(hints)); diff --git a/dist/bind/lib/dns/Makefile.in b/dist/bind/lib/dns/Makefile.in index 15996afc583..eb1fd61f172 100644 --- a/dist/bind/lib/dns/Makefile.in +++ b/dist/bind/lib/dns/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.126.2.3.2.14 2004/04/15 00:34:52 marka Exp +# Id: Makefile.in,v 1.126.2.3.2.15 2004/07/20 07:01:57 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -107,7 +107,7 @@ libdns.@SA@: ${OBJS} libdns.la: ${OBJS} ${LIBTOOL_MODE_LINK} \ - ${CC} ${ALL_CFLAGS} -o libdns.la -rpath ${libdir} \ + ${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libdns.la -rpath ${libdir} \ -version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \ ${OBJS} ${ISCLIBS} @DNS_CRYPTO_LIBS@ ${LIBS} @@ -151,7 +151,7 @@ code.h: gen ./gen -s ${srcdir} > code.h gen: gen.c - ${CC} ${ALL_CFLAGS} -o $@ ${srcdir}/gen.c ${LIBS} + ${CC} ${ALL_CFLAGS} ${LDFLAGS} -o $@ ${srcdir}/gen.c ${LIBS} rbtdb64.@O@: rbtdb.c diff --git a/dist/bind/lib/dns/adb.c b/dist/bind/lib/dns/adb.c index 0272a008f23..192e0c3f170 100644 --- a/dist/bind/lib/dns/adb.c +++ b/dist/bind/lib/dns/adb.c @@ -1,4 +1,4 @@ -/* $NetBSD: adb.c,v 1.1.1.1 2004/05/17 23:44:49 christos Exp $ */ +/* $NetBSD: adb.c,v 1.1.1.2 2004/11/06 23:55:35 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: adb.c,v 1.181.2.11.2.17 2004/03/10 02:55:57 marka Exp */ +/* Id: adb.c,v 1.181.2.11.2.19 2004/09/01 05:19:57 marka Exp */ /* * Implementation notes @@ -1009,6 +1009,8 @@ set_target(dns_adb_t *adb, dns_name_t *name, dns_name_t *fname, dns_fixedname_init(&fixed2); new_target = dns_fixedname_name(&fixed2); dns_name_split(name, nlabels, prefix, NULL); + result = dns_name_concatenate(prefix, &dname.dname, new_target, + NULL); dns_rdata_freestruct(&dname); if (result != ISC_R_SUCCESS) return (result); @@ -1581,7 +1583,7 @@ find_name_and_lock(dns_adb_t *adb, dns_name_t *name, dns_adbname_t *adbname; int bucket; - bucket = dns_fullname_hash(name, ISC_FALSE) % NBUCKETS; + bucket = dns_name_fullhash(name, ISC_FALSE) % NBUCKETS; if (*bucketp == DNS_ADB_INVALIDBUCKET) { LOCK(&adb->namelocks[bucket]); diff --git a/dist/bind/lib/dns/api b/dist/bind/lib/dns/api index a8be9070823..444e0c5cd0c 100644 --- a/dist/bind/lib/dns/api +++ b/dist/bind/lib/dns/api @@ -1,3 +1,3 @@ -LIBINTERFACE = 14 +LIBINTERFACE = 20 LIBREVISION = 0 LIBAGE = 0 diff --git a/dist/bind/lib/dns/byaddr.c b/dist/bind/lib/dns/byaddr.c index 1cfdc079098..f2183f852a0 100644 --- a/dist/bind/lib/dns/byaddr.c +++ b/dist/bind/lib/dns/byaddr.c @@ -1,4 +1,4 @@ -/* $NetBSD: byaddr.c,v 1.1.1.1 2004/05/17 23:44:48 christos Exp $ */ +/* $NetBSD: byaddr.c,v 1.1.1.2 2004/11/06 23:55:34 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,12 +17,13 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: byaddr.c,v 1.29.2.1.2.7 2004/03/09 05:21:08 marka Exp */ +/* Id: byaddr.c,v 1.29.2.1.2.8 2004/08/28 06:25:18 marka Exp */ #include <config.h> #include <isc/mem.h> #include <isc/netaddr.h> +#include <isc/print.h> #include <isc/string.h> /* Required for HP/UX (and others?) */ #include <isc/task.h> #include <isc/util.h> diff --git a/dist/bind/lib/dns/dispatch.c b/dist/bind/lib/dns/dispatch.c index e9d05054697..cd600f90bd3 100644 --- a/dist/bind/lib/dns/dispatch.c +++ b/dist/bind/lib/dns/dispatch.c @@ -1,4 +1,4 @@ -/* $NetBSD: dispatch.c,v 1.1.1.1 2004/05/17 23:44:49 christos Exp $ */ +/* $NetBSD: dispatch.c,v 1.1.1.2 2004/11/06 23:55:36 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: dispatch.c,v 1.101.2.6.2.7 2004/04/15 02:10:39 marka Exp */ +/* Id: dispatch.c,v 1.101.2.6.2.10 2004/09/01 04:27:41 marka Exp */ #include <config.h> @@ -157,14 +157,14 @@ static isc_boolean_t destroy_disp_ok(dns_dispatch_t *); static void destroy_disp(isc_task_t *task, isc_event_t *event); static void udp_recv(isc_task_t *, isc_event_t *); static void tcp_recv(isc_task_t *, isc_event_t *); -static inline void startrecv(dns_dispatch_t *); +static void startrecv(dns_dispatch_t *); static dns_messageid_t dns_randomid(dns_qid_t *); static isc_uint32_t dns_hash(dns_qid_t *, isc_sockaddr_t *, dns_messageid_t); static void free_buffer(dns_dispatch_t *disp, void *buf, unsigned int len); static void *allocate_udp_buffer(dns_dispatch_t *disp); static inline void free_event(dns_dispatch_t *disp, dns_dispatchevent_t *ev); static inline dns_dispatchevent_t *allocate_event(dns_dispatch_t *disp); -static void do_cancel(dns_dispatch_t *disp, dns_dispentry_t *resp); +static void do_cancel(dns_dispatch_t *disp); static dns_dispentry_t *linear_first(dns_qid_t *disp); static dns_dispentry_t *linear_next(dns_qid_t *disp, dns_dispentry_t *resp); @@ -629,26 +629,25 @@ udp_recv(isc_task_t *task, isc_event_t *ev_in) { /* query */ free_buffer(disp, ev->region.base, ev->region.length); goto restart; - } else { - /* response */ - bucket = dns_hash(qid, &ev->address, id); - LOCK(&qid->lock); - resp = bucket_search(qid, &ev->address, id, bucket); - UNLOCK(&qid->lock); - dispatch_log(disp, LVL(90), - "search for response in bucket %d: %s", - bucket, (resp == NULL ? "not found" : "found")); - - if (resp == NULL) { - free_buffer(disp, ev->region.base, ev->region.length); - goto restart; - } - queue_response = resp->item_out; - rev = allocate_event(resp->disp); - if (rev == NULL) { - free_buffer(disp, ev->region.base, ev->region.length); - goto restart; - } + } + + /* response */ + bucket = dns_hash(qid, &ev->address, id); + LOCK(&qid->lock); + resp = bucket_search(qid, &ev->address, id, bucket); + dispatch_log(disp, LVL(90), + "search for response in bucket %d: %s", + bucket, (resp == NULL ? "not found" : "found")); + + if (resp == NULL) { + free_buffer(disp, ev->region.base, ev->region.length); + goto unlock; + } + queue_response = resp->item_out; + rev = allocate_event(resp->disp); + if (rev == NULL) { + free_buffer(disp, ev->region.base, ev->region.length); + goto unlock; } /* @@ -676,6 +675,8 @@ udp_recv(isc_task_t *task, isc_event_t *ev_in) { resp->item_out = ISC_TRUE; isc_task_send(resp->task, ISC_EVENT_PTR(&rev)); } + unlock: + UNLOCK(&qid->lock); /* * Restart recv() to get the next packet. @@ -748,7 +749,7 @@ tcp_recv(isc_task_t *task, isc_event_t *ev_in) { case ISC_R_EOF: dispatch_log(disp, LVL(90), "shutting down on EOF"); - do_cancel(disp, NULL); + do_cancel(disp); break; case ISC_R_CONNECTIONRESET: @@ -762,7 +763,7 @@ tcp_recv(isc_task_t *task, isc_event_t *ev_in) { dispatch_log(disp, level, "shutting down due to TCP " "receive error: %s: %s", buf, isc_result_totext(tcpmsg->result)); - do_cancel(disp, NULL); + do_cancel(disp); break; } @@ -818,27 +819,26 @@ tcp_recv(isc_task_t *task, isc_event_t *ev_in) { * Query. */ goto restart; - } else { - /* - * Response. - */ - bucket = dns_hash(qid, &tcpmsg->address, id); - LOCK(&qid->lock); - resp = bucket_search(qid, &tcpmsg->address, id, bucket); - UNLOCK(&qid->lock); - dispatch_log(disp, LVL(90), - "search for response in bucket %d: %s", - bucket, (resp == NULL ? "not found" : "found")); - - if (resp == NULL) - goto restart; - queue_response = resp->item_out; - rev = allocate_event(disp); - if (rev == NULL) - goto restart; } /* + * Response. + */ + bucket = dns_hash(qid, &tcpmsg->address, id); + LOCK(&qid->lock); + resp = bucket_search(qid, &tcpmsg->address, id, bucket); + dispatch_log(disp, LVL(90), + "search for response in bucket %d: %s", + bucket, (resp == NULL ? "not found" : "found")); + + if (resp == NULL) + goto unlock; + queue_response = resp->item_out; + rev = allocate_event(disp); + if (rev == NULL) + goto unlock; + + /* * At this point, rev contains the event we want to fill in, and * resp contains the information on the place to send it to. * Send the event off. @@ -860,6 +860,8 @@ tcp_recv(isc_task_t *task, isc_event_t *ev_in) { resp->item_out = ISC_TRUE; isc_task_send(resp->task, ISC_EVENT_PTR(&rev)); } + unlock: + UNLOCK(&qid->lock); /* * Restart recv() to get the next packet. @@ -907,7 +909,7 @@ startrecv(dns_dispatch_t *disp) { free_buffer(disp, region.base, region.length); disp->shutdown_why = res; disp->shutting_down = 1; - do_cancel(disp, NULL); + do_cancel(disp); return; } INSIST(disp->recv_pending == 0); @@ -920,7 +922,7 @@ startrecv(dns_dispatch_t *disp) { if (res != ISC_R_SUCCESS) { disp->shutdown_why = res; disp->shutting_down = 1; - do_cancel(disp, NULL); + do_cancel(disp); return; } INSIST(disp->recv_pending == 0); @@ -1296,7 +1298,7 @@ local_addr_match(dns_dispatch_t *disp, isc_sockaddr_t *addr) { if (result != ISC_R_SUCCESS) return (ISC_FALSE); - return (isc_sockaddr_equal(&disp->local, &sockaddr)); + return (isc_sockaddr_equal(&sockaddr, addr)); } /* @@ -2020,7 +2022,7 @@ dns_dispatch_removeresponse(dns_dispentry_t **resp, res->magic = 0; isc_mempool_put(disp->mgr->rpool, res); if (disp->shutting_down == 1) - do_cancel(disp, NULL); + do_cancel(disp); else startrecv(disp); @@ -2031,8 +2033,9 @@ dns_dispatch_removeresponse(dns_dispentry_t **resp, } static void -do_cancel(dns_dispatch_t *disp, dns_dispentry_t *resp) { +do_cancel(dns_dispatch_t *disp) { dns_dispatchevent_t *ev; + dns_dispentry_t *resp; dns_qid_t *qid; if (disp->shutdown_out == 1) @@ -2043,28 +2046,16 @@ do_cancel(dns_dispatch_t *disp, dns_dispentry_t *resp) { /* * Search for the first response handler without packets outstanding. */ - if (resp == NULL) { - LOCK(&qid->lock); - resp = linear_first(qid); - if (resp == NULL) { - /* no first item? */ - UNLOCK(&qid->lock); - return; - } - do { - if (resp->item_out == ISC_FALSE) - break; - - resp = linear_next(qid, resp); - } while (resp != NULL); - UNLOCK(&qid->lock); - } - + LOCK(&qid->lock); + for (resp = linear_first(qid); + resp != NULL && resp->item_out != ISC_FALSE; + /* Empty. */) + resp = linear_next(qid, resp); /* * No one to send the cancel event to, so nothing to do. */ if (resp == NULL) - return; + goto unlock; /* * Send the shutdown failsafe event to this resp. @@ -2081,6 +2072,8 @@ do_cancel(dns_dispatch_t *disp, dns_dispentry_t *resp) { ev, resp->task); resp->item_out = ISC_TRUE; isc_task_send(resp->task, ISC_EVENT_PTR(&ev)); + unlock: + UNLOCK(&qid->lock); } isc_socket_t * @@ -2116,7 +2109,7 @@ dns_dispatch_cancel(dns_dispatch_t *disp) { disp->shutdown_why = ISC_R_CANCELED; disp->shutting_down = 1; - do_cancel(disp, NULL); + do_cancel(disp); UNLOCK(&disp->lock); diff --git a/dist/bind/lib/dns/dnssec.c b/dist/bind/lib/dns/dnssec.c index 51f85529fe8..4787f308974 100644 --- a/dist/bind/lib/dns/dnssec.c +++ b/dist/bind/lib/dns/dnssec.c @@ -1,4 +1,4 @@ -/* $NetBSD: dnssec.c,v 1.1.1.1 2004/05/17 23:44:50 christos Exp $ */ +/* $NetBSD: dnssec.c,v 1.1.1.2 2004/11/06 23:55:36 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -18,7 +18,7 @@ */ /* - * Id: dnssec.c,v 1.69.2.5.2.6 2004/03/08 21:06:26 marka Exp + * Id: dnssec.c,v 1.69.2.5.2.7 2004/06/11 00:30:54 marka Exp */ @@ -136,6 +136,8 @@ dns_dnssec_keyfromrdata(dns_name_t *name, dns_rdata_t *rdata, isc_mem_t *mctx, INSIST(mctx != NULL); INSIST(key != NULL); INSIST(*key == NULL); + REQUIRE(rdata->type == dns_rdatatype_key || + rdata->type == dns_rdatatype_dnskey); dns_rdata_toregion(rdata, &r); isc_buffer_init(&b, r.base, r.length); diff --git a/dist/bind/lib/dns/include/dns/db.h b/dist/bind/lib/dns/include/dns/db.h index 58e78ffb09c..c2ca6510acb 100644 --- a/dist/bind/lib/dns/include/dns/db.h +++ b/dist/bind/lib/dns/include/dns/db.h @@ -1,4 +1,4 @@ -/* $NetBSD: db.h,v 1.1.1.1 2004/05/17 23:44:57 christos Exp $ */ +/* $NetBSD: db.h,v 1.1.1.2 2004/11/06 23:55:44 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: db.h,v 1.67.12.7 2004/03/08 09:04:35 marka Exp */ +/* Id: db.h,v 1.67.12.8 2004/05/14 05:06:41 marka Exp */ #ifndef DNS_DB_H #define DNS_DB_H 1 @@ -190,6 +190,7 @@ struct dns_db { #define DNS_DBFIND_PENDINGOK 0x08 #define DNS_DBFIND_NOEXACT 0x10 #define DNS_DBFIND_FORCENSEC 0x20 +#define DNS_DBFIND_COVERINGNSEC 0x40 /* * Options that can be specified for dns_db_addrdataset(). @@ -649,6 +650,12 @@ dns_db_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, * is only necessary when querying a database that was not secure * when created. * + * If the DNS_DBFIND_COVERINGNSEC option is set, then look for a + * NSEC record that potentially covers 'name' if a answer cannot + * be found. Note the returned NSEC needs to be checked to ensure + * that it is correct. This only affects answers returned from the + * cache. + * * To respond to a query for SIG records, the caller should create a * rdataset iterator and extract the signatures from each rdataset. * @@ -772,6 +779,9 @@ dns_db_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, * DNS_R_EMPTYNAME The name exists but there is * no data at the name. * + * DNS_R_COVERINGNSEC The returned data is a NSEC + * that potentially covers 'name'. + * * Error results: * * ISC_R_NOMEMORY diff --git a/dist/bind/lib/dns/include/dns/name.h b/dist/bind/lib/dns/include/dns/name.h index a3aa4e93b69..7370f151227 100644 --- a/dist/bind/lib/dns/include/dns/name.h +++ b/dist/bind/lib/dns/include/dns/name.h @@ -1,4 +1,4 @@ -/* $NetBSD: name.h,v 1.1.1.1 2004/05/17 23:44:58 christos Exp $ */ +/* $NetBSD: name.h,v 1.1.1.2 2004/11/06 23:55:45 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: name.h,v 1.95.2.3.2.8 2004/03/16 12:57:17 marka Exp */ +/* Id: name.h,v 1.95.2.3.2.11 2004/09/01 05:19:59 marka Exp */ #ifndef DNS_NAME_H #define DNS_NAME_H 1 @@ -314,7 +314,7 @@ dns_name_hash(dns_name_t *name, isc_boolean_t case_sensitive); */ unsigned int -dns_fullname_hash(dns_name_t *name, isc_boolean_t case_sensitive); +dns_name_fullhash(dns_name_t *name, isc_boolean_t case_sensitive); /* * Provide a hash value for 'name'. Unlike dns_name_hash(), this function * always takes into account of the entire name to calculate the hash value. @@ -575,6 +575,9 @@ dns_name_getlabelsequence(const dns_name_t *source, unsigned int first, * Notes: * Numbering starts at 0. * + * Given "rc.vix.com.", the label 0 is "rc", and label 3 is the + * root label. + * * 'target' refers to the same memory as 'source', so 'source' * must not be changed while 'target' is still in use. * @@ -1216,7 +1219,7 @@ do { \ do { \ (r)->base = (n)->ndata; \ (r)->length = (n)->length; \ -} while (0); +} while (0) #define DNS_NAME_SPLIT(n, l, p, s) \ do { \ @@ -1228,7 +1231,7 @@ do { \ dns_name_getlabelsequence(_n, 0, _n->labels - _l, _p); \ if (_s != NULL) \ dns_name_getlabelsequence(_n, _n->labels - _l, _l, _s); \ -} while (0); +} while (0) #ifdef DNS_NAME_USEINLINE diff --git a/dist/bind/lib/dns/include/dns/result.h b/dist/bind/lib/dns/include/dns/result.h index d2fc5c76b58..bf98b76e610 100644 --- a/dist/bind/lib/dns/include/dns/result.h +++ b/dist/bind/lib/dns/include/dns/result.h @@ -1,4 +1,4 @@ -/* $NetBSD: result.h,v 1.1.1.1 2004/05/17 23:44:58 christos Exp $ */ +/* $NetBSD: result.h,v 1.1.1.2 2004/11/06 23:55:45 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: result.h,v 1.81.2.7.2.12 2004/04/15 23:56:32 marka Exp */ +/* Id: result.h,v 1.81.2.7.2.13 2004/05/14 05:06:41 marka Exp */ #ifndef DNS_RESULT_H #define DNS_RESULT_H 1 @@ -144,8 +144,9 @@ #define DNS_R_DYNAMIC (ISC_RESULTCLASS_DNS + 98) #define DNS_R_UNKNOWNCOMMAND (ISC_RESULTCLASS_DNS + 99) #define DNS_R_MUSTBESECURE (ISC_RESULTCLASS_DNS + 100) +#define DNS_R_COVERINGNSEC (ISC_RESULTCLASS_DNS + 101) -#define DNS_R_NRESULTS 101 /* Number of results */ +#define DNS_R_NRESULTS 102 /* Number of results */ /* * DNS wire format rcodes. diff --git a/dist/bind/lib/dns/include/dns/validator.h b/dist/bind/lib/dns/include/dns/validator.h index 578222d3cbe..98ca73586c8 100644 --- a/dist/bind/lib/dns/include/dns/validator.h +++ b/dist/bind/lib/dns/include/dns/validator.h @@ -1,4 +1,4 @@ -/* $NetBSD: validator.h,v 1.1.1.1 2004/05/17 23:44:58 christos Exp $ */ +/* $NetBSD: validator.h,v 1.1.1.2 2004/11/06 23:55:45 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: validator.h,v 1.18.12.6 2004/04/15 23:56:33 marka Exp */ +/* Id: validator.h,v 1.18.12.7 2004/05/14 05:06:41 marka Exp */ #ifndef DNS_VALIDATOR_H #define DNS_VALIDATOR_H 1 @@ -123,6 +123,8 @@ struct dns_validator { dns_fixedname_t wild; ISC_LINK(dns_validator_t) link; dns_rdataset_t * dlv; + dns_fixedname_t dlvsep; + isc_boolean_t havedlvsep; isc_boolean_t mustbesecure; }; diff --git a/dist/bind/lib/dns/journal.c b/dist/bind/lib/dns/journal.c index 42a331c07c7..7433e39e7f1 100644 --- a/dist/bind/lib/dns/journal.c +++ b/dist/bind/lib/dns/journal.c @@ -1,4 +1,4 @@ -/* $NetBSD: journal.c,v 1.1.1.1 2004/05/17 23:44:50 christos Exp $ */ +/* $NetBSD: journal.c,v 1.1.1.2 2004/11/06 23:55:37 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: journal.c,v 1.77.2.1.10.6 2004/03/08 09:04:30 marka Exp */ +/* Id: journal.c,v 1.77.2.1.10.8 2004/05/14 05:27:47 marka Exp */ #include <config.h> @@ -1824,10 +1824,16 @@ dns_db_diff(isc_mem_t *mctx, dns_fixedname_init(&fixname[0]); dns_fixedname_init(&fixname[1]); - CHECK(dns_journal_open(mctx, journal_filename, ISC_TRUE, &journal)); + result = dns_journal_open(mctx, journal_filename, ISC_TRUE, &journal); + if (result != ISC_R_SUCCESS) + return (result); - CHECK(dns_db_createiterator(db[0], ISC_FALSE, &dbit[0])); - CHECK(dns_db_createiterator(db[1], ISC_FALSE, &dbit[1])); + result = dns_db_createiterator(db[0], ISC_FALSE, &dbit[0]); + if (result != ISC_R_SUCCESS) + goto cleanup_journal; + result = dns_db_createiterator(db[1], ISC_FALSE, &dbit[1]); + if (result != ISC_R_SUCCESS) + goto cleanup_interator0; itresult[0] = dns_dbiterator_first(dbit[0]); itresult[1] = dns_dbiterator_first(dbit[1]); @@ -1900,8 +1906,10 @@ dns_db_diff(isc_mem_t *mctx, failure: dns_diff_clear(&resultdiff); - dns_dbiterator_destroy(&dbit[0]); dns_dbiterator_destroy(&dbit[1]); + cleanup_interator0: + dns_dbiterator_destroy(&dbit[0]); + cleanup_journal: dns_journal_destroy(&journal); return (result); } @@ -2117,6 +2125,7 @@ index_to_disk(dns_journal_t *j) { } INSIST(p == j->rawindex + rawbytes); + CHECK(journal_seek(j, sizeof(journal_rawheader_t))); CHECK(journal_write(j, j->rawindex, rawbytes)); } failure: diff --git a/dist/bind/lib/dns/master.c b/dist/bind/lib/dns/master.c index 50b796512c5..43a6d2f64ec 100644 --- a/dist/bind/lib/dns/master.c +++ b/dist/bind/lib/dns/master.c @@ -1,4 +1,4 @@ -/* $NetBSD: master.c,v 1.1.1.1 2004/05/17 23:44:51 christos Exp $ */ +/* $NetBSD: master.c,v 1.1.1.2 2004/11/06 23:55:37 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: master.c,v 1.122.2.8.2.13 2004/03/08 02:07:53 marka Exp */ +/* Id: master.c,v 1.122.2.8.2.14 2004/05/05 01:32:16 marka Exp */ #include <config.h> @@ -1647,7 +1647,8 @@ load(dns_loadctx_t *lctx) { } - if (type == dns_rdatatype_rrsig) + if (type == dns_rdatatype_rrsig || + type == dns_rdatatype_sig) covers = dns_rdata_covers(&rdata[rdcount]); else covers = 0; diff --git a/dist/bind/lib/dns/masterdump.c b/dist/bind/lib/dns/masterdump.c index ab3cf3d2e28..f3457bbda06 100644 --- a/dist/bind/lib/dns/masterdump.c +++ b/dist/bind/lib/dns/masterdump.c @@ -1,4 +1,4 @@ -/* $NetBSD: masterdump.c,v 1.1.1.1 2004/05/17 23:44:49 christos Exp $ */ +/* $NetBSD: masterdump.c,v 1.1.1.2 2004/11/06 23:55:35 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: masterdump.c,v 1.56.2.5.2.10 2004/03/08 09:04:30 marka Exp */ +/* Id: masterdump.c,v 1.56.2.5.2.12 2004/08/28 06:25:19 marka Exp */ #include <config.h> @@ -27,6 +27,7 @@ #include <isc/file.h> #include <isc/magic.h> #include <isc/mem.h> +#include <isc/print.h> #include <isc/stdio.h> #include <isc/string.h> #include <isc/task.h> @@ -981,6 +982,7 @@ closeandrename(FILE *f, isc_result_t result, const char *temp, const char *file) static void dump_quantum(isc_task_t *task, isc_event_t *event) { isc_result_t result; + isc_result_t tresult; dns_dumpctx_t *dctx; REQUIRE(event != NULL); @@ -996,11 +998,12 @@ dump_quantum(isc_task_t *task, isc_event_t *event) { return; } - if (dctx->file != NULL) - result = closeandrename(dctx->f, result, - dctx->tmpfile, dctx->file); - if (dctx->version != NULL) - dns_db_closeversion(dctx->db, &dctx->version, ISC_FALSE); + if (dctx->file != NULL) { + tresult = closeandrename(dctx->f, result, + dctx->tmpfile, dctx->file); + if (tresult != ISC_R_SUCCESS && result == ISC_R_SUCCESS) + result = tresult; + } (dctx->done)(dctx->done_arg, result); isc_event_free(&event); dns_dumpctx_detach(&dctx); diff --git a/dist/bind/lib/dns/message.c b/dist/bind/lib/dns/message.c index 693930d1863..30be78789fe 100644 --- a/dist/bind/lib/dns/message.c +++ b/dist/bind/lib/dns/message.c @@ -1,4 +1,4 @@ -/* $NetBSD: message.c,v 1.1.1.1 2004/05/17 23:44:51 christos Exp $ */ +/* $NetBSD: message.c,v 1.1.1.2 2004/11/06 23:55:38 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: message.c,v 1.194.2.10.2.16 2004/03/10 00:48:49 marka Exp */ +/* Id: message.c,v 1.194.2.10.2.17 2004/05/05 01:32:16 marka Exp */ /*** *** Imports @@ -1290,18 +1290,16 @@ getsection(isc_buffer_t *source, dns_message_t *msg, dns_decompress_t *dctx, if (result != ISC_R_SUCCESS) goto cleanup; rdata->rdclass = rdclass; + issigzero = ISC_FALSE; if (rdtype == dns_rdatatype_rrsig && rdata->flags == 0) { covers = dns_rdata_covers(rdata); if (covers == 0) DO_FORMERR; - } else - covers = 0; - - issigzero = ISC_FALSE; - if (rdtype == dns_rdatatype_sig /* SIG(0) */ && - rdata->flags == 0) { - if (dns_rdata_covers(rdata) == 0) { + } else if (rdtype == dns_rdatatype_sig /* SIG(0) */ && + rdata->flags == 0) { + covers = dns_rdata_covers(rdata); + if (covers == 0) { if (sectionid != DNS_SECTION_ADDITIONAL || count != msg->counts[sectionid] - 1) DO_FORMERR; @@ -1310,7 +1308,8 @@ getsection(isc_buffer_t *source, dns_message_t *msg, dns_decompress_t *dctx, skip_type_search = ISC_TRUE; issigzero = ISC_TRUE; } - } + } else + covers = 0; /* * If we are doing a dynamic update or this is a meta-type, diff --git a/dist/bind/lib/dns/name.c b/dist/bind/lib/dns/name.c index 8f6261e96f1..dac5874e8f4 100644 --- a/dist/bind/lib/dns/name.c +++ b/dist/bind/lib/dns/name.c @@ -1,4 +1,4 @@ -/* $NetBSD: name.c,v 1.1.1.1 2004/05/17 23:44:51 christos Exp $ */ +/* $NetBSD: name.c,v 1.1.1.2 2004/11/06 23:55:38 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: name.c,v 1.127.2.7.2.10 2004/04/19 21:55:38 marka Exp */ +/* Id: name.c,v 1.127.2.7.2.11 2004/09/01 05:19:59 marka Exp */ #include <config.h> @@ -181,6 +181,9 @@ static dns_name_t wild = /* XXXDCL make const? */ LIBDNS_EXTERNAL_DATA dns_name_t *dns_wildcardname = &wild; +unsigned int +dns_fullname_hash(dns_name_t *name, isc_boolean_t case_sensitive); + static void set_offsets(const dns_name_t *name, unsigned char *offsets, dns_name_t *set_name); @@ -432,7 +435,7 @@ dns_name_hash(dns_name_t *name, isc_boolean_t case_sensitive) { } unsigned int -dns_fullname_hash(dns_name_t *name, isc_boolean_t case_sensitive) { +dns_name_fullhash(dns_name_t *name, isc_boolean_t case_sensitive) { /* * Provide a hash value for 'name'. */ @@ -446,6 +449,18 @@ dns_fullname_hash(dns_name_t *name, isc_boolean_t case_sensitive) { } unsigned int +dns_fullname_hash(dns_name_t *name, isc_boolean_t case_sensitive) { + /* + * This function was deprecated due to the breakage of the name space + * convention. We only keep this internally to provide binary backward + * compatibility. + */ + REQUIRE(VALID_NAME(name)); + + return (dns_name_fullhash(name, case_sensitive)); +} + +unsigned int dns_name_hashbylabel(dns_name_t *name, isc_boolean_t case_sensitive) { unsigned char *offsets; dns_offsets_t odata; diff --git a/dist/bind/lib/dns/rbtdb.c b/dist/bind/lib/dns/rbtdb.c index 87e9f72f227..181af9195c7 100644 --- a/dist/bind/lib/dns/rbtdb.c +++ b/dist/bind/lib/dns/rbtdb.c @@ -1,4 +1,4 @@ -/* $NetBSD: rbtdb.c,v 1.1.1.1 2004/05/17 23:44:52 christos Exp $ */ +/* $NetBSD: rbtdb.c,v 1.1.1.2 2004/11/06 23:55:39 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: rbtdb.c,v 1.168.2.11.2.12 2004/03/08 02:07:55 marka Exp */ +/* Id: rbtdb.c,v 1.168.2.11.2.16 2004/05/23 11:07:23 marka Exp */ /* * Principal Author: Bob Halley @@ -844,8 +844,7 @@ clean_zone_node(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node, /* * If this is a NONEXISTENT rdataset, we can delete it. */ - if ((current->attributes & RDATASET_ATTR_NONEXISTENT) - != 0) { + if (NONEXISTENT(current)) { if (top_prev != NULL) top_prev->next = current->next; else @@ -1064,9 +1063,13 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) { * isn't being used by anyone, we can clean * it up. */ - if (rbtdb->current_version->references == 0) + if (rbtdb->current_version->references == 0) { cleanup_version = rbtdb->current_version; + APPENDLIST(version->changed_list, + cleanup_version->changed_list, + link); + } /* * Become the current version. */ @@ -1079,6 +1082,7 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) { * We're rolling back this transaction. */ cleanup_list = version->changed_list; + ISC_LIST_INIT(version->changed_list); rollback = ISC_TRUE; cleanup_version = version; rbtdb->future_version = NULL; @@ -1099,6 +1103,7 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) { if (least_greater == NULL) least_greater = rbtdb->current_version; + INSIST(version->serial < least_greater->serial); /* * Is this the least open version? */ @@ -1119,16 +1124,19 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) { version->changed_list, link); } - } + } else if (version->serial == rbtdb->least_serial) + INSIST(EMPTY(version->changed_list)); UNLINK(rbtdb->open_versions, version, link); } } least_serial = rbtdb->least_serial; UNLOCK(&rbtdb->lock); - if (cleanup_version != NULL) + if (cleanup_version != NULL) { + INSIST(EMPTY(cleanup_version->changed_list)); isc_mem_put(rbtdb->common.mctx, cleanup_version, sizeof(*cleanup_version)); + } if (!EMPTY(cleanup_list)) { for (changed = HEAD(cleanup_list); @@ -1933,8 +1941,7 @@ find_closest_nsec(rbtdb_search_t *search, dns_dbnode_t **nodep, * Is this a "this rdataset doesn't * exist" record? */ - if ((header->attributes & - RDATASET_ATTR_NONEXISTENT) != 0) + if (NONEXISTENT(header)) header = NULL; break; } else @@ -2206,8 +2213,7 @@ zone_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, * Is this a "this rdataset doesn't * exist" record? */ - if ((header->attributes & - RDATASET_ATTR_NONEXISTENT) != 0) + if (NONEXISTENT(header)) header = NULL; break; } else @@ -2660,8 +2666,7 @@ find_deepest_zonecut(rbtdb_search_t *search, dns_rbtnode_t *node, node->dirty = 1; header_prev = header; } - } else if ((header->attributes & - RDATASET_ATTR_NONEXISTENT) == 0) { + } else if (EXISTS(header)) { /* * We've found an extant rdataset. See if * we're interested in it. @@ -2738,6 +2743,104 @@ find_deepest_zonecut(rbtdb_search_t *search, dns_rbtnode_t *node, } static isc_result_t +find_coveringnsec(rbtdb_search_t *search, dns_dbnode_t **nodep, + isc_stdtime_t now, dns_name_t *foundname, + dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset) +{ + dns_rbtnode_t *node; + rdatasetheader_t *header, *header_next, *header_prev; + rdatasetheader_t *found, *foundsig; + isc_boolean_t empty_node; + isc_result_t result; + dns_fixedname_t fname, forigin; + dns_name_t *name, *origin; + rbtdb_rdatatype_t matchtype, sigmatchtype, nsectype; + + matchtype = RBTDB_RDATATYPE_VALUE(dns_rdatatype_nsec, 0); + nsectype = RBTDB_RDATATYPE_VALUE(0, dns_rdatatype_nsec); + sigmatchtype = RBTDB_RDATATYPE_VALUE(dns_rdatatype_rrsig, + dns_rdatatype_nsec); + + do { + node = NULL; + dns_fixedname_init(&fname); + name = dns_fixedname_name(&fname); + dns_fixedname_init(&forigin); + origin = dns_fixedname_name(&forigin); + result = dns_rbtnodechain_current(&search->chain, name, + origin, &node); + if (result != ISC_R_SUCCESS) + return (result); + LOCK(&(search->rbtdb->node_locks[node->locknum].lock)); + found = NULL; + foundsig = NULL; + empty_node = ISC_TRUE; + header_prev = NULL; + for (header = node->data; + header != NULL; + header = header_next) { + header_next = header->next; + if (header->ttl <= now) { + /* + * This rdataset is stale. If no one else is + * using the node, we can clean it up right + * now, otherwise we mark it as stale, and the + * node as dirty, so it will get cleaned up + * later. + */ + if (node->references == 0) { + INSIST(header->down == NULL); + if (header_prev != NULL) + header_prev->next = + header->next; + else + node->data = header->next; + free_rdataset(search->rbtdb->common.mctx, + header); + } else { + header->attributes |= + RDATASET_ATTR_STALE; + node->dirty = 1; + header_prev = header; + } + continue; + } + if (NONEXISTENT(header) || NXDOMAIN(header)) { + header_prev = header; + continue; + } + empty_node = ISC_FALSE; + if (header->type == matchtype) + found = header; + else if (header->type == sigmatchtype) + foundsig = header; + header_prev = header; + } + if (found != NULL) { + result = dns_name_concatenate(name, origin, + foundname, NULL); + if (result != ISC_R_SUCCESS) + goto unlock_node; + bind_rdataset(search->rbtdb, node, found, + now, rdataset); + if (foundsig != NULL) + bind_rdataset(search->rbtdb, node, foundsig, + now, sigrdataset); + new_reference(search->rbtdb, node); + *nodep = node; + result = DNS_R_COVERINGNSEC; + } else if (!empty_node) { + result = ISC_R_NOTFOUND; + }else + result = dns_rbtnodechain_prev(&search->chain, NULL, + NULL); + unlock_node: + UNLOCK(&(search->rbtdb->node_locks[node->locknum].lock)); + } while (empty_node && result == ISC_R_SUCCESS); + return (result); +} + +static isc_result_t cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, dns_rdatatype_t type, unsigned int options, isc_stdtime_t now, dns_dbnode_t **nodep, dns_name_t *foundname, @@ -2752,7 +2855,7 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, rdatasetheader_t *header, *header_prev, *header_next; rdatasetheader_t *found, *nsheader; rdatasetheader_t *foundsig, *nssig, *cnamesig; - rbtdb_rdatatype_t sigtype, nsecype; + rbtdb_rdatatype_t sigtype, nsectype; UNUSED(version); @@ -2787,6 +2890,13 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, cache_zonecut_callback, &search); if (result == DNS_R_PARTIALMATCH) { + if ((search.options & DNS_DBFIND_COVERINGNSEC) != 0) { + result = find_coveringnsec(&search, nodep, now, + foundname, rdataset, + sigrdataset); + if (result == DNS_R_COVERINGNSEC) + goto tree_exit; + } if (search.zonecut != NULL) { result = setup_delegation(&search, nodep, foundname, rdataset, sigrdataset); @@ -2820,7 +2930,7 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, found = NULL; foundsig = NULL; sigtype = RBTDB_RDATATYPE_VALUE(dns_rdatatype_rrsig, type); - nsecype = RBTDB_RDATATYPE_VALUE(0, type); + nsectype = RBTDB_RDATATYPE_VALUE(0, type); nsheader = NULL; nssig = NULL; cnamesig = NULL; @@ -2848,8 +2958,7 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, node->dirty = 1; header_prev = header; } - } else if ((header->attributes & RDATASET_ATTR_NONEXISTENT) - == 0) { + } else if (EXISTS(header)) { /* * We now know that there is at least one active * non-stale rdataset at this node. @@ -2891,7 +3000,7 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, */ foundsig = header; } else if (header->type == RBTDB_RDATATYPE_NCACHEANY || - header->type == nsecype) { + header->type == nsectype) { /* * We've found a negative cache entry. */ @@ -3116,8 +3225,7 @@ cache_findzonecut(dns_db_t *db, dns_name_t *name, unsigned int options, node->dirty = 1; header_prev = header; } - } else if ((header->attributes & RDATASET_ATTR_NONEXISTENT) - == 0) { + } else if (EXISTS(header)) { /* * If we found a type we were looking for, remember * it. @@ -3180,6 +3288,7 @@ attachnode(dns_db_t *db, dns_dbnode_t *source, dns_dbnode_t **targetp) { dns_rbtnode_t *node = (dns_rbtnode_t *)source; REQUIRE(VALID_RBTDB(rbtdb)); + REQUIRE(targetp != NULL && *targetp == NULL); LOCK(&rbtdb->node_locks[node->locknum].lock); INSIST(node->references > 0); @@ -3450,8 +3559,7 @@ zone_findrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version, * Is this a "this rdataset doesn't * exist" record? */ - if ((header->attributes & - RDATASET_ATTR_NONEXISTENT) != 0) + if (NONEXISTENT(header)) header = NULL; break; } else @@ -3501,7 +3609,7 @@ cache_findrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version, dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)db; dns_rbtnode_t *rbtnode = (dns_rbtnode_t *)node; rdatasetheader_t *header, *header_next, *found, *foundsig; - rbtdb_rdatatype_t matchtype, sigmatchtype, nsecype; + rbtdb_rdatatype_t matchtype, sigmatchtype, nsectype; isc_result_t result; REQUIRE(VALID_RBTDB(rbtdb)); @@ -3519,7 +3627,7 @@ cache_findrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version, found = NULL; foundsig = NULL; matchtype = RBTDB_RDATATYPE_VALUE(type, covers); - nsecype = RBTDB_RDATATYPE_VALUE(0, type); + nsectype = RBTDB_RDATATYPE_VALUE(0, type); if (covers == 0) sigmatchtype = RBTDB_RDATATYPE_VALUE(dns_rdatatype_rrsig, type); else @@ -3536,12 +3644,11 @@ cache_findrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version, */ header->attributes |= RDATASET_ATTR_STALE; rbtnode->dirty = 1; - } else if ((header->attributes & RDATASET_ATTR_NONEXISTENT) == - 0) { + } else if (EXISTS(header)) { if (header->type == matchtype) found = header; else if (header->type == RBTDB_RDATATYPE_NCACHEANY || - header->type == nsecype) + header->type == nsectype) found = header; else if (header->type == sigmatchtype) foundsig = header; @@ -3671,10 +3778,13 @@ cname_and_other_data(dns_rbtnode_t *node, rbtdb_serial_t serial) { * or RRSIG CNAME. */ rdtype = RBTDB_RDATATYPE_BASE(header->type); - if (rdtype == dns_rdatatype_rrsig) + if (rdtype == dns_rdatatype_rrsig || + rdtype == dns_rdatatype_sig) rdtype = RBTDB_RDATATYPE_EXT(header->type); if (rdtype != dns_rdatatype_nsec && rdtype != dns_rdatatype_dnskey && + rdtype != dns_rdatatype_nxt && + rdtype != dns_rdatatype_key && rdtype != dns_rdatatype_cname) { /* * We've found a type that isn't @@ -3718,7 +3828,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion, isc_boolean_t header_nx; isc_boolean_t newheader_nx; isc_boolean_t merge; - dns_rdatatype_t nsecype, rdtype, covers; + dns_rdatatype_t nsectype, rdtype, covers; dns_trust_t trust; /* @@ -3756,7 +3866,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion, newheader_nx = NONEXISTENT(newheader) ? ISC_TRUE : ISC_FALSE; topheader_prev = NULL; - nsecype = 0; + nsectype = 0; if (rbtversion == NULL && !newheader_nx) { rdtype = RBTDB_RDATATYPE_BASE(newheader->type); if (rdtype == 0) { @@ -3783,7 +3893,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion, rbtnode->dirty = 1; goto find_header; } - nsecype = RBTDB_RDATATYPE_VALUE(covers, 0); + nsectype = RBTDB_RDATATYPE_VALUE(covers, 0); } else { /* * We're adding something that isn't a @@ -3823,7 +3933,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion, topheader = NULL; goto find_header; } - nsecype = RBTDB_RDATATYPE_VALUE(0, rdtype); + nsectype = RBTDB_RDATATYPE_VALUE(0, rdtype); } } @@ -3831,7 +3941,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion, topheader != NULL; topheader = topheader->next) { if (topheader->type == newheader->type || - topheader->type == nsecype) + topheader->type == nsectype) break; topheader_prev = topheader; } @@ -4092,8 +4202,10 @@ addnoqname(dns_rbtdb_t *rbtdb, rdatasetheader_t *newheader, RUNTIME_CHECK(result == ISC_R_SUCCESS); noqname = isc_mem_get(mctx, sizeof(*noqname)); - if (noqname == NULL) - return (ISC_R_NOMEMORY); + if (noqname == NULL) { + result = ISC_R_NOMEMORY; + goto cleanup; + } dns_name_init(&noqname->name, NULL); noqname->nsec = NULL; noqname->nsecsig = NULL; @@ -4114,6 +4226,8 @@ addnoqname(dns_rbtdb_t *rbtdb, rdatasetheader_t *newheader, return (ISC_R_SUCCESS); cleanup: + dns_rdataset_disassociate(&nsec); + dns_rdataset_disassociate(&nsecsig); free_noqname(mctx, &noqname); return(result); } @@ -4956,7 +5070,7 @@ static void rdataset_clone(dns_rdataset_t *source, dns_rdataset_t *target) { dns_db_t *db = source->private1; dns_dbnode_t *node = source->private2; - dns_dbnode_t *cloned_node; + dns_dbnode_t *cloned_node = NULL; attachnode(db, node, &cloned_node); *target = *source; @@ -4987,9 +5101,8 @@ rdataset_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name, dns_dbnode_t *cloned_node; struct noqname *noqname = rdataset->private6; + cloned_node = NULL; attachnode(db, node, &cloned_node); - attachnode(db, node, &cloned_node); - nsec->methods = &rdataset_methods; nsec->rdclass = db->rdclass; nsec->type = dns_rdatatype_nsec; @@ -5003,6 +5116,8 @@ rdataset_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name, nsec->private5 = NULL; nsec->private6 = NULL; + cloned_node = NULL; + attachnode(db, node, &cloned_node); nsecsig->methods = &rdataset_methods; nsecsig->rdclass = db->rdclass; nsecsig->type = dns_rdatatype_rrsig; @@ -5021,7 +5136,6 @@ rdataset_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name, return (ISC_R_SUCCESS); } - /* * Rdataset Iterator Methods */ diff --git a/dist/bind/lib/dns/rdata/generic/rrsig_46.c b/dist/bind/lib/dns/rdata/generic/rrsig_46.c index 3089a64f38b..887bec85d5a 100644 --- a/dist/bind/lib/dns/rdata/generic/rrsig_46.c +++ b/dist/bind/lib/dns/rdata/generic/rrsig_46.c @@ -1,4 +1,4 @@ -/* $NetBSD: rrsig_46.c,v 1.1.1.1 2004/05/17 23:45:00 christos Exp $ */ +/* $NetBSD: rrsig_46.c,v 1.1.1.2 2004/11/06 23:55:47 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: rrsig_46.c,v 1.4.2.2 2004/03/16 12:38:14 marka Exp */ +/* Id: rrsig_46.c,v 1.4.2.3 2004/06/24 00:58:06 marka Exp */ /* Reviewed: Fri Mar 17 09:05:02 PST 2000 by gson */ @@ -156,8 +156,8 @@ totext_rrsig(ARGS_TOTEXT) { if (dns_rdatatype_isknown(covered) && covered != 0) { RETERR(dns_rdatatype_totext(covered, target)); } else { - char buf[sizeof("65535")]; - sprintf(buf, "%u", covered); + char buf[sizeof("TYPE65535")]; + sprintf(buf, "TYPE%u", covered); RETERR(str_totext(buf, target)); } RETERR(str_totext(" ", target)); diff --git a/dist/bind/lib/dns/resolver.c b/dist/bind/lib/dns/resolver.c index 4b953db42f1..ee58adf8d24 100644 --- a/dist/bind/lib/dns/resolver.c +++ b/dist/bind/lib/dns/resolver.c @@ -1,4 +1,4 @@ -/* $NetBSD: resolver.c,v 1.1.1.1 2004/05/17 23:44:54 christos Exp $ */ +/* $NetBSD: resolver.c,v 1.1.1.2 2004/11/06 23:55:41 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,10 +17,11 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: resolver.c,v 1.218.2.18.4.36 2004/04/19 23:41:33 marka Exp */ +/* Id: resolver.c,v 1.218.2.18.4.43 2004/08/28 06:25:19 marka Exp */ #include <config.h> +#include <isc/print.h> #include <isc/string.h> #include <isc/task.h> #include <isc/timer.h> @@ -67,25 +68,28 @@ DNS_LOGCATEGORY_RESOLVER, \ DNS_LOGMODULE_RESOLVER, \ ISC_LOG_DEBUG(3), \ - "fctx %p: %s", fctx, (m)) + "fctx %p(%s'): %s", fctx, fctx->info, (m)) #define FCTXTRACE2(m1, m2) \ isc_log_write(dns_lctx, \ DNS_LOGCATEGORY_RESOLVER, \ DNS_LOGMODULE_RESOLVER, \ ISC_LOG_DEBUG(3), \ - "fctx %p: %s %s", fctx, (m1), (m2)) + "fctx %p(%s): %s %s", \ + fctx, fctx->info, (m1), (m2)) #define FTRACE(m) isc_log_write(dns_lctx, \ DNS_LOGCATEGORY_RESOLVER, \ DNS_LOGMODULE_RESOLVER, \ ISC_LOG_DEBUG(3), \ - "fetch %p (fctx %p): %s", \ - fetch, fetch->private, (m)) + "fetch %p (fctx %p(%s)): %s", \ + fetch, fetch->private, \ + fetch->private->info, (m)) #define QTRACE(m) isc_log_write(dns_lctx, \ DNS_LOGCATEGORY_RESOLVER, \ DNS_LOGMODULE_RESOLVER, \ ISC_LOG_DEBUG(3), \ - "resquery %p (fctx %p): %s", \ - query, query->fctx, (m)) + "resquery %p (fctx %p(%s)): %s", \ + query, query->fctx, \ + query->fctx->info, (m)) #else #define RTRACE(m) #define RRTRACE(r, m) @@ -154,6 +158,7 @@ struct fetchctx { dns_rdatatype_t type; unsigned int options; unsigned int bucketnum; + char * info; /* Locked by appropriate bucket lock. */ fetchstate state; isc_boolean_t want_shutdown; @@ -1123,6 +1128,8 @@ resquery_send(resquery_t *query) { &secure_domain); if (result != ISC_R_SUCCESS) secure_domain = ISC_FALSE; + if (res->view->dlv != NULL) + secure_domain = ISC_TRUE; if (secure_domain) fctx->qmessage->flags |= DNS_MESSAGEFLAG_CD; } else @@ -1817,8 +1824,23 @@ fctx_getaddresses(fetchctx_t *fctx) { sa = ISC_LIST_HEAD(fctx->forwarders); if (sa == NULL) { dns_forwarders_t *forwarders = NULL; - result = dns_fwdtable_find(fctx->res->view->fwdtable, - &fctx->name, &forwarders); + dns_name_t *name = &fctx->name; + dns_name_t suffix; + unsigned int labels; + + /* + * DS records are found in the parent server. + * Strip label to get the correct forwarder (if any). + */ + if (fctx->type == dns_rdatatype_ds && + dns_name_countlabels(name) > 1) { + dns_name_init(&suffix, NULL); + labels = dns_name_countlabels(name); + dns_name_getlabelsequence(name, 1, labels - 1, &suffix); + name = &suffix; + } + result = dns_fwdtable_find(fctx->res->view->fwdtable, name, + &forwarders); if (result == ISC_R_SUCCESS) { sa = ISC_LIST_HEAD(forwarders->addrs); fctx->fwdpolicy = forwarders->fwdpolicy; @@ -2055,7 +2077,7 @@ possibly_mark(fetchctx_t *fctx, dns_adbaddrinfo_t *addr) static inline dns_adbaddrinfo_t * fctx_nextaddress(fetchctx_t *fctx) { - dns_adbfind_t *find; + dns_adbfind_t *find, *start; dns_adbaddrinfo_t *addrinfo; dns_adbaddrinfo_t *faddrinfo; @@ -2098,23 +2120,26 @@ fctx_nextaddress(fetchctx_t *fctx) { * Find the first unmarked addrinfo. */ addrinfo = NULL; - while (find != fctx->find) { - for (addrinfo = ISC_LIST_HEAD(find->list); - addrinfo != NULL; - addrinfo = ISC_LIST_NEXT(addrinfo, publink)) { - if (!UNMARKED(addrinfo)) - continue; - possibly_mark(fctx, addrinfo); - if (UNMARKED(addrinfo)) { - addrinfo->flags |= FCTX_ADDRINFO_MARK; - break; + if (find != NULL) { + start = find; + do { + for (addrinfo = ISC_LIST_HEAD(find->list); + addrinfo != NULL; + addrinfo = ISC_LIST_NEXT(addrinfo, publink)) { + if (!UNMARKED(addrinfo)) + continue; + possibly_mark(fctx, addrinfo); + if (UNMARKED(addrinfo)) { + addrinfo->flags |= FCTX_ADDRINFO_MARK; + break; + } } - } - if (addrinfo != NULL) - break; - find = ISC_LIST_NEXT(find, publink); - if (find != fctx->find && find == NULL) - find = ISC_LIST_HEAD(fctx->finds); + if (addrinfo != NULL) + break; + find = ISC_LIST_NEXT(find, publink); + if (find == NULL) + find = ISC_LIST_HEAD(fctx->finds); + } while (find != start); } fctx->find = find; @@ -2140,23 +2165,26 @@ fctx_nextaddress(fetchctx_t *fctx) { * Find the first unmarked addrinfo. */ addrinfo = NULL; - while (find != fctx->altfind) { - for (addrinfo = ISC_LIST_HEAD(find->list); - addrinfo != NULL; - addrinfo = ISC_LIST_NEXT(addrinfo, publink)) { - if (!UNMARKED(addrinfo)) - continue; - possibly_mark(fctx, addrinfo); - if (UNMARKED(addrinfo)) { - addrinfo->flags |= FCTX_ADDRINFO_MARK; - break; + if (find != NULL) { + start = find; + do { + for (addrinfo = ISC_LIST_HEAD(find->list); + addrinfo != NULL; + addrinfo = ISC_LIST_NEXT(addrinfo, publink)) { + if (!UNMARKED(addrinfo)) + continue; + possibly_mark(fctx, addrinfo); + if (UNMARKED(addrinfo)) { + addrinfo->flags |= FCTX_ADDRINFO_MARK; + break; + } } - } - if (addrinfo != NULL) - break; - find = ISC_LIST_NEXT(find, publink); - if (find != fctx->altfind && find == NULL) - find = ISC_LIST_HEAD(fctx->altfinds); + if (addrinfo != NULL) + break; + find = ISC_LIST_NEXT(find, publink); + if (find == NULL) + find = ISC_LIST_HEAD(fctx->altfinds); + } while (find != start); } faddrinfo = addrinfo; @@ -2289,6 +2317,7 @@ fctx_destroy(fetchctx_t *fctx) { dns_name_free(&fctx->name, res->mctx); dns_db_detach(&fctx->cache); dns_adb_detach(&fctx->adb); + isc_mem_free(res->mctx, fctx->info); isc_mem_put(res->mctx, fctx, sizeof(*fctx)); LOCK(&res->nlock); @@ -2577,6 +2606,9 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type, isc_interval_t interval; dns_fixedname_t qdomain; unsigned int findoptions = 0; + char buf[DNS_NAME_FORMATSIZE + DNS_RDATATYPE_FORMATSIZE]; + char typebuf[DNS_RDATATYPE_FORMATSIZE]; + dns_name_t suffix; /* * Caller must be holding the lock for bucket number 'bucketnum'. @@ -2586,11 +2618,18 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type, fctx = isc_mem_get(res->mctx, sizeof(*fctx)); if (fctx == NULL) return (ISC_R_NOMEMORY); + dns_name_format(name, buf, sizeof(buf)); + dns_rdatatype_format(type, typebuf, sizeof(typebuf)); + strcat(buf, "/"); /* checked */ + strcat(buf, typebuf); /* checked */ + fctx->info = isc_mem_strdup(res->mctx, buf); + if (fctx->info == NULL) + goto cleanup_fetch; FCTXTRACE("create"); dns_name_init(&fctx->name, NULL); result = dns_name_dup(name, res->mctx, &fctx->name); if (result != ISC_R_SUCCESS) - goto cleanup_fetch; + goto cleanup_info; dns_name_init(&fctx->domain, NULL); dns_rdataset_init(&fctx->nameservers); @@ -2629,8 +2668,21 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type, if (domain == NULL) { dns_forwarders_t *forwarders = NULL; - result = dns_fwdtable_find(fctx->res->view->fwdtable, - &fctx->name, &forwarders); + unsigned int labels; + + /* + * DS records are found in the parent server. + * Strip label to get the correct forwarder (if any). + */ + if (fctx->type == dns_rdatatype_ds && + dns_name_countlabels(name) > 1) { + dns_name_init(&suffix, NULL); + labels = dns_name_countlabels(name); + dns_name_getlabelsequence(name, 1, labels - 1, &suffix); + name = &suffix; + } + result = dns_fwdtable_find(fctx->res->view->fwdtable, name, + &forwarders); if (result == ISC_R_SUCCESS) fctx->fwdpolicy = forwarders->fwdpolicy; @@ -2763,6 +2815,9 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type, cleanup_name: dns_name_free(&fctx->name, res->mctx); + cleanup_info: + isc_mem_free(res->mctx, fctx->info); + cleanup_fetch: isc_mem_put(res->mctx, fctx, sizeof(*fctx)); @@ -3093,7 +3148,6 @@ validated(isc_task_t *task, isc_event_t *event) { ardataset, &eresult); if (result != ISC_R_SUCCESS) goto noanswer_response; - goto answer_response; } @@ -3154,8 +3208,9 @@ validated(isc_task_t *task, isc_event_t *event) { goto cleanup_event; } + answer_response: /* - * Cache any NS records that happened to be validate. + * Cache any NS/NSEC records that happened to be validated. */ result = dns_message_firstname(fctx->rmessage, DNS_SECTION_AUTHORITY); while (result == ISC_R_SUCCESS) { @@ -3165,14 +3220,15 @@ validated(isc_task_t *task, isc_event_t *event) { for (rdataset = ISC_LIST_HEAD(name->list); rdataset != NULL; rdataset = ISC_LIST_NEXT(rdataset, link)) { - if (rdataset->type != dns_rdatatype_ns || + if ((rdataset->type != dns_rdatatype_ns && + rdataset->type != dns_rdatatype_nsec) || rdataset->trust != dns_trust_secure) continue; for (sigrdataset = ISC_LIST_HEAD(name->list); sigrdataset != NULL; sigrdataset = ISC_LIST_NEXT(sigrdataset, link)) { if (sigrdataset->type != dns_rdatatype_rrsig || - sigrdataset->covers != dns_rdatatype_ns) + sigrdataset->covers != rdataset->type) continue; break; } @@ -3199,7 +3255,6 @@ validated(isc_task_t *task, isc_event_t *event) { result = ISC_R_SUCCESS; - answer_response: /* * Respond with an answer, positive or negative, * as opposed to an error. 'node' must be non-NULL. @@ -3264,6 +3319,9 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) { if (result != ISC_R_SUCCESS) return (result); + if (res->view->dlv != NULL) + secure_domain = ISC_TRUE; + if ((fctx->options & DNS_FETCHOPT_NOVALIDATE) != 0) need_validation = ISC_FALSE; else @@ -3688,6 +3746,9 @@ ncache_message(fetchctx_t *fctx, dns_rdatatype_t covers, isc_stdtime_t now) { if (result != ISC_R_SUCCESS) return (result); + if (res->view->dlv != NULL) + secure_domain = ISC_TRUE; + if ((fctx->options & DNS_FETCHOPT_NOVALIDATE) != 0) need_validation = ISC_FALSE; else @@ -4693,6 +4754,9 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) { isc_boolean_t bucket_empty = ISC_FALSE; isc_boolean_t locked = ISC_FALSE; unsigned int bucketnum; + dns_rdataset_t nameservers; + dns_fixedname_t fixed; + dns_name_t *domain; REQUIRE(event->ev_type == DNS_EVENT_FETCHDONE); fevent = (dns_fetchevent_t *)event; @@ -4708,15 +4772,17 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) { if (fevent->db != NULL) dns_db_detach(&fevent->db); - dns_resolver_destroyfetch(&fctx->nsfetch); + dns_rdataset_init(&nameservers); bucketnum = fctx->bucketnum; - if (fevent->result == ISC_R_CANCELED) + if (fevent->result == ISC_R_CANCELED) { + dns_resolver_destroyfetch(&fctx->nsfetch); fctx_done(fctx, ISC_R_CANCELED); - else if (fevent->result == ISC_R_SUCCESS) { + } else if (fevent->result == ISC_R_SUCCESS) { FCTXTRACE("resuming DS lookup"); + dns_resolver_destroyfetch(&fctx->nsfetch); if (dns_rdataset_isassociated(&fctx->nameservers)) dns_rdataset_disassociate(&fctx->nameservers); dns_rdataset_clone(fevent->rdataset, &fctx->nameservers); @@ -4735,22 +4801,29 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) { } else { unsigned int n; + /* + * Retrieve state from fctx->nsfetch before we destroy it. + */ + dns_fixedname_init(&fixed); + domain = dns_fixedname_name(&fixed); + dns_name_copy(&fctx->nsfetch->private->domain, domain, NULL); + dns_rdataset_clone(&fctx->nsfetch->private->nameservers, + &nameservers); + dns_resolver_destroyfetch(&fctx->nsfetch); + if (dns_name_equal(&fctx->nsname, domain)) { + fctx_done(fctx, DNS_R_SERVFAIL); + goto cleanup; + } n = dns_name_countlabels(&fctx->nsname); dns_name_getlabelsequence(&fctx->nsname, 1, n - 1, &fctx->nsname); - if (dns_name_equal(&fctx->nsname, &fctx->domain)) { - fctx_done(fctx, DNS_R_SERVFAIL); - goto cleanup; - } if (dns_rdataset_isassociated(fevent->rdataset)) dns_rdataset_disassociate(fevent->rdataset); FCTXTRACE("continuing to look for parent's NS records"); result = dns_resolver_createfetch(fctx->res, &fctx->nsname, - dns_rdatatype_ns, - &fctx->domain, - &fctx->nameservers, NULL, - 0, task, + dns_rdatatype_ns, domain, + &nameservers, NULL, 0, task, resume_dslookup, fctx, &fctx->nsrrset, NULL, &fctx->nsfetch); @@ -4764,6 +4837,8 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) { } cleanup: + if (dns_rdataset_isassociated(&nameservers)) + dns_rdataset_disassociate(&nameservers); if (dns_rdataset_isassociated(fevent->rdataset)) dns_rdataset_disassociate(fevent->rdataset); INSIST(fevent->sigrdataset == NULL); diff --git a/dist/bind/lib/dns/result.c b/dist/bind/lib/dns/result.c index 09163c77492..f4b2ecdb8e9 100644 --- a/dist/bind/lib/dns/result.c +++ b/dist/bind/lib/dns/result.c @@ -1,4 +1,4 @@ -/* $NetBSD: result.c,v 1.1.1.1 2004/05/17 23:44:54 christos Exp $ */ +/* $NetBSD: result.c,v 1.1.1.2 2004/11/06 23:55:41 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: result.c,v 1.90.2.9.2.12 2004/04/15 23:56:30 marka Exp */ +/* Id: result.c,v 1.90.2.9.2.13 2004/05/14 05:06:39 marka Exp */ #include <config.h> @@ -152,7 +152,8 @@ static const char *text[DNS_R_NRESULTS] = { "dynamic zone", /* 98 DNS_R_DYNAMIC */ "unknown command", /* 99 DNS_R_UNKNOWNCOMMAND */ - "must-be-secure" /* 100 DNS_R_MUSTBESECURE */ + "must-be-secure", /* 100 DNS_R_MUSTBESECURE */ + "covering NSEC record returned" /* 101 DNS_R_COVERINGNSEC */ }; static const char *rcode_text[DNS_R_NRCODERESULTS] = { diff --git a/dist/bind/lib/dns/sdb.c b/dist/bind/lib/dns/sdb.c index 97a429bcfde..34c04ba8cba 100644 --- a/dist/bind/lib/dns/sdb.c +++ b/dist/bind/lib/dns/sdb.c @@ -1,4 +1,4 @@ -/* $NetBSD: sdb.c,v 1.1.1.1 2004/05/17 23:44:54 christos Exp $ */ +/* $NetBSD: sdb.c,v 1.1.1.2 2004/11/06 23:55:42 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: sdb.c,v 1.35.12.7 2004/03/08 21:06:27 marka Exp */ +/* Id: sdb.c,v 1.35.12.8 2004/07/22 04:01:58 marka Exp */ #include <config.h> @@ -631,10 +631,10 @@ attachversion(dns_db_t *db, dns_dbversion_t *source, dns_dbversion_t **targetp) { REQUIRE(source != NULL && source == (void *) &dummy); + REQUIRE(targetp != NULL && *targetp == NULL); UNUSED(db); - UNUSED(source); - UNUSED(targetp); + *targetp = source; return; } diff --git a/dist/bind/lib/dns/sec/dst/dst_api.c b/dist/bind/lib/dns/sec/dst/dst_api.c index d8f11f5c9d2..9321870a205 100644 --- a/dist/bind/lib/dns/sec/dst/dst_api.c +++ b/dist/bind/lib/dns/sec/dst/dst_api.c @@ -1,4 +1,4 @@ -/* $NetBSD: dst_api.c,v 1.1.1.1 2004/05/17 23:45:00 christos Exp $ */ +/* $NetBSD: dst_api.c,v 1.1.1.2 2004/11/06 23:55:47 christos Exp $ */ /* * Portions Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -20,7 +20,7 @@ /* * Principal Author: Brian Wellington - * Id: dst_api.c,v 1.88.2.3.2.12 2004/03/16 05:50:22 marka Exp + * Id: dst_api.c,v 1.88.2.3.2.15 2004/06/16 01:05:01 marka Exp */ #include <config.h> @@ -72,6 +72,7 @@ static dst_key_t * get_key_struct(dns_name_t *name, dns_rdataclass_t rdclass, isc_mem_t *mctx); static isc_result_t read_public_key(const char *filename, + int type, isc_mem_t *mctx, dst_key_t **keyp); static isc_result_t write_public_key(const dst_key_t *key, int type, @@ -147,9 +148,11 @@ dst_lib_init(isc_mem_t *mctx, isc_entropy_t *ectx, unsigned int eflags) { RETERR(dst__openssl_init()); RETERR(dst__opensslrsa_init(&dst_t_func[DST_ALG_RSAMD5])); RETERR(dst__opensslrsa_init(&dst_t_func[DST_ALG_RSASHA1])); +#ifdef HAVE_OPENSSL_DSA RETERR(dst__openssldsa_init(&dst_t_func[DST_ALG_DSA])); - RETERR(dst__openssldh_init(&dst_t_func[DST_ALG_DH])); #endif + RETERR(dst__openssldh_init(&dst_t_func[DST_ALG_DH])); +#endif /* OPENSSL */ #ifdef GSSAPI RETERR(dst__gssapi_init(&dst_t_func[DST_ALG_GSSAPI])); #endif @@ -391,7 +394,7 @@ dst_key_fromnamedfile(const char *filename, int type, isc_mem_t *mctx, REQUIRE(mctx != NULL); REQUIRE(keyp != NULL && *keyp == NULL); - result = read_public_key(filename, mctx, &pubkey); + result = read_public_key(filename, type, mctx, &pubkey); if (result != ISC_R_SUCCESS) return (result); @@ -825,7 +828,9 @@ get_key_struct(dns_name_t *name, unsigned int alg, * Reads a public key from disk */ static isc_result_t -read_public_key(const char *filename, isc_mem_t *mctx, dst_key_t **keyp) { +read_public_key(const char *filename, int type, + isc_mem_t *mctx, dst_key_t **keyp) +{ u_char rdatabuf[DST_KEY_MAXSIZE]; isc_buffer_t b; dns_fixedname_t name; @@ -840,7 +845,7 @@ read_public_key(const char *filename, isc_mem_t *mctx, dst_key_t **keyp) { isc_lexspecials_t specials; isc_uint32_t ttl; isc_result_t result; - dns_rdatatype_t type; + dns_rdatatype_t keytype; newfilenamelen = strlen(filename) + 5; newfilename = isc_mem_get(mctx, newfilenamelen); @@ -913,14 +918,20 @@ read_public_key(const char *filename, isc_mem_t *mctx, dst_key_t **keyp) { BADTOKEN(); if (strcasecmp(DST_AS_STR(token), "DNSKEY") == 0) - type = dns_rdatatype_dnskey; + keytype = dns_rdatatype_dnskey; else if (strcasecmp(DST_AS_STR(token), "KEY") == 0) - type = dns_rdatatype_key; /* SIG(0) */ + keytype = dns_rdatatype_key; /* SIG(0), TKEY */ else BADTOKEN(); + if (((type & DST_TYPE_KEY) != 0 && keytype != dns_rdatatype_key) || + ((type & DST_TYPE_KEY) == 0 && keytype != dns_rdatatype_dnskey)) { + ret = DST_R_BADKEYTYPE; + goto cleanup; + } + isc_buffer_init(&b, rdatabuf, sizeof(rdatabuf)); - ret = dns_rdata_fromtext(&rdata, rdclass, type, lex, NULL, + ret = dns_rdata_fromtext(&rdata, rdclass, keytype, lex, NULL, ISC_FALSE, mctx, &b, NULL); if (ret != ISC_R_SUCCESS) goto cleanup; @@ -1138,10 +1149,12 @@ algorithm_status(unsigned int alg) { if (dst_algorithm_supported(alg)) return (ISC_R_SUCCESS); +#ifndef OPENSSL if (alg == DST_ALG_RSAMD5 || alg == DST_ALG_RSASHA1 || alg == DST_ALG_DSA || alg == DST_ALG_DH || alg == DST_ALG_HMACMD5) return (DST_R_NOCRYPTO); +#endif return (DST_R_UNSUPPORTEDALG); } diff --git a/dist/bind/lib/dns/sec/dst/dst_result.c b/dist/bind/lib/dns/sec/dst/dst_result.c index 18a8fd21efe..27a1460215a 100644 --- a/dist/bind/lib/dns/sec/dst/dst_result.c +++ b/dist/bind/lib/dns/sec/dst/dst_result.c @@ -1,4 +1,4 @@ -/* $NetBSD: dst_result.c,v 1.1.1.1 2004/05/17 23:45:00 christos Exp $ */ +/* $NetBSD: dst_result.c,v 1.1.1.2 2004/11/06 23:55:47 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -19,7 +19,7 @@ /* * Principal Author: Brian Wellington - * Id: dst_result.c,v 1.18.2.1.8.1 2004/03/06 08:14:21 marka Exp + * Id: dst_result.c,v 1.18.2.1.8.2 2004/06/11 00:30:55 marka Exp */ #include <config.h> @@ -51,6 +51,7 @@ static const char *text[DST_R_NRESULTS] = { "not a key that can compute a secret", /* 17 */ "failure computing a shared secret", /* 18 */ "no randomness available", /* 19 */ + "bad key type" /* 20 */ }; #define DST_RESULT_RESULTSET 2 diff --git a/dist/bind/lib/dns/sec/dst/include/dst/dst.h b/dist/bind/lib/dns/sec/dst/include/dst/dst.h index 7c4cc965da3..87392da810b 100644 --- a/dist/bind/lib/dns/sec/dst/include/dst/dst.h +++ b/dist/bind/lib/dns/sec/dst/include/dst/dst.h @@ -1,4 +1,4 @@ -/* $NetBSD: dst.h,v 1.1.1.1 2004/05/17 23:45:01 christos Exp $ */ +/* $NetBSD: dst.h,v 1.1.1.2 2004/11/06 23:55:48 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: dst.h,v 1.42.2.1.8.5 2004/03/10 02:55:59 marka Exp */ +/* Id: dst.h,v 1.42.2.1.8.6 2004/06/11 00:31:01 marka Exp */ #ifndef DST_DST_H #define DST_DST_H 1 @@ -220,6 +220,7 @@ dst_key_fromfile(dns_name_t *name, dns_keytag_t id, unsigned int alg, int type, * "id" is a valid key tag identifier. * "alg" is a supported key algorithm. * "type" is DST_TYPE_PUBLIC, DST_TYPE_PRIVATE, or the bitwise union. + * DST_TYPE_KEY look for a KEY record otherwise DNSKEY * "mctx" is a valid memory context. * "keyp" is not NULL and "*keyp" is NULL. * @@ -242,6 +243,7 @@ dst_key_fromnamedfile(const char *filename, int type, isc_mem_t *mctx, * Requires: * "filename" is not NULL * "type" is DST_TYPE_PUBLIC, DST_TYPE_PRIVATE, or the bitwise union + * DST_TYPE_KEY look for a KEY record otherwise DNSKEY * "mctx" is a valid memory context * "keyp" is not NULL and "*keyp" is NULL. * diff --git a/dist/bind/lib/dns/sec/dst/include/dst/result.h b/dist/bind/lib/dns/sec/dst/include/dst/result.h index 36bd3cd9f96..73d5d1d9e49 100644 --- a/dist/bind/lib/dns/sec/dst/include/dst/result.h +++ b/dist/bind/lib/dns/sec/dst/include/dst/result.h @@ -1,4 +1,4 @@ -/* $NetBSD: result.h,v 1.1.1.1 2004/05/17 23:45:01 christos Exp $ */ +/* $NetBSD: result.h,v 1.1.1.2 2004/11/06 23:55:48 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: result.h,v 1.20.206.1 2004/03/06 08:14:25 marka Exp */ +/* Id: result.h,v 1.20.206.2 2004/06/11 00:31:01 marka Exp */ #ifndef DST_RESULT_H #define DST_RESULT_H 1 @@ -53,8 +53,9 @@ #define DST_R_KEYCANNOTCOMPUTESECRET (ISC_RESULTCLASS_DST + 17) #define DST_R_COMPUTESECRETFAILURE (ISC_RESULTCLASS_DST + 18) #define DST_R_NORANDOMNESS (ISC_RESULTCLASS_DST + 19) +#define DST_R_BADKEYTYPE (ISC_RESULTCLASS_DST + 20) -#define DST_R_NRESULTS 20 /* Number of results */ +#define DST_R_NRESULTS 21 /* Number of results */ ISC_LANG_BEGINDECLS diff --git a/dist/bind/lib/dns/time.c b/dist/bind/lib/dns/time.c index 7e1d13f343d..e216aeb41d9 100644 --- a/dist/bind/lib/dns/time.c +++ b/dist/bind/lib/dns/time.c @@ -1,4 +1,4 @@ -/* $NetBSD: time.c,v 1.1.1.1 2004/05/17 23:44:55 christos Exp $ */ +/* $NetBSD: time.c,v 1.1.1.2 2004/11/06 23:55:42 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: time.c,v 1.18.2.4.2.7 2004/03/11 04:23:00 marka Exp */ +/* Id: time.c,v 1.18.2.4.2.8 2004/08/28 06:25:20 marka Exp */ #include <config.h> @@ -25,6 +25,7 @@ #include <isc/string.h> /* Required for HP/UX (and others?) */ #include <time.h> +#include <isc/print.h> #include <isc/region.h> #include <isc/stdtime.h> #include <isc/util.h> diff --git a/dist/bind/lib/dns/tkey.c b/dist/bind/lib/dns/tkey.c index d03b2fa5338..4648741e1ac 100644 --- a/dist/bind/lib/dns/tkey.c +++ b/dist/bind/lib/dns/tkey.c @@ -1,4 +1,4 @@ -/* $NetBSD: tkey.c,v 1.1.1.1 2004/05/17 23:44:55 christos Exp $ */ +/* $NetBSD: tkey.c,v 1.1.1.2 2004/11/06 23:55:42 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -18,7 +18,7 @@ */ /* - * Id: tkey.c,v 1.71.2.1.10.4 2004/03/08 02:07:58 marka Exp + * Id: tkey.c,v 1.71.2.1.10.5 2004/06/11 00:30:54 marka Exp */ #include <config.h> @@ -287,7 +287,7 @@ process_dhtkey(dns_message_t *msg, dns_name_t *signer, dns_name_t *name, keyname = NULL; dns_message_currentname(msg, DNS_SECTION_ADDITIONAL, &keyname); keyset = NULL; - result = dns_message_findtype(keyname, dns_rdatatype_dnskey, 0, + result = dns_message_findtype(keyname, dns_rdatatype_key, 0, &keyset); if (result != ISC_R_SUCCESS) continue; @@ -335,7 +335,7 @@ process_dhtkey(dns_message_t *msg, dns_name_t *signer, dns_name_t *name, RETERR(dst_key_todns(tctx->dhkey, &ourkeybuf)); isc_buffer_usedregion(&ourkeybuf, &ourkeyr); dns_rdata_fromregion(&ourkeyrdata, dns_rdataclass_any, - dns_rdatatype_dnskey, &ourkeyr); + dns_rdatatype_key, &ourkeyr); dns_name_init(&ourname, NULL); dns_name_clone(dst_key_name(tctx->dhkey), &ourname); @@ -879,7 +879,7 @@ dns_tkey_builddhquery(dns_message_t *msg, dst_key_t *key, dns_name_t *name, RETERR(dst_key_todns(key, dynbuf)); isc_buffer_usedregion(dynbuf, &r); dns_rdata_fromregion(rdata, dns_rdataclass_any, - dns_rdatatype_dnskey, &r); + dns_rdatatype_key, &r); dns_message_takebuffer(msg, &dynbuf); dns_name_init(&keyname, NULL); @@ -1051,7 +1051,7 @@ dns_tkey_processdhresponse(dns_message_t *qmsg, dns_message_t *rmsg, ourkeyname = NULL; ourkeyset = NULL; RETERR(dns_message_findname(rmsg, DNS_SECTION_ANSWER, &keyname, - dns_rdatatype_dnskey, 0, &ourkeyname, + dns_rdatatype_key, 0, &ourkeyname, &ourkeyset)); result = dns_message_firstname(rmsg, DNS_SECTION_ANSWER); @@ -1062,7 +1062,7 @@ dns_tkey_processdhresponse(dns_message_t *qmsg, dns_message_t *rmsg, if (dns_name_equal(theirkeyname, ourkeyname)) goto next; theirkeyset = NULL; - result = dns_message_findtype(theirkeyname, dns_rdatatype_dnskey, + result = dns_message_findtype(theirkeyname, dns_rdatatype_key, 0, &theirkeyset); if (result == ISC_R_SUCCESS) { RETERR(dns_rdataset_first(theirkeyset)); diff --git a/dist/bind/lib/dns/validator.c b/dist/bind/lib/dns/validator.c index f5ae6f87430..cbba995a3c9 100644 --- a/dist/bind/lib/dns/validator.c +++ b/dist/bind/lib/dns/validator.c @@ -1,4 +1,4 @@ -/* $NetBSD: validator.c,v 1.1.1.1 2004/05/17 23:44:53 christos Exp $ */ +/* $NetBSD: validator.c,v 1.1.1.2 2004/11/06 23:55:40 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: validator.c,v 1.91.2.5.8.10 2004/04/15 23:56:30 marka Exp */ +/* Id: validator.c,v 1.91.2.5.8.12 2004/06/11 01:17:36 marka Exp */ #include <config.h> @@ -55,6 +55,7 @@ #define VALATTR_INSECURITY 0x0010 #define VALATTR_DLV 0x0020 #define VALATTR_DLVTRIED 0x0040 +#define VALATTR_DLVSEPTRIED 0x0080 #define VALATTR_NEEDNOQNAME 0x0100 #define VALATTR_NEEDNOWILDCARD 0x0200 @@ -70,6 +71,7 @@ #define NEEDNOWILDCARD(val) ((val->attributes & VALATTR_NEEDNOWILDCARD) != 0) #define DLV(val) ((val->attributes & VALATTR_DLV) != 0) #define DLVTRIED(val) ((val->attributes & VALATTR_DLVTRIED) != 0) +#define DLVSEPTRIED(val) ((val->attributes & VALATTR_DLVSEPTRIED) != 0) #define SHUTDOWN(v) (((v)->attributes & VALATTR_SHUTDOWN) != 0) @@ -109,6 +111,9 @@ validator_logcreate(dns_validator_t *val, static isc_result_t dlv_validatezonekey(dns_validator_t *val); +static isc_result_t +finddlvsep(dns_validator_t *val, isc_boolean_t resume); + static void validator_done(dns_validator_t *val, isc_result_t result) { isc_task_t *task; @@ -737,6 +742,16 @@ negauthvalidated(isc_task_t *task, isc_event_t *event) { static inline isc_result_t view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) { + dns_fixedname_t fixedname; + dns_name_t *foundname; + dns_rdata_nsec_t nsec; + dns_rdata_t rdata = DNS_RDATA_INIT; + isc_result_t result; + unsigned int options; + char buf1[DNS_NAME_FORMATSIZE]; + char buf2[DNS_NAME_FORMATSIZE]; + char buf3[DNS_NAME_FORMATSIZE]; + if (dns_rdataset_isassociated(&val->frdataset)) dns_rdataset_disassociate(&val->frdataset); if (dns_rdataset_isassociated(&val->fsigrdataset)) @@ -744,9 +759,106 @@ view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) { if (val->view->zonetable == NULL) return (ISC_R_CANCELED); - return (dns_view_simplefind(val->view, name, type, 0, - DNS_DBFIND_PENDINGOK, ISC_FALSE, - &val->frdataset, &val->fsigrdataset)); + + options = DNS_DBFIND_PENDINGOK; + if (type == dns_rdatatype_dlv) + options |= DNS_DBFIND_COVERINGNSEC; + dns_fixedname_init(&fixedname); + foundname = dns_fixedname_name(&fixedname); + result = dns_view_find(val->view, name, type, 0, options, + ISC_FALSE, NULL, NULL, foundname, + &val->frdataset, &val->fsigrdataset); + if (result == DNS_R_NXDOMAIN) { + if (dns_rdataset_isassociated(&val->frdataset)) + dns_rdataset_disassociate(&val->frdataset); + if (dns_rdataset_isassociated(&val->fsigrdataset)) + dns_rdataset_disassociate(&val->fsigrdataset); + } else if (result == DNS_R_COVERINGNSEC) { + validator_log(val, ISC_LOG_DEBUG(3), "DNS_R_COVERINGNSEC"); + /* + * Check if the returned NSEC covers the name. + */ + INSIST(type == dns_rdatatype_dlv); + if (val->frdataset.trust != dns_trust_secure) { + validator_log(val, ISC_LOG_DEBUG(3), + "covering nsec: trust %u", + val->frdataset.trust); + goto notfound; + } + result = dns_rdataset_first(&val->frdataset); + if (result != ISC_R_SUCCESS) + goto notfound; + dns_rdataset_current(&val->frdataset, &rdata); + if (dns_nsec_typepresent(&rdata, dns_rdatatype_ns) && + !dns_nsec_typepresent(&rdata, dns_rdatatype_soa)) { + /* Parent NSEC record. */ + if (dns_name_issubdomain(name, foundname)) { + validator_log(val, ISC_LOG_DEBUG(3), + "covering nsec: for parent"); + goto notfound; + } + } + result = dns_rdata_tostruct(&rdata, &nsec, NULL); + if (result != ISC_R_SUCCESS) + goto notfound; + if (dns_name_compare(foundname, &nsec.next) >= 0) { + /* End of zone chain. */ + if (!dns_name_issubdomain(name, &nsec.next)) { + /* + * XXXMPA We could look for a parent NSEC + * at nsec.next and if found retest with + * this NSEC. + */ + dns_rdata_freestruct(&nsec); + validator_log(val, ISC_LOG_DEBUG(3), + "covering nsec: not in zone"); + goto notfound; + } + } else if (dns_name_compare(name, &nsec.next) >= 0) { + /* + * XXXMPA We could check if this NSEC is at a zone + * apex and if the qname is not below it and look for + * a parent NSEC with the same name. This requires + * that we can cache both NSEC records which we + * currently don't support. + */ + dns_rdata_freestruct(&nsec); + validator_log(val, ISC_LOG_DEBUG(3), + "covering nsec: not in range"); + goto notfound; + } + if (isc_log_wouldlog(dns_lctx,ISC_LOG_DEBUG(3))) { + dns_name_format(name, buf1, sizeof buf1); + dns_name_format(foundname, buf2, sizeof buf2); + dns_name_format(&nsec.next, buf3, sizeof buf3); + validator_log(val, ISC_LOG_DEBUG(3), + "covering nsec found: '%s' '%s' '%s'", + buf1, buf2, buf3); + } + if (dns_rdataset_isassociated(&val->frdataset)) + dns_rdataset_disassociate(&val->frdataset); + if (dns_rdataset_isassociated(&val->fsigrdataset)) + dns_rdataset_disassociate(&val->fsigrdataset); + dns_rdata_freestruct(&nsec); + result = DNS_R_NCACHENXDOMAIN; + } else if (result != ISC_R_SUCCESS && + result != DNS_R_GLUE && + result != DNS_R_HINT && + result != DNS_R_NCACHENXDOMAIN && + result != DNS_R_NCACHENXRRSET && + result != DNS_R_NXRRSET && + result != DNS_R_HINTNXRRSET && + result != ISC_R_NOTFOUND) { + goto notfound; + } + return (result); + + notfound: + if (dns_rdataset_isassociated(&val->frdataset)) + dns_rdataset_disassociate(&val->frdataset); + if (dns_rdataset_isassociated(&val->fsigrdataset)) + dns_rdataset_disassociate(&val->fsigrdataset); + return (ISC_R_NOTFOUND); } static inline isc_boolean_t @@ -1483,7 +1595,7 @@ dlv_validatezonekey(dns_validator_t *val) { } if (result != ISC_R_SUCCESS) { validator_log(val, ISC_LOG_DEBUG(3), - "no KEY matching DLV"); + "no DNSKEY matching DLV"); continue; } @@ -1518,7 +1630,8 @@ dlv_validatezonekey(dns_validator_t *val) { dns_rdataset_disassociate(&trdataset); if (result == ISC_R_SUCCESS) break; - validator_log(val, ISC_LOG_DEBUG(3), "no SIG matching DLV key"); + validator_log(val, ISC_LOG_DEBUG(3), + "no RRSIG matching DLV key"); } if (result == ISC_R_SUCCESS) { val->event->rdataset->trust = dns_trust_secure; @@ -1767,7 +1880,7 @@ validatezonekey(dns_validator_t *val) { } if (result != ISC_R_SUCCESS) { validator_log(val, ISC_LOG_DEBUG(3), - "no KEY matching DS"); + "no DNSKEY matching DS"); continue; } @@ -1802,7 +1915,8 @@ validatezonekey(dns_validator_t *val) { dns_rdataset_disassociate(&trdataset); if (result == ISC_R_SUCCESS) break; - validator_log(val, ISC_LOG_DEBUG(3), "no SIG matching DS key"); + validator_log(val, ISC_LOG_DEBUG(3), + "no RRSIG matching DS key"); } if (result == ISC_R_SUCCESS) { event->rdataset->trust = dns_trust_secure; @@ -1982,8 +2096,8 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) { * would lead to a query for the zone key, which * would return a negative answer, which would contain * an SOA and an NSEC signed by the missing key, which - * would trigger another query for the KEY (since the - * first one is still in progress), and go into an + * would trigger another query for the DNSKEY (since + * the first one is still in progress), and go into an * infinite loop. Avoid that. */ if (val->event->type == dns_rdatatype_dnskey && @@ -2099,9 +2213,127 @@ check_ds_algorithm(dns_validator_t *val, dns_name_t *name, return (ISC_FALSE); } +static void +dlv_fetched2(isc_task_t *task, isc_event_t *event) { + dns_fetchevent_t *devent; + dns_validator_t *val; + isc_boolean_t want_destroy; + isc_result_t eresult; + isc_result_t result; + + UNUSED(task); + INSIST(event->ev_type == DNS_EVENT_FETCHDONE); + devent = (dns_fetchevent_t *)event; + val = devent->ev_arg; + eresult = devent->result; + + isc_event_free(&event); + dns_resolver_destroyfetch(&val->fetch); + + INSIST(val->event != NULL); + validator_log(val, ISC_LOG_DEBUG(3), "in dlv_fetched2: %s", + dns_result_totext(eresult)); + + LOCK(&val->lock); + if (eresult == ISC_R_SUCCESS) { + val->havedlvsep = ISC_TRUE; + result = proveunsecure(val, ISC_FALSE); + if (result != DNS_R_WAIT) + validator_done(val, result); + } else if (eresult == DNS_R_NXRRSET || + eresult == DNS_R_NXDOMAIN || + eresult == DNS_R_NCACHENXRRSET || + eresult == DNS_R_NCACHENXDOMAIN) { + result = finddlvsep(val, ISC_TRUE); + if (result == ISC_R_SUCCESS) { + result = proveunsecure(val, ISC_FALSE); + if (result != DNS_R_WAIT) + validator_done(val, result); + } else if (result == ISC_R_NOTFOUND) { + validator_done(val, ISC_R_SUCCESS); + } else if (result != DNS_R_WAIT) + validator_done(val, result); + } + want_destroy = exit_check(val); + UNLOCK(&val->lock); + if (want_destroy) + destroy(val); +} + +static isc_result_t +finddlvsep(dns_validator_t *val, isc_boolean_t resume) { + dns_fixedname_t dlvfixed; + dns_name_t *dlvname; + dns_name_t *dlvsep; + dns_name_t noroot; + isc_result_t result; + unsigned int labels; + + if (!resume) { + dns_fixedname_init(&val->dlvsep); + dlvsep = dns_fixedname_name(&val->dlvsep); + dns_name_copy(val->event->name, dlvsep, NULL); + val->attributes |= VALATTR_DLVSEPTRIED; + } else { + dlvsep = dns_fixedname_name(&val->dlvsep); + labels = dns_name_countlabels(dlvsep); + dns_name_getlabelsequence(dlvsep, 1, labels - 1, dlvsep); + } + dns_name_init(&noroot, NULL); + dns_fixedname_init(&dlvfixed); + dlvname = dns_fixedname_name(&dlvfixed); + labels = dns_name_countlabels(dlvsep); + dns_name_getlabelsequence(dlvsep, 0, labels - 1, &noroot); + result = dns_name_concatenate(&noroot, val->view->dlv, dlvname, NULL); + while (result == ISC_R_NOSPACE) { + labels = dns_name_countlabels(dlvsep); + dns_name_getlabelsequence(dlvsep, 1, labels - 1, dlvsep); + dns_name_getlabelsequence(dlvsep, 0, labels - 2, &noroot); + result = dns_name_concatenate(&noroot, val->view->dlv, + dlvname, NULL); + } + if (result != ISC_R_SUCCESS) { + validator_log(val, ISC_LOG_DEBUG(2), "DLV concatenate failed"); + return (DNS_R_NOVALIDSIG); + } + + while (dns_name_countlabels(dlvname) > + dns_name_countlabels(val->view->dlv)) + { + result = view_find(val, dlvname, dns_rdatatype_dlv); + if (result == ISC_R_SUCCESS) { + if (val->frdataset.trust < dns_trust_secure) + return (DNS_R_NOVALIDSIG); + val->havedlvsep = ISC_TRUE; + return (ISC_R_SUCCESS); + } + if (result == ISC_R_NOTFOUND) { + result = create_fetch(val, dlvname, dns_rdatatype_dlv, + dlv_fetched2, "finddlvsep"); + if (result != ISC_R_SUCCESS) + return (result); + return (DNS_R_WAIT); + } + if (result != DNS_R_NXRRSET && + result != DNS_R_NXDOMAIN && + result != DNS_R_NCACHENXRRSET && + result != DNS_R_NCACHENXDOMAIN) + return (result); + /* + * Strip first labels from both dlvsep and dlvname. + */ + labels = dns_name_countlabels(dlvsep); + dns_name_getlabelsequence(dlvsep, 1, labels - 1, dlvsep); + labels = dns_name_countlabels(dlvname); + dns_name_getlabelsequence(dlvname, 1, labels - 1, dlvname); + } + return (ISC_R_NOTFOUND); +} + static isc_result_t proveunsecure(dns_validator_t *val, isc_boolean_t resume) { isc_result_t result; + isc_result_t tresult; dns_fixedname_t secroot; dns_name_t *tname; @@ -2112,11 +2344,30 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) { /* * If the name is not under a security root, it must be insecure. */ - if (result == ISC_R_NOTFOUND) - return (ISC_R_SUCCESS); + if (val->view->dlv != NULL && !DLVSEPTRIED(val) && + !dns_name_issubdomain(val->event->name, val->view->dlv)) { + tresult = finddlvsep(val, ISC_FALSE); + if (tresult != ISC_R_NOTFOUND && tresult != ISC_R_SUCCESS) { + validator_log(val, ISC_LOG_DEBUG(3), + "finddlvsep returned: %s", + dns_result_totext(tresult)); + return (tresult); + } + } - else if (result != ISC_R_SUCCESS) + if (result == ISC_R_NOTFOUND) { + if (!val->havedlvsep) + return (ISC_R_SUCCESS); + dns_name_copy(dns_fixedname_name(&val->dlvsep), + dns_fixedname_name(&secroot), NULL); + } else if (result != ISC_R_SUCCESS) return (result); + else if (val->havedlvsep && + dns_name_issubdomain(dns_fixedname_name(&val->dlvsep), + dns_fixedname_name(&secroot))) { + dns_name_copy(dns_fixedname_name(&val->dlvsep), + dns_fixedname_name(&secroot), NULL); + } if (!resume) { val->labels = @@ -2429,6 +2680,7 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type, val->nsecset = NULL; val->soaname = NULL; val->seensig = ISC_FALSE; + val->havedlvsep = ISC_FALSE; val->mustbesecure = dns_resolver_getmustbesecure(view->resolver, name); dns_rdataset_init(&val->frdataset); dns_rdataset_init(&val->fsigrdataset); diff --git a/dist/bind/lib/dns/zone.c b/dist/bind/lib/dns/zone.c index 9c94dc4ce9c..9e18270455b 100644 --- a/dist/bind/lib/dns/zone.c +++ b/dist/bind/lib/dns/zone.c @@ -1,4 +1,4 @@ -/* $NetBSD: zone.c,v 1.1.1.1 2004/05/17 23:44:56 christos Exp $ */ +/* $NetBSD: zone.c,v 1.1.1.2 2004/11/06 23:55:43 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: zone.c,v 1.333.2.23.2.45 2004/04/29 01:45:23 marka Exp */ +/* Id: zone.c,v 1.333.2.23.2.50 2004/08/28 05:53:37 marka Exp */ #include <config.h> @@ -2351,8 +2351,10 @@ dump_done(void *arg, isc_result_t result) { tresult = dns_db_getsoaserial(db, version, &serial); if (tresult == ISC_R_SUCCESS) { - tresult = dns_journal_compact(zone->mctx, zone->journal, - serial, zone->journalsize); + tresult = dns_journal_compact(zone->mctx, + zone->journal, + serial, + zone->journalsize); switch (tresult) { case ISC_R_SUCCESS: case ISC_R_NOSPACE: @@ -3620,7 +3622,12 @@ refresh_callback(isc_task_t *task, isc_event_t *event) { dns_message_destroy(&msg); } else if (isc_serial_eq(soa.serial, zone->serial)) { if (zone->masterfile != NULL) { - result = isc_file_settime(zone->masterfile, &now); + result = ISC_R_FAILURE; + if (zone->journal != NULL) + result = isc_file_settime(zone->journal, &now); + if (result != ISC_R_SUCCESS) + result = isc_file_settime(zone->masterfile, + &now); /* Someone removed the file from underneath us! */ if (result == ISC_R_FILENOTFOUND) { LOCK_ZONE(zone); @@ -3988,6 +3995,8 @@ soa_query(isc_task_t *task, isc_event_t *event) { return; skip_master: + if (key != NULL) + dns_tsigkey_detach(&key); zone->curmaster++; if (zone->curmaster < zone->masterscnt) goto again; @@ -4251,14 +4260,17 @@ zone_shutdown(isc_task_t *task, isc_event_t *event) { if (zone->readio != NULL) zonemgr_cancelio(zone->readio); - if (zone->writeio != NULL) - zonemgr_cancelio(zone->writeio); - if (zone->lctx != NULL) dns_loadctx_cancel(zone->lctx); - if (zone->dctx != NULL) - dns_dumpctx_cancel(zone->dctx); + if (!DNS_ZONE_FLAG(zone, DNS_ZONEFLG_FLUSH) || + !DNS_ZONE_FLAG(zone, DNS_ZONEFLG_DUMPING)) { + if (zone->writeio != NULL) + zonemgr_cancelio(zone->writeio); + + if (zone->dctx != NULL) + dns_dumpctx_cancel(zone->dctx); + } notify_cancel(zone); @@ -5166,9 +5178,8 @@ notify_done(isc_task_t *task, isc_event_t *event) { * the soa if we see a formerr and had sent a SOA. */ isc_event_free(&event); - if ((result == ISC_R_TIMEDOUT || - (message != NULL && message->rcode == dns_rcode_formerr && - (notify->flags & DNS_NOTIFY_NOSOA) == 0))) { + if (message != NULL && message->rcode == dns_rcode_formerr && + (notify->flags & DNS_NOTIFY_NOSOA) == 0) { notify->flags |= DNS_NOTIFY_NOSOA; dns_request_destroy(¬ify->request); result = notify_send_queue(notify); @@ -5226,6 +5237,31 @@ zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump) { goto fail; if (dump) zone_needdump(zone, DNS_DUMP_DELAY); + else if (zone->journalsize != -1) { + isc_uint32_t serial; + + result = dns_db_getsoaserial(db, ver, &serial); + if (result == ISC_R_SUCCESS) { + result = dns_journal_compact(zone->mctx, + zone->journal, + serial, + zone->journalsize); + switch (result) { + case ISC_R_SUCCESS: + case ISC_R_NOSPACE: + case ISC_R_NOTFOUND: + dns_zone_log(zone, ISC_LOG_DEBUG(3), + "dns_journal_compact: %s", + dns_result_totext(result)); + break; + default: + dns_zone_log(zone, ISC_LOG_ERROR, + "dns_journal_compact failed: %s", + dns_result_totext(result)); + break; + } + } + } } else { if (dump && zone->masterfile != NULL) { isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL, diff --git a/dist/bind/lib/isc/Makefile.in b/dist/bind/lib/isc/Makefile.in index 0c0c65df60c..c7bb871674d 100644 --- a/dist/bind/lib/isc/Makefile.in +++ b/dist/bind/lib/isc/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.71.2.2.2.7 2004/03/08 09:04:48 marka Exp +# Id: Makefile.in,v 1.71.2.2.2.8 2004/07/20 07:01:58 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -94,7 +94,7 @@ libisc.@SA@: ${OBJS} libisc.la: ${OBJS} ${LIBTOOL_MODE_LINK} \ - ${CC} ${ALL_CFLAGS} -o libisc.la -rpath ${libdir} \ + ${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libisc.la -rpath ${libdir} \ -version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \ ${OBJS} ${LIBS} diff --git a/dist/bind/lib/isc/api b/dist/bind/lib/isc/api index 75a502768ef..9d7fc51c828 100644 --- a/dist/bind/lib/isc/api +++ b/dist/bind/lib/isc/api @@ -1,3 +1,3 @@ LIBINTERFACE = 10 -LIBREVISION = 0 +LIBREVISION = 4 LIBAGE = 1 diff --git a/dist/bind/lib/isc/include/isc/result.h b/dist/bind/lib/isc/include/isc/result.h index 431c57e643e..33e4ef70309 100644 --- a/dist/bind/lib/isc/include/isc/result.h +++ b/dist/bind/lib/isc/include/isc/result.h @@ -1,4 +1,4 @@ -/* $NetBSD: result.h,v 1.1.1.1 2004/05/17 23:45:04 christos Exp $ */ +/* $NetBSD: result.h,v 1.1.1.2 2004/11/06 23:55:51 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: result.h,v 1.57.2.2.8.4 2004/03/08 09:04:53 marka Exp */ +/* Id: result.h,v 1.57.2.2.8.5 2004/05/15 03:46:13 jinmei Exp */ #ifndef ISC_RESULT_H #define ISC_RESULT_H 1 @@ -84,11 +84,12 @@ #define ISC_R_BADNUMBER 56 /* not a valid number */ #define ISC_R_DISABLED 57 /* disabled */ #define ISC_R_MAXSIZE 58 /* max size */ +#define ISC_R_BADADDRESSFORM 59 /* invalid address format */ /* * Not a result code: the number of results. */ -#define ISC_R_NRESULTS 59 +#define ISC_R_NRESULTS 60 ISC_LANG_BEGINDECLS diff --git a/dist/bind/lib/isc/inet_ntop.c b/dist/bind/lib/isc/inet_ntop.c index af350d36992..85f3d5eb000 100644 --- a/dist/bind/lib/isc/inet_ntop.c +++ b/dist/bind/lib/isc/inet_ntop.c @@ -1,4 +1,4 @@ -/* $NetBSD: inet_ntop.c,v 1.1.1.1 2004/05/17 23:45:02 christos Exp $ */ +/* $NetBSD: inet_ntop.c,v 1.1.1.2 2004/11/06 23:55:49 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -19,7 +19,7 @@ #if defined(LIBC_SCCS) && !defined(lint) static char rcsid[] = - "Id: inet_ntop.c,v 1.12.12.3 2004/03/08 09:04:49 marka Exp"; + "Id: inet_ntop.c,v 1.12.12.4 2004/08/28 06:25:21 marka Exp"; #endif /* LIBC_SCCS and not lint */ #include <config.h> @@ -29,6 +29,7 @@ static char rcsid[] = #include <string.h> #include <isc/net.h> +#include <isc/print.h> #define NS_INT16SZ 2 #define NS_IN6ADDRSZ 16 diff --git a/dist/bind/lib/isc/lex.c b/dist/bind/lib/isc/lex.c index 2d9072c39e1..53f5d21ffda 100644 --- a/dist/bind/lib/isc/lex.c +++ b/dist/bind/lib/isc/lex.c @@ -1,4 +1,4 @@ -/* $NetBSD: lex.c,v 1.1.1.1 2004/05/17 23:45:02 christos Exp $ */ +/* $NetBSD: lex.c,v 1.1.1.2 2004/11/06 23:55:49 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: lex.c,v 1.66.2.6.2.7 2004/03/06 08:14:31 marka Exp */ +/* Id: lex.c,v 1.66.2.6.2.8 2004/08/28 06:25:21 marka Exp */ #include <config.h> @@ -31,6 +31,7 @@ #include <isc/mem.h> #include <isc/msgs.h> #include <isc/parseint.h> +#include <isc/print.h> #include <isc/stdio.h> #include <isc/string.h> #include <isc/util.h> diff --git a/dist/bind/lib/isc/log.c b/dist/bind/lib/isc/log.c index 9192bac76f0..777532810c1 100644 --- a/dist/bind/lib/isc/log.c +++ b/dist/bind/lib/isc/log.c @@ -1,4 +1,4 @@ -/* $NetBSD: log.c,v 1.1.1.1 2004/05/17 23:45:02 christos Exp $ */ +/* $NetBSD: log.c,v 1.1.1.2 2004/11/06 23:55:49 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: log.c,v 1.70.2.8.2.10 2004/04/10 04:31:40 marka Exp */ +/* Id: log.c,v 1.70.2.8.2.12 2004/06/11 00:35:38 marka Exp */ /* Principal Authors: DCL */ @@ -1142,6 +1142,10 @@ greatest_version(isc_logchannel_t *channel, int *greatestp) { unsigned int basenamelen; isc_dir_t dir; isc_result_t result; + char sep = '/'; +#ifdef _WIN32 + char *basename2; +#endif REQUIRE(channel->type == ISC_LOG_TOFILE); @@ -1149,7 +1153,15 @@ greatest_version(isc_logchannel_t *channel, int *greatestp) { * It is safe to DE_CONST the file.name because it was copied * with isc_mem_strdup in isc_log_createchannel. */ - basename = strrchr(FILE_NAME(channel), '/'); + basename = strrchr(FILE_NAME(channel), sep); +#ifdef _WIN32 + basename2 = strrchr(FILE_NAME(channel), '\\'); + if ((basename != NULL && basename2 != NULL && basename2 > basename) || + (basename == NULL && basename2 != NULL)) { + basename = basename2; + sep = '\\'; + } +#endif if (basename != NULL) { *basename++ = '\0'; dirname = FILE_NAME(channel); @@ -1166,7 +1178,7 @@ greatest_version(isc_logchannel_t *channel, int *greatestp) { * Replace the file separator if it was taken out. */ if (basename != FILE_NAME(channel)) - *(basename - 1) = '/'; + *(basename - 1) = sep; /* * Return if the directory open failed. @@ -1319,8 +1331,11 @@ isc_log_open(isc_logchannel_t *channel) { if (stat(path, &statbuf) == 0) { regular_file = S_ISREG(statbuf.st_mode) ? ISC_TRUE : ISC_FALSE; /* XXXDCL if not regular_file complain? */ - roll = ISC_TF(regular_file && FILE_MAXSIZE(channel) > 0 && - statbuf.st_size >= FILE_MAXSIZE(channel)); + if ((FILE_MAXSIZE(channel) == 0 && + FILE_VERSIONS(channel) != ISC_LOG_ROLLNEVER) || + (FILE_MAXSIZE(channel) > 0 && + statbuf.st_size >= FILE_MAXSIZE(channel))) + roll = regular_file; } else if (errno == ENOENT) regular_file = ISC_TRUE; else diff --git a/dist/bind/lib/isc/netaddr.c b/dist/bind/lib/isc/netaddr.c index f19890d1166..9d318f0676a 100644 --- a/dist/bind/lib/isc/netaddr.c +++ b/dist/bind/lib/isc/netaddr.c @@ -1,4 +1,4 @@ -/* $NetBSD: netaddr.c,v 1.1.1.1 2004/05/17 23:45:02 christos Exp $ */ +/* $NetBSD: netaddr.c,v 1.1.1.2 2004/11/06 23:55:49 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: netaddr.c,v 1.18.12.8 2004/03/08 09:04:49 marka Exp */ +/* Id: netaddr.c,v 1.18.12.9 2004/05/15 03:46:12 jinmei Exp */ #include <config.h> @@ -49,7 +49,8 @@ isc_netaddr_equal(const isc_netaddr_t *a, const isc_netaddr_t *b) { break; case AF_INET6: if (memcmp(&a->type.in6, &b->type.in6, - sizeof(a->type.in6)) != 0) + sizeof(a->type.in6)) != 0 || + a->zone != b->zone) return (ISC_FALSE); break; default: diff --git a/dist/bind/lib/isc/result.c b/dist/bind/lib/isc/result.c index dc9c17af9b8..18127be04ce 100644 --- a/dist/bind/lib/isc/result.c +++ b/dist/bind/lib/isc/result.c @@ -1,4 +1,4 @@ -/* $NetBSD: result.c,v 1.1.1.1 2004/05/17 23:45:03 christos Exp $ */ +/* $NetBSD: result.c,v 1.1.1.2 2004/11/06 23:55:50 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: result.c,v 1.56.2.2.8.5 2004/03/08 09:04:50 marka Exp */ +/* Id: result.c,v 1.56.2.2.8.7 2004/06/11 00:31:01 marka Exp */ #include <config.h> @@ -98,7 +98,8 @@ static const char *text[ISC_R_NRESULTS] = { "soft quota reached", /* 55 */ "not a valid number", /* 56 */ "disabled", /* 57 */ - "max size" /* 58 */ + "max size", /* 58 */ + "invalid address format" /* 59 */ }; #define ISC_RESULT_RESULTSET 2 @@ -126,7 +127,7 @@ register_table(unsigned int base, unsigned int nresults, const char **text, if (table == NULL) return (ISC_R_NOMEMORY); table->base = base; - table->last = base + nresults; + table->last = base + nresults - 1; table->text = text; table->msgcat = msgcat; table->set = set; diff --git a/dist/bind/lib/isc/sockaddr.c b/dist/bind/lib/isc/sockaddr.c index b34e261749f..66ee4cabc12 100644 --- a/dist/bind/lib/isc/sockaddr.c +++ b/dist/bind/lib/isc/sockaddr.c @@ -1,4 +1,4 @@ -/* $NetBSD: sockaddr.c,v 1.1.1.1 2004/05/17 23:45:02 christos Exp $ */ +/* $NetBSD: sockaddr.c,v 1.1.1.2 2004/11/06 23:55:50 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: sockaddr.c,v 1.48.2.1.2.9 2004/03/08 09:04:50 marka Exp */ +/* Id: sockaddr.c,v 1.48.2.1.2.10 2004/05/15 03:46:12 jinmei Exp */ #include <config.h> @@ -59,6 +59,10 @@ isc_sockaddr_equal(const isc_sockaddr_t *a, const isc_sockaddr_t *b) { if (memcmp(&a->type.sin6.sin6_addr, &b->type.sin6.sin6_addr, sizeof(a->type.sin6.sin6_addr)) != 0) return (ISC_FALSE); +#ifdef ISC_PLATFORM_HAVESCOPEID + if (a->type.sin6.sin6_scope_id != b->type.sin6.sin6_scope_id) + return (ISC_FALSE); +#endif if (a->type.sin6.sin6_port != b->type.sin6.sin6_port) return (ISC_FALSE); break; @@ -88,6 +92,10 @@ isc_sockaddr_eqaddr(const isc_sockaddr_t *a, const isc_sockaddr_t *b) { if (memcmp(&a->type.sin6.sin6_addr, &b->type.sin6.sin6_addr, sizeof(a->type.sin6.sin6_addr)) != 0) return (ISC_FALSE); +#ifdef ISC_PLATFORM_HAVESCOPEID + if (a->type.sin6.sin6_scope_id != b->type.sin6.sin6_scope_id) + return (ISC_FALSE); +#endif break; default: if (memcmp(&a->type, &b->type, a->length) != 0) diff --git a/dist/bind/lib/isc/unix/Makefile.in b/dist/bind/lib/isc/unix/Makefile.in index 84eaa8cfc9e..d0c6c4b6c2a 100644 --- a/dist/bind/lib/isc/unix/Makefile.in +++ b/dist/bind/lib/isc/unix/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.35.2.1.10.1 2004/03/06 08:14:57 marka Exp +# Id: Makefile.in,v 1.35.2.1.10.2 2004/06/22 02:48:36 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -46,3 +46,6 @@ SUBDIRS = include TARGETS = ${OBJS} @BIND9_MAKE_RULES@ + +interfaceiter.@O@: interfaceiter.c ifiter_ioctl.c ifiter_sysctl.c ifiter_getifaddrs.c + diff --git a/dist/bind/lib/isc/unix/ifiter_ioctl.c b/dist/bind/lib/isc/unix/ifiter_ioctl.c index 2f4c958b0bc..6ef96fbb387 100644 --- a/dist/bind/lib/isc/unix/ifiter_ioctl.c +++ b/dist/bind/lib/isc/unix/ifiter_ioctl.c @@ -1,4 +1,4 @@ -/* $NetBSD: ifiter_ioctl.c,v 1.1.1.1 2004/05/17 23:45:05 christos Exp $ */ +/* $NetBSD: ifiter_ioctl.c,v 1.1.1.2 2004/11/06 23:55:52 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: ifiter_ioctl.c,v 1.19.2.5.2.10 2004/04/15 07:03:50 marka Exp */ +/* Id: ifiter_ioctl.c,v 1.19.2.5.2.14 2004/06/22 04:40:23 marka Exp */ /* * Obtain the list of network interfaces using the SIOCGLIFCONF ioctl. @@ -52,7 +52,7 @@ #define VALID_IFITER(t) ISC_MAGIC_VALID(t, IFITER_MAGIC) #define ISC_IF_INET6_SZ \ - sizeof("00000000000000000000000000000001 01 80 10 80 lo\n") + sizeof("00000000000000000000000000000001 01 80 10 80 XXXXXXloXXXXXXXX\n") struct isc_interfaceiter { unsigned int magic; /* Magic number. */ @@ -102,6 +102,16 @@ struct isc_interfaceiter { #define IFCONF_BUFSIZE_INITIAL 4096 #define IFCONF_BUFSIZE_MAX 1048576 +#ifdef __linux +#ifndef IF_NAMESIZE +# ifdef IFNAMSIZ +# define IF_NAMESIZE IFNAMSIZ +# else +# define IF_NAMESIZE 16 +# endif +#endif +#endif + static isc_result_t getbuf4(isc_interfaceiter_t *iter) { char strbuf[ISC_STRERRORSIZE]; @@ -446,15 +456,28 @@ linux_if_inet6_current(isc_interfaceiter_t *iter) { if (iter->valid != ISC_R_SUCCESS) return (iter->valid); - if (iter->proc == NULL) + if (iter->proc == NULL) { + isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, + ISC_LOGMODULE_INTERFACE, ISC_LOG_ERROR, + "/proc/net/if_inet6:iter->proc == NULL"); return (ISC_R_FAILURE); + } res = sscanf(iter->entry, "%32[a-f0-9] %x %x %x %x %16s\n", address, &ifindex, &prefix, &flag3, &flag4, name); - if (res != 6) + if (res != 6) { + isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, + ISC_LOGMODULE_INTERFACE, ISC_LOG_ERROR, + "/proc/net/if_inet6:sscanf() -> %d (expected 6)", + res); return (ISC_R_FAILURE); - if (strlen(address) != 32) + } + if (strlen(address) != 32) { + isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, + ISC_LOGMODULE_INTERFACE, ISC_LOG_ERROR, + "/proc/net/if_inet6:strlen(%s) != 32", address); return (ISC_R_FAILURE); + } for (i = 0; i < 16; i++) { unsigned char byte; static const char hex[] = "0123456789abcdef"; @@ -945,7 +968,7 @@ internal_next(isc_interfaceiter_t *iter) { #endif #ifdef HAVE_TRUCLUSTER if (!iter->clua_done) { - clua_result = clua_getaliasaddress(&intr->clua_sa, + clua_result = clua_getaliasaddress(&iter->clua_sa, &iter->clua_context); if (clua_result != CLUA_SUCCESS) iter->clua_done = ISC_TRUE; @@ -985,7 +1008,7 @@ void internal_first(isc_interfaceiter_t *iter) { #endif #ifdef HAVE_TRUCLUSTER iter->clua_context = 0; - clua_result = clua_getaliasaddress(&intr->clua_sa, + clua_result = clua_getaliasaddress(&iter->clua_sa, &iter->clua_context); iter->clua_done = ISC_TF(clua_result != CLUA_SUCCESS); #endif diff --git a/dist/bind/lib/isc/unix/interfaceiter.c b/dist/bind/lib/isc/unix/interfaceiter.c index a8427bfeaff..db8ec2ed0d5 100644 --- a/dist/bind/lib/isc/unix/interfaceiter.c +++ b/dist/bind/lib/isc/unix/interfaceiter.c @@ -1,4 +1,4 @@ -/* $NetBSD: interfaceiter.c,v 1.1.1.1 2004/05/17 23:45:05 christos Exp $ */ +/* $NetBSD: interfaceiter.c,v 1.1.1.2 2004/11/06 23:55:52 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: interfaceiter.c,v 1.22.2.1.10.12 2004/04/20 06:46:53 marka Exp */ +/* Id: interfaceiter.c,v 1.22.2.1.10.14 2004/08/28 06:25:22 marka Exp */ #include <config.h> @@ -38,6 +38,7 @@ #include <isc/mem.h> #include <isc/msgs.h> #include <isc/net.h> +#include <isc/print.h> #include <isc/result.h> #include <isc/strerror.h> #include <isc/string.h> @@ -67,6 +68,11 @@ get_addr(unsigned int family, isc_netaddr_t *dst, struct sockaddr *src, { struct sockaddr_in6 *sa6; +#if !defined(ISC_PLATFORM_HAVEIFNAMETOINDEX) || \ + !defined(ISC_PLATFORM_HAVESCOPEID) + UNUSED(ifname); +#endif + /* clear any remaining value for safety */ memset(dst, 0, sizeof(*dst)); diff --git a/dist/bind/lib/isc/unix/socket.c b/dist/bind/lib/isc/unix/socket.c index a75a4b2d69d..c5ff6c293b8 100644 --- a/dist/bind/lib/isc/unix/socket.c +++ b/dist/bind/lib/isc/unix/socket.c @@ -1,4 +1,4 @@ -/* $NetBSD: socket.c,v 1.1.1.1 2004/05/17 23:45:06 christos Exp $ */ +/* $NetBSD: socket.c,v 1.1.1.2 2004/11/06 23:55:53 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: socket.c,v 1.207.2.19.2.11 2004/04/19 03:05:22 marka Exp */ +/* Id: socket.c,v 1.207.2.19.2.13 2004/07/01 04:51:15 marka Exp */ #include <config.h> @@ -2861,7 +2861,11 @@ isc_socket_bind(isc_socket_t *sock, isc_sockaddr_t *sockaddr) { UNLOCK(&sock->lock); return (ISC_R_FAMILYMISMATCH); } - if (setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on, + /* + * Only set SO_REUSEADDR when we want a specific port. + */ + if (isc_sockaddr_getport(sockaddr) != (in_port_t)0 && + setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on, sizeof(on)) < 0) { UNEXPECTED_ERROR(__FILE__, __LINE__, "setsockopt(%d) %s", sock->fd, diff --git a/dist/bind/lib/isc/win32/socket.c b/dist/bind/lib/isc/win32/socket.c index d8ed9e78bef..980f11ad7f5 100644 --- a/dist/bind/lib/isc/win32/socket.c +++ b/dist/bind/lib/isc/win32/socket.c @@ -1,4 +1,4 @@ -/* $NetBSD: socket.c,v 1.1.1.1 2004/05/17 23:45:07 christos Exp $ */ +/* $NetBSD: socket.c,v 1.1.1.2 2004/11/06 23:55:58 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: socket.c,v 1.5.2.13.2.8 2004/03/06 08:15:10 marka Exp */ +/* Id: socket.c,v 1.5.2.13.2.13 2004/09/01 04:32:18 marka Exp */ /* This code has been rewritten to take advantage of Windows Sockets * I/O Completion Ports and Events. I/O Completion Ports is ONLY @@ -241,8 +241,10 @@ struct isc_socket { listener : 1, /* listener socket */ connected : 1, connecting : 1, /* connect pending */ - bound : 1; /* bound to local addr */ - + bound : 1, /* bound to local addr */ + pending_free: 1; + unsigned int pending_recv; + unsigned int pending_send; }; /* @@ -348,11 +350,8 @@ static isc_threadresult_t WINAPI SocketIoThread(LPVOID ThreadContext); static void free_socket(isc_socket_t **); enum { - SOCKET_CANCEL, - SOCKET_SHUTDOWN, SOCKET_RECV, SOCKET_SEND, - SOCK_ACCEPT }; enum { @@ -360,9 +359,6 @@ enum { EVENT_DELETE }; -#define SOCK_DEAD(s) ((s)->references == 0) - - #if defined(ISC_SOCKET_DEBUG) /* * This is used to dump the contents of the sock structure @@ -456,7 +452,7 @@ iocompletionport_createthreads(int total_threads, isc_socketmgr_t *manager) { * We need at least one */ for (i = 0; i < total_threads; i++) { - manager->hIOCPThreads[i] = CreateThread( NULL, 0, SocketIoThread, + manager->hIOCPThreads[i] = CreateThread(NULL, 0, SocketIoThread, manager, 0, &manager->dwIOCPThreadIds[i]); if(manager->hIOCPThreads[i] == NULL) { @@ -523,7 +519,8 @@ iocompletionport_exit(isc_socketmgr_t *manager) { } /* - * Add sockets in here and pass the sock data in as part of the information needed + * Add sockets in here and pass the sock data in as part of the + * information needed. */ void iocompletionport_update(isc_socket_t *sock) { @@ -654,9 +651,10 @@ socket_eventlist_add(event_change_t *evchange, sock_event_list *evlist, sock->evthread_id = GetCurrentThreadId(); return (ISC_TRUE); } + /* - * Note that the eventLock is locked before calling this function - * All Events and associated sockes are closed here + * Note that the eventLock is locked before calling this function. + * All Events and associated sockets are closed here. */ isc_boolean_t socket_eventlist_delete(event_change_t *evchange, sock_event_list *evlist) { @@ -666,7 +664,7 @@ socket_eventlist_delete(event_change_t *evchange, sock_event_list *evlist) { REQUIRE(evchange != NULL); /* Make sure this is the right thread from which to delete the event */ - if(evchange->evthread_id != GetCurrentThreadId()) + if (evchange->evthread_id != GetCurrentThreadId()) return (ISC_FALSE); REQUIRE(evlist != NULL); @@ -680,6 +678,7 @@ socket_eventlist_delete(event_change_t *evchange, sock_event_list *evlist) { break; } } + /* Actual event start at 1 */ if (iEvent < 1) return (ISC_FALSE); @@ -688,6 +687,7 @@ socket_eventlist_delete(event_change_t *evchange, sock_event_list *evlist) { evlist->aEventList[i] = evlist->aEventList[i + 1]; evlist->aSockList[i] = evlist->aSockList[i + 1]; } + evlist->aEventList[evlist->max_event - 1] = 0; evlist->aSockList[evlist->max_event - 1] = NULL; @@ -700,6 +700,7 @@ socket_eventlist_delete(event_change_t *evchange, sock_event_list *evlist) { return (ISC_TRUE); } + /* * Get the event changes off of the list and apply the * requested changes. The manager lock is taken out at @@ -724,15 +725,20 @@ process_eventlist(sock_event_list *evlist, isc_socketmgr_t *manager) { LOCK(&manager->lock); - /* First the deletes */ + /* + * First the deletes. + */ evchange = ISC_LIST_HEAD(manager->event_updates); while (evchange != NULL) { next = ISC_LIST_NEXT(evchange, link); del = ISC_FALSE; - if(evchange->action == EVENT_DELETE) { + if (evchange->action == EVENT_DELETE) { del = socket_eventlist_delete(evchange, evlist); - /* Delete only if this thread's socket list was updated */ + /* + * Delete only if this thread's socket list was + * updated. + */ if (del) { ISC_LIST_DEQUEUE(manager->event_updates, evchange, link); @@ -742,15 +748,21 @@ process_eventlist(sock_event_list *evlist, isc_socketmgr_t *manager) { } evchange = next; } - /* Now the adds */ + + /* + * Now the adds. + */ evchange = ISC_LIST_HEAD(manager->event_updates); while (evchange != NULL) { next = ISC_LIST_NEXT(evchange, link); del = ISC_FALSE; - if(evchange->action == EVENT_ADD) { + if (evchange->action == EVENT_ADD) { del = socket_eventlist_add(evchange, evlist, manager); - /* Delete only if this thread's socket list was updated */ + /* + * Delete only if this thread's socket list was + * updated. + */ if (del) { ISC_LIST_DEQUEUE(manager->event_updates, evchange, link); @@ -763,13 +775,15 @@ process_eventlist(sock_event_list *evlist, isc_socketmgr_t *manager) { UNLOCK(&manager->lock); return (ISC_R_SUCCESS); } + /* * Add the event list changes to the queue and notify the * event loop */ static void notify_eventlist(isc_socket_t *sock, isc_socketmgr_t *manager, - unsigned int action) { + unsigned int action) +{ event_change_t *evchange; @@ -795,6 +809,7 @@ notify_eventlist(isc_socket_t *sock, isc_socketmgr_t *manager, else WSASetEvent(manager->prime_alert); } + /* * Note that the socket is already locked before calling this function */ @@ -832,6 +847,7 @@ socket_event_add(isc_socket_t *sock, long type) { notify_eventlist(sock, sock->manager, EVENT_ADD); return (ISC_R_SUCCESS); } + /* * Note that the socket is not locked before calling this function */ @@ -849,8 +865,8 @@ socket_event_delete(isc_socket_t *sock) { sock->hAlert = NULL; sock->evthread_id = 0; } - } + /* * Routine to cleanup and then close the socket. * Only close the socket here if it is NOT associated @@ -874,6 +890,7 @@ socket_close(isc_socket_t *sock) { } } + /* * Initialize socket services */ @@ -895,7 +912,8 @@ BOOL InitSockets() { int internal_sendmsg(isc_socket_t *sock, IoCompletionInfo *lpo, - struct msghdr *messagehdr, int flags, int *Error) { + struct msghdr *messagehdr, int flags, int *Error) +{ int Result; DWORD BytesSent; DWORD Flags = flags; @@ -920,19 +938,20 @@ internal_sendmsg(isc_socket_t *sock, IoCompletionInfo *lpo, *Error = WSAGetLastError(); switch (*Error) { + case WSA_IO_INCOMPLETE : + case WSA_WAIT_IO_COMPLETION : + case WSA_IO_PENDING : + sock->pending_send++; + case NO_ERROR : + break; - case NO_ERROR : - case WSA_IO_INCOMPLETE : - case WSA_WAIT_IO_COMPLETION : - case WSA_IO_PENDING : - break; - - default : - return (-1); - break; - } - } - if(lpo != NULL) + default : + return (-1); + break; + } + } else + sock->pending_send++; + if (lpo != NULL) return (0); else return (total_sent); @@ -940,7 +959,8 @@ internal_sendmsg(isc_socket_t *sock, IoCompletionInfo *lpo, int internal_recvmsg(isc_socket_t *sock, IoCompletionInfo *lpo, - struct msghdr *messagehdr, int flags, int *Error) { + struct msghdr *messagehdr, int flags, int *Error) +{ DWORD Flags = 0; DWORD NumBytes = 0; int total_bytes = 0; @@ -948,14 +968,14 @@ internal_recvmsg(isc_socket_t *sock, IoCompletionInfo *lpo, *Error = 0; Result = WSARecvFrom((SOCKET) sock->fd, - messagehdr->msg_iov, - messagehdr->msg_iovlen, - &NumBytes, - &Flags, - messagehdr->msg_name, - (int *)&(messagehdr->msg_namelen), - (LPOVERLAPPED) lpo, - NULL); + messagehdr->msg_iov, + messagehdr->msg_iovlen, + &NumBytes, + &Flags, + messagehdr->msg_name, + (int *)&(messagehdr->msg_namelen), + (LPOVERLAPPED) lpo, + NULL); total_bytes = (int) NumBytes; @@ -965,31 +985,32 @@ internal_recvmsg(isc_socket_t *sock, IoCompletionInfo *lpo, *Error = WSAGetLastError(); switch (*Error) { + case WSA_IO_INCOMPLETE: + case WSA_WAIT_IO_COMPLETION: + case WSA_IO_PENDING: + sock->pending_recv++; + case NO_ERROR: + break; - case NO_ERROR : - case WSA_IO_INCOMPLETE : - case WSA_WAIT_IO_COMPLETION : - case WSA_IO_PENDING : - break; + default : + return (-1); + break; + } + } else + sock->pending_recv++; - default : - return (-1); - break; - } - } /* Return the flags received in header */ messagehdr->msg_flags = Flags; - if(lpo != NULL) + if (lpo != NULL) return (-1); else return (total_bytes); - } static void -manager_log(isc_socketmgr_t *sockmgr, - isc_logcategory_t *category, isc_logmodule_t *module, int level, - const char *fmt, ...) { +manager_log(isc_socketmgr_t *sockmgr, isc_logcategory_t *category, + isc_logmodule_t *module, int level, const char *fmt, ...) +{ char msgbuf[2048]; va_list ap; @@ -1009,11 +1030,13 @@ socket_log(isc_socket_t *sock, isc_sockaddr_t *address, isc_logcategory_t *category, isc_logmodule_t *module, int level, isc_msgcat_t *msgcat, int msgset, int message, const char *fmt, ...) ISC_FORMAT_PRINTF(9, 10); + static void socket_log(isc_socket_t *sock, isc_sockaddr_t *address, isc_logcategory_t *category, isc_logmodule_t *module, int level, isc_msgcat_t *msgcat, int msgset, int message, - const char *fmt, ...) { + const char *fmt, ...) +{ char msgbuf[2048]; char peerbuf[256]; va_list ap; @@ -1060,6 +1083,7 @@ make_nonblock(SOCKET fd) { return (ISC_R_SUCCESS); } + /* * Windows 2000 systems incorrectly cause UDP sockets using WASRecvFrom * to not work correctly, returning a WSACONNRESET error when a WSASendTo @@ -1109,7 +1133,8 @@ connection_reset_fix(SOCKET fd) { static void build_msghdr_send(isc_socket_t *sock, isc_socketevent_t *dev, struct msghdr *msg, char *cmsg, - WSABUF *iov, size_t *write_countp) { + WSABUF *iov, size_t *write_countp) +{ unsigned int iovcount; isc_buffer_t *buffer; isc_region_t used; @@ -1196,7 +1221,8 @@ build_msghdr_send(isc_socket_t *sock, isc_socketevent_t *dev, static void build_msghdr_recv(isc_socket_t *sock, isc_socketevent_t *dev, struct msghdr *msg, char *cmsg, - WSABUF *iov, size_t *read_countp) { + WSABUF *iov, size_t *read_countp) +{ unsigned int iovcount; isc_buffer_t *buffer; isc_region_t available; @@ -1226,10 +1252,10 @@ build_msghdr_recv(isc_socket_t *sock, isc_socketevent_t *dev, iov[0].len = read_count; iovcount = 1; } else { - /* - * Multibuffer I/O. - * Skip empty buffers. - */ + /* + * Multibuffer I/O. + * Skip empty buffers. + */ while (buffer != NULL) { REQUIRE(ISC_BUFFER_VALID(buffer)); if (isc_buffer_availablelength(buffer) != 0) @@ -1268,7 +1294,8 @@ build_msghdr_recv(isc_socket_t *sock, isc_socketevent_t *dev, static void set_dev_address(isc_sockaddr_t *address, isc_socket_t *sock, - isc_socketevent_t *dev) { + isc_socketevent_t *dev) +{ if (sock->type == isc_sockettype_udp) { if (address != NULL) dev->address = *address; @@ -1282,14 +1309,14 @@ set_dev_address(isc_sockaddr_t *address, isc_socket_t *sock, static isc_socketevent_t * allocate_socketevent(isc_socket_t *sock, isc_eventtype_t eventtype, - isc_taskaction_t action, const void *arg) { + isc_taskaction_t action, const void *arg) +{ isc_socketevent_t *ev; ev = (isc_socketevent_t *)isc_event_allocate(sock->manager->mctx, sock, eventtype, action, arg, sizeof(*ev)); - if (ev == NULL) return (NULL); @@ -1326,7 +1353,8 @@ dump_msg(struct msghdr *msg, isc_socket_t *sock) { static int completeio_recv(isc_socket_t *sock, isc_socketevent_t *dev, - struct msghdr *messagehdr, int cc, int recv_errno) { + struct msghdr *messagehdr, int cc, int recv_errno) +{ size_t actual_count; isc_buffer_t *buffer; @@ -1444,31 +1472,27 @@ completeio_recv(isc_socket_t *sock, isc_socketevent_t *dev, dev->result = ISC_R_SUCCESS; return (DOIO_SUCCESS); } + static int startio_recv(isc_socket_t *sock, isc_socketevent_t *dev, int *nbytes, - BOOL bwait, int *recv_errno) { + int *recv_errno) +{ char *cmsg = NULL; char strbuf[ISC_STRERRORSIZE]; IoCompletionInfo *lpo; int status; - struct msghdr messagehdr; struct msghdr *msghdr; - if (!bwait) { - lpo = (IoCompletionInfo *) HeapAlloc(hHeapHandle, - HEAP_ZERO_MEMORY, sizeof(IoCompletionInfo)); - lpo->request_type = SOCKET_RECV; - lpo->dev = dev; - msghdr = &lpo->messagehdr; - } else { /* Wait for recv to complete */ - lpo = NULL; - msghdr = &messagehdr; - } - sock->references++; + lpo = (IoCompletionInfo *) HeapAlloc(hHeapHandle, + HEAP_ZERO_MEMORY, + sizeof(IoCompletionInfo)); + lpo->request_type = SOCKET_RECV; + lpo->dev = dev; + msghdr = &lpo->messagehdr; memset(msghdr, 0, sizeof(struct msghdr)); build_msghdr_recv(sock, dev, msghdr, cmsg, sock->iov, - &(sock->totalBytes)); + &(sock->totalBytes)); #if defined(ISC_SOCKET_DEBUG) dump_msg(msghdr, sock); @@ -1487,13 +1511,12 @@ startio_recv(isc_socket_t *sock, isc_socketevent_t *dev, int *nbytes, socket_log(sock, NULL, IOEVENT, isc_msgcat, ISC_MSGSET_SOCKET, ISC_MSG_DOIORECV, - "startio_recv: recvmsg(%d) %d bytes, err %d/%s", + "startio_recv: recvmsg(%d) %d bytes, " + "err %d/%s", sock->fd, *nbytes, *recv_errno, strbuf); } - status = completeio_recv(sock, dev, msghdr, *nbytes, *recv_errno); - if(status != DOIO_SOFT) { - sock->references--; - } + status = completeio_recv(sock, dev, msghdr, + *nbytes, *recv_errno); goto done; } dev->result = ISC_R_SUCCESS; @@ -1501,6 +1524,7 @@ startio_recv(isc_socket_t *sock, isc_socketevent_t *dev, int *nbytes, done: return (status); } + /* * Returns: * DOIO_SUCCESS The operation succeeded. dev->result contains @@ -1515,8 +1539,9 @@ done: * No other return values are possible. */ static int -completeio_send(isc_socket_t *sock, isc_socketevent_t *dev, struct msghdr *messagehdr, int cc, - int send_errno) { +completeio_send(isc_socket_t *sock, isc_socketevent_t *dev, + struct msghdr *messagehdr, int cc, int send_errno) +{ char addrbuf[ISC_SOCKADDR_FORMATSIZE]; char strbuf[ISC_STRERRORSIZE]; @@ -1594,28 +1619,24 @@ completeio_send(isc_socket_t *sock, isc_socketevent_t *dev, struct msghdr *messa dev->result = ISC_R_SUCCESS; return (DOIO_SUCCESS); } + static int startio_send(isc_socket_t *sock, isc_socketevent_t *dev, int *nbytes, - BOOL bwait, int *send_errno) { + int *send_errno) +{ char *cmsg = NULL; char strbuf[ISC_STRERRORSIZE]; IoCompletionInfo *lpo; int status; - struct msghdr messagehdr; struct msghdr *msghdr; - if (!bwait) { - lpo = (IoCompletionInfo *) HeapAlloc(hHeapHandle, - HEAP_ZERO_MEMORY, sizeof(IoCompletionInfo)); - lpo->request_type = SOCKET_SEND; - lpo->dev = dev; - msghdr = &lpo->messagehdr; - } else { /* Wait for send to complete */ - lpo = NULL; - msghdr = &messagehdr; - } + lpo = (IoCompletionInfo *) HeapAlloc(hHeapHandle, + HEAP_ZERO_MEMORY, + sizeof(IoCompletionInfo)); + lpo->request_type = SOCKET_SEND; + lpo->dev = dev; + msghdr = &lpo->messagehdr; memset(msghdr, 0, sizeof(struct msghdr)); - sock->references++; build_msghdr_send(sock, dev, msghdr, cmsg, sock->iov, &(sock->totalBytes)); @@ -1633,13 +1654,12 @@ startio_send(isc_socket_t *sock, isc_socketevent_t *dev, int *nbytes, socket_log(sock, NULL, IOEVENT, isc_msgcat, ISC_MSGSET_SOCKET, ISC_MSG_INTERNALSEND, - "startio_send: internal_sendmsg(%d) %d bytes, err %d/%s", + "startio_send: internal_sendmsg(%d) %d " + "bytes, err %d/%s", sock->fd, *nbytes, *send_errno, strbuf); } - status = completeio_send(sock, dev, msghdr, *nbytes, *send_errno); - if(status != DOIO_SOFT) { - sock->references--; - } + status = completeio_send(sock, dev, msghdr, + *nbytes, *send_errno); goto done; } dev->result = ISC_R_SUCCESS; @@ -1647,6 +1667,7 @@ startio_send(isc_socket_t *sock, isc_socketevent_t *dev, int *nbytes, done: return (status); } + /* * Kill. * @@ -1657,6 +1678,7 @@ static void destroy_socket(isc_socket_t **sockp) { isc_socket_t *sock = *sockp; isc_socketmgr_t *manager = sock->manager; + isc_boolean_t dofree = ISC_TRUE; REQUIRE(sock != NULL); @@ -1670,15 +1692,14 @@ destroy_socket(isc_socket_t **sockp) { LOCK(&manager->lock); - /* - * No one has this socket open and the socket doesn't have to be - * locked. The socket_close function makes sure that if needed - * the event_wait loop removes any associated event from the list - * of events being waited on. - */ + LOCK(&sock->lock); socket_close(sock); - + if (sock->pending_recv != 0 || sock->pending_send != 0) { + dofree = ISC_FALSE; + sock->pending_free = 1; + } ISC_LIST_UNLINK(manager->socklist, sock, link); + UNLOCK(&sock->lock); if (ISC_LIST_EMPTY(manager->socklist)) SIGNAL(&manager->shutdown_ok); @@ -1686,10 +1707,10 @@ destroy_socket(isc_socket_t **sockp) { /* * XXX should reset manager->maxfd here */ - UNLOCK(&manager->lock); - free_socket(sockp); + if (dofree) + free_socket(sockp); } static isc_result_t @@ -1723,6 +1744,9 @@ allocate_socket(isc_socketmgr_t *manager, isc_sockettype_t type, sock->connect_ev = NULL; sock->pending_accept = 0; sock->pending_close = 0; + sock->pending_recv = 0; + sock->pending_send = 0; + sock->pending_free = 0; sock->iocp = 0; sock->listener = 0; sock->connected = 0; @@ -1824,11 +1848,13 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type, switch (type) { case isc_sockettype_udp: sock->fd = socket(pf, SOCK_DGRAM, IPPROTO_UDP); - result = connection_reset_fix(sock->fd); - if (result != ISC_R_SUCCESS) { - closesocket(sock->fd); - free_socket(&sock); - return (result); + if (sock->fd != INVALID_SOCKET) { + result = connection_reset_fix(sock->fd); + if (result != ISC_R_SUCCESS) { + closesocket(sock->fd); + free_socket(&sock); + return (result); + } } break; case isc_sockettype_tcp: @@ -1894,7 +1920,7 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type, if ((pf == AF_INET6) && (setsockopt(sock->fd, IPPROTO_IPV6, IPV6_PKTINFO, (void *)&on, sizeof(on)) < 0)) { - isc__strerror(WSAGetLaastError(), strbuf, sizeof(strbuf)); + isc__strerror(WSAGetLastError(), strbuf, sizeof(strbuf)); UNEXPECTED_ERROR(__FILE__, __LINE__, "setsockopt(%d, IPV6_PKTINFO) %s: %s", sock->fd, @@ -2068,14 +2094,6 @@ internal_accept(isc_socket_t *sock, int accept_errno) { INSIST(sock->pending_accept == 1); sock->pending_accept = 0; - INSIST(sock->references > 0); - sock->references--; /* the internal event is done with this socket */ - if (sock->references == 0) { - UNLOCK(&sock->lock); - destroy_socket(&sock); - return; - } - /* * Check any possible error status from the event notification here. * Note that we don't take any action since it was only @@ -2287,18 +2305,6 @@ internal_connect(isc_socket_t *sock, int connect_errno) { LOCK(&sock->lock); /* - * When the internal event was sent the reference count was bumped - * to keep the socket around for us. Decrement the count here. - */ - INSIST(sock->references > 0); - sock->references--; - if (sock->references == 0) { - UNLOCK(&sock->lock); - destroy_socket(&sock); - return; - } - - /* * Has this event been canceled? */ dev = sock->connect_ev; @@ -2368,7 +2374,9 @@ internal_connect(isc_socket_t *sock, int connect_errno) { } static void -internal_recv(isc_socket_t *sock, isc_socketevent_t *dev, struct msghdr *messagehdr, int nbytes, int recv_errno) { +internal_recv(isc_socket_t *sock, isc_socketevent_t *dev, + struct msghdr *messagehdr, int nbytes, int recv_errno) +{ isc_socketevent_t *ldev; int io_state; int cc; @@ -2380,14 +2388,8 @@ internal_recv(isc_socket_t *sock, isc_socketevent_t *dev, struct msghdr *message isc_msgcat, ISC_MSGSET_SOCKET, ISC_MSG_INTERNALRECV, "internal_recv: task got socket event %p", dev); - INSIST(sock->references > 0); - sock->references--; /* the internal event is done with this socket */ - if (sock->references == 0) { - UNLOCK(&sock->lock); - destroy_socket(&sock); - return; - } - + INSIST(sock->pending_recv > 0); + sock->pending_recv--; /* If the event is no longer in the list we can just return */ ldev = ISC_LIST_HEAD(sock->recv_list); while (ldev != NULL && ldev != dev) { @@ -2400,34 +2402,36 @@ internal_recv(isc_socket_t *sock, isc_socketevent_t *dev, struct msghdr *message * Try to do as much I/O as possible on this socket. There are no * limits here, currently. */ - switch (completeio_recv(sock, dev, messagehdr, nbytes, recv_errno)) { - case DOIO_SOFT: - cc = 0; - recv_errno = 0; - io_state = startio_recv(sock, dev, &cc, FALSE, &recv_errno); - goto done; + switch (completeio_recv(sock, dev, messagehdr, nbytes, recv_errno)) { + case DOIO_SOFT: + cc = 0; + recv_errno = 0; + io_state = startio_recv(sock, dev, &cc, &recv_errno); + goto done; - case DOIO_EOF: - /* - * read of 0 means the remote end was closed. - * Run through the event queue and dispatch all - * the events with an EOF result code. - */ - dev->result = ISC_R_EOF; - send_recvdone_event(sock, &dev); - goto done; + case DOIO_EOF: + /* + * read of 0 means the remote end was closed. + * Run through the event queue and dispatch all + * the events with an EOF result code. + */ + dev->result = ISC_R_EOF; + send_recvdone_event(sock, &dev); + goto done; - case DOIO_SUCCESS: - case DOIO_HARD: - send_recvdone_event(sock, &dev); - break; - } + case DOIO_SUCCESS: + case DOIO_HARD: + send_recvdone_event(sock, &dev); + break; + } done: UNLOCK(&sock->lock); } static void -internal_send(isc_socket_t *sock, isc_socketevent_t *dev, struct msghdr *messagehdr, int nbytes, int send_errno) { +internal_send(isc_socket_t *sock, isc_socketevent_t *dev, + struct msghdr *messagehdr, int nbytes, int send_errno) +{ isc_socketevent_t *ldev; int io_state; int cc; @@ -2442,13 +2446,8 @@ internal_send(isc_socket_t *sock, isc_socketevent_t *dev, struct msghdr *message isc_msgcat, ISC_MSGSET_SOCKET, ISC_MSG_INTERNALSEND, "internal_send: task got socket event %p", dev); - INSIST(sock->references > 0); - sock->references--; /* the internal event is done with this socket */ - if (sock->references == 0) { - UNLOCK(&sock->lock); - destroy_socket(&sock); - return; - } + INSIST(sock->pending_send > 0); + sock->pending_send--; /* If the event is no longer in the list we can just return */ ldev = ISC_LIST_HEAD(sock->send_list); @@ -2465,7 +2464,7 @@ internal_send(isc_socket_t *sock, isc_socketevent_t *dev, struct msghdr *message case DOIO_SOFT: cc = 0; send_errno = 0; - io_state = startio_send(sock, dev, &cc, FALSE, &send_errno); + io_state = startio_send(sock, dev, &cc, &send_errno); goto done; case DOIO_HARD: @@ -2489,8 +2488,6 @@ SocketIoThread(LPVOID ThreadContext) { isc_socketmgr_t *manager = ThreadContext; BOOL bSuccess = FALSE; DWORD nbytes; - DWORD tbytes; - DWORD tflags; IoCompletionInfo *lpo = NULL; isc_socket_t *sock = NULL; int request; @@ -2506,7 +2503,9 @@ SocketIoThread(LPVOID ThreadContext) { * preempt normal recv packet processing, but not * higher than the timer sync thread. */ - if (!SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_ABOVE_NORMAL)) { + if (!SetThreadPriority(GetCurrentThread(), + THREAD_PRIORITY_ABOVE_NORMAL)) + { errval = GetLastError(); isc__strerror(errval, strbuf, sizeof(strbuf)); FATAL_ERROR(__FILE__, __LINE__, @@ -2516,33 +2515,53 @@ SocketIoThread(LPVOID ThreadContext) { strbuf); } - /* * Loop forever waiting on I/O Completions and then processing them */ - while(TRUE) { + while (TRUE) { bSuccess = GetQueuedCompletionStatus ( manager->hIoCompletionPort, &nbytes, (LPDWORD) &sock, (LPOVERLAPPED *)&lpo, - INFINITE - ); - if(lpo == NULL ) { + INFINITE); + if (lpo == NULL) { /* * Received request to exit */ break; } errstatus = 0; - if(!bSuccess) { + if (!bSuccess) { + isc_boolean_t dofree = ISC_FALSE; + REQUIRE(VALID_SOCKET(sock)); /* - * I/O Failure - * Find out why + * Was this the socket closed under us? */ - WSAGetOverlappedResult(sock->fd, (LPWSAOVERLAPPED) &lpo, - &tbytes, FALSE, &tflags); - dev = lpo->dev; + errstatus = WSAGetLastError(); + if (nbytes == 0 && errstatus == WSA_OPERATION_ABORTED) { + LOCK(&sock->lock); + switch (lpo->request_type) { + case SOCKET_RECV: + INSIST(sock->pending_recv > 0); + sock->pending_recv--; + break; + case SOCKET_SEND: + INSIST(sock->pending_send > 0); + sock->pending_send--; + break; + } + if (sock->pending_recv == 0 && + sock->pending_send == 0 && + sock->pending_free) + dofree = ISC_TRUE; + UNLOCK(&sock->lock); + if (dofree) + free_socket(&sock); + if (lpo != NULL) + HeapFree(hHeapHandle, 0, lpo); + continue; + } } request = lpo->request_type; @@ -2550,20 +2569,17 @@ SocketIoThread(LPVOID ThreadContext) { messagehdr = &lpo->messagehdr; switch (request) { - case SOCKET_CANCEL: - break; case SOCKET_RECV: internal_recv(sock, dev, messagehdr, nbytes, errstatus); break; case SOCKET_SEND: internal_send(sock, dev, messagehdr, nbytes, errstatus); break; - default: - break; /* Unknown: Just ignore it */ } if (lpo != NULL) HeapFree(hHeapHandle, 0, lpo); } + /* * Exit Completion Port Thread */ @@ -2572,6 +2588,7 @@ SocketIoThread(LPVOID ThreadContext) { ISC_MSG_EXITING, "SocketIoThread exiting")); return ((isc_threadresult_t)0); } + /* * This is the thread that will loop forever, waiting for an event to * happen. @@ -2633,7 +2650,6 @@ event_wait(void *uap) { } while (cc < 0 && !manager->bShutdown && manager->event_written == 0); - if (manager->bShutdown) break; @@ -2692,11 +2708,9 @@ event_wait(void *uap) { if (wsock->listener == 1 && wsock->pending_accept == 0) { wsock->pending_accept = 1; - wsock->references++; internal_accept(wsock, event_errno); } else { - wsock->references++; internal_connect(wsock, event_errno); } } @@ -2708,6 +2722,7 @@ event_wait(void *uap) { return ((isc_threadresult_t)0); } + /* * Create a new socket manager. */ @@ -2863,7 +2878,8 @@ isc_socketmgr_destroy(isc_socketmgr_t **managerp) { static isc_result_t socket_recv(isc_socket_t *sock, isc_socketevent_t *dev, isc_task_t *task, - unsigned int flags) { + unsigned int flags) +{ int io_state; int cc = 0; isc_task_t *ntask = NULL; @@ -2874,7 +2890,7 @@ socket_recv(isc_socket_t *sock, isc_socketevent_t *dev, isc_task_t *task, LOCK(&sock->lock); iocompletionport_update(sock); - io_state = startio_recv(sock, dev, &cc, FALSE, &recv_errno); + io_state = startio_recv(sock, dev, &cc, &recv_errno); switch (io_state) { case DOIO_SOFT: @@ -3052,7 +3068,7 @@ socket_send(isc_socket_t *sock, isc_socketevent_t *dev, isc_task_t *task, LOCK(&sock->lock); have_lock = ISC_TRUE; iocompletionport_update(sock); - io_state = startio_send(sock, dev, &cc, FALSE, &send_errno); + io_state = startio_send(sock, dev, &cc, &send_errno); switch (io_state) { case DOIO_SOFT: @@ -3211,7 +3227,11 @@ isc_socket_bind(isc_socket_t *sock, isc_sockaddr_t *sockaddr) { UNLOCK(&sock->lock); return (ISC_R_FAMILYMISMATCH); } - if (setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on, + /* + * Only set SO_REUSEADDR when we want a specific port. + */ + if (isc_sockaddr_getport(sockaddr) != (in_port_t)0 && + setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on, sizeof(on)) < 0) { UNEXPECTED_ERROR(__FILE__, __LINE__, "setsockopt(%d) %s", sock->fd, @@ -3645,7 +3665,6 @@ isc_socket_cancel(isc_socket_t *sock, isc_task_t *task, unsigned int how) { isc_task_t *current_task; dev = ISC_LIST_HEAD(sock->accept_list); - socket_event_delete(sock); while (dev != NULL) { current_task = dev->ev_sender; diff --git a/dist/bind/lib/isccc/Makefile.in b/dist/bind/lib/isccc/Makefile.in index 2bee902664e..bab86d43523 100644 --- a/dist/bind/lib/isccc/Makefile.in +++ b/dist/bind/lib/isccc/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.2.12.4 2004/03/06 08:15:18 marka Exp +# Id: Makefile.in,v 1.2.12.5 2004/07/20 07:01:58 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -69,7 +69,7 @@ libisccc.@SA@: ${OBJS} libisccc.la: ${OBJS} ${LIBTOOL_MODE_LINK} \ - ${CC} ${ALL_CFLAGS} -o libisccc.la -rpath ${libdir} \ + ${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libisccc.la -rpath ${libdir} \ -version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \ ${OBJS} ${LIBS} ${ISCLIBS} diff --git a/dist/bind/lib/isccc/api b/dist/bind/lib/isccc/api index 8cf13ed487b..4f115e73f2d 100644 --- a/dist/bind/lib/isccc/api +++ b/dist/bind/lib/isccc/api @@ -1,3 +1,3 @@ LIBINTERFACE = 2 -LIBREVISION = 0 +LIBREVISION = 1 LIBAGE = 2 diff --git a/dist/bind/lib/isccc/cc.c b/dist/bind/lib/isccc/cc.c index 993db6bafcb..0bde13bf8a1 100644 --- a/dist/bind/lib/isccc/cc.c +++ b/dist/bind/lib/isccc/cc.c @@ -1,4 +1,4 @@ -/* $NetBSD: cc.c,v 1.1.1.1 2004/05/17 23:45:08 christos Exp $ */ +/* $NetBSD: cc.c,v 1.1.1.2 2004/11/06 23:55:59 christos Exp $ */ /* * Portions Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -18,7 +18,7 @@ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* Id: cc.c,v 1.4.2.3.2.4 2004/03/06 08:15:19 marka Exp */ +/* Id: cc.c,v 1.4.2.3.2.5 2004/08/28 06:25:23 marka Exp */ #include <config.h> @@ -28,6 +28,7 @@ #include <isc/assertions.h> #include <isc/hmacmd5.h> +#include <isc/print.h> #include <isc/stdlib.h> #include <isccc/alist.h> diff --git a/dist/bind/lib/isccfg/Makefile.in b/dist/bind/lib/isccfg/Makefile.in index 80fb0d7891c..61c38b07de7 100644 --- a/dist/bind/lib/isccfg/Makefile.in +++ b/dist/bind/lib/isccfg/Makefile.in @@ -13,7 +13,7 @@ # 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.7 2004/03/09 05:21:09 marka Exp +# Id: Makefile.in,v 1.6.12.8 2004/07/20 07:01:58 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -66,7 +66,7 @@ libisccfg.@SA@: ${OBJS} libisccfg.la: ${OBJS} ${LIBTOOL_MODE_LINK} \ - ${CC} ${ALL_CFLAGS} -o libisccfg.la -rpath ${libdir} \ + ${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libisccfg.la -rpath ${libdir} \ -version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \ ${OBJS} ${LIBS} ${DNSLIBS} ${ISCCCLIBS} ${ISCLIBS} diff --git a/dist/bind/lib/isccfg/api b/dist/bind/lib/isccfg/api index 7f2166bec3a..7c378e6ef95 100644 --- a/dist/bind/lib/isccfg/api +++ b/dist/bind/lib/isccfg/api @@ -1,3 +1,3 @@ LIBINTERFACE = 1 -LIBREVISION = 2 +LIBREVISION = 4 LIBAGE = 0 diff --git a/dist/bind/lib/isccfg/namedconf.c b/dist/bind/lib/isccfg/namedconf.c index ba1c21a8634..8e0a7624170 100644 --- a/dist/bind/lib/isccfg/namedconf.c +++ b/dist/bind/lib/isccfg/namedconf.c @@ -1,4 +1,4 @@ -/* $NetBSD: namedconf.c,v 1.1.1.1 2004/05/17 23:45:09 christos Exp $ */ +/* $NetBSD: namedconf.c,v 1.1.1.2 2004/11/06 23:55:59 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: namedconf.c,v 1.21.44.27 2004/04/15 23:56:34 marka Exp */ +/* Id: namedconf.c,v 1.21.44.28 2004/06/04 02:33:01 marka Exp */ #include <config.h> @@ -661,6 +661,28 @@ static cfg_type_t cfg_type_mustbesecure = { }; /* + * dnssec-lookaside + */ + +static keyword_type_t trustanchor_kw = { "trust-anchor", &cfg_type_astring }; + +static cfg_type_t cfg_type_trustanchor = { + "trust-anchor", parse_keyvalue, print_keyvalue, doc_keyvalue, + &cfg_rep_string, &trustanchor_kw +}; + +static cfg_tuplefielddef_t lookaside_fields[] = { + { "domain", &cfg_type_astring, 0 }, + { "trust-anchor", &cfg_type_trustanchor, 0 }, + { NULL, NULL, 0 } +}; + +static cfg_type_t cfg_type_lookaside = { + "lookaside", cfg_parse_tuple, cfg_print_tuple, cfg_doc_tuple, + &cfg_rep_tuple, lookaside_fields +}; + +/* * Clauses that can be found within the 'view' statement, * with defaults in the 'options' statement. */ @@ -705,7 +727,7 @@ view_clauses[] = { { "disable-algorithms", &cfg_type_disablealgorithm, CFG_CLAUSEFLAG_MULTI }, { "dnssec-enable", &cfg_type_boolean, 0 }, - { "dnssec-lookaside", &cfg_type_astring, 0 }, + { "dnssec-lookaside", &cfg_type_lookaside, CFG_CLAUSEFLAG_MULTI }, { "dnssec-must-be-secure", &cfg_type_mustbesecure, CFG_CLAUSEFLAG_MULTI }, { NULL, NULL, 0 } @@ -1203,6 +1225,7 @@ controls_clauses[] = { CFG_CLAUSEFLAG_MULTI|CFG_CLAUSEFLAG_NOTIMP }, { NULL, NULL, 0 } }; + static cfg_clausedef_t * controls_clausesets[] = { controls_clauses, diff --git a/dist/bind/lib/isccfg/parser.c b/dist/bind/lib/isccfg/parser.c index 8ad5956eb78..698f8c202f9 100644 --- a/dist/bind/lib/isccfg/parser.c +++ b/dist/bind/lib/isccfg/parser.c @@ -1,4 +1,4 @@ -/* $NetBSD: parser.c,v 1.1.1.1 2004/05/17 23:45:09 christos Exp $ */ +/* $NetBSD: parser.c,v 1.1.1.2 2004/11/06 23:56:00 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: parser.c,v 1.70.2.20.2.17 2004/03/16 12:38:15 marka Exp */ +/* Id: parser.c,v 1.70.2.20.2.18 2004/05/15 03:46:13 jinmei Exp */ #include <config.h> @@ -1673,7 +1673,7 @@ token_addr(cfg_parser_t *pctx, unsigned int flags, isc_netaddr_t *na) { } if ((flags & CFG_ADDR_V6OK) != 0 && strlen(s) <= 127U) { - char buf[128]; + char buf[128]; /* see lib/bind9/getaddresses.c */ char *d; /* zone delimiter */ isc_uint32_t zone = 0; /* scope zone ID */ @@ -1684,6 +1684,7 @@ token_addr(cfg_parser_t *pctx, unsigned int flags, isc_netaddr_t *na) { if (inet_pton(AF_INET6, buf, &in6a) == 1) { if (d != NULL) { +#ifdef ISC_PLATFORM_HAVESCOPEID isc_result_t result; result = isc_netscope_pton(AF_INET6, @@ -1692,6 +1693,9 @@ token_addr(cfg_parser_t *pctx, unsigned int flags, isc_netaddr_t *na) { &zone); if (result != ISC_R_SUCCESS) return (result); +#else + return (ISC_R_BADADDRESSFORM); +#endif } isc_netaddr_fromin6(na, &in6a); diff --git a/dist/bind/lib/lwres/Makefile.in b/dist/bind/lib/lwres/Makefile.in index 1dc36718b9d..a74bb8e099c 100644 --- a/dist/bind/lib/lwres/Makefile.in +++ b/dist/bind/lib/lwres/Makefile.in @@ -13,7 +13,7 @@ # 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.4 2004/03/08 09:05:09 marka Exp +# Id: Makefile.in,v 1.25.12.6 2004/08/28 06:25:23 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -35,14 +35,14 @@ OBJS = context.@O@ gai_strerror.@O@ getaddrinfo.@O@ gethost.@O@ \ getipnode.@O@ getnameinfo.@O@ getrrset.@O@ herror.@O@ \ lwbuffer.@O@ lwconfig.@O@ lwpacket.@O@ lwresutil.@O@ \ lwres_gabn.@O@ lwres_gnba.@O@ lwres_grbn.@O@ lwres_noop.@O@ \ - lwinetaton.@O@ lwinetpton.@O@ lwinetntop.@O@ + lwinetaton.@O@ lwinetpton.@O@ lwinetntop.@O@ print.@O@ # Alphabetically SRCS = context.c gai_strerror.c getaddrinfo.c gethost.c \ getipnode.c getnameinfo.c getrrset.c herror.c \ lwbuffer.c lwconfig.c lwpacket.c lwresutil.c \ lwres_gabn.c lwres_gnba.c lwres_grbn.c lwres_noop.c \ - lwinetaton.c lwinetpton.c lwinetntop.c + lwinetaton.c lwinetpton.c lwinetntop.c print.c LIBS = @LIBS@ @@ -65,7 +65,7 @@ liblwres.@SA@: ${OBJS} version.@O@ liblwres.la: ${OBJS} version.@O@ ${LIBTOOL_MODE_LINK} \ - ${CC} ${ALL_CFLAGS} -o liblwres.la -rpath ${libdir} \ + ${CC} ${ALL_CFLAGS} ${LDFLAGS} -o liblwres.la -rpath ${libdir} \ -version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \ ${OBJS} version.@O@ ${LIBS} diff --git a/dist/bind/lib/lwres/api b/dist/bind/lib/lwres/api index 44e7ba41c0a..1da8b023146 100644 --- a/dist/bind/lib/lwres/api +++ b/dist/bind/lib/lwres/api @@ -1,3 +1,3 @@ LIBINTERFACE = 3 -LIBREVISION = 0 +LIBREVISION = 1 LIBAGE = 2 diff --git a/dist/bind/lib/lwres/include/lwres/platform.h.in b/dist/bind/lib/lwres/include/lwres/platform.h.in index 7357836b657..ed9f9679837 100644 --- a/dist/bind/lib/lwres/include/lwres/platform.h.in +++ b/dist/bind/lib/lwres/include/lwres/platform.h.in @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: platform.h.in,v 1.12.2.1.10.1 2004/03/06 08:15:36 marka Exp */ +/* Id: platform.h.in,v 1.12.2.1.10.2 2004/08/28 06:25:26 marka Exp */ #ifndef LWRES_PLATFORM_H #define LWRES_PLATFORM_H 1 @@ -78,6 +78,16 @@ */ @LWRES_PLATFORM_USEDECLSPEC@ +/* + * Defined this system needs vsnprintf() and snprintf(). + */ +@LWRES_PLATFORM_NEEDVSNPRINTF@ + +/* + * If this system need a modern sprintf() that returns (int) not (char*). + */ +@LWRES_PLATFORM_NEEDSPRINTF@ + #ifndef LWRES_PLATFORM_USEDECLSPEC #define LIBLWRES_EXTERNAL_DATA #else diff --git a/dist/bind/lib/lwres/lwinetntop.c b/dist/bind/lib/lwres/lwinetntop.c index a3f5071708b..4b0c0740d97 100644 --- a/dist/bind/lib/lwres/lwinetntop.c +++ b/dist/bind/lib/lwres/lwinetntop.c @@ -1,4 +1,4 @@ -/* $NetBSD: lwinetntop.c,v 1.1.1.1 2004/05/17 23:45:10 christos Exp $ */ +/* $NetBSD: lwinetntop.c,v 1.1.1.2 2004/11/06 23:56:00 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -19,7 +19,7 @@ #if defined(LIBC_SCCS) && !defined(lint) static char rcsid[] = - "Id: lwinetntop.c,v 1.9.12.2 2004/03/06 08:15:32 marka Exp"; + "Id: lwinetntop.c,v 1.9.12.3 2004/08/28 06:25:24 marka Exp"; #endif /* LIBC_SCCS and not lint */ #include <config.h> @@ -29,6 +29,7 @@ static char rcsid[] = #include <string.h> #include <lwres/net.h> +#include "print_p.h" #define NS_INT16SZ 2 #define NS_IN6ADDRSZ 16 diff --git a/dist/bind/lib/lwres/man/lwres.html b/dist/bind/lib/lwres/man/lwres.html index e300bf3e50b..7981017d2d5 100644 --- a/dist/bind/lib/lwres/man/lwres.html +++ b/dist/bind/lib/lwres/man/lwres.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres.html,v 1.4.2.1.4.1 2004/03/06 08:15:37 marka Exp --> +<!-- Id: lwres.html,v 1.4.2.1.4.2 2004/08/22 23:39:02 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres</A -></H1 +></A +>lwres</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN11" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN12" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/lwres.h></PRE @@ -98,41 +98,41 @@ NAME="AEN18" ><P >The lwresd library implements multiple name service APIs. The standard -<TT +<CODE CLASS="FUNCTION" ->gethostbyname()</TT +>gethostbyname()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->gethostbyaddr()</TT +>gethostbyaddr()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->gethostbyname_r()</TT +>gethostbyname_r()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->gethostbyaddr_r()</TT +>gethostbyaddr_r()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->getaddrinfo()</TT +>getaddrinfo()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->getipnodebyname()</TT +>getipnodebyname()</CODE >, and -<TT +<CODE CLASS="FUNCTION" ->getipnodebyaddr()</TT +>getipnodebyaddr()</CODE > functions are all supported. To allow the lwres library to coexist with system libraries that define functions of the same name, the library defines these functions with names prefixed by -<TT +<VAR CLASS="LITERAL" ->lwres_</TT +>lwres_</VAR >. To define the standard names, applications must include the header file @@ -142,23 +142,23 @@ CLASS="FILENAME" > which contains macro definitions mapping the standard function names into -<TT +<VAR CLASS="LITERAL" ->lwres_</TT +>lwres_</VAR > prefixed ones. Operating system vendors who integrate the lwres library into their base distributions should rename the functions in the library proper so that the renaming macros are not needed.</P ><P >The library also provides a native API consisting of the functions -<TT +<CODE CLASS="FUNCTION" ->lwres_getaddrsbyname()</TT +>lwres_getaddrsbyname()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_getnamebyaddr()</TT +>lwres_getnamebyaddr()</CODE >. These may be called by applications that require more detailed control over the lookup process than the standard functions @@ -167,9 +167,9 @@ provide.</P >In addition to these name service independent address lookup functions, the library implements a new, experimental API for looking up arbitrary DNS resource records, using the -<TT +<CODE CLASS="FUNCTION" ->lwres_getaddrsbyname()</TT +>lwres_getaddrsbyname()</CODE > function.</P ><P @@ -201,66 +201,58 @@ sequence of actions.</P CLASS="TYPE" >lwres_packet_t</SPAN >, -called <TT +called <VAR CLASS="VARNAME" ->pkt</TT +>pkt</VAR > below.</P ><P ->(2) Set <TT +>(2) Set <CODE CLASS="STRUCTFIELD" -><I ->pkt.recvlength</I -></TT +>pkt.recvlength</CODE > to the maximum length we will accept. This is done so the receiver of our packets knows how large our receive buffer is. The "default" is a constant in <TT CLASS="FILENAME" >lwres.h</TT ->: <TT +>: <CODE CLASS="CONSTANT" ->LWRES_RECVLENGTH = 4096</TT +>LWRES_RECVLENGTH = 4096</CODE >.</P ><P ->(3) Set <TT +>(3) Set <CODE CLASS="STRUCTFIELD" -><I ->pkt.serial</I -></TT +>pkt.serial</CODE > to a unique serial number. This value is echoed back to the application by the remote server.</P ><P ->(4) Set <TT +>(4) Set <CODE CLASS="STRUCTFIELD" -><I ->pkt.pktflags</I -></TT +>pkt.pktflags</CODE >. Usually this is set to 0.</P ><P ->(5) Set <TT +>(5) Set <CODE CLASS="STRUCTFIELD" -><I ->pkt.result</I -></TT +>pkt.result</CODE > to 0.</P ><P ->(6) Call <TT +>(6) Call <CODE CLASS="FUNCTION" ->lwres_*request_render()</TT +>lwres_*request_render()</CODE >, or marshall in the data using the primitives -such as <TT +such as <CODE CLASS="FUNCTION" ->lwres_packet_render()</TT +>lwres_packet_render()</CODE > and storing the packet data.</P ><P >(7) Transmit the resulting buffer.</P ><P ->(8) Call <TT +>(8) Call <CODE CLASS="FUNCTION" ->lwres_*response_parse()</TT +>lwres_*response_parse()</CODE > to parse any packets received.</P ><P @@ -283,27 +275,27 @@ following is typically involved in processing each request packet.</P CLASS="TYPE" >lwres_packet_t</SPAN > is used -in both the <TT +in both the <CODE CLASS="FUNCTION" ->_parse()</TT -> and <TT +>_parse()</CODE +> and <CODE CLASS="FUNCTION" ->_render()</TT +>_render()</CODE > calls, with only a few modifications made to the packet header's contents between uses. This method is recommended as it keeps the serial, opcode, and other fields correct.</P ><P ->(1) When a packet is received, call <TT +>(1) When a packet is received, call <CODE CLASS="FUNCTION" ->lwres_*request_parse()</TT +>lwres_*request_parse()</CODE > to unmarshall it. This returns a <SPAN CLASS="TYPE" >lwres_packet_t</SPAN -> (also called <TT +> (also called <VAR CLASS="VARNAME" ->pkt</TT +>pkt</VAR >, below) as well as a data specific type, such as <SPAN CLASS="TYPE" @@ -312,42 +304,36 @@ CLASS="TYPE" ><P >(2) Process the request in the data specific type.</P ><P ->(3) Set the <TT +>(3) Set the <CODE CLASS="STRUCTFIELD" -><I ->pkt.result</I -></TT +>pkt.result</CODE >, -<TT +<CODE CLASS="STRUCTFIELD" -><I ->pkt.recvlength</I -></TT +>pkt.recvlength</CODE > as above. All other fields can -be left untouched since they were filled in by the <TT +be left untouched since they were filled in by the <CODE CLASS="FUNCTION" ->*_parse()</TT +>*_parse()</CODE > call -above. If using <TT +above. If using <CODE CLASS="FUNCTION" ->lwres_*response_render()</TT +>lwres_*response_render()</CODE >, -<TT +<CODE CLASS="STRUCTFIELD" -><I ->pkt.pktflags</I -></TT +>pkt.pktflags</CODE > will be set up -properly. Otherwise, the <TT +properly. Otherwise, the <CODE CLASS="CONSTANT" ->LWRES_LWPACKETFLAG_RESPONSE</TT +>LWRES_LWPACKETFLAG_RESPONSE</CODE > bit should be set.</P ><P >(4) Call the data specific rendering function, such as -<TT +<CODE CLASS="FUNCTION" ->lwres_gabnresponse_render()</TT +>lwres_gabnresponse_render()</CODE >.</P ><P >(5) Send the resulting packet to the client.</P diff --git a/dist/bind/lib/lwres/man/lwres_buffer.html b/dist/bind/lib/lwres/man/lwres_buffer.html index df2edd18b10..1e8efc95ce0 100644 --- a/dist/bind/lib/lwres/man/lwres_buffer.html +++ b/dist/bind/lib/lwres/man/lwres_buffer.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_buffer.html,v 1.4.2.1.4.1 2004/03/06 08:15:37 marka Exp --> +<!-- Id: lwres_buffer.html,v 1.4.2.1.4.2 2004/08/22 23:39:03 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_buffer</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_buffer</A -></H1 +></A +>lwres_buffer</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN26" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN27" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/lwbuffer.h></PRE @@ -205,9 +205,9 @@ NAME="AEN106" >These functions provide bounds checked access to a region of memory where data is being read or written. They are based on, and similar to, the -<TT +<VAR CLASS="LITERAL" ->isc_buffer_</TT +>isc_buffer_</VAR > functions in the ISC library.</P ><P @@ -308,323 +308,267 @@ CLASS="PROGRAMLISTING" b-c == optional active region.</PRE ></P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_buffer_init()</TT +>lwres_buffer_init()</CODE > initializes the <SPAN CLASS="TYPE" >lwres_buffer_t</SPAN > -<TT +<VAR CLASS="PARAMETER" -><I ->*b</I -></TT +>*b</VAR > and assocates it with the memory region of size -<TT +<VAR CLASS="PARAMETER" -><I ->length</I -></TT +>length</VAR > bytes starting at location -<TT +<VAR CLASS="PARAMETER" -><I ->base.</I -></TT +>base.</VAR ></P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_buffer_invalidate()</TT +>lwres_buffer_invalidate()</CODE > marks the buffer -<TT +<VAR CLASS="PARAMETER" -><I ->*b</I -></TT +>*b</VAR > as invalid. Invalidating a buffer after use is not required, but makes it possible to catch its possible accidental use.</P ><P >The functions -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_add()</TT +>lwres_buffer_add()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_subtract()</TT +>lwres_buffer_subtract()</CODE > respectively increase and decrease the used space in buffer -<TT +<VAR CLASS="PARAMETER" -><I ->*b</I -></TT +>*b</VAR > by -<TT +<VAR CLASS="PARAMETER" -><I ->n</I -></TT +>n</VAR > bytes. -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_add()</TT +>lwres_buffer_add()</CODE > checks for buffer overflow and -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_subtract()</TT +>lwres_buffer_subtract()</CODE > checks for underflow. These functions do not allocate or deallocate memory. They just change the value of -<TT +<CODE CLASS="STRUCTFIELD" -><I ->used</I -></TT +>used</CODE >.</P ><P >A buffer is re-initialised by -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_clear()</TT +>lwres_buffer_clear()</CODE >. The function sets -<TT +<CODE CLASS="STRUCTFIELD" -><I ->used</I -></TT +>used</CODE > , -<TT +<CODE CLASS="STRUCTFIELD" -><I ->current</I -></TT +>current</CODE > and -<TT +<CODE CLASS="STRUCTFIELD" -><I ->active</I -></TT +>active</CODE > to zero.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_buffer_first</TT +>lwres_buffer_first</CODE > makes the consumed region of buffer -<TT +<VAR CLASS="PARAMETER" -><I ->*p</I -></TT +>*p</VAR > empty by setting -<TT +<CODE CLASS="STRUCTFIELD" -><I ->current</I -></TT +>current</CODE > to zero (the start of the buffer).</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_buffer_forward()</TT +>lwres_buffer_forward()</CODE > increases the consumed region of buffer -<TT +<VAR CLASS="PARAMETER" -><I ->*b</I -></TT +>*b</VAR > by -<TT +<VAR CLASS="PARAMETER" -><I ->n</I -></TT +>n</VAR > bytes, checking for overflow. Similarly, -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_back()</TT +>lwres_buffer_back()</CODE > decreases buffer -<TT +<VAR CLASS="PARAMETER" -><I ->b</I -></TT +>b</VAR >'s consumed region by -<TT +<VAR CLASS="PARAMETER" -><I ->n</I -></TT +>n</VAR > bytes and checks for underflow.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_buffer_getuint8()</TT +>lwres_buffer_getuint8()</CODE > reads an unsigned 8-bit integer from -<TT +<VAR CLASS="PARAMETER" -><I ->*b</I -></TT +>*b</VAR > and returns it. -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_putuint8()</TT +>lwres_buffer_putuint8()</CODE > writes the unsigned 8-bit integer -<TT +<VAR CLASS="PARAMETER" -><I ->val</I -></TT +>val</VAR > to buffer -<TT +<VAR CLASS="PARAMETER" -><I ->*b</I -></TT +>*b</VAR >.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_buffer_getuint16()</TT +>lwres_buffer_getuint16()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_getuint32()</TT +>lwres_buffer_getuint32()</CODE > are identical to -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_putuint8()</TT +>lwres_buffer_putuint8()</CODE > except that they respectively read an unsigned 16-bit or 32-bit integer in network byte order from -<TT +<VAR CLASS="PARAMETER" -><I ->b</I -></TT +>b</VAR >. Similarly, -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_putuint16()</TT +>lwres_buffer_putuint16()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_putuint32()</TT +>lwres_buffer_putuint32()</CODE > writes the unsigned 16-bit or 32-bit integer -<TT +<VAR CLASS="PARAMETER" -><I ->val</I -></TT +>val</VAR > to buffer -<TT +<VAR CLASS="PARAMETER" -><I ->b</I -></TT +>b</VAR >, in network byte order.</P ><P >Arbitrary amounts of data are read or written from a lightweight resolver buffer with -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_getmem()</TT +>lwres_buffer_getmem()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_putmem()</TT +>lwres_buffer_putmem()</CODE > respectively. -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_putmem()</TT +>lwres_buffer_putmem()</CODE > copies -<TT +<VAR CLASS="PARAMETER" -><I ->length</I -></TT +>length</VAR > bytes of memory at -<TT +<VAR CLASS="PARAMETER" -><I ->base</I -></TT +>base</VAR > to -<TT +<VAR CLASS="PARAMETER" -><I ->b</I -></TT +>b</VAR >. Conversely, -<TT +<CODE CLASS="FUNCTION" ->lwres_buffer_getmem()</TT +>lwres_buffer_getmem()</CODE > copies -<TT +<VAR CLASS="PARAMETER" -><I ->length</I -></TT +>length</VAR > bytes of memory from -<TT +<VAR CLASS="PARAMETER" -><I ->b</I -></TT +>b</VAR > to -<TT +<VAR CLASS="PARAMETER" -><I ->base</I -></TT +>base</VAR >.</P ></DIV ></BODY diff --git a/dist/bind/lib/lwres/man/lwres_config.html b/dist/bind/lib/lwres/man/lwres_config.html index 2c6a27a621a..42a73447cf0 100644 --- a/dist/bind/lib/lwres/man/lwres_config.html +++ b/dist/bind/lib/lwres/man/lwres_config.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_config.html,v 1.4.2.1.4.1 2004/03/06 08:15:38 marka Exp --> +<!-- Id: lwres_config.html,v 1.4.2.1.4.2 2004/08/22 23:39:03 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_config</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_config</A -></H1 +></A +>lwres_config</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN15" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN16" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/lwres.h></PRE @@ -114,9 +114,9 @@ NAME="AEN40" ><H2 >DESCRIPTION</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_conf_init()</TT +>lwres_conf_init()</CODE > creates an empty <SPAN @@ -124,16 +124,14 @@ CLASS="TYPE" >lwres_conf_t</SPAN > structure for lightweight resolver context -<TT +<VAR CLASS="PARAMETER" -><I ->ctx</I -></TT +>ctx</VAR >.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_conf_clear()</TT +>lwres_conf_clear()</CODE > frees up all the internal memory used by that @@ -142,30 +140,24 @@ CLASS="TYPE" >lwres_conf_t</SPAN > structure in resolver context -<TT +<VAR CLASS="PARAMETER" -><I ->ctx</I -></TT +>ctx</VAR >.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_conf_parse()</TT +>lwres_conf_parse()</CODE > opens the file -<TT +<VAR CLASS="PARAMETER" -><I ->filename</I -></TT +>filename</VAR > and parses it to initialise the resolver context -<TT +<VAR CLASS="PARAMETER" -><I ->ctx</I -></TT +>ctx</VAR >'s <SPAN CLASS="TYPE" @@ -173,9 +165,9 @@ CLASS="TYPE" > structure.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_conf_print()</TT +>lwres_conf_print()</CODE > prints the <SPAN @@ -183,22 +175,18 @@ CLASS="TYPE" >lwres_conf_t</SPAN > structure for resolver context -<TT +<VAR CLASS="PARAMETER" -><I ->ctx</I -></TT +>ctx</VAR > to the <SPAN CLASS="TYPE" >FILE</SPAN > -<TT +<VAR CLASS="PARAMETER" -><I ->fp</I -></TT +>fp</VAR >.</P ></DIV ><DIV @@ -209,9 +197,9 @@ NAME="AEN61" ><H2 >RETURN VALUES</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_conf_parse()</TT +>lwres_conf_parse()</CODE > returns <SPAN @@ -219,11 +207,9 @@ CLASS="ERRORCODE" >LWRES_R_SUCCESS</SPAN > if it successfully read and parsed -<TT +<VAR CLASS="PARAMETER" -><I ->filename</I -></TT +>filename</VAR >. It returns <SPAN @@ -231,18 +217,16 @@ CLASS="ERRORCODE" >LWRES_R_FAILURE</SPAN > if -<TT +<VAR CLASS="PARAMETER" -><I ->filename</I -></TT +>filename</VAR > could not be opened or contained incorrect resolver statements.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_conf_print()</TT +>lwres_conf_print()</CODE > returns <SPAN diff --git a/dist/bind/lib/lwres/man/lwres_context.html b/dist/bind/lib/lwres/man/lwres_context.html index cde04fed1f4..cafd261efe4 100644 --- a/dist/bind/lib/lwres/man/lwres_context.html +++ b/dist/bind/lib/lwres/man/lwres_context.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_context.html,v 1.5.2.2.2.2 2004/03/08 09:05:12 marka Exp --> +<!-- Id: lwres_context.html,v 1.5.2.2.2.3 2004/08/22 23:39:03 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_context</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_context</A -></H1 +></A +>lwres_context</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN17" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN18" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/lwres.h></PRE @@ -130,9 +130,9 @@ NAME="AEN60" ><H2 >DESCRIPTION</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_context_create()</TT +>lwres_context_create()</CODE > creates a <SPAN @@ -148,11 +148,9 @@ CLASS="TYPE" >lwres_context_t</SPAN > is returned through -<TT +<VAR CLASS="PARAMETER" -><I ->contextp</I -></TT +>contextp</VAR >, a pointer to a @@ -174,33 +172,25 @@ CLASS="TYPE" ><P >When the lightweight resolver needs to perform dynamic memory allocation, it will call -<TT +<VAR CLASS="PARAMETER" -><I ->malloc_function</I -></TT +>malloc_function</VAR > to allocate memory and -<TT +<VAR CLASS="PARAMETER" -><I ->free_function</I -></TT +>free_function</VAR > to free it. If -<TT +<VAR CLASS="PARAMETER" -><I ->malloc_function</I -></TT +>malloc_function</VAR > and -<TT +<VAR CLASS="PARAMETER" -><I ->free_function</I -></TT +>free_function</VAR > are NULL, memory is allocated using @@ -215,48 +205,36 @@ CLASS="REFENTRYTITLE" >. It is not permitted to have a NULL -<TT +<VAR CLASS="PARAMETER" -><I ->malloc_function</I -></TT +>malloc_function</VAR > and a non-NULL -<TT +<VAR CLASS="PARAMETER" -><I ->free_function</I -></TT +>free_function</VAR > or vice versa. -<TT +<VAR CLASS="PARAMETER" -><I ->arg</I -></TT +>arg</VAR > is passed as the first parameter to the memory allocation functions. If -<TT +<VAR CLASS="PARAMETER" -><I ->malloc_function</I -></TT +>malloc_function</VAR > and -<TT +<VAR CLASS="PARAMETER" -><I ->free_function</I -></TT +>free_function</VAR > are NULL, -<TT +<VAR CLASS="PARAMETER" -><I ->arg</I -></TT +>arg</VAR > is unused and should be passed as NULL.</P @@ -272,16 +250,14 @@ CLASS="REFENTRYTITLE" > and returned via -<TT +<VAR CLASS="PARAMETER" -><I ->*contextp</I -></TT +>*contextp</VAR >. </P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_context_destroy()</TT +>lwres_context_destroy()</CODE > destroys a <SPAN @@ -290,11 +266,9 @@ CLASS="TYPE" >, closing its socket. -<TT +<VAR CLASS="PARAMETER" -><I ->contextp</I -></TT +>contextp</VAR > is a pointer to a pointer to the context that is to be destroyed. The pointer will be set to NULL when the context has been destroyed.</P @@ -302,124 +276,106 @@ The pointer will be set to NULL when the context has been destroyed.</P >The context holds a serial number that is used to identify resolver request packets and associate responses with the corresponding requests. This serial number is controlled using -<TT +<CODE CLASS="FUNCTION" ->lwres_context_initserial()</TT +>lwres_context_initserial()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_context_nextserial()</TT +>lwres_context_nextserial()</CODE >. -<TT +<CODE CLASS="FUNCTION" ->lwres_context_initserial()</TT +>lwres_context_initserial()</CODE > sets the serial number for context -<TT +<VAR CLASS="PARAMETER" -><I ->*ctx</I -></TT +>*ctx</VAR > to -<TT +<VAR CLASS="PARAMETER" -><I ->serial</I -></TT +>serial</VAR >. -<TT +<CODE CLASS="FUNCTION" ->lwres_context_nextserial()</TT +>lwres_context_nextserial()</CODE > increments the serial number and returns the previous value.</P ><P >Memory for a lightweight resolver context is allocated and freed using -<TT +<CODE CLASS="FUNCTION" ->lwres_context_allocmem()</TT +>lwres_context_allocmem()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_context_freemem()</TT +>lwres_context_freemem()</CODE >. These use whatever allocations were defined when the context was created with -<TT +<CODE CLASS="FUNCTION" ->lwres_context_create()</TT +>lwres_context_create()</CODE >. -<TT +<CODE CLASS="FUNCTION" ->lwres_context_allocmem()</TT +>lwres_context_allocmem()</CODE > allocates -<TT +<VAR CLASS="PARAMETER" -><I ->len</I -></TT +>len</VAR > bytes of memory and if successful returns a pointer to the allocated storage. -<TT +<CODE CLASS="FUNCTION" ->lwres_context_freemem()</TT +>lwres_context_freemem()</CODE > frees -<TT +<VAR CLASS="PARAMETER" -><I ->len</I -></TT +>len</VAR > bytes of space starting at location -<TT +<VAR CLASS="PARAMETER" -><I ->mem</I -></TT +>mem</VAR >. </P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_context_sendrecv()</TT +>lwres_context_sendrecv()</CODE > performs I/O for the context -<TT +<VAR CLASS="PARAMETER" -><I ->ctx</I -></TT +>ctx</VAR >. Data are read and written from the context's socket. It writes data from -<TT +<VAR CLASS="PARAMETER" -><I ->sendbase</I -></TT +>sendbase</VAR > — typically a lightweight resolver query packet — and waits for a reply which is copied to the receive buffer at -<TT +<VAR CLASS="PARAMETER" -><I ->recvbase</I -></TT +>recvbase</VAR >. The number of bytes that were written to this receive buffer is returned in -<TT +<VAR CLASS="PARAMETER" -><I ->*recvd_len</I -></TT +>*recvd_len</VAR >. </P ></DIV ><DIV @@ -430,9 +386,9 @@ NAME="AEN115" ><H2 >RETURN VALUES</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_context_create()</TT +>lwres_context_create()</CODE > returns <SPAN @@ -452,9 +408,9 @@ CLASS="ERRORCODE" otherwise.</P ><P >Successful calls to the memory allocator -<TT +<CODE CLASS="FUNCTION" ->lwres_context_allocmem()</TT +>lwres_context_allocmem()</CODE > return a pointer to the start of the allocated space. It returns NULL if memory could not be allocated.</P @@ -464,9 +420,9 @@ CLASS="ERRORCODE" >LWRES_R_SUCCESS</SPAN > is returned when -<TT +<CODE CLASS="FUNCTION" ->lwres_context_sendrecv()</TT +>lwres_context_sendrecv()</CODE > completes successfully. <SPAN @@ -479,9 +435,9 @@ CLASS="ERRORCODE" >LWRES_R_TIMEOUT</SPAN > is returned if -<TT +<CODE CLASS="FUNCTION" ->lwres_context_sendrecv()</TT +>lwres_context_sendrecv()</CODE > times out waiting for a response.</P ></DIV diff --git a/dist/bind/lib/lwres/man/lwres_gabn.html b/dist/bind/lib/lwres/man/lwres_gabn.html index 8d3d7b39940..fed9a252744 100644 --- a/dist/bind/lib/lwres/man/lwres_gabn.html +++ b/dist/bind/lib/lwres/man/lwres_gabn.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_gabn.html,v 1.6.2.1.4.1 2004/03/06 08:15:38 marka Exp --> +<!-- Id: lwres_gabn.html,v 1.6.2.1.4.2 2004/08/22 23:39:03 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_gabn</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_gabn</A -></H1 +></A +>lwres_gabn</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN16" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN17" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/lwres.h></PRE @@ -178,52 +178,42 @@ typedef struct { } lwres_gabnresponse_t;</PRE ></P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_gabnrequest_render()</TT +>lwres_gabnrequest_render()</CODE > uses resolver context -<TT +<VAR CLASS="PARAMETER" -><I ->ctx</I -></TT +>ctx</VAR > to convert getaddrbyname request structure -<TT +<VAR CLASS="PARAMETER" -><I ->req</I -></TT +>req</VAR > to canonical format. The packet header structure -<TT +<VAR CLASS="PARAMETER" -><I ->pkt</I -></TT +>pkt</VAR > is initialised and transferred to buffer -<TT +<VAR CLASS="PARAMETER" -><I ->b</I -></TT +>b</VAR >. The contents of -<TT +<VAR CLASS="PARAMETER" -><I ->*req</I -></TT +>*req</VAR > are then appended to the buffer in canonical format. -<TT +<CODE CLASS="FUNCTION" ->lwres_gabnresponse_render()</TT +>lwres_gabnresponse_render()</CODE > performs the same task, except it converts a getaddrbyname response structure <SPAN @@ -232,23 +222,19 @@ CLASS="TYPE" > to the lightweight resolver's canonical format.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_gabnrequest_parse()</TT +>lwres_gabnrequest_parse()</CODE > uses context -<TT +<VAR CLASS="PARAMETER" -><I ->ctx</I -></TT +>ctx</VAR > to convert the contents of packet -<TT +<VAR CLASS="PARAMETER" -><I ->pkt</I -></TT +>pkt</VAR > to a <SPAN @@ -257,11 +243,9 @@ CLASS="TYPE" > structure. Buffer -<TT +<VAR CLASS="PARAMETER" -><I ->b</I -></TT +>b</VAR > provides space to be used for storing this structure. When the function succeeds, the resulting @@ -270,21 +254,19 @@ CLASS="TYPE" >lwres_gabnrequest_t</SPAN > is made available through -<TT +<VAR CLASS="PARAMETER" -><I ->*structp</I -></TT +>*structp</VAR >. -<TT +<CODE CLASS="FUNCTION" ->lwres_gabnresponse_parse()</TT +>lwres_gabnresponse_parse()</CODE > offers the same semantics as -<TT +<CODE CLASS="FUNCTION" ->lwres_gabnrequest_parse()</TT +>lwres_gabnrequest_parse()</CODE > except it yields a <SPAN @@ -293,21 +275,19 @@ CLASS="TYPE" > structure.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_gabnresponse_free()</TT +>lwres_gabnresponse_free()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_gabnrequest_free()</TT +>lwres_gabnrequest_free()</CODE > release the memory in resolver context -<TT +<VAR CLASS="PARAMETER" -><I ->ctx</I -></TT +>ctx</VAR > that was allocated to the <SPAN @@ -320,11 +300,9 @@ CLASS="TYPE" >lwres_gabnrequest_t</SPAN > structures referenced via -<TT +<VAR CLASS="PARAMETER" -><I ->structp</I -></TT +>structp</VAR >. Any memory associated with ancillary buffers and strings for those @@ -339,22 +317,22 @@ NAME="AEN93" >RETURN VALUES</H2 ><P >The getaddrbyname opcode functions -<TT +<CODE CLASS="FUNCTION" ->lwres_gabnrequest_render()</TT +>lwres_gabnrequest_render()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->lwres_gabnresponse_render()</TT +>lwres_gabnresponse_render()</CODE > -<TT +<CODE CLASS="FUNCTION" ->lwres_gabnrequest_parse()</TT +>lwres_gabnrequest_parse()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_gabnresponse_parse()</TT +>lwres_gabnresponse_parse()</CODE > all return <SPAN @@ -373,11 +351,9 @@ CLASS="ERRORCODE" >LWRES_R_UNEXPECTEDEND</SPAN > is returned if the available space in the buffer -<TT +<VAR CLASS="PARAMETER" -><I ->b</I -></TT +>b</VAR > is too small to accommodate the packet header or the <SPAN @@ -390,14 +366,14 @@ CLASS="TYPE" >lwres_gabnresponse_t</SPAN > structures. -<TT +<CODE CLASS="FUNCTION" ->lwres_gabnrequest_parse()</TT +>lwres_gabnrequest_parse()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_gabnresponse_parse()</TT +>lwres_gabnresponse_parse()</CODE > will return <SPAN @@ -411,11 +387,9 @@ CLASS="ERRORCODE" >LWRES_R_FAILURE</SPAN > if -<TT +<CODE CLASS="STRUCTFIELD" -><I ->pktflags</I -></TT +>pktflags</CODE > in the packet header structure <SPAN diff --git a/dist/bind/lib/lwres/man/lwres_gai_strerror.html b/dist/bind/lib/lwres/man/lwres_gai_strerror.html index 6e596d67c7f..1031acda23d 100644 --- a/dist/bind/lib/lwres/man/lwres_gai_strerror.html +++ b/dist/bind/lib/lwres/man/lwres_gai_strerror.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_gai_strerror.html,v 1.5.2.1.4.1 2004/03/06 08:15:39 marka Exp --> +<!-- Id: lwres_gai_strerror.html,v 1.5.2.1.4.2 2004/08/22 23:39:03 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_gai_strerror</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_gai_strerror</A -></H1 +></A +>lwres_gai_strerror</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN11" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN12" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/netdb.h></PRE @@ -82,14 +82,14 @@ NAME="AEN18" ><H2 >DESCRIPTION</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_gai_strerror()</TT +>lwres_gai_strerror()</CODE > returns an error message corresponding to an error code returned by -<TT +<CODE CLASS="FUNCTION" ->getaddrinfo()</TT +>getaddrinfo()</CODE >. The following error codes and their meaning are defined in <TT @@ -127,9 +127,9 @@ CLASS="ERRORCODE" ><DD ><P >invalid value for -<TT +<CODE CLASS="CONSTANT" ->ai_flags</TT +>ai_flags</CODE ></P ></DD ><DT @@ -148,9 +148,9 @@ CLASS="ERRORCODE" ></DT ><DD ><P -><TT +><CODE CLASS="CONSTANT" ->ai_family</TT +>ai_family</CODE > not supported</P ></DD ><DT @@ -187,9 +187,9 @@ CLASS="ERRORCODE" ></DT ><DD ><P ->servname not supported for <TT +>servname not supported for <CODE CLASS="CONSTANT" ->ai_socktype</TT +>ai_socktype</CODE ></P ></DD ><DT @@ -199,9 +199,9 @@ CLASS="ERRORCODE" ></DT ><DD ><P -><TT +><CODE CLASS="CONSTANT" ->ai_socktype</TT +>ai_socktype</CODE > not supported</P ></DD ><DT @@ -220,26 +220,24 @@ The message <SPAN CLASS="ERRORNAME" >invalid error code</SPAN > is returned if -<TT +<VAR CLASS="PARAMETER" -><I ->ecode</I -></TT +>ecode</VAR > is out of range.</P ><P -><TT +><CODE CLASS="CONSTANT" ->ai_flags</TT +>ai_flags</CODE >, -<TT +<CODE CLASS="CONSTANT" ->ai_family</TT +>ai_family</CODE > and -<TT +<CODE CLASS="CONSTANT" ->ai_socktype</TT +>ai_socktype</CODE > are elements of the <SPAN @@ -247,9 +245,9 @@ CLASS="TYPE" >struct addrinfo</SPAN > used by -<TT +<CODE CLASS="FUNCTION" ->lwres_getaddrinfo()</TT +>lwres_getaddrinfo()</CODE >.</P ></DIV ><DIV diff --git a/dist/bind/lib/lwres/man/lwres_getaddrinfo.html b/dist/bind/lib/lwres/man/lwres_getaddrinfo.html index 933d0e8ab83..1ffe1ccd5bd 100644 --- a/dist/bind/lib/lwres/man/lwres_getaddrinfo.html +++ b/dist/bind/lib/lwres/man/lwres_getaddrinfo.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_getaddrinfo.html,v 1.8.2.1.4.2 2004/03/06 08:15:39 marka Exp --> +<!-- Id: lwres_getaddrinfo.html,v 1.8.2.1.4.3 2004/08/22 23:39:03 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_getaddrinfo</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_getaddrinfo</A -></H1 +></A +>lwres_getaddrinfo</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN12" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN13" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/netdb.h></PRE @@ -111,43 +111,35 @@ NAME="AEN29" ><H2 >DESCRIPTION</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_getaddrinfo()</TT +>lwres_getaddrinfo()</CODE > is used to get a list of IP addresses and port numbers for host -<TT +<VAR CLASS="PARAMETER" -><I ->hostname</I -></TT +>hostname</VAR > and service -<TT +<VAR CLASS="PARAMETER" -><I ->servname</I -></TT +>servname</VAR >. The function is the lightweight resolver's implementation of -<TT +<CODE CLASS="FUNCTION" ->getaddrinfo()</TT +>getaddrinfo()</CODE > as defined in RFC2133. -<TT +<VAR CLASS="PARAMETER" -><I ->hostname</I -></TT +>hostname</VAR > and -<TT +<VAR CLASS="PARAMETER" -><I ->servname</I -></TT +>servname</VAR > are pointers to null-terminated strings or @@ -156,19 +148,15 @@ CLASS="TYPE" >NULL</SPAN >. -<TT +<VAR CLASS="PARAMETER" -><I ->hostname</I -></TT +>hostname</VAR > is either a host name or a numeric host address string: a dotted decimal IPv4 address or an IPv6 address. -<TT +<VAR CLASS="PARAMETER" -><I ->servname</I -></TT +>servname</VAR > is either a decimal port number or a service name as listed in <TT @@ -176,11 +164,9 @@ CLASS="FILENAME" >/etc/services</TT >.</P ><P -><TT +><VAR CLASS="PARAMETER" -><I ->hints</I -></TT +>hints</VAR > is an optional pointer to a <SPAN @@ -190,11 +176,9 @@ CLASS="TYPE" This structure can be used to provide hints concerning the type of socket that the caller supports or wishes to use. The caller can supply the following structure elements in -<TT +<VAR CLASS="PARAMETER" -><I ->*hints</I -></TT +>*hints</VAR >: <P @@ -203,17 +187,17 @@ CLASS="PARAMETER" CLASS="VARIABLELIST" ><DL ><DT -><TT +><CODE CLASS="CONSTANT" ->ai_family</TT +>ai_family</CODE ></DT ><DD ><P >The protocol family that should be used. When -<TT +<CODE CLASS="CONSTANT" ->ai_family</TT +>ai_family</CODE > is set to <SPAN @@ -224,9 +208,9 @@ it means the caller will accept any protocol family supported by the operating system.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->ai_socktype</TT +>ai_socktype</CODE ></DT ><DD ><P @@ -246,32 +230,32 @@ CLASS="TYPE" > — that is wanted. When -<TT +<CODE CLASS="CONSTANT" ->ai_socktype</TT +>ai_socktype</CODE > is zero the caller will accept any socket type.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->ai_protocol</TT +>ai_protocol</CODE ></DT ><DD ><P >indicates which transport protocol is wanted: IPPROTO_UDP or IPPROTO_TCP. If -<TT +<CODE CLASS="CONSTANT" ->ai_protocol</TT +>ai_protocol</CODE > is zero the caller will accept any protocol.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->ai_flags</TT +>ai_flags</CODE ></DT ><DD ><P @@ -282,15 +266,15 @@ CLASS="TYPE" >AI_CANONNAME</SPAN > bit is set, a successful call to -<TT +<CODE CLASS="FUNCTION" ->lwres_getaddrinfo()</TT +>lwres_getaddrinfo()</CODE > will return a null-terminated string containing the canonical name of the specified hostname in -<TT +<CODE CLASS="CONSTANT" ->ai_canonname</TT +>ai_canonname</CODE > of the first <SPAN @@ -332,9 +316,9 @@ CLASS="TYPE" for an IPv6 address.</P ><P >When -<TT +<CODE CLASS="CONSTANT" ->ai_flags</TT +>ai_flags</CODE > does not set the <SPAN @@ -378,11 +362,9 @@ CLASS="REFENTRYTITLE" if a connectionless protocol was chosen. The IP address portion of the socket address structure will be set to the loopback address if -<TT +<VAR CLASS="PARAMETER" -><I ->hostname</I -></TT +>hostname</VAR > is a <SPAN @@ -395,15 +377,15 @@ CLASS="TYPE" >AI_PASSIVE</SPAN > is not set in -<TT +<CODE CLASS="CONSTANT" ->ai_flags</TT +>ai_flags</CODE >.</P ><P >If -<TT +<CODE CLASS="CONSTANT" ->ai_flags</TT +>ai_flags</CODE > is set to <SPAN @@ -411,11 +393,9 @@ CLASS="TYPE" >AI_NUMERICHOST</SPAN > it indicates that -<TT +<VAR CLASS="PARAMETER" -><I ->hostname</I -></TT +>hostname</VAR > should be treated as a numeric string defining an IPv4 or IPv6 address and no name resolution should be attempted.</P @@ -428,18 +408,14 @@ and no name resolution should be attempted.</P CLASS="TYPE" >struct addrinfo</SPAN > passed -via <TT +via <VAR CLASS="PARAMETER" -><I ->hints</I -></TT +>hints</VAR > must be zero.</P ><P ->A <TT +>A <VAR CLASS="PARAMETER" -><I ->hints</I -></TT +>hints</VAR > of <SPAN CLASS="TYPE" >NULL</SPAN @@ -448,25 +424,23 @@ the caller provided a <SPAN CLASS="TYPE" >struct addrinfo</SPAN > initialized to zero -with <TT +with <CODE CLASS="CONSTANT" ->ai_family</TT +>ai_family</CODE >set to -<TT +<CODE CLASS="CONSTANT" ->PF_UNSPEC</TT +>PF_UNSPEC</CODE >.</P ><P >After a successful call to -<TT +<CODE CLASS="FUNCTION" ->lwres_getaddrinfo()</TT +>lwres_getaddrinfo()</CODE >, -<TT +<VAR CLASS="PARAMETER" -><I ->*res</I -></TT +>*res</VAR > is a pointer to a linked list of one or more <SPAN @@ -481,9 +455,9 @@ CLASS="TYPE" > in this list cn be processed by following the -<TT +<CODE CLASS="CONSTANT" ->ai_next</TT +>ai_next</CODE > pointer, until a <SPAN @@ -492,18 +466,18 @@ CLASS="TYPE" > pointer is encountered. The three members -<TT +<CODE CLASS="CONSTANT" ->ai_family</TT +>ai_family</CODE >, -<TT +<CODE CLASS="CONSTANT" ->ai_socktype</TT +>ai_socktype</CODE >, and -<TT +<CODE CLASS="CONSTANT" ->ai_protocol</TT +>ai_protocol</CODE > in each returned @@ -525,43 +499,41 @@ CLASS="TYPE" >addrinfo</SPAN > structure in the list, the -<TT +<CODE CLASS="CONSTANT" ->ai_addr</TT +>ai_addr</CODE > member points to a filled-in socket address structure of length -<TT +<CODE CLASS="CONSTANT" ->ai_addrlen</TT +>ai_addrlen</CODE >.</P ><P >All of the information returned by -<TT +<CODE CLASS="FUNCTION" ->lwres_getaddrinfo()</TT +>lwres_getaddrinfo()</CODE > is dynamically allocated: the addrinfo structures, and the socket address structures and canonical host name strings pointed to by the -<TT +<CODE CLASS="CONSTANT" ->addrinfo</TT +>addrinfo</CODE >structures. Memory allocated for the dynamically allocated structures created by a successful call to -<TT +<CODE CLASS="FUNCTION" ->lwres_getaddrinfo()</TT +>lwres_getaddrinfo()</CODE > is released by -<TT +<CODE CLASS="FUNCTION" ->lwres_freeaddrinfo()</TT +>lwres_freeaddrinfo()</CODE >. -<TT +<VAR CLASS="PARAMETER" -><I ->ai</I -></TT +>ai</VAR > is a pointer to a <SPAN @@ -569,9 +541,9 @@ CLASS="TYPE" >struct addrinfo</SPAN > created by a call to -<TT +<CODE CLASS="FUNCTION" ->lwres_getaddrinfo()</TT +>lwres_getaddrinfo()</CODE >.</P ></DIV ><DIV @@ -582,9 +554,9 @@ NAME="AEN142" ><H2 >RETURN VALUES</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_getaddrinfo()</TT +>lwres_getaddrinfo()</CODE > returns zero on success or one of the error codes listed in <SPAN @@ -596,27 +568,23 @@ CLASS="REFENTRYTITLE" > if an error occurs. If both -<TT +<VAR CLASS="PARAMETER" -><I ->hostname</I -></TT +>hostname</VAR > and -<TT +<VAR CLASS="PARAMETER" -><I ->servname</I -></TT +>servname</VAR > are <SPAN CLASS="TYPE" >NULL</SPAN > -<TT +<CODE CLASS="FUNCTION" ->lwres_getaddrinfo()</TT +>lwres_getaddrinfo()</CODE > returns <SPAN diff --git a/dist/bind/lib/lwres/man/lwres_gethostent.html b/dist/bind/lib/lwres/man/lwres_gethostent.html index c7cdaa87cca..22b68bd58ab 100644 --- a/dist/bind/lib/lwres/man/lwres_gethostent.html +++ b/dist/bind/lib/lwres/man/lwres_gethostent.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_gethostent.html,v 1.8.2.1.4.1 2004/03/06 08:15:39 marka Exp --> +<!-- Id: lwres_gethostent.html,v 1.8.2.1.4.2 2004/08/22 23:39:04 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_gethostent</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_gethostent</A -></H1 +></A +>lwres_gethostent</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN21" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN22" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/netdb.h></PRE @@ -203,27 +203,27 @@ CLASS="PROGRAMLISTING" CLASS="VARIABLELIST" ><DL ><DT -><TT +><CODE CLASS="CONSTANT" ->h_name</TT +>h_name</CODE ></DT ><DD ><P >The official (canonical) name of the host.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->h_aliases</TT +>h_aliases</CODE ></DT ><DD ><P >A NULL-terminated array of alternate names (nicknames) for the host.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->h_addrtype</TT +>h_addrtype</CODE ></DT ><DD ><P @@ -239,18 +239,18 @@ CLASS="TYPE" >.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->h_length</TT +>h_length</CODE ></DT ><DD ><P >The length of the address in bytes.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->h_addr_list</TT +>h_addr_list</CODE ></DT ><DD ><P @@ -266,40 +266,40 @@ Host addresses are returned in network byte order.</P ></P ><P >For backward compatibility with very old software, -<TT +<CODE CLASS="CONSTANT" ->h_addr</TT +>h_addr</CODE > is the first address in -<TT +<CODE CLASS="CONSTANT" ->h_addr_list.</TT +>h_addr_list.</CODE ></P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_gethostent()</TT +>lwres_gethostent()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->lwres_sethostent()</TT +>lwres_sethostent()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->lwres_endhostent()</TT +>lwres_endhostent()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostent_r()</TT +>lwres_gethostent_r()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->lwres_sethostent_r()</TT +>lwres_sethostent_r()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_endhostent_r()</TT +>lwres_endhostent_r()</CODE > provide iteration over the known host entries on systems that provide such functionality through facilities like @@ -311,33 +311,29 @@ or NIS. The lightweight resolver does not currently implement these functions; it only provides them as stub functions that always return failure.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_gethostbyname()</TT +>lwres_gethostbyname()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyname2()</TT +>lwres_gethostbyname2()</CODE > look up the hostname -<TT +<VAR CLASS="PARAMETER" -><I ->name</I -></TT +>name</VAR >. -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyname()</TT +>lwres_gethostbyname()</CODE > always looks for an IPv4 -address while <TT +address while <CODE CLASS="FUNCTION" ->lwres_gethostbyname2()</TT +>lwres_gethostbyname2()</CODE > looks for an -address of protocol family <TT +address of protocol family <VAR CLASS="PARAMETER" -><I ->af</I -></TT +>af</VAR >: either <SPAN CLASS="TYPE" @@ -355,37 +351,31 @@ CLASS="TYPE" CLASS="TYPE" >NULL</SPAN > is returned if the lookups by -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyname()</TT +>lwres_gethostbyname()</CODE > or -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyname2()</TT +>lwres_gethostbyname2()</CODE > fail.</P ><P >Reverse lookups of addresses are performed by -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyaddr()</TT +>lwres_gethostbyaddr()</CODE >. -<TT +<VAR CLASS="PARAMETER" -><I ->addr</I -></TT +>addr</VAR > is an address of length -<TT +<VAR CLASS="PARAMETER" -><I ->len</I -></TT +>len</VAR > bytes and protocol family -<TT +<VAR CLASS="PARAMETER" -><I ->type</I -></TT +>type</VAR > — <SPAN CLASS="TYPE" >PF_INET</SPAN @@ -394,99 +384,81 @@ CLASS="TYPE" CLASS="TYPE" >PF_INET6</SPAN >. -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyname_r()</TT +>lwres_gethostbyname_r()</CODE > is a thread-safe function for forward lookups. If an error occurs, an error code is returned in -<TT +<VAR CLASS="PARAMETER" -><I ->*error</I -></TT +>*error</VAR >. -<TT +<VAR CLASS="PARAMETER" -><I ->resbuf</I -></TT +>resbuf</VAR > is a pointer to a <SPAN CLASS="TYPE" >struct hostent</SPAN > which is initialised by a successful call to -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyname_r()</TT +>lwres_gethostbyname_r()</CODE > . -<TT +<VAR CLASS="PARAMETER" -><I ->buf</I -></TT +>buf</VAR > is a buffer of length -<TT +<VAR CLASS="PARAMETER" -><I ->len</I -></TT +>len</VAR > bytes which is used to store the -<TT +<CODE CLASS="CONSTANT" ->h_name</TT ->, <TT +>h_name</CODE +>, <CODE CLASS="CONSTANT" ->h_aliases</TT +>h_aliases</CODE >, and -<TT +<CODE CLASS="CONSTANT" ->h_addr_list</TT +>h_addr_list</CODE > elements of the <SPAN CLASS="TYPE" >struct hostent</SPAN -> returned in <TT +> returned in <VAR CLASS="PARAMETER" -><I ->resbuf</I -></TT +>resbuf</VAR >. -Successful calls to <TT +Successful calls to <CODE CLASS="FUNCTION" ->lwres_gethostbyname_r()</TT +>lwres_gethostbyname_r()</CODE > -return <TT +return <VAR CLASS="PARAMETER" -><I ->resbuf</I -></TT +>resbuf</VAR >, which is a pointer to the <SPAN CLASS="TYPE" >struct hostent</SPAN > it created.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_gethostbyaddr_r()</TT +>lwres_gethostbyaddr_r()</CODE > is a thread-safe function -that performs a reverse lookup of address <TT +that performs a reverse lookup of address <VAR CLASS="PARAMETER" -><I ->addr</I -></TT +>addr</VAR > -which is <TT +which is <VAR CLASS="PARAMETER" -><I ->len</I -></TT +>len</VAR > bytes long and is of protocol -family <TT +family <VAR CLASS="PARAMETER" -><I ->type</I -></TT +>type</VAR > — <SPAN CLASS="TYPE" >PF_INET</SPAN @@ -495,75 +467,63 @@ CLASS="TYPE" CLASS="TYPE" >PF_INET6</SPAN >. If an error occurs, the error code is returned -in <TT +in <VAR CLASS="PARAMETER" -><I ->*error</I -></TT +>*error</VAR >. The other function parameters are -identical to those in <TT +identical to those in <CODE CLASS="FUNCTION" ->lwres_gethostbyname_r()</TT +>lwres_gethostbyname_r()</CODE >. -<TT +<VAR CLASS="PARAMETER" -><I ->resbuf</I -></TT +>resbuf</VAR > is a pointer to a <SPAN CLASS="TYPE" >struct hostent</SPAN > which is initialised by a successful call to -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyaddr_r()</TT +>lwres_gethostbyaddr_r()</CODE >. -<TT +<VAR CLASS="PARAMETER" -><I ->buf</I -></TT +>buf</VAR > is a buffer of length -<TT +<VAR CLASS="PARAMETER" -><I ->len</I -></TT +>len</VAR > bytes which is used to store the -<TT +<CODE CLASS="CONSTANT" ->h_name</TT ->, <TT +>h_name</CODE +>, <CODE CLASS="CONSTANT" ->h_aliases</TT +>h_aliases</CODE >, and -<TT +<CODE CLASS="CONSTANT" ->h_addr_list</TT +>h_addr_list</CODE > elements of the <SPAN CLASS="TYPE" >struct hostent</SPAN -> returned in <TT +> returned in <VAR CLASS="PARAMETER" -><I ->resbuf</I -></TT +>resbuf</VAR >. Successful -calls to <TT +calls to <CODE CLASS="FUNCTION" ->lwres_gethostbyaddr_r()</TT +>lwres_gethostbyaddr_r()</CODE > return -<TT +<VAR CLASS="PARAMETER" -><I ->resbuf</I -></TT +>resbuf</VAR >, which is a pointer to the -<TT +<CODE CLASS="FUNCTION" ->struct hostent()</TT +>struct hostent()</CODE > it created.</P ></DIV ><DIV @@ -575,22 +535,22 @@ NAME="AEN191" >RETURN VALUES</H2 ><P >The functions -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyname()</TT +>lwres_gethostbyname()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyname2()</TT +>lwres_gethostbyname2()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyaddr()</TT +>lwres_gethostbyaddr()</CODE >, and -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostent()</TT +>lwres_gethostent()</CODE > return NULL to indicate an error. In this case the global variable <SPAN @@ -609,18 +569,18 @@ CLASS="FILENAME" CLASS="VARIABLELIST" ><DL ><DT -><TT +><CODE CLASS="CONSTANT" ->HOST_NOT_FOUND</TT +>HOST_NOT_FOUND</CODE ></DT ><DD ><P >The host or address was not found.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->TRY_AGAIN</TT +>TRY_AGAIN</CODE ></DT ><DD ><P @@ -628,18 +588,18 @@ CLASS="CONSTANT" Retrying the lookup may succeed.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->NO_RECOVERY</TT +>NO_RECOVERY</CODE ></DT ><DD ><P >A non-recoverable error occurred.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->NO_DATA</TT +>NO_DATA</CODE ></DT ><DD ><P @@ -662,14 +622,14 @@ CLASS="REFENTRYTITLE" > translates these error codes to suitable error messages.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_gethostent()</TT +>lwres_gethostent()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostent_r()</TT +>lwres_gethostent_r()</CODE > always return <SPAN @@ -677,19 +637,17 @@ CLASS="TYPE" >NULL</SPAN >.</P ><P ->Successful calls to <TT +>Successful calls to <CODE CLASS="FUNCTION" ->lwres_gethostbyname_r()</TT +>lwres_gethostbyname_r()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyaddr_r()</TT +>lwres_gethostbyaddr_r()</CODE > return -<TT +<VAR CLASS="PARAMETER" -><I ->resbuf</I -></TT +>resbuf</VAR >, a pointer to the <SPAN CLASS="TYPE" >struct @@ -698,40 +656,36 @@ hostent</SPAN <SPAN CLASS="TYPE" >NULL</SPAN -> if the lookups fail or if <TT +> if the lookups fail or if <VAR CLASS="PARAMETER" -><I ->buf</I -></TT +>buf</VAR > was too small to hold the list of addresses and names referenced by -the <TT +the <CODE CLASS="CONSTANT" ->h_name</TT ->, <TT +>h_name</CODE +>, <CODE CLASS="CONSTANT" ->h_aliases</TT +>h_aliases</CODE >, and -<TT +<CODE CLASS="CONSTANT" ->h_addr_list</TT +>h_addr_list</CODE > elements of the <SPAN CLASS="TYPE" >struct hostent</SPAN ->. If <TT +>. If <VAR CLASS="PARAMETER" -><I ->buf</I -></TT +>buf</VAR > was too small, both -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyname_r()</TT +>lwres_gethostbyname_r()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyaddr_r()</TT +>lwres_gethostbyaddr_r()</CODE > set the global variable <SPAN CLASS="TYPE" @@ -781,34 +735,34 @@ NAME="AEN257" ><H2 >BUGS</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_gethostbyname()</TT +>lwres_gethostbyname()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyname2()</TT +>lwres_gethostbyname2()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyaddr()</TT +>lwres_gethostbyaddr()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_endhostent()</TT +>lwres_endhostent()</CODE > are not thread safe; they return pointers to static data and provide error codes through a global variable. Thread-safe versions for name and address lookup are provided by -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyname_r()</TT +>lwres_gethostbyname_r()</CODE >, and -<TT +<CODE CLASS="FUNCTION" ->lwres_gethostbyaddr_r()</TT +>lwres_gethostbyaddr_r()</CODE > respectively.</P ><P diff --git a/dist/bind/lib/lwres/man/lwres_getipnode.html b/dist/bind/lib/lwres/man/lwres_getipnode.html index 044f1b27cba..4cf87bc6c41 100644 --- a/dist/bind/lib/lwres/man/lwres_getipnode.html +++ b/dist/bind/lib/lwres/man/lwres_getipnode.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_getipnode.html,v 1.7.2.1.4.1 2004/03/06 08:15:40 marka Exp --> +<!-- Id: lwres_getipnode.html,v 1.7.2.1.4.2 2004/08/22 23:39:04 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_getipnode</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_getipnode</A -></H1 +></A +>lwres_getipnode</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN13" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN14" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/netdb.h></PRE @@ -131,27 +131,27 @@ CLASS="PROGRAMLISTING" CLASS="VARIABLELIST" ><DL ><DT -><TT +><CODE CLASS="CONSTANT" ->h_name</TT +>h_name</CODE ></DT ><DD ><P >The official (canonical) name of the host.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->h_aliases</TT +>h_aliases</CODE ></DT ><DD ><P >A NULL-terminated array of alternate names (nicknames) for the host.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->h_addrtype</TT +>h_addrtype</CODE ></DT ><DD ><P @@ -167,18 +167,18 @@ CLASS="TYPE" >. </P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->h_length</TT +>h_length</CODE ></DT ><DD ><P >The length of the address in bytes.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->h_addr_list</TT +>h_addr_list</CODE ></DT ><DD ><P @@ -194,32 +194,26 @@ Host addresses are returned in network byte order.</P ></DIV ></P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_getipnodebyname()</TT +>lwres_getipnodebyname()</CODE > looks up addresses of protocol family -<TT +<VAR CLASS="PARAMETER" -><I ->af</I -></TT +>af</VAR > for the hostname -<TT +<VAR CLASS="PARAMETER" -><I ->name</I -></TT +>name</VAR >. The -<TT +<VAR CLASS="PARAMETER" -><I ->flags</I -></TT +>flags</VAR > parameter contains ORed flag bits to specify the types of addresses that are searched @@ -231,44 +225,40 @@ The flag bits are: CLASS="VARIABLELIST" ><DL ><DT -><TT +><CODE CLASS="CONSTANT" ->AI_V4MAPPED</TT +>AI_V4MAPPED</CODE ></DT ><DD ><P >This is used with an -<TT +<VAR CLASS="PARAMETER" -><I ->af</I -></TT +>af</VAR > of AF_INET6, and causes IPv4 addresses to be returned as IPv4-mapped IPv6 addresses.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->AI_ALL</TT +>AI_ALL</CODE ></DT ><DD ><P >This is used with an -<TT +<VAR CLASS="PARAMETER" -><I ->af</I -></TT +>af</VAR > of AF_INET6, and causes all known addresses (IPv6 and IPv4) to be returned. If AI_V4MAPPED is also set, the IPv4 addresses are return as mapped IPv6 addresses.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->AI_ADDRCONFIG</TT +>AI_ADDRCONFIG</CODE ></DT ><DD ><P @@ -277,21 +267,21 @@ interface of that type. This is not currently implemented in the BIND 9 lightweight resolver, and the flag is ignored.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->AI_DEFAULT</TT +>AI_DEFAULT</CODE ></DT ><DD ><P >This default sets the -<TT +<CODE CLASS="CONSTANT" ->AI_V4MAPPED</TT +>AI_V4MAPPED</CODE > and -<TT +<CODE CLASS="CONSTANT" ->AI_ADDRCONFIG</TT +>AI_ADDRCONFIG</CODE > flag bits.</P ></DD @@ -299,31 +289,25 @@ flag bits.</P ></DIV ></P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_getipnodebyaddr()</TT +>lwres_getipnodebyaddr()</CODE > performs a reverse lookup of address -<TT +<VAR CLASS="PARAMETER" -><I ->src</I -></TT +>src</VAR > which is -<TT +<VAR CLASS="PARAMETER" -><I ->len</I -></TT +>len</VAR > bytes long. -<TT +<VAR CLASS="PARAMETER" -><I ->af</I -></TT +>af</VAR > denotes the protocol family, typically <SPAN @@ -336,9 +320,9 @@ CLASS="TYPE" >PF_INET6</SPAN >. </P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_freehostent()</TT +>lwres_freehostent()</CODE > releases all the memory associated with the @@ -347,27 +331,25 @@ CLASS="TYPE" >struct hostent</SPAN > pointer -<TT +<VAR CLASS="PARAMETER" -><I ->he</I -></TT +>he</VAR >. Any memory allocated for the -<TT +<CODE CLASS="CONSTANT" ->h_name</TT +>h_name</CODE >, -<TT +<CODE CLASS="CONSTANT" ->h_addr_list</TT +>h_addr_list</CODE > and -<TT +<CODE CLASS="CONSTANT" ->h_aliases</TT +>h_aliases</CODE > is freed, as is the memory for the <SPAN @@ -385,21 +367,19 @@ NAME="AEN116" >RETURN VALUES</H2 ><P >If an error occurs, -<TT +<CODE CLASS="FUNCTION" ->lwres_getipnodebyname()</TT +>lwres_getipnodebyname()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_getipnodebyaddr()</TT +>lwres_getipnodebyaddr()</CODE > set -<TT +<VAR CLASS="PARAMETER" -><I ->*error_num</I -></TT +>*error_num</VAR > to an appropriate error code and the function returns a <SPAN @@ -418,18 +398,18 @@ CLASS="FILENAME" CLASS="VARIABLELIST" ><DL ><DT -><TT +><CODE CLASS="CONSTANT" ->HOST_NOT_FOUND</TT +>HOST_NOT_FOUND</CODE ></DT ><DD ><P >No such host is known.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->NO_ADDRESS</TT +>NO_ADDRESS</CODE ></DT ><DD ><P @@ -438,9 +418,9 @@ available. Another type of request to the name server for the domain might return an answer.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->TRY_AGAIN</TT +>TRY_AGAIN</CODE ></DT ><DD ><P @@ -449,9 +429,9 @@ failure of a server to respond. The request may succeed if retried.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->NO_RECOVERY</TT +>NO_RECOVERY</CODE ></DT ><DD ><P diff --git a/dist/bind/lib/lwres/man/lwres_getnameinfo.html b/dist/bind/lib/lwres/man/lwres_getnameinfo.html index 5ba59923cdd..5bc528fe4c9 100644 --- a/dist/bind/lib/lwres/man/lwres_getnameinfo.html +++ b/dist/bind/lib/lwres/man/lwres_getnameinfo.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_getnameinfo.html,v 1.5.2.1.4.1 2004/03/06 08:15:40 marka Exp --> +<!-- Id: lwres_getnameinfo.html,v 1.5.2.1.4.2 2004/08/22 23:39:04 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_getnameinfo</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_getnameinfo</A -></H1 +></A +>lwres_getnameinfo</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN11" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN12" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/netdb.h></PRE @@ -89,70 +89,54 @@ CLASS="REFENTRYTITLE" >getnameinfo</SPAN >(3)</SPAN > function defined in RFC2133. -<TT +<CODE CLASS="FUNCTION" ->lwres_getnameinfo()</TT +>lwres_getnameinfo()</CODE > returns the hostname for the <SPAN CLASS="TYPE" >struct sockaddr</SPAN -> <TT +> <VAR CLASS="PARAMETER" -><I ->sa</I -></TT +>sa</VAR > which is -<TT +<VAR CLASS="PARAMETER" -><I ->salen</I -></TT +>salen</VAR > bytes long. The hostname is of length -<TT +<VAR CLASS="PARAMETER" -><I ->hostlen</I -></TT +>hostlen</VAR > and is returned via -<TT +<VAR CLASS="PARAMETER" -><I ->*host.</I -></TT +>*host.</VAR > The maximum length of the hostname is -1025 bytes: <TT +1025 bytes: <CODE CLASS="CONSTANT" ->NI_MAXHOST</TT +>NI_MAXHOST</CODE >.</P ><P > The name of the service associated with the port number in -<TT +<VAR CLASS="PARAMETER" -><I ->sa</I -></TT -> is returned in <TT +>sa</VAR +> is returned in <VAR CLASS="PARAMETER" -><I ->*serv.</I -></TT +>*serv.</VAR > -It is <TT +It is <VAR CLASS="PARAMETER" -><I ->servlen</I -></TT +>servlen</VAR > bytes long. The maximum length -of the service name is <TT +of the service name is <CODE CLASS="CONSTANT" ->NI_MAXSERV</TT +>NI_MAXSERV</CODE > - 32 bytes.</P ><P -> The <TT +> The <VAR CLASS="PARAMETER" -><I ->flags</I -></TT +>flags</VAR > argument sets the following bits: <P @@ -161,9 +145,9 @@ bits: CLASS="VARIABLELIST" ><DL ><DT -><TT +><CODE CLASS="CONSTANT" ->NI_NOFQDN</TT +>NI_NOFQDN</CODE ></DT ><DD ><P @@ -171,9 +155,9 @@ CLASS="CONSTANT" The local part of the fully qualified domain name is returned instead.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->NI_NUMERICHOST</TT +>NI_NUMERICHOST</CODE ></DT ><DD ><P @@ -181,9 +165,9 @@ CLASS="CONSTANT" instead of a host name.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->NI_NAMEREQD</TT +>NI_NAMEREQD</CODE ></DT ><DD ><P @@ -193,18 +177,18 @@ If the hostname is not found and the flag is not set, the address is returned in numeric form.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->NI_NUMERICSERV</TT +>NI_NUMERICSERV</CODE ></DT ><DD ><P >The service name is returned as a digit string representing the port number.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->NI_DGRAM</TT +>NI_DGRAM</CODE ></DT ><DD ><P @@ -226,9 +210,9 @@ NAME="AEN70" ><H2 >RETURN VALUES</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_getnameinfo()</TT +>lwres_getnameinfo()</CODE > returns 0 on success or a non-zero error code if an error occurs.</P ></DIV diff --git a/dist/bind/lib/lwres/man/lwres_getrrsetbyname.html b/dist/bind/lib/lwres/man/lwres_getrrsetbyname.html index 1a54243090e..db2b344ef2a 100644 --- a/dist/bind/lib/lwres/man/lwres_getrrsetbyname.html +++ b/dist/bind/lib/lwres/man/lwres_getrrsetbyname.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_getrrsetbyname.html,v 1.5.2.1.4.1 2004/03/06 08:15:40 marka Exp --> +<!-- Id: lwres_getrrsetbyname.html,v 1.5.2.1.4.2 2004/08/22 23:39:04 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_getrrsetbyname</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_getrrsetbyname</A -></H1 +></A +>lwres_getrrsetbyname</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN12" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN13" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/netdb.h></PRE @@ -111,60 +111,48 @@ NAME="AEN29" ><H2 >DESCRIPTION</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_getrrsetbyname()</TT +>lwres_getrrsetbyname()</CODE > gets a set of resource records associated with a -<TT +<VAR CLASS="PARAMETER" -><I ->hostname</I -></TT +>hostname</VAR >, -<TT +<VAR CLASS="PARAMETER" -><I ->class</I -></TT +>class</VAR >, and -<TT +<VAR CLASS="PARAMETER" -><I ->type</I -></TT +>type</VAR >. -<TT +<VAR CLASS="PARAMETER" -><I ->hostname</I -></TT +>hostname</VAR > is a pointer a to null-terminated string. The -<TT +<VAR CLASS="PARAMETER" -><I ->flags</I -></TT +>flags</VAR > field is currently unused and must be zero.</P ><P >After a successful call to -<TT +<CODE CLASS="FUNCTION" ->lwres_getrrsetbyname()</TT +>lwres_getrrsetbyname()</CODE >, -<TT +<VAR CLASS="PARAMETER" -><I ->*res</I -></TT +>*res</VAR > is a pointer to an <SPAN @@ -184,84 +172,82 @@ CLASS="TYPE" structures containing SIG resource records associated with those records. The members -<TT +<CODE CLASS="CONSTANT" ->rri_rdclass</TT +>rri_rdclass</CODE > and -<TT +<CODE CLASS="CONSTANT" ->rri_rdtype</TT +>rri_rdtype</CODE > are copied from the parameters. -<TT +<CODE CLASS="CONSTANT" ->rri_ttl</TT +>rri_ttl</CODE > and -<TT +<CODE CLASS="CONSTANT" ->rri_name</TT +>rri_name</CODE > are properties of the obtained rrset. The resource records contained in -<TT +<CODE CLASS="CONSTANT" ->rri_rdatas</TT +>rri_rdatas</CODE > and -<TT +<CODE CLASS="CONSTANT" ->rri_sigs</TT +>rri_sigs</CODE > are in uncompressed DNS wire format. Properties of the rdataset are represented in the -<TT +<CODE CLASS="CONSTANT" ->rri_flags</TT +>rri_flags</CODE > bitfield. If the RRSET_VALIDATED bit is set, the data has been DNSSEC validated and the signatures verified. </P ><P >All of the information returned by -<TT +<CODE CLASS="FUNCTION" ->lwres_getrrsetbyname()</TT +>lwres_getrrsetbyname()</CODE > is dynamically allocated: the -<TT +<CODE CLASS="CONSTANT" ->rrsetinfo</TT +>rrsetinfo</CODE > and -<TT +<CODE CLASS="CONSTANT" ->rdatainfo</TT +>rdatainfo</CODE > structures, and the canonical host name strings pointed to by the -<TT +<CODE CLASS="CONSTANT" ->rrsetinfo</TT +>rrsetinfo</CODE >structure. Memory allocated for the dynamically allocated structures created by a successful call to -<TT +<CODE CLASS="FUNCTION" ->lwres_getrrsetbyname()</TT +>lwres_getrrsetbyname()</CODE > is released by -<TT +<CODE CLASS="FUNCTION" ->lwres_freerrset()</TT +>lwres_freerrset()</CODE >. -<TT +<VAR CLASS="PARAMETER" -><I ->rrset</I -></TT +>rrset</VAR > is a pointer to a <SPAN @@ -269,9 +255,9 @@ CLASS="TYPE" >struct rrset</SPAN > created by a call to -<TT +<CODE CLASS="FUNCTION" ->lwres_getrrsetbyname()</TT +>lwres_getrrsetbyname()</CODE >. </P ><P ></P @@ -284,9 +270,9 @@ NAME="AEN62" ><H2 >RETURN VALUES</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_getrrsetbyname()</TT +>lwres_getrrsetbyname()</CODE > returns zero on success, and one of the following error codes if an error occurred: @@ -296,54 +282,54 @@ codes if an error occurred: CLASS="VARIABLELIST" ><DL ><DT -><TT +><CODE CLASS="CONSTANT" ->ERRSET_NONAME</TT +>ERRSET_NONAME</CODE ></DT ><DD ><P >the name does not exist</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->ERRSET_NODATA</TT +>ERRSET_NODATA</CODE ></DT ><DD ><P >the name exists, but does not have data of the desired type</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->ERRSET_NOMEMORY</TT +>ERRSET_NOMEMORY</CODE ></DT ><DD ><P >memory could not be allocated</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->ERRSET_INVAL</TT +>ERRSET_INVAL</CODE ></DT ><DD ><P >a parameter is invalid</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->ERRSET_FAIL</TT +>ERRSET_FAIL</CODE ></DT ><DD ><P >other failure</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" -></TT +></CODE ></DT ><DD ><P diff --git a/dist/bind/lib/lwres/man/lwres_gnba.html b/dist/bind/lib/lwres/man/lwres_gnba.html index bd24797ded3..e1f15358578 100644 --- a/dist/bind/lib/lwres/man/lwres_gnba.html +++ b/dist/bind/lib/lwres/man/lwres_gnba.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_gnba.html,v 1.6.2.1.4.1 2004/03/06 08:15:40 marka Exp --> +<!-- Id: lwres_gnba.html,v 1.6.2.1.4.2 2004/08/22 23:39:04 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_gnba</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_gnba</A -></H1 +></A +>lwres_gnba</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN16" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN17" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/lwres.h></PRE @@ -171,41 +171,41 @@ typedef struct { } lwres_gnbaresponse_t;</PRE ></P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_gnbarequest_render()</TT +>lwres_gnbarequest_render()</CODE > uses resolver context -<TT +<VAR CLASS="VARNAME" ->ctx</TT +>ctx</VAR > to convert getnamebyaddr request structure -<TT +<VAR CLASS="VARNAME" ->req</TT +>req</VAR > to canonical format. The packet header structure -<TT +<VAR CLASS="VARNAME" ->pkt</TT +>pkt</VAR > is initialised and transferred to buffer -<TT +<VAR CLASS="VARNAME" ->b</TT +>b</VAR >. The contents of -<TT +<VAR CLASS="VARNAME" ->*req</TT +>*req</VAR > are then appended to the buffer in canonical format. -<TT +<CODE CLASS="FUNCTION" ->lwres_gnbaresponse_render()</TT +>lwres_gnbaresponse_render()</CODE > performs the same task, except it converts a getnamebyaddr response structure <SPAN @@ -214,19 +214,19 @@ CLASS="TYPE" > to the lightweight resolver's canonical format.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_gnbarequest_parse()</TT +>lwres_gnbarequest_parse()</CODE > uses context -<TT +<VAR CLASS="VARNAME" ->ctx</TT +>ctx</VAR > to convert the contents of packet -<TT +<VAR CLASS="VARNAME" ->pkt</TT +>pkt</VAR > to a <SPAN @@ -235,9 +235,9 @@ CLASS="TYPE" > structure. Buffer -<TT +<VAR CLASS="VARNAME" ->b</TT +>b</VAR > provides space to be used for storing this structure. When the function succeeds, the resulting @@ -246,18 +246,18 @@ CLASS="TYPE" >lwres_gnbarequest_t</SPAN > is made available through -<TT +<VAR CLASS="VARNAME" ->*structp</TT +>*structp</VAR >. -<TT +<CODE CLASS="FUNCTION" ->lwres_gnbaresponse_parse()</TT +>lwres_gnbaresponse_parse()</CODE > offers the same semantics as -<TT +<CODE CLASS="FUNCTION" ->lwres_gnbarequest_parse()</TT +>lwres_gnbarequest_parse()</CODE > except it yields a <SPAN @@ -266,19 +266,19 @@ CLASS="TYPE" > structure.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_gnbaresponse_free()</TT +>lwres_gnbaresponse_free()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_gnbarequest_free()</TT +>lwres_gnbarequest_free()</CODE > release the memory in resolver context -<TT +<VAR CLASS="VARNAME" ->ctx</TT +>ctx</VAR > that was allocated to the <SPAN @@ -291,9 +291,9 @@ CLASS="TYPE" >lwres_gnbarequest_t</SPAN > structures referenced via -<TT +<VAR CLASS="VARNAME" ->structp</TT +>structp</VAR >. Any memory associated with ancillary buffers and strings for those structures is also discarded.</P @@ -307,22 +307,22 @@ NAME="AEN97" >RETURN VALUES</H2 ><P >The getnamebyaddr opcode functions -<TT +<CODE CLASS="FUNCTION" ->lwres_gnbarequest_render()</TT +>lwres_gnbarequest_render()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->lwres_gnbaresponse_render()</TT +>lwres_gnbaresponse_render()</CODE > -<TT +<CODE CLASS="FUNCTION" ->lwres_gnbarequest_parse()</TT +>lwres_gnbarequest_parse()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_gnbaresponse_parse()</TT +>lwres_gnbaresponse_parse()</CODE > all return <SPAN @@ -341,9 +341,9 @@ CLASS="ERRORCODE" >LWRES_R_UNEXPECTEDEND</SPAN > is returned if the available space in the buffer -<TT +<VAR CLASS="VARNAME" ->b</TT +>b</VAR > is too small to accommodate the packet header or the <SPAN @@ -356,14 +356,14 @@ CLASS="TYPE" >lwres_gnbaresponse_t</SPAN > structures. -<TT +<CODE CLASS="FUNCTION" ->lwres_gnbarequest_parse()</TT +>lwres_gnbarequest_parse()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_gnbaresponse_parse()</TT +>lwres_gnbaresponse_parse()</CODE > will return <SPAN @@ -377,11 +377,9 @@ CLASS="ERRORCODE" >LWRES_R_FAILURE</SPAN > if -<TT +<CODE CLASS="STRUCTFIELD" -><I ->pktflags</I -></TT +>pktflags</CODE > in the packet header structure <SPAN diff --git a/dist/bind/lib/lwres/man/lwres_hstrerror.html b/dist/bind/lib/lwres/man/lwres_hstrerror.html index 3de9591a566..df3dd3f2561 100644 --- a/dist/bind/lib/lwres/man/lwres_hstrerror.html +++ b/dist/bind/lib/lwres/man/lwres_hstrerror.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_hstrerror.html,v 1.5.2.1.4.1 2004/03/06 08:15:41 marka Exp --> +<!-- Id: lwres_hstrerror.html,v 1.5.2.1.4.2 2004/08/22 23:39:04 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_hstrerror</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_hstrerror</A -></H1 +></A +>lwres_hstrerror</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN12" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN13" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/netdb.h></PRE @@ -90,37 +90,33 @@ NAME="AEN23" ><H2 >DESCRIPTION</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_herror()</TT +>lwres_herror()</CODE > prints the string -<TT +<VAR CLASS="PARAMETER" -><I ->s</I -></TT +>s</VAR > on <SPAN CLASS="TYPE" >stderr</SPAN > followed by the string -generated by <TT +generated by <CODE CLASS="FUNCTION" ->lwres_hstrerror()</TT +>lwres_hstrerror()</CODE > for the error code -stored in the global variable <TT +stored in the global variable <CODE CLASS="CONSTANT" ->lwres_h_errno</TT +>lwres_h_errno</CODE >.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_hstrerror()</TT +>lwres_hstrerror()</CODE > returns an appropriate string -for the error code gievn by <TT +for the error code gievn by <VAR CLASS="PARAMETER" -><I ->err</I -></TT +>err</VAR >. The values of the error codes and messages are as follows: @@ -205,14 +201,14 @@ NAME="AEN65" CLASS="ERRORNAME" >Unknown resolver error</SPAN > is returned by -<TT +<CODE CLASS="FUNCTION" ->lwres_hstrerror()</TT +>lwres_hstrerror()</CODE > when the value of -<TT +<CODE CLASS="CONSTANT" ->lwres_h_errno</TT +>lwres_h_errno</CODE > is not a valid error code.</P ></DIV diff --git a/dist/bind/lib/lwres/man/lwres_inetntop.html b/dist/bind/lib/lwres/man/lwres_inetntop.html index defddb0a9a4..196d87dffd1 100644 --- a/dist/bind/lib/lwres/man/lwres_inetntop.html +++ b/dist/bind/lib/lwres/man/lwres_inetntop.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_inetntop.html,v 1.5.2.1.4.1 2004/03/06 08:15:41 marka Exp --> +<!-- Id: lwres_inetntop.html,v 1.5.2.1.4.2 2004/08/22 23:39:05 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_inetntop</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_inetntop</A -></H1 +></A +>lwres_inetntop</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN11" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN12" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/net.h></PRE @@ -82,37 +82,29 @@ NAME="AEN21" ><H2 >DESCRIPTION</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_net_ntop()</TT +>lwres_net_ntop()</CODE > converts an IP address of -protocol family <TT +protocol family <VAR CLASS="PARAMETER" -><I ->af</I -></TT +>af</VAR > — IPv4 or IPv6 — -at location <TT +at location <VAR CLASS="PARAMETER" -><I ->src</I -></TT +>src</VAR > from network format to its conventional representation as a string. For IPv4 addresses, that string would be a dotted-decimal. An IPv6 address would be represented in colon notation as described in RFC1884.</P ><P ->The generated string is copied to <TT +>The generated string is copied to <VAR CLASS="PARAMETER" -><I ->dst</I -></TT +>dst</VAR > provided -<TT +<VAR CLASS="PARAMETER" -><I ->size</I -></TT +>size</VAR > indicates it is long enough to store the ASCII representation of the address.</P ></DIV @@ -124,33 +116,29 @@ NAME="AEN30" ><H2 >RETURN VALUES</H2 ><P ->If successful, the function returns <TT +>If successful, the function returns <VAR CLASS="PARAMETER" -><I ->dst</I -></TT +>dst</VAR >: a pointer to a string containing the presentation format of the -address. <TT +address. <CODE CLASS="FUNCTION" ->lwres_net_ntop()</TT +>lwres_net_ntop()</CODE > returns <SPAN CLASS="TYPE" >NULL</SPAN > and sets the global variable -<TT +<CODE CLASS="CONSTANT" ->errno</TT +>errno</CODE > to <SPAN CLASS="ERRORCODE" >EAFNOSUPPORT</SPAN > if -the protocol family given in <TT +the protocol family given in <VAR CLASS="PARAMETER" -><I ->af</I -></TT +>af</VAR > is not supported.</P ></DIV diff --git a/dist/bind/lib/lwres/man/lwres_noop.html b/dist/bind/lib/lwres/man/lwres_noop.html index cb1eca822a3..0c239e7ce1b 100644 --- a/dist/bind/lib/lwres/man/lwres_noop.html +++ b/dist/bind/lib/lwres/man/lwres_noop.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_noop.html,v 1.7.2.1.4.1 2004/03/06 08:15:41 marka Exp --> +<!-- Id: lwres_noop.html,v 1.7.2.1.4.2 2004/08/22 23:39:05 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_noop</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_noop</A -></H1 +></A +>lwres_noop</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN16" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN17" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/lwres.h></PRE @@ -176,43 +176,33 @@ Although the structures have different types, they are identical. This is because the no-op opcode simply echos whatever data was sent: the response is therefore identical to the request.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_nooprequest_render()</TT +>lwres_nooprequest_render()</CODE > uses resolver -context <TT +context <VAR CLASS="PARAMETER" -><I ->ctx</I -></TT +>ctx</VAR > to convert no-op request structure -<TT +<VAR CLASS="PARAMETER" -><I ->req</I -></TT +>req</VAR > to canonical format. The packet header -structure <TT +structure <VAR CLASS="PARAMETER" -><I ->pkt</I -></TT +>pkt</VAR > is initialised and transferred to -buffer <TT +buffer <VAR CLASS="PARAMETER" -><I ->b</I -></TT +>b</VAR >. The contents of -<TT +<VAR CLASS="PARAMETER" -><I ->*req</I -></TT +>*req</VAR > are then appended to the buffer in -canonical format. <TT +canonical format. <CODE CLASS="FUNCTION" ->lwres_noopresponse_render()</TT +>lwres_noopresponse_render()</CODE > performs the same task, except it converts a no-op response structure <SPAN @@ -221,68 +211,58 @@ CLASS="TYPE" > to the lightweight resolver's canonical format.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_nooprequest_parse()</TT +>lwres_nooprequest_parse()</CODE > uses context -<TT +<VAR CLASS="PARAMETER" -><I ->ctx</I -></TT +>ctx</VAR > to convert the contents of packet -<TT +<VAR CLASS="PARAMETER" -><I ->pkt</I -></TT +>pkt</VAR > to a <SPAN CLASS="TYPE" >lwres_nooprequest_t</SPAN > -structure. Buffer <TT +structure. Buffer <VAR CLASS="PARAMETER" -><I ->b</I -></TT +>b</VAR > provides space to be used for storing this structure. When the function succeeds, the resulting <SPAN CLASS="TYPE" >lwres_nooprequest_t</SPAN > is made available through -<TT +<VAR CLASS="PARAMETER" -><I ->*structp</I -></TT +>*structp</VAR >. -<TT +<CODE CLASS="FUNCTION" ->lwres_noopresponse_parse()</TT +>lwres_noopresponse_parse()</CODE > offers the same -semantics as <TT +semantics as <CODE CLASS="FUNCTION" ->lwres_nooprequest_parse()</TT +>lwres_nooprequest_parse()</CODE > except it yields a <SPAN CLASS="TYPE" >lwres_noopresponse_t</SPAN > structure.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_noopresponse_free()</TT +>lwres_noopresponse_free()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_nooprequest_free()</TT +>lwres_nooprequest_free()</CODE > release the memory in -resolver context <TT +resolver context <VAR CLASS="PARAMETER" -><I ->ctx</I -></TT +>ctx</VAR > that was allocated to the <SPAN CLASS="TYPE" @@ -291,11 +271,9 @@ CLASS="TYPE" CLASS="TYPE" >lwres_nooprequest_t</SPAN > -structures referenced via <TT +structures referenced via <VAR CLASS="PARAMETER" -><I ->structp</I -></TT +>structp</VAR >.</P ></DIV ><DIV @@ -307,23 +285,23 @@ NAME="AEN95" >RETURN VALUES</H2 ><P >The no-op opcode functions -<TT +<CODE CLASS="FUNCTION" ->lwres_nooprequest_render()</TT +>lwres_nooprequest_render()</CODE >, -<TT +<CODE CLASS="FUNCTION" ->lwres_noopresponse_render()</TT +>lwres_noopresponse_render()</CODE > -<TT +<CODE CLASS="FUNCTION" ->lwres_nooprequest_parse()</TT +>lwres_nooprequest_parse()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_noopresponse_parse()</TT +>lwres_noopresponse_parse()</CODE > all return <SPAN @@ -342,11 +320,9 @@ CLASS="ERRORCODE" >LWRES_R_UNEXPECTEDEND</SPAN > is returned if the available space in the buffer -<TT +<VAR CLASS="PARAMETER" -><I ->b</I -></TT +>b</VAR > is too small to accommodate the packet header or the <SPAN @@ -359,14 +335,14 @@ CLASS="TYPE" >lwres_noopresponse_t</SPAN > structures. -<TT +<CODE CLASS="FUNCTION" ->lwres_nooprequest_parse()</TT +>lwres_nooprequest_parse()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_noopresponse_parse()</TT +>lwres_noopresponse_parse()</CODE > will return <SPAN @@ -380,9 +356,9 @@ CLASS="ERRORCODE" >LWRES_R_FAILURE</SPAN > if -<TT +<CODE CLASS="CONSTANT" ->pktflags</TT +>pktflags</CODE > in the packet header structure <SPAN diff --git a/dist/bind/lib/lwres/man/lwres_packet.html b/dist/bind/lib/lwres/man/lwres_packet.html index 42c633cf6fb..73511ea31f9 100644 --- a/dist/bind/lib/lwres/man/lwres_packet.html +++ b/dist/bind/lib/lwres/man/lwres_packet.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_packet.html,v 1.8.2.1.4.1 2004/03/06 08:15:42 marka Exp --> +<!-- Id: lwres_packet.html,v 1.8.2.1.4.2 2004/08/22 23:39:05 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_packet</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_packet</A -></H1 +></A +>lwres_packet</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN12" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN13" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/lwpacket.h></PRE @@ -125,9 +125,9 @@ struct lwres_lwpacket { CLASS="VARIABLELIST" ><DL ><DT -><TT +><CODE CLASS="CONSTANT" ->length</TT +>length</CODE ></DT ><DD ><P @@ -136,9 +136,9 @@ This field is filled in by the lwres_gabn_*() and lwres_gnba_*() calls.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->version</TT +>version</CODE ></DT ><DD ><P @@ -152,9 +152,9 @@ This field is filled in by the lwres_gabn_*() and lwres_gnba_*() calls.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->pktflags</TT +>pktflags</CODE ></DT ><DD ><P @@ -166,9 +166,9 @@ LWRES_LWPACKETFLAG_RESPONSE bit, which is set by the library in the lwres_gabn_*() and lwres_gnba_*() calls.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->serial</TT +>serial</CODE ></DT ><DD ><P @@ -179,9 +179,9 @@ may be dropped. This field must be set by the application.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->opcode</TT +>opcode</CODE ></DT ><DD ><P @@ -193,9 +193,9 @@ This field is filled in by the lwres_gabn_*() and lwres_gnba_*() calls.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->result</TT +>result</CODE ></DT ><DD ><P @@ -206,9 +206,9 @@ This field is filled in by the lwres_gabn_*() and lwres_gnba_*() calls.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->recvlength</TT +>recvlength</CODE ></DT ><DD ><P @@ -218,9 +218,9 @@ is too large for replies. This field is supplied by the application.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->authtype</TT +>authtype</CODE ></DT ><DD ><P @@ -230,9 +230,9 @@ and types between 0x0000 and 0x0fff are reserved for library use. Currently these are not used and must be zero.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->authlen</TT +>authlen</CODE ></DT ><DD ><P @@ -250,9 +250,9 @@ Since packet authentication is currently not used, this must be zero.</P CLASS="VARIABLELIST" ><DL ><DT -><TT +><CODE CLASS="CONSTANT" ->NOOP</TT +>NOOP</CODE ></DT ><DD ><P @@ -260,9 +260,9 @@ CLASS="CONSTANT" The lwres_noop_*() functions should be used for this type.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->GETADDRSBYNAME</TT +>GETADDRSBYNAME</CODE ></DT ><DD ><P @@ -270,9 +270,9 @@ CLASS="CONSTANT" The lwres_gabn_*() functions should be used for this type.</P ></DD ><DT -><TT +><CODE CLASS="CONSTANT" ->GETNAMEBYADDR</TT +>GETNAMEBYADDR</CODE ></DT ><DD ><P @@ -283,50 +283,40 @@ The lwres_gnba_*() functions should be used for this type.</P ></DIV ></P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_lwpacket_renderheader()</TT +>lwres_lwpacket_renderheader()</CODE > transfers the contents of lightweight resolver packet structure <SPAN CLASS="TYPE" >lwres_lwpacket_t</SPAN -> <TT +> <VAR CLASS="PARAMETER" -><I ->*pkt</I -></TT +>*pkt</VAR > in network byte order to the lightweight resolver buffer, -<TT +<VAR CLASS="PARAMETER" -><I ->*b</I -></TT +>*b</VAR >.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_lwpacket_parseheader()</TT +>lwres_lwpacket_parseheader()</CODE > performs the converse operation. It transfers data in network byte order from -buffer <TT +buffer <VAR CLASS="PARAMETER" -><I ->*b</I -></TT +>*b</VAR > to resolver packet -<TT +<VAR CLASS="PARAMETER" -><I ->*pkt</I -></TT +>*pkt</VAR >. The contents of the buffer -<TT +<VAR CLASS="PARAMETER" -><I ->b</I -></TT +>b</VAR > should correspond to a <SPAN CLASS="TYPE" @@ -342,29 +332,25 @@ NAME="AEN107" >RETURN VALUES</H2 ><P > Successful calls to -<TT +<CODE CLASS="FUNCTION" ->lwres_lwpacket_renderheader()</TT +>lwres_lwpacket_renderheader()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_lwpacket_parseheader()</TT +>lwres_lwpacket_parseheader()</CODE > return <SPAN CLASS="ERRORCODE" >LWRES_R_SUCCESS</SPAN >. If there is insufficient -space to copy data between the buffer <TT +space to copy data between the buffer <VAR CLASS="PARAMETER" -><I ->*b</I -></TT +>*b</VAR > and -lightweight resolver packet <TT +lightweight resolver packet <VAR CLASS="PARAMETER" -><I ->*pkt</I -></TT +>*pkt</VAR > both functions return <SPAN CLASS="ERRORCODE" diff --git a/dist/bind/lib/lwres/man/lwres_resutil.html b/dist/bind/lib/lwres/man/lwres_resutil.html index ce23f90f63c..f6bf3b1c903 100644 --- a/dist/bind/lib/lwres/man/lwres_resutil.html +++ b/dist/bind/lib/lwres/man/lwres_resutil.html @@ -15,16 +15,16 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- Id: lwres_resutil.html,v 1.8.2.1.4.1 2004/03/06 08:15:42 marka Exp --> +<!-- Id: lwres_resutil.html,v 1.8.2.1.4.2 2004/08/22 23:39:05 marka Exp --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML ><HEAD ><TITLE >lwres_resutil</TITLE ><META NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.73 -"></HEAD +CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD ><BODY CLASS="REFENTRY" BGCOLOR="#FFFFFF" @@ -35,8 +35,8 @@ ALINK="#0000FF" ><H1 ><A NAME="AEN1" ->lwres_resutil</A -></H1 +></A +>lwres_resutil</H1 ><DIV CLASS="REFNAMEDIV" ><A @@ -54,11 +54,11 @@ NAME="AEN14" >Synopsis</H2 ><DIV CLASS="FUNCSYNOPSIS" +><P +></P ><A NAME="AEN15" ></A -><P -></P ><PRE CLASS="FUNCSYNOPSISINFO" >#include <lwres/lwres.h></PRE @@ -106,32 +106,26 @@ NAME="AEN43" ><H2 >DESCRIPTION</H2 ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_string_parse()</TT +>lwres_string_parse()</CODE > retrieves a DNS-encoded string starting the current pointer of lightweight resolver buffer -<TT +<VAR CLASS="PARAMETER" -><I ->b</I -></TT ->: i.e. <TT +>b</VAR +>: i.e. <CODE CLASS="CONSTANT" ->b->current</TT +>b->current</CODE >. When the function returns, the address of the first byte of the -encoded string is returned via <TT +encoded string is returned via <VAR CLASS="PARAMETER" -><I ->*c</I -></TT +>*c</VAR > and the -length of that string is given by <TT +length of that string is given by <VAR CLASS="PARAMETER" -><I ->*len</I -></TT +>*len</VAR >. The buffer's current pointer is advanced to point at the character following the string length, the encoded string, and the trailing @@ -140,45 +134,43 @@ CLASS="TYPE" >NULL</SPAN > character.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_addr_parse()</TT +>lwres_addr_parse()</CODE > extracts an address from the -buffer <TT +buffer <VAR CLASS="PARAMETER" -><I ->b</I -></TT +>b</VAR >. The buffer's current pointer -<TT +<CODE CLASS="CONSTANT" ->b->current</TT +>b->current</CODE > is presumed to point at an encoded address: the address preceded by a 32-bit protocol family identifier and a 16-bit length field. The encoded address is copied to -<TT +<CODE CLASS="CONSTANT" ->addr->address</TT +>addr->address</CODE > and -<TT +<CODE CLASS="CONSTANT" ->addr->length</TT +>addr->length</CODE > indicates the size in bytes of -the address that was copied. <TT +the address that was copied. <CODE CLASS="CONSTANT" ->b->current</TT +>b->current</CODE > is advanced to point at the next byte of available data in the buffer following the encoded address.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_getaddrsbyname()</TT +>lwres_getaddrsbyname()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_getnamebyaddr()</TT +>lwres_getnamebyaddr()</CODE > use the <SPAN @@ -213,27 +205,21 @@ CLASS="REFENTRYTITLE" functions.</P ><P >The lightweight resolver uses -<TT +<CODE CLASS="FUNCTION" ->lwres_getaddrsbyname()</TT +>lwres_getaddrsbyname()</CODE > to perform foward lookups. -Hostname <TT +Hostname <VAR CLASS="PARAMETER" -><I ->name</I -></TT +>name</VAR > is looked up using the resolver -context <TT +context <VAR CLASS="PARAMETER" -><I ->ctx</I -></TT +>ctx</VAR > for memory allocation. -<TT +<VAR CLASS="PARAMETER" -><I ->addrtypes</I -></TT +>addrtypes</VAR > is a bitmask indicating which type of addresses are to be looked up. Current values for this bitmask are <SPAN @@ -244,29 +230,23 @@ CLASS="TYPE" CLASS="TYPE" >LWRES_ADDRTYPE_V6</SPAN > for IPv6 addresses. Results of the -lookup are returned in <TT +lookup are returned in <VAR CLASS="PARAMETER" -><I ->*structp</I -></TT +>*structp</VAR >.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_getnamebyaddr()</TT +>lwres_getnamebyaddr()</CODE > performs reverse lookups. -Resolver context <TT +Resolver context <VAR CLASS="PARAMETER" -><I ->ctx</I -></TT +>ctx</VAR > is used for memory allocation. The address type is indicated by -<TT +<VAR CLASS="PARAMETER" -><I ->addrtype</I -></TT +>addrtype</VAR >: <SPAN CLASS="TYPE" >LWRES_ADDRTYPE_V4</SPAN @@ -275,23 +255,17 @@ CLASS="TYPE" CLASS="TYPE" >LWRES_ADDRTYPE_V6</SPAN >. The address to be looked up is given -by <TT +by <VAR CLASS="PARAMETER" -><I ->addr</I -></TT +>addr</VAR > and its length is -<TT +<VAR CLASS="PARAMETER" -><I ->addrlen</I -></TT +>addrlen</VAR > bytes. The result of the function call -is made available through <TT +is made available through <VAR CLASS="PARAMETER" -><I ->*structp</I -></TT +>*structp</VAR >.</P ></DIV ><DIV @@ -303,14 +277,14 @@ NAME="AEN84" >RETURN VALUES</H2 ><P >Successful calls to -<TT +<CODE CLASS="FUNCTION" ->lwres_string_parse()</TT +>lwres_string_parse()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_addr_parse()</TT +>lwres_addr_parse()</CODE > return <SPAN @@ -330,9 +304,9 @@ CLASS="ERRORCODE" if the buffer has less space than expected for the components of the encoded string or address.</P ><P -><TT +><CODE CLASS="FUNCTION" ->lwres_getaddrsbyname()</TT +>lwres_getaddrsbyname()</CODE > returns <SPAN @@ -345,11 +319,9 @@ CLASS="ERRORCODE" >LWRES_R_NOTFOUND</SPAN > if the hostname -<TT +<VAR CLASS="PARAMETER" -><I ->name</I -></TT +>name</VAR > could not be found.</P ><P @@ -358,20 +330,20 @@ CLASS="ERRORCODE" >LWRES_R_SUCCESS</SPAN > is returned by a successful call to -<TT +<CODE CLASS="FUNCTION" ->lwres_getnamebyaddr()</TT +>lwres_getnamebyaddr()</CODE >.</P ><P >Both -<TT +<CODE CLASS="FUNCTION" ->lwres_getaddrsbyname()</TT +>lwres_getaddrsbyname()</CODE > and -<TT +<CODE CLASS="FUNCTION" ->lwres_getnamebyaddr()</TT +>lwres_getnamebyaddr()</CODE > return <SPAN diff --git a/dist/bind/lib/lwres/print.c b/dist/bind/lib/lwres/print.c new file mode 100644 index 00000000000..f5efdc195d1 --- /dev/null +++ b/dist/bind/lib/lwres/print.c @@ -0,0 +1,555 @@ +/* $NetBSD: print.c,v 1.1.1.1 2004/11/06 23:56:01 christos Exp $ */ + +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-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: print.c,v 1.2.4.1 2004/08/28 06:25:25 marka Exp */ + +#include <config.h> + +#include <ctype.h> +#include <stdio.h> /* for sprintf */ + +#define LWRES__PRINT_SOURCE /* Used to get the lwres_print_* prototypes. */ + +#include <stdlib.h> + +#include "assert_p.h" +#include "print_p.h" + +int +lwres__print_sprintf(char *str, const char *format, ...) { + va_list ap; + + va_start(ap, format); + vsprintf(str, format, ap); + va_end(ap); + return (strlen(str)); +} + +/* + * Return length of string that would have been written if not truncated. + */ + +int +lwres__print_snprintf(char *str, size_t size, const char *format, ...) { + va_list ap; + int ret; + + va_start(ap, format); + ret = vsnprintf(str, size, format, ap); + va_end(ap); + return (ret); + +} + +/* + * Return length of string that would have been written if not truncated. + */ + +int +lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) { + int h; + int l; + int q; + int alt; + int zero; + int left; + int plus; + int space; + int neg; + long long tmpi; + unsigned long long tmpui; + unsigned long width; + unsigned long precision; + unsigned int length; + char buf[1024]; + char c; + void *v; + char *save = str; + const char *cp; + const char *head; + int count = 0; + int pad; + int zeropad; + int dot; + double dbl; +#ifdef HAVE_LONG_DOUBLE + long double ldbl; +#endif + char fmt[32]; + + INSIST(str != NULL); + INSIST(format != NULL); + + while (*format != '\0') { + if (*format != '%') { + if (size > 1) { + *str++ = *format; + size--; + } + count++; + format++; + continue; + } + format++; + + /* + * Reset flags. + */ + dot = neg = space = plus = left = zero = alt = h = l = q = 0; + width = precision = 0; + head = ""; + length = pad = zeropad = 0; + + do { + if (*format == '#') { + alt = 1; + format++; + } else if (*format == '-') { + left = 1; + zero = 0; + format++; + } else if (*format == ' ') { + if (!plus) + space = 1; + format++; + } else if (*format == '+') { + plus = 1; + space = 0; + format++; + } else if (*format == '0') { + if (!left) + zero = 1; + format++; + } else + break; + } while (1); + + /* + * Width. + */ + if (*format == '*') { + width = va_arg(ap, int); + format++; + } else if (isdigit((unsigned char)*format)) { + char *e; + width = strtoul(format, &e, 10); + format = e; + } + + /* + * Precision. + */ + if (*format == '.') { + format++; + dot = 1; + if (*format == '*') { + precision = va_arg(ap, int); + format++; + } else if (isdigit((unsigned char)*format)) { + char *e; + precision = strtoul(format, &e, 10); + format = e; + } + } + + switch (*format) { + case '\0': + continue; + case '%': + if (size > 1) { + *str++ = *format; + size--; + } + count++; + break; + case 'q': + q = 1; + format++; + goto doint; + case 'h': + h = 1; + format++; + goto doint; + case 'l': + l = 1; + format++; + if (*format == 'l') { + q = 1; + format++; + } + goto doint; + case 'n': + case 'i': + case 'd': + case 'o': + case 'u': + case 'x': + case 'X': + doint: + if (precision != 0) + zero = 0; + switch (*format) { + case 'n': + if (h) { + short int *p; + p = va_arg(ap, short *); + REQUIRE(p != NULL); + *p = str - save; + } else if (l) { + long int *p; + p = va_arg(ap, long *); + REQUIRE(p != NULL); + *p = str - save; + } else { + int *p; + p = va_arg(ap, int *); + REQUIRE(p != NULL); + *p = str - save; + } + break; + case 'i': + case 'd': + if (q) + tmpi = va_arg(ap, long long int); + else if (l) + tmpi = va_arg(ap, long int); + else + tmpi = va_arg(ap, int); + if (tmpi < 0) { + head = "-"; + tmpui = -tmpi; + } else { + if (plus) + head = "+"; + else if (space) + head = " "; + else + head = ""; + tmpui = tmpi; + } + sprintf(buf, "%llu", + tmpui); + goto printint; + case 'o': + if (q) + tmpui = va_arg(ap, + unsigned long long int); + else if (l) + tmpui = va_arg(ap, long int); + else + tmpui = va_arg(ap, int); + sprintf(buf, + alt ? "%#llo" : "%llo", tmpui); + goto printint; + case 'u': + if (q) + tmpui = va_arg(ap, + unsigned long long int); + else if (l) + tmpui = va_arg(ap, unsigned long int); + else + tmpui = va_arg(ap, unsigned int); + sprintf(buf, "%llu", tmpui); + goto printint; + case 'x': + if (q) + tmpui = va_arg(ap, + unsigned long long int); + else if (l) + tmpui = va_arg(ap, unsigned long int); + else + tmpui = va_arg(ap, unsigned int); + if (alt) { + head = "0x"; + if (precision > 2) + precision -= 2; + } + sprintf(buf, "%llx", tmpui); + goto printint; + case 'X': + if (q) + tmpui = va_arg(ap, + unsigned long long int); + else if (l) + tmpui = va_arg(ap, unsigned long int); + else + tmpui = va_arg(ap, unsigned int); + if (alt) { + head = "0X"; + if (precision > 2) + precision -= 2; + } + sprintf(buf, "%llX", tmpui); + goto printint; + printint: + if (precision != 0 || width != 0) { + length = strlen(buf); + if (length < precision) + zeropad = precision - length; + else if (length < width && zero) + zeropad = width - length; + if (width != 0) { + pad = width - length - + zeropad - strlen(head); + if (pad < 0) + pad = 0; + } + } + count += strlen(head) + strlen(buf) + pad + + zeropad; + if (!left) { + while (pad > 0 && size > 1) { + *str++ = ' '; + size--; + pad--; + } + } + cp = head; + while (*cp != '\0' && size > 1) { + *str++ = *cp++; + size--; + } + while (zeropad > 0 && size > 1) { + *str++ = '0'; + size--; + zeropad--; + } + cp = buf; + while (*cp != '\0' && size > 1) { + *str++ = *cp++; + size--; + } + while (pad > 0 && size > 1) { + *str++ = ' '; + size--; + pad--; + } + break; + default: + break; + } + break; + case 's': + cp = va_arg(ap, char *); + REQUIRE(cp != NULL); + + if (precision != 0) { + /* + * cp need not be NULL terminated. + */ + const char *tp; + unsigned long n; + + n = precision; + tp = cp; + while (n != 0 && *tp != '\0') + n--, tp++; + length = precision - n; + } else { + length = strlen(cp); + } + if (width != 0) { + pad = width - length; + if (pad < 0) + pad = 0; + } + count += pad + length; + if (!left) + while (pad > 0 && size > 1) { + *str++ = ' '; + size--; + pad--; + } + if (precision != 0) + while (precision > 0 && *cp != '\0' && + size > 1) { + *str++ = *cp++; + size--; + precision--; + } + else + while (*cp != '\0' && size > 1) { + *str++ = *cp++; + size--; + } + while (pad > 0 && size > 1) { + *str++ = ' '; + size--; + pad--; + } + break; + case 'c': + c = va_arg(ap, int); + if (width > 0) { + count += width; + width--; + if (left) { + *str++ = c; + size--; + } + while (width-- > 0 && size > 1) { + *str++ = ' '; + size--; + } + if (!left && size > 1) { + *str++ = c; + size--; + } + } else { + count++; + if (size > 1) { + *str++ = c; + size--; + } + } + break; + case 'p': + v = va_arg(ap, void *); + sprintf(buf, "%p", v); + length = strlen(buf); + if (precision > length) + zeropad = precision - length; + if (width > 0) { + pad = width - length - zeropad; + if (pad < 0) + pad = 0; + } + count += length + pad + zeropad; + if (!left) + while (pad > 0 && size > 1) { + *str++ = ' '; + size--; + pad--; + } + cp = buf; + if (zeropad > 0 && buf[0] == '0' && + (buf[1] == 'x' || buf[1] == 'X')) { + if (size > 1) { + *str++ = *cp++; + size--; + } + if (size > 1) { + *str++ = *cp++; + size--; + } + while (zeropad > 0 && size > 1) { + *str++ = '0'; + size--; + zeropad--; + } + } + while (*cp != '\0' && size > 1) { + *str++ = *cp++; + size--; + } + while (pad > 0 && size > 1) { + *str++ = ' '; + size--; + pad--; + } + break; + case 'D': /*deprecated*/ + INSIST("use %ld instead of %D" == NULL); + case 'O': /*deprecated*/ + INSIST("use %lo instead of %O" == NULL); + case 'U': /*deprecated*/ + INSIST("use %lu instead of %U" == NULL); + + case 'L': +#ifdef HAVE_LONG_DOUBLE + l = 1; +#else + INSIST("long doubles are not supported" == NULL); +#endif + /*FALLTHROUGH*/ + case 'e': + case 'E': + case 'f': + case 'g': + case 'G': + if (!dot) + precision = 6; + /* + * IEEE floating point. + * MIN 2.2250738585072014E-308 + * MAX 1.7976931348623157E+308 + * VAX floating point has a smaller range than IEEE. + * + * precisions > 324 don't make much sense. + * if we cap the precision at 512 we will not + * overflow buf. + */ + if (precision > 512) + precision = 512; + sprintf(fmt, "%%%s%s.%lu%s%c", alt ? "#" : "", + plus ? "+" : space ? " " : "", + precision, l ? "L" : "", *format); + switch (*format) { + case 'e': + case 'E': + case 'f': + case 'g': + case 'G': +#ifdef HAVE_LONG_DOUBLE + if (l) { + ldbl = va_arg(ap, long double); + sprintf(buf, fmt, ldbl); + } else +#endif + { + dbl = va_arg(ap, double); + sprintf(buf, fmt, dbl); + } + length = strlen(buf); + if (width > 0) { + pad = width - length; + if (pad < 0) + pad = 0; + } + count += length + pad; + if (!left) + while (pad > 0 && size > 1) { + *str++ = ' '; + size--; + pad--; + } + cp = buf; + while (*cp != ' ' && size > 1) { + *str++ = *cp++; + size--; + } + while (pad > 0 && size > 1) { + *str++ = ' '; + size--; + pad--; + } + break; + default: + continue; + } + break; + default: + continue; + } + format++; + } + if (size > 0) + *str = '\0'; + return (count); +} diff --git a/dist/bind/lib/lwres/print_p.h b/dist/bind/lib/lwres/print_p.h new file mode 100644 index 00000000000..d43b72034e6 --- /dev/null +++ b/dist/bind/lib/lwres/print_p.h @@ -0,0 +1,88 @@ +/* $NetBSD: print_p.h,v 1.1.1.1 2004/11/06 23:56:01 christos Exp $ */ + +/* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 1999-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: print_p.h,v 1.2.4.1 2004/08/28 06:25:25 marka Exp */ + +#ifndef LWRES_PRINT_P_H +#define LWRES_PRINT_P_H 1 + +/*** + *** Imports + ***/ + +#include <lwres/lang.h> +#include <lwres/platform.h> + +/* + * This block allows lib/lwres/print.c to be cleanly compiled even if + * the platform does not need it. The standard Makefile will still + * not compile print.c or archive print.o, so this is just to make test + * compilation ("make print.o") easier. + */ +#if !defined(LWRES_PLATFORM_NEEDVSNPRINTF) && defined(LWRES__PRINT_SOURCE) +#define LWRES_PLATFORM_NEEDVSNPRINTF +#endif + +#if !defined(LWRES_PLATFORM_NEEDSPRINTF) && defined(LWRES__PRINT_SOURCE) +#define LWRES_PLATFORM_NEEDSPRINTF +#endif + +/*** + *** Macros. + ***/ + +#ifdef __GNUC__ +#define LWRES_FORMAT_PRINTF(fmt, args) \ + __attribute__((__format__(__printf__, fmt, args))) +#else +#define LWRES_FORMAT_PRINTF(fmt, args) +#endif + +/*** + *** Functions + ***/ + +#ifdef LWRES_PLATFORM_NEEDVSNPRINTF +#include <stdarg.h> +#include <stddef.h> +#endif + +LWRES_LANG_BEGINDECLS + +#ifdef LWRES_PLATFORM_NEEDVSNPRINTF +int +lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) + LWRES_FORMAT_PRINTF(3, 0); +#define vsnprintf lwres__print_vsnprintf + +int +lwres__print_snprintf(char *str, size_t size, const char *format, ...) + LWRES_FORMAT_PRINTF(3, 4); +#define snprintf lwres__print_snprintf +#endif /* LWRES_PLATFORM_NEEDVSNPRINTF */ + +#ifdef LWRES_PLATFORM_NEEDSPRINTF +int +lwres__print_sprintf(char *str, const char *format, ...) LWRES_FORMAT_PRINTF(2, 3); +#define sprintf lwres__print_sprintf +#endif + +LWRES_LANG_ENDDECLS + +#endif /* LWRES_PRINT_P_H */ diff --git a/dist/bind/lib/tests/Makefile.in b/dist/bind/lib/tests/Makefile.in index e8d8b96824f..0a17d0e77e5 100644 --- a/dist/bind/lib/tests/Makefile.in +++ b/dist/bind/lib/tests/Makefile.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: Makefile.in,v 1.14.12.6 2004/03/06 08:15:46 marka Exp +# Id: Makefile.in,v 1.14.12.7 2004/07/20 07:01:59 marka Exp srcdir = @srcdir@ VPATH = @srcdir@ @@ -46,7 +46,7 @@ libt_api.@SA@: ${OBJS} libt_api.la: ${OBJS} ${LIBTOOL_MODE_LINK} \ - ${CC} ${ALL_CFLAGS} -o libt_api.la -rpath ${libdir} \ + ${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libt_api.la -rpath ${libdir} \ ${OBJS} ${ISCLIBS} ${LIBS} -allow-undefined timestamp: libt_api.@A@ diff --git a/dist/bind/lib/tests/include/tests/t_api.h b/dist/bind/lib/tests/include/tests/t_api.h index d6c28352266..7b8f1004703 100644 --- a/dist/bind/lib/tests/include/tests/t_api.h +++ b/dist/bind/lib/tests/include/tests/t_api.h @@ -1,4 +1,4 @@ -/* $NetBSD: t_api.h,v 1.1.1.1 2004/05/17 23:45:12 christos Exp $ */ +/* $NetBSD: t_api.h,v 1.1.1.2 2004/11/06 23:56:02 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: t_api.h,v 1.14.206.1 2004/03/06 08:15:47 marka Exp */ +/* Id: t_api.h,v 1.14.206.2 2004/06/21 06:58:02 marka Exp */ #ifndef TESTS_T_API_H #define TESTS_T_API_H 1 @@ -39,6 +39,7 @@ #define T_UNRESOLVED 0x3 #define T_UNSUPPORTED 0x4 #define T_UNTESTED 0x5 +#define T_THREADONLY 0x6 /* * diff --git a/dist/bind/lib/tests/t_api.c b/dist/bind/lib/tests/t_api.c index 1401f655cd5..ac1ff43933d 100644 --- a/dist/bind/lib/tests/t_api.c +++ b/dist/bind/lib/tests/t_api.c @@ -1,4 +1,4 @@ -/* $NetBSD: t_api.c,v 1.1.1.1 2004/05/17 23:45:12 christos Exp $ */ +/* $NetBSD: t_api.c,v 1.1.1.2 2004/11/06 23:56:02 christos Exp $ */ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") @@ -17,7 +17,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* Id: t_api.c,v 1.48.2.1.2.4 2004/03/08 09:05:13 marka Exp */ +/* Id: t_api.c,v 1.48.2.1.2.6 2004/08/28 06:25:27 marka Exp */ #include <config.h> @@ -35,6 +35,7 @@ #include <isc/boolean.h> #include <isc/commandline.h> +#include <isc/print.h> #include <isc/string.h> #include <dns/compress.h> @@ -392,6 +393,9 @@ t_result(int result) { case T_UNTESTED: p = "UNTESTED"; break; + case T_THREADONLY: + p = "THREADONLY"; + break; default: p = "UNKNOWN"; break; diff --git a/dist/bind/make/rules.in b/dist/bind/make/rules.in index 714070163ab..9cbeba2369d 100644 --- a/dist/bind/make/rules.in +++ b/dist/bind/make/rules.in @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# Id: rules.in,v 1.40.2.5.4.3 2004/03/06 13:16:21 marka Exp +# Id: rules.in,v 1.40.2.5.4.4 2004/07/20 07:02:00 marka Exp ### ### Common Makefile rules for BIND 9. @@ -87,6 +87,7 @@ install clean distclean maintainer-clean doc docclean man manclean:: ### CC ### Makefile may define ### CFLAGS +### LDFLAGS ### CINCLUDES ### CDEFINES ### CWARNINGS @@ -95,6 +96,7 @@ install clean distclean maintainer-clean doc docclean man manclean:: CC = @CC@ CFLAGS = @CFLAGS@ +LDFLAGS = @LDFLAGS@ STD_CINCLUDES = @STD_CINCLUDES@ STD_CDEFINES = @STD_CDEFINES@ STD_CWARNINGS = @STD_CWARNINGS@ diff --git a/dist/bind/version b/dist/bind/version index 0e408b2320c..b7eaab41c8f 100644 --- a/dist/bind/version +++ b/dist/bind/version @@ -1,4 +1,4 @@ -# Id: version,v 1.26.2.17.2.4 2004/04/29 03:23:36 marka Exp +# Id: version,v 1.26.2.17.2.10.4.1 2004/09/20 01:01:01 marka Exp # # This file must follow /bin/sh rules. It is imported directly via # configure. @@ -6,5 +6,5 @@ MAJORVER=9 MINORVER=3 PATCHVER=0 -RELEASETYPE=beta -RELEASEVER=3 +RELEASETYPE= +RELEASEVER= diff --git a/dist/bind/win32utils/BuildAll.bat b/dist/bind/win32utils/BuildAll.bat index 22222ad7706..c0077b9edcb 100644 --- a/dist/bind/win32utils/BuildAll.bat +++ b/dist/bind/win32utils/BuildAll.bat @@ -105,10 +105,12 @@ cd ..\.. cd dnssec\win32 nmake /nologo -f keygen.mak CFG="keygen - Win32 Release" NO_EXTERNAL_DEPS="1" -nmake /nologo -f makekeyset.mak CFG="makekeyset - Win32 Release" NO_EXTERNAL_DEPS="1" -nmake /nologo -f signkey.mak CFG="signkey - Win32 Release" NO_EXTERNAL_DEPS="1" +rem nmake /nologo -f makekeyset.mak CFG="makekeyset - Win32 Release" NO_EXTERNAL_DEPS="1" +rem nmake /nologo -f signkey.mak CFG="signkey - Win32 Release" NO_EXTERNAL_DEPS="1" nmake /nologo -f signzone.mak CFG="signzone - Win32 Release" NO_EXTERNAL_DEPS="1" -copy ..\*.html ..\..\..\Build\Release +rem copy ..\*.html ..\..\..\Build\Release +copy ..\dnssec-keygen.html ..\..\..\Build\Release +copy ..\dnssec-signzone.html ..\..\..\Build\Release cd ..\.. rem This is the BIND 9 Installer @@ -121,6 +123,9 @@ cd .. cd win32utils +copy ..\doc\misc\migration ..\Build\Release +copy ..\doc\misc\migration-4to9 ..\Build\Release + echo Done. rem exit here. diff --git a/dist/bind/win32utils/readme1st.txt b/dist/bind/win32utils/readme1st.txt index 1155ad239dc..b945555a7cf 100644 --- a/dist/bind/win32utils/readme1st.txt +++ b/dist/bind/win32utils/readme1st.txt @@ -2,15 +2,38 @@ Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") Copyright (C) 2001, 2003 Internet Software Consortium. See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. -Id: readme1st.txt,v 1.7.2.4.4.1 2004/03/06 13:16:25 marka Exp +Id: readme1st.txt,v 1.7.2.4.4.2 2004/08/19 05:10:41 marka Exp - Release of BIND 9.2.2 for Window NT/2000 + Release of BIND 9.3 for Window NT/2000/XP/2003 -This is a maintenance release of BIND 9.2 for Window NT/2000. Only -IPv4 stacks are supported on the box running this version of BIND. +This is a release of BIND 9.3 for Window NT/2000/XP/2003. +Only IPv4 stacks are supported on the box running this version of BIND. IPv6 stacks will be supported in a future release. - Kit Installation Information + Important Kit Installation Information + +As of release 9.3.0, BINDInstall requires that you install +it under an account with restricted privileges. The installer +will prompt you for an account name, the default is "named", and +a password for that account. It will also check for the existence +of that account. If it does not exist is will create it with only +the privileges required to run BIND. If the account does exist it +will check that it has only the one privilege required: +"Log on as a service". If it has too many privileges it will prompt +you if you want to continue. + +With BIND running under an account name it is necessary for all +files and directories that BIND uses to have permissions set up +for the named account if the files are on an NTFS disk. BIND requires +that the account have read and write access to the directory for +the pid file, any files that are maintained either for slave zones +or for master zones supporting dynamic updates. The account will +also need read access to the named.conf and any other file that +it needs to read. + +It is important that on Windows the directory directive is used in +the options section to tell BIND where to find the files used in +named.conf. If you have previously installed BIND 8 or BIND 4 on the system that you wish to install this kit, you MUST use the BIND 8 or BIND 4 installer @@ -23,6 +46,8 @@ Unpack the kit into any convenient directory and run the BINDInstall program. This will install the named and associated programs into the correct directories and set up the required registry keys. +Messages are logged to the Application log in the EventViewer. + Controlling BIND Windows NT/2000 uses the same rndc program as is used on Unix @@ -64,6 +89,13 @@ the servers you wish to control, specifically the IP address and key in both named.conf and rndc.conf. Again see section 3.4.1.2 of the ARM for details. +In order to you rndc from a different system it is important to +ensure that the clocks are synchronized. The clocks must be kept +within 5 minutes of each other or the rndc commands will fail +authentication. Use NTP or other time synchronization software +to keep your clocks accurate. NTP can be found at +http://www.ntp.org/. + In addition BIND is installed as a win32 system service, can be started and stopped in the same way as any other service and automatically starts whenever the system is booted. Signals are @@ -72,7 +104,7 @@ not supported and are in fact ignored. Note: Unlike most Windows applications, named does not, change its working directory when started as a service. If you wish to use relative files in named.conf you will need to specify a working -directory. +directory using the directory directive options. Documentation @@ -92,10 +124,17 @@ Win9x, only WinNT and Win2000. The latter tools are for use with DNSSEC. All tools are installed in the dns/bin directory. IMPORTANT NOTE ON USING THE TOOLS: -If you wish to use nsupdate on a win32 platform to do dynamic updates -to a zone you MUST create a resolv.conf in the System32\Drivers\etc -directory containing a list of nameserver addresses to use to find -the nameserver authoritative for the zone. The format of this file is: + +It is no longer necessary to create a resolv.conf file on Windows as +the tools will look in the registry for the required nameserver +information. However if you wish to create a resolv.conf file as +follows it will use it in preference to the registry nameserver +entries. + +To create a resolv.conf you need to place it in the System32\Drivers\etc +directory and it needs to contain a list of nameserver addresses to +use to find the nameserver authoritative for the zone. The format of +this file is: nameserver 1.2.3.4 nameserver 5.6.7.8 @@ -103,14 +142,6 @@ nameserver 5.6.7.8 Replace the IP addresses with your real addresses. 127.0.0.1 is a valid address if you are running a nameserver on the localhost. -In addition, if you use dig, host or nslookup, you will need this -file on the system where you are running these tools unless you have -BIND running on that system. - -This will be fixed in a future release. - -Messages are logged to the Application log in the EventViewer. - Problems Please report all problems to bind9-bugs@isc.org and not to me. All @@ -118,5 +149,5 @@ other questions should go to the bind-users@isc.org mailing list or the comp.protocol.dns.bind news group. Danny Mayer - danny.mayer@nominum.com + mayer@ntp.isc.org |
