From 4f7eea47db70acf8fe34a311a1387759f79a0cdc Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 9 Dec 2004 01:56:46 +0000 Subject: [PATCH 001/130] 1790. [cleanup] Move lib/dns/sec/dst up into lib/dns. This should allow parallel make to succeed. --- lib/dns/sec/.cvsignore | 1 - lib/dns/sec/Makefile.in | 25 ------------------------- 2 files changed, 26 deletions(-) delete mode 100644 lib/dns/sec/.cvsignore delete mode 100644 lib/dns/sec/Makefile.in diff --git a/lib/dns/sec/.cvsignore b/lib/dns/sec/.cvsignore deleted file mode 100644 index f3c7a7c5da..0000000000 --- a/lib/dns/sec/.cvsignore +++ /dev/null @@ -1 +0,0 @@ -Makefile diff --git a/lib/dns/sec/Makefile.in b/lib/dns/sec/Makefile.in deleted file mode 100644 index 348956214c..0000000000 --- a/lib/dns/sec/Makefile.in +++ /dev/null @@ -1,25 +0,0 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -# Copyright (C) 1998-2001 Internet Software Consortium. -# -# Permission to use, copy, modify, and distribute this software for any -# purpose with or without fee is hereby granted, provided that the above -# copyright notice and this permission notice appear in all copies. -# -# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH -# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY -# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, -# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM -# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE -# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR -# PERFORMANCE OF THIS SOFTWARE. - -# $Id: Makefile.in,v 1.12 2004/03/05 05:10:27 marka Exp $ - -srcdir = @srcdir@ -VPATH = @srcdir@ -top_srcdir = @top_srcdir@ - -SUBDIRS = dst -TARGETS = - -@BIND9_MAKE_RULES@ From 910041ee93d7556b7ea636bf436da2156d522ed4 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 9 Dec 2004 02:16:28 +0000 Subject: [PATCH 002/130] regen --- configure | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 375b07cf8a..3c3849a866 100755 --- a/configure +++ b/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.356 2004/12/09 01:40:42 marka Exp $ +# $Id: configure,v 1.357 2004/12/09 02:16:28 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.370 . +# From configure.in Revision: 1.371 . # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.59. # From 12b1e10c52a6c36c49b7fc12f3f5a8a8b6495a51 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 9 Dec 2004 23:50:18 +0000 Subject: [PATCH 003/130] newcopyrights --- util/copyrights | 1 + 1 file changed, 1 insertion(+) diff --git a/util/copyrights b/util/copyrights index 9d1054e886..03456122b6 100644 --- a/util/copyrights +++ b/util/copyrights @@ -1620,6 +1620,7 @@ ./lib/dns/dst_lib.c C 1999,2000,2001,2004 ./lib/dns/dst_openssl.h C 2002,2004 ./lib/dns/dst_parse.c C.NAI 1999,2000,2001,2002,2004 +./lib/dns/dst_parse.h C 2004 ./lib/dns/dst_result.c C 1999,2000,2001,2004 ./lib/dns/forward.c C 2000,2001,2004 ./lib/dns/gen-unix.h C 1999,2000,2001,2004 From 9b4a030a309b81fec50275b8708fd678a09411ef Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 10 Dec 2004 00:12:27 +0000 Subject: [PATCH 004/130] need to link against libdns. --- lib/bind9/Makefile.in | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lib/bind9/Makefile.in b/lib/bind9/Makefile.in index 043658875f..9c3b2461da 100644 --- a/lib/bind9/Makefile.in +++ b/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.8 2004/12/08 13:18:52 marka Exp $ +# $Id: Makefile.in,v 1.9 2004/12/10 00:12:27 marka Exp $ srcdir = @srcdir@ VPATH = @srcdir@ @@ -33,9 +33,11 @@ CWARNINGS = ISCLIBS = ../../lib/isc/libisc.@A@ ISCCFGLIBS = ../../lib/isccfg/libisccfg.@A@ +DNSLIBS = ../../lib/dns/libdns.@A@ ISCDEPLIBS = ../../lib/isc/libisc.@A@ ISCCFGDEPLIBS = ../../lib/isccfg/libisccfg.@A@ +DNSDEPLIBS = ../../lib/dns/libdns.@A@ LIBS = @LIBS@ @@ -63,11 +65,11 @@ libbind9.@SA@: ${OBJS} ${AR} ${ARFLAGS} $@ ${OBJS} ${RANLIB} $@ -libbind9.la: ${OBJS} ${ISCCFGDEPLIBS} ${ISCDEPLIBS} +libbind9.la: ${OBJS} ${ISCCFGDEPLIBS} ${ISCDEPLIBS} ${DNSDEPLIBS} ${LIBTOOL_MODE_LINK} \ ${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libbind9.la -rpath ${libdir} \ -version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \ - ${OBJS} ${ISCCFGLIBS} ${ISCLIBS} ${LIBS} + ${OBJS} ${DNSLIBS} ${ISCCFGLIBS} ${ISCLIBS} ${LIBS} timestamp: libbind9.@A@ touch timestamp From a4c9fece80ebadb00022e2543c5be29e2adbf106 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 10 Dec 2004 03:46:07 +0000 Subject: [PATCH 005/130] dst_parse.h --- util/copyrights | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/util/copyrights b/util/copyrights index 03456122b6..9754f9c47e 100644 --- a/util/copyrights +++ b/util/copyrights @@ -1614,13 +1614,12 @@ ./lib/dns/dispatch.c C 1999,2000,2001,2002,2003,2004 ./lib/dns/dnssec.c C 1999,2000,2001,2002,2003,2004 ./lib/dns/ds.c C 2002,2003,2004 -./lib/dns/dst/dst_parse.h C.NAI 2000,2001,2002,2004 ./lib/dns/dst_api.c C.NAI 1999,2000,2001,2002,2003,2004 ./lib/dns/dst_internal.h C.NAI 2000,2001,2002,2004 ./lib/dns/dst_lib.c C 1999,2000,2001,2004 ./lib/dns/dst_openssl.h C 2002,2004 ./lib/dns/dst_parse.c C.NAI 1999,2000,2001,2002,2004 -./lib/dns/dst_parse.h C 2004 +./lib/dns/dst_parse.h C.NAI 2000,2001,2002,2004 ./lib/dns/dst_result.c C 1999,2000,2001,2004 ./lib/dns/forward.c C 2000,2001,2004 ./lib/dns/gen-unix.h C 1999,2000,2001,2004 From c85ffa76df4b94e0c44b2924f7a7f2e875a1ea86 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 13 Dec 2004 02:06:53 +0000 Subject: [PATCH 006/130] Fix files which should be using DOS style newlines --- util/kit.sh | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/util/kit.sh b/util/kit.sh index 29a32387b9..ea12ff86d4 100644 --- a/util/kit.sh +++ b/util/kit.sh @@ -15,7 +15,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: kit.sh,v 1.28 2004/06/03 02:45:03 marka Exp $ +# $Id: kit.sh,v 1.29 2004/12/13 02:06:53 marka Exp $ # Make a release kit # @@ -126,6 +126,17 @@ chmod +x configure install-sh mkinstalldirs \ lib/bind/configure lib/bind/mkinstalldirs \ bin/tests/system/ifconfig.sh +# Fix files which should be using DOS style newlines +windirs=`find lib bin -type d -name win32` +windirs="$windirs win32utils" +winnames="-name *.mak -or -name *.dsp -or -name *.dsw -or -name *.txt -or -name *.bat" +for f in `find $windirs -type f \( $winnames \) -print` +do + awk '{sub("\r$", "", $0); printf("%s\r\n", $0);}' < $f > tmp + touch -r $f tmp + mv tmp $f +done + cd .. || exit 1 kit=$topdir.tar.gz From 3002b5952de09eee4282ad72981e46dfecc5df61 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 14 Dec 2004 01:02:50 +0000 Subject: [PATCH 007/130] cleanup a couple more files --- bin/tests/system/dnssec/clean.sh | 3 ++- bin/tests/system/xferquota/clean.sh | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/bin/tests/system/dnssec/clean.sh b/bin/tests/system/dnssec/clean.sh index 90e17cbcc5..1264cb9956 100644 --- a/bin/tests/system/dnssec/clean.sh +++ b/bin/tests/system/dnssec/clean.sh @@ -15,12 +15,13 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: clean.sh,v 1.16 2004/09/07 04:14:44 marka Exp $ +# $Id: clean.sh,v 1.17 2004/12/14 01:02:49 marka Exp $ rm -f */K* */keyset-* */dsset-* */dlvset-* */signedkey-* */*.signed */trusted.conf */tmp* rm -f ns1/root.db ns2/example.db ns3/secure.example.db rm -f ns3/unsecure.example.db ns3/bogus.example.db ns3/keyless.example.db rm -f ns3/dynamic.example.db ns3/dynamic.example.db.signed.jnl +rm -f ns2/private.secure.example.db rm -f */example.bk rm -f dig.out.* rm -f random.data diff --git a/bin/tests/system/xferquota/clean.sh b/bin/tests/system/xferquota/clean.sh index 4d72856f7d..52bfbc5659 100644 --- a/bin/tests/system/xferquota/clean.sh +++ b/bin/tests/system/xferquota/clean.sh @@ -15,7 +15,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: clean.sh,v 1.10 2004/03/10 01:06:06 marka Exp $ +# $Id: clean.sh,v 1.11 2004/12/14 01:02:50 marka Exp $ # # Clean up after zone transfer quota tests. @@ -24,3 +24,4 @@ rm -f ns1/zone*.example.db ns1/zones.conf rm -f ns2/zone*.example.bk ns2/zones.conf rm -f dig.out.* ns2/changing.bk +rm -f ns1/changing.db From c04f4437ff8b2aba326e5099eae0cacb7de6f74b Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 14 Dec 2004 03:44:24 +0000 Subject: [PATCH 008/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 8388515f37..129e977aab 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1791. [placeholder] rt13230 + 1790. [cleanup] Move lib/dns/sec/dst up into lib/dns. This should allow parallel make to succeed. From 0e93730a02a4cafbc5cdfaa04b2d813a0c11b205 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 14 Dec 2004 06:06:20 +0000 Subject: [PATCH 009/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 129e977aab..1d2f9e1ae0 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1792. [placeholder] rt13124 + 1791. [placeholder] rt13230 1790. [cleanup] Move lib/dns/sec/dst up into lib/dns. This should From d0eb2cc33c5db3366a16b1cb0abcca6ec7c8ee3c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tatuya=20JINMEI=20=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= Date: Tue, 21 Dec 2004 10:45:20 +0000 Subject: [PATCH 010/130] 1526. [func] Implemented "additional section caching (or acache)", an internal cache framework for additional section content to improve response performance. Several configuration options were provided to control the behavior. --- CHANGES | 6 +- bin/named/config.c | 5 +- bin/named/include/named/server.h | 5 +- bin/named/query.c | 672 ++++++++++++- bin/named/server.c | 53 +- doc/arm/Bv9ARM-book.xml | 107 +- lib/dns/Makefile.in | 6 +- lib/dns/acache.c | 1575 ++++++++++++++++++++++++++++++ lib/dns/db.c | 50 +- lib/dns/include/dns/acache.h | 440 +++++++++ lib/dns/include/dns/db.h | 84 +- lib/dns/include/dns/events.h | 6 +- lib/dns/include/dns/log.h | 3 +- lib/dns/include/dns/rdataset.h | 128 ++- lib/dns/include/dns/types.h | 4 +- lib/dns/include/dns/view.h | 3 +- lib/dns/include/dns/zone.h | 15 +- lib/dns/log.c | 3 +- lib/dns/ncache.c | 5 +- lib/dns/rbtdb.c | 533 +++++++++- lib/dns/rdatalist.c | 7 +- lib/dns/rdataset.c | 83 +- lib/dns/rdataslab.c | 5 +- lib/dns/sdb.c | 13 +- lib/dns/view.c | 8 +- lib/dns/zone.c | 73 +- lib/isccfg/namedconf.c | 5 +- 27 files changed, 3802 insertions(+), 95 deletions(-) create mode 100644 lib/dns/acache.c create mode 100644 lib/dns/include/dns/acache.h diff --git a/CHANGES b/CHANGES index 1d2f9e1ae0..446d4a87f8 100644 --- a/CHANGES +++ b/CHANGES @@ -770,7 +770,11 @@ 1527. [cleanup] Reduce the number of gettimeofday() calls without losing necessary timer granularity. -1526. [placeholder] +1526. [func] Implemented "additional section caching (or acache)", + an internal cache framework for additional section + content to improve response performance. Several + configuration options were provided to control the + behavior. 1525. [bug] dns_cache_create() could trigger a REQUIRE failure in isc_mem_put() during error cleanup. diff --git a/bin/named/config.c b/bin/named/config.c index 10739e777b..1965758be0 100644 --- a/bin/named/config.c +++ b/bin/named/config.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: config.c,v 1.51 2004/10/05 02:47:50 marka Exp $ */ +/* $Id: config.c,v 1.52 2004/12/21 10:45:15 jinmei Exp $ */ #include @@ -125,6 +125,9 @@ options {\n\ check-names master fail;\n\ check-names slave warn;\n\ check-names response ignore;\n\ + use-additional-cache true;\n\ + acache-cleaning-interval 60;\n\ + max-acache-size 0;\n\ dnssec-enable no; /* Make yes for 9.4. */ \n\ " diff --git a/bin/named/include/named/server.h b/bin/named/include/named/server.h index 2aafc9cccc..e50f9ab354 100644 --- a/bin/named/include/named/server.h +++ b/bin/named/include/named/server.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.h,v 1.75 2004/10/11 05:30:19 marka Exp $ */ +/* $Id: server.h,v 1.76 2004/12/21 10:45:15 jinmei Exp $ */ #ifndef NAMED_SERVER_H #define NAMED_SERVER_H 1 @@ -94,7 +94,8 @@ struct ns_server { ns_controls_t * controls; /* Control channels */ unsigned int dispatchgen; ns_dispatchlist_t dispatches; - + + dns_acache_t *acache; }; #define NS_SERVER_MAGIC ISC_MAGIC('S','V','E','R') diff --git a/bin/named/query.c b/bin/named/query.c index 907fac3556..62f9ffacea 100644 --- a/bin/named/query.c +++ b/bin/named/query.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: query.c,v 1.261 2004/06/30 14:16:06 marka Exp $ */ +/* $Id: query.c,v 1.262 2004/12/21 10:45:15 jinmei Exp $ */ #include @@ -92,6 +92,11 @@ #define DNS_GETDB_NOLOG 0x02U #define DNS_GETDB_PARTIAL 0x04U +typedef struct client_additionalctx { + ns_client_t *client; + dns_rdataset_t *rdataset; +} client_additionalctx_t; + static void query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype); @@ -538,37 +543,18 @@ query_findversion(ns_client_t *client, dns_db_t *db, } static inline isc_result_t -query_getzonedb(ns_client_t *client, dns_name_t *name, dns_rdatatype_t qtype, - unsigned int options, dns_zone_t **zonep, dns_db_t **dbp, - dns_dbversion_t **versionp) +query_validatezonedb(ns_client_t *client, dns_name_t *name, + dns_rdatatype_t qtype, unsigned int options, + dns_zone_t *zone, dns_db_t *db, + dns_dbversion_t **versionp) { isc_result_t result; isc_boolean_t check_acl, new_zone; dns_acl_t *queryacl; ns_dbversion_t *dbversion; - unsigned int ztoptions; - dns_zone_t *zone = NULL; - dns_db_t *db = NULL; - isc_boolean_t partial = ISC_FALSE; - REQUIRE(zonep != NULL && *zonep == NULL); - REQUIRE(dbp != NULL && *dbp == NULL); - - /* - * Find a zone database to answer the query. - */ - ztoptions = ((options & DNS_GETDB_NOEXACT) != 0) ? - DNS_ZTFIND_NOEXACT : 0; - - result = dns_zt_find(client->view->zonetable, name, ztoptions, NULL, - &zone); - if (result == DNS_R_PARTIALMATCH) - partial = ISC_TRUE; - if (result == ISC_R_SUCCESS || result == DNS_R_PARTIALMATCH) - result = dns_zone_getdb(zone, &db); - - if (result != ISC_R_SUCCESS) - goto fail; + REQUIRE(zone != NULL); + REQUIRE(db != NULL); /* * This limits our searching to the zone where the first name @@ -689,17 +675,63 @@ query_getzonedb(ns_client_t *client, dns_name_t *name, dns_rdatatype_t qtype, */ dbversion->queryok = ISC_TRUE; + /* Transfer ownership, if necessary. */ + if (versionp != NULL) + *versionp = dbversion->version; + + return (ISC_R_SUCCESS); + + refuse: + return (DNS_R_REFUSED); + + fail: + return (result); +} + +static inline isc_result_t +query_getzonedb(ns_client_t *client, dns_name_t *name, dns_rdatatype_t qtype, + unsigned int options, dns_zone_t **zonep, dns_db_t **dbp, + dns_dbversion_t **versionp) +{ + isc_result_t result; + unsigned int ztoptions; + dns_zone_t *zone = NULL; + dns_db_t *db = NULL; + isc_boolean_t partial = ISC_FALSE; + + REQUIRE(zonep != NULL && *zonep == NULL); + REQUIRE(dbp != NULL && *dbp == NULL); + + /* + * Find a zone database to answer the query. + */ + ztoptions = ((options & DNS_GETDB_NOEXACT) != 0) ? + DNS_ZTFIND_NOEXACT : 0; + + result = dns_zt_find(client->view->zonetable, name, ztoptions, NULL, + &zone); + if (result == DNS_R_PARTIALMATCH) + partial = ISC_TRUE; + if (result == ISC_R_SUCCESS || result == DNS_R_PARTIALMATCH) + result = dns_zone_getdb(zone, &db); + + if (result != ISC_R_SUCCESS) + goto fail; + + result = query_validatezonedb(client, name, qtype, options, zone, db, + versionp); + + if (result != ISC_R_SUCCESS) + goto fail; + /* Transfer ownership. */ *zonep = zone; *dbp = db; - *versionp = dbversion->version; if (partial && (options & DNS_GETDB_PARTIAL) != 0) return (DNS_R_PARTIALMATCH); return (ISC_R_SUCCESS); - refuse: - result = DNS_R_REFUSED; fail: if (zone != NULL) dns_zone_detach(&zone); @@ -1237,11 +1269,516 @@ query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) { return (eresult); } +static inline void +query_discardcache(ns_client_t *client, dns_rdataset_t *rdataset_base, + dns_rdatasetadditional_t additionaltype, + dns_rdatatype_t type, dns_zone_t **zonep, dns_db_t **dbp, + dns_dbversion_t **versionp, dns_dbnode_t **nodep, + dns_name_t *fname) +{ + dns_rdataset_t *rdataset; + + while ((rdataset = ISC_LIST_HEAD(fname->list)) != NULL) { + ISC_LIST_UNLINK(fname->list, rdataset, link); + query_putrdataset(client, &rdataset); + } + if (*versionp != NULL) + dns_db_closeversion(*dbp, versionp, ISC_FALSE); + if (*nodep != NULL) + dns_db_detachnode(*dbp, nodep); + if (*dbp != NULL) + dns_db_detach(dbp); + if (*zonep != NULL) + dns_zone_detach(zonep); + (void)dns_rdataset_putadditional(client->view->acache, rdataset_base, + additionaltype, type); +} + +static inline isc_result_t +query_iscachevalid(dns_zone_t *zone, dns_db_t *db, dns_db_t *db0, + dns_dbversion_t *version) +{ + isc_result_t result = ISC_R_SUCCESS; + dns_dbversion_t *version_current = NULL; + dns_db_t *db_current = db0; + + if (db_current == NULL) { + result = dns_zone_getdb(zone, &db_current); + if (result != ISC_R_SUCCESS) + return (result); + } + dns_db_currentversion(db_current, &version_current); + if (db_current != db || version_current != version) { + result = ISC_R_FAILURE; + goto cleanup; + } + + cleanup: + dns_db_closeversion(db_current, &version_current, ISC_FALSE); + if (db0 == NULL && db_current != NULL) + dns_db_detach(&db_current); + + return (result); +} + +static isc_result_t +query_addadditional2(void *arg, dns_name_t *name, dns_rdatatype_t qtype) { + client_additionalctx_t *additionalctx = arg; + dns_rdataset_t *rdataset_base; + ns_client_t *client; + isc_result_t result, eresult; + dns_dbnode_t *node, *cnode; + dns_db_t *db, *cdb; + dns_name_t *fname, *mname0, cfname; + dns_rdataset_t *rdataset, *sigrdataset; + dns_rdataset_t *crdataset, *crdataset_next; + isc_buffer_t *dbuf; + isc_buffer_t b; + dns_dbversion_t *version, *cversion; + isc_boolean_t added_something, need_addname, needadditionalcache; + isc_boolean_t need_sigrrset; + dns_zone_t *zone; + dns_rdatatype_t type; + dns_rdatasetadditional_t additionaltype; + + if (qtype != dns_rdatatype_a) { + /* + * This function is optimized for "address" types. For other + * types, use a generic routine. + * XXX: ideally, this function should be generic enough. + */ + return (query_addadditional(additionalctx->client, + name, qtype)); + } + + /* + * Initialization. + */ + rdataset_base = additionalctx->rdataset; + client = additionalctx->client; + REQUIRE(NS_CLIENT_VALID(client)); + eresult = ISC_R_SUCCESS; + fname = NULL; + rdataset = NULL; + sigrdataset = NULL; + db = NULL; + cdb = NULL; + version = NULL; + cversion = NULL; + node = NULL; + cnode = NULL; + added_something = ISC_FALSE; + need_addname = ISC_FALSE; + zone = NULL; + needadditionalcache = ISC_FALSE; + additionaltype = dns_rdatasetadditional_fromauth; + dns_name_init(&cfname, NULL); + + CTRACE("query_addadditional2"); + + /* + * We treat type A additional section processing as if it + * were "any address type" additional section processing. + * To avoid multiple lookups, we do an 'any' database + * lookup and iterate over the node. + * XXXJT: this approach can cause a suboptimal result when the cache + * DB only has partial address types and the glue DB has remaining + * ones. + */ + type = dns_rdatatype_any; + + /* + * Get some resources. + */ + dbuf = query_getnamebuf(client); + if (dbuf == NULL) + goto cleanup; + fname = query_newname(client, dbuf, &b); + if (fname == NULL) + goto cleanup; + dns_name_setbuffer(&cfname, &b); /* share the buffer */ + + /* Check additional cache */ + result = dns_rdataset_getadditional(rdataset_base, additionaltype, + type, client->view->acache, &zone, + &cdb, &cversion, &cnode, &cfname, + client->message, client->now); + if (result != ISC_R_SUCCESS) + goto findauthdb; + if (zone == NULL) { + CTRACE("query_addadditional2: auth zone not found"); + goto try_cache; + } + + /* Is the cached DB up-to-date? */ + result = query_iscachevalid(zone, cdb, NULL, cversion); + if (result != ISC_R_SUCCESS) { + CTRACE("query_addadditional2: old auth additional cache"); + query_discardcache(client, rdataset_base, additionaltype, + type, &zone, &cdb, &cversion, &cnode, + &cfname); + goto findauthdb; + } + + if (cnode == NULL) { + /* + * We have a negative cache. We don't have to check the zone + * ACL, since the result (not using this zone) would be same + * regardless of the result. + */ + CTRACE("query_addadditional2: negative auth additional cache"); + dns_db_closeversion(cdb, &cversion, ISC_FALSE); + dns_db_detach(&cdb); + dns_zone_detach(&zone); + goto try_cache; + } + + result = query_validatezonedb(client, name, qtype, DNS_GETDB_NOLOG, + zone, cdb, NULL); + if (result != ISC_R_SUCCESS) { + query_discardcache(client, rdataset_base, additionaltype, + type, &zone, &cdb, &cversion, &cnode, + &cfname); + goto try_cache; + } + + /* We've got an active cache. */ + CTRACE("query_addadditional2: auth additional cache"); + dns_db_closeversion(cdb, &cversion, ISC_FALSE); + db = cdb; + node = cnode; + dns_name_clone(&cfname, fname); + query_keepname(client, fname, dbuf); + goto foundcache; + + /* + * Look for a zone database that might contain authoritative + * additional data. + */ + findauthdb: + result = query_getzonedb(client, name, qtype, DNS_GETDB_NOLOG, + &zone, &db, &version); + if (result != ISC_R_SUCCESS) { + /* Cache the negative result */ + (void)dns_rdataset_setadditional(rdataset_base, additionaltype, + type, client->view->acache, + NULL, NULL, NULL, NULL, + NULL); + goto try_cache; + } + + CTRACE("query_addadditional2: db_find"); + + /* + * Since we are looking for authoritative data, we do not set + * the GLUEOK flag. Glue will be looked for later, but not + * necessarily in the same database. + */ + node = NULL; + result = dns_db_find(db, name, version, type, client->query.dboptions, + client->now, &node, fname, NULL, NULL); + if (result == ISC_R_SUCCESS) + goto found; + + /* Cache the negative result */ + (void)dns_rdataset_setadditional(rdataset_base, additionaltype, + type, client->view->acache, zone, db, + version, NULL, fname); + + if (node != NULL) + dns_db_detachnode(db, &node); + version = NULL; + dns_db_detach(&db); + + /* + * No authoritative data was found. The cache is our next best bet. + */ + + try_cache: + additionaltype = dns_rdatasetadditional_fromcache; + result = query_getcachedb(client, name, qtype, &db, DNS_GETDB_NOLOG); + if (result != ISC_R_SUCCESS) + /* + * Most likely the client isn't allowed to query the cache. + */ + goto try_glue; + + result = dns_db_find(db, name, version, type, client->query.dboptions, + client->now, &node, fname, NULL, NULL); + if (result == ISC_R_SUCCESS) + goto found; + + if (node != NULL) + dns_db_detachnode(db, &node); + dns_db_detach(&db); + + try_glue: + /* + * No cached data was found. Glue is our last chance. + * RFC1035 sayeth: + * + * NS records cause both the usual additional section + * processing to locate a type A record, and, when used + * in a referral, a special search of the zone in which + * they reside for glue information. + * + * This is the "special search". Note that we must search + * the zone where the NS record resides, not the zone it + * points to, and that we only do the search in the delegation + * case (identified by client->query.gluedb being set). + */ + if (client->query.gluedb == NULL) + goto cleanup; + + /* + * Don't poision caches using the bailiwick protection model. + */ + if (!dns_name_issubdomain(name, dns_db_origin(client->query.gluedb))) + goto cleanup; + + /* Check additional cache */ + additionaltype = dns_rdatasetadditional_fromglue; + result = dns_rdataset_getadditional(rdataset_base, additionaltype, + type, client->view->acache, NULL, + &cdb, &cversion, &cnode, &cfname, + client->message, client->now); + if (result != ISC_R_SUCCESS) + goto findglue; + + result = query_iscachevalid(zone, cdb, client->query.gluedb, cversion); + if (result != ISC_R_SUCCESS) { + CTRACE("query_addadditional2: old glue additional cache"); + query_discardcache(client, rdataset_base, additionaltype, + type, &zone, &cdb, &cversion, &cnode, + &cfname); + goto findglue; + } + + if (cnode == NULL) { + /* We have a negative cache. */ + CTRACE("query_addadditional2: negative glue additional cache"); + dns_db_closeversion(cdb, &cversion, ISC_FALSE); + dns_db_detach(&cdb); + goto cleanup; + } + + /* Cache hit. */ + CTRACE("query_addadditional2: glue additional cache"); + dns_db_closeversion(cdb, &cversion, ISC_FALSE); + db = cdb; + node = cnode; + dns_name_clone(&cfname, fname); + query_keepname(client, fname, dbuf); + goto foundcache; + + findglue: + dns_db_attach(client->query.gluedb, &db); + result = dns_db_find(db, name, version, type, + client->query.dboptions | DNS_DBFIND_GLUEOK, + client->now, &node, fname, NULL, NULL); + if (!(result == ISC_R_SUCCESS || + result == DNS_R_ZONECUT || + result == DNS_R_GLUE)) { + /* cache the negative result */ + (void)dns_rdataset_setadditional(rdataset_base, additionaltype, + type, client->view->acache, + NULL, db, version, NULL, + fname); + goto cleanup; + } + + found: + /* + * We have found a DB node to iterate over from a DB. + * We are going to look for address RRsets (i.e., A and AAAA) in the DB + * node we've just found. We'll then store the complete information + * in the additional data cache. + */ + dns_name_clone(fname, &cfname); + query_keepname(client, fname, dbuf); + needadditionalcache = ISC_TRUE; + + rdataset = query_newrdataset(client); + if (rdataset == NULL) + goto cleanup; + if (WANTDNSSEC(client)) { + sigrdataset = query_newrdataset(client); + if (sigrdataset == NULL) + goto cleanup; + } + + /* + * Find A RRset with sig RRset. Even if we don't find a sig RRset + * for a client using DNSSEC, we'll continue the process to make a + * complete list to be cached. However, we need to cancel the + * caching when something unexpected happens, in order to avoid + * caching incomplete information. + */ + result = dns_db_findrdataset(db, node, version, dns_rdatatype_a, 0, + client->now, rdataset, sigrdataset); + if (result == DNS_R_NCACHENXDOMAIN) + goto setcache; + if (result == DNS_R_NCACHENXRRSET) { + dns_rdataset_disassociate(rdataset); + /* + * Negative cache entries don't have sigrdatasets. + */ + INSIST(sigrdataset == NULL || + ! dns_rdataset_isassociated(sigrdataset)); + } + if (result == ISC_R_SUCCESS) { + /* Remember the result as a cache */ + ISC_LIST_APPEND(cfname.list, rdataset, link); + if (sigrdataset != NULL && + dns_rdataset_isassociated(sigrdataset)) { + ISC_LIST_APPEND(cfname.list, sigrdataset, + link); + sigrdataset = + query_newrdataset(client); + if (sigrdataset == NULL) + needadditionalcache = ISC_FALSE; + } + rdataset = query_newrdataset(client); + if (rdataset == NULL) { + /* do not cache incomplete information */ + goto foundcache; + } + } + + /* Find AAAA RRset with sig RRset */ + result = dns_db_findrdataset(db, node, version, + dns_rdatatype_aaaa, 0, + client->now, rdataset, + sigrdataset); + /* The NXDOMAIN case should be covered above */ + INSIST(result != DNS_R_NCACHENXDOMAIN); + if (result == DNS_R_NCACHENXRRSET) { + dns_rdataset_disassociate(rdataset); + /* + * Negative cache entries don't have sigrdatasets. + */ + INSIST(sigrdataset == NULL || + ! dns_rdataset_isassociated(sigrdataset)); + } + if (result == ISC_R_SUCCESS) { + ISC_LIST_APPEND(cfname.list, rdataset, link); + rdataset = NULL; + if (sigrdataset != NULL && + dns_rdataset_isassociated(sigrdataset)) { + ISC_LIST_APPEND(cfname.list, sigrdataset, + link); + sigrdataset = NULL; + } + } + + setcache: + /* + * Set the new result in the cache if required. We do not support + * caching additional data from a cache DB. + */ + if (needadditionalcache == ISC_TRUE && + (additionaltype == dns_rdatasetadditional_fromauth || + additionaltype == dns_rdatasetadditional_fromglue)) { + (void)dns_rdataset_setadditional(rdataset_base, additionaltype, + type, client->view->acache, + zone, db, version, node, + &cfname); + } + + foundcache: + need_sigrrset = ISC_FALSE; + mname0 = NULL; + for (crdataset = ISC_LIST_HEAD(cfname.list); + crdataset != NULL; + crdataset = crdataset_next) { + dns_name_t *mname; + + crdataset_next = ISC_LIST_NEXT(crdataset, link); + + mname = NULL; + if (crdataset->type == dns_rdatatype_a || + crdataset->type == dns_rdatatype_aaaa) { + if (!query_isduplicate(client, fname, crdataset->type, + &mname)) { + if (mname != NULL) { + /* + * A different type of this name is + * already stored in the additional + * section. We'll reuse the name. + * Note that this should happen at most + * once. Otherwise, fname->link could + * leak below. + */ + INSIST(mname0 == NULL); + + query_releasename(client, &fname); + fname = mname; + mname0 = mname; + } else + need_addname = ISC_TRUE; + ISC_LIST_UNLINK(cfname.list, crdataset, link); + ISC_LIST_APPEND(fname->list, crdataset, link); + added_something = ISC_TRUE; + need_sigrrset = ISC_TRUE; + } else + need_sigrrset = ISC_FALSE; + } else if (crdataset->type == dns_rdatatype_sig && + need_sigrrset && WANTDNSSEC(client)) { + ISC_LIST_UNLINK(cfname.list, crdataset, link); + ISC_LIST_APPEND(fname->list, crdataset, link); + added_something = ISC_TRUE; /* just in case */ + need_sigrrset = ISC_FALSE; + } + } + + CTRACE("query_addadditional2: addname"); + + /* + * If we haven't added anything, then we're done. + */ + if (!added_something) + goto cleanup; + + /* + * We may have added our rdatasets to an existing name, if so, then + * need_addname will be ISC_FALSE. Whether we used an existing name + * or a new one, we must set fname to NULL to prevent cleanup. + */ + if (need_addname) + dns_message_addname(client->message, fname, + DNS_SECTION_ADDITIONAL); + fname = NULL; + + cleanup: + CTRACE("query_addadditional2: cleanup"); + + if (rdataset != NULL) + query_putrdataset(client, &rdataset); + if (sigrdataset != NULL) + query_putrdataset(client, &sigrdataset); + while ((crdataset = ISC_LIST_HEAD(cfname.list)) != NULL) { + ISC_LIST_UNLINK(cfname.list, crdataset, link); + query_putrdataset(client, &crdataset); + } + if (fname != NULL) + query_releasename(client, &fname); + if (node != NULL) + dns_db_detachnode(db, &node); + if (db != NULL) + dns_db_detach(&db); + if (zone != NULL) + dns_zone_detach(&zone); + + CTRACE("query_addadditional2: done"); + return (eresult); +} + static inline void query_addrdataset(ns_client_t *client, dns_name_t *fname, dns_rdataset_t *rdataset) { dns_rdatatype_t type = rdataset->type; + client_additionalctx_t additionalctx; /* * Add 'rdataset' and any pertinent additional data to @@ -1264,8 +1801,10 @@ query_addrdataset(ns_client_t *client, dns_name_t *fname, * * We don't care if dns_rdataset_additionaldata() fails. */ - (void)dns_rdataset_additionaldata(rdataset, - query_addadditional, client); + additionalctx.client = client; + additionalctx.rdataset = rdataset; + (void)dns_rdataset_additionaldata(rdataset, query_addadditional2, + &additionalctx); /* * RFC 2535 section 3.5 says that when NS, SOA, A, or AAAA records * are retrieved, any KEY RRs for the owner name should be added @@ -1362,11 +1901,12 @@ query_addrrset(ns_client_t *client, dns_name_t **namep, } static inline isc_result_t -query_addsoa(ns_client_t *client, dns_db_t *db, isc_boolean_t zero_ttl) { - dns_name_t *name, *fname; +query_addsoa(ns_client_t *client, dns_db_t *db, dns_dbversion_t *version, + isc_boolean_t zero_ttl) +{ + dns_name_t *name; dns_dbnode_t *node; isc_result_t result, eresult; - dns_fixedname_t foundname; dns_rdataset_t *rdataset = NULL, *sigrdataset = NULL; dns_rdataset_t **sigrdatasetp = NULL; @@ -1378,8 +1918,6 @@ query_addsoa(ns_client_t *client, dns_db_t *db, isc_boolean_t zero_ttl) { name = NULL; rdataset = NULL; node = NULL; - dns_fixedname_init(&foundname); - fname = dns_fixedname_name(&foundname); /* * Get resources and make 'name' be the database origin. @@ -1405,9 +1943,26 @@ query_addsoa(ns_client_t *client, dns_db_t *db, isc_boolean_t zero_ttl) { /* * Find the SOA. */ - result = dns_db_find(db, name, NULL, dns_rdatatype_soa, - client->query.dboptions, 0, &node, - fname, rdataset, sigrdataset); + result = dns_db_getsoanode(db, &node); + if (result == ISC_R_SUCCESS) { + result = dns_db_findrdataset(db, node, version, + dns_rdatatype_soa, + 0, client->now, rdataset, + sigrdataset); + } else { + dns_fixedname_t foundname; + dns_name_t *fname; + + dns_fixedname_init(&foundname); + fname = dns_fixedname_name(&foundname); + + result = dns_db_find(db, name, version, dns_rdatatype_soa, + client->query.dboptions, 0, &node, + fname, rdataset, sigrdataset); + + if (result == ISC_R_SUCCESS) + (void)dns_db_setsoanode(db, node); + } if (result != ISC_R_SUCCESS) { /* * This is bad. We tried to get the SOA RR at the zone top @@ -1463,7 +2018,7 @@ query_addsoa(ns_client_t *client, dns_db_t *db, isc_boolean_t zero_ttl) { } static inline isc_result_t -query_addns(ns_client_t *client, dns_db_t *db) { +query_addns(ns_client_t *client, dns_db_t *db, dns_dbversion_t *version) { dns_name_t *name, *fname; dns_dbnode_t *node; isc_result_t result, eresult; @@ -1510,13 +2065,25 @@ query_addns(ns_client_t *client, dns_db_t *db) { /* * Find the NS rdataset. */ - CTRACE("query_addns: calling dns_db_find"); - result = dns_db_find(db, name, NULL, dns_rdatatype_ns, - client->query.dboptions, 0, &node, - fname, rdataset, sigrdataset); - CTRACE("query_addns: dns_db_find complete"); + result = dns_db_getnsnode(db, &node); + if (result == ISC_R_SUCCESS) { + result = dns_db_findrdataset(db, node, version, + dns_rdatatype_ns, + 0, client->now, rdataset, + sigrdataset); + } else { + CTRACE("query_addns: calling dns_db_find"); + result = dns_db_find(db, name, NULL, dns_rdatatype_ns, + client->query.dboptions, 0, &node, + fname, rdataset, sigrdataset); + CTRACE("query_addns: dns_db_find complete"); + + if (result == ISC_R_SUCCESS) + (void)dns_db_setnsnode(db, node); + } if (result != ISC_R_SUCCESS) { - CTRACE("query_addns: dns_db_find failed"); + CTRACE("query_addns: " + "dns_db_findrdataset or dns_db_find failed"); /* * This is bad. We tried to get the NS rdataset at the zone * top and it didn't work! @@ -2514,7 +3081,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) if (is_zone) authoritative = ISC_TRUE; - + if (event == NULL && client->query.restarts == 0) { if (is_zone) { dns_zone_attach(zone, &client->query.authzone); @@ -2838,7 +3405,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) /* * Add SOA. */ - result = query_addsoa(client, db, ISC_FALSE); + result = query_addsoa(client, db, version, ISC_FALSE); if (result != ISC_R_SUCCESS) { QUERY_ERROR(result); goto cleanup; @@ -2879,9 +3446,9 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) * resolver and not have it cached. */ if (qtype == dns_rdatatype_soa) - result = query_addsoa(client, db, ISC_TRUE); + result = query_addsoa(client, db, version, ISC_TRUE); else - result = query_addsoa(client, db, ISC_FALSE); + result = query_addsoa(client, db, version, ISC_FALSE); if (result != ISC_R_SUCCESS) { QUERY_ERROR(result); goto cleanup; @@ -3205,7 +3772,8 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) /* * Add SOA. */ - result = query_addsoa(client, db, ISC_FALSE); + result = query_addsoa(client, db, version, + ISC_FALSE); if (result == ISC_R_SUCCESS) result = ISC_R_NOMORE; } else { @@ -3257,7 +3825,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) qtype == dns_rdatatype_any) && dns_name_equal(client->query.qname, dns_db_origin(db)))) - (void)query_addns(client, db); + (void)query_addns(client, db, version); } else if (qtype != dns_rdatatype_ns) { if (fname != NULL) query_releasename(client, &fname); diff --git a/bin/named/server.c b/bin/named/server.c index 513b2e446f..4b22013393 100644 --- a/bin/named/server.c +++ b/bin/named/server.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.c,v 1.433 2004/11/10 22:14:28 marka Exp $ */ +/* $Id: server.c,v 1.434 2004/12/21 10:45:15 jinmei Exp $ */ #include @@ -41,6 +41,7 @@ #include +#include #include #include #include @@ -733,6 +734,7 @@ configure_view(dns_view_t *view, cfg_obj_t *config, cfg_obj_t *vconfig, isc_result_t result; isc_uint32_t max_adb_size; isc_uint32_t max_cache_size; + isc_uint32_t max_acache_size; isc_uint32_t lame_ttl; dns_tsig_keyring_t *ring; dns_view_t *pview = NULL; /* Production view */ @@ -776,6 +778,51 @@ configure_view(dns_view_t *view, cfg_obj_t *config, cfg_obj_t *vconfig, CHECKM(ns_config_getport(config, &port), "port"); dns_view_setdstport(view, port); + /* + * Create additional cache for this view and zones under the view + * unless explicitly disabled. + */ + obj = NULL; + ns_config_get(maps, "use-additional-cache", &obj); + if (obj == NULL || cfg_obj_asboolean(obj)) { + cmctx = NULL; + CHECK(isc_mem_create(0, 0, &cmctx)); + CHECK(dns_acache_create(&view->acache, cmctx, ns_g_taskmgr, + ns_g_timermgr)); + isc_mem_detach(&cmctx); + } + if (view->acache != NULL) { + obj = NULL; + result = ns_config_get(maps, "acache-cleaning-interval", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_acache_setcleaninginterval(view->acache, + cfg_obj_asuint32(obj) * 60); + + obj = NULL; + result = ns_config_get(maps, "max-acache-size", &obj); + INSIST(result == ISC_R_SUCCESS); + if (cfg_obj_isstring(obj)) { + str = cfg_obj_asstring(obj); + INSIST(strcasecmp(str, "unlimited") == 0); + max_acache_size = ISC_UINT32_MAX; + } else { + isc_resourcevalue_t value; + + value = cfg_obj_asuint64(obj); + if (value > ISC_UINT32_MAX) { + cfg_obj_log(obj, ns_g_lctx, ISC_LOG_ERROR, + "'max-acache-size " + "%" ISC_PRINT_QUADFORMAT + "d' is too large", + value); + result = ISC_R_RANGE; + goto cleanup; + } + max_acache_size = (isc_uint32_t)value; + } + dns_acache_setcachesize(view->acache, max_acache_size); + } + /* * Configure the zones. */ @@ -1737,6 +1784,8 @@ configure_zone(cfg_obj_t *config, cfg_obj_t *zconfig, cfg_obj_t *vconfig, * new view. */ dns_zone_setview(zone, view); + if (view->acache != NULL) + dns_zone_setacache(zone, view->acache); } else { /* * We cannot reuse an existing zone, we have @@ -1745,6 +1794,8 @@ configure_zone(cfg_obj_t *config, cfg_obj_t *zconfig, cfg_obj_t *vconfig, CHECK(dns_zone_create(&zone, mctx)); CHECK(dns_zone_setorigin(zone, origin)); dns_zone_setview(zone, view); + if (view->acache != NULL) + dns_zone_setacache(zone, view->acache); CHECK(dns_zonemgr_managezone(ns_g_server->zonemgr, zone)); } diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 8ecb232287..04882f40bf 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -2,7 +2,7 @@ - + BIND 9 Administrator Reference Manual @@ -392,7 +392,12 @@ signed zones, serving many thousands of queries per second. cache and zones loaded off disk. The max-cache-size option can be used to limit the amount of memory used by the cache, at the expense of reducing cache hit rates and causing more DNS -traffic. It is still good practice to have enough memory to load +traffic. +Additionally, if additional section caching +() is enabled, +the max-acache-size can be used to limit the amount +of memory used by the mechanism. +It is still good practice to have enough memory to load all zone and cache data into memory — unfortunately, the best way to determine this for a given installation is to watch the name server in operation. After a few weeks the server process should reach @@ -2800,8 +2805,11 @@ statement in the named.conf file: edns-udp-size number; root-delegation-only exclude { namelist } ; querylog yes_or_no ; -}; disable-algorithms domain { algorithm; algorithm; }; + use-additional-cache yes_or_no ; + acache-cleaning-interval number; + max-acache-size size_spec ; +}; @@ -4346,6 +4354,99 @@ to be incremented, and may additionally cause the + +Additional Section Caching + + +The additional section cache, also called acache, +is an internal cache to improve the response performance of BIND 9. +When the additional section caching is enabled, BIND 9 will +cache internal short-cut to the additional section content for each +answer RR. +Note that acache is an internal caching mechanism of BIND 9, and is +not relevant to the DNS caching server function. + + + +The additional section caching does not make any difference on the +response content (except the RRsets ordering of the additional +section, see below), but can improve the response performance significantly. +It is particularly effective when BIND 9 acts as an authoritative server +for a zone that has many delegations with many glue RRs. + + + +In order to achieve the maximum performance improvement by acache, +it is recommended to set additional-from-cache +to no, since the current implementation of acache +does not make a short-cut of additional section information from a DNS +cache data. + + + +One obvious disadvantage of acache is that it requires much more +memory for the internal cached data. +Thus, if the response performance does not matter and memory +consumption is much more severe, the acache mechanism can be +disabled by setting use-additional-cache to +no. +It is also possible to specify the upper limit of memory consumption +for acache by max-acache-size. + + + +The additional section caching also has a minor effect on the RRset +ordering in the additional section. +Without acache, the "cyclic" order is effective for the additional +section as well as the answer and authority sections. +However, the additional section caching fixes the ordering when it +first caches an RRset for the additional section, and the same +ordering will be kept in succeeding responses, regardless of the +configuration for rrset-order. +This should be minor, though, since an RRset in the additional section +typically only contains a small number of RRs (and in many cases it +only contains a single RR), in which case the +ordering does not matter much. + + + +The following is a summary of options related to acache. + + + + +use-additional-cache + +If yes, the additional section caching is enabled. +The default value is yes. + + + +acache-cleaning-interval + +The server will remove stale cache entries, based on an LRU based +algorithm, every acache-cleaning-interval minutes. +The default is 60 minutes. +If set to 0, no periodic cleaning will occur. + + + +max-acache-size + +The maximum amount of memory to use for the server's acache, in bytes. +When the amount of data in the acache reaches this limit, the server +will cause more aggressive cleaning so that the limit is not exceeded. +In a server with multiple views, the limit applies separately to the +acache of each view. +The default is unlimited, meaning that +entries are purged from acache only at the periodic cleaning time. + + + + + + + diff --git a/lib/dns/Makefile.in b/lib/dns/Makefile.in index b4304d80ec..248f874649 100644 --- a/lib/dns/Makefile.in +++ b/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.148 2004/12/09 01:40:59 marka Exp $ +# $Id: Makefile.in,v 1.149 2004/12/21 10:45:16 jinmei Exp $ srcdir = @srcdir@ VPATH = @srcdir@ @@ -49,7 +49,7 @@ DSTOBJS = dst_api.@O@ dst_lib.@O@ dst_parse.@O@ dst_result.@O@ \ opensslrsa_link.@O@ # Alphabetically -DNSOBJS = acl.@O@ adb.@O@ byaddr.@O@ \ +DNSOBJS = acache.@O@ acl.@O@ adb.@O@ byaddr.@O@ \ cache.@O@ callbacks.@O@ compress.@O@ \ db.@O@ dbiterator.@O@ dbtable.@O@ diff.@O@ dispatch.@O@ \ dnssec.@O@ ds.@O@ forward.@O@ journal.@O@ keytable.@O@ \ @@ -73,7 +73,7 @@ DSTSRCS = dst_api.c dst_lib.c dst_parse.c \ openssl_link.c openssldh_link.c \ openssldsa_link.c opensslrsa_link.c -DNSSRCS = acl.c adb.c byaddr.c \ +DNSSRCS = acache.c acl.c adb.c byaddr.c \ cache.c callbacks.c compress.c \ db.c dbiterator.c dbtable.c diff.c dispatch.c \ dnssec.c ds.c forward.c journal.c keytable.c \ diff --git a/lib/dns/acache.c b/lib/dns/acache.c new file mode 100644 index 0000000000..a59d326f64 --- /dev/null +++ b/lib/dns/acache.c @@ -0,0 +1,1575 @@ +/* + * Copyright (C) 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 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. + */ + +/* $Id: acache.c,v 1.2 2004/12/21 10:45:16 jinmei Exp $ */ + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define ACACHE_MAGIC ISC_MAGIC('A', 'C', 'H', 'E') +#define DNS_ACACHE_VALID(acache) ISC_MAGIC_VALID(acache, ACACHE_MAGIC) + +#define ACACHEENTRY_MAGIC ISC_MAGIC('A', 'C', 'E', 'T') +#define DNS_ACACHEENTRY_VALID(entry) ISC_MAGIC_VALID(entry, ACACHEENTRY_MAGIC) + +#define DBBUCKETS 67 + +#if 0 +#define ATRACE(m) isc_log_write(dns_lctx, \ + DNS_LOGCATEGORY_DATABASE, \ + DNS_LOGMODULE_ACACHE, \ + ISC_LOG_DEBUG(3), \ + "acache %p: %s", acache, (m)) +#define AATRACE(a,m) isc_log_write(dns_lctx, \ + DNS_LOGCATEGORY_DATABASE, \ + DNS_LOGMODULE_ACACHE, \ + ISC_LOG_DEBUG(3), \ + "acache %p: %s", (a), (m)) +#else +#define ATRACE(m) +#define AATRACE(a, m) +#endif + +/* + * The following variables control incremental cleaning. + * MINSIZE is how many bytes is the floor for dns_acache_setcachesize(). + * CLEANERINCREMENT is how many entries are examined in one pass. + * (XXX simply derived from definitions in cache.c There may be better + * constants here.) + */ +#define DNS_ACACHE_MINSIZE 2097152 /* Bytes. 2097152 = 2 MB */ +#define DNS_ACACHE_CLEANERINCREMENT 1000 /* Number of entries. */ + +/* Locked by acache lock */ +typedef struct dbentry { + ISC_LINK(struct dbentry) link; + + dns_db_t *db; + ISC_LIST(dns_acacheentry_t) originlist; + ISC_LIST(dns_acacheentry_t) referlist; +} dbentry_t; + +typedef ISC_LIST(dbentry_t) dbentrylist_t; + +typedef struct acache_cleaner acache_cleaner_t; + +typedef enum { + cleaner_s_idle, /* Waiting for cleaning-interval to expire. */ + cleaner_s_busy, /* Currently cleaning. */ + cleaner_s_done /* Freed enough memory after being overmem. */ +} cleaner_state_t; + +/* + * Convenience macros for comprehensive assertion checking. + */ +#define CLEANER_IDLE(c) ((c)->state == cleaner_s_idle && \ + (c)->resched_event != NULL) +#define CLEANER_BUSY(c) ((c)->state == cleaner_s_busy && \ + (c)->resched_event == NULL) + +struct acache_cleaner { + isc_mutex_t lock; + /* + * Locks overmem_event, overmem. (See cache.c) + */ + + dns_acache_t *acache; + unsigned int cleaning_interval; /* The cleaning-interval + from named.conf, + in seconds. */ + + isc_timer_t *cleaning_timer; + isc_event_t *resched_event; /* Sent by cleaner task to + itself to reschedule */ + isc_event_t *overmem_event; + + dns_acacheentry_t *current_entry; /* The bookmark entry to + restart the cleaning. + Locked by acache lock. */ + int increment; /* Number of entries to + clean in one increment */ + + unsigned long ncleaned; /* Number of entries cleaned + up (for logging purposes) */ + cleaner_state_t state; /* Idle/Busy/Done. */ + isc_boolean_t overmem; /* The acache is in an overmem + state. */ +}; + +/* + * The actual acache object. + */ + +struct dns_acache { + unsigned int magic; + + isc_mem_t *mctx; + isc_refcount_t refs; + + isc_mutex_t lock; + + int live_cleaners; + acache_cleaner_t cleaner; + ISC_LIST(dns_acacheentry_t) entries; + unsigned int dbentries; + dbentrylist_t dbbucket[DBBUCKETS]; + + isc_boolean_t shutting_down; + + isc_task_t *task; + isc_event_t cevent; + isc_boolean_t cevent_sent; +}; + +struct dns_acacheentry { + unsigned int magic; + + isc_mutex_t lock; + isc_refcount_t references; + + dns_acache_t *acache; + + /* Data for Management of cache entries */ + ISC_LINK(dns_acacheentry_t) link; + ISC_LINK(dns_acacheentry_t) olink; + ISC_LINK(dns_acacheentry_t) rlink; + + dns_db_t *origdb; /* reference to the DB + holding this entry */ + + /* Cache data */ + dns_zone_t *zone; /* zone this entry + belongs to */ + dns_db_t *db; /* DB this entry belongs to */ + dns_dbversion_t *version; /* the version of the DB */ + dns_dbnode_t *node; /* node this entry + belongs to */ + dns_name_t *foundname; /* corresponding DNS name + and rdataset */ + + /* Callback function and its argument */ + void (*callback)(dns_acacheentry_t *, void **); + void *cbarg; + + /* Timestamp of the last time this entry is referred to */ + isc_stdtime_t lastused; +}; + +/* + * Internal functions (and prototypes). + */ +static inline isc_boolean_t check_noentry(dns_acache_t *acache); +static void destroy(dns_acache_t *acache); +static void shutdown_entries(dns_acache_t *acache); +static void shutdown_buckets(dns_acache_t *acache); +static void destroy_entry(dns_acacheentry_t *ent); +static inline void unlink_dbentries(dns_acache_t *acache, + dns_acacheentry_t *ent); +static inline isc_result_t finddbent(dns_acache_t *acache, + dns_db_t *db, dbentry_t **dbentryp); +static inline void clear_entry(dns_acache_t *acache, dns_acacheentry_t *entry); +static isc_result_t acache_cleaner_init(dns_acache_t *acache, + isc_timermgr_t *timermgr, + acache_cleaner_t *cleaner); +static void acache_cleaning_timer_action(isc_task_t *task, isc_event_t *event); +static void acache_incremental_cleaning_action(isc_task_t *task, + isc_event_t *event); +static void acache_overmem_cleaning_action(isc_task_t *task, + isc_event_t *event); +static void acache_cleaner_shutdown_action(isc_task_t *task, + isc_event_t *event); + +/* + * The acache must be locked before calling. + */ +static inline isc_boolean_t +check_noentry(dns_acache_t *acache) { + if (ISC_LIST_EMPTY(acache->entries) && acache->dbentries == 0) { + return (ISC_TRUE); + } + + return (ISC_FALSE); +} + +/* + * The acache must be locked before calling. + */ +static void +shutdown_entries(dns_acache_t *acache) { + dns_acacheentry_t *entry, *entry_next; + + REQUIRE(DNS_ACACHE_VALID(acache)); + INSIST(acache->shutting_down); + + /* + * Release the dependency of all entries, and detach them. + */ + for (entry = ISC_LIST_HEAD(acache->entries); + entry != NULL; + entry = entry_next) { + entry_next = ISC_LIST_NEXT(entry, link); + + LOCK(&entry->lock); + + /* + * If the cleaner holds this entry, it will be unlinked and + * freed in the cleaner later. + */ + if (acache->cleaner.current_entry != entry) + ISC_LIST_UNLINK(acache->entries, entry, link); + unlink_dbentries(acache, entry); + if (entry->callback != NULL) { + (entry->callback)(entry, &entry->cbarg); + entry->callback = NULL; + } + + UNLOCK(&entry->lock); + + if (acache->cleaner.current_entry != entry) + dns_acache_detachentry(&entry); + } +} + +/* + * The acache must be locked before calling. + */ +static void +shutdown_buckets(dns_acache_t *acache) { + int i; + dbentry_t *dbent; + + REQUIRE(DNS_ACACHE_VALID(acache)); + INSIST(acache->shutting_down); + + for (i = 0; i < DBBUCKETS; i++) { + while ((dbent = ISC_LIST_HEAD(acache->dbbucket[i])) != NULL) { + INSIST(ISC_LIST_EMPTY(dbent->originlist) && + ISC_LIST_EMPTY(dbent->referlist)); + ISC_LIST_UNLINK(acache->dbbucket[i], dbent, link); + + dns_db_detach(&dbent->db); + + isc_mem_put(acache->mctx, dbent, sizeof(*dbent)); + + acache->dbentries--; + } + } + + INSIST(acache->dbentries == 0); +} + +static void +shutdown_task(isc_task_t *task, isc_event_t *ev) { + dns_acache_t *acache; + + UNUSED(task); + + acache = ev->ev_arg; + INSIST(DNS_ACACHE_VALID(acache)); + + isc_event_free(&ev); + + LOCK(&acache->lock); + + shutdown_entries(acache); + shutdown_buckets(acache); + + UNLOCK(&acache->lock); + + dns_acache_detach(&acache); +} + +/* The acache and the entry must be locked before calling. */ +static inline void +unlink_dbentries(dns_acache_t *acache, dns_acacheentry_t *ent) { + isc_result_t result; + dbentry_t *dbent; + + if (ISC_LINK_LINKED(ent, olink)) { + INSIST(ent->origdb != NULL); + dbent = NULL; + result = finddbent(acache, ent->origdb, &dbent); + INSIST(result == ISC_R_SUCCESS); + + ISC_LIST_UNLINK(dbent->originlist, ent, olink); + } + if (ISC_LINK_LINKED(ent, rlink)) { + INSIST(ent->db != NULL); + dbent = NULL; + result = finddbent(acache, ent->db, &dbent); + INSIST(result == ISC_R_SUCCESS); + + ISC_LIST_UNLINK(dbent->referlist, ent, rlink); + } +} + +/* There must not be a reference to this entry. */ +static void +destroy_entry(dns_acacheentry_t *entry) { + dns_acache_t *acache; + + REQUIRE(DNS_ACACHEENTRY_VALID(entry)); + + acache = entry->acache; + REQUIRE(DNS_ACACHE_VALID(acache)); + + /* + * Since there is no reference to this entry, it is safe to call + * clear_entry() here. + */ + clear_entry(acache, entry); + + isc_mem_put(acache->mctx, entry, sizeof(*entry)); + + dns_acache_detach(&acache); +} + +static void +destroy(dns_acache_t *acache) { + isc_mem_t *mctx; + + REQUIRE(DNS_ACACHE_VALID(acache)); + + ATRACE("destroy"); + + isc_mem_setwater(acache->mctx, NULL, NULL, 0, 0); + + if (acache->cleaner.overmem_event != NULL) + isc_event_free(&acache->cleaner.overmem_event); + + if (acache->cleaner.resched_event != NULL) + isc_event_free(&acache->cleaner.resched_event); + + if (acache->task != NULL) + isc_task_detach(&acache->task); + + DESTROYLOCK(&acache->cleaner.lock); + + DESTROYLOCK(&acache->lock); + acache->magic = 0; + mctx = acache->mctx; + + isc_mem_putanddetach(&acache->mctx, acache, sizeof(*acache)); +} + +static inline isc_result_t +finddbent(dns_acache_t *acache, dns_db_t *db, dbentry_t **dbentryp) { + int bucket; + dbentry_t *dbentry; + + REQUIRE(DNS_ACACHE_VALID(acache)); + REQUIRE(db != NULL); + REQUIRE(dbentryp != NULL && *dbentryp == NULL); + + /* + * The caller must be holding the acache lock. + */ + + bucket = isc_hash_calc((const unsigned char *)&db, + sizeof(db), ISC_TRUE) % DBBUCKETS; + + for (dbentry = ISC_LIST_HEAD(acache->dbbucket[bucket]); + dbentry != NULL; + dbentry = ISC_LIST_NEXT(dbentry, link)) { + if (dbentry->db == db) + break; + } + + *dbentryp = dbentry; + + if (dbentry == NULL) + return (ISC_R_NOTFOUND); + else + return (ISC_R_SUCCESS); +} + +static inline void +clear_entry(dns_acache_t *acache, dns_acacheentry_t *entry) { + REQUIRE(DNS_ACACHE_VALID(acache)); + REQUIRE(DNS_ACACHEENTRY_VALID(entry)); + + /* + * The caller must be holing the entry lock. + */ + + if (entry->foundname) { + dns_rdataset_t *rdataset, *rdataset_next; + + for (rdataset = ISC_LIST_HEAD(entry->foundname->list); + rdataset != NULL; + rdataset = rdataset_next) { + rdataset_next = ISC_LIST_NEXT(rdataset, link); + ISC_LIST_UNLINK(entry->foundname->list, + rdataset, link); + dns_rdataset_disassociate(rdataset); + isc_mem_put(acache->mctx, rdataset, sizeof(*rdataset)); + } + if (dns_name_dynamic(entry->foundname)) + dns_name_free(entry->foundname, acache->mctx); + isc_mem_put(acache->mctx, entry->foundname, + sizeof(*entry->foundname)); + entry->foundname = NULL; + } + + if (entry->node != NULL) { + INSIST(entry->db != NULL); + dns_db_detachnode(entry->db, &entry->node); + } + if (entry->version != NULL) { + INSIST(entry->db != NULL); + dns_db_closeversion(entry->db, &entry->version, ISC_FALSE); + } + if (entry->db != NULL) + dns_db_detach(&entry->db); + if (entry->zone != NULL) + dns_zone_detach(&entry->zone); + + if (entry->origdb != NULL) + dns_db_detach(&entry->origdb); +} + +static isc_result_t +acache_cleaner_init(dns_acache_t *acache, isc_timermgr_t *timermgr, + acache_cleaner_t *cleaner) +{ + int result; + + ATRACE("acache cleaner init"); + + result = isc_mutex_init(&cleaner->lock); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_mutex_init() failed: %s", + dns_result_totext(result)); + result = ISC_R_UNEXPECTED; + goto fail; + } + + cleaner->increment = DNS_ACACHE_CLEANERINCREMENT; + cleaner->state = cleaner_s_idle; + cleaner->acache = acache; + cleaner->overmem = ISC_FALSE; + + cleaner->cleaning_timer = NULL; + cleaner->resched_event = NULL; + cleaner->overmem_event = NULL; + cleaner->current_entry = NULL; + + if (timermgr != NULL) { + cleaner->acache->live_cleaners++; + + result = isc_task_onshutdown(acache->task, + acache_cleaner_shutdown_action, + acache); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "acache cleaner: " + "isc_task_onshutdown() failed: %s", + dns_result_totext(result)); + goto cleanup; + } + + cleaner->cleaning_interval = 0; /* Initially turned off. */ + result = isc_timer_create(timermgr, isc_timertype_inactive, + NULL, NULL, + acache->task, + acache_cleaning_timer_action, + cleaner, &cleaner->cleaning_timer); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_timer_create() failed: %s", + dns_result_totext(result)); + result = ISC_R_UNEXPECTED; + goto cleanup; + } + + cleaner->resched_event = + isc_event_allocate(acache->mctx, cleaner, + DNS_EVENT_ACACHECLEAN, + acache_incremental_cleaning_action, + cleaner, sizeof(isc_event_t)); + if (cleaner->resched_event == NULL) { + result = ISC_R_NOMEMORY; + goto cleanup; + } + + cleaner->overmem_event = + isc_event_allocate(acache->mctx, cleaner, + DNS_EVENT_ACACHEOVERMEM, + acache_overmem_cleaning_action, + cleaner, sizeof(isc_event_t)); + if (cleaner->overmem_event == NULL) { + result = ISC_R_NOMEMORY; + goto cleanup; + } + } + + return (ISC_R_SUCCESS); + + cleanup: + if (cleaner->overmem_event != NULL) + isc_event_free(&cleaner->overmem_event); + if (cleaner->resched_event != NULL) + isc_event_free(&cleaner->resched_event); + if (cleaner->cleaning_timer != NULL) + isc_timer_detach(&cleaner->cleaning_timer); + cleaner->acache->live_cleaners--; + DESTROYLOCK(&cleaner->lock); + fail: + return (result); +} + +static void +begin_cleaning(acache_cleaner_t *cleaner) { + dns_acacheentry_t *head; + dns_acache_t *acache = cleaner->acache; + + /* + * This function does not have to lock the cleaner, since critical + * parameters (except current_entry, which is locked by acache lock,) + * are only used in a single task context. + */ + + REQUIRE(CLEANER_IDLE(cleaner)); + INSIST(DNS_ACACHE_VALID(acache)); + INSIST(cleaner->current_entry == NULL); + + isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE, + DNS_LOGMODULE_ACACHE, ISC_LOG_DEBUG(1), + "begin acache cleaning, mem inuse %lu", + (unsigned long)isc_mem_inuse(cleaner->acache->mctx)); + + LOCK(&acache->lock); + + head = ISC_LIST_HEAD(acache->entries); + if (head != NULL) + dns_acache_attachentry(head, &cleaner->current_entry); + + UNLOCK(&acache->lock); + + if (cleaner->current_entry != NULL) { + cleaner->ncleaned = 0; + cleaner->state = cleaner_s_busy; + isc_task_send(acache->task, &cleaner->resched_event); + } + + return; +} + +static void +end_cleaning(acache_cleaner_t *cleaner, isc_event_t *event) { + dns_acache_t *acache = cleaner->acache; + + REQUIRE(CLEANER_BUSY(cleaner)); + REQUIRE(event != NULL); + REQUIRE(DNS_ACACHEENTRY_VALID(cleaner->current_entry)); + + /* No need to lock the cleaner (see begin_cleaning()). */ + + LOCK(&acache->lock); + + /* + * Even if the cleaner has the last reference to the entry, which means + * the entry has been unused, it may still be linked if unlinking the + * entry has been delayed due to the reference. + */ + if (isc_refcount_current(&cleaner->current_entry->references) == 1) { + INSIST(cleaner->current_entry->callback == NULL); + + if (ISC_LINK_LINKED(cleaner->current_entry, link)) { + ISC_LIST_UNLINK(acache->entries, + cleaner->current_entry, link); + } + } + dns_acache_detachentry(&cleaner->current_entry); + + UNLOCK(&acache->lock); + + dns_acache_setcleaninginterval(cleaner->acache, + cleaner->cleaning_interval); + + isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE, DNS_LOGMODULE_ACACHE, + ISC_LOG_DEBUG(1), "end acache cleaning, " + "%lu entries cleaned, mem inuse %lu", + cleaner->ncleaned, + (unsigned long)isc_mem_inuse(cleaner->acache->mctx)); + + if (cleaner->overmem) { + isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE, + DNS_LOGMODULE_ACACHE, ISC_LOG_NOTICE, + "acache is still in overmem state " + "after cleaning"); + } + + cleaner->ncleaned = 0; + cleaner->state = cleaner_s_idle; + cleaner->resched_event = event; +} + +/* + * This is run once for every acache-cleaning-interval as defined + * in named.conf. + */ +static void +acache_cleaning_timer_action(isc_task_t *task, isc_event_t *event) { + acache_cleaner_t *cleaner = event->ev_arg; + + UNUSED(task); + + INSIST(event->ev_type == ISC_TIMEREVENT_TICK); + + isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE, DNS_LOGMODULE_ACACHE, + ISC_LOG_DEBUG(1), "acache cleaning timer fired, " + "cleaner state = %d", cleaner->state); + + if (cleaner->state == cleaner_s_idle) + begin_cleaning(cleaner); + + isc_event_free(&event); +} + +/* The caller must hold entry lock. */ +static inline isc_boolean_t +entry_stale(acache_cleaner_t *cleaner, dns_acacheentry_t *entry, + isc_stdtime_t now) +{ + unsigned int interval = cleaner->cleaning_interval; + + /* + * If the callback has been canceled, we definitely do not need the + * entry. + */ + if (entry->callback == NULL) + return (ISC_TRUE); + + if (entry->lastused + interval < now) + return (ISC_TRUE); + + /* + * If the acache is in an overmem state, probabilistically decide if + * the entry should be purged, based on the time passed from its last + * use and the cleaning interval. + */ + if (cleaner->overmem) { + unsigned int passed = now - entry->lastused; /* <= interval */ + isc_uint32_t val, r; + + isc_random_get(&val); + r = val % interval; + + if (r < passed) + return (ISC_TRUE); + } + + return (ISC_FALSE); +} + +/* + * Do incremental cleaning. + */ +static void +acache_incremental_cleaning_action(isc_task_t *task, isc_event_t *event) { + acache_cleaner_t *cleaner = event->ev_arg; + dns_acache_t *acache = cleaner->acache; + dns_acacheentry_t *entry, *next = NULL; + int n_entries; + isc_stdtime_t now; + + INSIST(DNS_ACACHE_VALID(acache)); + INSIST(task == acache->task); + INSIST(event->ev_type == DNS_EVENT_ACACHECLEAN); + + if (cleaner->state == cleaner_s_done) { + cleaner->state = cleaner_s_busy; + end_cleaning(cleaner, event); + return; + } + + INSIST(CLEANER_BUSY(cleaner)); + + n_entries = cleaner->increment; + + isc_stdtime_get(&now); + + LOCK(&acache->lock); + + entry = cleaner->current_entry; + + while (n_entries-- > 0) { + isc_boolean_t is_stale = ISC_FALSE; + + INSIST(entry != NULL); + + next = ISC_LIST_NEXT(entry, link); + + LOCK(&entry->lock); + + is_stale = entry_stale(cleaner, entry, now); + if (is_stale) { + ISC_LIST_UNLINK(acache->entries, entry, link); + unlink_dbentries(acache, entry); + if (entry->callback != NULL) + (entry->callback)(entry, &entry->cbarg); + entry->callback = NULL; + + cleaner->ncleaned++; + } + + UNLOCK(&entry->lock); + + if (is_stale) + dns_acache_detachentry(&entry); + + if (next == NULL) { + UNLOCK(&acache->lock); + end_cleaning(cleaner, event); + return; + } + + entry = next; + } + + /* + * We have successfully performed a cleaning increment but have + * not gone through the entire cache. Remember the entry that will + * be the starting point in the next clean-up, and reschedule another + * batch. If it fails, just try to continue anyway. + */ + INSIST(next != NULL && next != cleaner->current_entry); + dns_acache_detachentry(&cleaner->current_entry); + dns_acache_attachentry(next, &cleaner->current_entry); + + UNLOCK(&acache->lock); + + isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE, DNS_LOGMODULE_ACACHE, + ISC_LOG_DEBUG(1), "acache cleaner: checked %d entries, " + "mem inuse %lu, sleeping", cleaner->increment, + (unsigned long)isc_mem_inuse(cleaner->acache->mctx)); + + isc_task_send(task, &event); + INSIST(CLEANER_BUSY(cleaner)); + + return; +} + +/* + * This is called when the acache either surpasses its upper limit + * or shrinks beyond its lower limit. + */ +static void +acache_overmem_cleaning_action(isc_task_t *task, isc_event_t *event) { + acache_cleaner_t *cleaner = event->ev_arg; + isc_boolean_t want_cleaning = ISC_FALSE; + + UNUSED(task); + + INSIST(event->ev_type == DNS_EVENT_ACACHEOVERMEM); + INSIST(cleaner->overmem_event == NULL); + + isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE, DNS_LOGMODULE_ACACHE, + ISC_LOG_DEBUG(1), "overmem_cleaning_action called, " + "overmem = %d, state = %d", cleaner->overmem, + cleaner->state); + + LOCK(&cleaner->lock); + + if (cleaner->overmem) { + if (cleaner->state == cleaner_s_idle) + want_cleaning = ISC_TRUE; + } else { + if (cleaner->state == cleaner_s_busy) + /* + * end_cleaning() can't be called here because + * then both cleaner->overmem_event and + * cleaner->resched_event will point to this + * event. Set the state to done, and then + * when the acache_incremental_cleaning_action() event + * is posted, it will handle the end_cleaning. + */ + cleaner->state = cleaner_s_done; + } + + cleaner->overmem_event = event; + + UNLOCK(&cleaner->lock); + + if (want_cleaning) + begin_cleaning(cleaner); +} + +static void +water(void *arg, int mark) { + dns_acache_t *acache = arg; + isc_boolean_t overmem = ISC_TF(mark == ISC_MEM_HIWATER); + + REQUIRE(DNS_ACACHE_VALID(acache)); + + isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE, + DNS_LOGMODULE_ACACHE, ISC_LOG_DEBUG(1), + "acache memory reaches %s watermark, mem inuse %lu", + overmem ? "high" : "low", + (unsigned long)isc_mem_inuse(acache->mctx)); + + LOCK(&acache->cleaner.lock); + + acache->cleaner.overmem = overmem; + + if (acache->cleaner.overmem_event != NULL) + isc_task_send(acache->task, &acache->cleaner.overmem_event); + + UNLOCK(&acache->cleaner.lock); +} + +/* + * The cleaner task is shutting down; do the necessary cleanup. + */ +static void +acache_cleaner_shutdown_action(isc_task_t *task, isc_event_t *event) { + dns_acache_t *acache = event->ev_arg; + isc_boolean_t should_free = ISC_FALSE; + + INSIST(task == acache->task); + INSIST(event->ev_type == ISC_TASKEVENT_SHUTDOWN); + INSIST(DNS_ACACHE_VALID(acache)); + + ATRACE("acache cleaner shutdown"); + + if (CLEANER_BUSY(&acache->cleaner)) + end_cleaning(&acache->cleaner, event); + else + isc_event_free(&event); + + LOCK(&acache->lock); + + acache->live_cleaners--; + INSIST(acache->live_cleaners == 0); + + if (isc_refcount_current(&acache->refs) == 0) { + INSIST(check_noentry(acache) == ISC_TRUE); + should_free = ISC_TRUE; + } + + /* + * By detaching the timer in the context of its task, + * we are guaranteed that there will be no further timer + * events. + */ + if (acache->cleaner.cleaning_timer != NULL) + isc_timer_detach(&acache->cleaner.cleaning_timer); + + /* Make sure we don't reschedule anymore. */ + (void)isc_task_purge(task, NULL, DNS_EVENT_ACACHECLEAN, NULL); + + UNLOCK(&acache->lock); + + if (should_free) + destroy(acache); +} + +/* + * Public functions. + */ + +isc_result_t +dns_acache_create(dns_acache_t **acachep, isc_mem_t *mctx, + isc_taskmgr_t *taskmgr, isc_timermgr_t *timermgr) +{ + int i; + isc_result_t result; + dns_acache_t *acache; + + REQUIRE(acachep != NULL && *acachep == NULL); + REQUIRE(mctx != NULL); + REQUIRE(taskmgr != NULL); + + acache = isc_mem_get(mctx, sizeof(*acache)); + if (acache == NULL) + return (ISC_R_NOMEMORY); + + ATRACE("create"); + + isc_refcount_init(&acache->refs, 1); + + result = isc_mutex_init(&acache->lock); + if (result != ISC_R_SUCCESS) { + isc_mem_put(mctx, acache, sizeof(*acache)); + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_mutex_init() failed: %s", + isc_result_totext(result)); + return (ISC_R_UNEXPECTED); + } + + acache->mctx = NULL; + isc_mem_attach(mctx, &acache->mctx); + ISC_LIST_INIT(acache->entries); + + acache->shutting_down = ISC_FALSE; + + acache->task = NULL; + result = isc_task_create(taskmgr, 1, &acache->task); + if (result != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_task_create() failed(): %s", + dns_result_totext(result)); + result = ISC_R_UNEXPECTED; + goto cleanup; + } + isc_task_setname(acache->task, "acachetask", acache); + ISC_EVENT_INIT(&acache->cevent, sizeof(acache->cevent), 0, NULL, + DNS_EVENT_ACACHECONTROL, shutdown_task, NULL, + NULL, NULL, NULL); + acache->cevent_sent = ISC_FALSE; + + acache->dbentries = 0; + for (i = 0; i < DBBUCKETS; i++) + ISC_LIST_INIT(acache->dbbucket[i]); + + acache->live_cleaners = 0; + result = acache_cleaner_init(acache, timermgr, &acache->cleaner); + if (result != ISC_R_SUCCESS) + goto cleanup; + + acache->magic = ACACHE_MAGIC; + + *acachep = acache; + return (ISC_R_SUCCESS); + + cleanup: + if (acache->task != NULL) + isc_task_detach(&acache->task); + DESTROYLOCK(&acache->lock); + isc_mem_put(mctx, acache, sizeof(*acache)); + isc_mem_detach(&mctx); + + return (result); +} + +void +dns_acache_attach(dns_acache_t *source, dns_acache_t **targetp) { + REQUIRE(DNS_ACACHE_VALID(source)); + REQUIRE(targetp != NULL && *targetp == NULL); + + AATRACE(source, "attach"); + + isc_refcount_increment(&source->refs, NULL); + + *targetp = source; +} + +void +dns_acache_detach(dns_acache_t **acachep) { + dns_acache_t *acache; + unsigned int refs; + isc_boolean_t should_free = ISC_FALSE; + + REQUIRE(acachep != NULL && DNS_ACACHE_VALID(*acachep)); + acache = *acachep; + + ATRACE("detach"); + + isc_refcount_decrement(&acache->refs, &refs); + if (refs == 0) { + INSIST(check_noentry(acache) == ISC_TRUE); + should_free = ISC_TRUE; + } + + *acachep = NULL; + + /* + * If we're exiting and the cleaner task exists, let it free the cache. + */ + if (should_free && acache->live_cleaners > 0) { + isc_task_shutdown(acache->task); + should_free = ISC_FALSE; + } + + if (should_free) + destroy(acache); +} + +void +dns_acache_shutdown(dns_acache_t *acache) { + REQUIRE(DNS_ACACHE_VALID(acache)); + + LOCK(&acache->lock); + + ATRACE("shutdown"); + + if (!acache->shutting_down) { + isc_event_t *event; + dns_acache_t *acache_evarg = NULL; + + INSIST(!acache->cevent_sent); + + acache->shutting_down = ISC_TRUE; + + isc_mem_setwater(acache->mctx, NULL, NULL, 0, 0); + + /* + * Self attach the object in order to prevent it from being + * destroyed while waiting for the event. + */ + dns_acache_attach(acache, &acache_evarg); + event = &acache->cevent; + event->ev_arg = acache_evarg; + isc_task_send(acache->task, &event); + acache->cevent_sent = ISC_TRUE; + } + + UNLOCK(&acache->lock); +} + +isc_result_t +dns_acache_setdb(dns_acache_t *acache, dns_db_t *db) { + int bucket; + dbentry_t *dbentry; + isc_result_t result = ISC_R_SUCCESS; + + REQUIRE(DNS_ACACHE_VALID(acache)); + REQUIRE(db != NULL); + + ATRACE("setdb"); + + LOCK(&acache->lock); + + dbentry = NULL; + result = finddbent(acache, db, &dbentry); + if (result == ISC_R_SUCCESS) { + result = ISC_R_EXISTS; + goto end; + } + result = ISC_R_SUCCESS; + + dbentry = isc_mem_get(acache->mctx, sizeof(*dbentry)); + if (dbentry == NULL) { + result = ISC_R_NOMEMORY; + goto end; + } + + ISC_LINK_INIT(dbentry, link); + ISC_LIST_INIT(dbentry->originlist); + ISC_LIST_INIT(dbentry->referlist); + + dbentry->db = NULL; + dns_db_attach(db, &dbentry->db); + + bucket = isc_hash_calc((const unsigned char *)&db, + sizeof(db), ISC_TRUE) % DBBUCKETS; + + ISC_LIST_APPEND(acache->dbbucket[bucket], dbentry, link); + + acache->dbentries++; + + end: + UNLOCK(&acache->lock); + + return (result); +} + +isc_result_t +dns_acache_putdb(dns_acache_t *acache, dns_db_t *db) { + int bucket; + isc_result_t result; + dbentry_t *dbentry; + dns_acacheentry_t *entry; + + REQUIRE(DNS_ACACHE_VALID(acache)); + REQUIRE(db != NULL); + + ATRACE("putdb"); + + LOCK(&acache->lock); + + dbentry = NULL; + result = finddbent(acache, db, &dbentry); + if (result != ISC_R_SUCCESS) { + /* + * The entry may have not been created due to memory shortage. + */ + UNLOCK(&acache->lock); + return (ISC_R_NOTFOUND); + } + + /* + * Release corresponding cache entries: for each entry, release all + * links the entry has, and then callback to the entry holder (if any). + * If no other external references exist (this can happen if the + * original holder has canceled callback,) destroy it here. + */ + while ((entry = ISC_LIST_HEAD(dbentry->originlist)) != NULL) { + LOCK(&entry->lock); + + /* + * Releasing olink first would avoid finddbent() in + * unlink_dbentries(). + */ + ISC_LIST_UNLINK(dbentry->originlist, entry, olink); + if (acache->cleaner.current_entry == NULL || + acache->cleaner.current_entry != entry) { + ISC_LIST_UNLINK(acache->entries, entry, link); + } + unlink_dbentries(acache, entry); + + if (entry->callback != NULL) + (entry->callback)(entry, &entry->cbarg); + entry->callback = NULL; + + UNLOCK(&entry->lock); + + if (acache->cleaner.current_entry == NULL || + acache->cleaner.current_entry != entry) { + dns_acache_detachentry(&entry); + } + } + while ((entry = ISC_LIST_HEAD(dbentry->referlist)) != NULL) { + LOCK(&entry->lock); + + ISC_LIST_UNLINK(dbentry->referlist, entry, rlink); + if (acache->cleaner.current_entry == NULL || + acache->cleaner.current_entry != entry) { + ISC_LIST_UNLINK(acache->entries, entry, link); + } + unlink_dbentries(acache, entry); + + if (entry->callback != NULL) + (entry->callback)(entry, &entry->cbarg); + entry->callback = NULL; + + UNLOCK(&entry->lock); + + if (acache->cleaner.current_entry == NULL || + acache->cleaner.current_entry != entry) { + dns_acache_detachentry(&entry); + } + } + + INSIST(ISC_LIST_EMPTY(dbentry->originlist) && + ISC_LIST_EMPTY(dbentry->referlist)); + + bucket = isc_hash_calc((const unsigned char *)&db, + sizeof(db), ISC_TRUE) % DBBUCKETS; + ISC_LIST_UNLINK(acache->dbbucket[bucket], dbentry, link); + dns_db_detach(&dbentry->db); + + isc_mem_put(acache->mctx, dbentry, sizeof(*dbentry)); + + acache->dbentries--; + + UNLOCK(&acache->lock); + + return (ISC_R_SUCCESS); +} + +isc_result_t +dns_acache_createentry(dns_acache_t *acache, dns_db_t *origdb, + void (*callback)(dns_acacheentry_t *, void **), + void *cbarg, dns_acacheentry_t **entryp) +{ + dns_acacheentry_t *newentry; + isc_result_t result; + + REQUIRE(DNS_ACACHE_VALID(acache)); + REQUIRE(entryp != NULL && *entryp == NULL); + REQUIRE(origdb != NULL); + + newentry = isc_mem_get(acache->mctx, sizeof(*newentry)); + if (newentry == NULL) + return (ISC_R_NOMEMORY); + + result = isc_mutex_init(&newentry->lock); + if (result != ISC_R_SUCCESS) { + isc_mem_put(acache->mctx, newentry, sizeof(*newentry)); + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_mutex_init() failed: %s", + isc_result_totext(result)); + return (ISC_R_UNEXPECTED); + }; + /* + * We need two counters on creation: one for the caller, and one for + * the cache object. + */ + isc_refcount_init(&newentry->references, 2); + + ISC_LINK_INIT(newentry, link); + ISC_LINK_INIT(newentry, olink); + ISC_LINK_INIT(newentry, rlink); + + newentry->acache = NULL; + dns_acache_attach(acache, &newentry->acache); + + newentry->zone = NULL; + newentry->db = NULL; + newentry->version = NULL; + newentry->node = NULL; + newentry->foundname = NULL; + + newentry->callback = callback; + newentry->cbarg = cbarg; + newentry->origdb = NULL; + dns_db_attach(origdb, &newentry->origdb); + + isc_stdtime_get(&newentry->lastused); + + newentry->magic = ACACHEENTRY_MAGIC; + + *entryp = newentry; + + return (ISC_R_SUCCESS); +} + +isc_result_t +dns_acache_getentry(dns_acacheentry_t *entry, dns_zone_t **zonep, + dns_db_t **dbp, dns_dbversion_t **versionp, + dns_dbnode_t **nodep, dns_name_t *fname, + dns_message_t *msg, isc_stdtime_t now) +{ + isc_result_t result = ISC_R_SUCCESS; + dns_rdataset_t *erdataset; + + REQUIRE(DNS_ACACHEENTRY_VALID(entry)); + REQUIRE(zonep == NULL || *zonep == NULL); + REQUIRE(dbp != NULL && *dbp == NULL); + REQUIRE(versionp != NULL && *versionp == NULL); + REQUIRE(nodep != NULL && *nodep == NULL); + REQUIRE(fname != NULL); + REQUIRE(msg != NULL); + + LOCK(&entry->lock); + + entry->lastused = now; + + if (entry->zone != NULL && zonep != NULL) + dns_zone_attach(entry->zone, zonep); + + if (entry->db == NULL) { + *dbp = NULL; + *versionp = NULL; + } else { + dns_db_attach(entry->db, dbp); + dns_db_attachversion(entry->db, entry->version, versionp); + } + if (entry->node == NULL) + *nodep = NULL; + else { + dns_db_attachnode(entry->db, entry->node, nodep); + + INSIST(entry->foundname != NULL); + dns_name_copy(entry->foundname, fname, NULL); + for (erdataset = ISC_LIST_HEAD(entry->foundname->list); + erdataset != NULL; + erdataset = ISC_LIST_NEXT(erdataset, link)) { + dns_rdataset_t *ardataset; + + ardataset = NULL; + result = dns_message_gettemprdataset(msg, &ardataset); + if (result != ISC_R_SUCCESS) { + UNLOCK(&entry->lock); + goto fail; + } + + /* + * XXXJT: if we simply clone the rdataset, we'll get + * lost wrt cyclic ordering. We'll need an additional + * trick to get the latest counter from the original + * header. + */ + dns_rdataset_init(ardataset); + dns_rdataset_clone(erdataset, ardataset); + ISC_LIST_APPEND(fname->list, ardataset, link); + } + } + + UNLOCK(&entry->lock); + + return (result); + + fail: + while ((erdataset = ISC_LIST_HEAD(fname->list)) != NULL) { + ISC_LIST_UNLINK(fname->list, erdataset, link); + dns_rdataset_disassociate(erdataset); + dns_message_puttemprdataset(msg, &erdataset); + } + if (*nodep != NULL) + dns_db_detachnode(*dbp, nodep); + if (*versionp != NULL) + dns_db_closeversion(*dbp, versionp, ISC_FALSE); + if (*dbp != NULL) + dns_db_detach(dbp); + if (zonep != NULL && *zonep != NULL) + dns_zone_detach(zonep); + + return (result); +} + +isc_result_t +dns_acache_setentry(dns_acache_t *acache, dns_acacheentry_t *entry, + dns_zone_t *zone, dns_db_t *db, dns_dbversion_t *version, + dns_dbnode_t *node, dns_name_t *fname) +{ + isc_result_t result; + dbentry_t *odbent; + dbentry_t *rdbent = NULL; + isc_boolean_t close_version = ISC_FALSE; + + REQUIRE(DNS_ACACHE_VALID(acache)); + REQUIRE(DNS_ACACHEENTRY_VALID(entry)); + + LOCK(&acache->lock); /* XXX: need to lock it here for ordering */ + LOCK(&entry->lock); + + /* Set zone */ + if (zone != NULL) + dns_zone_attach(zone, &entry->zone); + /* Set DB */ + if (db != NULL) + dns_db_attach(db, &entry->db); + /* + * Set DB version. If the version is not given by the caller, + * which is the case for glue or cache DBs, use the current version. + */ + if (version == NULL) { + if (db != NULL) { + dns_db_currentversion(db, &version); + close_version = ISC_TRUE; + } + } + if (version != NULL) { + INSIST(db != NULL); + dns_db_attachversion(db, version, &entry->version); + } + if (close_version) + dns_db_closeversion(db, &version, ISC_FALSE); + /* Set DB node. */ + if (node != NULL) { + INSIST(db != NULL); + dns_db_attachnode(db, node, &entry->node); + } + + /* + * Set list of the corresponding rdatasets, if given. + * To minimize the overhead and memory consumption, we'll do this for + * positive cache only, in which case the DB node is non NULL. + * We do not want to cache incomplete information, so give up the + * entire entry when a memory shortage happen during the process. + */ + if (node != NULL) { + dns_rdataset_t *ardataset, *crdataset; + + entry->foundname = isc_mem_get(acache->mctx, + sizeof(*entry->foundname)); + + if (entry->foundname == NULL) { + result = ISC_R_NOMEMORY; + goto fail; + } + dns_name_init(entry->foundname, NULL); + result = dns_name_dup(fname, acache->mctx, + entry->foundname); + if (result != ISC_R_SUCCESS) + goto fail; + + for (ardataset = ISC_LIST_HEAD(fname->list); + ardataset != NULL; + ardataset = ISC_LIST_NEXT(ardataset, link)) { + crdataset = isc_mem_get(acache->mctx, + sizeof(*crdataset)); + if (crdataset == NULL) { + result = ISC_R_NOMEMORY; + goto fail; + } + + dns_rdataset_init(crdataset); + dns_rdataset_clone(ardataset, crdataset); + ISC_LIST_APPEND(entry->foundname->list, crdataset, + link); + } + } + + odbent = NULL; + result = finddbent(acache, entry->origdb, &odbent); + if (result != ISC_R_SUCCESS) + goto fail; + if (db != NULL) { + rdbent = NULL; + result = finddbent(acache, db, &rdbent); + if (result != ISC_R_SUCCESS) + goto fail; + } + + ISC_LIST_APPEND(acache->entries, entry, link); + ISC_LIST_APPEND(odbent->originlist, entry, olink); + if (rdbent != NULL) + ISC_LIST_APPEND(rdbent->referlist, entry, rlink); + + UNLOCK(&entry->lock); + UNLOCK(&acache->lock); + + return (ISC_R_SUCCESS); + + fail: + clear_entry(acache, entry); + + UNLOCK(&entry->lock); + UNLOCK(&acache->lock); + + return (result); +} + +void +dns_acache_cancelentry(dns_acacheentry_t *entry) { + dns_acache_t *acache = entry->acache; + + REQUIRE(DNS_ACACHEENTRY_VALID(entry)); + INSIST(DNS_ACACHE_VALID(acache)); + + LOCK(&acache->lock); + LOCK(&entry->lock); + + /* + * Release dependencies stored in this entry as much as possible. + * The main link cannot be released, since the acache object has + * a reference to this entry; the empty entry will be released in + * the next cleaning action. + */ + unlink_dbentries(acache, entry); + clear_entry(entry->acache, entry); + + entry->callback = NULL; + entry->cbarg = NULL; + + UNLOCK(&entry->lock); + UNLOCK(&acache->lock); +} + +void +dns_acache_attachentry(dns_acacheentry_t *source, + dns_acacheentry_t **targetp) +{ + REQUIRE(DNS_ACACHEENTRY_VALID(source)); + REQUIRE(targetp != NULL && *targetp == NULL); + + isc_refcount_increment(&source->references, NULL); + + *targetp = source; +} + +void +dns_acache_detachentry(dns_acacheentry_t **entryp) { + dns_acacheentry_t *entry; + unsigned int refs; + + REQUIRE(entryp != NULL && DNS_ACACHEENTRY_VALID(*entryp)); + entry = *entryp; + + isc_refcount_decrement(&entry->references, &refs); + + /* + * If there are no references to the entry, the entry must have been + * unlinked and can be destroyed safely. + */ + if (refs == 0) { + INSIST(!ISC_LINK_LINKED(entry, link)); + destroy_entry(entry); + } + + *entryp = NULL; +} + +void +dns_acache_setcleaninginterval(dns_acache_t *acache, unsigned int t) { + isc_interval_t interval; + isc_result_t result; + + REQUIRE(DNS_ACACHE_VALID(acache)); + + ATRACE("dns_acache_setcleaninginterval"); + + LOCK(&acache->lock); + + /* + * It may be the case that the acache has already shut down. + * If so, it has no timer. (Not sure if this can really happen.) + */ + if (acache->cleaner.cleaning_timer == NULL) + goto unlock; + + acache->cleaner.cleaning_interval = t; + + if (t == 0) { + result = isc_timer_reset(acache->cleaner.cleaning_timer, + isc_timertype_inactive, + NULL, NULL, ISC_TRUE); + } else { + isc_interval_set(&interval, acache->cleaner.cleaning_interval, + 0); + result = isc_timer_reset(acache->cleaner.cleaning_timer, + isc_timertype_ticker, + NULL, &interval, ISC_FALSE); + } + if (result != ISC_R_SUCCESS) + isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE, + DNS_LOGMODULE_ACACHE, ISC_LOG_WARNING, + "could not set acache cleaning interval: %s", + isc_result_totext(result)); + + unlock: + UNLOCK(&acache->lock); +} + +/* + * This function was derived from cache.c:dns_cache_setcachesize(). See the + * function for more details about the logic. + */ +void +dns_acache_setcachesize(dns_acache_t *acache, isc_uint32_t size) { + isc_uint32_t lowater; + isc_uint32_t hiwater; + + REQUIRE(DNS_ACACHE_VALID(acache)); + + if (size != 0 && size < DNS_ACACHE_MINSIZE) + size = DNS_ACACHE_MINSIZE; + + hiwater = size - (size >> 3); + lowater = size - (size >> 2); + + if (size == 0 || hiwater == 0 || lowater == 0) + isc_mem_setwater(acache->mctx, water, acache, 0, 0); + else + isc_mem_setwater(acache->mctx, water, acache, + hiwater, lowater); +} diff --git a/lib/dns/db.c b/lib/dns/db.c index c8033469af..a539ebdee4 100644 --- a/lib/dns/db.c +++ b/lib/dns/db.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: db.c,v 1.74 2004/03/05 05:09:18 marka Exp $ */ +/* $Id: db.c,v 1.75 2004/12/21 10:45:16 jinmei Exp $ */ /*** *** Imports @@ -791,3 +791,51 @@ dns_db_unregister(dns_dbimplementation_t **dbimp) { isc_mem_detach(&mctx); RWUNLOCK(&implock, isc_rwlocktype_write); } + +isc_result_t +dns_db_getsoanode(dns_db_t *db, dns_dbnode_t **nodep) { + REQUIRE(DNS_DB_VALID(db)); + REQUIRE(dns_db_iszone(db) == ISC_TRUE); + REQUIRE(nodep != NULL && *nodep == NULL); + + if (db->methods->getsoanode != NULL) + return ((db->methods->getsoanode)(db, nodep)); + + return (ISC_R_NOTFOUND); +} + +isc_result_t +dns_db_setsoanode(dns_db_t *db, dns_dbnode_t *node) { + REQUIRE(DNS_DB_VALID(db)); + REQUIRE(dns_db_iszone(db) == ISC_TRUE); + REQUIRE(node != NULL); + + if (db->methods->setsoanode != NULL) + return ((db->methods->setsoanode)(db, node)); + + return (ISC_R_FAILURE); +} + +isc_result_t +dns_db_getnsnode(dns_db_t *db, dns_dbnode_t **nodep) { + REQUIRE(DNS_DB_VALID(db)); + REQUIRE(dns_db_iszone(db) == ISC_TRUE); + REQUIRE(nodep != NULL && *nodep == NULL); + + if (db->methods->getnsnode != NULL) + return ((db->methods->getnsnode)(db, nodep)); + + return (ISC_R_NOTFOUND); +} + +isc_result_t +dns_db_setnsnode(dns_db_t *db, dns_dbnode_t *node) { + REQUIRE(DNS_DB_VALID(db)); + REQUIRE(dns_db_iszone(db) == ISC_TRUE); + REQUIRE(node != NULL); + + if (db->methods->setnsnode != NULL) + return ((db->methods->setnsnode)(db, node)); + + return (ISC_R_FAILURE); +} diff --git a/lib/dns/include/dns/acache.h b/lib/dns/include/dns/acache.h new file mode 100644 index 0000000000..2969f77cbc --- /dev/null +++ b/lib/dns/include/dns/acache.h @@ -0,0 +1,440 @@ +/* + * Copyright (C) 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 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. + */ + +/* $Id: acache.h,v 1.2 2004/12/21 10:45:18 jinmei Exp $ */ + +#ifndef DNS_ACACHE_H +#define DNS_ACACHE_H 1 + +/***** + ***** Module Info + *****/ + +/* + * Acache + * + * The Additional Cache Object + * + * This module manages internal caching entries that correspond to + * the additional section data of a DNS DB node (an RRset header, more + * accurately). An additional cache entry is expected to be (somehow) + * attached to a particular RR in a particular DB node, and contains a set + * of information of an additional data for the DB node. + * + * An additional cache object is intended to be created as a per-view + * object, and manages all cache entries within the view. + * + * The intended usage of the additional caching is to provide a short cut + * to additional glue RRs of an NS RR. For each NS RR, it is often + * necessary to look for glue RRs to make a proper response. Once the + * glue RRs are known, the additional caching allows the client to + * associate the information to the original NS RR so that further + * expensive lookups can be avoided for the NS RR. + * + * Each additional cache entry contains information to identify a + * particular DB node and (optionally) an associated RRset. The + * information consists of its zone, database, the version of the + * database, database node, and RRset. + * + * A "negative" information can also be cached. For example, if a glue + * RR does not exist as an authoritative data in the same zone as that + * of the NS RR, this fact can be cached by specifying a NULL pointer + * for the database, version, and node. (See the description for + * dns_acache_getentry() below for more details.) + * + * Since each member stored in an additional cache entry holds a reference + * to a corresponding object, a stale cache entry may cause unnecessary + * memory consumption. For instance, when a zone is reloaded, additional + * cache entries that have a reference to the zone (and its DB and/or + * DB nodes) can delay the cleanup of the referred objects. In order to + * minimize such a bad effect, this module provides several cleanup + * mechanisms. + * + * The first one is a shutdown procedure called when the associated view + * is shut down. In this case, dns_acache_shutdown() will be called and + * all cache entries will be purged. This mechanism will help the + * situation when the configuration is reloaded or the main server is + * stopped. + * + * Per-DB cleanup mechanism is also provided. Each additional cache entry + * is associated with related DB, which is expected to have been + * registered when the DB was created by dns_acache_setdb(). If a + * particular DB is going to be destroyed, the primary holder of the DB, + * a typical example of which is a zone, will call dns_acache_putdb(). + * Then this module will clean-up all cache entries associated with the + * DB. This mechanism is effective when a secondary zone DB is going to + * be stale after a zone transfer. + * + * Finally, this module supports for periodic clean-up of stale entries. + * Each cache entry has a timestamp field, which is updated every time + * the entry is referred. A periodically invoked cleaner checks the + * timestamp of each entry, and purge entries that have not been referred + * for a certain period. The cleaner interval can be specified by + * dns_acache_setcleaninginterval(). If the periodic clean-up is not + * enough, it is also possible to specify the upper limit of entries + * in terms of the memory consumption. If the maximum value is + * specified, the cleaner is invoked when the memory consumption reaches + * the high watermark inferred from the maximum value. In this case, + * the cleaner will use more aggressive algorithm to decide the "victim" + * entries. The maximum value can be specified by + * dns_acache_setcachesize(). + * + * When a cache entry is going to be purged within this module, the + * callback function specified at the creation time will be called. + * The callback function is expected to release all internal resources + * related to the entry, which will typically be specific to DB + * implementation, and to call dns_acache_detachentry(). The callback + * mechanism is very important, since the holder of an additional cache + * entry may not be able to initiate the clean-up of the entry, due to + * the reference ordering. For example, as long as an additional cache + * entry has a reference to a DB object, the DB cannot be freed, in which + * a DB node may have a reference to the cache entry. + * + * Credits: + * The basic idea of this kind of short-cut for frequently used + * information is similar to the "pre-compiled answer" approach adopted + * in nsd by NLnet LABS with RIPE NCC. Our work here is an independent + * effort, but the success of nsd encouraged us to pursue this path. + * + * The design and implementation of the periodic memory management and + * the upper limitation of memory consumption was derived from the cache + * DB implementation of BIND9. + * + * MP: + * There are two main locks in this module. One is for each entry, and + * the other is for the additional cache object. + * + * Reliability: + * The callback function for a cache entry is called with holding the + * entry lock. Thus, it implicitly assumes the callback function does not + * call a function that can require the lock. Typically, the only + * function that can be called from the callback function safely is + * dns_acache_detachentry(). The breakage of this implicit assumption + * may cause a deadlock. + * + * Resources: + * In a 32-bit architecture (such as i386), the following additional + * memory is required comparing to the case that disables this module. + * - 76 bytes for each additional cache entry + * - if the entry has a DNS name and associated RRset, + * * 44 bytes + size of the name (1-255 bytes) + * * 52 bytes x number_of_RRs + * - 28 bytes for each DB related to this module + * + * Using the additional cache also requires extra memory consumption in + * the DB implementation. In the current implementation for rbtdb, we + * need: + * - two additional pointers for each DB node (8 bytes for a 32-bit + * architecture + * - for each RR associated to an RR in a DB node, we also need + * a pointer and management objects to support the additional cache + * function. These are allocated on-demand. The total size is + * 32 bytes for a 32-bit architecture. + * + * Security: + * Since this module does not handle any low-level data directly, + * no security issue specific to this module is anticipated. + * + * Standards: + * None. + */ + +/*** + *** Imports + ***/ + +#include +#include +#include +#include + +#include + +/*** + *** Functions + ***/ +ISC_LANG_BEGINDECLS + +isc_result_t +dns_acache_create(dns_acache_t **acachep, isc_mem_t *mctx, + isc_taskmgr_t *taskmgr, isc_timermgr_t *timermgr); +/* + * Create a new DNS additional cache object. + * + * Requires: + * + * 'mctx' is a valid memory context + * + * 'taskmgr' is a valid task manager + * + * 'timermgr' is a valid timer or NULL. If NULL, no periodic cleaning of + * the cache will take place. + * + * 'acachep' is a valid pointer, and *acachep == NULL + * + * Ensures: + * + * '*acachep' is attached to the newly created cache + * + * Returns: + * + * ISC_R_SUCCESS + * ISC_R_NOMEMORY + * ISC_R_UNEXPECTED + */ + +void +dns_acache_attach(dns_acache_t *source, dns_acache_t **targetp); +/* + * Attach *targetp to cache. + * + * Requires: + * + * 'acache' is a valid additional cache. + * + * 'targetp' points to a NULL dns_acache_t *. + * + * Ensures: + * + * *targetp is attached to the 'source' additional cache. + */ + +void +dns_acache_detach(dns_acache_t **acachep); +/* + * Detach *acachep from its cache. + * + * Requires: + * + * '*acachep' points to a valid additional cache. + * + * Ensures: + * + * *acachep is NULL. + * + * If '*acachep' is the last reference to the cache and the additional + * cache does not have an outstanding task, all resources used by the + * cache will be freed. + */ + +void +dns_acache_setcleaninginterval(dns_acache_t *acache, unsigned int t); +/* + * Set the periodic cleaning interval of an additional cache to 'interval' + * seconds. + */ + +void +dns_acache_setcachesize(dns_acache_t *acache, isc_uint32_t size); +/* + * Set the maximum additional cache size. 0 means unlimited. + */ + +isc_result_t +dns_acache_setdb(dns_acache_t *acache, dns_db_t *db); +/* + * Set 'db' in 'acache' when the db can be referred from acache, in order + * to provide a hint for resolving the back reference. + * + * Requires: + * 'acache' is a valid acache pointer. + * 'db' is a valid DNS DB pointer. + * + * Ensures: + * 'acache' will have a reference to 'db'. + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_EXISTS (which means the specified 'db' is already set) + * ISC_R_NOMEMORY + */ + +isc_result_t +dns_acache_putdb(dns_acache_t *acache, dns_db_t *db); +/* + * Release 'db' from 'acache' if it has been set by dns_acache_setdb(). + * + * Requires: + * 'acache' is a valid acache pointer. + * 'db' is a valid DNS DB pointer. + * + * Ensures: + * 'acache' will release the reference to 'db'. Additionally, the content + * of each cache entry that is related to the 'db' will be released via + * the callback function. + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_NOTFOUND (which means the specified 'db' is not set in 'acache') + * ISC_R_NOMEMORY + */ + +void +dns_acache_shutdown(dns_acache_t *acache); +/* + * Shutdown 'acache'. + * + * Requires: + * + * '*acache' is a valid additional cache. + */ + +isc_result_t +dns_acache_createentry(dns_acache_t *acache, dns_db_t *origdb, + void (*callback)(dns_acacheentry_t *, void **), + void *cbarg, dns_acacheentry_t **entryp); +/* + * Create an additional cache entry. A new entry is created and attached to + * the given additional cache object. A callback function is also associated + * with the created entry, which will be called when the cache entry is purged + * for some reason. + * + * Requires: + * + * 'acache' is a valid additional cache. + * 'entryp' is a valid pointer, and *entryp == NULL + * 'origdb' is a valid DNS DB pointer. + * 'callback' and 'cbarg' can be NULL. In this case, however, the entry + * is meaningless (and will be cleaned-up in the next periodical + * cleaning). + * + * Ensures: + * '*entryp' will point to a new additional cache entry. + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_NOMEMORY + */ + +isc_result_t +dns_acache_getentry(dns_acacheentry_t *entry, dns_zone_t **zonep, + dns_db_t **dbp, dns_dbversion_t **versionp, + dns_dbnode_t **nodep, dns_name_t *fname, + dns_message_t *msg, isc_stdtime_t now); +/* + * Get content from a particular additional cache entry. + * + * Requires: + * + * 'entry' is a valid additional cache entry. + * 'zonep' is a NULL pointer or '*zonep' == NULL (this is the only + * optional parameter.) + * 'dbp' is a valid pointer, and '*dbp' == NULL + * 'versionp' is a valid pointer, and '*versionp' == NULL + * 'nodep' is a valid pointer, and '*nodep' == NULL + * 'fname' is a valid DNS name. + * 'msg' is a valid DNS message. + * + * Ensures: + * Several possible cases can happen according to the content. + * 1. For a positive cache entry, + * '*zonep' will point to the corresponding zone (if zonep is a valid + * pointer), + * '*dbp' will point to a DB for the zone, + * '*versionp' will point to its version, and + * '*nodep' will point to the corresponding DB node. + * 'fname' will have the DNS name of the DB node and contain a list of + * rdataset for the node (which can be an empty list). + * + * 2. For a negative cache entry that means no corresponding zone exists, + * '*zonep' == NULL (if zonep is a valid pointer) + * '*dbp', '*versionp', and '*nodep' will be NULL. + * + * 3. For a negative cache entry that means no corresponding DB node + * exists, '*zonep' will point to the corresponding zone (if zonep is a + * valid pointer), + * '*dbp' will point to a corresponding DB for zone, + * '*versionp' will point to its version. + * '*nodep' will be kept as NULL. + * 'fname' will not change. + * + * On failure, no new references will be created. + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_NOMEMORY + */ + +isc_result_t +dns_acache_setentry(dns_acache_t *acache, dns_acacheentry_t *entry, + dns_zone_t *zone, dns_db_t *db, dns_dbversion_t *version, + dns_dbnode_t *node, dns_name_t *fname); +/* + * Set content to a particular additional cache entry. + * + * Requires: + * 'acache' is a valid additional cache. + * 'entry' is a valid additional cache entry. + * All the others pointers are NULL or a valid pointer of the + * corresponding type. + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_NOMEMORY + * ISC_R_NOTFOUND + */ + +void +dns_acache_cancelentry(dns_acacheentry_t *entry); +/* + * Cancel the use of the cache entry 'entry'. This function is supposed to + * be called when the node that holds the entry finds the content is not + * correct any more. This function will try to release as much dependency as + * possible, and will be ready to be cleaned-up. The registered callback + * function will be canceled and will never called. + * + * Requires: + * 'entry' is a valid additional cache entry. + */ + +void +dns_acache_attachentry(dns_acacheentry_t *source, dns_acacheentry_t **targetp); +/* + * Attach *targetp to the cache entry 'source'. + * + * Requires: + * + * 'source' is a valid additional cache entry. + * + * 'targetp' points to a NULL dns_acacheentry_t *. + * + * Ensures: + * + * *targetp is attached to 'source'. + */ + +void +dns_acache_detachentry(dns_acacheentry_t **entryp); +/* + * Detach *entryp from its cache. + * + * Requires: + * + * '*entryp' points to a valid additional cache entry. + * + * Ensures: + * + * *entryp is NULL. + * + * If '*entryp' is the last reference to the entry, + * cache does not have an outstanding task, all resources used by the + * entry (including the entry object itself) will be freed. + */ + +ISC_LANG_ENDDECLS + +#endif /* DNS_ACACHE_H */ diff --git a/lib/dns/include/dns/db.h b/lib/dns/include/dns/db.h index b4c7261da5..c94dc4f930 100644 --- a/lib/dns/include/dns/db.h +++ b/lib/dns/include/dns/db.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: db.h,v 1.77 2004/05/14 04:45:57 marka Exp $ */ +/* $Id: db.h,v 1.78 2004/12/21 10:45:18 jinmei Exp $ */ #ifndef DNS_DB_H #define DNS_DB_H 1 @@ -145,6 +145,10 @@ typedef struct dns_dbmethods { isc_boolean_t (*ispersistent)(dns_db_t *db); void (*overmem)(dns_db_t *db, isc_boolean_t overmem); void (*settask)(dns_db_t *db, isc_task_t *); + isc_result_t (*getsoanode)(dns_db_t *db, dns_dbnode_t **nodep); + isc_result_t (*setsoanode)(dns_db_t *db, dns_dbnode_t *nodep); + isc_result_t (*getnsnode)(dns_db_t *db, dns_dbnode_t **nodep); + isc_result_t (*setnsnode)(dns_db_t *db, dns_dbnode_t *nodep); } dns_dbmethods_t; typedef isc_result_t @@ -1266,6 +1270,84 @@ dns_db_unregister(dns_dbimplementation_t **dbimp); * Any memory allocated in *dbimp will be freed. */ +isc_result_t +dns_db_getsoanode(dns_db_t *db, dns_dbnode_t **nodep); +/* + * Get a cached SOA DB node corresponding to the DB's zone. + * + * Requires: + * + * 'db' is a valid zone database. + * 'nodep' != NULL && '*nodep' == NULL + * + * Ensures: + * On sucess, '*nodep' will point to a DB node for the SOA RR of 'db.' + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_NOTFOUND - an SOA RR node has not been cached in 'db' or SOA RR + * caching is not supported for 'db' + */ + +isc_result_t +dns_db_setsoanode(dns_db_t *db, dns_dbnode_t *node); +/* + * Set an SOA DB node as cache corresponding to the DB's zone. If there is + * already a node set in the DB, it will be detached and replaced with the + * new one. + * + * Requires: + * + * 'db' is a valid zone database. + * 'node' is a valid DB node. + * + * Ensures: + * On sucess, '*nodep' will point to a DB node for the SOA RR of 'db.' + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_FAILURE - SOA RR caching is not supported for 'db' + */ + +isc_result_t +dns_db_getnsnode(dns_db_t *db, dns_dbnode_t **nodep); +/* + * Get a cached NS DB node corresponding to the DB's zone. + * + * Requires: + * + * 'db' is a valid zone database. + * 'nodep' != NULL && '*nodep' == NULL + * + * Ensures: + * On sucess, '*nodep' will point to a DB node for the NS RR of 'db.' + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_NOTFOUND - an NS RR node has not been cached in 'db' or NS RR + * caching is not supported for 'db' + */ + +isc_result_t +dns_db_setnsnode(dns_db_t *db, dns_dbnode_t *node); +/* + * Set an NS DB node as cache corresponding to the DB's zone. If there is + * already a node set in the DB, it will be detached and replaced with the + * new one. + * + * Requires: + * + * 'db' is a valid zone database. + * 'node' is a valid DB node. + * + * Ensures: + * On sucess, '*nodep' will point to a DB node for the NS RR of 'db.' + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_FAILURE - NS RR caching is not supported for 'db' + */ + ISC_LANG_ENDDECLS #endif /* DNS_DB_H */ diff --git a/lib/dns/include/dns/events.h b/lib/dns/include/dns/events.h index 0c56291485..9f8ffd13cc 100644 --- a/lib/dns/include/dns/events.h +++ b/lib/dns/include/dns/events.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: events.h,v 1.42 2004/03/05 05:09:42 marka Exp $ */ +/* $Id: events.h,v 1.43 2004/12/21 10:45:19 jinmei Exp $ */ #ifndef DNS_EVENTS_H #define DNS_EVENTS_H 1 @@ -63,6 +63,10 @@ #define DNS_EVENT_DUMPQUANTUM (ISC_EVENTCLASS_DNS + 34) #define DNS_EVENT_IMPORTRECVDONE (ISC_EVENTCLASS_DNS + 35) #define DNS_EVENT_FREESTORAGE (ISC_EVENTCLASS_DNS + 36) +#define DNS_EVENT_VIEWACACHESHUTDOWN (ISC_EVENTCLASS_DNS + 37) +#define DNS_EVENT_ACACHECONTROL (ISC_EVENTCLASS_DNS + 38) +#define DNS_EVENT_ACACHECLEAN (ISC_EVENTCLASS_DNS + 39) +#define DNS_EVENT_ACACHEOVERMEM (ISC_EVENTCLASS_DNS + 40) #define DNS_EVENT_FIRSTEVENT (ISC_EVENTCLASS_DNS + 0) #define DNS_EVENT_LASTEVENT (ISC_EVENTCLASS_DNS + 65535) diff --git a/lib/dns/include/dns/log.h b/lib/dns/include/dns/log.h index dc1fa8c88f..514d31aa1e 100644 --- a/lib/dns/include/dns/log.h +++ b/lib/dns/include/dns/log.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: log.h,v 1.33 2004/03/05 05:09:43 marka Exp $ */ +/* $Id: log.h,v 1.34 2004/12/21 10:45:19 jinmei Exp $ */ /* Principal Authors: DCL */ @@ -69,6 +69,7 @@ LIBDNS_EXTERNAL_DATA extern isc_logmodule_t dns_modules[]; #define DNS_LOGMODULE_SDB (&dns_modules[22]) #define DNS_LOGMODULE_DIFF (&dns_modules[23]) #define DNS_LOGMODULE_HINTS (&dns_modules[24]) +#define DNS_LOGMODULE_ACACHE (&dns_modules[25]) ISC_LANG_BEGINDECLS diff --git a/lib/dns/include/dns/rdataset.h b/lib/dns/include/dns/rdataset.h index ee61b9b549..a286600bad 100644 --- a/lib/dns/include/dns/rdataset.h +++ b/lib/dns/include/dns/rdataset.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rdataset.h,v 1.51 2004/03/05 05:09:45 marka Exp $ */ +/* $Id: rdataset.h,v 1.52 2004/12/21 10:45:19 jinmei Exp $ */ #ifndef DNS_RDATASET_H #define DNS_RDATASET_H 1 @@ -54,11 +54,18 @@ #include #include +#include #include ISC_LANG_BEGINDECLS +typedef enum { + dns_rdatasetadditional_fromauth, + dns_rdatasetadditional_fromcache, + dns_rdatasetadditional_fromglue +} dns_rdatasetadditional_t; + typedef struct dns_rdatasetmethods { void (*disassociate)(dns_rdataset_t *rdataset); isc_result_t (*first)(dns_rdataset_t *rdataset); @@ -74,6 +81,30 @@ typedef struct dns_rdatasetmethods { dns_name_t *name, dns_rdataset_t *nsec, dns_rdataset_t *nsecsig); + isc_result_t (*getadditional)(dns_rdataset_t *rdataset, + dns_rdatasetadditional_t type, + dns_rdatatype_t qtype, + dns_acache_t *acache, + dns_zone_t **zonep, + dns_db_t **dbp, + dns_dbversion_t **versionp, + dns_dbnode_t **nodep, + dns_name_t *fname, + dns_message_t *msg, + isc_stdtime_t now); + isc_result_t (*setadditional)(dns_rdataset_t *rdataset, + dns_rdatasetadditional_t type, + dns_rdatatype_t qtype, + dns_acache_t *acache, + dns_zone_t *zone, + dns_db_t *db, + dns_dbversion_t *version, + dns_dbnode_t *node, + dns_name_t *fname); + isc_result_t (*putadditional)(dns_acache_t *acache, + dns_rdataset_t *rdataset, + dns_rdatasetadditional_t type, + dns_rdatatype_t qtype); } dns_rdatasetmethods_t; #define DNS_RDATASET_MAGIC ISC_MAGIC('D','N','S','R') @@ -409,7 +440,6 @@ dns_rdataset_towirepartial(dns_rdataset_t *rdataset, * written. */ - isc_result_t dns_rdataset_additionaldata(dns_rdataset_t *rdataset, dns_additionaldatafunc_t add, void *arg); @@ -463,6 +493,100 @@ dns_rdataset_addnoqname(dns_rdataset_t *rdataset, dns_name_t *name); * 'name' to be valid and have NSEC and RRSIG(NSEC) rdatasets. */ +isc_result_t +dns_rdataset_getadditional(dns_rdataset_t *rdataset, + dns_rdatasetadditional_t type, + dns_rdatatype_t qtype, + dns_acache_t *acache, + dns_zone_t **zonep, + dns_db_t **dbp, + dns_dbversion_t **versionp, + dns_dbnode_t **nodep, + dns_name_t *fname, + dns_message_t *msg, + isc_stdtime_t now); +/* + * Get cached additional information from the DB node for a particular + * 'rdataset.' 'type' is one of dns_rdatasetadditional_fromauth, + * dns_rdatasetadditional_fromcache, and dns_rdatasetadditional_fromglue, + * which specifies the origin of the information. 'qtype' is intended to + * be used for specifying a particular rdata type in the cached information. + * + * Requires: + * 'rdataset' is a valid rdataset. + * 'acache' can be NULL, in which case this function will simply return + * ISC_R_FAILURE. + * For the other pointers, see dns_acache_getentry(). + * + * Ensures: + * See dns_acache_getentry(). + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_FAILURE - additional information caching is not supported. + * ISC_R_NOTFOUND - the corresponding DB node has not cached additional + * information for 'rdataset.' + * + * Any error that dns_acache_getentry() can return. + */ + +isc_result_t +dns_rdataset_setadditional(dns_rdataset_t *rdataset, + dns_rdatasetadditional_t type, + dns_rdatatype_t qtype, + dns_acache_t *acache, + dns_zone_t *zone, + dns_db_t *db, + dns_dbversion_t *version, + dns_dbnode_t *node, + dns_name_t *fname); +/* + * Set cached additional information to the DB node for a particular + * 'rdataset.' See dns_rdataset_getadditional for the semantics of 'type' + * and 'qtype'. + * + * Requires: + * 'rdataset' is a valid rdataset. + * 'acache' can be NULL, in which case this function will simply return + * ISC_R_FAILURE. + * For the other pointers, see dns_acache_setentry(). + * + * Ensures: + * See dns_acache_setentry(). + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_FAILURE - additional information caching is not supported. + * ISC_R_NOMEMORY + * + * Any error that dns_acache_setentry() can return. + */ + +isc_result_t +dns_rdataset_putadditional(dns_acache_t *acache, + dns_rdataset_t *rdataset, + dns_rdatasetadditional_t type, + dns_rdatatype_t qtype); +/* + * Discard cached additional information stored in the DB node for a particular + * 'rdataset.' See dns_rdataset_getadditional for the semantics of 'type' + * and 'qtype'. + * + * Requires: + * 'rdataset' is a valid rdataset. + * 'acache' can be NULL, in which case this function will simply return + * ISC_R_FAILURE. + * + * Ensures: + * See dns_acache_cancelentry(). + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_FAILURE - additional information caching is not supported. + * ISC_R_NOTFOUND - the corresponding DB node has not cached additional + * information for 'rdataset.' + */ + ISC_LANG_ENDDECLS #endif /* DNS_RDATASET_H */ diff --git a/lib/dns/include/dns/types.h b/lib/dns/include/dns/types.h index 42e8314252..625380b417 100644 --- a/lib/dns/include/dns/types.h +++ b/lib/dns/include/dns/types.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: types.h,v 1.110 2004/03/30 02:13:44 marka Exp $ */ +/* $Id: types.h,v 1.111 2004/12/21 10:45:19 jinmei Exp $ */ #ifndef DNS_TYPES_H #define DNS_TYPES_H 1 @@ -30,6 +30,8 @@ #include +typedef struct dns_acache dns_acache_t; +typedef struct dns_acacheentry dns_acacheentry_t; typedef struct dns_acl dns_acl_t; typedef struct dns_aclelement dns_aclelement_t; typedef struct dns_aclenv dns_aclenv_t; diff --git a/lib/dns/include/dns/view.h b/lib/dns/include/dns/view.h index e46085b617..4570cfc70b 100644 --- a/lib/dns/include/dns/view.h +++ b/lib/dns/include/dns/view.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: view.h,v 1.91 2004/03/10 02:19:56 marka Exp $ */ +/* $Id: view.h,v 1.92 2004/12/21 10:45:19 jinmei Exp $ */ #ifndef DNS_VIEW_H #define DNS_VIEW_H 1 @@ -86,6 +86,7 @@ struct dns_view { dns_resolver_t * resolver; dns_adb_t * adb; dns_requestmgr_t * requestmgr; + dns_acache_t * acache; dns_cache_t * cache; dns_db_t * cachedb; dns_db_t * hints; diff --git a/lib/dns/include/dns/zone.h b/lib/dns/include/dns/zone.h index 2316c259b1..28337a68f8 100644 --- a/lib/dns/include/dns/zone.h +++ b/lib/dns/include/dns/zone.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.h,v 1.127 2004/10/26 02:01:19 marka Exp $ */ +/* $Id: zone.h,v 1.128 2004/12/21 10:45:19 jinmei Exp $ */ #ifndef DNS_ZONE_H #define DNS_ZONE_H 1 @@ -1432,6 +1432,19 @@ dns_zone_checknames(dns_zone_t *zone, dns_name_t *name, dns_rdata_t *rdata); * DNS_R_BADNAME failed rdata checks. */ +void +dns_zone_setacache(dns_zone_t *zone, dns_acache_t *acache); +/* + * Associate the zone with an additional cache. + * + * Require: + * 'zone' to be a valid zone. + * 'acache' to be a non NULL pointer. + * + * Ensures: + * 'zone' will have a reference to 'acache' + */ + ISC_LANG_ENDDECLS #endif /* DNS_ZONE_H */ diff --git a/lib/dns/log.c b/lib/dns/log.c index a37d05aef6..0ce419f18c 100644 --- a/lib/dns/log.c +++ b/lib/dns/log.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: log.c,v 1.36 2004/03/05 05:09:20 marka Exp $ */ +/* $Id: log.c,v 1.37 2004/12/21 10:45:16 jinmei Exp $ */ /* Principal Authors: DCL */ @@ -74,6 +74,7 @@ LIBDNS_EXTERNAL_DATA isc_logmodule_t dns_modules[] = { { "dns/sdb", 0 }, { "dns/diff", 0 }, { "dns/hints", 0 }, + { "dns/acache", 0 }, { NULL, 0 } }; diff --git a/lib/dns/ncache.c b/lib/dns/ncache.c index 5e1c87fe2e..5bec301b95 100644 --- a/lib/dns/ncache.c +++ b/lib/dns/ncache.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: ncache.c,v 1.36 2004/03/05 05:09:21 marka Exp $ */ +/* $Id: ncache.c,v 1.37 2004/12/21 10:45:17 jinmei Exp $ */ #include @@ -473,6 +473,9 @@ static dns_rdatasetmethods_t rdataset_methods = { rdataset_clone, rdataset_count, NULL, + NULL, + NULL, + NULL, NULL }; diff --git a/lib/dns/rbtdb.c b/lib/dns/rbtdb.c index 93aaa593e9..30959ddaa5 100644 --- a/lib/dns/rbtdb.c +++ b/lib/dns/rbtdb.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rbtdb.c,v 1.200 2004/05/23 06:59:20 marka Exp $ */ +/* $Id: rbtdb.c,v 1.201 2004/12/21 10:45:17 jinmei Exp $ */ /* * Principal Author: Bob Halley @@ -34,6 +34,7 @@ #include #include +#include #include #include #include @@ -46,6 +47,8 @@ #include #include #include +#include +#include #include #ifdef DNS_RBTDB_VERSION64 @@ -103,6 +106,8 @@ struct noqname { void * nsecsig; }; +typedef struct acachectl acachectl_t; + typedef struct rdatasetheader { /* * Locked by the owning node's lock. @@ -140,6 +145,9 @@ typedef struct rdatasetheader { * should not be so crucial, no lock is set for the counter for * performance reasons. */ + + acachectl_t *additional_auth; + acachectl_t *additional_glue; } rdatasetheader_t; #define RDATASET_ATTR_NONEXISTENT 0x0001 @@ -148,6 +156,19 @@ typedef struct rdatasetheader { #define RDATASET_ATTR_RETAIN 0x0008 #define RDATASET_ATTR_NXDOMAIN 0x0010 +typedef struct acache_cbarg { + dns_rdatasetadditional_t type; + unsigned int count; + dns_db_t *db; + dns_dbnode_t *node; + rdatasetheader_t *header; +} acache_cbarg_t; + +struct acachectl { + dns_acacheentry_t *entry; + acache_cbarg_t *cbarg; +}; + /* * XXX * When the cache will pre-expire data (due to memory low or other @@ -219,6 +240,8 @@ typedef struct { rbtdb_versionlist_t open_versions; isc_boolean_t overmem; isc_task_t * task; + dns_dbnode_t *soanode; + dns_dbnode_t *nsnode; /* Locked by tree_lock. */ dns_rbt_t * tree; isc_boolean_t secure; @@ -264,6 +287,30 @@ static isc_result_t rdataset_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name, dns_rdataset_t *nsec, dns_rdataset_t *nsecsig); +static isc_result_t rdataset_getadditional(dns_rdataset_t *rdataset, + dns_rdatasetadditional_t type, + dns_rdatatype_t qtype, + dns_acache_t *acache, + dns_zone_t **zonep, + dns_db_t **dbp, + dns_dbversion_t **versionp, + dns_dbnode_t **nodep, + dns_name_t *fname, + dns_message_t *msg, + isc_stdtime_t now); +static isc_result_t rdataset_setadditional(dns_rdataset_t *rdataset, + dns_rdatasetadditional_t type, + dns_rdatatype_t qtype, + dns_acache_t *acache, + dns_zone_t *zone, + dns_db_t *db, + dns_dbversion_t *version, + dns_dbnode_t *node, + dns_name_t *fname); +static isc_result_t rdataset_putadditional(dns_acache_t *acache, + dns_rdataset_t *rdataset, + dns_rdatasetadditional_t type, + dns_rdatatype_t qtype); static dns_rdatasetmethods_t rdataset_methods = { rdataset_disassociate, @@ -273,7 +320,10 @@ static dns_rdatasetmethods_t rdataset_methods = { rdataset_clone, rdataset_count, NULL, - rdataset_getnoqname + rdataset_getnoqname, + rdataset_getadditional, + rdataset_setadditional, + rdataset_putadditional }; static void rdatasetiter_destroy(dns_rdatasetiter_t **iteratorp); @@ -468,6 +518,11 @@ maybe_free_rbtdb(dns_rbtdb_t *rbtdb) { /* XXX check for open versions here */ + if (rbtdb->soanode != NULL) + dns_db_detachnode((dns_db_t *)rbtdb, &rbtdb->soanode); + if (rbtdb->nsnode != NULL) + dns_db_detachnode((dns_db_t *)rbtdb, &rbtdb->nsnode); + /* * Even though there are no external direct references, there still * may be nodes in use. @@ -631,6 +686,35 @@ add_changed(dns_rbtdb_t *rbtdb, rbtdb_version_t *version, return (changed); } +static void +free_acachearray(isc_mem_t *mctx, rdatasetheader_t *header, + acachectl_t *array) +{ + unsigned int count; + unsigned int i; + unsigned char *raw; + + /* + * The caller must be holding the corresponding node lock. + */ + + if (array == NULL) + return; + + raw = (unsigned char *)header + sizeof(*header); + count = raw[0] * 256 + raw[1]; + + /* + * Sanity check: since an additional cache entry has a reference to + * the original DB node (in the callback arg), there should be no + * acache entries when the node can be freed. + */ + for (i = 0; i < count; i++) + INSIST(array[i].entry == NULL && array[i].cbarg == NULL); + + isc_mem_put(mctx, array, count * sizeof(acachectl_t)); +} + static inline void free_noqname(isc_mem_t *mctx, struct noqname **noqname) { @@ -652,7 +736,10 @@ free_rdataset(isc_mem_t *mctx, rdatasetheader_t *rdataset) { if (rdataset->noqname != NULL) free_noqname(mctx, &rdataset->noqname); - + + free_acachearray(mctx, rdataset, rdataset->additional_auth); + free_acachearray(mctx, rdataset, rdataset->additional_glue); + if ((rdataset->attributes & RDATASET_ATTR_NONEXISTENT) != 0) size = sizeof(*rdataset); else @@ -4265,6 +4352,8 @@ addrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version, newheader->noqname = NULL; newheader->count = 0; newheader->trust = rdataset->trust; + newheader->additional_auth = NULL; + newheader->additional_glue = NULL; if (rbtversion != NULL) { newheader->serial = rbtversion->serial; now = 0; @@ -4338,6 +4427,8 @@ subtractrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version, newheader->trust = 0; newheader->noqname = NULL; newheader->count = 0; + newheader->additional_auth = NULL; + newheader->additional_glue = NULL; LOCK(&rbtdb->node_locks[rbtnode->locknum].lock); @@ -4390,6 +4481,13 @@ subtractrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version, * header, not newheader. */ newheader->serial = rbtversion->serial; + /* + * XXXJT: dns_rdataslab_subtract() copied the pointers + * to additional info. We need to clear these fields + * to avoid having duplicated references. + */ + newheader->additional_auth = NULL; + newheader->additional_glue = NULL; } else if (result == DNS_R_NXRRSET) { /* * This subtraction would remove all of the rdata; @@ -4409,6 +4507,8 @@ subtractrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version, newheader->serial = rbtversion->serial; newheader->noqname = NULL; newheader->count = 0; + newheader->additional_auth = NULL; + newheader->additional_glue = NULL; } else { free_rdataset(rbtdb->common.mctx, newheader); goto unlock; @@ -4474,6 +4574,8 @@ deleterdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version, newheader->attributes = RDATASET_ATTR_NONEXISTENT; newheader->trust = 0; newheader->noqname = NULL; + newheader->additional_auth = NULL; + newheader->additional_glue = NULL; if (rbtversion != NULL) newheader->serial = rbtversion->serial; else @@ -4556,6 +4658,8 @@ loading_addrdataset(void *arg, dns_name_t *name, dns_rdataset_t *rdataset) { newheader->serial = 1; newheader->noqname = NULL; newheader->count = 0; + newheader->additional_auth = NULL; + newheader->additional_glue = NULL; result = add(rbtdb, node, rbtdb->current_version, newheader, DNS_DBADD_MERGE, ISC_TRUE, NULL, 0); @@ -4755,6 +4859,74 @@ ispersistent(dns_db_t *db) { return (ISC_FALSE); } +static isc_result_t +getsoanode(dns_db_t *db, dns_dbnode_t **nodep) { + dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)db; + isc_result_t result = ISC_R_SUCCESS; + + REQUIRE(VALID_RBTDB(rbtdb)); + REQUIRE(nodep != NULL && *nodep == NULL); + + LOCK(&rbtdb->lock); + if (rbtdb->soanode != NULL) { + attachnode(db, rbtdb->soanode, nodep); + } else + result = ISC_R_NOTFOUND; + UNLOCK(&rbtdb->lock); + + return (result); +} + +static isc_result_t +setsoanode(dns_db_t *db, dns_dbnode_t *node) { + dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)db; + + REQUIRE(VALID_RBTDB(rbtdb)); + REQUIRE(node != NULL); + + LOCK(&rbtdb->lock); + if (rbtdb->soanode != NULL) + detachnode(db, &rbtdb->soanode); + attachnode(db, node, &rbtdb->soanode); + UNLOCK(&rbtdb->lock); + + return (ISC_R_SUCCESS); +} + +static isc_result_t +getnsnode(dns_db_t *db, dns_dbnode_t **nodep) { + dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)db; + isc_result_t result = ISC_R_SUCCESS; + + REQUIRE(VALID_RBTDB(rbtdb)); + REQUIRE(nodep != NULL && *nodep == NULL); + + LOCK(&rbtdb->lock); + if (rbtdb->nsnode != NULL) { + attachnode(db, rbtdb->nsnode, nodep); + } else + result = ISC_R_NOTFOUND; + UNLOCK(&rbtdb->lock); + + return (result); +} + +static isc_result_t +setnsnode(dns_db_t *db, dns_dbnode_t *node) { + dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)db; + + REQUIRE(VALID_RBTDB(rbtdb)); + REQUIRE(node != NULL); + + LOCK(&rbtdb->lock); + if (rbtdb->nsnode != NULL) + detachnode(db, &rbtdb->nsnode); + attachnode(db, node, &rbtdb->nsnode); + UNLOCK(&rbtdb->lock); + + return (ISC_R_SUCCESS); +} + static dns_dbmethods_t zone_methods = { attach, detach, @@ -4782,7 +4954,11 @@ static dns_dbmethods_t zone_methods = { nodecount, ispersistent, overmem, - settask + settask, + getsoanode, + setsoanode, + getnsnode, + setnsnode }; static dns_dbmethods_t cache_methods = { @@ -4812,7 +4988,11 @@ static dns_dbmethods_t cache_methods = { nodecount, ispersistent, overmem, - settask + settask, + getsoanode, + setsoanode, + getnsnode, + setnsnode }; isc_result_t @@ -5704,3 +5884,346 @@ dbiterator_origin(dns_dbiterator_t *iterator, dns_name_t *name) { return (dns_name_copy(origin, name, NULL)); } + +/* + * Additional cache routines. + */ +static isc_result_t +rdataset_getadditional(dns_rdataset_t *rdataset, dns_rdatasetadditional_t type, + dns_rdatatype_t qtype, dns_acache_t *acache, + dns_zone_t **zonep, dns_db_t **dbp, + dns_dbversion_t **versionp, dns_dbnode_t **nodep, + dns_name_t *fname, dns_message_t *msg, + isc_stdtime_t now) +{ + dns_rbtdb_t *rbtdb = rdataset->private1; + dns_rbtnode_t *rbtnode = rdataset->private2; + unsigned char *raw = rdataset->private3; + unsigned int current_count = rdataset->privateuint4; + unsigned int count; + rdatasetheader_t *header; + isc_mutex_t *nodelock; + unsigned int total_count; + acachectl_t *acarray; + dns_acacheentry_t *entry; + isc_result_t result; + + UNUSED(qtype); /* we do not use this value at least for now */ + UNUSED(acache); + + header = (struct rdatasetheader *)(raw - sizeof(*header)); + + total_count = rdataset_count(rdataset); + INSIST(total_count > current_count); + count = total_count - current_count - 1; + + acarray = NULL; + + nodelock = &rbtdb->node_locks[rbtnode->locknum].lock; + LOCK(nodelock); + + switch (type) { + case dns_rdatasetadditional_fromauth: + acarray = header->additional_auth; + break; + case dns_rdatasetadditional_fromcache: + acarray = NULL; + break; + case dns_rdatasetadditional_fromglue: + acarray = header->additional_glue; + break; + default: + INSIST(0); + } + + if (acarray == NULL) { + UNLOCK(nodelock); + return (ISC_R_NOTFOUND); + } + + if (acarray[count].entry == NULL) { + UNLOCK(nodelock); + return (ISC_R_NOTFOUND); + } + + entry = NULL; + dns_acache_attachentry(acarray[count].entry, &entry); + + UNLOCK(nodelock); + + result = dns_acache_getentry(entry, zonep, dbp, versionp, + nodep, fname, msg, now); + + dns_acache_detachentry(&entry); + + return (result); +} + +static void +acache_callback(dns_acacheentry_t *entry, void **arg) { + dns_rbtdb_t *rbtdb; + dns_rbtnode_t *rbtnode; + isc_mutex_t *nodelock; + acachectl_t *acarray = NULL; + acache_cbarg_t *cbarg; + unsigned int count; + + REQUIRE(arg != NULL); + cbarg = *arg; + + /* + * The caller must hold the entry lock. + */ + + rbtdb = (dns_rbtdb_t *)cbarg->db; + rbtnode = (dns_rbtnode_t *)cbarg->node; + + nodelock = &rbtdb->node_locks[rbtnode->locknum].lock; + LOCK(nodelock); + + switch (cbarg->type) { + case dns_rdatasetadditional_fromauth: + acarray = cbarg->header->additional_auth; + break; + case dns_rdatasetadditional_fromglue: + acarray = cbarg->header->additional_glue; + break; + default: + INSIST(0); + } + + count = cbarg->count; + if (acarray[count].entry == entry) + acarray[count].entry = NULL; + INSIST(acarray[count].cbarg != NULL); + isc_mem_put(rbtdb->common.mctx, acarray[count].cbarg, + sizeof(acache_cbarg_t)); + acarray[count].cbarg = NULL; + + dns_acache_detachentry(&entry); + + UNLOCK(nodelock); + + dns_db_detachnode((dns_db_t *)rbtdb, (dns_dbnode_t **)&rbtnode); + dns_db_detach((dns_db_t **)&rbtdb); + + *arg = NULL; +} + +static void +acache_cancelentry(isc_mem_t *mctx, dns_acacheentry_t *entry, + acache_cbarg_t **cbargp) +{ + acache_cbarg_t *cbarg; + + REQUIRE(mctx != NULL); + REQUIRE(entry != NULL); + REQUIRE(cbargp != NULL && *cbargp != NULL); + + cbarg = *cbargp; + + dns_acache_cancelentry(entry); + dns_db_detachnode(cbarg->db, &cbarg->node); + dns_db_detach(&cbarg->db); + + isc_mem_put(mctx, cbarg, sizeof(acache_cbarg_t)); + + *cbargp = NULL; +} + +static isc_result_t +rdataset_setadditional(dns_rdataset_t *rdataset, dns_rdatasetadditional_t type, + dns_rdatatype_t qtype, dns_acache_t *acache, + dns_zone_t *zone, dns_db_t *db, + dns_dbversion_t *version, dns_dbnode_t *node, + dns_name_t *fname) +{ + dns_rbtdb_t *rbtdb = rdataset->private1; + dns_rbtnode_t *rbtnode = rdataset->private2; + unsigned char *raw = rdataset->private3; + unsigned int current_count = rdataset->privateuint4; + rdatasetheader_t *header; + unsigned int total_count, count; + isc_mutex_t *nodelock; + isc_mem_t *mctx = rbtdb->common.mctx; + isc_result_t result; + acachectl_t *acarray; + dns_acacheentry_t *newentry, *oldentry = NULL; + acache_cbarg_t *newcbarg, *oldcbarg = NULL; + + UNUSED(qtype); + + if (type == dns_rdatasetadditional_fromcache) + return (ISC_R_SUCCESS); + + header = (struct rdatasetheader *)(raw - sizeof(*header)); + + total_count = rdataset_count(rdataset); + INSIST(total_count > current_count); + count = total_count - current_count - 1; /* should be private data */ + + newcbarg = isc_mem_get(mctx, sizeof(*newcbarg)); + if (newcbarg == NULL) + return (ISC_R_NOMEMORY); + newcbarg->type = type; + newcbarg->count = count; + newcbarg->header = header; + newcbarg->db = NULL; + dns_db_attach((dns_db_t *)rbtdb, &newcbarg->db); + newcbarg->node = NULL; + dns_db_attachnode((dns_db_t *)rbtdb, (dns_dbnode_t *)rbtnode, + &newcbarg->node); + newentry = NULL; + result = dns_acache_createentry(acache, (dns_db_t *)rbtdb, + acache_callback, newcbarg, &newentry); + if (result != ISC_R_SUCCESS) + goto fail; + /* Set cache data in the new entry. */ + result = dns_acache_setentry(acache, newentry, zone, db, + version, node, fname); + if (result != ISC_R_SUCCESS) + goto fail; + + nodelock = &rbtdb->node_locks[rbtnode->locknum].lock; + LOCK(nodelock); + + acarray = NULL; + switch (type) { + case dns_rdatasetadditional_fromauth: + acarray = header->additional_auth; + break; + case dns_rdatasetadditional_fromglue: + acarray = header->additional_glue; + break; + default: + INSIST(0); + } + + if (acarray == NULL) { + unsigned int i; + + acarray = isc_mem_get(mctx, total_count * + sizeof(acachectl_t)); + + if (acarray == NULL) { + UNLOCK(nodelock); + goto fail; + } + + for (i = 0; i < total_count; i++) { + acarray[i].entry = NULL; + acarray[i].cbarg = NULL; + } + } + switch (type) { + case dns_rdatasetadditional_fromauth: + header->additional_auth = acarray; + break; + case dns_rdatasetadditional_fromglue: + header->additional_glue = acarray; + break; + default: + INSIST(0); + } + + if (acarray[count].entry != NULL) { + /* + * Swap the entry. Delay cleaning-up the old entry since + * it would require a node lock. + */ + oldentry = acarray[count].entry; + INSIST(acarray[count].cbarg != NULL); + oldcbarg = acarray[count].cbarg; + } + acarray[count].entry = newentry; + acarray[count].cbarg = newcbarg; + + UNLOCK(nodelock); + + if (oldentry != NULL) { + if (oldcbarg != NULL) + acache_cancelentry(mctx, oldentry, &oldcbarg); + dns_acache_detachentry(&oldentry); + } + + return (ISC_R_SUCCESS); + + fail: + if (newentry != NULL) { + if (newcbarg != NULL) + acache_cancelentry(mctx, newentry, &newcbarg); + dns_acache_detachentry(&newentry); + } + + return (result); +} + +static isc_result_t +rdataset_putadditional(dns_acache_t *acache, dns_rdataset_t *rdataset, + dns_rdatasetadditional_t type, dns_rdatatype_t qtype) +{ + dns_rbtdb_t *rbtdb = rdataset->private1; + dns_rbtnode_t *rbtnode = rdataset->private2; + unsigned char *raw = rdataset->private3; + unsigned int current_count = rdataset->privateuint4; + rdatasetheader_t *header; + isc_mutex_t *nodelock; + unsigned int total_count, count; + acachectl_t *acarray; + dns_acacheentry_t *entry; + acache_cbarg_t *cbarg; + + UNUSED(qtype); /* we do not use this value at least for now */ + UNUSED(acache); + + if (type == dns_rdatasetadditional_fromcache) + return (ISC_R_SUCCESS); + + header = (struct rdatasetheader *)(raw - sizeof(*header)); + + total_count = rdataset_count(rdataset); + INSIST(total_count > current_count); + count = total_count - current_count - 1; + + acarray = NULL; + entry = NULL; + + nodelock = &rbtdb->node_locks[rbtnode->locknum].lock; + LOCK(nodelock); + + switch (type) { + case dns_rdatasetadditional_fromauth: + acarray = header->additional_auth; + break; + case dns_rdatasetadditional_fromglue: + acarray = header->additional_glue; + break; + default: + INSIST(0); + } + + if (acarray == NULL) { + UNLOCK(nodelock); + return (ISC_R_NOTFOUND); + } + + entry = acarray[count].entry; + if (entry == NULL) { + UNLOCK(nodelock); + return (ISC_R_NOTFOUND); + } + + acarray[count].entry = NULL; + cbarg = acarray[count].cbarg; + acarray[count].cbarg = NULL; + + UNLOCK(nodelock); + + if (entry != NULL) { + if(cbarg != NULL) + acache_cancelentry(rbtdb->common.mctx, entry, &cbarg); + dns_acache_detachentry(&entry); + } + + return (ISC_R_SUCCESS); +} diff --git a/lib/dns/rdatalist.c b/lib/dns/rdatalist.c index 2ceda74fca..a181f5ccbf 100644 --- a/lib/dns/rdatalist.c +++ b/lib/dns/rdatalist.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rdatalist.c,v 1.28 2004/03/05 05:09:23 marka Exp $ */ +/* $Id: rdatalist.c,v 1.29 2004/12/21 10:45:17 jinmei Exp $ */ #include @@ -38,7 +38,10 @@ static dns_rdatasetmethods_t methods = { isc__rdatalist_clone, isc__rdatalist_count, isc__rdatalist_addnoqname, - isc__rdatalist_getnoqname + isc__rdatalist_getnoqname, + NULL, + NULL, + NULL }; void diff --git a/lib/dns/rdataset.c b/lib/dns/rdataset.c index 8f3f1f0dcf..f65b4bd825 100644 --- a/lib/dns/rdataset.c +++ b/lib/dns/rdataset.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rdataset.c,v 1.72 2004/03/05 05:09:23 marka Exp $ */ +/* $Id: rdataset.c,v 1.73 2004/12/21 10:45:17 jinmei Exp $ */ #include @@ -174,6 +174,9 @@ static dns_rdatasetmethods_t question_methods = { question_clone, question_count, NULL, + NULL, + NULL, + NULL, NULL }; @@ -624,3 +627,81 @@ dns_rdataset_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name, return (ISC_R_NOTIMPLEMENTED); return((rdataset->methods->getnoqname)(rdataset, name, nsec, nsecsig)); } + +/* + * Additional cache stuff + */ +isc_result_t +dns_rdataset_getadditional(dns_rdataset_t *rdataset, + dns_rdatasetadditional_t type, + dns_rdatatype_t qtype, + dns_acache_t *acache, + dns_zone_t **zonep, + dns_db_t **dbp, + dns_dbversion_t **versionp, + dns_dbnode_t **nodep, + dns_name_t *fname, + dns_message_t *msg, + isc_stdtime_t now) +{ + REQUIRE(DNS_RDATASET_VALID(rdataset)); + REQUIRE(rdataset->methods != NULL); + REQUIRE(zonep == NULL || *zonep == NULL); + REQUIRE(dbp != NULL && *dbp == NULL); + REQUIRE(versionp != NULL && *versionp == NULL); + REQUIRE(nodep != NULL && *nodep == NULL); + REQUIRE(fname != NULL); + REQUIRE(msg != NULL); + + if (acache != NULL && rdataset->methods->getadditional != NULL) { + return ((rdataset->methods->getadditional)(rdataset, type, + qtype, acache, + zonep, dbp, + versionp, nodep, + fname, msg, now)); + } + + return (ISC_R_FAILURE); +} + +isc_result_t +dns_rdataset_setadditional(dns_rdataset_t *rdataset, + dns_rdatasetadditional_t type, + dns_rdatatype_t qtype, + dns_acache_t *acache, + dns_zone_t *zone, + dns_db_t *db, + dns_dbversion_t *version, + dns_dbnode_t *node, + dns_name_t *fname) +{ + REQUIRE(DNS_RDATASET_VALID(rdataset)); + REQUIRE(rdataset->methods != NULL); + + if (acache != NULL && rdataset->methods->setadditional != NULL) { + return ((rdataset->methods->setadditional)(rdataset, type, + qtype, acache, zone, + db, version, + node, fname)); + } + + return (ISC_R_FAILURE); +} + +isc_result_t +dns_rdataset_putadditional(dns_acache_t *acache, + dns_rdataset_t *rdataset, + dns_rdatasetadditional_t type, + dns_rdatatype_t qtype) +{ + REQUIRE(DNS_RDATASET_VALID(rdataset)); + REQUIRE(rdataset->methods != NULL); + + if (acache != NULL && rdataset->methods->putadditional != NULL) { + return ((rdataset->methods->putadditional)(acache, rdataset, + type, qtype)); + } + + return (ISC_R_FAILURE); +} + diff --git a/lib/dns/rdataslab.c b/lib/dns/rdataslab.c index 2e1b5f823e..228cf1fe72 100644 --- a/lib/dns/rdataslab.c +++ b/lib/dns/rdataslab.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rdataslab.c,v 1.35 2004/03/05 05:09:23 marka Exp $ */ +/* $Id: rdataslab.c,v 1.36 2004/12/21 10:45:17 jinmei Exp $ */ #include @@ -241,6 +241,9 @@ static dns_rdatasetmethods_t rdataset_methods = { rdataset_clone, rdataset_count, NULL, + NULL, + NULL, + NULL, NULL }; diff --git a/lib/dns/sdb.c b/lib/dns/sdb.c index 486874788f..ebf113ae19 100644 --- a/lib/dns/sdb.c +++ b/lib/dns/sdb.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: sdb.c,v 1.46 2004/07/22 03:58:07 marka Exp $ */ +/* $Id: sdb.c,v 1.47 2004/12/21 10:45:18 jinmei Exp $ */ #include @@ -1234,7 +1234,11 @@ static dns_dbmethods_t sdb_methods = { nodecount, ispersistent, overmem, - settask + settask, + NULL, + NULL, + NULL, + NULL }; static isc_result_t @@ -1361,7 +1365,10 @@ static dns_rdatasetmethods_t methods = { rdataset_clone, isc__rdatalist_count, isc__rdatalist_addnoqname, - isc__rdatalist_getnoqname + isc__rdatalist_getnoqname, + NULL, + NULL, + NULL }; static void diff --git a/lib/dns/view.c b/lib/dns/view.c index b3848c1cc3..ba90d117c8 100644 --- a/lib/dns/view.c +++ b/lib/dns/view.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: view.c,v 1.126 2004/03/10 02:19:56 marka Exp $ */ +/* $Id: view.c,v 1.127 2004/12/21 10:45:18 jinmei Exp $ */ #include @@ -24,6 +24,7 @@ #include /* Required for HP/UX (and others?) */ #include +#include #include #include #include @@ -120,6 +121,7 @@ dns_view_create(isc_mem_t *mctx, dns_rdataclass_t rdclass, goto cleanup_trustedkeys; } + view->acache = NULL; view->cache = NULL; view->cachedb = NULL; view->hints = NULL; @@ -253,6 +255,8 @@ destroy(dns_view_t *view) { dns_adb_detach(&view->adb); if (view->resolver != NULL) dns_resolver_detach(&view->resolver); + if (view->acache != NULL) + dns_acache_detach(&view->acache); if (view->requestmgr != NULL) dns_requestmgr_detach(&view->requestmgr); if (view->task != NULL) @@ -365,6 +369,8 @@ view_flushanddetach(dns_view_t **viewp, isc_boolean_t flush) { dns_adb_shutdown(view->adb); if (!REQSHUTDOWN(view)) dns_requestmgr_shutdown(view->requestmgr); + if (view->acache != NULL) + dns_acache_shutdown(view->acache); if (view->flush) dns_zt_flushanddetach(&view->zonetable); else diff --git a/lib/dns/zone.c b/lib/dns/zone.c index dac17f6fb1..063c1a64cd 100644 --- a/lib/dns/zone.c +++ b/lib/dns/zone.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.c,v 1.425 2004/11/23 05:23:46 marka Exp $ */ +/* $Id: zone.c,v 1.426 2004/12/21 10:45:18 jinmei Exp $ */ #include @@ -31,6 +31,7 @@ #include #include +#include #include #include #include @@ -206,6 +207,7 @@ struct dns_zone { dns_ssutable_t *ssutable; isc_uint32_t sigvalidityinterval; dns_view_t *view; + dns_acache_t *acache; /* * Zones in certain states such as "waiting for zone transfer" * or "zone transfer in progress" are kept on per-state linked lists @@ -384,6 +386,8 @@ static void zone_iattach(dns_zone_t *source, dns_zone_t **target); static void zone_idetach(dns_zone_t **zonep); static isc_result_t zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump); +static inline void zone_attachdb(dns_zone_t *zone, dns_db_t *db); +static inline void zone_detachdb(dns_zone_t *zone); static isc_result_t default_journal(dns_zone_t *zone); static void zone_xfrdone(dns_zone_t *zone, isc_result_t result); static isc_result_t zone_postload(dns_zone_t *zone, dns_db_t *db, @@ -572,6 +576,7 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) { zone->ssutable = NULL; zone->sigvalidityinterval = 30 * 24 * 3600; zone->view = NULL; + zone->acache = NULL; ISC_LINK_INIT(zone, statelink); zone->statelist = NULL; zone->counters = NULL; @@ -636,7 +641,9 @@ zone_free(dns_zone_t *zone) { if (zone->counters != NULL) dns_stats_freecounters(zone->mctx, &zone->counters); if (zone->db != NULL) - dns_db_detach(&zone->db); + zone_detachdb(zone); + if (zone->acache != NULL) + dns_acache_detach(&zone->acache); zone_freedbargs(zone); RUNTIME_CHECK(dns_zone_setmasterswithkeys(zone, NULL, NULL, 0) == ISC_R_SUCCESS); @@ -821,6 +828,33 @@ dns_zone_setorigin(dns_zone_t *zone, dns_name_t *origin) { return (result); } +void +dns_zone_setacache(dns_zone_t *zone, dns_acache_t *acache) { + REQUIRE(DNS_ZONE_VALID(zone)); + REQUIRE(acache != NULL); + + LOCK_ZONE(zone); + if (zone->acache != NULL) + dns_acache_detach(&zone->acache); + dns_acache_attach(acache, &zone->acache); + if (zone->db != NULL) { + isc_result_t result; + + /* + * If the zone reuses an existing DB, the DB needs to be + * set in the acache explicitly. We can safely ignore the + * case where the DB is already set. If other error happens, + * the acache will not work effectively. + */ + result = dns_acache_setdb(acache, zone->db); + if (result != ISC_R_SUCCESS && result != ISC_R_EXISTS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "dns_acache_setdb() failed: %s", + isc_result_totext(result)); + } + } + UNLOCK_ZONE(zone); +} static isc_result_t dns_zone_setstring(dns_zone_t *zone, char **field, const char *value) { @@ -1423,7 +1457,7 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime, if (result != ISC_R_SUCCESS) goto cleanup; } else { - dns_db_attach(db, &zone->db); + zone_attachdb(zone, db); DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_LOADED|DNS_ZONEFLG_NEEDNOTIFY); } @@ -2641,7 +2675,7 @@ zone_unload(dns_zone_t *zone) { REQUIRE(LOCKED_ZONE(zone)); - dns_db_detach(&zone->db); + zone_detachdb(zone); DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_LOADED); DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_NEEDDUMP); } @@ -3400,7 +3434,7 @@ stub_callback(isc_task_t *task, isc_event_t *event) { dns_db_closeversion(stub->db, &stub->version, ISC_TRUE); LOCK_ZONE(zone); if (zone->db == NULL) - dns_db_attach(stub->db, &zone->db); + zone_attachdb(zone, stub->db); UNLOCK_ZONE(zone); dns_db_detach(&stub->db); @@ -5427,8 +5461,8 @@ zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump) { "replacing zone database"); if (zone->db != NULL) - dns_db_detach(&zone->db); - dns_db_attach(db, &zone->db); + zone_detachdb(zone); + zone_attachdb(zone, db); dns_db_settask(zone->db, zone->task); DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_LOADED|DNS_ZONEFLG_NEEDNOTIFY); return (ISC_R_SUCCESS); @@ -5438,6 +5472,31 @@ zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump) { return (result); } +static inline void +zone_attachdb(dns_zone_t *zone, dns_db_t *db) { + REQUIRE(zone->db == NULL && db != NULL); + + dns_db_attach(db, &zone->db); + if (zone->acache != NULL) { + isc_result_t result; + result = dns_acache_setdb(zone->acache, db); + if (result != ISC_R_SUCCESS && result != ISC_R_EXISTS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "dns_acache_setdb() failed: %s", + isc_result_totext(result)); + } + } +} + +static inline void +zone_detachdb(dns_zone_t *zone) { + REQUIRE(zone->db != NULL); + + if (zone->acache != NULL) + (void)dns_acache_putdb(zone->acache, zone->db); + dns_db_detach(&zone->db); +} + static void zone_xfrdone(dns_zone_t *zone, isc_result_t result) { isc_time_t now; diff --git a/lib/isccfg/namedconf.c b/lib/isccfg/namedconf.c index a93179a2d9..90176929dd 100644 --- a/lib/isccfg/namedconf.c +++ b/lib/isccfg/namedconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: namedconf.c,v 1.41 2004/11/11 01:08:24 marka Exp $ */ +/* $Id: namedconf.c,v 1.42 2004/12/21 10:45:20 jinmei Exp $ */ #include @@ -733,6 +733,9 @@ view_clauses[] = { { "dnssec-must-be-secure", &cfg_type_mustbesecure, CFG_CLAUSEFLAG_MULTI }, { "ixfr-from-differences", &cfg_type_ixfrdifftype, 0 }, + { "use-additional-cache", &cfg_type_boolean, 0 }, + { "acache-cleaning-interval", &cfg_type_uint32, 0 }, + { "max-acache-size", &cfg_type_sizenodefault, 0 }, { NULL, NULL, 0 } }; From 1ba466b68ece96bb9ff3b81fff6770539c2cd507 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tatuya=20JINMEI=20=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= Date: Tue, 21 Dec 2004 10:54:12 +0000 Subject: [PATCH 011/130] new copyright for new files --- lib/dns/acache.c | 3 ++- lib/dns/include/dns/acache.h | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/dns/acache.c b/lib/dns/acache.c index a59d326f64..23893523e5 100644 --- a/lib/dns/acache.c +++ b/lib/dns/acache.c @@ -1,4 +1,5 @@ /* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +16,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: acache.c,v 1.2 2004/12/21 10:45:16 jinmei Exp $ */ +/* $Id: acache.c,v 1.3 2004/12/21 10:54:11 jinmei Exp $ */ #include diff --git a/lib/dns/include/dns/acache.h b/lib/dns/include/dns/acache.h index 2969f77cbc..f4e96651ab 100644 --- a/lib/dns/include/dns/acache.h +++ b/lib/dns/include/dns/acache.h @@ -1,4 +1,5 @@ /* + * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +16,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: acache.h,v 1.2 2004/12/21 10:45:18 jinmei Exp $ */ +/* $Id: acache.h,v 1.3 2004/12/21 10:54:12 jinmei Exp $ */ #ifndef DNS_ACACHE_H #define DNS_ACACHE_H 1 From 7fa947fc828e282156744ade7cdcd2ce7a708ff9 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 21 Dec 2004 23:49:18 +0000 Subject: [PATCH 012/130] newcopyrights --- util/copyrights | 2 ++ 1 file changed, 2 insertions(+) diff --git a/util/copyrights b/util/copyrights index 9754f9c47e..ce8e0738ec 100644 --- a/util/copyrights +++ b/util/copyrights @@ -1600,6 +1600,7 @@ ./lib/bind9/win32/version.c C 1998,1999,2000,2001,2004 ./lib/dns/.cvsignore X 1999,2000,2001 ./lib/dns/Makefile.in MAKE 1998,1999,2000,2001,2002,2003,2004 +./lib/dns/acache.c C 2004 ./lib/dns/acl.c C 1999,2000,2001,2002,2004 ./lib/dns/adb.c C 1999,2000,2001,2002,2003,2004 ./lib/dns/api X 1999,2000,2001 @@ -1632,6 +1633,7 @@ ./lib/dns/include/Makefile.in MAKE 1998,1999,2000,2001,2004 ./lib/dns/include/dns/.cvsignore X 1999,2000,2001 ./lib/dns/include/dns/Makefile.in MAKE 1998,1999,2000,2001,2002,2003,2004 +./lib/dns/include/dns/acache.h C 2004 ./lib/dns/include/dns/acl.h C 1999,2000,2001,2002,2004 ./lib/dns/include/dns/adb.h C 1999,2000,2001,2002,2003,2004 ./lib/dns/include/dns/bit.h C 2000,2001,2004 From 0c487f4b6eade1440ea40f5a5ffc9b5fd4c41ed1 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 22 Dec 2004 02:02:10 +0000 Subject: [PATCH 013/130] regen --- doc/arm/Bv9ARM.ch02.html | 21 ++- doc/arm/Bv9ARM.ch03.html | 20 +-- doc/arm/Bv9ARM.ch04.html | 42 +++--- doc/arm/Bv9ARM.ch05.html | 4 +- doc/arm/Bv9ARM.ch06.html | 282 ++++++++++++++++++++++++++++++--------- doc/arm/Bv9ARM.ch07.html | 8 +- doc/arm/Bv9ARM.ch08.html | 14 +- doc/arm/Bv9ARM.ch09.html | 108 +++++++-------- doc/arm/Bv9ARM.html | 114 ++++++++-------- 9 files changed, 389 insertions(+), 224 deletions(-) diff --git a/doc/arm/Bv9ARM.ch02.html b/doc/arm/Bv9ARM.ch02.html index 0b293c7edf..e7b38428cd 100644 --- a/doc/arm/Bv9ARM.ch02.html +++ b/doc/arm/Bv9ARM.ch02.html @@ -99,12 +99,12 @@ HREF="Bv9ARM.ch02.html#AEN240" >
2.4. Name Server Intensive Environment Issues
2.5. Supported Operating Systems
DNS -traffic. It is still good practice to have enough memory to load +traffic. +Additionally, if additional section caching +(Section 6.2.16.18) is enabled, +the max-acache-size can be used to limit the amount +of memory used by the mechanism. +It is still good practice to have enough memory to load all zone and cache data into memory — unfortunately, the best way to determine this for a given installation is to watch the name server in operation. After a few weeks the server process should reach @@ -188,7 +199,7 @@ CLASS="sect1" >

2.4. Name Server Intensive Environment Issues

2.5. Supported Operating Systems

3.2. Load Balancing
3.3. Name Server Operations

3.1.1. A Caching-only Name Server

3.1.2. An Authoritative-only Name Server

3.2. Load Balancing

3.3. Name Server Operations

3.3.1. Tools for Use With the Name Server Daemon

3.3.2. Signals

4.4. Split DNS
4.6. TKEY
4.7. SIG(0)
4.9. IPv6 Support in BIND

4.4. Split DNS

4.5.1. Generate Shared Keys for Each Pair of Hosts

4.5.1.1. Automatic Generation

4.5.1.2. Manual Generation

4.5.2. Copying the Shared Secret to Both Machines

4.5.3. Informing the Servers of the Key's Existence

4.5.4. Instructing the Server to Use the Key

4.5.5. TSIG Key Based Access Control

4.5.6. Errors

4.6. TKEY

4.7. SIG(0)

4.8.1. Generating Keys

4.8.2. Signing the Zone

4.8.3. Configuring Servers

4.9. IPv6 Support in BIND

4.9.1. Address Lookups Using AAAA Records

4.9.2. Address to Name Lookups Using Nibble Format

5.1. The Lightweight Resolver Library

5.1. The Lightweight Resolver Library

6.3. Zone File

6.1.1.1. Syntax

6.1.1.2. Definition and Usage
6.1.2. Comment Syntax
6.1.2.1. Syntax
6.1.2.2. Definition and Usage

6.2.1. acl

6.2.3. controls

6.2.5. include

6.2.6. include

6.2.7. key

6.2.8. key

6.2.9. logging

6.2.10. logging

6.2.10.1. The channel

6.2.11. lwres

6.2.12. lwres

6.2.13. masters

6.2.14. masters

6.2.15. optionsyes_or_no ; ] -}; [ disable-algorithms ; ] }; ] + [ use-additional-cache yes_or_no ; ] + [ acache-cleaning-interval number; ] + [ max-acache-size size_spec ; ] +};

6.2.16.2. Forwarding

6.2.16.3. Dual-stack Servers

6.2.16.5. Interfaces

6.2.16.6. Query Address

6.2.16.8. Bad UDP Port Lists

6.2.16.9. Operating System Resource Limits

6.2.16.10. Server Resource Limits

6.2.16.11. Periodic Task Intervals

counter to be incremented.

6.2.16.18. Additional Section Caching

The additional section cache, also called acache, +is an internal cache to improve the response performance of BIND 9. +When the additional section caching is enabled, BIND 9 will +cache internal short-cut to the additional section content for each +answer RR. +Note that acache is an internal caching mechanism of BIND 9, and is +not relevant to the DNS caching server function. +

The additional section caching does not make any difference on the +response content (except the RRsets ordering of the additional +section, see below), but can improve the response performance significantly. +It is particularly effective when BIND 9 acts as an authoritative server +for a zone that has many delegations with many glue RRs. +

In order to achieve the maximum performance improvement by acache, +it is recommended to set additional-from-cache +to no, since the current implementation of acache +does not make a short-cut of additional section information from a DNS +cache data. +

One obvious disadvantage of acache is that it requires much more +memory for the internal cached data. +Thus, if the response performance does not matter and memory +consumption is much more severe, the acache mechanism can be +disabled by setting use-additional-cache to +no. +It is also possible to specify the upper limit of memory consumption +for acache by max-acache-size. +

The additional section caching also has a minor effect on the RRset +ordering in the additional section. +Without acache, the "cyclic" order is effective for the additional +section as well as the answer and authority sections. +However, the additional section caching fixes the ordering when it +first caches an RRset for the additional section, and the same +ordering will be kept in succeeding responses, regardless of the +configuration for rrset-order. +This should be minor, though, since an RRset in the additional section +typically only contains a small number of RRs (and in many cases it +only contains a single RR), in which case the +ordering does not matter much. +

The following is a summary of options related to acache. +

use-additional-cache

If yes, the additional section caching is enabled. +The default value is yes. +

acache-cleaning-interval

The server will remove stale cache entries, based on an LRU based +algorithm, every acache-cleaning-interval minutes. +The default is 60 minutes. +If set to 0, no periodic cleaning will occur. +

max-acache-size

The maximum amount of memory to use for the server's acache, in bytes. +When the amount of data in the acache reaches this limit, the server +will cause more aggressive cleaning so that the limit is not exceeded. +In a server with multiple views, the limit applies separately to the +acache of each view. +The default is unlimited, meaning that +entries are purged from acache only at the periodic cleaning time. +

6.2.19. trusted-keys

6.2.20. trusted-keys

6.2.22. view

6.2.24. zone

6.2.24.1. Zone Types

6.2.24.2. Class

6.2.24.3. Zone Options

6.3. Zone File

6.3.1.1. Resource Records

6.3.1.2. Textual expression of RRs

6.3.2. Discussion of MX Records

6.3.4. Inverse Mapping in IPv4

6.3.5. Other Zone File Directives

6.3.5.1. The $ORIGIN

6.3.5.2. The $INCLUDE

6.3.5.3. The $TTL

6.3.6. BIND

7.2. chroot

7.2. chroot

7.2.1. The chroot

7.2.2. Using the setuid

8.1. Common Problems
8.2. Incrementing and Changing the Serial Number
8.3. Where Can I Get Help?

8.1. Common Problems

8.1.1. It's not working; how can I figure out what's wrong?

8.2. Incrementing and Changing the Serial Number

8.3. Where Can I Get Help?

A.1. Acknowledgments

A.1. Acknowledgments

A.1.1. A Brief History of the DNS

Bibliography

Standards

[RFC974] 

[RFC1034] 

[RFC1035] 

[RFC2181] 

[RFC2308] 

[RFC1995] 

[RFC1996] 

[RFC2136] 

[RFC2845] 

Proposed Standards Still Under Development

[RFC1886] 

[RFC2065] 

[RFC2137] 

Other Important RFCs About DNS

[RFC1535] 

[RFC1536] 

[RFC1982] 

Resource Record Types

[RFC1183] 

[RFC1706] 

[RFC2168] 

[RFC1876] 

[RFC2052] 

[RFC2163] 

[RFC2230] 

DNS

[RFC1101] 

[RFC1123] 

[RFC1591] 

[RFC2317] 

DNS

[RFC1537] 

[RFC1912] 

[RFC2010] 

[RFC2219] 

Other DNS

[RFC1464] 

[RFC1713] 

[RFC1794] 

[RFC2240] 

[RFC2345] 

[RFC2352] 

Obsolete and Unimplemented Experimental RRs

[RFC1712] 

A.3.3. Other Documents About BIND

Bibliography

2.4. Name Server Intensive Environment Issues
2.5. Supported Operating Systems
3.1.1. A Caching-only Name Server
3.1.2. An Authoritative-only Name Server
3.2. Load Balancing
3.3. Name Server Operations
3.3.1. Tools for Use With the Name Server Daemon
3.3.2. Signals
4.4. Split DNS
4.5.1. Generate Shared Keys for Each Pair of Hosts
4.5.2. Copying the Shared Secret to Both Machines
4.5.3. Informing the Servers of the Key's Existence
4.5.4. Instructing the Server to Use the Key
4.5.5. TSIG Key Based Access Control
4.5.6. Errors
4.6. TKEY
4.7. SIG(0)
4.8.1. Generating Keys
4.8.2. Signing the Zone
4.8.3. Configuring Servers
4.9. IPv6 Support in BIND
4.9.1. Address Lookups Using AAAA Records
4.9.2. Address to Name Lookups Using Nibble Format
5.1. The Lightweight Resolver Library
6.1.2. Comment Syntax
6.2.1. acl
6.2.3. controls
6.2.5. include
6.2.6. include
6.2.7. key
6.2.8. key
6.2.9. logging
6.2.10. logging
6.2.11. lwres
6.2.12. lwres
6.2.13. masters
6.2.14. masters
6.2.15. options
6.2.19. trusted-keys
6.2.20. trusted-keys
6.2.22. view
6.2.24. zone
6.3. Zone File
6.3.2. Discussion of MX Records
6.3.4. Inverse Mapping in IPv4
6.3.5. Other Zone File Directives
6.3.6. BIND
7.2. chroot
7.2.1. The chroot
7.2.2. Using the setuid
8.1. Common Problems
8.1.1. It's not working; how can I figure out what's wrong?
8.2. Incrementing and Changing the Serial Number
8.3. Where Can I Get Help?
A.1. Acknowledgments
A.1.1. A Brief History of the DNS
A.3.3. Other Documents About BIND Date: Wed, 22 Dec 2004 22:51:27 +0000 Subject: [PATCH 014/130] regen --- doc/misc/options | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/doc/misc/options b/doc/misc/options index 65325967b0..9f76722438 100644 --- a/doc/misc/options +++ b/doc/misc/options @@ -87,6 +87,9 @@ options { dnssec-lookaside trust-anchor ; dnssec-must-be-secure ; ixfr-from-differences ; + use-additional-cache ; + acache-cleaning-interval ; + max-acache-size ; allow-query { ; ... }; allow-transfer { ; ... }; allow-update { ; ... }; @@ -270,6 +273,9 @@ view { dnssec-lookaside trust-anchor ; dnssec-must-be-secure ; ixfr-from-differences ; + use-additional-cache ; + acache-cleaning-interval ; + max-acache-size ; allow-query { ; ... }; allow-transfer { ; ... }; allow-update { ; ... }; From 0c865fa57d3b9b072c2878b09fad17c732be2eb9 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 23 Dec 2004 00:13:17 +0000 Subject: [PATCH 015/130] update copyright notice --- lib/dns/acache.c | 18 ++++++++---------- lib/dns/include/dns/acache.h | 18 ++++++++---------- 2 files changed, 16 insertions(+), 20 deletions(-) diff --git a/lib/dns/acache.c b/lib/dns/acache.c index 23893523e5..2f4b328da9 100644 --- a/lib/dns/acache.c +++ b/lib/dns/acache.c @@ -1,22 +1,20 @@ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") - * Copyright (C) 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 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: acache.c,v 1.3 2004/12/21 10:54:11 jinmei Exp $ */ +/* $Id: acache.c,v 1.4 2004/12/23 00:13:09 marka Exp $ */ #include diff --git a/lib/dns/include/dns/acache.h b/lib/dns/include/dns/acache.h index f4e96651ab..19def50b02 100644 --- a/lib/dns/include/dns/acache.h +++ b/lib/dns/include/dns/acache.h @@ -1,22 +1,20 @@ /* * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") - * Copyright (C) 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 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: acache.h,v 1.3 2004/12/21 10:54:12 jinmei Exp $ */ +/* $Id: acache.h,v 1.4 2004/12/23 00:13:17 marka Exp $ */ #ifndef DNS_ACACHE_H #define DNS_ACACHE_H 1 From a1cc4108f61d1fd2a57810242b06dd929eaab4bd Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 29 Dec 2004 22:30:10 +0000 Subject: [PATCH 016/130] avoided leakage of a cache entry by adjusting the timing of incrementing the reference counter to the entry. Otherwise, the entry could leak when dns_acache_setentry() fails. This must be corrected in some way if not by this change. [RT #13339] --- lib/dns/acache.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/lib/dns/acache.c b/lib/dns/acache.c index 2f4b328da9..42823bf0dc 100644 --- a/lib/dns/acache.c +++ b/lib/dns/acache.c @@ -14,7 +14,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: acache.c,v 1.4 2004/12/23 00:13:09 marka Exp $ */ +/* $Id: acache.c,v 1.5 2004/12/29 22:30:10 marka Exp $ */ #include @@ -1217,11 +1217,8 @@ dns_acache_createentry(dns_acache_t *acache, dns_db_t *origdb, isc_result_totext(result)); return (ISC_R_UNEXPECTED); }; - /* - * We need two counters on creation: one for the caller, and one for - * the cache object. - */ - isc_refcount_init(&newentry->references, 2); + + isc_refcount_init(&newentry->references, 1); ISC_LINK_INIT(newentry, link); ISC_LINK_INIT(newentry, olink); @@ -1343,6 +1340,7 @@ dns_acache_setentry(dns_acache_t *acache, dns_acacheentry_t *entry, dbentry_t *odbent; dbentry_t *rdbent = NULL; isc_boolean_t close_version = ISC_FALSE; + dns_acacheentry_t *dummy_entry = NULL; REQUIRE(DNS_ACACHE_VALID(acache)); REQUIRE(DNS_ACACHEENTRY_VALID(entry)); @@ -1434,6 +1432,12 @@ dns_acache_setentry(dns_acache_t *acache, dns_acacheentry_t *entry, if (rdbent != NULL) ISC_LIST_APPEND(rdbent->referlist, entry, rlink); + /* + * The additional cache needs an implicit reference to entries in its + * link. + */ + dns_acache_attachentry(entry, &dummy_entry); + UNLOCK(&entry->lock); UNLOCK(&acache->lock); From 24875d713b228dd51e542c71e75ac9fa2f982e0e Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 29 Dec 2004 22:42:57 +0000 Subject: [PATCH 017/130] cleanup --- lib/dns/acache.c | 21 +++++---------------- 1 file changed, 5 insertions(+), 16 deletions(-) diff --git a/lib/dns/acache.c b/lib/dns/acache.c index 42823bf0dc..79d2113833 100644 --- a/lib/dns/acache.c +++ b/lib/dns/acache.c @@ -14,7 +14,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: acache.c,v 1.5 2004/12/29 22:30:10 marka Exp $ */ +/* $Id: acache.c,v 1.6 2004/12/29 22:42:57 marka Exp $ */ #include @@ -359,8 +359,6 @@ destroy_entry(dns_acacheentry_t *entry) { static void destroy(dns_acache_t *acache) { - isc_mem_t *mctx; - REQUIRE(DNS_ACACHE_VALID(acache)); ATRACE("destroy"); @@ -380,7 +378,6 @@ destroy(dns_acache_t *acache) { DESTROYLOCK(&acache->lock); acache->magic = 0; - mctx = acache->mctx; isc_mem_putanddetach(&acache->mctx, acache, sizeof(*acache)); } @@ -1137,10 +1134,8 @@ dns_acache_putdb(dns_acache_t *acache, dns_db_t *db) { * unlink_dbentries(). */ ISC_LIST_UNLINK(dbentry->originlist, entry, olink); - if (acache->cleaner.current_entry == NULL || - acache->cleaner.current_entry != entry) { + if (acache->cleaner.current_entry != entry) ISC_LIST_UNLINK(acache->entries, entry, link); - } unlink_dbentries(acache, entry); if (entry->callback != NULL) @@ -1149,19 +1144,15 @@ dns_acache_putdb(dns_acache_t *acache, dns_db_t *db) { UNLOCK(&entry->lock); - if (acache->cleaner.current_entry == NULL || - acache->cleaner.current_entry != entry) { + if (acache->cleaner.current_entry != entry) dns_acache_detachentry(&entry); - } } while ((entry = ISC_LIST_HEAD(dbentry->referlist)) != NULL) { LOCK(&entry->lock); ISC_LIST_UNLINK(dbentry->referlist, entry, rlink); - if (acache->cleaner.current_entry == NULL || - acache->cleaner.current_entry != entry) { + if (acache->cleaner.current_entry != entry) ISC_LIST_UNLINK(acache->entries, entry, link); - } unlink_dbentries(acache, entry); if (entry->callback != NULL) @@ -1170,10 +1161,8 @@ dns_acache_putdb(dns_acache_t *acache, dns_db_t *db) { UNLOCK(&entry->lock); - if (acache->cleaner.current_entry == NULL || - acache->cleaner.current_entry != entry) { + if (acache->cleaner.current_entry != entry) dns_acache_detachentry(&entry); - } } INSIST(ISC_LIST_EMPTY(dbentry->originlist) && From 4ae404824bcdc6a26383f16663ad23eba044acad Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 29 Dec 2004 23:01:13 +0000 Subject: [PATCH 018/130] set the cache DB in the view's additional cache object so that additional sections for a (DNS) cached response can also be stored in the additional cache. [RT #13339] --- lib/dns/view.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/lib/dns/view.c b/lib/dns/view.c index ba90d117c8..6a3fa54e66 100644 --- a/lib/dns/view.c +++ b/lib/dns/view.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: view.c,v 1.127 2004/12/21 10:45:18 jinmei Exp $ */ +/* $Id: view.c,v 1.128 2004/12/29 23:01:13 marka Exp $ */ #include @@ -255,8 +255,11 @@ destroy(dns_view_t *view) { dns_adb_detach(&view->adb); if (view->resolver != NULL) dns_resolver_detach(&view->resolver); - if (view->acache != NULL) + if (view->acache != NULL) { + if (view->cachedb != NULL) + dns_acache_putdb(view->acache, view->cachedb); dns_acache_detach(&view->acache); + } if (view->requestmgr != NULL) dns_requestmgr_detach(&view->requestmgr); if (view->task != NULL) @@ -591,12 +594,17 @@ dns_view_setcache(dns_view_t *view, dns_cache_t *cache) { REQUIRE(!view->frozen); if (view->cache != NULL) { + if (view->acache != NULL) + dns_acache_putdb(view->acache, view->cachedb); dns_db_detach(&view->cachedb); dns_cache_detach(&view->cache); } dns_cache_attach(cache, &view->cache); dns_cache_attachdb(cache, &view->cachedb); INSIST(DNS_DB_VALID(view->cachedb)); + + if (view->acache != NULL) + dns_acache_setdb(view->acache, view->cachedb); } void @@ -1204,8 +1212,12 @@ dns_view_flushcache(dns_view_t *view) { result = dns_cache_flush(view->cache); if (result != ISC_R_SUCCESS) return (result); + if (view->acache != NULL) + dns_acache_putdb(view->acache, view->cachedb); dns_db_detach(&view->cachedb); dns_cache_attachdb(view->cache, &view->cachedb); + if (view->acache != NULL) + dns_acache_setdb(view->acache, view->cachedb); dns_adb_flush(view->adb); return (ISC_R_SUCCESS); From 4c47c184b98a5ec1b303281959c1f3b0db85d733 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 4 Jan 2005 02:21:31 +0000 Subject: [PATCH 019/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 446d4a87f8..6e2acb30b3 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1793. [placeholder] rt13378 + 1792. [placeholder] rt13124 1791. [placeholder] rt13230 From 4834c6a7f0054b8f4a8a267d60ef78204521e39e Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 4 Jan 2005 02:34:31 +0000 Subject: [PATCH 020/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 6e2acb30b3..d0ec311b63 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1794. [placeholder] rt13382 + 1793. [placeholder] rt13378 1792. [placeholder] rt13124 From c0a1ebb1adecc5da1f1ad6f9b06a2b4356d2b135 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 7 Jan 2005 04:30:29 +0000 Subject: [PATCH 021/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index d0ec311b63..e84c9a1f4c 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1795. [placeholder] rt13396 + 1794. [placeholder] rt13382 1793. [placeholder] rt13378 From 508f61f8d699c46f962b682f388e54b446a7194d Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Sun, 9 Jan 2005 23:40:04 +0000 Subject: [PATCH 022/130] 1794. [func] Named and named-checkzone can now both check for non-terminal wildcard records. --- CHANGES | 3 ++- bin/check/check-tool.c | 5 +++-- bin/check/named-checkzone.c | 13 ++++++++--- bin/check/named-checkzone.docbook | 16 ++++++++++++- bin/named/config.c | 3 ++- bin/named/update.c | 13 ++++++++++- bin/named/zoneconf.c | 10 +++++++-- doc/arm/Bv9ARM-book.xml | 19 +++++++++++++++- doc/misc/options | 4 ++++ lib/bind9/check.c | 3 ++- lib/dns/include/dns/master.h | 3 ++- lib/dns/include/dns/name.h | 11 ++++++++- lib/dns/include/dns/zone.h | 3 ++- lib/dns/master.c | 29 ++++++++++++++++++++++-- lib/dns/name.c | 37 ++++++++++++++++++++++++++++++- lib/dns/zone.c | 6 ++++- lib/isccfg/namedconf.c | 3 ++- 17 files changed, 160 insertions(+), 21 deletions(-) diff --git a/CHANGES b/CHANGES index e84c9a1f4c..727bb4d04b 100644 --- a/CHANGES +++ b/CHANGES @@ -1,6 +1,7 @@ 1795. [placeholder] rt13396 -1794. [placeholder] rt13382 +1794. [func] Named and named-checkzone can now both check for + non-terminal wildcard records. 1793. [placeholder] rt13378 diff --git a/bin/check/check-tool.c b/bin/check/check-tool.c index 14e855a6eb..f06602fb33 100644 --- a/bin/check/check-tool.c +++ b/bin/check/check-tool.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: check-tool.c,v 1.13 2004/11/30 01:08:48 marka Exp $ */ +/* $Id: check-tool.c,v 1.14 2005/01/09 23:39:56 marka Exp $ */ #include @@ -51,7 +51,8 @@ int debug = 0; isc_boolean_t nomerge = ISC_TRUE; unsigned int zone_options = DNS_ZONEOPT_CHECKNS | DNS_ZONEOPT_MANYERRORS | - DNS_ZONEOPT_CHECKNAMES; + DNS_ZONEOPT_CHECKNAMES | + DNS_ZONEOPT_CHECKWILDCARD; /* * This needs to match the list in bin/named/log.c. diff --git a/bin/check/named-checkzone.c b/bin/check/named-checkzone.c index e4f93d2aa3..83886a60b1 100644 --- a/bin/check/named-checkzone.c +++ b/bin/check/named-checkzone.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named-checkzone.c,v 1.31 2004/10/25 01:27:53 marka Exp $ */ +/* $Id: named-checkzone.c,v 1.32 2005/01/09 23:39:56 marka Exp $ */ #include @@ -67,7 +67,7 @@ usage(void) { fprintf(stderr, "usage: named-checkzone [-djqvD] [-c class] [-o output] " "[-t directory] [-w directory] [-k (ignore|warn|fail)] " - "[-n (ignore|warn|fail)] zonename filename\n"); + "[-n (ignore|warn|fail)] [-W (ignore|warn)] zonename filename\n"); exit(1); } @@ -88,7 +88,7 @@ main(int argc, char **argv) { char *classname = classname_in; const char *workdir = NULL; - while ((c = isc_commandline_parse(argc, argv, "c:dijk:n:qst:o:vw:D")) != EOF) { + while ((c = isc_commandline_parse(argc, argv, "c:dijk:n:qst:o:vw:DW:")) != EOF) { switch (c) { case 'c': classname = isc_commandline_argument; @@ -165,6 +165,13 @@ main(int argc, char **argv) { dumpzone++; break; + case 'W': + if (!strcmp(isc_commandline_argument, "warn")) + zone_options |= DNS_ZONEOPT_CHECKWILDCARD; + else if (!strcmp(isc_commandline_argument, "ignore")) + zone_options &= ~DNS_ZONEOPT_CHECKWILDCARD; + break; + default: usage(); } diff --git a/bin/check/named-checkzone.docbook b/bin/check/named-checkzone.docbook index 85bd233615..213267d65e 100644 --- a/bin/check/named-checkzone.docbook +++ b/bin/check/named-checkzone.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> - + @@ -48,6 +48,7 @@ + zonename filename @@ -178,6 +179,19 @@ + + -W mode + + + Specify whether to check for non-terminal wildcards. + Non-terminal wildcards are almost always the result of a + failure to understand the wildcard matching algorithm (RFC 1034). + Possible modes are "warn" (default) and + "ignore". + + + + zonename diff --git a/bin/named/config.c b/bin/named/config.c index 1965758be0..6f34fc1acc 100644 --- a/bin/named/config.c +++ b/bin/named/config.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: config.c,v 1.52 2004/12/21 10:45:15 jinmei Exp $ */ +/* $Id: config.c,v 1.53 2005/01/09 23:39:57 marka Exp $ */ #include @@ -158,6 +158,7 @@ options {\n\ zone-statistics false;\n\ max-journal-size unlimited;\n\ ixfr-from-differences false;\n\ + check-wildcard yes;\n\ };\n\ " diff --git a/bin/named/update.c b/bin/named/update.c index 9f9c395cbf..6bc8c337bd 100644 --- a/bin/named/update.c +++ b/bin/named/update.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: update.c,v 1.118 2004/10/21 01:29:29 marka Exp $ */ +/* $Id: update.c,v 1.119 2005/01/09 23:39:58 marka Exp $ */ #include @@ -2149,6 +2149,7 @@ update_action(isc_task_t *task, isc_event_t *event) { dns_ssutable_t *ssutable = NULL; dns_fixedname_t tmpnamefixed; dns_name_t *tmpname = NULL; + unsigned int options; INSIST(event->ev_type == DNS_EVENT_UPDATE); @@ -2382,6 +2383,7 @@ update_action(isc_task_t *task, isc_event_t *event) { * Process the Update Section. */ + options = dns_zone_getoptions(zone); for (result = dns_message_firstname(request, DNS_SECTION_UPDATE); result == ISC_R_SUCCESS; result = dns_message_nextname(request, DNS_SECTION_UPDATE)) @@ -2468,6 +2470,15 @@ update_action(isc_task_t *task, isc_event_t *event) { } soa_serial_changed = ISC_TRUE; } + if ((options & DNS_ZONEOPT_CHECKWILDCARD) != 0 && + dns_name_internalwildcard(name)) { + char namestr[DNS_NAME_FORMATSIZE]; + dns_name_format(name, namestr, + sizeof(namestr)); + update_log(client, zone, LOGLEVEL_PROTOCOL, + "warning: ownername '%s' contains " + "a non-terminal wildcard", namestr); + } if (isc_log_wouldlog(ns_g_lctx, LOGLEVEL_PROTOCOL)) { char namestr[DNS_NAME_FORMATSIZE]; diff --git a/bin/named/zoneconf.c b/bin/named/zoneconf.c index 86ff65c09f..7d56979101 100644 --- a/bin/named/zoneconf.c +++ b/bin/named/zoneconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zoneconf.c,v 1.114 2004/10/14 00:49:33 marka Exp $ */ +/* $Id: zoneconf.c,v 1.115 2005/01/09 23:39:58 marka Exp $ */ #include @@ -602,7 +602,13 @@ ns_zone_configure(cfg_obj_t *config, cfg_obj_t *vconfig, cfg_obj_t *zconfig, } RETERR(dns_zone_setkeydirectory(zone, filename)); } - + obj = NULL; + result = ns_config_get(maps, "check-wildcard", &obj); + if (result == ISC_R_SUCCESS) + check = cfg_obj_asboolean(obj); + else + check = ISC_FALSE; + dns_zone_setoption(zone, DNS_ZONEOPT_CHECKWILDCARD, check); } else if (ztype == dns_zone_slave) { RETERR(configure_zone_acl(zconfig, vconfig, config, "allow-update-forwarding", ac, zone, diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 04882f40bf..3658577441 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -2,7 +2,7 @@ - + BIND 9 Administrator Reference Manual @@ -2733,6 +2733,7 @@ statement in the named.conf file: forwarders { ip_addr port ip_port ; ip_addr port ip_port ; ... }; dual-stack-servers port ip_port { ( domain_name port ip_port | ip_addr port ip_port ) ; ... }; check-names ( master | slave | response )( warn | fail | ignore ); + check-wildcard yes_or_no; allow-notify { address_match_list }; allow-query { address_match_list }; allow-query-cache { address_match_list }; @@ -3384,6 +3385,16 @@ IN-ADDR.ARPA, IP6.ARPA, IP6.INT). +check-wildcard + +This option is used to check for non-terminal wildcards. +The use of non-terminal wildcards is almost always as a result of a failure +to understand the wildcard matching algorithm (RFC 1034). This option +affects master zones. The default (yes) is to check +for non-terminal wildcards and issue a warning. + + + @@ -4686,6 +4697,7 @@ Statement Grammar allow-update-forwarding { address_match_list } ; also-notify { ip_addr port ip_port ; ip_addr port ip_port ; ... }; check-names (warn|fail|ignore) ; + check-wildcard yes_or_no; dialup dialup_option ; delegation-only yes_or_no ; file string ; @@ -4908,6 +4920,11 @@ zones the default is warn. +check-wildcard +See the description of +check-wildcard in . + + database Specify the type of database to be used for storing the zone data. The string following the database keyword diff --git a/doc/misc/options b/doc/misc/options index 9f76722438..e16959c5e2 100644 --- a/doc/misc/options +++ b/doc/misc/options @@ -126,6 +126,7 @@ options { use-alt-transfer-source ; zone-statistics ; key-directory ; + check-wildcard ; }; controls { @@ -218,6 +219,7 @@ view { use-alt-transfer-source ; zone-statistics ; key-directory ; + check-wildcard ; }; server ( | ) { bogus ; @@ -312,6 +314,7 @@ view { use-alt-transfer-source ; zone-statistics ; key-directory ; + check-wildcard ; }; lwres { @@ -378,6 +381,7 @@ zone { use-alt-transfer-source ; zone-statistics ; key-directory ; + check-wildcard ; }; server ( | ) { diff --git a/lib/bind9/check.c b/lib/bind9/check.c index 8b4772060e..aad0cd5ebf 100644 --- a/lib/bind9/check.c +++ b/lib/bind9/check.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: check.c,v 1.51 2004/11/22 05:03:11 marka Exp $ */ +/* $Id: check.c,v 1.52 2005/01/09 23:40:00 marka Exp $ */ #include @@ -741,6 +741,7 @@ check_zoneconf(cfg_obj_t *zconfig, cfg_obj_t *config, isc_symtab_t *symtab, { "update-policy", MASTERZONE }, { "database", MASTERZONE | SLAVEZONE | STUBZONE }, { "key-directory", MASTERZONE }, + { "check-wildcard", MASTERZONE }, }; static optionstable dialups[] = { diff --git a/lib/dns/include/dns/master.h b/lib/dns/include/dns/master.h index af652a6caa..8b7b7866b4 100644 --- a/lib/dns/include/dns/master.h +++ b/lib/dns/include/dns/master.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: master.h,v 1.38 2004/03/05 05:09:43 marka Exp $ */ +/* $Id: master.h,v 1.39 2005/01/09 23:40:03 marka Exp $ */ #ifndef DNS_MASTER_H #define DNS_MASTER_H 1 @@ -45,6 +45,7 @@ * matches as fatal */ #define DNS_MASTER_CHECKNAMES 0x00000100 #define DNS_MASTER_CHECKNAMESFAIL 0x00000200 +#define DNS_MASTER_CHECKWILDCARD 0x00000400 /* Check for internal wilcards. */ ISC_LANG_BEGINDECLS diff --git a/lib/dns/include/dns/name.h b/lib/dns/include/dns/name.h index ea10296ed6..662ce5b059 100644 --- a/lib/dns/include/dns/name.h +++ b/lib/dns/include/dns/name.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: name.h,v 1.111 2004/09/08 00:26:14 marka Exp $ */ +/* $Id: name.h,v 1.112 2005/01/09 23:40:03 marka Exp $ */ #ifndef DNS_NAME_H #define DNS_NAME_H 1 @@ -1167,6 +1167,15 @@ dns_name_ismailbox(const dns_name_t *name); * 'name' to be valid. */ +isc_boolean_t +dns_name_internalwildcard(const dns_name_t *name); +/* + * Return if 'name' contains a internal wildcard name. + * + * Requires: + * 'name' to be valid. + */ + ISC_LANG_ENDDECLS /*** diff --git a/lib/dns/include/dns/zone.h b/lib/dns/include/dns/zone.h index 28337a68f8..c05a927dd6 100644 --- a/lib/dns/include/dns/zone.h +++ b/lib/dns/include/dns/zone.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.h,v 1.128 2004/12/21 10:45:19 jinmei Exp $ */ +/* $Id: zone.h,v 1.129 2005/01/09 23:40:03 marka Exp $ */ #ifndef DNS_ZONE_H #define DNS_ZONE_H 1 @@ -52,6 +52,7 @@ typedef enum { #define DNS_ZONEOPT_USEALTXFRSRC 0x00000400U /* use alternate transfer sources */ #define DNS_ZONEOPT_CHECKNAMES 0x00000800U /* check-names */ #define DNS_ZONEOPT_CHECKNAMESFAIL 0x00001000U /* fatal check-name failures */ +#define DNS_ZONEOPT_CHECKWILDCARD 0x00002000U /* check for internal wildcards */ #ifndef NOMINUM_PUBLIC /* diff --git a/lib/dns/master.c b/lib/dns/master.c index 615a95a494..82e21ed2f8 100644 --- a/lib/dns/master.c +++ b/lib/dns/master.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: master.c,v 1.149 2004/05/05 01:32:58 marka Exp $ */ +/* $Id: master.c,v 1.150 2005/01/09 23:40:01 marka Exp $ */ #include @@ -862,6 +862,23 @@ check_ns(dns_loadctx_t *lctx, isc_token_t *token, const char *source, return (result); } +static void +check_wildcard(dns_incctx_t *ictx, const char *source, unsigned long line, + dns_rdatacallbacks_t *callbacks) +{ + dns_name_t *name; + + name = (ictx->glue != NULL) ? ictx->glue : ictx->current; + if (dns_name_internalwildcard(name)) { + char namebuf[DNS_NAME_FORMATSIZE]; + + dns_name_format(name, namebuf, sizeof(namebuf)); + (*callbacks->warn)(callbacks, "%s:%lu: warning: ownername " + "'%s' contains an non-terminal wildcard", + source, line, namebuf); + } +} + static isc_result_t load(dns_loadctx_t *lctx) { dns_rdataclass_t rdclass; @@ -1346,6 +1363,14 @@ load(dns_loadctx_t *lctx) { isc_buffer_init(&target, target_mem, target_size); } + /* + * Check for internal wildcards. + */ + if ((lctx->options & DNS_MASTER_CHECKWILDCARD) + != 0) + check_wildcard(ictx, source, line, + callbacks); + } if ((lctx->options & DNS_MASTER_ZONE) != 0 && (lctx->options & DNS_MASTER_SLAVE) == 0 && @@ -1571,7 +1596,7 @@ load(dns_loadctx_t *lctx) { isc_boolean_t ok; dns_name_t *name; - name = (ictx->glue != NULL) ? ictx-> glue : + name = (ictx->glue != NULL) ? ictx->glue : ictx->current; ok = dns_rdata_checkowner(name, lctx->zclass, type, ISC_TRUE); diff --git a/lib/dns/name.c b/lib/dns/name.c index 27110a93ed..f5805a33c0 100644 --- a/lib/dns/name.c +++ b/lib/dns/name.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: name.c,v 1.146 2004/09/01 05:13:05 marka Exp $ */ +/* $Id: name.c,v 1.147 2005/01/09 23:40:01 marka Exp $ */ #include @@ -385,6 +385,41 @@ dns_name_iswildcard(const dns_name_t *name) { return (ISC_FALSE); } +isc_boolean_t +dns_name_internalwildcard(const dns_name_t *name) { + unsigned char *ndata; + unsigned int count; + unsigned int label; + + /* + * Does 'name' contain a internal wildcard? + */ + + REQUIRE(VALID_NAME(name)); + REQUIRE(name->labels > 0); + + /* + * Skip first label. + */ + ndata = name->ndata; + count = *ndata++; + INSIST(count <= 63); + ndata += count; + label = 1; + /* + * Check all but the last of the remaining labels. + */ + while (label + 1 < name->labels) { + count = *ndata++; + INSIST(count <= 63); + if (count == 1 && *ndata == '*') + return (ISC_TRUE); + ndata += count; + label++; + } + return (ISC_FALSE); +} + static inline unsigned int name_hash(dns_name_t *name, isc_boolean_t case_sensitive) { unsigned int length; diff --git a/lib/dns/zone.c b/lib/dns/zone.c index 063c1a64cd..347358e973 100644 --- a/lib/dns/zone.c +++ b/lib/dns/zone.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.c,v 1.426 2004/12/21 10:45:18 jinmei Exp $ */ +/* $Id: zone.c,v 1.427 2005/01/09 23:40:02 marka Exp $ */ #include @@ -1148,6 +1148,8 @@ zone_gotreadhandle(isc_task_t *task, isc_event_t *event) { options |= DNS_MASTER_CHECKNAMES; if (DNS_ZONE_OPTION(load->zone, DNS_ZONEOPT_CHECKNAMESFAIL)) options |= DNS_MASTER_CHECKNAMESFAIL; + if (DNS_ZONE_OPTION(load->zone, DNS_ZONEOPT_CHECKWILDCARD)) + options |= DNS_MASTER_CHECKWILDCARD; result = dns_master_loadfileinc(load->zone->masterfile, dns_db_origin(load->db), dns_db_origin(load->db), @@ -1218,6 +1220,8 @@ zone_startload(dns_db_t *db, dns_zone_t *zone, isc_time_t loadtime) { options |= DNS_MASTER_CHECKNAMES; if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKNAMESFAIL)) options |= DNS_MASTER_CHECKNAMESFAIL; + if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKWILDCARD)) + options |= DNS_MASTER_CHECKWILDCARD; if (zone->zmgr != NULL && zone->db != NULL && zone->task != NULL) { load = isc_mem_get(zone->mctx, sizeof(*load)); diff --git a/lib/isccfg/namedconf.c b/lib/isccfg/namedconf.c index 90176929dd..866b6bcd8a 100644 --- a/lib/isccfg/namedconf.c +++ b/lib/isccfg/namedconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: namedconf.c,v 1.42 2004/12/21 10:45:20 jinmei Exp $ */ +/* $Id: namedconf.c,v 1.43 2005/01/09 23:40:04 marka Exp $ */ #include @@ -788,6 +788,7 @@ zone_clauses[] = { { "use-alt-transfer-source", &cfg_type_boolean, 0 }, { "zone-statistics", &cfg_type_boolean, 0 }, { "key-directory", &cfg_type_qstring, 0 }, + { "check-wildcard", &cfg_type_boolean, 0 }, { NULL, NULL, 0 } }; From 0756445a735e2df39bf798d8de42ae5dd030aa3b Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Sun, 9 Jan 2005 23:50:39 +0000 Subject: [PATCH 023/130] newcopyrights --- util/copyrights | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/util/copyrights b/util/copyrights index ce8e0738ec..a8d085a9f0 100644 --- a/util/copyrights +++ b/util/copyrights @@ -10,15 +10,15 @@ ./bin/Makefile.in MAKE 1998,1999,2000,2001,2004 ./bin/check/.cvsignore X 2000,2001 ./bin/check/Makefile.in MAKE 2000,2001,2002,2003,2004 -./bin/check/check-tool.c C 2000,2001,2002,2004 +./bin/check/check-tool.c C 2000,2001,2002,2004,2005 ./bin/check/check-tool.h C 2000,2001,2002,2004 ./bin/check/named-checkconf.8 MAN 2000,2001,2002,2004 ./bin/check/named-checkconf.c C 1999,2000,2001,2002,2004 ./bin/check/named-checkconf.docbook SGML 2001,2002,2004 ./bin/check/named-checkconf.html HTML 2001,2002,2004 ./bin/check/named-checkzone.8 MAN 2000,2001,2002,2004 -./bin/check/named-checkzone.c C 1999,2000,2001,2002,2003,2004 -./bin/check/named-checkzone.docbook SGML 2001,2002,2004 +./bin/check/named-checkzone.c C 1999,2000,2001,2002,2003,2004,2005 +./bin/check/named-checkzone.docbook SGML 2001,2002,2004,2005 ./bin/check/named-checkzone.html HTML 2001,2002,2004 ./bin/check/win32/namedcheckconf.dsp X 2001 ./bin/check/win32/namedcheckconf.dsw X 2001 @@ -90,7 +90,7 @@ ./bin/named/aclconf.c C 1999,2000,2001,2002,2004 ./bin/named/builtin.c C 2001,2002,2003,2004 ./bin/named/client.c C 1999,2000,2001,2002,2003,2004 -./bin/named/config.c C 2001,2002,2003,2004 +./bin/named/config.c C 2001,2002,2003,2004,2005 ./bin/named/control.c C 2001,2002,2003,2004 ./bin/named/controlconf.c C 2001,2002,2003,2004 ./bin/named/include/named/aclconf.h C 1999,2000,2001,2004 @@ -151,7 +151,7 @@ ./bin/named/unix/Makefile.in MAKE 1999,2000,2001,2004 ./bin/named/unix/include/named/os.h C 1999,2000,2001,2002,2004 ./bin/named/unix/os.c C 1999,2000,2001,2002,2004 -./bin/named/update.c C 1999,2000,2001,2002,2003,2004 +./bin/named/update.c C 1999,2000,2001,2002,2003,2004,2005 ./bin/named/win32/include/named/ntservice.h C 1999,2000,2001,2002,2003,2004 ./bin/named/win32/include/named/os.h C 1999,2000,2001,2002,2004 ./bin/named/win32/named.dsp X 2001 @@ -160,7 +160,7 @@ ./bin/named/win32/ntservice.c C 1999,2000,2001,2002,2004 ./bin/named/win32/os.c C 1999,2000,2001,2002,2004 ./bin/named/xfrout.c C 1999,2000,2001,2002,2003,2004 -./bin/named/zoneconf.c C 1999,2000,2001,2002,2003,2004 +./bin/named/zoneconf.c C 1999,2000,2001,2002,2003,2004,2005 ./bin/nsupdate/.cvsignore X 2000,2001 ./bin/nsupdate/Makefile.in MAKE 2000,2001,2002,2004 ./bin/nsupdate/nsupdate.8 MAN 2000,2001,2002,2003,2004 @@ -1582,7 +1582,7 @@ ./lib/bind9/.cvsignore X 2001 ./lib/bind9/Makefile.in MAKE 2001,2004 ./lib/bind9/api X 2001 -./lib/bind9/check.c C 2001,2002,2003,2004 +./lib/bind9/check.c C 2001,2002,2003,2004,2005 ./lib/bind9/getaddresses.c C 2001,2002,2004 ./lib/bind9/include/.cvsignore X 2001 ./lib/bind9/include/Makefile.in MAKE 2001,2004 @@ -1659,10 +1659,10 @@ ./lib/dns/include/dns/lib.h C 1999,2000,2001,2004 ./lib/dns/include/dns/log.h C 1999,2000,2001,2003,2004 ./lib/dns/include/dns/lookup.h C 2000,2001,2004 -./lib/dns/include/dns/master.h C 1999,2000,2001,2002,2004 +./lib/dns/include/dns/master.h C 1999,2000,2001,2002,2004,2005 ./lib/dns/include/dns/masterdump.h C 1999,2000,2001,2002,2004 ./lib/dns/include/dns/message.h C 1999,2000,2001,2002,2003,2004 -./lib/dns/include/dns/name.h C 1998,1999,2000,2001,2002,2003,2004 +./lib/dns/include/dns/name.h C 1998,1999,2000,2001,2002,2003,2004,2005 ./lib/dns/include/dns/ncache.h C 1999,2000,2001,2002,2004 ./lib/dns/include/dns/nsec.h C 1999,2000,2001,2003,2004 ./lib/dns/include/dns/opcode.h C 2002,2004 @@ -1699,7 +1699,7 @@ ./lib/dns/include/dns/version.h C 2001,2004 ./lib/dns/include/dns/view.h C 1999,2000,2001,2002,2003,2004 ./lib/dns/include/dns/xfrin.h C 1999,2000,2001,2003,2004 -./lib/dns/include/dns/zone.h C 1999,2000,2001,2002,2003,2004 +./lib/dns/include/dns/zone.h C 1999,2000,2001,2002,2003,2004,2005 ./lib/dns/include/dns/zonekey.h C 2001,2004 ./lib/dns/include/dns/zt.h C 1999,2000,2001,2002,2004 ./lib/dns/include/dst/.cvsignore X 2000,2001 @@ -1714,10 +1714,10 @@ ./lib/dns/lib.c C 1999,2000,2001,2004 ./lib/dns/log.c C 1999,2000,2001,2003,2004 ./lib/dns/lookup.c C 2000,2001,2003,2004 -./lib/dns/master.c C 1999,2000,2001,2002,2003,2004 +./lib/dns/master.c C 1999,2000,2001,2002,2003,2004,2005 ./lib/dns/masterdump.c C 1999,2000,2001,2002,2003,2004 ./lib/dns/message.c C 1999,2000,2001,2002,2003,2004 -./lib/dns/name.c C 1998,1999,2000,2001,2002,2003,2004 +./lib/dns/name.c C 1998,1999,2000,2001,2002,2003,2004,2005 ./lib/dns/ncache.c C 1999,2000,2001,2002,2003,2004 ./lib/dns/nsec.c C 1999,2000,2001,2003,2004 ./lib/dns/openssl_link.c C.NAI 1999,2000,2001,2002,2003,2004 @@ -1866,7 +1866,7 @@ ./lib/dns/win32/libdns.mak X 2001 ./lib/dns/win32/version.c C 1998,1999,2000,2001,2004 ./lib/dns/xfrin.c C 1999,2000,2001,2002,2003,2004 -./lib/dns/zone.c C 1999,2000,2001,2002,2003,2004 +./lib/dns/zone.c C 1999,2000,2001,2002,2003,2004,2005 ./lib/dns/zonekey.c C 2001,2003,2004 ./lib/dns/zt.c C 1999,2000,2001,2002,2004 ./lib/isc/.cvsignore X 1999,2000,2001 @@ -2165,7 +2165,7 @@ ./lib/isccfg/include/isccfg/namedconf.h C 2002,2004 ./lib/isccfg/include/isccfg/version.h C 2001,2004 ./lib/isccfg/log.c C 2001,2004 -./lib/isccfg/namedconf.c C 2002,2003,2004 +./lib/isccfg/namedconf.c C 2002,2003,2004,2005 ./lib/isccfg/parser.c C 2000,2001,2002,2003,2004 ./lib/isccfg/version.c C 1998,1999,2000,2001,2004 ./lib/isccfg/win32/DLLMain.c C 2001,2004 From ffc73e6d26ccf2f643e0c445d716eba20e20d9c7 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 10 Jan 2005 06:01:48 +0000 Subject: [PATCH 024/130] regen --- bin/check/named-checkzone.8 | 11 ++- bin/check/named-checkzone.html | 38 ++++++++-- doc/arm/Bv9ARM.ch06.html | 127 ++++++++++++++++++++++----------- doc/arm/Bv9ARM.ch07.html | 8 +-- doc/arm/Bv9ARM.ch08.html | 14 ++-- doc/arm/Bv9ARM.ch09.html | 108 ++++++++++++++-------------- doc/arm/Bv9ARM.html | 38 +++++----- 7 files changed, 212 insertions(+), 132 deletions(-) diff --git a/bin/check/named-checkzone.8 b/bin/check/named-checkzone.8 index 98c9c6ca02..6961697ca9 100644 --- a/bin/check/named-checkzone.8 +++ b/bin/check/named-checkzone.8 @@ -13,14 +13,14 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: named-checkzone.8,v 1.21 2004/06/03 04:12:35 marka Exp $ +.\" $Id: named-checkzone.8,v 1.22 2005/01/10 06:01:47 marka Exp $ .\" .TH "NAMED-CHECKZONE" "8" "June 13, 2000" "BIND9" "" .SH NAME named-checkzone \- zone file validity checking tool .SH SYNOPSIS .sp -\fBnamed-checkzone\fR [ \fB-d\fR ] [ \fB-j\fR ] [ \fB-q\fR ] [ \fB-v\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-k \fImode\fB\fR ] [ \fB-n \fImode\fB\fR ] [ \fB-o \fIfilename\fB\fR ] [ \fB-t \fIdirectory\fB\fR ] [ \fB-w \fIdirectory\fB\fR ] [ \fB-D\fR ] \fBzonename\fR \fBfilename\fR +\fBnamed-checkzone\fR [ \fB-d\fR ] [ \fB-j\fR ] [ \fB-q\fR ] [ \fB-v\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-k \fImode\fB\fR ] [ \fB-n \fImode\fB\fR ] [ \fB-o \fIfilename\fB\fR ] [ \fB-t \fIdirectory\fB\fR ] [ \fB-w \fIdirectory\fB\fR ] [ \fB-D\fR ] [ \fB-W \fImode\fB\fR ] \fBzonename\fR \fBfilename\fR .SH "DESCRIPTION" .PP \fBnamed-checkzone\fR checks the syntax and integrity of @@ -75,6 +75,13 @@ is similar to the directory clause in \fB-D\fR Dump zone file in canonical format. .TP +\fB-W \fImode\fB\fR +Specify whether to check for non-terminal wildcards. +Non-terminal wildcards are almost always the result of a +failure to understand the wildcard matching algorithm (RFC 1034). +Possible modes are \fB"warn"\fR (default) and +\fB"ignore"\fR. +.TP \fBzonename\fR The domain name of the zone being checked. .TP diff --git a/bin/check/named-checkzone.html b/bin/check/named-checkzone.html index 4e4b53be66..b49f56a59e 100644 --- a/bin/check/named-checkzone.html +++ b/bin/check/named-checkzone.html @@ -15,7 +15,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> - + ] [-D] [-W mode] {zonename} {filename}

DESCRIPTION

OPTIONS

-W mode

Specify whether to check for non-terminal wildcards. + Non-terminal wildcards are almost always the result of a + failure to understand the wildcard matching algorithm (RFC 1034). + Possible modes are "warn" (default) and + "ignore". +

zonename

RETURN VALUES

SEE ALSO

AUTHOR

6.3. Zone File
] [ check-wildcard yes_or_no; ] + [ allow-notify { address_match_list

check-wildcard

This option is used to check for non-terminal wildcards. +The use of non-terminal wildcards is almost always as a result of a failure +to understand the wildcard matching algorithm (RFC 1034). This option +affects master zones. The default (yes) is to check +for non-terminal wildcards and issue a warning. +

6.2.16.2. Forwarding

6.2.16.3. Dual-stack Servers

6.2.16.5. Interfaces

6.2.16.6. Query Address

6.2.16.8. Bad UDP Port Lists

6.2.16.9. Operating System Resource Limits

6.2.16.10. Server Resource Limits

6.2.16.11. Periodic Task Intervals

6.2.19. trusted-keys

6.2.20. trusted-keys

6.2.22. view] [ check-wildcard yes_or_no; ] + [ dialup dialup_option

6.2.24. zone

6.2.24.1. Zone Types

6.2.24.2. Class

6.2.24.3. Zone Options

check-wildcard

See the description of +check-wildcard in Section 6.2.16.1.

database

6.3. Zone File

6.3.1.1. Resource Records

6.3.1.2. Textual expression of RRs

6.3.2. Discussion of MX Records

6.3.4. Inverse Mapping in IPv4

6.3.5. Other Zone File Directives

6.3.5.1. The $ORIGIN

6.3.5.2. The $INCLUDE

6.3.5.3. The $TTL

6.3.6. BIND

7.2. chroot

7.2. chroot

7.2.1. The chroot

7.2.2. Using the setuid

8.1. Common Problems
8.2. Incrementing and Changing the Serial Number
8.3. Where Can I Get Help?

8.1. Common Problems

8.1.1. It's not working; how can I figure out what's wrong?

8.2. Incrementing and Changing the Serial Number

8.3. Where Can I Get Help?

A.1. Acknowledgments

A.1. Acknowledgments

A.1.1. A Brief History of the DNS

Bibliography

Standards

[RFC974] 

[RFC1034] 

[RFC1035] 

[RFC2181] 

[RFC2308] 

[RFC1995] 

[RFC1996] 

[RFC2136] 

[RFC2845] 

Proposed Standards Still Under Development

[RFC1886] 

[RFC2065] 

[RFC2137] 

Other Important RFCs About DNS

[RFC1535] 

[RFC1536] 

[RFC1982] 

Resource Record Types

[RFC1183] 

[RFC1706] 

[RFC2168] 

[RFC1876] 

[RFC2052] 

[RFC2163] 

[RFC2230] 

DNS

[RFC1101] 

[RFC1123] 

[RFC1591] 

[RFC2317] 

DNS

[RFC1537] 

[RFC1912] 

[RFC2010] 

[RFC2219] 

Other DNS

[RFC1464] 

[RFC1713] 

[RFC1794] 

[RFC2240] 

[RFC2345] 

[RFC2352] 

Obsolete and Unimplemented Experimental RRs

[RFC1712] 

A.3.3. Other Documents About BIND

Bibliography

6.2.19. trusted-keys
6.2.20. trusted-keys
6.2.22. view
6.2.24. zone
6.3. Zone File
6.3.2. Discussion of MX Records
6.3.4. Inverse Mapping in IPv4
6.3.5. Other Zone File Directives
6.3.6. BIND
7.2. chroot
7.2.1. The chroot
7.2.2. Using the setuid
8.1. Common Problems
8.1.1. It's not working; how can I figure out what's wrong?
8.2. Incrementing and Changing the Serial Number
8.3. Where Can I Get Help?
A.1. Acknowledgments
A.1.1. A Brief History of the DNS
A.3.3. Other Documents About BIND Date: Mon, 10 Jan 2005 23:43:27 +0000 Subject: [PATCH 025/130] update copyrights --- bin/check/check-tool.c | 4 ++-- bin/check/named-checkzone.c | 4 ++-- bin/check/named-checkzone.docbook | 4 ++-- bin/named/config.c | 4 ++-- bin/named/update.c | 4 ++-- bin/named/zoneconf.c | 4 ++-- lib/bind9/check.c | 4 ++-- lib/dns/include/dns/master.h | 4 ++-- lib/dns/include/dns/name.h | 4 ++-- lib/dns/include/dns/zone.h | 4 ++-- lib/dns/master.c | 4 ++-- lib/dns/name.c | 4 ++-- lib/dns/zone.c | 4 ++-- lib/isccfg/namedconf.c | 4 ++-- 14 files changed, 28 insertions(+), 28 deletions(-) diff --git a/bin/check/check-tool.c b/bin/check/check-tool.c index f06602fb33..d38cd8aea5 100644 --- a/bin/check/check-tool.c +++ b/bin/check/check-tool.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: check-tool.c,v 1.14 2005/01/09 23:39:56 marka Exp $ */ +/* $Id: check-tool.c,v 1.15 2005/01/10 23:43:12 marka Exp $ */ #include diff --git a/bin/check/named-checkzone.c b/bin/check/named-checkzone.c index 83886a60b1..f23e7291d1 100644 --- a/bin/check/named-checkzone.c +++ b/bin/check/named-checkzone.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named-checkzone.c,v 1.32 2005/01/09 23:39:56 marka Exp $ */ +/* $Id: named-checkzone.c,v 1.33 2005/01/10 23:43:12 marka Exp $ */ #include diff --git a/bin/check/named-checkzone.docbook b/bin/check/named-checkzone.docbook index 213267d65e..f824876ace 100644 --- a/bin/check/named-checkzone.docbook +++ b/bin/check/named-checkzone.docbook @@ -1,6 +1,6 @@ - + diff --git a/bin/named/config.c b/bin/named/config.c index 6f34fc1acc..0c17bc946c 100644 --- a/bin/named/config.c +++ b/bin/named/config.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2001-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: config.c,v 1.53 2005/01/09 23:39:57 marka Exp $ */ +/* $Id: config.c,v 1.54 2005/01/10 23:43:16 marka Exp $ */ #include diff --git a/bin/named/update.c b/bin/named/update.c index 6bc8c337bd..2d4c264205 100644 --- a/bin/named/update.c +++ b/bin/named/update.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: update.c,v 1.119 2005/01/09 23:39:58 marka Exp $ */ +/* $Id: update.c,v 1.120 2005/01/10 23:43:17 marka Exp $ */ #include diff --git a/bin/named/zoneconf.c b/bin/named/zoneconf.c index 7d56979101..5d01470d3c 100644 --- a/bin/named/zoneconf.c +++ b/bin/named/zoneconf.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zoneconf.c,v 1.115 2005/01/09 23:39:58 marka Exp $ */ +/* $Id: zoneconf.c,v 1.116 2005/01/10 23:43:17 marka Exp $ */ #include diff --git a/lib/bind9/check.c b/lib/bind9/check.c index aad0cd5ebf..545fbbf439 100644 --- a/lib/bind9/check.c +++ b/lib/bind9/check.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2001-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: check.c,v 1.52 2005/01/09 23:40:00 marka Exp $ */ +/* $Id: check.c,v 1.53 2005/01/10 23:43:20 marka Exp $ */ #include diff --git a/lib/dns/include/dns/master.h b/lib/dns/include/dns/master.h index 8b7b7866b4..a0f8be6165 100644 --- a/lib/dns/include/dns/master.h +++ b/lib/dns/include/dns/master.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: master.h,v 1.39 2005/01/09 23:40:03 marka Exp $ */ +/* $Id: master.h,v 1.40 2005/01/10 23:43:24 marka Exp $ */ #ifndef DNS_MASTER_H #define DNS_MASTER_H 1 diff --git a/lib/dns/include/dns/name.h b/lib/dns/include/dns/name.h index 662ce5b059..8e8d0cd4fc 100644 --- a/lib/dns/include/dns/name.h +++ b/lib/dns/include/dns/name.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: name.h,v 1.112 2005/01/09 23:40:03 marka Exp $ */ +/* $Id: name.h,v 1.113 2005/01/10 23:43:25 marka Exp $ */ #ifndef DNS_NAME_H #define DNS_NAME_H 1 diff --git a/lib/dns/include/dns/zone.h b/lib/dns/include/dns/zone.h index c05a927dd6..ce9c100df0 100644 --- a/lib/dns/include/dns/zone.h +++ b/lib/dns/include/dns/zone.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.h,v 1.129 2005/01/09 23:40:03 marka Exp $ */ +/* $Id: zone.h,v 1.130 2005/01/10 23:43:25 marka Exp $ */ #ifndef DNS_ZONE_H #define DNS_ZONE_H 1 diff --git a/lib/dns/master.c b/lib/dns/master.c index 82e21ed2f8..be86774871 100644 --- a/lib/dns/master.c +++ b/lib/dns/master.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: master.c,v 1.150 2005/01/09 23:40:01 marka Exp $ */ +/* $Id: master.c,v 1.151 2005/01/10 23:43:22 marka Exp $ */ #include diff --git a/lib/dns/name.c b/lib/dns/name.c index f5805a33c0..a9fba7c708 100644 --- a/lib/dns/name.c +++ b/lib/dns/name.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: name.c,v 1.147 2005/01/09 23:40:01 marka Exp $ */ +/* $Id: name.c,v 1.148 2005/01/10 23:43:22 marka Exp $ */ #include diff --git a/lib/dns/zone.c b/lib/dns/zone.c index 347358e973..031f45dc94 100644 --- a/lib/dns/zone.c +++ b/lib/dns/zone.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.c,v 1.427 2005/01/09 23:40:02 marka Exp $ */ +/* $Id: zone.c,v 1.428 2005/01/10 23:43:22 marka Exp $ */ #include diff --git a/lib/isccfg/namedconf.c b/lib/isccfg/namedconf.c index 866b6bcd8a..ea2ba78734 100644 --- a/lib/isccfg/namedconf.c +++ b/lib/isccfg/namedconf.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2002, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: namedconf.c,v 1.43 2005/01/09 23:40:04 marka Exp $ */ +/* $Id: namedconf.c,v 1.44 2005/01/10 23:43:27 marka Exp $ */ #include From 0d0ed0297fedcf7fd3751cb7bfa63da0b04b143a Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 10 Jan 2005 23:49:41 +0000 Subject: [PATCH 026/130] update copyright notice --- COPYRIGHT | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/COPYRIGHT b/COPYRIGHT index 034871bbe6..2c1c62c1b6 100644 --- a/COPYRIGHT +++ b/COPYRIGHT @@ -1,4 +1,4 @@ -Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") Copyright (C) 1996-2003 Internet Software Consortium. Permission to use, copy, modify, and distribute this software for any @@ -13,7 +13,7 @@ LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -$Id: COPYRIGHT,v 1.9 2004/03/05 05:47:55 marka Exp $ +$Id: COPYRIGHT,v 1.10 2005/01/10 23:49:41 marka Exp $ Portions Copyright (C) 1996-2001 Nominum, Inc. From a02a0a8a7eb461619931f4a0e896afa247b52c54 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 10 Jan 2005 23:57:52 +0000 Subject: [PATCH 027/130] newcopyrights --- util/copyrights | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/util/copyrights b/util/copyrights index a8d085a9f0..987a9c9529 100644 --- a/util/copyrights +++ b/util/copyrights @@ -1,6 +1,6 @@ ./.cvsignore X 1999,2000,2001 ./CHANGES X 2000,2001 -./COPYRIGHT TXT 1996,1997,1998,1999,2000,2001,2002,2003,2004 +./COPYRIGHT TXT 1996,1997,1998,1999,2000,2001,2002,2003,2004,2005 ./FAQ X 2000,2001 ./Makefile.in MAKE 1998,1999,2000,2001,2002,2004 ./README X 1999,2000,2001 @@ -16,10 +16,10 @@ ./bin/check/named-checkconf.c C 1999,2000,2001,2002,2004 ./bin/check/named-checkconf.docbook SGML 2001,2002,2004 ./bin/check/named-checkconf.html HTML 2001,2002,2004 -./bin/check/named-checkzone.8 MAN 2000,2001,2002,2004 +./bin/check/named-checkzone.8 MAN 2000,2001,2002,2004,2005 ./bin/check/named-checkzone.c C 1999,2000,2001,2002,2003,2004,2005 ./bin/check/named-checkzone.docbook SGML 2001,2002,2004,2005 -./bin/check/named-checkzone.html HTML 2001,2002,2004 +./bin/check/named-checkzone.html HTML 2001,2002,2004,2005 ./bin/check/win32/namedcheckconf.dsp X 2001 ./bin/check/win32/namedcheckconf.dsw X 2001 ./bin/check/win32/namedcheckconf.mak X 2001 From 101c34c3f7fd2c86668d37bf7f921c5112204c07 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 11 Jan 2005 01:36:35 +0000 Subject: [PATCH 028/130] update copyright --- bin/check/named-checkzone.8 | 4 ++-- bin/check/named-checkzone.html | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/bin/check/named-checkzone.8 b/bin/check/named-checkzone.8 index 6961697ca9..967eb489e3 100644 --- a/bin/check/named-checkzone.8 +++ b/bin/check/named-checkzone.8 @@ -1,4 +1,4 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (C) 2000-2002 Internet Software Consortium. .\" .\" Permission to use, copy, modify, and distribute this software for any @@ -13,7 +13,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.22 2005/01/10 06:01:47 marka Exp $ +.\" $Id: named-checkzone.8,v 1.23 2005/01/11 01:36:35 marka Exp $ .\" .TH "NAMED-CHECKZONE" "8" "June 13, 2000" "BIND9" "" .SH NAME diff --git a/bin/check/named-checkzone.html b/bin/check/named-checkzone.html index b49f56a59e..e95190a266 100644 --- a/bin/check/named-checkzone.html +++ b/bin/check/named-checkzone.html @@ -1,5 +1,5 @@ - + Date: Tue, 11 Jan 2005 02:14:29 +0000 Subject: [PATCH 029/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 727bb4d04b..d115593bec 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1796. [placeholder] rt12498 + 1795. [placeholder] rt13396 1794. [func] Named and named-checkzone can now both check for From ad5bc22a819190839bdcc4d102d023782dc23660 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 11 Jan 2005 03:46:11 +0000 Subject: [PATCH 030/130] 1797. [func] named-checkconf now check acls to verify that they only refer to existing acls. [RT #13101] --- CHANGES | 3 + bin/named/Makefile.in | 6 +- bin/named/controlconf.c | 17 +-- bin/named/include/named/control.h | 7 +- bin/named/include/named/zoneconf.h | 7 +- bin/named/server.c | 31 ++--- bin/named/zoneconf.c | 10 +- doc/arm/Bv9ARM-book.xml | 4 +- lib/bind9/check.c | 120 ++++++++++++++---- lib/isccfg/Makefile.in | 6 +- {bin/named => lib/isccfg}/aclconf.c | 45 ++++--- lib/isccfg/include/isccfg/Makefile.in | 4 +- .../isccfg/include/isccfg}/aclconf.h | 27 ++-- 13 files changed, 184 insertions(+), 103 deletions(-) rename {bin/named => lib/isccfg}/aclconf.c (85%) rename {bin/named/include/named => lib/isccfg/include/isccfg}/aclconf.h (79%) diff --git a/CHANGES b/CHANGES index d115593bec..b0dd6f8852 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,6 @@ +1797. [func] named-checkconf now check acls to verify that they + only refer to existing acls. [RT #13101] + 1796. [placeholder] rt12498 1795. [placeholder] rt13396 diff --git a/bin/named/Makefile.in b/bin/named/Makefile.in index 8d38e14137..3244c50c70 100644 --- a/bin/named/Makefile.in +++ b/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.84 2004/09/06 21:53:34 marka Exp $ +# $Id: Makefile.in,v 1.85 2005/01/11 03:46:07 marka Exp $ srcdir = @srcdir@ VPATH = @srcdir@ @@ -63,7 +63,7 @@ SUBDIRS = unix TARGETS = named@EXEEXT@ lwresd@EXEEXT@ -OBJS = aclconf.@O@ builtin.@O@ client.@O@ config.@O@ control.@O@ \ +OBJS = builtin.@O@ client.@O@ config.@O@ control.@O@ \ controlconf.@O@ interfacemgr.@O@ \ listenlist.@O@ log.@O@ logconf.@O@ main.@O@ notify.@O@ \ query.@O@ server.@O@ sortlist.@O@ \ @@ -75,7 +75,7 @@ OBJS = aclconf.@O@ builtin.@O@ client.@O@ config.@O@ control.@O@ \ UOBJS = unix/os.@O@ -SRCS = aclconf.c builtin.c client.c config.c control.c \ +SRCS = builtin.c client.c config.c control.c \ controlconf.c interfacemgr.c \ listenlist.c log.c logconf.c main.c notify.c \ query.c server.c sortlist.c \ diff --git a/bin/named/controlconf.c b/bin/named/controlconf.c index ce541e0201..a120a5aac9 100644 --- a/bin/named/controlconf.c +++ b/bin/named/controlconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: controlconf.c,v 1.40 2004/03/05 04:57:46 marka Exp $ */ +/* $Id: controlconf.c,v 1.41 2005/01/11 03:46:08 marka Exp $ */ #include @@ -915,7 +915,7 @@ static void update_listener(ns_controls_t *cp, controllistener_t **listenerp, cfg_obj_t *control, cfg_obj_t *config, isc_sockaddr_t *addr, - ns_aclconfctx_t *aclconfctx, const char *socktext) + cfg_aclconfctx_t *aclconfctx, const char *socktext) { controllistener_t *listener; cfg_obj_t *allow; @@ -995,8 +995,9 @@ update_listener(ns_controls_t *cp, */ if (control != NULL) { allow = cfg_tuple_get(control, "allow"); - result = ns_acl_fromconfig(allow, config, aclconfctx, - listener->mctx, &new_acl); + result = cfg_acl_fromconfig(allow, config, ns_g_lctx, + aclconfctx, listener->mctx, + &new_acl); } else { result = dns_acl_any(listener->mctx, &new_acl); } @@ -1018,7 +1019,7 @@ update_listener(ns_controls_t *cp, static void add_listener(ns_controls_t *cp, controllistener_t **listenerp, cfg_obj_t *control, cfg_obj_t *config, isc_sockaddr_t *addr, - ns_aclconfctx_t *aclconfctx, const char *socktext) + cfg_aclconfctx_t *aclconfctx, const char *socktext) { isc_mem_t *mctx = cp->server->mctx; controllistener_t *listener; @@ -1050,8 +1051,8 @@ add_listener(ns_controls_t *cp, controllistener_t **listenerp, */ if (control != NULL) { allow = cfg_tuple_get(control, "allow"); - result = ns_acl_fromconfig(allow, config, aclconfctx, - mctx, &new_acl); + result = cfg_acl_fromconfig(allow, config, ns_g_lctx, + aclconfctx, mctx, &new_acl); } else { result = dns_acl_any(mctx, &new_acl); } @@ -1136,7 +1137,7 @@ add_listener(ns_controls_t *cp, controllistener_t **listenerp, isc_result_t ns_controls_configure(ns_controls_t *cp, cfg_obj_t *config, - ns_aclconfctx_t *aclconfctx) + cfg_aclconfctx_t *aclconfctx) { controllistener_t *listener; controllistenerlist_t new_listeners; diff --git a/bin/named/include/named/control.h b/bin/named/include/named/control.h index 8e2b2cdaf7..7d86365d7e 100644 --- a/bin/named/include/named/control.h +++ b/bin/named/include/named/control.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: control.h,v 1.16 2004/10/11 05:30:19 marka Exp $ */ +/* $Id: control.h,v 1.17 2005/01/11 03:46:09 marka Exp $ */ #ifndef NAMED_CONTROL_H #define NAMED_CONTROL_H 1 @@ -26,7 +26,8 @@ #include -#include +#include + #include #define NS_CONTROL_PORT 953 @@ -70,7 +71,7 @@ ns_controls_destroy(ns_controls_t **ctrlsp); isc_result_t ns_controls_configure(ns_controls_t *controls, cfg_obj_t *config, - ns_aclconfctx_t *aclconfctx); + cfg_aclconfctx_t *aclconfctx); /* * Configure zero or more command channels into 'controls' * as defined in the configuration parse tree 'config'. diff --git a/bin/named/include/named/zoneconf.h b/bin/named/include/named/zoneconf.h index b2f9092e06..186f1d1532 100644 --- a/bin/named/include/named/zoneconf.h +++ b/bin/named/include/named/zoneconf.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zoneconf.h,v 1.19 2004/03/05 04:57:57 marka Exp $ */ +/* $Id: zoneconf.h,v 1.20 2005/01/11 03:46:09 marka Exp $ */ #ifndef NS_ZONECONF_H #define NS_ZONECONF_H 1 @@ -23,15 +23,14 @@ #include #include +#include #include -#include - ISC_LANG_BEGINDECLS isc_result_t ns_zone_configure(cfg_obj_t *config, cfg_obj_t *vconfig, cfg_obj_t *zconfig, - ns_aclconfctx_t *ac, dns_zone_t *zone); + cfg_aclconfctx_t *ac, dns_zone_t *zone); /* * Configure or reconfigure a zone according to the named.conf * data in 'cctx' and 'czone'. diff --git a/bin/named/server.c b/bin/named/server.c index 4b22013393..f4c06d61e4 100644 --- a/bin/named/server.c +++ b/bin/named/server.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.c,v 1.434 2004/12/21 10:45:15 jinmei Exp $ */ +/* $Id: server.c,v 1.435 2005/01/11 03:46:08 marka Exp $ */ #include @@ -165,11 +165,11 @@ ns_server_reload(isc_task_t *task, isc_event_t *event); static isc_result_t ns_listenelt_fromconfig(cfg_obj_t *listener, cfg_obj_t *config, - ns_aclconfctx_t *actx, + cfg_aclconfctx_t *actx, isc_mem_t *mctx, ns_listenelt_t **target); static isc_result_t ns_listenlist_fromconfig(cfg_obj_t *listenlist, cfg_obj_t *config, - ns_aclconfctx_t *actx, + cfg_aclconfctx_t *actx, isc_mem_t *mctx, ns_listenlist_t **target); static isc_result_t @@ -183,7 +183,7 @@ configure_alternates(cfg_obj_t *config, dns_view_t *view, static isc_result_t configure_zone(cfg_obj_t *config, cfg_obj_t *zconfig, cfg_obj_t *vconfig, isc_mem_t *mctx, dns_view_t *view, - ns_aclconfctx_t *aclconf); + cfg_aclconfctx_t *aclconf); static void end_reserved_dispatches(ns_server_t *server, isc_boolean_t all); @@ -195,7 +195,7 @@ end_reserved_dispatches(ns_server_t *server, isc_boolean_t all); */ static isc_result_t configure_view_acl(cfg_obj_t *vconfig, cfg_obj_t *config, - const char *aclname, ns_aclconfctx_t *actx, + const char *aclname, cfg_aclconfctx_t *actx, isc_mem_t *mctx, dns_acl_t **aclp) { isc_result_t result; @@ -222,7 +222,8 @@ configure_view_acl(cfg_obj_t *vconfig, cfg_obj_t *config, */ return (ISC_R_SUCCESS); - result = ns_acl_fromconfig(aclobj, config, actx, mctx, aclp); + result = cfg_acl_fromconfig(aclobj, config, ns_g_lctx, + actx, mctx, aclp); return (result); } @@ -715,7 +716,7 @@ disable_algorithms(cfg_obj_t *disabled, dns_resolver_t *resolver) { */ static isc_result_t configure_view(dns_view_t *view, cfg_obj_t *config, cfg_obj_t *vconfig, - isc_mem_t *mctx, ns_aclconfctx_t *actx, + isc_mem_t *mctx, cfg_aclconfctx_t *actx, isc_boolean_t need_hints) { cfg_obj_t *maps[4]; @@ -1608,7 +1609,7 @@ create_view(cfg_obj_t *vconfig, dns_viewlist_t *viewlist, dns_view_t **viewp) { static isc_result_t configure_zone(cfg_obj_t *config, cfg_obj_t *zconfig, cfg_obj_t *vconfig, isc_mem_t *mctx, dns_view_t *view, - ns_aclconfctx_t *aclconf) + cfg_aclconfctx_t *aclconf) { dns_view_t *pview = NULL; /* Production view */ dns_zone_t *zone = NULL; /* New or reused zone */ @@ -2183,14 +2184,14 @@ load_configuration(const char *filename, ns_server_t *server, dns_view_t *view_next; dns_viewlist_t viewlist; dns_viewlist_t tmpviewlist; - ns_aclconfctx_t aclconfctx; + cfg_aclconfctx_t aclconfctx; isc_uint32_t interface_interval; isc_uint32_t heartbeat_interval; isc_uint32_t udpsize; in_port_t listen_port; int i; - ns_aclconfctx_init(&aclconfctx); + cfg_aclconfctx_init(&aclconfctx); ISC_LIST_INIT(viewlist); /* Ensure exclusive access to configuration data. */ @@ -2770,7 +2771,7 @@ load_configuration(const char *filename, ns_server_t *server, result = ISC_R_SUCCESS; cleanup: - ns_aclconfctx_destroy(&aclconfctx); + cfg_aclconfctx_destroy(&aclconfctx); if (parser != NULL) { if (config != NULL) @@ -3552,7 +3553,7 @@ ns_server_togglequerylog(ns_server_t *server) { static isc_result_t ns_listenlist_fromconfig(cfg_obj_t *listenlist, cfg_obj_t *config, - ns_aclconfctx_t *actx, + cfg_aclconfctx_t *actx, isc_mem_t *mctx, ns_listenlist_t **target) { isc_result_t result; @@ -3591,7 +3592,7 @@ ns_listenlist_fromconfig(cfg_obj_t *listenlist, cfg_obj_t *config, */ static isc_result_t ns_listenelt_fromconfig(cfg_obj_t *listener, cfg_obj_t *config, - ns_aclconfctx_t *actx, + cfg_aclconfctx_t *actx, isc_mem_t *mctx, ns_listenelt_t **target) { isc_result_t result; @@ -3623,8 +3624,8 @@ ns_listenelt_fromconfig(cfg_obj_t *listener, cfg_obj_t *config, if (result != ISC_R_SUCCESS) return (result); - result = ns_acl_fromconfig(cfg_tuple_get(listener, "acl"), - config, actx, mctx, &delt->acl); + result = cfg_acl_fromconfig(cfg_tuple_get(listener, "acl"), + config, ns_g_lctx, actx, mctx, &delt->acl); if (result != ISC_R_SUCCESS) { ns_listenelt_destroy(delt); return (result); diff --git a/bin/named/zoneconf.c b/bin/named/zoneconf.c index 5d01470d3c..c9924c87b0 100644 --- a/bin/named/zoneconf.c +++ b/bin/named/zoneconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zoneconf.c,v 1.116 2005/01/10 23:43:17 marka Exp $ */ +/* $Id: zoneconf.c,v 1.117 2005/01/11 03:46:08 marka Exp $ */ #include @@ -56,7 +56,7 @@ */ static isc_result_t configure_zone_acl(cfg_obj_t *zconfig, cfg_obj_t *vconfig, cfg_obj_t *config, - const char *aclname, ns_aclconfctx_t *actx, + const char *aclname, cfg_aclconfctx_t *actx, dns_zone_t *zone, void (*setzacl)(dns_zone_t *, dns_acl_t *), void (*clearzacl)(dns_zone_t *)) @@ -85,8 +85,8 @@ configure_zone_acl(cfg_obj_t *zconfig, cfg_obj_t *vconfig, cfg_obj_t *config, return (ISC_R_SUCCESS); } - result = ns_acl_fromconfig(aclobj, config, actx, - dns_zone_getmctx(zone), &dacl); + result = cfg_acl_fromconfig(aclobj, config, ns_g_lctx, actx, + dns_zone_getmctx(zone), &dacl); if (result != ISC_R_SUCCESS) return (result); (*setzacl)(zone, dacl); @@ -309,7 +309,7 @@ checknames(dns_zonetype_t ztype, cfg_obj_t **maps, cfg_obj_t **objp) { isc_result_t ns_zone_configure(cfg_obj_t *config, cfg_obj_t *vconfig, cfg_obj_t *zconfig, - ns_aclconfctx_t *ac, dns_zone_t *zone) + cfg_aclconfctx_t *ac, dns_zone_t *zone) { isc_result_t result; char *zname; diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 3658577441..45194af34c 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -2,7 +2,7 @@ - + BIND 9 Administrator Reference Manual @@ -1836,7 +1836,7 @@ which constitute an address match list can be any of the following: a key ID, as defined by the key statement - the name of an address match list previously defined with + the name of an address match list defined with the acl statement a nested address match list enclosed in braces diff --git a/lib/bind9/check.c b/lib/bind9/check.c index 545fbbf439..aa2af9021e 100644 --- a/lib/bind9/check.c +++ b/lib/bind9/check.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: check.c,v 1.53 2005/01/10 23:43:20 marka Exp $ */ +/* $Id: check.c,v 1.54 2005/01/11 03:46:10 marka Exp $ */ #include @@ -33,11 +33,13 @@ #include #include +#include #include #include #include #include +#include #include #include @@ -344,6 +346,57 @@ mustbesecure(cfg_obj_t *secure, isc_symtab_t *symtab, isc_log_t *logctx, return (result); } +static isc_result_t +checkacl(const char *aclname, cfg_obj_t *zconfig, cfg_obj_t *voptions, + cfg_obj_t *config, isc_log_t *logctx, isc_mem_t *mctx) +{ + isc_result_t result; + cfg_obj_t *aclobj = NULL; + cfg_obj_t *options; + dns_acl_t *acl = NULL; + cfg_aclconfctx_t actx; + + if (zconfig != NULL) { + options = cfg_tuple_get(zconfig, "options"); + cfg_map_get(options, aclname, &aclobj); + } + if (voptions != NULL && aclobj == NULL) + cfg_map_get(voptions, aclname, &aclobj); + if (config != NULL && aclobj == NULL) { + options = NULL; + cfg_map_get(config, "options", &options); + if (options != NULL) + cfg_map_get(options, aclname, &aclobj); + } + if (aclobj == NULL) + return (ISC_R_SUCCESS); + cfg_aclconfctx_init(&actx); + result = cfg_acl_fromconfig(aclobj, config, logctx, &actx, mctx, &acl); + if (acl != NULL) + dns_acl_detach(&acl); + return (result); +} + +static isc_result_t +check_viewacls(cfg_obj_t *voptions, cfg_obj_t *config, + isc_log_t *logctx, isc_mem_t *mctx) +{ + isc_result_t result = ISC_R_SUCCESS, tresult; + int i = 0; + + static const char *acls[] = { "allow-query", "allow-query-cache", + "allow-recursion", "blackhole", "match-clients", + "match-destinations", "sortlist", NULL }; + + while (acls[i] != NULL) { + tresult = checkacl(acls[i++], NULL, voptions, config, + logctx, mctx); + if (tresult != ISC_R_SUCCESS) + result = tresult; + } + return (result); +} + typedef struct { const char *name; unsigned int scale; @@ -682,6 +735,7 @@ validate_masters(cfg_obj_t *obj, cfg_obj_t *config, isc_uint32_t *countp, #define HINTZONE 8 #define FORWARDZONE 16 #define DELEGATIONZONE 32 +#define CHECKACL 64 typedef struct { const char *name; @@ -689,8 +743,9 @@ typedef struct { } optionstable; static isc_result_t -check_zoneconf(cfg_obj_t *zconfig, cfg_obj_t *config, isc_symtab_t *symtab, - dns_rdataclass_t defclass, isc_log_t *logctx, isc_mem_t *mctx) +check_zoneconf(cfg_obj_t *zconfig, cfg_obj_t *voptions, cfg_obj_t *config, + isc_symtab_t *symtab, dns_rdataclass_t defclass, + isc_log_t *logctx, isc_mem_t *mctx) { const char *zname; const char *typestr; @@ -705,9 +760,9 @@ check_zoneconf(cfg_obj_t *zconfig, cfg_obj_t *config, isc_symtab_t *symtab, isc_buffer_t b; static optionstable options[] = { - { "allow-query", MASTERZONE | SLAVEZONE | STUBZONE }, - { "allow-notify", SLAVEZONE }, - { "allow-transfer", MASTERZONE | SLAVEZONE }, + { "allow-query", MASTERZONE | SLAVEZONE | STUBZONE | CHECKACL }, + { "allow-notify", SLAVEZONE | CHECKACL }, + { "allow-transfer", MASTERZONE | SLAVEZONE | CHECKACL }, { "notify", MASTERZONE | SLAVEZONE }, { "also-notify", MASTERZONE | SLAVEZONE }, { "dialup", MASTERZONE | SLAVEZONE | STUBZONE }, @@ -730,8 +785,8 @@ check_zoneconf(cfg_obj_t *zconfig, cfg_obj_t *config, isc_symtab_t *symtab, { "min-refresh-time", SLAVEZONE | STUBZONE }, { "sig-validity-interval", MASTERZONE }, { "zone-statistics", MASTERZONE | SLAVEZONE | STUBZONE }, - { "allow-update", MASTERZONE }, - { "allow-update-forwarding", SLAVEZONE }, + { "allow-update", MASTERZONE | CHECKACL }, + { "allow-update-forwarding", SLAVEZONE | CHECKACL }, { "file", MASTERZONE | SLAVEZONE | STUBZONE | HINTZONE }, { "journal", MASTERZONE | SLAVEZONE }, { "ixfr-base", MASTERZONE | SLAVEZONE }, @@ -833,6 +888,7 @@ check_zoneconf(cfg_obj_t *zconfig, cfg_obj_t *config, isc_symtab_t *symtab, /* * Look for inappropriate options for the given zone type. + * Check that ACLs expand correctly. */ for (i = 0; i < sizeof(options) / sizeof(options[0]); i++) { obj = NULL; @@ -853,6 +909,16 @@ check_zoneconf(cfg_obj_t *zconfig, cfg_obj_t *config, isc_symtab_t *symtab, "in '%s' zone '%s'", options[i].name, typestr, zname); } + obj = NULL; + if ((options[i].allowed & ztype) != 0 && + (options[i].allowed & CHECKACL) != 0) { + + tresult = checkacl(options[i].name, zconfig, + voptions, config, logctx, mctx); + if (tresult != ISC_R_SUCCESS) + result = tresult; + } + } /* @@ -1090,7 +1156,7 @@ check_servers(cfg_obj_t *servers, isc_log_t *logctx) { } static isc_result_t -check_viewconf(cfg_obj_t *config, cfg_obj_t *vconfig, dns_rdataclass_t vclass, +check_viewconf(cfg_obj_t *config, cfg_obj_t *voptions, dns_rdataclass_t vclass, isc_log_t *logctx, isc_mem_t *mctx) { cfg_obj_t *servers = NULL; @@ -1110,8 +1176,8 @@ check_viewconf(cfg_obj_t *config, cfg_obj_t *vconfig, dns_rdataclass_t vclass, if (tresult != ISC_R_SUCCESS) return (ISC_R_NOMEMORY); - if (vconfig != NULL) - (void)cfg_map_get(vconfig, "zone", &zones); + if (voptions != NULL) + (void)cfg_map_get(voptions, "zone", &zones); else (void)cfg_map_get(config, "zone", &zones); @@ -1122,8 +1188,8 @@ check_viewconf(cfg_obj_t *config, cfg_obj_t *vconfig, dns_rdataclass_t vclass, isc_result_t tresult; cfg_obj_t *zone = cfg_listelt_value(element); - tresult = check_zoneconf(zone, config, symtab, vclass, - logctx, mctx); + tresult = check_zoneconf(zone, voptions, config, symtab, + vclass, logctx, mctx); if (tresult != ISC_R_SUCCESS) result = ISC_R_FAILURE; } @@ -1147,9 +1213,9 @@ check_viewconf(cfg_obj_t *config, cfg_obj_t *vconfig, dns_rdataclass_t vclass, return (tresult); } - if (vconfig != NULL) { + if (voptions != NULL) { keys = NULL; - (void)cfg_map_get(vconfig, "key", &keys); + (void)cfg_map_get(voptions, "key", &keys); tresult = check_keylist(keys, symtab, logctx); if (tresult == ISC_R_EXISTS) result = ISC_R_FAILURE; @@ -1164,52 +1230,56 @@ check_viewconf(cfg_obj_t *config, cfg_obj_t *vconfig, dns_rdataclass_t vclass, /* * Check that forwarding is reasonable. */ - if (vconfig == NULL) { + if (voptions == NULL) { cfg_obj_t *options = NULL; (void)cfg_map_get(config, "options", &options); if (options != NULL) if (check_forward(options, logctx) != ISC_R_SUCCESS) result = ISC_R_FAILURE; } else { - if (check_forward(vconfig, logctx) != ISC_R_SUCCESS) + if (check_forward(voptions, logctx) != ISC_R_SUCCESS) result = ISC_R_FAILURE; } /* * Check that dual-stack-servers is reasonable. */ - if (vconfig == NULL) { + if (voptions == NULL) { cfg_obj_t *options = NULL; (void)cfg_map_get(config, "options", &options); if (options != NULL) if (check_dual_stack(options, logctx) != ISC_R_SUCCESS) result = ISC_R_FAILURE; } else { - if (check_dual_stack(vconfig, logctx) != ISC_R_SUCCESS) + if (check_dual_stack(voptions, logctx) != ISC_R_SUCCESS) result = ISC_R_FAILURE; } /* * Check that rrset-order is reasonable. */ - if (vconfig != NULL) { - if (check_order(vconfig, logctx) != ISC_R_SUCCESS) + if (voptions != NULL) { + if (check_order(voptions, logctx) != ISC_R_SUCCESS) result = ISC_R_FAILURE; } - if (vconfig != NULL) { - (void)cfg_map_get(vconfig, "server", &servers); + if (voptions != NULL) { + (void)cfg_map_get(voptions, "server", &servers); if (servers != NULL && check_servers(servers, logctx) != ISC_R_SUCCESS) result = ISC_R_FAILURE; } - if (vconfig != NULL) - tresult = check_options(vconfig, logctx, mctx); + if (voptions != NULL) + tresult = check_options(voptions, logctx, mctx); else tresult = check_options(config, logctx, mctx); if (tresult != ISC_R_SUCCESS) result = tresult; + tresult = check_viewacls(voptions, config, logctx, mctx); + if (tresult != ISC_R_SUCCESS) + result = tresult; + return (result); } diff --git a/lib/isccfg/Makefile.in b/lib/isccfg/Makefile.in index 72e1199edb..3759d07c30 100644 --- a/lib/isccfg/Makefile.in +++ b/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.13 2004/07/20 07:13:42 marka Exp $ +# $Id: Makefile.in,v 1.14 2005/01/11 03:46:10 marka Exp $ srcdir = @srcdir@ VPATH = @srcdir@ @@ -43,10 +43,10 @@ LIBS = @LIBS@ SUBDIRS = include # Alphabetically -OBJS = log.@O@ namedconf.@O@ parser.@O@ version.@O@ +OBJS = aclconf.@O@ log.@O@ namedconf.@O@ parser.@O@ version.@O@ # Alphabetically -SRCS = log.c namedconf.c parser.c version.c +SRCS = aclconf.c log.c namedconf.c parser.c version.c TARGETS = timestamp diff --git a/bin/named/aclconf.c b/lib/isccfg/aclconf.c similarity index 85% rename from bin/named/aclconf.c rename to lib/isccfg/aclconf.c index 9258ff33ae..ed2d583548 100644 --- a/bin/named/aclconf.c +++ b/lib/isccfg/aclconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: aclconf.c,v 1.30 2004/03/05 04:57:46 marka Exp $ */ +/* $Id: aclconf.c,v 1.2 2005/01/11 03:46:11 marka Exp $ */ #include @@ -24,20 +24,20 @@ #include #include +#include #include #include #include -#include void -ns_aclconfctx_init(ns_aclconfctx_t *ctx) { +cfg_aclconfctx_init(cfg_aclconfctx_t *ctx) { ISC_LIST_INIT(ctx->named_acl_cache); } void -ns_aclconfctx_destroy(ns_aclconfctx_t *ctx) { +cfg_aclconfctx_destroy(cfg_aclconfctx_t *ctx) { dns_acl_t *dacl, *next; for (dacl = ISC_LIST_HEAD(ctx->named_acl_cache); dacl != NULL; @@ -75,8 +75,8 @@ get_acl_def(cfg_obj_t *cctx, char *name, cfg_obj_t **ret) { static isc_result_t convert_named_acl(cfg_obj_t *nameobj, cfg_obj_t *cctx, - ns_aclconfctx_t *ctx, isc_mem_t *mctx, - dns_acl_t **target) + isc_log_t *lctx, cfg_aclconfctx_t *ctx, + isc_mem_t *mctx, dns_acl_t **target) { isc_result_t result; cfg_obj_t *cacl = NULL; @@ -96,11 +96,11 @@ convert_named_acl(cfg_obj_t *nameobj, cfg_obj_t *cctx, /* Not yet converted. Convert now. */ result = get_acl_def(cctx, aclname, &cacl); if (result != ISC_R_SUCCESS) { - cfg_obj_log(nameobj, dns_lctx, ISC_LOG_WARNING, + cfg_obj_log(nameobj, lctx, ISC_LOG_WARNING, "undefined ACL '%s'", aclname); return (result); } - result = ns_acl_fromconfig(cacl, cctx, ctx, mctx, &dacl); + result = cfg_acl_fromconfig(cacl, cctx, lctx, ctx, mctx, &dacl); if (result != ISC_R_SUCCESS) return (result); dacl->name = isc_mem_strdup(dacl->mctx, aclname); @@ -112,7 +112,9 @@ convert_named_acl(cfg_obj_t *nameobj, cfg_obj_t *cctx, } static isc_result_t -convert_keyname(cfg_obj_t *keyobj, isc_mem_t *mctx, dns_name_t *dnsname) { +convert_keyname(cfg_obj_t *keyobj, isc_log_t *lctx, isc_mem_t *mctx, + dns_name_t *dnsname) +{ isc_result_t result; isc_buffer_t buf; dns_fixedname_t fixname; @@ -126,7 +128,7 @@ convert_keyname(cfg_obj_t *keyobj, isc_mem_t *mctx, dns_name_t *dnsname) { result = dns_name_fromtext(dns_fixedname_name(&fixname), &buf, dns_rootname, ISC_FALSE, NULL); if (result != ISC_R_SUCCESS) { - cfg_obj_log(keyobj, dns_lctx, ISC_LOG_WARNING, + cfg_obj_log(keyobj, lctx, ISC_LOG_WARNING, "key name '%s' is not a valid domain name", txtname); return (result); @@ -135,11 +137,12 @@ convert_keyname(cfg_obj_t *keyobj, isc_mem_t *mctx, dns_name_t *dnsname) { } isc_result_t -ns_acl_fromconfig(cfg_obj_t *caml, - cfg_obj_t *cctx, - ns_aclconfctx_t *ctx, - isc_mem_t *mctx, - dns_acl_t **target) +cfg_acl_fromconfig(cfg_obj_t *caml, + cfg_obj_t *cctx, + isc_log_t *lctx, + cfg_aclconfctx_t *ctx, + isc_mem_t *mctx, + dns_acl_t **target) { isc_result_t result; unsigned int count; @@ -184,14 +187,15 @@ ns_acl_fromconfig(cfg_obj_t *caml, /* Key name */ de->type = dns_aclelementtype_keyname; dns_name_init(&de->u.keyname, NULL); - result = convert_keyname(ce, mctx, &de->u.keyname); + result = convert_keyname(ce, lctx, mctx, + &de->u.keyname); if (result != ISC_R_SUCCESS) goto cleanup; } else if (cfg_obj_islist(ce)) { /* Nested ACL */ de->type = dns_aclelementtype_nestedacl; - result = ns_acl_fromconfig(ce, cctx, ctx, mctx, - &de->u.nestedacl); + result = cfg_acl_fromconfig(ce, cctx, lctx, ctx, + mctx, &de->u.nestedacl); if (result != ISC_R_SUCCESS) goto cleanup; } else if (cfg_obj_isstring(ce)) { @@ -208,13 +212,14 @@ ns_acl_fromconfig(cfg_obj_t *caml, de->negative = ISC_TF(! de->negative); } else { de->type = dns_aclelementtype_nestedacl; - result = convert_named_acl(ce, cctx, ctx, mctx, + result = convert_named_acl(ce, cctx, lctx, + ctx, mctx, &de->u.nestedacl); if (result != ISC_R_SUCCESS) goto cleanup; } } else { - cfg_obj_log(ce, dns_lctx, ISC_LOG_WARNING, + cfg_obj_log(ce, lctx, ISC_LOG_WARNING, "address match list contains " "unsupported element type"); result = ISC_R_FAILURE; diff --git a/lib/isccfg/include/isccfg/Makefile.in b/lib/isccfg/include/isccfg/Makefile.in index a250c5d47f..7f1a588d55 100644 --- a/lib/isccfg/include/isccfg/Makefile.in +++ b/lib/isccfg/include/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.8 2004/03/05 05:12:26 marka Exp $ +# $Id: Makefile.in,v 1.9 2005/01/11 03:46:11 marka Exp $ srcdir = @srcdir@ VPATH = @srcdir@ @@ -26,7 +26,7 @@ top_srcdir = @top_srcdir@ # machine generated. The latter are handled specially in the # install target below. # -HEADERS = cfg.h grammar.h log.h namedconf.h version.h +HEADERS = aclconf.h cfg.h grammar.h log.h namedconf.h version.h SUBDIRS = TARGETS = diff --git a/bin/named/include/named/aclconf.h b/lib/isccfg/include/isccfg/aclconf.h similarity index 79% rename from bin/named/include/named/aclconf.h rename to lib/isccfg/include/isccfg/aclconf.h index 56b6647d41..4452503b9c 100644 --- a/bin/named/include/named/aclconf.h +++ b/lib/isccfg/include/isccfg/aclconf.h @@ -15,10 +15,10 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: aclconf.h,v 1.13 2004/03/05 04:57:55 marka Exp $ */ +/* $Id: aclconf.h,v 1.2 2005/01/11 03:46:11 marka Exp $ */ -#ifndef NS_ACLCONF_H -#define NS_ACLCONF_H 1 +#ifndef ISCCFG_ACLCONF_H +#define ISCCFG_ACLCONF_H 1 #include @@ -26,9 +26,9 @@ #include -typedef struct ns_aclconfctx { +typedef struct cfg_aclconfctx { ISC_LIST(dns_acl_t) named_acl_cache; -} ns_aclconfctx_t; +} cfg_aclconfctx_t; /*** *** Functions @@ -37,23 +37,24 @@ typedef struct ns_aclconfctx { ISC_LANG_BEGINDECLS void -ns_aclconfctx_init(ns_aclconfctx_t *ctx); +cfg_aclconfctx_init(cfg_aclconfctx_t *ctx); /* * Initialize an ACL configuration context. */ void -ns_aclconfctx_destroy(ns_aclconfctx_t *ctx); +cfg_aclconfctx_destroy(cfg_aclconfctx_t *ctx); /* * Destroy an ACL configuration context. */ isc_result_t -ns_acl_fromconfig(cfg_obj_t *caml, - cfg_obj_t *cctx, - ns_aclconfctx_t *ctx, - isc_mem_t *mctx, - dns_acl_t **target); +cfg_acl_fromconfig(cfg_obj_t *caml, + cfg_obj_t *cctx, + isc_log_t *lctx, + cfg_aclconfctx_t *ctx, + isc_mem_t *mctx, + dns_acl_t **target); /* * Construct a new dns_acl_t from configuration data in 'caml' and * 'cctx'. Memory is allocated through 'mctx'. @@ -69,4 +70,4 @@ ns_acl_fromconfig(cfg_obj_t *caml, ISC_LANG_ENDDECLS -#endif /* NS_ACLCONF_H */ +#endif /* ISCCFG_ACLCONF_H */ From e286a65f41d7e1f9058227b1d491f73c4c4ed49a Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 11 Jan 2005 05:30:00 +0000 Subject: [PATCH 031/130] regen --- doc/arm/Bv9ARM.ch06.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/arm/Bv9ARM.ch06.html b/doc/arm/Bv9ARM.ch06.html index 90426440a7..f6a0db6510 100644 --- a/doc/arm/Bv9ARM.ch06.html +++ b/doc/arm/Bv9ARM.ch06.html @@ -689,7 +689,7 @@ CLASS="command" >

  • the name of an address match list previously defined with +>the name of an address match list defined with the acl Date: Tue, 11 Jan 2005 23:10:06 +0000 Subject: [PATCH 032/130] 1792. [func] New zone option "notify-delay". Specify a minimum delay between sets of NOTIFY messages. --- CHANGES | 3 ++- bin/named/config.c | 3 ++- bin/named/named.conf.docbook | 5 ++++- bin/named/zoneconf.c | 8 +++++++- lib/dns/include/dns/zone.h | 20 +++++++++++++++++- lib/dns/zone.c | 40 ++++++++++++++++++++++++++++-------- lib/isccfg/namedconf.c | 3 ++- 7 files changed, 68 insertions(+), 14 deletions(-) diff --git a/CHANGES b/CHANGES index b0dd6f8852..a6cd511340 100644 --- a/CHANGES +++ b/CHANGES @@ -10,7 +10,8 @@ 1793. [placeholder] rt13378 -1792. [placeholder] rt13124 +1792. [func] New zone option "notify-delay". Specify a minimum + delay between sets of NOTIFY messages. 1791. [placeholder] rt13230 diff --git a/bin/named/config.c b/bin/named/config.c index 0c17bc946c..98a4c4fef1 100644 --- a/bin/named/config.c +++ b/bin/named/config.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: config.c,v 1.54 2005/01/10 23:43:16 marka Exp $ */ +/* $Id: config.c,v 1.55 2005/01/11 23:10:04 marka Exp $ */ #include @@ -136,6 +136,7 @@ options {\n\ allow-transfer {any;};\n\ notify yes;\n\ # also-notify \n\ + notify-delay 5;\n\ dialup no;\n\ # forward \n\ # forwarders \n\ diff --git a/bin/named/named.conf.docbook b/bin/named/named.conf.docbook index 55efcdff85..7f5726bf82 100644 --- a/bin/named/named.conf.docbook +++ b/bin/named/named.conf.docbook @@ -15,7 +15,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> - + @@ -258,6 +258,7 @@ options { notify notifytype; notify-source ( ipv4_address | * ) port ( integer | * ) ; notify-source-v6 ( ipv6_address | * ) port ( integer | * ) ; + notify-delay seconds; also-notify port integer { ( ipv4_address | ipv6_address ) port integer ; ... }; allow-notify { address_match_element; ... }; @@ -387,6 +388,7 @@ view string optional_class notify notifytype; notify-source ( ipv4_address | * ) port ( integer | * ) ; notify-source-v6 ( ipv6_address | * ) port ( integer | * ) ; + notify-delay seconds; also-notify port integer { ( ipv4_address | ipv6_address ) port integer ; ... }; allow-notify { address_match_element; ... }; @@ -464,6 +466,7 @@ zone string optional_class notify notifytype; notify-source ( ipv4_address | * ) port ( integer | * ) ; notify-source-v6 ( ipv6_address | * ) port ( integer | * ) ; + notify-delay seconds; also-notify port integer { ( ipv4_address | ipv6_address ) port integer ; ... }; allow-notify { address_match_element; ... }; diff --git a/bin/named/zoneconf.c b/bin/named/zoneconf.c index c9924c87b0..e02427219e 100644 --- a/bin/named/zoneconf.c +++ b/bin/named/zoneconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zoneconf.c,v 1.117 2005/01/11 03:46:08 marka Exp $ */ +/* $Id: zoneconf.c,v 1.118 2005/01/11 23:10:04 marka Exp $ */ #include @@ -561,6 +561,12 @@ ns_zone_configure(cfg_obj_t *config, cfg_obj_t *vconfig, cfg_obj_t *zconfig, INSIST(0); dns_zone_setoption(zone, DNS_ZONEOPT_CHECKNAMES, check); dns_zone_setoption(zone, DNS_ZONEOPT_CHECKNAMESFAIL, fail); + + obj = NULL; + result = ns_config_get(maps, "notify-delay", &obj); + INSIST(result == ISC_R_SUCCESS); + dns_zone_setnotifydelay(zone, cfg_obj_asuint32(obj)); + } /* diff --git a/lib/dns/include/dns/zone.h b/lib/dns/include/dns/zone.h index ce9c100df0..78a3e28587 100644 --- a/lib/dns/include/dns/zone.h +++ b/lib/dns/include/dns/zone.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.h,v 1.130 2005/01/10 23:43:25 marka Exp $ */ +/* $Id: zone.h,v 1.131 2005/01/11 23:10:05 marka Exp $ */ #ifndef DNS_ZONE_H #define DNS_ZONE_H 1 @@ -1446,6 +1446,24 @@ dns_zone_setacache(dns_zone_t *zone, dns_acache_t *acache); * 'zone' will have a reference to 'acache' */ +void +dns_zone_setnotifydelay(dns_zone_t *zone, isc_uint32_t delay); +/* + * Set the minimum delay between sets of notify messages. + * + * Requires: + * 'zone' to be valid. + */ + +isc_uint32_t +dns_zone_getnotifydelay(dns_zone_t *zone); +/* + * Get the minimum delay between sets of notify messages. + * + * Requires: + * 'zone' to be valid. + */ + ISC_LANG_ENDDECLS #endif /* DNS_ZONE_H */ diff --git a/lib/dns/zone.c b/lib/dns/zone.c index 031f45dc94..73cae60739 100644 --- a/lib/dns/zone.c +++ b/lib/dns/zone.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.c,v 1.428 2005/01/10 23:43:22 marka Exp $ */ +/* $Id: zone.c,v 1.429 2005/01/11 23:10:05 marka Exp $ */ #include @@ -154,6 +154,7 @@ struct dns_zone { isc_time_t refreshtime; isc_time_t dumptime; isc_time_t loadtime; + isc_time_t notifytime; isc_uint32_t serial; isc_uint32_t refresh; isc_uint32_t retry; @@ -220,7 +221,8 @@ struct dns_zone { /* * Optional per-zone statistics counters (NULL if not present). */ - isc_uint64_t *counters; + isc_uint64_t *counters; + isc_uint32_t notifydelay; }; #define DNS_ZONE_FLAG(z,f) (ISC_TF(((z)->flags & (f)) != 0)) @@ -443,7 +445,7 @@ static void forward_callback(isc_task_t *task, isc_event_t *event); static void zone_saveunique(dns_zone_t *zone, const char *path, const char *templat); static void zone_maintenance(dns_zone_t *zone); -static void zone_notify(dns_zone_t *zone); +static void zone_notify(dns_zone_t *zone, isc_time_t *now); static void dump_done(void *arg, isc_result_t result); #define ENTER zone_debuglog(zone, me, 1, "enter") @@ -487,10 +489,12 @@ isc_result_t dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) { isc_result_t result; dns_zone_t *zone; + isc_time_t now; REQUIRE(zonep != NULL && *zonep == NULL); REQUIRE(mctx != NULL); + TIME_NOW(&now); zone = isc_mem_get(mctx, sizeof(*zone)); if (zone == NULL) return (ISC_R_NOMEMORY); @@ -530,6 +534,7 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) { isc_time_settoepoch(&zone->refreshtime); isc_time_settoepoch(&zone->dumptime); isc_time_settoepoch(&zone->loadtime); + zone->notifytime = now; zone->serial = 0; zone->refresh = DNS_ZONE_DEFAULTREFRESH; zone->retry = DNS_ZONE_DEFAULTRETRY; @@ -580,6 +585,7 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) { ISC_LINK_INIT(zone, statelink); zone->statelist = NULL; zone->counters = NULL; + zone->notifydelay = 5; zone->magic = ZONE_MAGIC; @@ -2287,8 +2293,9 @@ zone_maintenance(dns_zone_t *zone) { switch (zone->type) { case dns_zone_master: case dns_zone_slave: - if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_NEEDNOTIFY)) - zone_notify(zone); + if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_NEEDNOTIFY) && + isc_time_compare(&now, &zone->notifytime) >= 0) + zone_notify(zone, &now); break; default: break; @@ -3016,7 +3023,7 @@ dns_zone_notify(dns_zone_t *zone) { } static void -zone_notify(dns_zone_t *zone) { +zone_notify(dns_zone_t *zone, isc_time_t *now) { dns_dbnode_t *node = NULL; dns_dbversion_t *version = NULL; dns_name_t *origin = NULL; @@ -3041,6 +3048,7 @@ zone_notify(dns_zone_t *zone) { LOCK_ZONE(zone); DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_NEEDNOTIFY); notifytype = zone->notifytype; + DNS_ZONE_TIME_ADD(now, zone->notifydelay, &zone->notifytime); UNLOCK_ZONE(zone); if (! DNS_ZONE_FLAG(zone, DNS_ZONEFLG_LOADED)) @@ -4460,7 +4468,7 @@ zone_settimer(dns_zone_t *zone, isc_time_t *now) { switch (zone->type) { case dns_zone_master: if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_NEEDNOTIFY)) - next = *now; + next = zone->notifytime; if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_NEEDDUMP) && !DNS_ZONE_FLAG(zone, DNS_ZONEFLG_DUMPING)) { INSIST(!isc_time_isepoch(&zone->dumptime)); @@ -4472,7 +4480,7 @@ zone_settimer(dns_zone_t *zone, isc_time_t *now) { case dns_zone_slave: if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_NEEDNOTIFY)) - next = *now; + next = zone->notifytime; /*FALLTHROUGH*/ case dns_zone_stub: @@ -6997,3 +7005,19 @@ dns_zone_checknames(dns_zone_t *zone, dns_name_t *name, dns_rdata_t *rdata) { return (ISC_R_SUCCESS); } + +void +dns_zone_setnotifydelay(dns_zone_t *zone, isc_uint32_t delay) { + REQUIRE(DNS_ZONE_VALID(zone)); + + LOCK_ZONE(zone); + zone->notifydelay = delay; + UNLOCK_ZONE(zone); +} + +isc_uint32_t +dns_zone_getnotifydelay(dns_zone_t *zone) { + REQUIRE(DNS_ZONE_VALID(zone)); + + return (zone->notifydelay); +} diff --git a/lib/isccfg/namedconf.c b/lib/isccfg/namedconf.c index ea2ba78734..4d7b88c82f 100644 --- a/lib/isccfg/namedconf.c +++ b/lib/isccfg/namedconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: namedconf.c,v 1.44 2005/01/10 23:43:27 marka Exp $ */ +/* $Id: namedconf.c,v 1.45 2005/01/11 23:10:06 marka Exp $ */ #include @@ -765,6 +765,7 @@ zone_clauses[] = { { "notify-source", &cfg_type_sockaddr4wild, 0 }, { "notify-source-v6", &cfg_type_sockaddr6wild, 0 }, { "also-notify", &cfg_type_portiplist, 0 }, + { "notify-delay", &cfg_type_uint32, 0 }, { "dialup", &cfg_type_dialuptype, 0 }, { "forward", &cfg_type_forwardtype, 0 }, { "forwarders", &cfg_type_portiplist, 0 }, From c25080dc50542213058c240226c9f342186e6285 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 11 Jan 2005 23:36:16 +0000 Subject: [PATCH 033/130] newcopyrights --- util/copyrights | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/util/copyrights b/util/copyrights index 987a9c9529..ea4da082df 100644 --- a/util/copyrights +++ b/util/copyrights @@ -86,18 +86,18 @@ ./bin/dnssec/win32/signzone.dsw X 2001 ./bin/dnssec/win32/signzone.mak X 2001 ./bin/named/.cvsignore X 1999,2000,2001 -./bin/named/Makefile.in MAKE 1998,1999,2000,2001,2002,2004 +./bin/named/Makefile.in MAKE 1998,1999,2000,2001,2002,2004,2005 ./bin/named/aclconf.c C 1999,2000,2001,2002,2004 ./bin/named/builtin.c C 2001,2002,2003,2004 ./bin/named/client.c C 1999,2000,2001,2002,2003,2004 ./bin/named/config.c C 2001,2002,2003,2004,2005 ./bin/named/control.c C 2001,2002,2003,2004 -./bin/named/controlconf.c C 2001,2002,2003,2004 +./bin/named/controlconf.c C 2001,2002,2003,2004,2005 ./bin/named/include/named/aclconf.h C 1999,2000,2001,2004 ./bin/named/include/named/builtin.h C 2001,2004 ./bin/named/include/named/client.h C 1999,2000,2001,2002,2003,2004 ./bin/named/include/named/config.h C 2001,2002,2004 -./bin/named/include/named/control.h C 2001,2002,2003,2004 +./bin/named/include/named/control.h C 2001,2002,2003,2004,2005 ./bin/named/include/named/globals.h C 1999,2000,2001,2002,2003,2004 ./bin/named/include/named/interfacemgr.h C 1999,2000,2001,2002,2004 ./bin/named/include/named/listenlist.h C 2000,2001,2004 @@ -117,7 +117,7 @@ ./bin/named/include/named/types.h C 1999,2000,2001,2004 ./bin/named/include/named/update.h C 1999,2000,2001,2004 ./bin/named/include/named/xfrout.h C 1999,2000,2001,2004 -./bin/named/include/named/zoneconf.h C 1999,2000,2001,2002,2004 +./bin/named/include/named/zoneconf.h C 1999,2000,2001,2002,2004,2005 ./bin/named/interfacemgr.c C 1999,2000,2001,2002,2004 ./bin/named/listenlist.c C 2000,2001,2004 ./bin/named/log.c C 1999,2000,2001,2002,2004 @@ -137,13 +137,13 @@ ./bin/named/main.c C 1999,2000,2001,2002,2003,2004 ./bin/named/named.8 MAN 2000,2001,2003,2004 ./bin/named/named.conf.5 MAN 2004 -./bin/named/named.conf.docbook SGML 2004 +./bin/named/named.conf.docbook SGML 2004,2005 ./bin/named/named.conf.html HTML 2004 ./bin/named/named.docbook SGML 2000,2001,2003,2004 ./bin/named/named.html HTML 2000,2001,2003,2004 ./bin/named/notify.c C 1999,2000,2001,2002,2003,2004 ./bin/named/query.c C 1999,2000,2001,2002,2003,2004 -./bin/named/server.c C 1999,2000,2001,2002,2003,2004 +./bin/named/server.c C 1999,2000,2001,2002,2003,2004,2005 ./bin/named/sortlist.c C 2000,2001,2004 ./bin/named/tkeyconf.c C 1999,2000,2001,2004 ./bin/named/tsigconf.c C 1999,2000,2001,2004 @@ -2153,12 +2153,14 @@ ./lib/isccc/win32/libisccc.mak X 2001 ./lib/isccc/win32/version.c C 2001,2004 ./lib/isccfg/.cvsignore X 2001 -./lib/isccfg/Makefile.in MAKE 2001,2002,2003,2004 +./lib/isccfg/Makefile.in MAKE 2001,2002,2003,2004,2005 +./lib/isccfg/aclconf.c C 2005 ./lib/isccfg/api X 2001 ./lib/isccfg/include/.cvsignore X 2001 ./lib/isccfg/include/Makefile.in MAKE 2001,2004 ./lib/isccfg/include/isccfg/.cvsignore X 2001 -./lib/isccfg/include/isccfg/Makefile.in MAKE 2001,2002,2004 +./lib/isccfg/include/isccfg/Makefile.in MAKE 2001,2002,2004,2005 +./lib/isccfg/include/isccfg/aclconf.h C 2005 ./lib/isccfg/include/isccfg/cfg.h C 2000,2001,2002,2004 ./lib/isccfg/include/isccfg/grammar.h C 2002,2003,2004 ./lib/isccfg/include/isccfg/log.h C 2001,2004 From 369ed36db553e24f0170c9e0063b075cbab99fe1 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 11 Jan 2005 23:50:56 +0000 Subject: [PATCH 034/130] aclconf.h was moved. preserve copyright history. --- util/copyrights | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/util/copyrights b/util/copyrights index ea4da082df..01f16e2a00 100644 --- a/util/copyrights +++ b/util/copyrights @@ -2154,13 +2154,13 @@ ./lib/isccc/win32/version.c C 2001,2004 ./lib/isccfg/.cvsignore X 2001 ./lib/isccfg/Makefile.in MAKE 2001,2002,2003,2004,2005 -./lib/isccfg/aclconf.c C 2005 +./lib/isccfg/aclconf.c C 1999,2000,2001,2002,2004,2005 ./lib/isccfg/api X 2001 ./lib/isccfg/include/.cvsignore X 2001 ./lib/isccfg/include/Makefile.in MAKE 2001,2004 ./lib/isccfg/include/isccfg/.cvsignore X 2001 ./lib/isccfg/include/isccfg/Makefile.in MAKE 2001,2002,2004,2005 -./lib/isccfg/include/isccfg/aclconf.h C 2005 +./lib/isccfg/include/isccfg/aclconf.h C 1999,2000,2001,2004,2005 ./lib/isccfg/include/isccfg/cfg.h C 2000,2001,2002,2004 ./lib/isccfg/include/isccfg/grammar.h C 2002,2003,2004 ./lib/isccfg/include/isccfg/log.h C 2001,2004 From f450814ab8989820a7bc9a2c484eb9f2c1c7b915 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 11 Jan 2005 23:56:50 +0000 Subject: [PATCH 035/130] 1793. [func] Extend adjusting TTL warning messages. [RT #13378] --- CHANGES | 2 +- lib/dns/diff.c | 19 ++++++++++++++++--- 2 files changed, 17 insertions(+), 4 deletions(-) diff --git a/CHANGES b/CHANGES index a6cd511340..83a5d74694 100644 --- a/CHANGES +++ b/CHANGES @@ -8,7 +8,7 @@ 1794. [func] Named and named-checkzone can now both check for non-terminal wildcard records. -1793. [placeholder] rt13378 +1793. [func] Extend adjusting TTL warning messages. [RT #13378] 1792. [func] New zone option "notify-delay". Specify a minimum delay between sets of NOTIFY messages. diff --git a/lib/dns/diff.c b/lib/dns/diff.c index 651b9564fc..c24f20ec0f 100644 --- a/lib/dns/diff.c +++ b/lib/dns/diff.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: diff.c,v 1.9 2004/03/05 05:09:19 marka Exp $ */ +/* $Id: diff.c,v 1.10 2005/01/11 23:56:50 marka Exp $ */ #include @@ -30,8 +30,10 @@ #include #include #include +#include #include #include +#include #include #define CHECK(op) \ @@ -195,6 +197,9 @@ diff_apply(dns_diff_t *diff, dns_db_t *db, dns_dbversion_t *ver, dns_difftuple_t *t; dns_dbnode_t *node = NULL; isc_result_t result; + char namebuf[DNS_NAME_FORMATSIZE]; + char typebuf[DNS_RDATATYPE_FORMATSIZE]; + char classbuf[DNS_RDATACLASS_FORMATSIZE]; REQUIRE(DNS_DIFF_VALID(diff)); REQUIRE(DNS_DB_VALID(db)); @@ -254,11 +259,19 @@ diff_apply(dns_diff_t *diff, dns_db_t *db, dns_dbversion_t *ver, t->rdata.type == type && rdata_covers(&t->rdata) == covers) { + dns_name_format(name, namebuf, sizeof(namebuf)); + dns_rdatatype_format(t->rdata.type, typebuf, + sizeof(typebuf)); + dns_rdataclass_format(t->rdata.rdclass, + classbuf, + sizeof(classbuf)); if (t->ttl != rdl.ttl && warn) isc_log_write(DIFF_COMMON_LOGARGS, ISC_LOG_WARNING, - "TTL differs in rdataset, " - "adjusting %lu -> %lu", + "'%s/%s/%s': TTL differs in " + "rdataset, adjusting " + "%lu -> %lu", + namebuf, typebuf, classbuf, (unsigned long) t->ttl, (unsigned long) rdl.ttl); ISC_LIST_APPEND(rdl.rdata, &t->rdata, link); From abeb45c7753db766ebe07c855632819271f6df9b Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 12 Jan 2005 01:56:12 +0000 Subject: [PATCH 036/130] update copyrights --- bin/named/Makefile.in | 4 ++-- bin/named/controlconf.c | 4 ++-- bin/named/include/named/control.h | 4 ++-- bin/named/include/named/zoneconf.h | 4 ++-- bin/named/named.conf.docbook | 4 ++-- bin/named/server.c | 4 ++-- lib/isccfg/Makefile.in | 4 ++-- lib/isccfg/aclconf.c | 4 ++-- lib/isccfg/include/isccfg/Makefile.in | 4 ++-- lib/isccfg/include/isccfg/aclconf.h | 4 ++-- 10 files changed, 20 insertions(+), 20 deletions(-) diff --git a/bin/named/Makefile.in b/bin/named/Makefile.in index 3244c50c70..52e9cf8d65 100644 --- a/bin/named/Makefile.in +++ b/bin/named/Makefile.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 1998-2002 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -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.85 2005/01/11 03:46:07 marka Exp $ +# $Id: Makefile.in,v 1.86 2005/01/12 01:56:06 marka Exp $ srcdir = @srcdir@ VPATH = @srcdir@ diff --git a/bin/named/controlconf.c b/bin/named/controlconf.c index a120a5aac9..571c660081 100644 --- a/bin/named/controlconf.c +++ b/bin/named/controlconf.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2001-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: controlconf.c,v 1.41 2005/01/11 03:46:08 marka Exp $ */ +/* $Id: controlconf.c,v 1.42 2005/01/12 01:56:06 marka Exp $ */ #include diff --git a/bin/named/include/named/control.h b/bin/named/include/named/control.h index 7d86365d7e..27dfde4d13 100644 --- a/bin/named/include/named/control.h +++ b/bin/named/include/named/control.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2001-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: control.h,v 1.17 2005/01/11 03:46:09 marka Exp $ */ +/* $Id: control.h,v 1.18 2005/01/12 01:56:11 marka Exp $ */ #ifndef NAMED_CONTROL_H #define NAMED_CONTROL_H 1 diff --git a/bin/named/include/named/zoneconf.h b/bin/named/include/named/zoneconf.h index 186f1d1532..61c72d6b2c 100644 --- a/bin/named/include/named/zoneconf.h +++ b/bin/named/include/named/zoneconf.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zoneconf.h,v 1.20 2005/01/11 03:46:09 marka Exp $ */ +/* $Id: zoneconf.h,v 1.21 2005/01/12 01:56:11 marka Exp $ */ #ifndef NS_ZONECONF_H #define NS_ZONECONF_H 1 diff --git a/bin/named/named.conf.docbook b/bin/named/named.conf.docbook index 7f5726bf82..58dd5889a1 100644 --- a/bin/named/named.conf.docbook +++ b/bin/named/named.conf.docbook @@ -1,6 +1,6 @@ - + diff --git a/bin/named/server.c b/bin/named/server.c index f4c06d61e4..0dc6cdf049 100644 --- a/bin/named/server.c +++ b/bin/named/server.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.c,v 1.435 2005/01/11 03:46:08 marka Exp $ */ +/* $Id: server.c,v 1.436 2005/01/12 01:56:07 marka Exp $ */ #include diff --git a/lib/isccfg/Makefile.in b/lib/isccfg/Makefile.in index 3759d07c30..feddcde69f 100644 --- a/lib/isccfg/Makefile.in +++ b/lib/isccfg/Makefile.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 2001-2003 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -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 2005/01/11 03:46:10 marka Exp $ +# $Id: Makefile.in,v 1.15 2005/01/12 01:56:12 marka Exp $ srcdir = @srcdir@ VPATH = @srcdir@ diff --git a/lib/isccfg/aclconf.c b/lib/isccfg/aclconf.c index ed2d583548..3937ca1bc4 100644 --- a/lib/isccfg/aclconf.c +++ b/lib/isccfg/aclconf.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: aclconf.c,v 1.2 2005/01/11 03:46:11 marka Exp $ */ +/* $Id: aclconf.c,v 1.3 2005/01/12 01:56:12 marka Exp $ */ #include diff --git a/lib/isccfg/include/isccfg/Makefile.in b/lib/isccfg/include/isccfg/Makefile.in index 7f1a588d55..74de3a6f5f 100644 --- a/lib/isccfg/include/isccfg/Makefile.in +++ b/lib/isccfg/include/isccfg/Makefile.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 2001, 2002 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -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 2005/01/11 03:46:11 marka Exp $ +# $Id: Makefile.in,v 1.10 2005/01/12 01:56:12 marka Exp $ srcdir = @srcdir@ VPATH = @srcdir@ diff --git a/lib/isccfg/include/isccfg/aclconf.h b/lib/isccfg/include/isccfg/aclconf.h index 4452503b9c..39ede975c6 100644 --- a/lib/isccfg/include/isccfg/aclconf.h +++ b/lib/isccfg/include/isccfg/aclconf.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: aclconf.h,v 1.2 2005/01/11 03:46:11 marka Exp $ */ +/* $Id: aclconf.h,v 1.3 2005/01/12 01:56:12 marka Exp $ */ #ifndef ISCCFG_ACLCONF_H #define ISCCFG_ACLCONF_H 1 From 6274add733f4a16dfef4455dafb71a6a4721a0df Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 12 Jan 2005 23:34:14 +0000 Subject: [PATCH 037/130] newcopyrights --- util/copyrights | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util/copyrights b/util/copyrights index 01f16e2a00..8ec7b87807 100644 --- a/util/copyrights +++ b/util/copyrights @@ -1611,7 +1611,7 @@ ./lib/dns/db.c C 1999,2000,2001,2003,2004 ./lib/dns/dbiterator.c C 1999,2000,2001,2004 ./lib/dns/dbtable.c C 1999,2000,2001,2004 -./lib/dns/diff.c C 2000,2001,2002,2003,2004 +./lib/dns/diff.c C 2000,2001,2002,2003,2004,2005 ./lib/dns/dispatch.c C 1999,2000,2001,2002,2003,2004 ./lib/dns/dnssec.c C 1999,2000,2001,2002,2003,2004 ./lib/dns/ds.c C 2002,2003,2004 From 32374d94830dc91c2aa598ba8438edb5d7fa1331 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 13 Jan 2005 04:52:21 +0000 Subject: [PATCH 038/130] regen --- bin/named/named.conf.5 | 5 ++++- bin/named/named.conf.html | 22 +++++++++++++++++----- doc/misc/options | 4 ++++ 3 files changed, 25 insertions(+), 6 deletions(-) diff --git a/bin/named/named.conf.5 b/bin/named/named.conf.5 index fd1b91d0fa..515886dea0 100644 --- a/bin/named/named.conf.5 +++ b/bin/named/named.conf.5 @@ -12,7 +12,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: named.conf.5,v 1.6 2004/11/11 02:06:28 marka Exp $ +.\" $Id: named.conf.5,v 1.7 2005/01/13 04:52:20 marka Exp $ .\" .TH "NAMED.CONF" "5" "Aug 13, 2004" "BIND9" "" .SH NAME @@ -223,6 +223,7 @@ options { notify \fInotifytype\fR; notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + notify-delay \fIseconds\fR; also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... }; allow-notify { \fIaddress_match_element\fR; ... }; @@ -351,6 +352,7 @@ view \fIstring\fR \fIoptional_class\fR { notify \fInotifytype\fR; notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + notify-delay \fIseconds\fR; also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... }; allow-notify { \fIaddress_match_element\fR; ... }; @@ -427,6 +429,7 @@ zone \fIstring\fR \fIoptional_class\fR { notify \fInotifytype\fR; notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + notify-delay \fIseconds\fR; also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... }; allow-notify { \fIaddress_match_element\fR; ... }; diff --git a/bin/named/named.conf.html b/bin/named/named.conf.html index 7a79e849aa..ca85d57b26 100644 --- a/bin/named/named.conf.html +++ b/bin/named/named.conf.html @@ -14,7 +14,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> - + integer | * ) ];
    + notify-delay seconds;
    also-notify [ port

    VIEW

    integer | * ) ];
    + notify-delay seconds;
    also-notify [ port

    ZONE

    integer | * ) ];
    + notify-delay seconds;
    also-notify [ port

    FILES

    SEE ALSO

    | * ) [ port ( | * ) ]; also-notify [ port ] { ( | ) [ port ]; ... }; + notify-delay ; dialup ; forward ( first | only ); forwarders [ port ] { ( | ) @@ -191,6 +192,7 @@ view { | * ) ]; also-notify [ port ] { ( | ) [ port ]; ... }; + notify-delay ; dialup ; forward ( first | only ); forwarders [ port ] { ( | @@ -288,6 +290,7 @@ view { notify-source-v6 ( | * ) [ port ( | * ) ]; also-notify [ port ] { ( | ) [ port ]; ... }; + notify-delay ; dialup ; forward ( first | only ); forwarders [ port ] { ( | ) @@ -355,6 +358,7 @@ zone { notify-source-v6 ( | * ) [ port ( | * ) ]; also-notify [ port ] { ( | ) [ port ]; ... }; + notify-delay ; dialup ; forward ( first | only ); forwarders [ port ] { ( | ) From 5ec08bdbca766adfd0811e9dc45cc82607952537 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 13 Jan 2005 05:15:16 +0000 Subject: [PATCH 039/130] spelling --- lib/isccfg/include/isccfg/aclconf.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/isccfg/include/isccfg/aclconf.h b/lib/isccfg/include/isccfg/aclconf.h index 39ede975c6..642972d3bc 100644 --- a/lib/isccfg/include/isccfg/aclconf.h +++ b/lib/isccfg/include/isccfg/aclconf.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: aclconf.h,v 1.3 2005/01/12 01:56:12 marka Exp $ */ +/* $Id: aclconf.h,v 1.4 2005/01/13 05:15:16 marka Exp $ */ #ifndef ISCCFG_ACLCONF_H #define ISCCFG_ACLCONF_H 1 @@ -60,7 +60,7 @@ cfg_acl_fromconfig(cfg_obj_t *caml, * 'cctx'. Memory is allocated through 'mctx'. * * Any named ACLs referred to within 'caml' will be be converted - * inte nested dns_acl_t objects. Multiple references to the same + * into nested dns_acl_t objects. Multiple references to the same * named ACLs will be converted into shared references to a single * nested dns_acl_t object when the referring objects were created * passing the same ACL configuration context 'ctx'. From b25eafb3f43cd4558c2a97afc92de81aa71c3a8f Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 14 Jan 2005 00:00:29 +0000 Subject: [PATCH 040/130] update copyrights --- lib/dns/diff.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/dns/diff.c b/lib/dns/diff.c index c24f20ec0f..af7f8e9c04 100644 --- a/lib/dns/diff.c +++ b/lib/dns/diff.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: diff.c,v 1.10 2005/01/11 23:56:50 marka Exp $ */ +/* $Id: diff.c,v 1.11 2005/01/14 00:00:29 marka Exp $ */ #include From db2649bad98fc08054feb1a1ed234d8b9b011ea8 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 14 Jan 2005 02:46:40 +0000 Subject: [PATCH 041/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 83a5d74694..8317c0a0e4 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1798. [placeholder] rt11132 + 1797. [func] named-checkconf now check acls to verify that they only refer to existing acls. [RT #13101] From 7502c6600645f120434d84d0ce3df7c3585cfe43 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 14 Jan 2005 03:28:09 +0000 Subject: [PATCH 042/130] 1796. [func] "rndc freeze/thaw" now freezes/thaws all zones. --- CHANGES | 2 +- bin/named/server.c | 30 ++++++++--- bin/rndc/rndc.c | 4 +- lib/dns/include/dns/view.h | 10 +++- lib/dns/include/dns/zt.h | 18 ++++++- lib/dns/view.c | 8 ++- lib/dns/zt.c | 100 +++++++++++++++++++++++++++++++++++-- 7 files changed, 157 insertions(+), 15 deletions(-) diff --git a/CHANGES b/CHANGES index 8317c0a0e4..e419b2afc0 100644 --- a/CHANGES +++ b/CHANGES @@ -3,7 +3,7 @@ 1797. [func] named-checkconf now check acls to verify that they only refer to existing acls. [RT #13101] -1796. [placeholder] rt12498 +1796. [func] "rndc freeze/thaw" now freezes/thaws all zones. 1795. [placeholder] rt13396 diff --git a/bin/named/server.c b/bin/named/server.c index 0dc6cdf049..b2a6e4ad6b 100644 --- a/bin/named/server.c +++ b/bin/named/server.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.c,v 1.436 2005/01/12 01:56:07 marka Exp $ */ +/* $Id: server.c,v 1.437 2005/01/14 03:28:07 marka Exp $ */ #include @@ -4109,11 +4109,11 @@ ns_server_status(ns_server_t *server, isc_buffer_t *text) { } /* - * Act on a "freeze" or "unfreeze" command from the command channel. + * Act on a "freeze" or "thaw" command from the command channel. */ isc_result_t ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args) { - isc_result_t result; + isc_result_t result, tresult; dns_zone_t *zone = NULL; dns_zonetype_t type; char classstr[DNS_RDATACLASS_FORMATSIZE]; @@ -4126,8 +4126,26 @@ ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args) { result = zone_from_args(server, args, &zone); if (result != ISC_R_SUCCESS) return (result); - if (zone == NULL) - return (ISC_R_UNEXPECTEDEND); + if (zone == NULL) { + result = isc_task_beginexclusive(server->task); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + tresult = ISC_R_SUCCESS; + for (view = ISC_LIST_HEAD(server->viewlist); + view != NULL; + view = ISC_LIST_NEXT(view, link)) { + result = dns_view_freezezones(view, freeze); + if (result != ISC_R_SUCCESS && + tresult == ISC_R_SUCCESS) + tresult = result; + } + isc_task_endexclusive(server->task); + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_SERVER, ISC_LOG_INFO, + "%s all zones: %s", + freeze ? "freezing" : "thawing", + isc_result_totext(tresult)); + return (tresult); + } type = dns_zone_gettype(zone); if (type != dns_zone_master) { dns_zone_detach(&zone); @@ -4173,7 +4191,7 @@ ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args) { isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER, ISC_LOG_INFO, "%s zone '%s/%s'%s%s: %s", - freeze ? "freezing" : "unfreezing", + freeze ? "freezing" : "thawing", zonename, classstr, sep, vname, isc_result_totext(result)); dns_zone_detach(&zone); diff --git a/bin/rndc/rndc.c b/bin/rndc/rndc.c index d2f16edc56..8b0aea4732 100644 --- a/bin/rndc/rndc.c +++ b/bin/rndc/rndc.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rndc.c,v 1.100 2004/10/11 05:30:20 marka Exp $ */ +/* $Id: rndc.c,v 1.101 2005/01/14 03:28:07 marka Exp $ */ /* * Principal Author: DCL @@ -100,8 +100,10 @@ command is one of the following:\n\ Schedule immediate maintenance for a zone.\n\ retransfer zone [class [view]]\n\ Retransfer a single zone without checking serial number.\n\ + freeze Suspend updates to all dynamic zones.\n\ freeze zone [class [view]]\n\ Suspend updates to a dynamic zone.\n\ + thaw Enable updates to all dynamic zones and reload them.\n\ thaw zone [class [view]]\n\ Enable updates to a frozen dynamic zone and reload it.\n\ notify zone [class [view]]\n\ diff --git a/lib/dns/include/dns/view.h b/lib/dns/include/dns/view.h index 4570cfc70b..a6f359a66c 100644 --- a/lib/dns/include/dns/view.h +++ b/lib/dns/include/dns/view.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: view.h,v 1.92 2004/12/21 10:45:19 jinmei Exp $ */ +/* $Id: view.h,v 1.93 2005/01/14 03:28:08 marka Exp $ */ #ifndef DNS_VIEW_H #define DNS_VIEW_H 1 @@ -787,4 +787,12 @@ dns_view_getrootdelonly(dns_view_t *view); * 'view' is valid. */ +isc_result_t +dns_view_freezezones(dns_view_t *view, isc_boolean_t freeze); +/* + * Freeze/thaw updates to master zones. + * + * Requires: + * 'view' is valid. + */ #endif /* DNS_VIEW_H */ diff --git a/lib/dns/include/dns/zt.h b/lib/dns/include/dns/zt.h index cfd77a85a3..63ab5fa0c7 100644 --- a/lib/dns/include/dns/zt.h +++ b/lib/dns/include/dns/zt.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zt.h,v 1.30 2004/03/05 05:09:48 marka Exp $ */ +/* $Id: zt.h,v 1.31 2005/01/14 03:28:09 marka Exp $ */ #ifndef DNS_ZT_H #define DNS_ZT_H 1 @@ -145,9 +145,21 @@ dns_zt_loadnew(dns_zt_t *zt, isc_boolean_t stop); * 'zt' to be valid */ +isc_result_t +dns_zt_freezezones(dns_zt_t *zt, isc_boolean_t freeze); +/* + * Freeze/thaw updates to master zones. + * Any pending updates will be flushed. + * Zones will be reloaded on thaw. + */ + isc_result_t dns_zt_apply(dns_zt_t *zt, isc_boolean_t stop, isc_result_t (*action)(dns_zone_t *, void *), void *uap); + +isc_result_t +dns_zt_apply2(dns_zt_t *zt, isc_boolean_t stop, isc_result_t *sub, + isc_result_t (*action)(dns_zone_t *, void *), void *uap); /* * Apply a given 'action' to all zone zones in the table. * If 'stop' is 'ISC_TRUE' then walking the zone tree will stop if @@ -158,7 +170,9 @@ dns_zt_apply(dns_zt_t *zt, isc_boolean_t stop, * 'action' to be non NULL. * * Returns: - * ISC_R_SUCCESS if action was applied to all nodes. + * ISC_R_SUCCESS if action was applied to all nodes. If 'stop' is + * ISC_FALSE and 'sub' is non NULL then the first error (if any) + * reported by 'action' is returned in '*sub'; * any error code from 'action'. */ diff --git a/lib/dns/view.c b/lib/dns/view.c index 6a3fa54e66..61b208ced1 100644 --- a/lib/dns/view.c +++ b/lib/dns/view.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: view.c,v 1.128 2004/12/29 23:01:13 marka Exp $ */ +/* $Id: view.c,v 1.129 2005/01/14 03:28:07 marka Exp $ */ #include @@ -1348,3 +1348,9 @@ dns_view_getrootdelonly(dns_view_t *view) { REQUIRE(DNS_VIEW_VALID(view)); return (view->rootdelonly); } + +isc_result_t +dns_view_freezezones(dns_view_t *view, isc_boolean_t value) { + REQUIRE(DNS_VIEW_VALID(view)); + return (dns_zt_freezezones(view->zonetable, value)); +} diff --git a/lib/dns/zt.c b/lib/dns/zt.c index 4b942f6dbb..6fbd260d64 100644 --- a/lib/dns/zt.c +++ b/lib/dns/zt.c @@ -15,16 +15,22 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zt.c,v 1.38 2004/03/05 05:09:27 marka Exp $ */ +/* $Id: zt.c,v 1.39 2005/01/14 03:28:07 marka Exp $ */ #include +#include #include #include +#include #include +#include +#include #include +#include #include +#include #include #include @@ -51,6 +57,9 @@ load(dns_zone_t *zone, void *uap); static isc_result_t loadnew(dns_zone_t *zone, void *uap); +static isc_result_t +freezezones(dns_zone_t *zone, void *uap); + isc_result_t dns_zt_create(isc_mem_t *mctx, dns_rdataclass_t rdclass, dns_zt_t **ztp) { dns_zt_t *zt; @@ -265,13 +274,91 @@ loadnew(dns_zone_t *zone, void *uap) { return (result); } +isc_result_t +dns_zt_freezezones(dns_zt_t *zt, isc_boolean_t freeze) { + isc_result_t result, tresult; + + REQUIRE(VALID_ZT(zt)); + + RWLOCK(&zt->rwlock, isc_rwlocktype_read); + result = dns_zt_apply2(zt, ISC_FALSE, &tresult, freezezones, &freeze); + RWUNLOCK(&zt->rwlock, isc_rwlocktype_read); + return ((result == ISC_R_SUCCESS) ? tresult : result); +} + +static isc_result_t +freezezones(dns_zone_t *zone, void *uap) { + isc_boolean_t freeze = *(isc_boolean_t *)uap; + isc_boolean_t frozen; + isc_result_t result = ISC_R_SUCCESS; + char classstr[DNS_RDATACLASS_FORMATSIZE]; + char zonename[DNS_NAME_FORMATSIZE]; + dns_view_t *view; + char *journal; + const char *vname; + const char *sep; + int level; + + if (dns_zone_gettype(zone) != dns_zone_master) + return (ISC_R_SUCCESS); + + frozen = dns_zone_getupdatedisabled(zone); + if (freeze) { + if (frozen) + result = DNS_R_FROZEN; + if (result == ISC_R_SUCCESS) + result = dns_zone_flush(zone); + if (result == ISC_R_SUCCESS) { + journal = dns_zone_getjournal(zone); + if (journal != NULL) + (void)isc_file_remove(journal); + } + } else { + if (frozen) { + result = dns_zone_load(zone); + if (result == DNS_R_CONTINUE || + result == DNS_R_UPTODATE) + result = ISC_R_SUCCESS; + } + } + if (result == ISC_R_SUCCESS) + dns_zone_setupdatedisabled(zone, freeze); + view = dns_zone_getview(zone); + if (strcmp(view->name, "_bind") == 0 || + strcmp(view->name, "_default") == 0) + { + vname = ""; + sep = ""; + } else { + vname = view->name; + sep = " "; + } + dns_rdataclass_format(dns_zone_getclass(zone), classstr, + sizeof(classstr)); + dns_name_format(dns_zone_getorigin(zone), zonename, sizeof(zonename)); + level = (result != ISC_R_SUCCESS) ? ISC_LOG_ERROR : ISC_LOG_DEBUG(1); + isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL, DNS_LOGMODULE_ZONE, + level, "%s zone '%s/%s'%s%s: %s", + freeze ? "freezing" : "thawing", + zonename, classstr, sep, vname, + isc_result_totext(result)); + return (result); +} + isc_result_t dns_zt_apply(dns_zt_t *zt, isc_boolean_t stop, isc_result_t (*action)(dns_zone_t *, void *), void *uap) +{ + return (dns_zt_apply2(zt, stop, NULL, action, uap)); +} + +isc_result_t +dns_zt_apply2(dns_zt_t *zt, isc_boolean_t stop, isc_result_t *sub, + isc_result_t (*action)(dns_zone_t *, void *), void *uap) { dns_rbtnode_t *node; dns_rbtnodechain_t chain; - isc_result_t result; + isc_result_t result, tresult = ISC_R_SUCCESS; dns_zone_t *zone; REQUIRE(VALID_ZT(zt)); @@ -292,8 +379,13 @@ dns_zt_apply(dns_zt_t *zt, isc_boolean_t stop, zone = node->data; if (zone != NULL) result = (action)(zone, uap); - if (result != ISC_R_SUCCESS && stop) + if (result != ISC_R_SUCCESS && stop) { + tresult = result; goto cleanup; /* don't break */ + } else if (result != ISC_R_SUCCESS && + tresult != ISC_R_SUCCESS) + tresult = result; + } result = dns_rbtnodechain_next(&chain, NULL, NULL); } @@ -302,6 +394,8 @@ dns_zt_apply(dns_zt_t *zt, isc_boolean_t stop, cleanup: dns_rbtnodechain_invalidate(&chain); + if (sub != NULL) + *sub = tresult; return (result); } From 5752b9e296f14034f103149f18188770c2cc5239 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 14 Jan 2005 23:34:20 +0000 Subject: [PATCH 043/130] newcopyrights --- util/copyrights | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/util/copyrights b/util/copyrights index 8ec7b87807..5e0a277f30 100644 --- a/util/copyrights +++ b/util/copyrights @@ -136,9 +136,9 @@ ./bin/named/lwsearch.c C 2000,2001,2004 ./bin/named/main.c C 1999,2000,2001,2002,2003,2004 ./bin/named/named.8 MAN 2000,2001,2003,2004 -./bin/named/named.conf.5 MAN 2004 +./bin/named/named.conf.5 MAN 2004,2005 ./bin/named/named.conf.docbook SGML 2004,2005 -./bin/named/named.conf.html HTML 2004 +./bin/named/named.conf.html HTML 2004,2005 ./bin/named/named.docbook SGML 2000,2001,2003,2004 ./bin/named/named.html HTML 2000,2001,2003,2004 ./bin/named/notify.c C 1999,2000,2001,2002,2003,2004 @@ -178,7 +178,7 @@ ./bin/rndc/rndc-confgen.docbook SGML 2001,2003,2004 ./bin/rndc/rndc-confgen.html HTML 2001,2002,2003,2004 ./bin/rndc/rndc.8 MAN 2000,2001,2004 -./bin/rndc/rndc.c C 2000,2001,2002,2003,2004 +./bin/rndc/rndc.c C 2000,2001,2002,2003,2004,2005 ./bin/rndc/rndc.conf CONF-C 2000,2001,2004 ./bin/rndc/rndc.conf.5 MAN 2000,2001,2004 ./bin/rndc/rndc.conf.docbook SGML 2001,2004 @@ -1697,11 +1697,11 @@ ./lib/dns/include/dns/types.h C 1998,1999,2000,2001,2002,2003,2004 ./lib/dns/include/dns/validator.h C 2000,2001,2002,2003,2004 ./lib/dns/include/dns/version.h C 2001,2004 -./lib/dns/include/dns/view.h C 1999,2000,2001,2002,2003,2004 +./lib/dns/include/dns/view.h C 1999,2000,2001,2002,2003,2004,2005 ./lib/dns/include/dns/xfrin.h C 1999,2000,2001,2003,2004 ./lib/dns/include/dns/zone.h C 1999,2000,2001,2002,2003,2004,2005 ./lib/dns/include/dns/zonekey.h C 2001,2004 -./lib/dns/include/dns/zt.h C 1999,2000,2001,2002,2004 +./lib/dns/include/dns/zt.h C 1999,2000,2001,2002,2004,2005 ./lib/dns/include/dst/.cvsignore X 2000,2001 ./lib/dns/include/dst/Makefile.in MAKE 1998,1999,2000,2001,2004 ./lib/dns/include/dst/dst.h C 2000,2001,2002,2004 @@ -1855,7 +1855,7 @@ ./lib/dns/ttl.c C 1999,2000,2001,2004 ./lib/dns/validator.c C 2000,2001,2002,2003,2004 ./lib/dns/version.c C 1998,1999,2000,2001,2004 -./lib/dns/view.c C 1999,2000,2001,2002,2003,2004 +./lib/dns/view.c C 1999,2000,2001,2002,2003,2004,2005 ./lib/dns/win32/DLLMain.c C 2001,2004 ./lib/dns/win32/gen.dsp X 2001 ./lib/dns/win32/gen.dsw X 2001 @@ -1868,7 +1868,7 @@ ./lib/dns/xfrin.c C 1999,2000,2001,2002,2003,2004 ./lib/dns/zone.c C 1999,2000,2001,2002,2003,2004,2005 ./lib/dns/zonekey.c C 2001,2003,2004 -./lib/dns/zt.c C 1999,2000,2001,2002,2004 +./lib/dns/zt.c C 1999,2000,2001,2002,2004,2005 ./lib/isc/.cvsignore X 1999,2000,2001 ./lib/isc/Makefile.in MAKE 1998,1999,2000,2001,2002,2003,2004 ./lib/isc/api X 1999,2000,2001 From 4844ed026a9b5a91044e76399cee80a6514cbf0d Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 17 Jan 2005 00:46:05 +0000 Subject: [PATCH 044/130] 1798. [func] The server syntax has been extended to support a range of servers. [RT #11132] --- CHANGES | 3 ++- bin/named/named.conf.docbook | 6 ++--- bin/named/server.c | 9 +++---- doc/arm/Bv9ARM-book.xml | 9 ++++--- lib/bind9/check.c | 41 ++++++++++++++++++---------- lib/dns/include/dns/peer.h | 7 ++++- lib/dns/peer.c | 42 ++++++++++++++++++++++++++--- lib/isc/include/isc/netaddr.h | 15 ++++++++++- lib/isc/netaddr.c | 38 +++++++++++++++++++++++++- lib/isccfg/include/isccfg/grammar.h | 6 ++++- lib/isccfg/namedconf.c | 4 +-- lib/isccfg/parser.c | 16 +++++++++-- 12 files changed, 159 insertions(+), 37 deletions(-) diff --git a/CHANGES b/CHANGES index e419b2afc0..17ec86e495 100644 --- a/CHANGES +++ b/CHANGES @@ -1,4 +1,5 @@ -1798. [placeholder] rt11132 +1798. [func] The server syntax has been extended to support a + range of servers. [RT #11132] 1797. [func] named-checkconf now check acls to verify that they only refer to existing acls. [RT #13101] diff --git a/bin/named/named.conf.docbook b/bin/named/named.conf.docbook index 58dd5889a1..f054724700 100644 --- a/bin/named/named.conf.docbook +++ b/bin/named/named.conf.docbook @@ -15,7 +15,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> - + @@ -90,7 +90,7 @@ masters string port integer SERVER -server ( ipv4_address | ipv6_address ) { +server ( ipv4_address/prefixlen | ipv6_address/prefixlen ) { bogus boolean; edns boolean; provide-ixfr boolean; @@ -327,7 +327,7 @@ view string optional_class ... }; - server ( ipv4_address | ipv6_address ) { + server ( ipv4_address/prefixlen | ipv6_address/prefixlen ) { ... }; diff --git a/bin/named/server.c b/bin/named/server.c index b2a6e4ad6b..62394c121b 100644 --- a/bin/named/server.c +++ b/bin/named/server.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.c,v 1.437 2005/01/14 03:28:07 marka Exp $ */ +/* $Id: server.c,v 1.438 2005/01/17 00:46:01 marka Exp $ */ #include @@ -580,15 +580,14 @@ configure_order(dns_order_t *order, cfg_obj_t *ent) { static isc_result_t configure_peer(cfg_obj_t *cpeer, isc_mem_t *mctx, dns_peer_t **peerp) { - isc_sockaddr_t *sa; isc_netaddr_t na; dns_peer_t *peer; cfg_obj_t *obj; char *str; isc_result_t result; + unsigned int prefixlen; - sa = cfg_obj_assockaddr(cfg_map_getname(cpeer)); - isc_netaddr_fromsockaddr(&na, sa); + cfg_obj_asnetprefix(cfg_map_getname(cpeer), &na, &prefixlen); peer = NULL; result = dns_peer_new(mctx, &na, &peer); @@ -643,7 +642,7 @@ configure_peer(cfg_obj_t *cpeer, isc_mem_t *mctx, dns_peer_t **peerp) { } obj = NULL; - if (isc_sockaddr_pf(sa) == AF_INET) + if (na.family == AF_INET) (void)cfg_map_get(cpeer, "transfer-source", &obj); else (void)cfg_map_get(cpeer, "transfer-source-v6", &obj); diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 45194af34c..c582510517 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -2,7 +2,7 @@ - + BIND 9 Administrator Reference Manual @@ -4463,7 +4463,7 @@ entries are purged from acache only at the periodic cleaning time. <command>server</command> Statement Grammar -server ip_addr { +server ip_addr/prefixlen { bogus yes_or_no ; provide-ixfr yes_or_no ; request-ixfr yes_or_no ; @@ -4482,7 +4482,10 @@ entries are purged from acache only at the periodic cleaning time. <command>server</command> Statement Definition and Usage The server statement defines characteristics -to be associated with a remote name server. +to be associated with a remote name server. If a prefix length is +specified then a range of servers is covered. Only the most specific +server clause applies regardless of the order in +named.conf. The server statement can occur at the top level of the diff --git a/lib/bind9/check.c b/lib/bind9/check.c index aa2af9021e..5f45ea4de4 100644 --- a/lib/bind9/check.c +++ b/lib/bind9/check.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: check.c,v 1.54 2005/01/11 03:46:10 marka Exp $ */ +/* $Id: check.c,v 1.55 2005/01/17 00:46:02 marka Exp $ */ #include @@ -1101,8 +1101,8 @@ check_servers(cfg_obj_t *servers, isc_log_t *logctx) { isc_result_t result = ISC_R_SUCCESS; cfg_listelt_t *e1, *e2; cfg_obj_t *v1, *v2; - isc_sockaddr_t *s1, *s2; - isc_netaddr_t na; + isc_netaddr_t n1, n2; + unsigned int p1, p2; cfg_obj_t *ts; char buf[128]; const char *xfr; @@ -1110,44 +1110,57 @@ check_servers(cfg_obj_t *servers, isc_log_t *logctx) { for (e1 = cfg_list_first(servers); e1 != NULL; e1 = cfg_list_next(e1)) { v1 = cfg_listelt_value(e1); - s1 = cfg_obj_assockaddr(cfg_map_getname(v1)); + cfg_obj_asnetprefix(cfg_map_getname(v1), &n1, &p1); + /* + * Check that unused bits are zero. + */ + result = isc_netaddr_prefixok(&n1, p1); + if (result != ISC_R_SUCCESS) { + INSIST(result == ISC_R_FAILURE); + isc_buffer_init(&target, buf, sizeof(buf) - 1); + RUNTIME_CHECK(isc_netaddr_totext(&n1, &target) + == ISC_R_SUCCESS); + buf[isc_buffer_usedlength(&target)] = '\0'; + cfg_obj_log(v1, logctx, ISC_LOG_ERROR, + "server '%s/%u': invalid prefix " + "(extra bits specified)", buf, p1); + } ts = NULL; - if (isc_sockaddr_pf(s1) == AF_INET) + if (n1.family == AF_INET) xfr = "transfer-source-v6"; else xfr = "transfer-source"; (void)cfg_map_get(v1, xfr, &ts); if (ts != NULL) { - isc_netaddr_fromsockaddr(&na, s1); isc_buffer_init(&target, buf, sizeof(buf) - 1); - RUNTIME_CHECK(isc_netaddr_totext(&na, &target) + RUNTIME_CHECK(isc_netaddr_totext(&n1, &target) == ISC_R_SUCCESS); buf[isc_buffer_usedlength(&target)] = '\0'; cfg_obj_log(v1, logctx, ISC_LOG_ERROR, - "server '%s': %s not valid", buf, xfr); + "server '%s/%u': %s not valid", + buf, p1, xfr); result = ISC_R_FAILURE; } e2 = e1; while ((e2 = cfg_list_next(e2)) != NULL) { v2 = cfg_listelt_value(e2); - s2 = cfg_obj_assockaddr(cfg_map_getname(v2)); - if (isc_sockaddr_eqaddr(s1, s2)) { + cfg_obj_asnetprefix(cfg_map_getname(v2), &n2, &p2); + if (p1 == p2 && isc_netaddr_equal(&n1, &n2)) { const char *file = cfg_obj_file(v1); unsigned int line = cfg_obj_line(v1); if (file == NULL) file = ""; - isc_netaddr_fromsockaddr(&na, s2); isc_buffer_init(&target, buf, sizeof(buf) - 1); - RUNTIME_CHECK(isc_netaddr_totext(&na, &target) + RUNTIME_CHECK(isc_netaddr_totext(&n2, &target) == ISC_R_SUCCESS); buf[isc_buffer_usedlength(&target)] = '\0'; cfg_obj_log(v2, logctx, ISC_LOG_ERROR, - "server '%s': already exists " + "server '%s/%u': already exists " "previous definition: %s:%u", - buf, file, line); + buf, p2, file, line); result = ISC_R_FAILURE; } } diff --git a/lib/dns/include/dns/peer.h b/lib/dns/include/dns/peer.h index 78be7a99d2..5dffcc4b30 100644 --- a/lib/dns/include/dns/peer.h +++ b/lib/dns/include/dns/peer.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: peer.h,v 1.20 2004/03/05 05:09:45 marka Exp $ */ +/* $Id: peer.h,v 1.21 2005/01/17 00:46:03 marka Exp $ */ #ifndef DNS_PEER_H #define DNS_PEER_H 1 @@ -64,6 +64,7 @@ struct dns_peer { isc_mem_t *mem; isc_netaddr_t address; + unsigned int prefixlen; isc_boolean_t bogus; dns_transfer_format_t transfer_format; isc_uint32_t transfers; @@ -115,6 +116,10 @@ dns_peerlist_currpeer(dns_peerlist_t *peers, dns_peer_t **retval); isc_result_t dns_peer_new(isc_mem_t *mem, isc_netaddr_t *ipaddr, dns_peer_t **peer); +isc_result_t +dns_peer_newprefix(isc_mem_t *mem, isc_netaddr_t *ipaddr, + unsigned int prefixlen, dns_peer_t **peer); + void dns_peer_attach(dns_peer_t *source, dns_peer_t **target); diff --git a/lib/dns/peer.c b/lib/dns/peer.c index 39fdf2b3d2..a1204c6091 100644 --- a/lib/dns/peer.c +++ b/lib/dns/peer.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: peer.c,v 1.19 2004/03/05 05:09:22 marka Exp $ */ +/* $Id: peer.c,v 1.20 2005/01/17 00:46:03 marka Exp $ */ #include @@ -130,7 +130,20 @@ dns_peerlist_addpeer(dns_peerlist_t *peers, dns_peer_t *peer) { dns_peer_attach(peer, &p); - ISC_LIST_APPEND(peers->elements, peer, next); + /* + * More specifics to front of list. + */ + for (p = ISC_LIST_HEAD(peers->elements); + p != NULL; + p = ISC_LIST_NEXT(p, next)) + if (p->prefixlen < peer->prefixlen) + break; + + if (p != NULL) + ISC_LIST_INSERTBEFORE(peers->elements, p, peer, next); + else + ISC_LIST_APPEND(peers->elements, peer, next); + } isc_result_t @@ -145,7 +158,8 @@ dns_peerlist_peerbyaddr(dns_peerlist_t *servers, server = ISC_LIST_HEAD(servers->elements); while (server != NULL) { - if (isc_netaddr_equal(addr, &server->address)) + if (isc_netaddr_eqprefix(addr, &server->address, + server->prefixlen)) break; server = ISC_LIST_NEXT(server, next); @@ -176,6 +190,27 @@ dns_peerlist_currpeer(dns_peerlist_t *peers, dns_peer_t **retval) { isc_result_t dns_peer_new(isc_mem_t *mem, isc_netaddr_t *addr, dns_peer_t **peerptr) { + unsigned int prefixlen = 0; + + REQUIRE(peerptr != NULL); + switch(addr->family) { + case AF_INET: + prefixlen = 32; + break; + case AF_INET6: + prefixlen = 128; + break; + default: + INSIST(0); + } + + return (dns_peer_newprefix(mem, addr, prefixlen, peerptr)); +} + +isc_result_t +dns_peer_newprefix(isc_mem_t *mem, isc_netaddr_t *addr, unsigned int prefixlen, + dns_peer_t **peerptr) +{ dns_peer_t *peer; REQUIRE(peerptr != NULL); @@ -186,6 +221,7 @@ dns_peer_new(isc_mem_t *mem, isc_netaddr_t *addr, dns_peer_t **peerptr) { peer->magic = DNS_PEER_MAGIC; peer->address = *addr; + peer->prefixlen = prefixlen; peer->mem = mem; peer->bogus = ISC_FALSE; peer->transfer_format = dns_one_answer; diff --git a/lib/isc/include/isc/netaddr.h b/lib/isc/include/isc/netaddr.h index 5c399bb02d..b92335505f 100644 --- a/lib/isc/include/isc/netaddr.h +++ b/lib/isc/include/isc/netaddr.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: netaddr.h,v 1.25 2004/03/05 05:10:59 marka Exp $ */ +/* $Id: netaddr.h,v 1.26 2005/01/17 00:46:04 marka Exp $ */ #ifndef ISC_NETADDR_H #define ISC_NETADDR_H 1 @@ -143,6 +143,19 @@ isc_netaddr_fromv4mapped(isc_netaddr_t *t, const isc_netaddr_t *s); * Convert an IPv6 v4mapped address into an IPv4 address. */ +isc_result_t +isc_netaddr_prefixok(const isc_netaddr_t *na, unsigned int prefixlen); +/* + * Test whether the netaddr 'na' and 'prefixlen' are consistant. + * e.g. prefixlen within range. + * na does not have bits set which are not covered by the prefixlen. + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_RANGE prefixlen out of range + * ISC_R_NOTIMPLENTED unsupported family + * ISC_R_FAILURE extra bits. + */ ISC_LANG_ENDDECLS diff --git a/lib/isc/netaddr.c b/lib/isc/netaddr.c index 74cd159535..40fece183d 100644 --- a/lib/isc/netaddr.c +++ b/lib/isc/netaddr.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: netaddr.c,v 1.28 2004/05/15 03:37:33 jinmei Exp $ */ +/* $Id: netaddr.c,v 1.29 2005/01/17 00:46:04 marka Exp $ */ #include @@ -190,6 +190,42 @@ isc_netaddr_format(const isc_netaddr_t *na, char *array, unsigned int size) { } } + +isc_result_t +isc_netaddr_prefixok(const isc_netaddr_t *na, unsigned int prefixlen) { + static const unsigned char zeros[16]; + unsigned int nbits, nbytes, ipbytes, i; + const unsigned char *p; + + switch (na->family) { + case AF_INET: + p = (const unsigned char *) &na->type.in; + ipbytes = 4; + if (prefixlen > 32) + return (ISC_R_RANGE); + break; + case AF_INET6: + p = (const unsigned char *) &na->type.in6; + ipbytes = 16; + if (prefixlen > 128) + return (ISC_R_RANGE); + break; + default: + ipbytes = 0; + return (ISC_R_NOTIMPLEMENTED); + } + nbytes = prefixlen / 8; + nbits = prefixlen % 8; + if (nbits != 0) { + if ((p[nbytes] & (0xff>>nbits)) != 0U) + return (ISC_R_FAILURE); + nbytes++; + } + if (memcmp(p + nbytes, zeros, ipbytes - nbytes) != 0) + return (ISC_R_FAILURE); + return (ISC_R_SUCCESS); +} + isc_result_t isc_netaddr_masktoprefixlen(const isc_netaddr_t *s, unsigned int *lenp) { unsigned int nbits, nbytes, ipbytes, i; diff --git a/lib/isccfg/include/isccfg/grammar.h b/lib/isccfg/include/isccfg/grammar.h index 230f346ac8..32bf863f40 100644 --- a/lib/isccfg/include/isccfg/grammar.h +++ b/lib/isccfg/include/isccfg/grammar.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: grammar.h,v 1.6 2004/11/30 01:08:52 marka Exp $ */ +/* $Id: grammar.h,v 1.7 2005/01/17 00:46:05 marka Exp $ */ #ifndef ISCCFG_GRAMMAR_H #define ISCCFG_GRAMMAR_H 1 @@ -377,6 +377,10 @@ cfg_parse_named_map(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret) isc_result_t cfg_parse_addressed_map(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret); +isc_result_t +cfg_parse_netprefix_map(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t ** +ret); + void cfg_print_map(cfg_printer_t *pctx, cfg_obj_t *obj); diff --git a/lib/isccfg/namedconf.c b/lib/isccfg/namedconf.c index 4d7b88c82f..52e86a2851 100644 --- a/lib/isccfg/namedconf.c +++ b/lib/isccfg/namedconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: namedconf.c,v 1.45 2005/01/11 23:10:06 marka Exp $ */ +/* $Id: namedconf.c,v 1.46 2005/01/17 00:46:04 marka Exp $ */ #include @@ -912,7 +912,7 @@ server_clausesets[] = { NULL }; static cfg_type_t cfg_type_server = { - "server", cfg_parse_addressed_map, cfg_print_map, cfg_doc_map, &cfg_rep_map, + "server", cfg_parse_netprefix_map, cfg_print_map, cfg_doc_map, &cfg_rep_map, server_clausesets }; diff --git a/lib/isccfg/parser.c b/lib/isccfg/parser.c index 3fbda9bff4..4d22ace0a9 100644 --- a/lib/isccfg/parser.c +++ b/lib/isccfg/parser.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: parser.c,v 1.114 2004/07/23 04:15:26 marka Exp $ */ +/* $Id: parser.c,v 1.115 2005/01/17 00:46:04 marka Exp $ */ #include @@ -1358,13 +1358,22 @@ cfg_parse_named_map(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret) /* * Parse a map identified by a network address. - * Used for the "server" statement. + * Used to be used for the "server" statement. */ isc_result_t cfg_parse_addressed_map(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret) { return (parse_any_named_map(pctx, &cfg_type_netaddr, type, ret)); } +/* + * Parse a map identified by a network prefix. + * Used for the "server" statement. + */ +isc_result_t +cfg_parse_netprefix_map(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret) { + return (parse_any_named_map(pctx, &cfg_type_netprefix, type, ret)); +} + void cfg_print_mapbody(cfg_printer_t *pctx, cfg_obj_t *obj) { isc_result_t result = ISC_R_SUCCESS; @@ -1483,6 +1492,9 @@ cfg_doc_map(cfg_printer_t *pctx, const cfg_type_t *type) { } else if (type->parse == cfg_parse_addressed_map) { cfg_doc_obj(pctx, &cfg_type_netaddr); cfg_print_chars(pctx, " ", 1); + } else if (type->parse == cfg_parse_netprefix_map) { + cfg_doc_obj(pctx, &cfg_type_netprefix); + cfg_print_chars(pctx, " ", 1); } print_open(pctx); From e0172ab8e2bf2fd2315f5c9b34cae8e013c71dda Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 17 Jan 2005 01:55:06 +0000 Subject: [PATCH 045/130] regen --- bin/named/named.conf.5 | 8 +-- bin/named/named.conf.html | 42 +++++++++------ doc/arm/Bv9ARM.ch06.html | 71 ++++++++++++++----------- doc/arm/Bv9ARM.ch07.html | 8 +-- doc/arm/Bv9ARM.ch08.html | 14 ++--- doc/arm/Bv9ARM.ch09.html | 108 +++++++++++++++++++------------------- doc/arm/Bv9ARM.html | 38 +++++++------- doc/misc/options | 4 +- 8 files changed, 157 insertions(+), 136 deletions(-) diff --git a/bin/named/named.conf.5 b/bin/named/named.conf.5 index 515886dea0..a4762ac817 100644 --- a/bin/named/named.conf.5 +++ b/bin/named/named.conf.5 @@ -1,4 +1,4 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2004, 2005 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 @@ -12,7 +12,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: named.conf.5,v 1.7 2005/01/13 04:52:20 marka Exp $ +.\" $Id: named.conf.5,v 1.8 2005/01/17 01:55:05 marka Exp $ .\" .TH "NAMED.CONF" "5" "Aug 13, 2004" "BIND9" "" .SH NAME @@ -60,7 +60,7 @@ masters \fIstring\fR [ port \fIinteger\fR ] { .SH "SERVER" .sp .nf -server ( \fIipv4_address\fR | \fIipv6_address\fR ) { +server ( \fIipv4_address[/prefixlen]\fR | \fIipv6_address[/prefixlen]\fR ) { bogus \fIboolean\fR; edns \fIboolean\fR; provide-ixfr \fIboolean\fR; @@ -291,7 +291,7 @@ view \fIstring\fR \fIoptional_class\fR { ... }; - server ( \fIipv4_address\fR | \fIipv6_address\fR ) { + server ( \fIipv4_address[/prefixlen]\fR | \fIipv6_address[/prefixlen]\fR ) { ... }; diff --git a/bin/named/named.conf.html b/bin/named/named.conf.html index ca85d57b26..380e3b014c 100644 --- a/bin/named/named.conf.html +++ b/bin/named/named.conf.html @@ -1,5 +1,5 @@ - + server ( ipv4_addressipv4_address[/prefixlen] | ipv6_addressipv6_address[/prefixlen] ) {
    bogus 

    TRUSTED-KEYS

    CONTROLS

    LOGGING

    LWRES

    OPTIONS

    VIEW

    server ( ipv4_addressipv4_address[/prefixlen] | ipv6_addressipv6_address[/prefixlen] ) {
    ...
    };
    @@ -1558,7 +1570,7 @@ CLASS="REPLACEABLE" >

    ZONE

    FILES

    SEE ALSO

    • 6.3. Zone File
    server ip_addrip_addr[/prefixlen] { [server statement defines characteristics -to be associated with a remote name server.

    named.conf.

    The

    6.2.19. trusted-keys

    6.2.20. trusted-keys

    6.2.22. view

    6.2.24. zone

    6.2.24.1. Zone Types

    6.2.24.2. Class

    6.2.24.3. Zone Options

    6.3. Zone File

    6.3.1.1. Resource Records

    6.3.1.2. Textual expression of RRs

    6.3.2. Discussion of MX Records

    6.3.4. Inverse Mapping in IPv4

    6.3.5. Other Zone File Directives

    6.3.5.1. The $ORIGIN

    6.3.5.2. The $INCLUDE

    6.3.5.3. The $TTL

    6.3.6. BIND

    7.2. chroot

    7.2. chroot

    7.2.1. The chroot

    7.2.2. Using the setuid

    8.1. Common Problems
    8.2. Incrementing and Changing the Serial Number
    8.3. Where Can I Get Help?

    8.1. Common Problems

    8.1.1. It's not working; how can I figure out what's wrong?

    8.2. Incrementing and Changing the Serial Number

    8.3. Where Can I Get Help?

    A.1. Acknowledgments

    A.1. Acknowledgments

    A.1.1. A Brief History of the DNS

    Bibliography

    Standards

    [RFC974] 

    [RFC1034] 

    [RFC1035] 

    [RFC2181] 

    [RFC2308] 

    [RFC1995] 

    [RFC1996] 

    [RFC2136] 

    [RFC2845] 

    Proposed Standards Still Under Development

    [RFC1886] 

    [RFC2065] 

    [RFC2137] 

    Other Important RFCs About DNS

    [RFC1535] 

    [RFC1536] 

    [RFC1982] 

    Resource Record Types

    [RFC1183] 

    [RFC1706] 

    [RFC2168] 

    [RFC1876] 

    [RFC2052] 

    [RFC2163] 

    [RFC2230] 

    DNS

    [RFC1101] 

    [RFC1123] 

    [RFC1591] 

    [RFC2317] 

    DNS

    [RFC1537] 

    [RFC1912] 

    [RFC2010] 

    [RFC2219] 

    Other DNS

    [RFC1464] 

    [RFC1713] 

    [RFC1794] 

    [RFC2240] 

    [RFC2345] 

    [RFC2352] 

    Obsolete and Unimplemented Experimental RRs

    [RFC1712] 

    A.3.3. Other Documents About BIND

    Bibliography

    6.2.19. trusted-keys
    6.2.20. trusted-keys
    6.2.22. view
    6.2.24. zone
    6.3. Zone File
    6.3.2. Discussion of MX Records
    6.3.4. Inverse Mapping in IPv4
    6.3.5. Other Zone File Directives
    6.3.6. BIND
    7.2. chroot
    7.2.1. The chroot
    7.2.2. Using the setuid
    8.1. Common Problems
    8.1.1. It's not working; how can I figure out what's wrong?
    8.2. Incrementing and Changing the Serial Number
    8.3. Where Can I Get Help?
    A.1. Acknowledgments
    A.1.1. A Brief History of the DNS
    A.3.3. Other Documents About BIND { key-directory ; check-wildcard ; }; - server ( | ) { + server { bogus ; provide-ixfr ; request-ixfr ; @@ -388,7 +388,7 @@ zone { check-wildcard ; }; -server ( | ) { +server { bogus ; provide-ixfr ; request-ixfr ; From e89e09eda84cc704e307dbf3ae6fc99a1bf5ec79 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 17 Jan 2005 04:11:34 +0000 Subject: [PATCH 046/130] update copyrights --- bin/rndc/rndc.c | 4 ++-- lib/dns/include/dns/view.h | 4 ++-- lib/dns/include/dns/zt.h | 4 ++-- lib/dns/view.c | 4 ++-- lib/dns/zt.c | 4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/bin/rndc/rndc.c b/bin/rndc/rndc.c index 8b0aea4732..b064a35b1d 100644 --- a/bin/rndc/rndc.c +++ b/bin/rndc/rndc.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rndc.c,v 1.101 2005/01/14 03:28:07 marka Exp $ */ +/* $Id: rndc.c,v 1.102 2005/01/17 04:11:33 marka Exp $ */ /* * Principal Author: DCL diff --git a/lib/dns/include/dns/view.h b/lib/dns/include/dns/view.h index a6f359a66c..79846796fe 100644 --- a/lib/dns/include/dns/view.h +++ b/lib/dns/include/dns/view.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: view.h,v 1.93 2005/01/14 03:28:08 marka Exp $ */ +/* $Id: view.h,v 1.94 2005/01/17 04:11:33 marka Exp $ */ #ifndef DNS_VIEW_H #define DNS_VIEW_H 1 diff --git a/lib/dns/include/dns/zt.h b/lib/dns/include/dns/zt.h index 63ab5fa0c7..f405d296e5 100644 --- a/lib/dns/include/dns/zt.h +++ b/lib/dns/include/dns/zt.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zt.h,v 1.31 2005/01/14 03:28:09 marka Exp $ */ +/* $Id: zt.h,v 1.32 2005/01/17 04:11:34 marka Exp $ */ #ifndef DNS_ZT_H #define DNS_ZT_H 1 diff --git a/lib/dns/view.c b/lib/dns/view.c index 61b208ced1..43c3fab225 100644 --- a/lib/dns/view.c +++ b/lib/dns/view.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: view.c,v 1.129 2005/01/14 03:28:07 marka Exp $ */ +/* $Id: view.c,v 1.130 2005/01/17 04:11:33 marka Exp $ */ #include diff --git a/lib/dns/zt.c b/lib/dns/zt.c index 6fbd260d64..faf6513b45 100644 --- a/lib/dns/zt.c +++ b/lib/dns/zt.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zt.c,v 1.39 2005/01/14 03:28:07 marka Exp $ */ +/* $Id: zt.c,v 1.40 2005/01/17 04:11:33 marka Exp $ */ #include From 7087b3dc9298e85909df7a10f83bbd0588310f0c Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 17 Jan 2005 04:50:00 +0000 Subject: [PATCH 047/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 17ec86e495..0490110651 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1799. [placeholder] rt13438 + 1798. [func] The server syntax has been extended to support a range of servers. [RT #11132] From 67afb42794e0efcbb1c96108037733127544787c Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 17 Jan 2005 23:34:58 +0000 Subject: [PATCH 048/130] newcopyrights --- util/copyrights | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/util/copyrights b/util/copyrights index 5e0a277f30..63bba8d496 100644 --- a/util/copyrights +++ b/util/copyrights @@ -1667,7 +1667,7 @@ ./lib/dns/include/dns/nsec.h C 1999,2000,2001,2003,2004 ./lib/dns/include/dns/opcode.h C 2002,2004 ./lib/dns/include/dns/order.h C 2002,2004 -./lib/dns/include/dns/peer.h C 2000,2001,2003,2004 +./lib/dns/include/dns/peer.h C 2000,2001,2003,2004,2005 ./lib/dns/include/dns/portlist.h C 2003,2004 ./lib/dns/include/dns/rbt.h C 1999,2000,2001,2002,2004 ./lib/dns/include/dns/rcode.h C 1999,2000,2001,2004 @@ -1725,7 +1725,7 @@ ./lib/dns/openssldsa_link.c C.NAI 1999,2000,2001,2002,2004 ./lib/dns/opensslrsa_link.c C 2000,2001,2002,2003,2004 ./lib/dns/order.c C 2002,2004 -./lib/dns/peer.c C 2000,2001,2003,2004 +./lib/dns/peer.c C 2000,2001,2003,2004,2005 ./lib/dns/portlist.c C 2003,2004 ./lib/dns/rbt.c C 1999,2000,2001,2002,2003,2004 ./lib/dns/rbtdb.c C 1999,2000,2001,2002,2003,2004 @@ -1923,7 +1923,7 @@ ./lib/isc/include/isc/msgcat.h C 1999,2000,2001,2004 ./lib/isc/include/isc/msgs.h C 2000,2001,2002,2003,2004 ./lib/isc/include/isc/mutexblock.h C 1999,2000,2001,2004 -./lib/isc/include/isc/netaddr.h C 1998,1999,2000,2001,2002,2004 +./lib/isc/include/isc/netaddr.h C 1998,1999,2000,2001,2002,2004,2005 ./lib/isc/include/isc/netscope.h C 2002,2004 ./lib/isc/include/isc/ondestroy.h C 2000,2001,2004 ./lib/isc/include/isc/os.h C 2000,2001,2004 @@ -1963,7 +1963,7 @@ ./lib/isc/md5.c C 2000,2001,2004 ./lib/isc/mem.c C 1997,1998,1999,2000,2001,2002,2003,2004 ./lib/isc/mutexblock.c C 1999,2000,2001,2004 -./lib/isc/netaddr.c C 1999,2000,2001,2002,2004 +./lib/isc/netaddr.c C 1999,2000,2001,2002,2004,2005 ./lib/isc/netscope.c C 2002,2004 ./lib/isc/nls/.cvsignore X 1999,2000,2001 ./lib/isc/nls/Makefile.in MAKE 1999,2000,2001,2004 @@ -2162,13 +2162,13 @@ ./lib/isccfg/include/isccfg/Makefile.in MAKE 2001,2002,2004,2005 ./lib/isccfg/include/isccfg/aclconf.h C 1999,2000,2001,2004,2005 ./lib/isccfg/include/isccfg/cfg.h C 2000,2001,2002,2004 -./lib/isccfg/include/isccfg/grammar.h C 2002,2003,2004 +./lib/isccfg/include/isccfg/grammar.h C 2002,2003,2004,2005 ./lib/isccfg/include/isccfg/log.h C 2001,2004 ./lib/isccfg/include/isccfg/namedconf.h C 2002,2004 ./lib/isccfg/include/isccfg/version.h C 2001,2004 ./lib/isccfg/log.c C 2001,2004 ./lib/isccfg/namedconf.c C 2002,2003,2004,2005 -./lib/isccfg/parser.c C 2000,2001,2002,2003,2004 +./lib/isccfg/parser.c C 2000,2001,2002,2003,2004,2005 ./lib/isccfg/version.c C 1998,1999,2000,2001,2004 ./lib/isccfg/win32/DLLMain.c C 2001,2004 ./lib/isccfg/win32/libisccfg.def X 2001 From ebf264ea105fc78b8316a1166bae0624d488d83b Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 17 Jan 2005 23:58:33 +0000 Subject: [PATCH 049/130] update copyright --- lib/dns/include/dns/peer.h | 4 ++-- lib/dns/peer.c | 4 ++-- lib/isc/include/isc/netaddr.h | 4 ++-- lib/isc/netaddr.c | 4 ++-- lib/isccfg/include/isccfg/grammar.h | 4 ++-- lib/isccfg/parser.c | 4 ++-- 6 files changed, 12 insertions(+), 12 deletions(-) diff --git a/lib/dns/include/dns/peer.h b/lib/dns/include/dns/peer.h index 5dffcc4b30..31501f5fdd 100644 --- a/lib/dns/include/dns/peer.h +++ b/lib/dns/include/dns/peer.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000, 2001, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: peer.h,v 1.21 2005/01/17 00:46:03 marka Exp $ */ +/* $Id: peer.h,v 1.22 2005/01/17 23:58:32 marka Exp $ */ #ifndef DNS_PEER_H #define DNS_PEER_H 1 diff --git a/lib/dns/peer.c b/lib/dns/peer.c index a1204c6091..0badd73738 100644 --- a/lib/dns/peer.c +++ b/lib/dns/peer.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000, 2001, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: peer.c,v 1.20 2005/01/17 00:46:03 marka Exp $ */ +/* $Id: peer.c,v 1.21 2005/01/17 23:58:32 marka Exp $ */ #include diff --git a/lib/isc/include/isc/netaddr.h b/lib/isc/include/isc/netaddr.h index b92335505f..ae6b57e291 100644 --- a/lib/isc/include/isc/netaddr.h +++ b/lib/isc/include/isc/netaddr.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: netaddr.h,v 1.26 2005/01/17 00:46:04 marka Exp $ */ +/* $Id: netaddr.h,v 1.27 2005/01/17 23:58:33 marka Exp $ */ #ifndef ISC_NETADDR_H #define ISC_NETADDR_H 1 diff --git a/lib/isc/netaddr.c b/lib/isc/netaddr.c index 40fece183d..f02f1354ef 100644 --- a/lib/isc/netaddr.c +++ b/lib/isc/netaddr.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: netaddr.c,v 1.29 2005/01/17 00:46:04 marka Exp $ */ +/* $Id: netaddr.c,v 1.30 2005/01/17 23:58:32 marka Exp $ */ #include diff --git a/lib/isccfg/include/isccfg/grammar.h b/lib/isccfg/include/isccfg/grammar.h index 32bf863f40..0c54acaa89 100644 --- a/lib/isccfg/include/isccfg/grammar.h +++ b/lib/isccfg/include/isccfg/grammar.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2002, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: grammar.h,v 1.7 2005/01/17 00:46:05 marka Exp $ */ +/* $Id: grammar.h,v 1.8 2005/01/17 23:58:33 marka Exp $ */ #ifndef ISCCFG_GRAMMAR_H #define ISCCFG_GRAMMAR_H 1 diff --git a/lib/isccfg/parser.c b/lib/isccfg/parser.c index 4d22ace0a9..51a275a3af 100644 --- a/lib/isccfg/parser.c +++ b/lib/isccfg/parser.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: parser.c,v 1.115 2005/01/17 00:46:04 marka Exp $ */ +/* $Id: parser.c,v 1.116 2005/01/17 23:58:33 marka Exp $ */ #include From 2a65727a9a2899acb61bcc55e2180700f0ccc301 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 18 Jan 2005 02:03:44 +0000 Subject: [PATCH 050/130] Q: I get "Error 1067" when starting named under Windows. --- FAQ | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/FAQ b/FAQ index 25eb00ce38..f6ed41e422 100644 --- a/FAQ +++ b/FAQ @@ -452,3 +452,19 @@ A: This is usually a configuration error. Q: I don't get RRSIG's returned when I use "dig +dnssec". A: You need to ensure DNSSEC is enabled (dnssec-enable yes;). + + +Q: I get "Error 1067" when starting named under Windows. + +A: This is the service manager saying that named exited. You need to + examine the Application log in the EventViewer to find out why. + + Common causes are that you failed to create "named.conf" (usually + "C:\windows\dns\etc\named.conf") or failed to specify the directory + in named.conf. + + options { + Directory "C:\windows\dns\etc"; + }; + + From 498e628692bd7301633bc3d2420f6d4cabcfc94a Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 19 Jan 2005 23:22:50 +0000 Subject: [PATCH 051/130] remove unused variable. --- lib/isc/netaddr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/isc/netaddr.c b/lib/isc/netaddr.c index f02f1354ef..aa48a88e5f 100644 --- a/lib/isc/netaddr.c +++ b/lib/isc/netaddr.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: netaddr.c,v 1.30 2005/01/17 23:58:32 marka Exp $ */ +/* $Id: netaddr.c,v 1.31 2005/01/19 23:22:50 marka Exp $ */ #include @@ -194,7 +194,7 @@ isc_netaddr_format(const isc_netaddr_t *na, char *array, unsigned int size) { isc_result_t isc_netaddr_prefixok(const isc_netaddr_t *na, unsigned int prefixlen) { static const unsigned char zeros[16]; - unsigned int nbits, nbytes, ipbytes, i; + unsigned int nbits, nbytes, ipbytes; const unsigned char *p; switch (na->family) { From 164e2a6f83cc3172bc9ba0c97a326a5eca80bc18 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 19 Jan 2005 23:25:41 +0000 Subject: [PATCH 052/130] 1800. [bug] Changes #1719 allowed a INSIST to be triggered. [RT #13428] --- CHANGES | 3 +++ lib/dns/resolver.c | 15 ++++++++++----- 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/CHANGES b/CHANGES index 0490110651..c7daf1b033 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,6 @@ +1800. [bug] Changes #1719 allowed a INSIST to be triggered. + [RT #13428] + 1799. [placeholder] rt13438 1798. [func] The server syntax has been extended to support a diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c index 34c1113f98..a1089849cb 100644 --- a/lib/dns/resolver.c +++ b/lib/dns/resolver.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: resolver.c,v 1.299 2004/12/03 01:59:28 marka Exp $ */ +/* $Id: resolver.c,v 1.300 2005/01/19 23:25:41 marka Exp $ */ #include @@ -4253,11 +4253,11 @@ noanswer_response(fetchctx_t *fctx, dns_name_t *oqname, /* * A negative response has a SOA record (Type 2) * and a optional NS RRset (Type 1) or it has neither - * a SOA or a NS RRset (Type 3) or rcode is NXDOMAIN - * (handled above) in which case the NS RRset is - * allowed (Type 4). + * a SOA or a NS RRset (Type 3, handled above) or + * rcode is NXDOMAIN (handled above) in which case + * the NS RRset is allowed (Type 4). */ - if (soa_name != NULL || ns_name == NULL) + if (soa_name != NULL) negative_response = ISC_TRUE; for (rdataset = ISC_LIST_HEAD(name->list); rdataset != NULL; @@ -5320,6 +5320,11 @@ resquery_response(isc_task_t *task, isc_event_t *event) { if ((fctx->res->options & DNS_RESOLVER_CHECKNAMES) != 0) checknames(message); + /* + * Clear cache bits. + */ + fctx->attributes &= ~(FCTX_ATTR_WANTNCACHE | FCTX_ATTR_WANTCACHE); + /* * Did we get any answers? */ From 880e7930a386d07a4f22c00a2fd4c66911754e93 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 19 Jan 2005 23:35:04 +0000 Subject: [PATCH 053/130] newcopyrights --- util/copyrights | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util/copyrights b/util/copyrights index 63bba8d496..eab3c76a6b 100644 --- a/util/copyrights +++ b/util/copyrights @@ -1840,7 +1840,7 @@ ./lib/dns/rdatasetiter.c C 1999,2000,2001,2004 ./lib/dns/rdataslab.c C 1999,2000,2001,2002,2003,2004 ./lib/dns/request.c C 2000,2001,2002,2004 -./lib/dns/resolver.c C 1999,2000,2001,2002,2003,2004 +./lib/dns/resolver.c C 1999,2000,2001,2002,2003,2004,2005 ./lib/dns/result.c C 1998,1999,2000,2001,2002,2003,2004 ./lib/dns/rootns.c C 1999,2000,2001,2002,2004 ./lib/dns/sdb.c C 2000,2001,2003,2004 From 7fed21a109b9a7eb74b67f3350264a774b4daf0c Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 20 Jan 2005 00:01:46 +0000 Subject: [PATCH 054/130] update copyright notice --- lib/dns/resolver.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c index a1089849cb..5128c96de9 100644 --- a/lib/dns/resolver.c +++ b/lib/dns/resolver.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: resolver.c,v 1.300 2005/01/19 23:25:41 marka Exp $ */ +/* $Id: resolver.c,v 1.301 2005/01/20 00:01:46 marka Exp $ */ #include From 14a97c343bc3adb840b13d515a8298c18f15be52 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 21 Jan 2005 09:18:07 +0000 Subject: [PATCH 055/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index c7daf1b033..58c074595f 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1801. [placeholder] rt288 + 1800. [bug] Changes #1719 allowed a INSIST to be triggered. [RT #13428] From 11b399514e4af7f370fe3948c3e3779a182ac5ac Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 25 Jan 2005 01:17:46 +0000 Subject: [PATCH 056/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 58c074595f..80cba75f50 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1802. [placeholder] rt11280 + 1801. [placeholder] rt288 1800. [bug] Changes #1719 allowed a INSIST to be triggered. From 28b65e6d0a03704f4faee88ebf5105addfa57968 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 25 Jan 2005 04:32:29 +0000 Subject: [PATCH 057/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 80cba75f50..339656d7b3 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1803. [placeholder] rt13483 + 1802. [placeholder] rt11280 1801. [placeholder] rt288 From 6f0f001580561b9aa300af7917ea45346da04017 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 25 Jan 2005 04:48:11 +0000 Subject: [PATCH 058/130] new draft --- doc/draft/draft-ietf-ipseckey-rr-09.txt | 951 --------------------- doc/draft/draft-ietf-ipseckey-rr-12.txt | 1008 +++++++++++++++++++++++ 2 files changed, 1008 insertions(+), 951 deletions(-) delete mode 100644 doc/draft/draft-ietf-ipseckey-rr-09.txt create mode 100644 doc/draft/draft-ietf-ipseckey-rr-12.txt diff --git a/doc/draft/draft-ietf-ipseckey-rr-09.txt b/doc/draft/draft-ietf-ipseckey-rr-09.txt deleted file mode 100644 index 423a119f39..0000000000 --- a/doc/draft/draft-ietf-ipseckey-rr-09.txt +++ /dev/null @@ -1,951 +0,0 @@ - - -IPSECKEY WG M. Richardson -Internet-Draft SSW -|Expires: August 1, 2004 February 2004 - - - A Method for Storing IPsec Keying Material in DNS -| draft-ietf-ipseckey-rr-09.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -| This Internet-Draft will expire on August 1, 2004. - -Copyright Notice - -| Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - -| This document describes a new resource record for Domain Name System -| (DNS). This record may be used to store public keys for use in IP -| security (IPsec) systems. The record also includes provisions for -| indicating what system should be contacted when establishing an IPsec -| tunnel with the entity in question. - - This record replaces the functionality of the sub-type #1 of the KEY - Resource Record, which has been obsoleted by RFC3445. - - - - - - - -|Richardson Expires August 1, 2004 [Page 1] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 -| 1.2 Use of reverse (in-addr.arpa) map . . . . . . . . . . . . . . 3 -| 1.3 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . . 3 -| 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 5 -| 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 5 -| 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 5 -| 2.3 RDATA format - gateway type . . . . . . . . . . . . . . . . . 5 -| 2.4 RDATA format - algorithm type . . . . . . . . . . . . . . . . 6 -| 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 6 -| 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . . 6 -| 3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 8 -| 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 8 -| 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 -| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 -| 4.1 Active attacks against unsecured IPSECKEY resource records . . 10 -| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 -| 6. Intellectual Property Claims . . . . . . . . . . . . . . . . . 13 -| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 -| Normative references . . . . . . . . . . . . . . . . . . . . . 15 -| Non-normative references . . . . . . . . . . . . . . . . . . . 16 -| Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 -| Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 2] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -1. Introduction - - It postulated that there is an end system desiring to establish an - IPsec tunnel with some remote entity on the network. This system, - having only a DNS name of some kind (forward, reverse or even - user@FQDN) needs a public key to authenticate the remote entity. It - also desires some guidance about whether to contact the entity - directly, or whether to contact another entity, as the gateway to - that desired entity. - - The IPSECKEY RR provides a storage mechanism for such items as the - public key, and the gateway information. - - The type number for the IPSECKEY RR is TBD. - -1.1 Overview - - The IPSECKEY resource record (RR) is used to publish a public key - that is to be associated with a Domain Name System (DNS) name for use - with the IPsec protocol suite. This can be the public key of a - host, network, or application (in the case of per-port keying). - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC2119 [7]. - -|1.2 Use of reverse (in-addr.arpa) map - -| Often a security gateway will only have access to the IP address to -| which communication is desired. It will not know the forward name. -| As such, it will frequently be the case that the IP address will be -| used an index into the reverse map. - -| The lookup is done in the usual fashion as for PTR records. The IP -| address' octets (IPv4) or nibbles (IPv6) are reversed and looked up -| under the .arpa. zone. Any CNAMEs or DNAMEs found SHOULD be -| followed. - -| Note: even when the IPsec function is the end-host, often only the -| application will know the forward name used. While the case where -| the application knows the forward name is common, the user could -| easily have typed in a literal IP address. This storage mechanism -| does not preclude using the forward name when it is available, but -| does not require it. - -|1.3 Usage Criteria - - An IPSECKEY resource record SHOULD be used in combination with DNSSEC - - - -|Richardson Expires August 1, 2004 [Page 3] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - - unless some other means of authenticating the IPSECKEY resource - record is available. - - It is expected that there will often be multiple IPSECKEY resource - records at the same name. This will be due to the presence of - multiple gateways and the need to rollover keys. - - This resource record is class independent. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 4] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -2. Storage formats - -2.1 IPSECKEY RDATA format - - The RDATA for an IPSECKEY RR consists of a precedence value, a - gateway type, a public key, algorithm type, and an optional gateway - address. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | precedence | gateway type | algorithm | gateway | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + - ~ gateway ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - -2.2 RDATA format - precedence - - This is an 8-bit precedence for this record. This is interpreted in - the same way as the PREFERENCE field described in section 3.3.9 of - RFC1035 [2]. - - Gateways listed in IPSECKEY records with lower precedence are to be - attempted first. Where there is a tie in precedence, the order - should be non-deterministic. - -2.3 RDATA format - gateway type - - The gateway type field indicates the format of the information that - is stored in the gateway field. - - The following values are defined: - - 0 No gateway is present - - 1 A 4-byte IPv4 address is present - - 2 A 16-byte IPv6 address is present - - 3 A wire-encoded domain name is present. The wire-encoded format is - self-describing, so the length is implicit. The domain name MUST - NOT be compressed. (see section 3.3 of RFC1035 [2]). - - - - -|Richardson Expires August 1, 2004 [Page 5] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -2.4 RDATA format - algorithm type - - The algorithm type field identifies the public key's cryptographic - algorithm and determines the format of the public key field. - - A value of 0 indicates that no key is present. - - The following values are defined: - - 1 A DSA key is present, in the format defined in RFC2536 [10] - - 2 A RSA key is present, in the format defined in RFC3110 [11] - - -2.5 RDATA format - gateway - - The gateway field indicates a gateway to which an IPsec tunnel may be - created in order to reach the entity named by this resource record. - - There are three formats: - - A 32-bit IPv4 address is present in the gateway field. The data - portion is an IPv4 address as described in section 3.4.1 of RFC1035 - [2]. This is a 32-bit number in network byte order. - - A 128-bit IPv6 address is present in the gateway field. The data - portion is an IPv6 address as described in section 2.2 of RFC3596 - [13]. This is a 128-bit number in network byte order. - - The gateway field is a normal wire-encoded domain name, as described - in section 3.3 of RFC1035 [2]. Compression MUST NOT be used. - -2.6 RDATA format - public keys - - Both of the public key types defined in this document (RSA and DSA) - inherit their public key formats from the corresponding KEY RR - formats. Specifically, the public key field contains the algorithm- - specific portion of the KEY RR RDATA, which is all of the KEY RR DATA - after the first four octets. This is the same portion of the KEY RR - that must be specified by documents that define a DNSSEC algorithm. - Those documents also specify a message digest to be used for - generation of SIG RRs; that specification is not relevant for - IPSECKEY RR. - - Future algorithms, if they are to be used by both DNSSEC (in the KEY - RR) and IPSECKEY, are likely to use the same public key encodings in - both records. Unless otherwise specified, the IPSECKEY public key - field will contain the algorithm-specific portion of the KEY RR RDATA - - - -|Richardson Expires August 1, 2004 [Page 6] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - - for the corresponding algorithm. The algorithm must still be - designated for use by IPSECKEY, and an IPSECKEY algorithm type number - (which might be different than the DNSSEC algorithm number) must be - assigned to it. - - The DSA key format is defined in RFC2536 [10] - - The RSA key format is defined in RFC3110 [11], with the following - changes: - - The earlier definition of RSA/MD5 in RFC2065 limited the exponent and - modulus to 2552 bits in length. RFC3110 extended that limit to 4096 - bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on - RSA public keys, other than the 65535 octet limit imposed by the two- - octet length encoding. This length extension is applicable only to - IPSECKEY and not to KEY RRs. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 7] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -3. Presentation formats - -3.1 Representation of IPSECKEY RRs - - IPSECKEY RRs may appear in a zone data master file. The precedence, - gateway type and algorithm and gateway fields are REQUIRED. The - base64 encoded public key block is OPTIONAL; if not present, then the - public key field of the resource record MUST be construed as being - zero octets in length. - - The algorithm field is an unsigned integer. No mnemonics are - defined. - - If no gateway is to be indicated, then the gateway type field MUST be - zero, and the gateway field MUST be "." - - The Public Key field is represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding, see RFC3548 [6] Section 5.2. - - The general presentation for the record as as follows: - - IN IPSECKEY ( precedence gateway-type algorithm - gateway base64-encoded-public-key ) - - -3.2 Examples - - An example of a node 192.0.2.38 that will accept IPsec tunnels on its - own behalf. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.38 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 192.0.2.38 that has published its key only. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 - . - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 192.0.2.38 that has delegated authority to the - node 192.0.2.3. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.3 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - - - -|Richardson Expires August 1, 2004 [Page 8] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - - An example of a node, 192.0.1.38 that has delegated authority to the - node with the identity "mygateway.example.com". - - 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 - mygateway.example.com. - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has - delegated authority to the node 2001:0DB8:c000:0200:2::1 - - $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa. - 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 - 2001:0DB8:0:8002::2000:1 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 9] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -4. Security Considerations - - This entire memo pertains to the provision of public keying material - for use by key management protocols such as ISAKMP/IKE (RFC2407) [8]. - - The IPSECKEY resource record contains information that SHOULD be - communicated to the end client in an integral fashion - i.e. free - from modification. The form of this channel is up to the consumer of - the data - there must be a trust relationship between the end - consumer of this resource record and the server. This relationship - may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to - another secure source, a secure local channel on the host, or some - combination of the above. - - The keying material provided by the IPSECKEY resource record is not - sensitive to passive attacks. The keying material may be freely - disclosed to any party without any impact on the security properties - of the resulting IPsec session: IPsec and IKE provide for defense - against both active and passive attacks. - - Any derivative standard that makes use of this resource record MUST - carefully document their trust model, and why the trust model of - DNSSEC is appropriate, if that is the secure channel used. - -4.1 Active attacks against unsecured IPSECKEY resource records - - This section deals with active attacks against the DNS. These - attacks require that DNS requests and responses be intercepted and - changed. DNSSEC is designed to defend against attacks of this kind. - - The first kind of active attack is when the attacker replaces the - keying material with either a key under its control or with garbage. - - If the attacker is not able to mount a subsequent man-in-the-middle - attack on the IKE negotiation after replacing the public key, then - this will result in a denial of service, as the authenticator used by - IKE would fail. - - If the attacker is able to both to mount active attacks against DNS - and is also in a position to perform a man-in-the-middle attack on - IKE and IPsec negotiations, then the attacker will be in a position - to compromise the resulting IPsec channel. Note that an attacker - must be able to perform active DNS attacks on both sides of the IKE - negotiation in order for this to succeed. - - The second kind of active attack is one in which the attacker - replaces the the gateway address to point to a node under the - attacker's control. The attacker can then either replace the public - - - -|Richardson Expires August 1, 2004 [Page 10] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - - key or remove it, thus providing an IPSECKEY record of its own to - match the gateway address. - - This later form creates a simple man-in-the-middle since the attacker - can then create a second tunnel to the real destination. Note that, - as before, this requires that the attacker also mount an active - attack against the responder. - - Note that the man-in-the-middle can not just forward cleartext - packets to the original destination. While the destination may be - willing to speak in the clear, replying to the original sender, the - sender will have already created a policy expecting ciphertext. - Thus, the attacker will need to intercept traffic from both sides. - In some cases, the attacker may be able to accomplish the full - intercept by use of Network Addresss/Port Translation (NAT/NAPT) - technology. - -| Note that risk of a man-in-the-middle attack mediated by the IPSECKEY -| RR only applies to cases where the gateway field of the IPSECKEY RR -| indicates a different entity than the owner name of the IPSECKEY RR. - -| An active attack on the DNS that caused the wrong IP address to be -| retrieved (via forged A RR), and therefore the wrong QNAME to be -| queried would also result in a man-in-the-middle attack. This -| situation exists independantly of whether or not the IPSECKEY RR is -| used. - -| In cases where the end-to-end integrity of the IPSECKEY RR is -| suspect, the end client MUST restrict its use of the IPSECKEY RR to -| cases where the RR owner name matches the content of the gateway -| field. - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 11] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -5. IANA Considerations - - This document updates the IANA Registry for DNS Resource Record Types - by assigning type X to the IPSECKEY record. - - This document creates two new IANA registries, both specific to the - IPSECKEY Resource Record: - - This document creates an IANA registry for the algorithm type field. - - Values 0, 1 and 2 are defined in Section 2.4. Algorithm numbers 3 - through 255 can be assigned by IETF Consensus (see RFC2434 [5]). - - This document creates an IANA registry for the gateway type field. - - Values 0, 1, 2 and 3 are defined in Section 2.3. Gateway type - numbers 4 through 255 can be assigned by Standards Action (see - RFC2434 [5]). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 12] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -6. Intellectual Property Claims - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 13] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -7. Acknowledgments - - My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob - Austein, and Olafur Gurmundsson who reviewed this document carefully. - Additional thanks to Olafur Gurmundsson for a reference - implementation. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 14] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -Normative references - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP - 9, RFC 2026, October 1996. - - [4] Eastlake, D. and C. Kaufman, "Domain Name System Security - Extensions", RFC 2065, January 1997. - - [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", - RFC 3548, July 2003. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 15] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -Non-normative references - - [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [8] Piper, D., "The Internet IP Security Domain of Interpretation - for ISAKMP", RFC 2407, November 1998. - - [9] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System - (DNS)", RFC 2536, March 1999. - - [11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name - System (DNS)", RFC 3110, May 2001. - - [12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource - Record (RR)", RFC 3445, December 2002. - - [13] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS - Extensions to Support IP Version 6", RFC 3596, October 2003. - - -Author's Address - - Michael C. Richardson - Sandelman Software Works - 470 Dawson Avenue - Ottawa, ON K1Z 5V7 - CA - - EMail: mcr@sandelman.ottawa.on.ca - URI: http://www.sandelman.ottawa.on.ca/ - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 16] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -Full Copyright Statement - -| Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 17] diff --git a/doc/draft/draft-ietf-ipseckey-rr-12.txt b/doc/draft/draft-ietf-ipseckey-rr-12.txt new file mode 100644 index 0000000000..c00c46b348 --- /dev/null +++ b/doc/draft/draft-ietf-ipseckey-rr-12.txt @@ -0,0 +1,1008 @@ + + +IPSECKEY WG M. Richardson +Internet-Draft SSW +Expires: July 19, 2005 January 18, 2005 + + + A Method for Storing IPsec Keying Material in DNS + draft-ietf-ipseckey-rr-12.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 July 19, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). All Rights Reserved. + +Abstract + + This document describes a new resource record for the Domain Name + System (DNS). This record may be used to store public keys for use in + IP security (IPsec) systems. The record also includes provisions for + indicating what system should be contacted when establishing an IPsec + tunnel with the entity in question. + + This record replaces the functionality of the sub-type #1 of the KEY + Resource Record, which has been obsoleted by RFC3445. + + + + + + +Richardson Expires July 19, 2005 [Page 1] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2 Use of DNS address-to-name maps (IN-ADDR.ARPA and + IP6.ARPA) . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.3 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . 5 + 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . 5 + 2.3 RDATA format - gateway type . . . . . . . . . . . . . . . . 5 + 2.4 RDATA format - algorithm type . . . . . . . . . . . . . . . 6 + 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . 6 + 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . 6 + 3. Presentation formats . . . . . . . . . . . . . . . . . . . . 8 + 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . 8 + 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4. Security Considerations . . . . . . . . . . . . . . . . . . 10 + 4.1 Active attacks against unsecured IPSECKEY resource + records . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.1.1 Active attacks against IPSECKEY keying materials . . . . . . 10 + 4.1.2 Active attacks against IPSECKEY gateway material . . . . . . 11 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 + 6. Intellectual Property Claims . . . . . . . . . . . . . . . . 14 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 + Normative references . . . . . . . . . . . . . . . . . . . . 16 + Non-normative references . . . . . . . . . . . . . . . . . . 17 + Author's Address . . . . . . . . . . . . . . . . . . . . . . 17 + Intellectual Property and Copyright Statements . . . . . . . 18 + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires July 19, 2005 [Page 2] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + +1. Introduction + + Suppose we have a host which wishes to establish an IPsec tunnel with + some remote entity on the network. In many cases this end system + will only know a DNS name for the remote entity (whether that DNS + name be the name of the remote node, a DNS reverse tree name + corresponding to the IP address of the remote node, or perhaps a the + domain name portion of a "user@FQDN" name for a remote entity). In + these cases the host will need to obtain a public key in order to + authenticate the remote entity, and may also need some guidance about + whether it should contact the entity directly or use another node as + a gateway to the target entity. + + The IPSECKEY RR provides a storage mechanism for such data as the + public key and the gateway information. + + The type number for the IPSECKEY RR is TBD. + + This record replaces the functionality of the sub-type #1 of the KEY + Resource Record, which has been obsoleted by RFC3445 [12]. + +1.1 Overview + + The IPSECKEY resource record (RR) is used to publish a public key + that is to be associated with a Domain Name System (DNS)[1] name for + use with the IPsec protocol suite. This can be the public key of a + host, network, or application (in the case of per-port keying). + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC2119 [7]. + +1.2 Use of DNS address-to-name maps (IN-ADDR.ARPA and IP6.ARPA) + + Often a security gateway will only have access to the IP address of + the node with which communication is desired, and will not know any + other name for the target node. Because of this, it will frequently + be the case that the best way of looking up IPSECKEY RRs will be by + using the IP address as an index into one of the reverse mapping + trees (IN-ADDR.ARPA for IPv4 or IP6.ARPA for IPv6). + + The lookup is done in the usual fashion as for PTR records. The IP + address' octets (IPv4) or nibbles (IPv6) are reversed and looked up + with the appropriate suffix. Any CNAMEs or DNAMEs found MUST be + followed. + + Note: even when the IPsec function is the end-host, often only the + application will know the forward name used. While the case where the + + + +Richardson Expires July 19, 2005 [Page 3] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + + application knows the forward name is common, the user could easily + have typed in a literal IP address. This storage mechanism does not + preclude using the forward name when it is available, but does not + require it. + +1.3 Usage Criteria + + An IPSECKEY resource record SHOULD be used in combination with DNSSEC + [9] unless some other means of authenticating the IPSECKEY resource + record is available. + + It is expected that there will often be multiple IPSECKEY resource + records at the same name. This will be due to the presence of + multiple gateways and the need to rollover keys. + + This resource record is class independent. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires July 19, 2005 [Page 4] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + +2. Storage formats + +2.1 IPSECKEY RDATA format + + The RDATA for an IPSECKEY RR consists of a precedence value, a + gateway type, a public key, algorithm type, and an optional gateway + address. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | precedence | gateway type | algorithm | gateway | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + + ~ gateway ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + + +2.2 RDATA format - precedence + + This is an 8-bit precedence for this record. This is interpreted in + the same way as the PREFERENCE field described in section 3.3.9 of + RFC1035 [2]. + + Gateways listed in IPSECKEY records with lower precedence are to be + attempted first. Where there is a tie in precedence, the order should + be non-deterministic. + +2.3 RDATA format - gateway type + + The gateway type field indicates the format of the information that + is stored in the gateway field. + + The following values are defined: + + 0 No gateway is present + + 1 A 4-byte IPv4 address is present + + 2 A 16-byte IPv6 address is present + + 3 A wire-encoded domain name is present. The wire-encoded format is + self-describing, so the length is implicit. The domain name MUST + NOT be compressed. (see section 3.3 of RFC1035 [2]). + + + + +Richardson Expires July 19, 2005 [Page 5] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + +2.4 RDATA format - algorithm type + + The algorithm type field identifies the public key's cryptographic + algorithm and determines the format of the public key field. + + A value of 0 indicates that no key is present. + + The following values are defined: + + 1 A DSA key is present, in the format defined in RFC2536 [10] + + 2 A RSA key is present, in the format defined in RFC3110 [11] + + +2.5 RDATA format - gateway + + The gateway field indicates a gateway to which an IPsec tunnel may be + created in order to reach the entity named by this resource record. + + There are three formats: + + A 32-bit IPv4 address is present in the gateway field. The data + portion is an IPv4 address as described in section 3.4.1 of RFC1035 + [2]. This is a 32-bit number in network byte order. + + A 128-bit IPv6 address is present in the gateway field. The data + portion is an IPv6 address as described in section 2.2 of RFC3596 + [13]. This is a 128-bit number in network byte order. + + The gateway field is a normal wire-encoded domain name, as described + in section 3.3 of RFC1035 [2]. Compression MUST NOT be used. + +2.6 RDATA format - public keys + + Both of the public key types defined in this document (RSA and DSA) + inherit their public key formats from the corresponding KEY RR + formats. Specifically, the public key field contains the + algorithm-specific portion of the KEY RR RDATA, which is all of the + KEY RR DATA after the first four octets. This is the same portion of + the KEY RR that must be specified by documents that define a DNSSEC + algorithm. Those documents also specify a message digest to be used + for generation of SIG RRs; that specification is not relevant for + IPSECKEY RR. + + Future algorithms, if they are to be used by both DNSSEC (in the KEY + RR) and IPSECKEY, are likely to use the same public key encodings in + both records. Unless otherwise specified, the IPSECKEY public key + field will contain the algorithm-specific portion of the KEY RR RDATA + + + +Richardson Expires July 19, 2005 [Page 6] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + + for the corresponding algorithm. The algorithm must still be + designated for use by IPSECKEY, and an IPSECKEY algorithm type number + (which might be different than the DNSSEC algorithm number) must be + assigned to it. + + The DSA key format is defined in RFC2536 [10] + + The RSA key format is defined in RFC3110 [11], with the following + changes: + + The earlier definition of RSA/MD5 in RFC2065 limited the exponent and + modulus to 2552 bits in length. RFC3110 extended that limit to 4096 + bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on + RSA public keys, other than the 65535 octet limit imposed by the + two-octet length encoding. This length extension is applicable only + to IPSECKEY and not to KEY RRs. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires July 19, 2005 [Page 7] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + +3. Presentation formats + +3.1 Representation of IPSECKEY RRs + + IPSECKEY RRs may appear in a zone data master file. The precedence, + gateway type and algorithm and gateway fields are REQUIRED. The + base64 encoded public key block is OPTIONAL; if not present, then the + public key field of the resource record MUST be construed as being + zero octets in length. + + The algorithm field is an unsigned integer. No mnemonics are defined. + + If no gateway is to be indicated, then the gateway type field MUST be + zero, and the gateway field MUST be "." + + The Public Key field is represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding, see RFC3548 [6] Section 5.2. + + The general presentation for the record as as follows: + + IN IPSECKEY ( precedence gateway-type algorithm + gateway base64-encoded-public-key ) + + +3.2 Examples + + An example of a node 192.0.2.38 that will accept IPsec tunnels on its + own behalf. + + 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 + 192.0.2.38 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + An example of a node, 192.0.2.38 that has published its key only. + + 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 + . + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + An example of a node, 192.0.2.38 that has delegated authority to the + node 192.0.2.3. + + 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 + 192.0.2.3 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + An example of a node, 192.0.1.38 that has delegated authority to the + + + +Richardson Expires July 19, 2005 [Page 8] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + + node with the identity "mygateway.example.com". + + 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 + mygateway.example.com. + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has + delegated authority to the node 2001:0DB8:c000:0200:2::1 + + $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa. + 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 + 2001:0DB8:0:8002::2000:1 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires July 19, 2005 [Page 9] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + +4. Security Considerations + + This entire memo pertains to the provision of public keying material + for use by key management protocols such as ISAKMP/IKE (RFC2407) [8]. + + The IPSECKEY resource record contains information that SHOULD be + communicated to the end client in an integral fashion - i.e. free + from modification. The form of this channel is up to the consumer of + the data - there must be a trust relationship between the end + consumer of this resource record and the server. This relationship + may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to + another secure source, a secure local channel on the host, or some + combination of the above. + + The keying material provided by the IPSECKEY resource record is not + sensitive to passive attacks. The keying material may be freely + disclosed to any party without any impact on the security properties + of the resulting IPsec session: IPsec and IKE provide for defense + against both active and passive attacks. + + Any derivative specification that makes use of this resource record + MUST carefully document their trust model, and why the trust model of + DNSSEC is appropriate, if that is the secure channel used. + + An active attack on the DNS that caused the wrong IP address to be + retrieved (via forged address), and therefore the wrong QNAME to be + queried would also result in a man-in-the-middle attack. This + situation exists independantly of whether or not the IPSECKEY RR is + used. + +4.1 Active attacks against unsecured IPSECKEY resource records + + This section deals with active attacks against the DNS. These attacks + require that DNS requests and responses be intercepted and changed. + DNSSEC is designed to defend against attacks of this kind. This + section deals with the situation where DNSSEC is not available. This + is not the recommended deployment scenario. + +4.1.1 Active attacks against IPSECKEY keying materials + + The first kind of active attack is when the attacker replaces the + keying material with either a key under its control or with garbage. + + The gateway field is either untouched, or is null. The IKE + negotiation will therefore occur with the original end-system. For + this attack to be successful, the attacker must be able to perform a + man-in-the-middle attack on the IKE negotiation. This attack requires + that the attacker be able to intercept and modify packets on the + + + +Richardson Expires July 19, 2005 [Page 10] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + + forwarding path for the IKE and data packets. + + If the attacker is not able to perform this man-in-the-middle attack + on the IKE negotiation, then this will result in a denial of service, + as the IKE negotiation will fail. + + If the attacker is able to both to mount active attacks against DNS + and is also in a position to perform a man-in-the-middle attack on + IKE and IPsec negotiations, then the attacker will be in a position + to compromise the resulting IPsec channel. Note that an attacker + must be able to perform active DNS attacks on both sides of the IKE + negotiation in order for this to succeed. + +4.1.2 Active attacks against IPSECKEY gateway material + + The second kind of active attack is one in which the attacker + replaces the the gateway address to point to a node under the + attacker's control. The attacker then either replaces the public key + or removes it. If they were to remove the public key, then they + could provide an accurate public key of their own in a second record. + + This second form creates a simple man-in-the-middle since the + attacker can then create a second tunnel to the real destination. + Note that, as before, this requires that the attacker also mount an + active attack against the responder. + + Note that the man-in-the-middle can not just forward cleartext + packets to the original destination. While the destination may be + willing to speak in the clear, replying to the original sender, the + sender will have already created a policy expecting ciphertext. Thus, + the attacker will need to intercept traffic in both directions. In + some cases, the attacker may be able to accomplish the full intercept + by use of Network Addresss/Port Translation (NAT/NAPT) technology. + + This attack is easier than the first one because the attacker does + NOT need to be on the end-to-end forwarding path. The attacker need + only be able to modify DNS replies. This can be done by packet + modification, by various kinds of race attacks, or through methods + that pollute DNS caches. + + In cases where the end-to-end integrity of the IPSECKEY RR is + suspect, the end client MUST restrict its use of the IPSECKEY RR to + cases where the RR owner name matches the content of the gateway + field. As the RR owner name is assumed when the gateway field is + null, a null gateway field is considered a match. + + Thus, any records obtained under unverified conditions (e.g. no + DNSSEC, or trusted path to source) that have a non-null gateway field + + + +Richardson Expires July 19, 2005 [Page 11] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + + MUST be ignored. + + This restriction eliminates attacks against the gateway field, which + are considered much easier, as the attack does not need to be on the + forwarding path. + + In the case of an IPSECKEY RR with a value of three in its gateway + type field, the gateway field contains a domain name. The subsequent + query required to translate that name into an IP address or IPSECKEY + RR will also be subject to man-in-the-middle attacks. If the + end-to-end integrity of this second query is suspect, then the + provisions above also apply. The IPSECKEY RR MUST be ignored whenever + the resulting gateway does not match the QNAME of the original + IPSECKEY RR query. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires July 19, 2005 [Page 12] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + +5. IANA Considerations + + This document updates the IANA Registry for DNS Resource Record Types + by assigning type X to the IPSECKEY record. + + This document creates two new IANA registries, both specific to the + IPSECKEY Resource Record: + + This document creates an IANA registry for the algorithm type field. + + Values 0, 1 and 2 are defined in Section 2.4. Algorithm numbers 3 + through 255 can be assigned by IETF Consensus (see RFC2434 [5]). + + This document creates an IANA registry for the gateway type field. + + Values 0, 1, 2 and 3 are defined in Section 2.3. Gateway type numbers + 4 through 255 can be assigned by Standards Action (see RFC2434 [5]). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires July 19, 2005 [Page 13] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + +6. Intellectual Property Claims + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires July 19, 2005 [Page 14] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + +7. Acknowledgments + + My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob + Austein, and Olafur Gurmundsson who reviewed this document carefully. + Additional thanks to Olafur Gurmundsson for a reference + implementation. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires July 19, 2005 [Page 15] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + +Normative references + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [4] Eastlake, D. and C. Kaufman, "Domain Name System Security + Extensions", RFC 2065, January 1997. + + [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", + RFC 3548, July 2003. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires July 19, 2005 [Page 16] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + +Non-normative references + + [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [8] Piper, D., "The Internet IP Security Domain of Interpretation + for ISAKMP", RFC 2407, November 1998. + + [9] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name + System (DNS)", RFC 3110, May 2001. + + [12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record (RR)", RFC 3445, December 2002. + + [13] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS + Extensions to Support IP Version 6", RFC 3596, October 2003. + + +Author's Address + + Michael C. Richardson + Sandelman Software Works + 470 Dawson Avenue + Ottawa, ON K1Z 5V7 + CA + + EMail: mcr@sandelman.ottawa.on.ca + URI: http://www.sandelman.ottawa.on.ca/ + + + + + + + + + + + + + + + + + +Richardson Expires July 19, 2005 [Page 17] + +Internet-Draft Storing IPsec keying material in DNS January 2005 + + +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 (2005). 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. + + + + +Richardson Expires July 19, 2005 [Page 18] + From 70ba825728dc64439801981a1abe7f1e28182698 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 27 Jan 2005 23:27:54 +0000 Subject: [PATCH 059/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 339656d7b3..a8e4f024e7 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1804. [placeholder] rt10114 + 1803. [placeholder] rt13483 1802. [placeholder] rt11280 From a45f11c75d305930721d1b3d0972b76cb2a894f0 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 28 Jan 2005 00:41:31 +0000 Subject: [PATCH 060/130] new draft --- doc/draft/draft-ietf-dnsext-nsec3-00.txt | 840 ++++++++++++++++++ doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt | 728 +++++++++++++++ 2 files changed, 1568 insertions(+) create mode 100644 doc/draft/draft-ietf-dnsext-nsec3-00.txt create mode 100644 doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt diff --git a/doc/draft/draft-ietf-dnsext-nsec3-00.txt b/doc/draft/draft-ietf-dnsext-nsec3-00.txt new file mode 100644 index 0000000000..2b4ac79ec2 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-nsec3-00.txt @@ -0,0 +1,840 @@ + +Network Working Group B. Laurie +Internet-Draft G. Sisson +Expires: July 2, 2005 Nominet + R. Arends + Telematica Instituut + january 2005 + + DNSSEC Hash Authenticated Denial of Existence + draft-ietf-dnsext-nsec3-00 + +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 July 2, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be + used to provide authenticated denial of existence of DNS ownernames + and types; however, it permits any user to traverse a zone and obtain + a listing of all ownernames. + + +Laurie, et al. Expires July 2, 2005 [Page 1] +Internet-Draft nsec3 january 2005 + + A complete zone file can be used either directly as a source of + probable e-mail addresses for spam, or indirectly as a key for + multiple WHOIS queries to reveal registrant data which many + registries (particularly in Europe) may be under strict legal + obligations to protect. Many registries therefore prohibit copying + of their zone file; however the use of NSEC RRs makes renders + policies unenforceable. + + This document proposes a scheme which obscures original ownernames + while permitting authenticated denial of existence of non-existent + names. Non-authoritative delegation point NS RR types may be + excluded. + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires July 2, 2005 [Page 2] +Internet-Draft nsec3 january 2005 + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5 + 2.1 NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 5 + 2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 6 + 2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 6 + 2.1.3 The Iterations Field . . . . . . . . . . . . . . . . . 6 + 2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 6 + 2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 6 + 2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7 + 2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 7 + 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 8 + 3. Creating Additional NSEC3 RR for Empty Non Terminals . . . . . 9 + 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 9 + 5. Special Considerations . . . . . . . . . . . . . . . . . . . . 9 + 5.1 delegation points . . . . . . . . . . . . . . . . . . . . 10 + 5.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 10 + 5.2 Additional Complexity Caused by Wildcards . . . . . . . . 11 + 5.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 11 + 5.4.1 Avoiding Hash Collisions during generation . . . . . . 11 + 5.4.2 Second Preimage Requirement Analysis . . . . . . . . . 11 + 5.4.3 Possible Hash Value Truncation Method . . . . . . . . 12 + 6. Performance Considerations . . . . . . . . . . . . . . . . . . 12 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 9. Requirements notation . . . . . . . . . . . . . . . . . . . . 13 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 13 + A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 + 11.2 Informative References . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 + Intellectual Property and Copyright Statements . . . . . . . . 17 + + + + + + + +Laurie, et al. Expires July 2, 2005 [Page 3] +Internet-Draft nsec3 january 2005 + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduced the NSEC Resource + Record (RR) for Authenticated Denial of Existence. This document + introduces a new RR as an alternative to NSEC that provides measures + against zone traversal and allows for gradual expansion of + delegation-centric zones. + +1.1 Rationale + + The DNS Security Extensions included the NSEC RR to provide + authenticated denial of existence. Though the NSEC RR meets the + requirements for authenticated denial of Existence, it introduced a + side-effect in that the contents of a zone can be enumerated. This + property introduces undesired policy issues. + + A second requirement was that the existence of all record types in a + zone -including delegation point NS record types- can be accounted + for, despite the fact that delegation point NS RRsets are not + authoritative and not signed. This requirement has a side-effect + that the overhead of delegation centric signed zones is not related + to the increase in security of subzones. This requirement does not + allow delegation centric zones size to grow in relation to the growth + of signed subzones. + + In the past, solutions have been proposed as a measure against these + side effects but at the time were regarded as secondary over the need + to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter) + a graceful transition path to future enhancements is introduced, + while current DNSSEC deployment can continue. This document + accumulates measures against the side effects introduced by NSEC, and + presents the NSEC3 Resource Record. + + The reader is assumed to be familiar with the basic DNS concepts + described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs + that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 + [RFC2308]. + +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]. + +1.3 Terminology + + In this document the term "original ownername" refers to a standard + ownername. Because this proposal uses the result of a hash function + + +Laurie, et al. Expires July 2, 2005 [Page 4] +Internet-Draft nsec3 january 2005 + + over the original (unmodified) ownername, this result is refered to + as "hashed ownername". + +2. The NSEC3 Resource Record + + The NSEC3 RR provides Authenticated Denial of Existence for DNS + Resource Record Sets. + + The NSEC3 Resource Record lists RR types present at the NSEC3 RR's + original ownername. It includes the next hashed ownername in the + canonical ordering of the zone. The complete set of NSEC3 RRs in a + zone indicates which RRsets exist for the original ownername of the + RRset and form a chain of hashed ownernames in the zone. This + information is used to provide authenticated denial of existence for + DNS data, as described in RFC 2535 [RFC2535]. Unsigned delegation + point NS RR sets can optionally be excluded. To provide protection + against zone traversal, the ownernames used in the NSEC3 RR are + cryptographic hash-value prepended to the name of the zone. The + NSEC3 RR record indicates which Hash Function is used to construct to + hash, which Salt is used, and how many iterations of the Hash + Function are performed over the original ownername. + + The type value for the NSEC3 RR is XX. + + The NSEC3 RR RDATA format is class independent. + + The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching [RFC2308]. + +2.1 NSEC3 RDATA Wire Format + + The RDATA of the NSEC3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |A|Hash Function| Iterations | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Salt Length | Salt / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Hashed Ownername / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Laurie, et al. Expires July 2, 2005 [Page 5] +Internet-Draft nsec3 january 2005 + +2.1.1 The Authoritative Only Flag Field + + The Authoritative Only Flag field indicates whether the Type Bit Maps + include delegation point NS record types. + + If the flag is set to 1, the NS RR type bit for a delegation point + ownername SHOULD be clear when the NSEC3 RR is generated. The NS RR + type bit MUST be ignored during processing of the NSEC3 RR. The NS + RR type bit has no meaning in this context (it is not authoritative), + hence the NSEC3 does not contest the existence of a NS RR type record + for this ownername. When a delegation is not secured, there exist no + DS RR type nor any other authoritative types for this delegation, + hence the unsecured delegation has no NSEC3 record associated. + Please see the Special Consideration section for implications for + unsigned delegations. + + If the flag is set to 0, the NS RR type bit for a delegation point + ownername MUST be set if the NSEC3 covers a delegation, even though + the NS RR itself is not authoritative. This implies that all + delegations, signed or unsigned, have an NSEC3 record associated. + This behavior is identical to NSEC behavior. + +2.1.2 The Hash Function Field + + The Hash Function field identifies the cryptographic hash function + used to construct the hash-value. + + This document defines Value 1 for SHA-1 and Value 127 for + Experimental. All other values are reserved. + + On reception, a resolver MUST discard an NSEC3 RR with an unknown + Hash Function value. + +2.1.3 The Iterations Field + + The Iterations field defines the number of times the hash has been + iterated. More iterations results in greater resiliency of the hash + value against dictionary attacks, but at a higher cost for both the + server and resolver. + +2.1.4 The Salt Length Field + + The Salt Length Field defines the length of the salt in octets. + +2.1.5 The Salt Field + + The salt field is not present when the Salt Length Field has a value + of 0. + + +Laurie, et al. Expires July 2, 2005 [Page 6] +Internet-Draft nsec3 january 2005 + + The salt field is prepended to the original ownername before hashing + in order to defend against precalculated dictionary attacks. + + The salt is not prepended during iterations of the hash function. + + The Salt field value MUST be identical for all NSEC3 RRs generated + for the zone. If the salt were different for each NSEC3 RR, + collisions could occur where an NSEC3 denies the existence of + existing RRs due to the application of different salt values. + +2.1.6 The Next Hashed Ownername Field + + The Next Hashed Ownername Field contains the hash of the ownername of + the next RR in the canonical ordering of the hashed ownernames of the + zone. The value of the Next Hashed Ownername Field in the last NSEC3 + record in the zone is the same as the ownername of the first NSEC3 RR + in the zone in canonical order. + + A sender MUST NOT use DNS name compression on the Next Hashed + Ownername field when transmitting an NSEC3 RR. + + Hashed ownernames of RRsets not authoritative for the given zone + (such as glue records) MUST NOT be listed in the Hash of Next Domain + Name unless at least one authoritative RRset exists at the same owner + name. + +2.1.7 The list of Type Bit Map(s) Field + + The Type Bit Maps field identifies the RRset types which exist at the + NSEC3 RR's ownername. + + The Type bit for the NSEC3 and RRSIG MUST be set during generation, + and MUST be ignored during processing. + + 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 NSEC3 RR RDATA in increasing numerical + order. + + "|" denotes concatenation + + Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + + + +Laurie, et al. Expires July 2, 2005 [Page 7] +Internet-Draft nsec3 january 2005 + + 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 to + 1, it indicates that an RRset of that type is present for the NSEC3 + RR's ownername. If a bit is set to 0, it indicates that no RRset of + that type is present for the NSEC3 RR's ownername. + + The RR type 2 (NS) is authoritative at the apex of a zone and is not + authoritative at delegation points. If the Authoritative Only Flag + is set to 1, the delegation point NS RR type MUST NOT be included in + the type bit maps. If the Authoritative Only Flag is set to 0, the + NS RR type at a delegation point MUST be included in the type bit + maps. + + 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 [4] + (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 + NSEC3 RR's actual ownername. Trailing zero octets not specified MUST + be interpretted as zero octets. + +2.2 The NSEC3 RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Authoritative Only Field is represented as an unsigned decimal + integer. The value are either 0 or 1. + + The Hash field is presented as the name of the hash or as an unsigned + decimal integer. The value has a maximum of 127. + + The Iterations field is presented as an unsigned decimal integer. + + The Salt Length field is not presented. + + The Salt field is represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is not allowed within the sequence. + + +Laurie, et al. Expires July 2, 2005 [Page 8] +Internet-Draft nsec3 january 2005 + + The Salt Field is represented as 00 when the Salt Length field has + value 0. + + The Hash of Next Domain Name field is represented as a sequence of + case-insensitive base32 digits. Whitespace is allowed within the + sequence. + + 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 [5] (section 5) MUST be used. + +3. Creating Additional NSEC3 RR for Empty Non Terminals + + In order to prove the nonexistence of a record that might be covered + by a wildcard, it is necessary to prove the existence of its closest + encloser. A closest encloser might be an Empty Non Terminal. + + Additional NSEC3 RRs cover every existing intermediate label level. + Additional NSEC3 RRs are identical in format to NSEC3 RRs that cover + existing RRs in the zone. The difference is that the type-bit-maps + only indicate the existence of an NSEC3 RR and a RRSIG type. + +4. Calculation of the Hash + + Define H(x) to be the hash of x using the hash function selected by + the NSEC3 record and || to indicate concatenation. Then define: + + IH(salt,x,0)=H(x || salt) + + IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0 + + Then the calculated hash of an ownername is + IH(salt,ownername,iterations-1), where the ownername is the canonical + form. + + The canonical form of the ownername is the wire format of the + ownername where: + 1. The ownername is fully expanded (no DNS name compression) and + fully qualified; + 2. All uppercase US-ASCII letters are replaced by the corresponding + lowercase US-ASCII letters; + 3. If the ownername is a wildcard name, the ownername is in its + original unexpanded form, including the "*" label (no wildcard + substitution); + +5. Special Considerations + + The following paragraphs clarify specific behavior explain special + + +Laurie, et al. Expires July 2, 2005 [Page 9] +Internet-Draft nsec3 january 2005 + + considerations for implementations. + +5.1 delegation points + + This proposal introduces the Authoritative Only Flag which indicates + whether non authoritative delegation point NS records are included in + the type bit Maps. As discussed in paragraph 2.1.1, a flag value of + 0 indicates that the interpretation of the type bit maps is identical + to NSEC records. + + The following subsections describe behavior when the flag value is 1. + +5.1.1 Unsigned Delegations + + Delegation point NS records are not authoritative. They are + authoritative in the delegated zone. No other data exists at the + ownername of an unsigned delegation point. + + Since no authoritative data exist at this ownername, it is excluded + from the NSEC3 chain. This is an optimization since it relieves the + zone of including an NSEC3 record and its associated signature for + this name. + + An NSEC3 that denies existence of ownernames between X and X' with + the Authoritative Only Flag set to 1 can not be used to proof + presence nor absence of the delegation point NS records for unsigned + delegations in the interval X, X'. The Authoritative Only Flag + effectively states No Contest on the presence of delegation point NS + resource records. + + Since proof is absent, there exists a new attack vector. Unsigned + delegation point NS records can be deleted during a man in the middle + attack, effectively denying existence of the delegation. This is a + form of Denial of Service, where the victim has no information it is + under attack, since all signatures are valid and the fabricated + response form is a known type of response. + + The only possible mitigation is to either not use this method, hence + proving existence or absence of unsigned delegations, or signing the + delegated zone, changing the unsigned delegation into a signed + delegation. + + A second attack vector exists in that an adversary is able to + successfully fabricate a response claiming a not existent delegation + to exist, though unsigned. + + The only possible mitigation is to either not use this method, hence + proving absence of unsigned delegations. + + +Laurie, et al. Expires July 2, 2005 [Page 10] +Internet-Draft nsec3 january 2005 + +5.2 Additional Complexity Caused by Wildcards + + If a wildcard ownername appears in a zone, the wildcard label ("*") + is treated as a literal symbol and is treated in the same way as any + other ownername for purposes of generating NSEC3 RRs. RFC 2535 + [RFC2525] describes the impact of wildcards on authenticated denial + of existence. + + In order to prove there are no wildcards for a domain, as well as no + RRs that match directly, an RR must be shown for the closest + encloser, and nonexistence must be shown for all enclosers that could + be closer. + +5.3 Salting + + Augmenting original ownernames with salt before hashing increases the + cost of a dictionary of pre-generated hash-values. For every bit of + salt, the cost of the dictionary doubles. The NSEC3 RR can use + maximum 2040 bits of salt, multiplying the cost by 2^2040. + + The salt value for each NSEC3 RR MUST be equal for a single version + of the zone. + +5.4 Hash Collision + + Hash collisions occur when different messages have the same hash + value. The expected number of domain names needed to give a 1 in 2 + chance of a single collision is about 2^80. Though this probability + is extremely low, the following paragraphs deal with avoiding + collisions and assessing possible damage in the event of an attack + using Hash collisions. + +5.4.1 Avoiding Hash Collisions during generation + + During generation of NSEC3 RRs, hash values are supposedly unique. + In the (academic) case of a collision occuring, an alternative salt + SHOULD be chosen and all hash values SHOULD be regenerated. + + If hash values are not regenerated on collision, the NSEC3 RR MUST + list all authoritative RR types that exist for both owners, to avoid + a replay attack, spoofing an existing type as non-existent. + +5.4.2 Second Preimage Requirement Analysis + + A collision resistant hash function has a second-preimage resistance + property. The second-preimage resistance property means that it is + computationally infeasible to find another message with the same hash + value as a given message, i.e. given preimage X, to find a second + + +Laurie, et al. Expires July 2, 2005 [Page 11] +Internet-Draft nsec3 january 2005 + + preimage X' <> X such that hash(X) = hash(X'). The probability of + finding a second preimage is 1 in 2^160 for SHA-1 on average. To + mount an attack using an existing NSEC3 RR, an adversary needs to + find a second preimage. + + Assuming an adversary is capable of mounting such an extreme attack, + the actual damage is that a response message can be generated which + claims that a certain QNAME (i.e. the second pre-image) does exist, + while in reality QNAME does not exist (a false positive), which will + either cause a security aware resolver to re-query for the + non-existent name, or to fail the initial query. Note that the + adversary can't mount this attack on an existing name but only on a + name that the adversary can't choose and does not yet exist. + +5.4.3 Possible Hash Value Truncation Method + + The previous sections outlined the low probability and low impact of + a second-preimage attack. When impact and probability are low, while + space in a DNS message is costly, truncation is tempting. Truncation + might be considered to allow for shorter ownernames and rdata for + hashed labels. In general, if a cryptographic hash is truncated to n + bits, then the expected number of domains required to give a 1 in 2 + probability of a single collision is approximately 2^(n/2) and the + work factor to produce a second preimage resistance is 2^n. + + An extreme hash value truncation would be truncating to the shortest + possible unique label value. Considering that hash values are + presented in base32, which represents 5 bits per label character, + truncation must be done on a 5 bit boundary. This would be unwise, + since the work factor to produce collisions would then approximate + the size of the zone. + + Though the mentioned truncation can be maximized to a certain + extreme, the probability of collision increases exponentially for + every truncated bit. Given the low impact of hash value collisions + and limited space in DNS messages, the balance between truncation + profit and collision damage may be determined by local policy. + +6. Performance Considerations + + Iterated hashes will obviously impose a performance penalty on both + authoritative servers and resolvers. Therefore, the number of + iterations should be carefully chosen. + +7. IANA Considerations + + IANA has to create a new registry for NSEC3 Hash Functions. The + range for this registry is 0-127. Value 1 is marked as SHA-1. + + +Laurie, et al. Expires July 2, 2005 [Page 12] +Internet-Draft nsec3 january 2005 + + Values 0, 2-126 are marked as Reserved For Future Use. Value 127 is + marked as Experimental. + +8. Security Considerations + + The NSEC3 records are still susceptible to dictionary attacks (i.e. + the attacker retrieves all the NSEC3 records, then calculates the + hashes of all likely domain names, comparing against the hashes found + in the NSEC3 records, and thus enumerating the zone). These are + substantially more expensive than traversing the original NSEC + records would have been, and in any case, such an attack could also + be used directly against the name server itself by performing queries + for all likely names. The expense of this attack can be chosen by + setting the iterations in the NSEC3 RR. + + High-value domains are also susceptible to a precalculated dictionary + attack - that is, a list of hashes for all likely names is computed + once, then NSEC3 is scanned periodically and compared against the + precomputed hashes. This attack is prevented by changing the salt on + a regular basis. + + Walking the NSEC3 RRs will reveal the total number of records in the + zone, and also what types they are. This could be mitigated by + adding dummy entries, but certainly an upper limit can always be + found. + + Hash collisions may occur. If they do, it will be impossible to + prove the nonexistence of the colliding domain - however, this is + fantastically unlikely, and, in any case, DNSSEC already relies on + SHA-1 to not collide. + +9. Requirements notation + + 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]. + +10. Security Considerations + +Appendix A. Example Zone + + This is a zone showing its NSEC3 records. They can also be used as + test vectors for the hash algorithm. RRSIG records have been elided. + + + + +Laurie, et al. Expires July 2, 2005 [Page 13] +Internet-Draft nsec3 january 2005 + + example.com. 1000 IN SOA localhost. + postmaster.localhost.example.com. ( + 1 ; serial + 3600 ; refresh (1 hour) + 1800 ; retry (30 minutes) + 604800 ; expire (1 week) + 3600 ; minimum (1 hour) + ) + 1000 NS ns1.example.com. + 1000 NS ns2.example.com. + f519593e82969842a136e0f47814c881fa163833.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 4EF8239D95C18403A509D7C336A5D0FA48FD1107 \ + NS SOA RRSIG DNSKEY NSEC3 + a.example.com. 1000 IN A 1.2.3.4 + 1000 IN A 1.2.3.5 + 1000 TXT "An example" + bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \ + A TXT RRSIG NSEC3 + b.example.com. 1000 IN A 1.2.3.7 + 83c06d3b7d01fbc9576c71af2bec1a1163435153.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 A33559360EECB02F36B5C1B72C109126CA4F5A0D \ + A RRSIG NSEC3 + a.b.c.example.com. 1000 IN A 1.2.3.6 + a33559360eecb02f36b5c1b72c109126ca4f5a0d.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 BFE6EA21DEE9D228889AE11FA58C4BD551D15801 \ + A RRSIG NSEC3 + ns1.example.com. 1000 IN A 1.2.3.8 + 4ef8239d95c18403a509d7c336a5d0fa48fd1107.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 50016B56FD2F0FFC7B563C50FAF0E34259763BBB \ + A RRSIG NSEC3 + ns2.example.com. 1000 IN A 1.2.3.9 + 50016b56fd2f0ffc7b563c50faf0e34259763bbb.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 83C06D3B7D01FBC9576C71AF2BEC1A1163435153 \ + A RRSIG NSEC3 + +11. References + +11.1 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. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + + +Laurie, et al. Expires July 2, 2005 [Page 14] +Internet-Draft nsec3 january 2005 + + 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. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + +11.2 Informative References + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + + [rollover] + Ihren, J., Kolkman, O. and B. Manning, "An In-Band + Rollover Algorithm and a Out-Of-Band Priming Method for + DNS Trust Anchors.", July 2004. + +Authors' Addresses + + Ben Laurie + Nominet + 17 Perryn Road + London W3 7LR + England + + Phone: +44 (20) 8735 0686 + EMail: ben@algroup.co.uk + + Geoffrey Sisson + Nominet + + + + +Laurie, et al. Expires July 2, 2005 [Page 15] +Internet-Draft nsec3 january 2005 + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + The Netherlands + + Phone: +31 (53) 485 0485 + EMail: roy.arends@telin.nl + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires July 2, 2005 [Page 16] +Internet-Draft nsec3 january 2005 + +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 (2005). 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. + + +Laurie, et al. Expires July 2, 2005 [Page 17] diff --git a/doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt new file mode 100644 index 0000000000..8cd32e316b --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt @@ -0,0 +1,728 @@ + +Network Working Group S. Josefsson +Internet-Draft January 24, 2005 +Expires: July 25, 2005 + + + Storing Certificates in the Domain Name System (DNS) + draft-ietf-dnsext-rfc2538bis-00 + +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 July 25, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + Cryptographic public key are frequently published and their + authenticity demonstrated by certificates. A CERT resource record + (RR) is defined so that such certificates and related certificate + revocation lists can be stored in the Domain Name System (DNS). + + + + + + + +Josefsson Expires July 25, 2005 [Page 1] + +Internet-Draft Storing Certificates in the DNS January 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3 + 2.1 Certificate Type Values . . . . . . . . . . . . . . . . . 4 + 2.2 Text Representation of CERT RRs . . . . . . . . . . . . . 5 + 2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6 + 3.1 Content-based X.509 CERT RR Names . . . . . . . . . . . . 7 + 3.2 Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8 + 3.3 Content-based OpenPGP CERT RR Names . . . . . . . . . . . 8 + 3.4 Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9 + 4. Performance Considerations . . . . . . . . . . . . . . . . . . 9 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 8. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 12 + A. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 12 + Intellectual Property and Copyright Statements . . . . . . . . 13 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires July 25, 2005 [Page 2] + +Internet-Draft Storing Certificates in the DNS January 2005 + + +1. Introduction + + Public keys are frequently published in the form of a certificate and + their authenticity is commonly demonstrated by certificates and + related certificate revocation lists (CRLs). A certificate is a + binding, through a cryptographic digital signature, of a public key, + a validity interval and/or conditions, and identity, authorization, + or other information. A certificate revocation list is a list of + certificates that are revoked, and incidental information, all signed + by the signer (issuer) of the revoked certificates. Examples are + X.509 certificates/CRLs in the X.500 directory system or OpenPGP + certificates/revocations used by OpenPGP software. + + Section 2 below specifies a CERT resource record (RR) for the storage + of certificates in the Domain Name System. + + Section 3 discusses appropriate owner names for CERT RRs. + + Sections 4, 5, and 6 below cover performance, IANA, and security + considerations, respectively. + + 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 [10]. + +2. The CERT Resource Record + + The CERT resource record (RR) has the structure given below. Its RR + type code is 37. + + 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 | key tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | algorithm | / + +---------------+ certificate or CRL / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + + The type field is the certificate type as define in section 2.1 + below. + + The algorithm field has the same meaning as the algorithm field in + DNSKEY and RRSIG RRs [9] except that a zero algorithm field indicates + the algorithm is unknown to a secure DNS, which may simply be the + result of the algorithm not having been standardized for DNSSEC. + + + + +Josefsson Expires July 25, 2005 [Page 3] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + The key tag field is the 16 bit value computed for the key embedded + in the certificate, using the RRSIG Key Tag Algorithm described in + Appendix B of [9]. This field is used as an efficiency measure to + pick which CERT RRs may be applicable to a particular key. The key + tag can be calculated for the key in question and then only CERT RRs + with the same key tag need be examined. However, the key must always + be transformed to the format it would have as the public key portion + of a DNSKEY RR before the key tag is computed. This is only possible + if the key is applicable to an algorithm (and limits such as key size + limits) defined for DNS security. If it is not, the algorithm field + MUST BE zero and the tag field is meaningless and SHOULD BE zero. + +2.1 Certificate Type Values + + The following values are defined or reserved: + + Value Mnemonic Certificate Type + ----- -------- ----------- ---- + 0 reserved + 1 PKIX X.509 as per PKIX + 2 SPKI SPKI certificate + 3 PGP OpenPGP packet + 4-252 available for IANA assignment + 253 URI URI private + 254 OID OID private + 255-65534 available for IANA assignment + 65535 reserved + + The PKIX type is reserved to indicate an X.509 certificate conforming + to the profile being defined by the IETF PKIX working group. The + certificate section will start with a one byte unsigned OID length + and then an X.500 OID indicating the nature of the remainder of the + certificate section (see 2.3 below). (NOTE: X.509 certificates do + not include their X.500 directory type designating OID as a prefix.) + + The SPKI type is reserved to indicate a certificate formated as to be + specified by the IETF SPKI working group. + + The PGP type indicates an OpenPGP packet as described in [5] and its + extensions and successors. Two uses are to transfer public key + material and revocation signatures. The data is binary, and MUST NOT + be encoded into an ASCII armor. An implementation SHOULD process + transferable public keys as described in section 10.1 of [5], but it + MAY handle additional OpenPGP packets. + + The URI private type indicates a certificate format defined by an + absolute URI. The certificate portion of the CERT RR MUST begin with + a null terminated URI [4] and the data after the null is the private + + + +Josefsson Expires July 25, 2005 [Page 4] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + format certificate itself. The URI SHOULD be such that a retrieval + from it will lead to documentation on the format of the certificate. + Recognition of private certificate types need not be based on URI + equality but can use various forms of pattern matching so that, for + example, subtype or version information can also be encoded into the + URI. + + The OID private type indicates a private format certificate specified + by a an ISO OID prefix. The certificate section will start with a + one byte unsigned OID length and then a BER encoded OID indicating + the nature of the remainder of the certificate section. This can be + an X.509 certificate format or some other format. X.509 certificates + that conform to the IETF PKIX profile SHOULD be indicated by the PKIX + type, not the OID private type. Recognition of private certificate + types need not be based on OID equality but can use various forms of + pattern matching such as OID prefix. + +2.2 Text Representation of CERT RRs + + The RDATA portion of a CERT RR has the type field as an unsigned + decimal integer or as a mnemonic symbol as listed in section 2.1 + above. + + The key tag field is represented as an unsigned decimal integer. + + The algorithm field is represented as an unsigned decimal integer or + a mnemonic symbol as listed in [9]. + + The certificate / CRL portion is represented in base 64 [11] and may + be divided up into any number of white space separated substrings, + down to single base 64 digits, which are concatenated to obtain the + full signature. These substrings can span lines using the standard + parenthesis. + + Note that the certificate / CRL portion may have internal sub-fields + but these do not appear in the master file representation. For + example, with type 254, there will be an OID size, an OID, and then + the certificate / CRL proper. But only a single logical base 64 + string will appear in the text representation. + +2.3 X.509 OIDs + + OIDs have been defined in connection with the X.500 directory for + user certificates, certification authority certificates, revocations + of certification authority, and revocations of user certificates. + The following table lists the OIDs, their BER encoding, and their + length prefixed hex format for use in CERT RRs: + + + + +Josefsson Expires July 25, 2005 [Page 5] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + id-at-userCertificate + = { joint-iso-ccitt(2) ds(5) at(4) 36 } + == 0x 03 55 04 24 + id-at-cACertificate + = { joint-iso-ccitt(2) ds(5) at(4) 37 } + == 0x 03 55 04 25 + id-at-authorityRevocationList + = { joint-iso-ccitt(2) ds(5) at(4) 38 } + == 0x 03 55 04 26 + id-at-certificateRevocationList + = { joint-iso-ccitt(2) ds(5) at(4) 39 } + == 0x 03 55 04 27 + + +3. Appropriate Owner Names for CERT RRs + + It is recommended that certificate CERT RRs be stored under a domain + name related to their subject, i.e., the name of the entity intended + to control the private key corresponding to the public key being + certified. It is recommended that certificate revocation list CERT + RRs be stored under a domain name related to their issuer. + + Following some of the guidelines below may result in the use in DNS + names of characters that require DNS quoting which is to use a + backslash followed by the octal representation of the ASCII code for + the character such as \000 for NULL. + + The choice of name under which CERT RRs are stored is important to + clients that perform CERT queries. In some situations, the client + may not know all information about the CERT RR object it wishes to + retrieve. For example, a client may not know the subject name of an + X.509 certificate, or the e-mail address of the owner of an OpenPGP + key. Further, the client might only know the hostname of a service + that uses X.509 certificates or the Key ID of an OpenPGP key. + + This motivate describing two different owner name guidelines. We + call the two rules content-based owner names and purpose-based owner + names. A content-based owner name is derived from the content of the + CERT RR data; for example the Subject field in an X.509 certificate + or the User ID field in OpenPGP keys. A purpose-based owner name is + selected to be a name that clients that wishes to retrieve CERT RRs + are expected to know; for example the host name of a X.509 protected + service or a Key ID of an OpenPGP key. Note that in some situations, + the content-based and purpose-based owner name can be the same; for + example when a client look up keys based on e-mail addresses for + incoming e-mail. + + Implementations SHOULD use the purpose-based owner name guidelines + + + +Josefsson Expires July 25, 2005 [Page 6] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + described in this document, and MAY use CNAMEs at content-based owner + names (or other names), pointing to the purpose-based owner name. + +3.1 Content-based X.509 CERT RR Names + + Some X.509 versions permit multiple names to be associated with + subjects and issuers under "Subject Alternate Name" and "Issuer + Alternate Name". For example, x.509v3 has such Alternate Names with + an ASN.1 specification as follows: + + GeneralName ::= CHOICE { + otherName [0] INSTANCE OF OTHER-NAME, + rfc822Name [1] IA5String, + dNSName [2] IA5String, + x400Address [3] EXPLICIT OR-ADDRESS.&Type, + directoryName [4] EXPLICIT Name, + ediPartyName [5] EDIPartyName, + uniformResourceIdentifier [6] IA5String, + iPAddress [7] OCTET STRING, + registeredID [8] OBJECT IDENTIFIER + } + + The recommended locations of CERT storage are as follows, in priority + order: + 1. If a domain name is included in the identification in the + certificate or CRL, that should be used. + 2. If a domain name is not included but an IP address is included, + then the translation of that IP address into the appropriate + inverse domain name should be used. + 3. If neither of the above it used but a URI containing a domain + name is present, that domain name should be used. + 4. If none of the above is included but a character string name is + included, then it should be treated as described for PGP names + below. + 5. If none of the above apply, then the distinguished name (DN) + should be mapped into a domain name as specified in [3]. + + Example 1: Assume that an X.509v3 certificate is issued to /CN=John + Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative + names of (a) string "John (the Man) Doe", (b) domain name john- + doe.com, and (c) uri . Then + the storage locations recommended, in priority order, would be + 1. john-doe.com, + 2. www.secure.john-doe.com, and + 3. Doe.com.xy. + + Example 2: Assume that an X.509v3 certificate is issued to /CN=James + Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names + + + +Josefsson Expires July 25, 2005 [Page 7] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + of (a) domain name widget.foo.example, (b) IPv4 address + 10.251.13.201, and (c) string "James Hacker + ". Then the storage locations + recommended, in priority order, would be + 1. widget.foo.example, + 2. 201.13.251.10.in-addr.arpa, and + 3. hacker.mail.widget.foo.example. + +3.2 Purpose-based X.509 CERT RR Names + + It is difficult for clients that do not already posses a certificate + to reconstruct the content-based owner name that should be used to + retrieve the certificate. For this reason, purpose-based owner names + are recommended in this section. Because purpose-based owner names + by nature depend on the specific scenario, or purpose, for which the + certificate will be used, there are more than one recommendation. + The following table summarize the purpose-based X.509 CERT RR owner + name guidelines. + + Scenario Owner name + ------------------------------------------------------------------- + S/MIME Certificate Standard translation of RFC 822 email address. + Example: A S/MIME certificate for + "postmaster@example.org" will use a standard + hostname translation of the owner name, + i.e. "postmaster.example.org". + + SSL Certificate Hostname of the SSL server. + + IPSEC Certificate Hostname of the IPSEC machine, and/or + for the in-addr.arpa reverse lookup IP address. + + CRLs Hostname of the issuing CA. + + +3.3 Content-based OpenPGP CERT RR Names + + OpenPGP signed keys (certificates) use a general character string + User ID [5]. However, it is recommended by OpenPGP that such names + include the RFC 2822 [7] email address of the party, as in "Leslie + Example ". If such a format is used, the CERT + should be under the standard translation of the email address into a + domain name, which would be leslie.host.example in this case. If no + RFC 2822 name can be extracted from the string name no specific + domain name is recommended. + + If a user has more than one email address, the CNAME type can be used + to reduce the amount of data stored in the DNS. For example: + + + +Josefsson Expires July 25, 2005 [Page 8] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + $ORIGIN example.org. + smith IN CERT PGP 0 0 + john.smith IN CNAME smith + js IN CNAME smith + + +3.4 Purpose-based OpenPGP CERT RR Names + + Applications that receive an OpenPGP packet but do not know the email + address of the sender will have difficulties constructing the correct + owner name, and cannot use the content-based owner name guidelines. + However, these clients commonly know the key fingerprint or the Key + ID. The key ID is found in OpenPGP packets, and the key fingerprint + is commonly found in auxilliary data that may be available. For + these situations, it is recommended to use an owner name identical to + the key fingerprint and key ID expressed in hexadecimal [11]. For + example: + + $ORIGIN example.org. + 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... + F835EDA21E94B565716F IN CERT PGP ... + B565716F IN CERT PGP ... + + If the same key material is stored at several owner names, the use of + CNAME may be used to avoid data duplication. Note that CNAME is not + always applicable, because it map an owner names to the other for all + purposes, and this may be sub-optimal when two keys with the same Key + ID are stored. + +4. Performance Considerations + + Current Domain Name System (DNS) implementations are optimized for + small transfers, typically not more than 512 bytes including + overhead. While larger transfers will perform correctly and work is + underway to make larger transfers more efficient, it is still + advisable at this time to make every reasonable effort to minimize + the size of certificates stored within the DNS. Steps that can be + taken may include using the fewest possible optional or extensions + fields and using short field values for variable length fields that + must be included. + + The RDATA field in the DNS protocol may only hold data of size 65535 + octets (64kb) or less. This means that each CERT RR cannot contain + more than 64kb worth of payload, even if the corresponding + certificate or certificate revocation list is larger. This document + do not address this limitation. + + + + + +Josefsson Expires July 25, 2005 [Page 9] + +Internet-Draft Storing Certificates in the DNS January 2005 + + +5. Acknowledgements + + The majority of this document is copied verbatim from RFC 2538, by + Donald Eastlake 3rd and Olafur Gudmundsson. + + The author wishes to thank David Shaw and Michael Graff for their + contributions to the earlier work that motivated this revised + document. + + Florian Weimer suggested to clarify wording regarding what data can + be stored in RRDATA portion of OpenPGP CERT RRs, and that the URI + type may include hashes to secure the indirection. Olivier Dubuisson + confirmed that the X.509 OID were indeed correct. + +6. Security Considerations + + By definition, certificates contain their own authenticating + signature. Thus it is reasonable to store certificates in non-secure + DNS zones or to retrieve certificates from DNS with DNS security + checking not implemented or deferred for efficiency. The results MAY + be trusted if the certificate chain is verified back to a known + trusted key and this conforms with the user's security policy. + + Alternatively, if certificates are retrieved from a secure DNS zone + with DNS security checking enabled and are verified by DNS security, + the key within the retrieved certificate MAY be trusted without + verifying the certificate chain if this conforms with the user's + security policy. + + When the URI type is used, it should be understood that is introduce + an additional indirection that may allow for a new attack vector. + One method to secure that indirection is to include a hash of the + certificate in the URI itself. + + CERT RRs are not used in connection with securing the DNS security + additions so there are no security considerations related to CERT RRs + and securing the DNS itself. + +7. IANA Considerations + + Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can + only be assigned by an IETF standards action [6]. This document + assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE. Certificate + types 0x0100 through 0xFEFF are assigned through IETF Consensus [6] + based on RFC documentation of the certificate type. The availability + of private types under 0x00FD and 0x00FE should satisfy most + requirements for proprietary or private types. + + + + +Josefsson Expires July 25, 2005 [Page 10] + +Internet-Draft Storing Certificates in the DNS January 2005 + + +8. Changes since RFC 2538 + + 1. Editorial changes to conform with new document requirements, + including splitting reference section into two parts and updating + the references to point at latest versions, and to add some + additional references. + 2. Improve terminology. For example replace "PGP" with "OpenPGP", + to align with RFC 2440. + 3. In section 2.1, clarify that OpenPGP public key data are binary, + not the ASCII armored format, and reference 10.1 in RFC 2440 on + how to deal with OpenPGP keys, and acknowledge that + implementations may handle additional packet types. + 4. Clarify that integers in the representation format are decimal. + 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis + terminology. Improve reference for Key Tag Algorithm + calculations. + 6. Add examples that suggest use of CNAME to reduce bandwidth. + 7. In section 3, appended the last paragraphs that discuss + "content-based" vs "purpose-based" owner names. Add section 3.2 + for purpose-based X.509 CERT owner names, and section 3.4 for + purpose-based OpenPGP CERT owner names. + 8. Added size considerations. + +9. References + +9.1 Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, + "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, + January 1998. + + [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource + Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP + Message Format", RFC 2440, November 1998. + + [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. + + + + +Josefsson Expires July 25, 2005 [Page 11] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [9] Arends, R., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + +9.2 Informative References + + [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", + RFC 3548, July 2003. + + +Author's Address + + Simon Josefsson + + EMail: simon@josefsson.org + +Appendix A. Copying conditions + + Regarding the portion of this document that was written by Simon + Josefsson ("the author", for the remainder of this section), the + author makes no guarantees and is not responsible for any damage + resulting from its use. The author grants irrevocable permission to + anyone to use, modify, and distribute it in any way that does not + diminish the rights of anyone else to use, modify, and distribute it, + provided that redistributed derivative works do not contain + misleading author or version information. Derivative works need not + be licensed under similar terms. + + + + + + + + + + + + + + + + +Josefsson Expires July 25, 2005 [Page 12] + +Internet-Draft Storing Certificates in the DNS January 2005 + + +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 (2005). 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. + + + + +Josefsson Expires July 25, 2005 [Page 13] + + From 3d348d8a0412791fd51d642f856794a2db2acf50 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 28 Jan 2005 23:34:38 +0000 Subject: [PATCH 061/130] newcopyrights --- util/copyrights | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util/copyrights b/util/copyrights index eab3c76a6b..aa4b11052f 100644 --- a/util/copyrights +++ b/util/copyrights @@ -1853,7 +1853,7 @@ ./lib/dns/tkey.c C 1999,2000,2001,2003,2004 ./lib/dns/tsig.c C 1999,2000,2001,2002,2004 ./lib/dns/ttl.c C 1999,2000,2001,2004 -./lib/dns/validator.c C 2000,2001,2002,2003,2004 +./lib/dns/validator.c C 2000,2001,2002,2003,2004,2005 ./lib/dns/version.c C 1998,1999,2000,2001,2004 ./lib/dns/view.c C 1999,2000,2001,2002,2003,2004,2005 ./lib/dns/win32/DLLMain.c C 2001,2004 From f93d6e86ded924cb23d80a6d45a4c830b57984dd Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 1 Feb 2005 05:35:00 +0000 Subject: [PATCH 062/130] placeholder --- CHANGES | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/CHANGES b/CHANGES index a8e4f024e7..1341726bed 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,9 @@ +1807. [placeholder] rt13526 + +1806. [placeholder] rt13501 + +1805. [placeholder] rt13501 + 1804. [placeholder] rt10114 1803. [placeholder] rt13483 From 2a2e9c7a1a8cded637be17f32dc1bbdef519ca81 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 1 Feb 2005 06:08:38 +0000 Subject: [PATCH 063/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 1341726bed..679d1b3ac3 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1808. [placeholder] rt13511 + 1807. [placeholder] rt13526 1806. [placeholder] rt13501 From 28e36fcc1eea8b5283aa33d3a6d21d42df8fdaf2 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 2 Feb 2005 03:53:14 +0000 Subject: [PATCH 064/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 679d1b3ac3..deb5105dab 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1809. [placeholder] rt13463 + 1808. [placeholder] rt13511 1807. [placeholder] rt13526 From cc4eef2a533c338310738f57898845784ce48433 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 2 Feb 2005 05:05:16 +0000 Subject: [PATCH 065/130] gcc-3.3.5 powerpc generates incorrect code at -02 --- README | 1 + 1 file changed, 1 insertion(+) diff --git a/README b/README index 73715ce09d..63a6732994 100644 --- a/README +++ b/README @@ -295,6 +295,7 @@ Building * gcc-3.2.1 and gcc-3.1.1 is known to cause problems with solaris-x86. * gcc prior to gcc-3.2.3 ultrasparc generates incorrect code at -02. + * gcc-3.3.5 powerpc generates incorrect code at -02. A limited test suite can be run with "make test". Many of the tests require you to configure a set of virtual IP addresses From 91c0a631bb30835d64f309e3bfd8061f461351d7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tatuya=20JINMEI=20=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= Date: Thu, 3 Feb 2005 02:52:53 +0000 Subject: [PATCH 066/130] forgot destroing the acache entry lock in destroy_entry(), causing memory leak. [RT #13533] (I won't update the CHANGES list, since it's an "internal" report, and this code has never been available publically) --- lib/dns/acache.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/dns/acache.c b/lib/dns/acache.c index 79d2113833..1d2f6a0a06 100644 --- a/lib/dns/acache.c +++ b/lib/dns/acache.c @@ -14,7 +14,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: acache.c,v 1.6 2004/12/29 22:42:57 marka Exp $ */ +/* $Id: acache.c,v 1.7 2005/02/03 02:52:53 jinmei Exp $ */ #include @@ -352,6 +352,8 @@ destroy_entry(dns_acacheentry_t *entry) { */ clear_entry(acache, entry); + DESTROYLOCK(&entry->lock); + isc_mem_put(acache->mctx, entry, sizeof(*entry)); dns_acache_detach(&acache); From 5cf146c586f69af7c65e4a4f612ae3ef6c9cf8de Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 3 Feb 2005 05:07:35 +0000 Subject: [PATCH 067/130] 1808. [bug] zone.c:notify_zone() contained a race condition, zone->db could change underneath it. [RT #13511] --- CHANGES | 3 ++- lib/dns/zone.c | 25 ++++++++++++++++--------- 2 files changed, 18 insertions(+), 10 deletions(-) diff --git a/CHANGES b/CHANGES index deb5105dab..4e628031ec 100644 --- a/CHANGES +++ b/CHANGES @@ -1,6 +1,7 @@ 1809. [placeholder] rt13463 -1808. [placeholder] rt13511 +1808. [bug] zone.c:notify_zone() contained a race condition, + zone->db could change underneath it. [RT #13511] 1807. [placeholder] rt13526 diff --git a/lib/dns/zone.c b/lib/dns/zone.c index 73cae60739..7d3a664eba 100644 --- a/lib/dns/zone.c +++ b/lib/dns/zone.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.c,v 1.429 2005/01/11 23:10:05 marka Exp $ */ +/* $Id: zone.c,v 1.430 2005/02/03 05:07:35 marka Exp $ */ #include @@ -3042,6 +3042,7 @@ zone_notify(dns_zone_t *zone, isc_time_t *now) { dns_notifytype_t notifytype; unsigned int flags = 0; isc_boolean_t loggednotify = ISC_FALSE; + dns_db_t *db = NULL; REQUIRE(DNS_ZONE_VALID(zone)); @@ -3061,6 +3062,13 @@ zone_notify(dns_zone_t *zone, isc_time_t *now) { zone->type != dns_zone_master) return; + LOCK_ZONE(zone); + if (zone->db != NULL) + dns_db_attach(zone->db, &db); + UNLOCK_ZONE(zone); + if (db == NULL) + return; + origin = &zone->origin; /* @@ -3073,14 +3081,13 @@ zone_notify(dns_zone_t *zone, isc_time_t *now) { /* * Get SOA RRset. */ - dns_db_currentversion(zone->db, &version); - result = dns_db_findnode(zone->db, origin, ISC_FALSE, &node); + dns_db_currentversion(db, &version); + result = dns_db_findnode(db, origin, ISC_FALSE, &node); if (result != ISC_R_SUCCESS) goto cleanup1; dns_rdataset_init(&soardset); - result = dns_db_findrdataset(zone->db, node, version, - dns_rdatatype_soa, + result = dns_db_findrdataset(db, node, version, dns_rdatatype_soa, dns_rdatatype_none, 0, &soardset, NULL); if (result != ISC_R_SUCCESS) goto cleanup2; @@ -3137,8 +3144,7 @@ zone_notify(dns_zone_t *zone, isc_time_t *now) { */ dns_rdataset_init(&nsrdset); - result = dns_db_findrdataset(zone->db, node, version, - dns_rdatatype_ns, + result = dns_db_findrdataset(db, node, version, dns_rdatatype_ns, dns_rdatatype_none, 0, &nsrdset, NULL); if (result != ISC_R_SUCCESS) goto cleanup3; @@ -3195,9 +3201,10 @@ zone_notify(dns_zone_t *zone, isc_time_t *now) { if (dns_name_dynamic(&master)) dns_name_free(&master, zone->mctx); cleanup2: - dns_db_detachnode(zone->db, &node); + dns_db_detachnode(db, &node); cleanup1: - dns_db_closeversion(zone->db, &version, ISC_FALSE); + dns_db_closeversion(db, &version, ISC_FALSE); + dns_db_detach(&db); } /*** From 036b375184c14c1b12bd347c1f920278970f3f41 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 3 Feb 2005 23:35:23 +0000 Subject: [PATCH 068/130] newcopyrights --- util/copyrights | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util/copyrights b/util/copyrights index aa4b11052f..e573318d19 100644 --- a/util/copyrights +++ b/util/copyrights @@ -1600,7 +1600,7 @@ ./lib/bind9/win32/version.c C 1998,1999,2000,2001,2004 ./lib/dns/.cvsignore X 1999,2000,2001 ./lib/dns/Makefile.in MAKE 1998,1999,2000,2001,2002,2003,2004 -./lib/dns/acache.c C 2004 +./lib/dns/acache.c C 2004,2005 ./lib/dns/acl.c C 1999,2000,2001,2002,2004 ./lib/dns/adb.c C 1999,2000,2001,2002,2003,2004 ./lib/dns/api X 1999,2000,2001 From 07bf7b758c0d2a133a6b347414318887c268b408 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 7 Feb 2005 00:04:05 +0000 Subject: [PATCH 069/130] update copyright notice --- lib/dns/acache.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/dns/acache.c b/lib/dns/acache.c index 1d2f6a0a06..1d9491020a 100644 --- a/lib/dns/acache.c +++ b/lib/dns/acache.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 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 @@ -14,7 +14,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: acache.c,v 1.7 2005/02/03 02:52:53 jinmei Exp $ */ +/* $Id: acache.c,v 1.8 2005/02/07 00:04:05 marka Exp $ */ #include From 4296c5480dde48ea555f5916be8612e173f1edeb Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 7 Feb 2005 00:53:29 +0000 Subject: [PATCH 070/130] 1801. [func] Report differences between hints and real NS rrset and associated address records. --- CHANGES | 3 +- lib/dns/include/dns/rootns.h | 10 +- lib/dns/resolver.c | 12 +- lib/dns/rootns.c | 271 ++++++++++++++++++++++++++++++++++- 4 files changed, 290 insertions(+), 6 deletions(-) diff --git a/CHANGES b/CHANGES index 4e628031ec..9ed87b3140 100644 --- a/CHANGES +++ b/CHANGES @@ -15,7 +15,8 @@ 1802. [placeholder] rt11280 -1801. [placeholder] rt288 +1801. [func] Report differences between hints and real NS rrset + and associated address records. 1800. [bug] Changes #1719 allowed a INSIST to be triggered. [RT #13428] diff --git a/lib/dns/include/dns/rootns.h b/lib/dns/include/dns/rootns.h index 0b10c77968..ab95d16099 100644 --- a/lib/dns/include/dns/rootns.h +++ b/lib/dns/include/dns/rootns.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rootns.h,v 1.9 2004/03/05 05:09:46 marka Exp $ */ +/* $Id: rootns.h,v 1.10 2005/02/07 00:53:29 marka Exp $ */ #ifndef DNS_ROOTNS_H #define DNS_ROOTNS_H 1 @@ -30,6 +30,14 @@ isc_result_t dns_rootns_create(isc_mem_t *mctx, dns_rdataclass_t rdclass, const char *filename, dns_db_t **target); +void +dns_root_checkhints(dns_view_t *view, dns_db_t *hints, dns_db_t *db); +/* + * Reports differences between hints and the real roots. + * + * Requires view, hints and (cache) db to be valid. + */ + ISC_LANG_ENDDECLS #endif /* DNS_ROOTNS_H */ diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c index 5128c96de9..cbb2cee73e 100644 --- a/lib/dns/resolver.c +++ b/lib/dns/resolver.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: resolver.c,v 1.301 2005/01/20 00:01:46 marka Exp $ */ +/* $Id: resolver.c,v 1.302 2005/02/07 00:53:28 marka Exp $ */ #include @@ -27,6 +27,7 @@ #include #include +#include #include #include #include @@ -47,6 +48,7 @@ #include #include #include +#include #include #include @@ -5814,6 +5816,7 @@ prime_done(isc_task_t *task, isc_event_t *event) { dns_resolver_t *res; dns_fetchevent_t *fevent; dns_fetch_t *fetch; + dns_db_t *db = NULL; REQUIRE(event->ev_type == DNS_EVENT_FETCHDONE); fevent = (dns_fetchevent_t *)event; @@ -5832,6 +5835,13 @@ prime_done(isc_task_t *task, isc_event_t *event) { UNLOCK(&res->primelock); UNLOCK(&res->lock); + + if (fevent->result == ISC_R_SUCCESS && + res->view->cache != NULL && res->view->hints != NULL) { + dns_cache_attachdb(res->view->cache, &db); + dns_root_checkhints(res->view, res->view->hints, db); + dns_db_detach(&db); + } if (fevent->node != NULL) dns_db_detachnode(fevent->db, &fevent->node); diff --git a/lib/dns/rootns.c b/lib/dns/rootns.c index 36f764eddb..6acb1c95bc 100644 --- a/lib/dns/rootns.c +++ b/lib/dns/rootns.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rootns.c,v 1.26 2004/03/05 05:09:24 marka Exp $ */ +/* $Id: rootns.c,v 1.27 2005/02/07 00:53:29 marka Exp $ */ #include @@ -26,15 +26,18 @@ #include #include #include -#include #include +#include #include #include -#include +#include #include +#include #include +#include #include #include +#include static char root_ns[] = ";\n" @@ -245,3 +248,265 @@ dns_rootns_create(isc_mem_t *mctx, dns_rdataclass_t rdclass, return (result); } + +static void +report(dns_view_t *view, dns_name_t *name, isc_boolean_t missing, + dns_rdata_t *rdata) +{ + const char *viewname = "", *sep = ""; + char namebuf[DNS_NAME_FORMATSIZE]; + char typebuf[DNS_RDATATYPE_FORMATSIZE]; + char databuf[sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:123.123.123.123")]; + isc_buffer_t buffer; + isc_result_t result; + + if (strcmp(view->name, "_bind") != 0 && + strcmp(view->name, "_default") != 0) { + viewname = view->name; + sep = ": view "; + } + + dns_name_format(name, namebuf, sizeof(namebuf)); + dns_rdatatype_format(rdata->type, typebuf, sizeof(typebuf)); + isc_buffer_init(&buffer, databuf, sizeof(databuf) - 1); + result = dns_rdata_totext(rdata, NULL, &buffer); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + databuf[isc_buffer_usedlength(&buffer)] = '\0'; + + if (missing) + isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL, + DNS_LOGMODULE_HINTS, ISC_LOG_WARNING, + "checkhints%s%s: %s/%s (%s) missing from hints", + sep, viewname, namebuf, typebuf, databuf); + else + isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL, + DNS_LOGMODULE_HINTS, ISC_LOG_WARNING, + "checkhints%s%s: %s/%s (%s) extra record " + "in hints", sep, viewname, namebuf, typebuf, + databuf); +} + +static isc_boolean_t +inrrset(dns_rdataset_t *rrset, dns_rdata_t *rdata) { + isc_result_t result; + dns_rdata_t current = DNS_RDATA_INIT; + + result = dns_rdataset_first(rrset); + while (result == ISC_R_SUCCESS) { + dns_rdataset_current(rrset, ¤t); + if (dns_rdata_compare(rdata, ¤t) == 0) + return (ISC_TRUE); + dns_rdata_reset(¤t); + result = dns_rdataset_next(rrset); + } + return (ISC_FALSE); +} + +/* + * Check that the address RRsets match. + * + * Note we don't complain about missing glue records. + */ + +static void +check_address_records(dns_view_t *view, dns_db_t *hints, dns_db_t *db, + dns_name_t *name, isc_stdtime_t now) +{ + isc_result_t hresult, rresult, result; + dns_rdataset_t hintrrset, rootrrset; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_name_t *foundname; + dns_fixedname_t fixed; + + dns_rdataset_init(&hintrrset); + dns_rdataset_init(&rootrrset); + dns_fixedname_init(&fixed); + foundname = dns_fixedname_name(&fixed); + + hresult = dns_db_find(hints, name, NULL, dns_rdatatype_a, 0, + now, NULL, foundname, &hintrrset, NULL); + rresult = dns_db_find(db, name, NULL, dns_rdatatype_a, + DNS_DBFIND_GLUEOK, now, NULL, foundname, + &rootrrset, NULL); + if (hresult == ISC_R_SUCCESS && + (rresult == ISC_R_SUCCESS || rresult == DNS_R_GLUE)) { + result = dns_rdataset_first(&rootrrset); + while (result == ISC_R_SUCCESS) { + dns_rdataset_current(&rootrrset, &rdata); + if (!inrrset(&hintrrset, &rdata)) + report(view, name, ISC_TRUE, &rdata); + result = dns_rdataset_next(&rootrrset); + } + result = dns_rdataset_first(&hintrrset); + while (result == ISC_R_SUCCESS) { + dns_rdataset_current(&hintrrset, &rdata); + if (!inrrset(&rootrrset, &rdata)) + report(view, name, ISC_FALSE, &rdata); + result = dns_rdataset_next(&hintrrset); + } + } + if (hresult == ISC_R_NOTFOUND && + (rresult == ISC_R_SUCCESS || rresult == DNS_R_GLUE)) { + result = dns_rdataset_first(&rootrrset); + while (result == ISC_R_SUCCESS) { + dns_rdataset_current(&rootrrset, &rdata); + report(view, name, ISC_TRUE, &rdata); + result = dns_rdataset_next(&rootrrset); + } + } + if (dns_rdataset_isassociated(&rootrrset)) + dns_rdataset_disassociate(&rootrrset); + if (dns_rdataset_isassociated(&hintrrset)) + dns_rdataset_disassociate(&hintrrset); + + /* + * Check AAAA records. + */ + hresult = dns_db_find(hints, name, NULL, dns_rdatatype_aaaa, 0, + now, NULL, foundname, &hintrrset, NULL); + rresult = dns_db_find(db, name, NULL, dns_rdatatype_aaaa, + DNS_DBFIND_GLUEOK, now, NULL, foundname, + &rootrrset, NULL); + if (hresult == ISC_R_SUCCESS && + (rresult == ISC_R_SUCCESS || rresult == DNS_R_GLUE)) { + result = dns_rdataset_first(&rootrrset); + while (result == ISC_R_SUCCESS) { + dns_rdataset_current(&rootrrset, &rdata); + if (!inrrset(&hintrrset, &rdata)) + report(view, name, ISC_TRUE, &rdata); + dns_rdata_reset(&rdata); + result = dns_rdataset_next(&rootrrset); + } + result = dns_rdataset_first(&hintrrset); + while (result == ISC_R_SUCCESS) { + dns_rdataset_current(&hintrrset, &rdata); + if (!inrrset(&rootrrset, &rdata)) + report(view, name, ISC_FALSE, &rdata); + dns_rdata_reset(&rdata); + result = dns_rdataset_next(&hintrrset); + } + } + if (hresult == ISC_R_NOTFOUND && + (rresult == ISC_R_SUCCESS || rresult == DNS_R_GLUE)) { + result = dns_rdataset_first(&rootrrset); + while (result == ISC_R_SUCCESS) { + dns_rdataset_current(&rootrrset, &rdata); + report(view, name, ISC_TRUE, &rdata); + dns_rdata_reset(&rdata); + result = dns_rdataset_next(&rootrrset); + } + } + if (dns_rdataset_isassociated(&rootrrset)) + dns_rdataset_disassociate(&rootrrset); + if (dns_rdataset_isassociated(&hintrrset)) + dns_rdataset_disassociate(&hintrrset); +} + +void +dns_root_checkhints(dns_view_t *view, dns_db_t *hints, dns_db_t *db) { + isc_result_t result; + dns_rdata_t rdata = DNS_RDATA_INIT; + dns_rdata_ns_t ns; + dns_rdataset_t hintns, rootns; + const char *viewname = "", *sep = ""; + isc_stdtime_t now; + dns_name_t *name; + dns_fixedname_t fixed; + + REQUIRE(hints != NULL); + REQUIRE(db != NULL); + REQUIRE(view != NULL); + + isc_stdtime_get(&now); + + if (strcmp(view->name, "_bind") != 0 && + strcmp(view->name, "_default") != 0) { + viewname = view->name; + sep = ": view "; + } + + dns_rdataset_init(&hintns); + dns_rdataset_init(&rootns); + dns_fixedname_init(&fixed); + name = dns_fixedname_name(&fixed); + + result = dns_db_find(hints, dns_rootname, NULL, dns_rdatatype_ns, 0, + now, NULL, name, &hintns, NULL); + if (result != ISC_R_SUCCESS) { + isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL, + DNS_LOGMODULE_HINTS, ISC_LOG_WARNING, + "checkhints%s%s: unable to get root NS rrset " + "from hints: %s", sep, viewname, + dns_result_totext(result)); + goto cleanup; + } + + result = dns_db_find(db, dns_rootname, NULL, dns_rdatatype_ns, 0, + now, NULL, name, &rootns, NULL); + if (result != ISC_R_SUCCESS) { + isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL, + DNS_LOGMODULE_HINTS, ISC_LOG_WARNING, + "checkhints%s%s: unable to get root NS rrset " + "from cache: %s", sep, viewname, + dns_result_totext(result)); + goto cleanup; + } + + /* + * Look for missing root NS names. + */ + result = dns_rdataset_first(&rootns); + while (result == ISC_R_SUCCESS) { + dns_rdataset_current(&rootns, &rdata); + result = dns_rdata_tostruct(&rdata, &ns, NULL); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + result = in_rootns(&hintns, &ns.name); + if (result != ISC_R_SUCCESS) { + char namebuf[DNS_NAME_FORMATSIZE]; + /* missing from hints */ + dns_name_format(&ns.name, namebuf, sizeof(namebuf)); + isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL, + DNS_LOGMODULE_HINTS, ISC_LOG_WARNING, + "checkhints%s%s: unable to find root " + "NS '%s' in hints", sep, viewname, + namebuf); + } else + check_address_records(view, hints, db, &ns.name, now); + dns_rdata_reset(&rdata); + result = dns_rdataset_next(&rootns); + } + if (result != ISC_R_NOMORE) { + goto cleanup; + } + + /* + * Look for extra root NS names. + */ + result = dns_rdataset_first(&hintns); + while (result == ISC_R_SUCCESS) { + dns_rdataset_current(&hintns, &rdata); + result = dns_rdata_tostruct(&rdata, &ns, NULL); + RUNTIME_CHECK(result == ISC_R_SUCCESS); + result = in_rootns(&rootns, &ns.name); + if (result != ISC_R_SUCCESS) { + char namebuf[DNS_NAME_FORMATSIZE]; + /* extra entry in hints */ + dns_name_format(&ns.name, namebuf, sizeof(namebuf)); + isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL, + DNS_LOGMODULE_HINTS, ISC_LOG_WARNING, + "checkhints%s%s: extra NS '%s' in hints", + sep, viewname, namebuf); + } + dns_rdata_reset(&rdata); + result = dns_rdataset_next(&hintns); + } + if (result != ISC_R_NOMORE) { + goto cleanup; + } + + cleanup: + if (dns_rdataset_isassociated(&rootns)) + dns_rdataset_disassociate(&rootns); + if (dns_rdataset_isassociated(&hintns)) + dns_rdataset_disassociate(&hintns); +} From 1da87201292c454b0e5e3d3f38d9bb086196b87f Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 7 Feb 2005 23:37:54 +0000 Subject: [PATCH 071/130] newcopyrights --- util/copyrights | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/util/copyrights b/util/copyrights index e573318d19..88ff8538d2 100644 --- a/util/copyrights +++ b/util/copyrights @@ -1681,7 +1681,7 @@ ./lib/dns/include/dns/request.h C 2000,2001,2002,2004 ./lib/dns/include/dns/resolver.h C 1999,2000,2001,2003,2004 ./lib/dns/include/dns/result.h C 1998,1999,2000,2001,2002,2003,2004 -./lib/dns/include/dns/rootns.h C 1999,2000,2001,2004 +./lib/dns/include/dns/rootns.h C 1999,2000,2001,2004,2005 ./lib/dns/include/dns/sdb.h C 2000,2001,2004 ./lib/dns/include/dns/secalg.h C 1999,2000,2001,2004 ./lib/dns/include/dns/secproto.h C 1999,2000,2001,2004 @@ -1842,7 +1842,7 @@ ./lib/dns/request.c C 2000,2001,2002,2004 ./lib/dns/resolver.c C 1999,2000,2001,2002,2003,2004,2005 ./lib/dns/result.c C 1998,1999,2000,2001,2002,2003,2004 -./lib/dns/rootns.c C 1999,2000,2001,2002,2004 +./lib/dns/rootns.c C 1999,2000,2001,2002,2004,2005 ./lib/dns/sdb.c C 2000,2001,2003,2004 ./lib/dns/soa.c C 2000,2001,2004 ./lib/dns/ssu.c C 2000,2001,2003,2004 From 07b9b1c44e58319d0f00f17c63a3603593969ef4 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 7 Feb 2005 23:57:02 +0000 Subject: [PATCH 072/130] update copyright notice --- lib/dns/include/dns/rootns.h | 4 ++-- lib/dns/rootns.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/dns/include/dns/rootns.h b/lib/dns/include/dns/rootns.h index ab95d16099..5e32868d48 100644 --- a/lib/dns/include/dns/rootns.h +++ b/lib/dns/include/dns/rootns.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rootns.h,v 1.10 2005/02/07 00:53:29 marka Exp $ */ +/* $Id: rootns.h,v 1.11 2005/02/07 23:57:01 marka Exp $ */ #ifndef DNS_ROOTNS_H #define DNS_ROOTNS_H 1 diff --git a/lib/dns/rootns.c b/lib/dns/rootns.c index 6acb1c95bc..159558ac00 100644 --- a/lib/dns/rootns.c +++ b/lib/dns/rootns.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rootns.c,v 1.27 2005/02/07 00:53:29 marka Exp $ */ +/* $Id: rootns.c,v 1.28 2005/02/07 23:57:02 marka Exp $ */ #include From 65d64acb51b0655f04b165c8045d1aed556489ab Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 8 Feb 2005 01:09:50 +0000 Subject: [PATCH 073/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 9ed87b3140..f0049300c8 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1810. [placeholder] rt13212 + 1809. [placeholder] rt13463 1808. [bug] zone.c:notify_zone() contained a race condition, From 073dfc245fd921958b1ccd869ed3471f828cf283 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 8 Feb 2005 23:32:40 +0000 Subject: [PATCH 074/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index f0049300c8..97179864c9 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1811. [placeholder] rt13547 + 1810. [placeholder] rt13212 1809. [placeholder] rt13463 From 0ad024cc4272894e877e3a7896f80a2892bc703c Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 8 Feb 2005 23:51:32 +0000 Subject: [PATCH 075/130] 1806. [bug] The resolver returned the wrong result when a CNAME / DNAME was encountered when fetching glue from a secure namespace. [RT #13501] 1805. [bug] Pending status was not being cleared when DLV was active. [RT #13501] --- CHANGES | 7 +++++-- lib/dns/resolver.c | 10 +++++++++- lib/dns/validator.c | 14 ++++++++++++-- 3 files changed, 26 insertions(+), 5 deletions(-) diff --git a/CHANGES b/CHANGES index 97179864c9..82bc02e06b 100644 --- a/CHANGES +++ b/CHANGES @@ -9,9 +9,12 @@ 1807. [placeholder] rt13526 -1806. [placeholder] rt13501 +1806. [bug] The resolver returned the wrong result when a CNAME / + DNAME was encountered when fetching glue from a + secure namespace. [RT #13501] -1805. [placeholder] rt13501 +1805. [bug] Pending status was not being cleared when DLV was + active. [RT #13501] 1804. [placeholder] rt10114 diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c index cbb2cee73e..9680424404 100644 --- a/lib/dns/resolver.c +++ b/lib/dns/resolver.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: resolver.c,v 1.302 2005/02/07 00:53:28 marka Exp $ */ +/* $Id: resolver.c,v 1.303 2005/02/08 23:51:31 marka Exp $ */ #include @@ -3587,6 +3587,14 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) { fctx->validators, validator, link); } + } else if (CHAINING(rdataset)) { + if (rdataset->type == dns_rdatatype_cname) + eresult = DNS_R_CNAME; + else { + INSIST(rdataset->type == + dns_rdatatype_dname); + eresult = DNS_R_DNAME; + } } } else if (!EXTERNAL(rdataset)) { /* diff --git a/lib/dns/validator.c b/lib/dns/validator.c index ef1dc75920..612e24ef8f 100644 --- a/lib/dns/validator.c +++ b/lib/dns/validator.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: validator.c,v 1.124 2004/11/17 23:52:31 marka Exp $ */ +/* $Id: validator.c,v 1.125 2005/02/08 23:51:32 marka Exp $ */ #include @@ -2356,8 +2356,18 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) { } if (result == ISC_R_NOTFOUND) { - if (!val->havedlvsep) + if (!val->havedlvsep) { + validator_log(val, ISC_LOG_DEBUG(3), + "not beneath secure root / DLV"); + if (val->mustbesecure) { + validator_log(val, ISC_LOG_WARNING, + "must be secure failure"); + result = DNS_R_MUSTBESECURE; + goto out; + } + val->event->rdataset->trust = dns_trust_answer; return (ISC_R_SUCCESS); + } dns_name_copy(dns_fixedname_name(&val->dlvsep), dns_fixedname_name(&secroot), NULL); } else if (result != ISC_R_SUCCESS) From fde0a3f89b9c42e9e4ef9aaf8e044e6b18c4978c Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 03:38:25 +0000 Subject: [PATCH 076/130] 1812. [port] win32: IN6_IS_ADDR_UNSPECIFIED macro is incorrect. [RT #13453] --- CHANGES | 3 +++ lib/isc/win32/include/isc/ipv6.h | 4 ++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/CHANGES b/CHANGES index 82bc02e06b..d2db06b255 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,6 @@ +1812. [port] win32: IN6_IS_ADDR_UNSPECIFIED macro is incorrect. + [RT #13453] + 1811. [placeholder] rt13547 1810. [placeholder] rt13212 diff --git a/lib/isc/win32/include/isc/ipv6.h b/lib/isc/win32/include/isc/ipv6.h index db07a5299e..5e485ed770 100644 --- a/lib/isc/win32/include/isc/ipv6.h +++ b/lib/isc/win32/include/isc/ipv6.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: ipv6.h,v 1.13 2004/04/19 04:16:55 marka Exp $ */ +/* $Id: ipv6.h,v 1.14 2005/02/09 03:38:25 marka Exp $ */ #ifndef ISC_IPV6_H #define ISC_IPV6_H 1 @@ -61,7 +61,7 @@ LIBISC_EXTERNAL_DATA extern const struct in6_addr isc_in6addr_loopback; * Unspecified */ #ifndef IN6_IS_ADDR_UNSPECIFIED -#define IN6_IS_ADDR_UNSPECIFIED(a) \ +#define IN6_IS_ADDR_UNSPECIFIED(a) (\ *((u_long *)((a)->s6_addr) ) == 0 && \ *((u_long *)((a)->s6_addr) + 1) == 0 && \ *((u_long *)((a)->s6_addr) + 2) == 0 && \ From d8d02f9aecba21ccea1b11597e12548eafa0e4fc Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 04:03:44 +0000 Subject: [PATCH 077/130] newcopyrights --- util/copyrights | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util/copyrights b/util/copyrights index 88ff8538d2..4fd98d431d 100644 --- a/util/copyrights +++ b/util/copyrights @@ -2075,7 +2075,7 @@ ./lib/isc/win32/include/isc/condition.h C 1998,1999,2000,2001,2004 ./lib/isc/win32/include/isc/dir.h C 1999,2000,2001,2004 ./lib/isc/win32/include/isc/int.h C 1999,2000,2001,2004 -./lib/isc/win32/include/isc/ipv6.h C 2000,2001,2002,2004 +./lib/isc/win32/include/isc/ipv6.h C 2000,2001,2002,2004,2005 ./lib/isc/win32/include/isc/keyboard.h C 2000,2001,2004 ./lib/isc/win32/include/isc/mutex.h C 1998,1999,2000,2001,2004 ./lib/isc/win32/include/isc/net.h C 1999,2000,2001,2002,2003,2004 From 2d7fc01cb302bfb7ff10aa2fbee529389e0211f2 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 05:19:30 +0000 Subject: [PATCH 078/130] update copyright notice --- lib/dns/validator.c | 4 ++-- lib/isc/win32/include/isc/ipv6.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/dns/validator.c b/lib/dns/validator.c index 612e24ef8f..0989855cec 100644 --- a/lib/dns/validator.c +++ b/lib/dns/validator.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: validator.c,v 1.125 2005/02/08 23:51:32 marka Exp $ */ +/* $Id: validator.c,v 1.126 2005/02/09 05:19:30 marka Exp $ */ #include diff --git a/lib/isc/win32/include/isc/ipv6.h b/lib/isc/win32/include/isc/ipv6.h index 5e485ed770..3f63b97d72 100644 --- a/lib/isc/win32/include/isc/ipv6.h +++ b/lib/isc/win32/include/isc/ipv6.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: ipv6.h,v 1.14 2005/02/09 03:38:25 marka Exp $ */ +/* $Id: ipv6.h,v 1.15 2005/02/09 05:19:30 marka Exp $ */ #ifndef ISC_IPV6_H #define ISC_IPV6_H 1 From 4df7858200ca846418d92ca50bd5a1f87160e819 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 13:54:05 +0000 Subject: [PATCH 079/130] add acache --- lib/dns/win32/libdns.dsp | 8 ++++++++ lib/dns/win32/libdns.mak | 24 ++++++++++++++++++++++++ 2 files changed, 32 insertions(+) diff --git a/lib/dns/win32/libdns.dsp b/lib/dns/win32/libdns.dsp index 1571b857c6..44f76e62e7 100644 --- a/lib/dns/win32/libdns.dsp +++ b/lib/dns/win32/libdns.dsp @@ -98,6 +98,10 @@ LINK32=link.exe # PROP Default_Filter "h;hpp;hxx;hm;inl" # Begin Source File +SOURCE=..\include\dns\acache.h +# End Source File +# Begin Source File + SOURCE=..\include\dns\acl.h # End Source File # Begin Source File @@ -398,6 +402,10 @@ SOURCE=..\include\dns\zt.h # PROP Default_Filter "c" # Begin Source File +SOURCE=..\acache.c +# End Source File +# Begin Source File + SOURCE=..\acl.c # End Source File # Begin Source File diff --git a/lib/dns/win32/libdns.mak b/lib/dns/win32/libdns.mak index caee8ee8bd..8adbc13322 100644 --- a/lib/dns/win32/libdns.mak +++ b/lib/dns/win32/libdns.mak @@ -45,6 +45,7 @@ CLEAN :"libisc - Win32 ReleaseCLEAN" !ELSE CLEAN : !ENDIF + -@erase "$(INTDIR)\acache.obj" -@erase "$(INTDIR)\acl.obj" -@erase "$(INTDIR)\adb.obj" -@erase "$(INTDIR)\byaddr.obj" @@ -169,6 +170,7 @@ LINK32_FLAGS=user32.lib advapi32.lib ws2_32.lib ../../isc/win32/Release/libisc.l DEF_FILE= \ ".\libdns.def" LINK32_OBJS= \ + "$(INTDIR)\acache.obj" \ "$(INTDIR)\acl.obj" \ "$(INTDIR)\adb.obj" \ "$(INTDIR)\byaddr.obj" \ @@ -270,6 +272,8 @@ CLEAN :"libisc - Win32 DebugCLEAN" !ELSE CLEAN : !ENDIF + -@erase "$(INTDIR)\acache.obj" + -@erase "$(INTDIR)\acache.sbr" -@erase "$(INTDIR)\acl.obj" -@erase "$(INTDIR)\acl.sbr" -@erase "$(INTDIR)\adb.obj" @@ -464,6 +468,7 @@ RSC=rc.exe BSC32=bscmake.exe BSC32_FLAGS=/nologo /o"$(OUTDIR)\libdns.bsc" BSC32_SBRS= \ + "$(INTDIR)\acache.sbr" \ "$(INTDIR)\acl.sbr" \ "$(INTDIR)\adb.sbr" \ "$(INTDIR)\byaddr.sbr" \ @@ -546,6 +551,7 @@ LINK32_FLAGS=user32.lib advapi32.lib ws2_32.lib ../../isc/win32/debug/libisc.lib DEF_FILE= \ ".\libdns.def" LINK32_OBJS= \ + "$(INTDIR)\acache.obj" \ "$(INTDIR)\acl.obj" \ "$(INTDIR)\adb.obj" \ "$(INTDIR)\byaddr.obj" \ @@ -637,6 +643,24 @@ LINK32_OBJS= \ !IF "$(CFG)" == "libdns - Win32 Release" || "$(CFG)" == "libdns - Win32 Debug" +SOURCE=..\acache.c + +!IF "$(CFG)" == "libdns - Win32 Release" + + +"$(INTDIR)\acache.obj" : $(SOURCE) "$(INTDIR)" + $(CPP) $(CPP_PROJ) $(SOURCE) + + +!ELSEIF "$(CFG)" == "libdns - Win32 Debug" + + +"$(INTDIR)\acache.obj" "$(INTDIR)\acache.sbr" : $(SOURCE) "$(INTDIR)" + $(CPP) $(CPP_PROJ) $(SOURCE) + + +!ENDIF + SOURCE=..\acl.c !IF "$(CFG)" == "libdns - Win32 Release" From 8dff6ed8e0d4c1f6fe76c82d6993be3c16f57452 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 21:28:02 +0000 Subject: [PATCH 080/130] add aclconf --- lib/isccfg/win32/libisccfg.dsp | 8 ++++++++ lib/isccfg/win32/libisccfg.mak | 24 ++++++++++++++++++++++++ 2 files changed, 32 insertions(+) diff --git a/lib/isccfg/win32/libisccfg.dsp b/lib/isccfg/win32/libisccfg.dsp index 358d0d15cf..856f89ddd6 100644 --- a/lib/isccfg/win32/libisccfg.dsp +++ b/lib/isccfg/win32/libisccfg.dsp @@ -98,6 +98,10 @@ SOURCE=.\DLLMain.c # End Source File # Begin Source File +SOURCE=..\aclconf.c.c +# End Source File +# Begin Source File + SOURCE=..\log.c # End Source File # Begin Source File @@ -130,6 +134,10 @@ SOURCE=..\include\isccfg\grammar.h # End Source File # Begin Source File +SOURCE=..\include\isccfg\aclconf.c.h +# End Source File +# Begin Source File + SOURCE=..\include\isccfg\log.h # End Source File # Begin Source File diff --git a/lib/isccfg/win32/libisccfg.mak b/lib/isccfg/win32/libisccfg.mak index 56f5c3b214..4f2a50f1ba 100644 --- a/lib/isccfg/win32/libisccfg.mak +++ b/lib/isccfg/win32/libisccfg.mak @@ -50,6 +50,7 @@ CLEAN :"libisc - Win32 ReleaseCLEAN" CLEAN : !ENDIF -@erase "$(INTDIR)\DLLMain.obj" + -@erase "$(INTDIR)\aclconf.c.obj" -@erase "$(INTDIR)\log.obj" -@erase "$(INTDIR)\namedconf.obj" -@erase "$(INTDIR)\parser.obj" @@ -74,6 +75,7 @@ DEF_FILE= \ ".\libisccfg.def" LINK32_OBJS= \ "$(INTDIR)\DLLMain.obj" \ + "$(INTDIR)\aclconf.c.obj" \ "$(INTDIR)\log.obj" \ "$(INTDIR)\parser.obj" \ "$(INTDIR)\version.obj" \ @@ -110,6 +112,8 @@ CLEAN : !ENDIF -@erase "$(INTDIR)\DLLMain.obj" -@erase "$(INTDIR)\DLLMain.sbr" + -@erase "$(INTDIR)\aclconf.c.obj" + -@erase "$(INTDIR)\aclconf.c.sbr" -@erase "$(INTDIR)\log.obj" -@erase "$(INTDIR)\log.sbr" -@erase "$(INTDIR)\namedconf.obj" @@ -136,6 +140,7 @@ BSC32=bscmake.exe BSC32_FLAGS=/nologo /o"$(OUTDIR)\libisccfg.bsc" BSC32_SBRS= \ "$(INTDIR)\DLLMain.sbr" \ + "$(INTDIR)\aclconf.c.sbr" \ "$(INTDIR)\log.sbr" \ "$(INTDIR)\parser.sbr" \ "$(INTDIR)\version.sbr" \ @@ -152,6 +157,7 @@ DEF_FILE= \ ".\libisccfg.def" LINK32_OBJS= \ "$(INTDIR)\DLLMain.obj" \ + "$(INTDIR)\aclconf.c.obj" \ "$(INTDIR)\log.obj" \ "$(INTDIR)\parser.obj" \ "$(INTDIR)\version.obj" \ @@ -220,6 +226,24 @@ SOURCE=.\DLLMain.c "$(INTDIR)\DLLMain.obj" "$(INTDIR)\DLLMain.sbr" : $(SOURCE) "$(INTDIR)" +!ENDIF + +SOURCE=..\aclconf.c.c + +!IF "$(CFG)" == "libisccfg - Win32 Release" + + +"$(INTDIR)\aclconf.c.obj" : $(SOURCE) "$(INTDIR)" + $(CPP) $(CPP_PROJ) $(SOURCE) + + +!ELSEIF "$(CFG)" == "libisccfg - Win32 Debug" + + +"$(INTDIR)\aclconf.c.obj" "$(INTDIR)\aclconf.c.sbr" : $(SOURCE) "$(INTDIR)" + $(CPP) $(CPP_PROJ) $(SOURCE) + + !ENDIF SOURCE=..\log.c From 8e9872ebbe2129a5aa19c5f39b3d136f8a1cb744 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 21:45:52 +0000 Subject: [PATCH 081/130] remove extraneous .c's --- lib/isccfg/win32/libisccfg.dsp | 4 ++-- lib/isccfg/win32/libisccfg.mak | 18 +++++++++--------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/lib/isccfg/win32/libisccfg.dsp b/lib/isccfg/win32/libisccfg.dsp index 856f89ddd6..5e3658f711 100644 --- a/lib/isccfg/win32/libisccfg.dsp +++ b/lib/isccfg/win32/libisccfg.dsp @@ -98,7 +98,7 @@ SOURCE=.\DLLMain.c # End Source File # Begin Source File -SOURCE=..\aclconf.c.c +SOURCE=..\aclconf.c # End Source File # Begin Source File @@ -134,7 +134,7 @@ SOURCE=..\include\isccfg\grammar.h # End Source File # Begin Source File -SOURCE=..\include\isccfg\aclconf.c.h +SOURCE=..\include\isccfg\aclconf.h # End Source File # Begin Source File diff --git a/lib/isccfg/win32/libisccfg.mak b/lib/isccfg/win32/libisccfg.mak index 4f2a50f1ba..94a9a9fd0b 100644 --- a/lib/isccfg/win32/libisccfg.mak +++ b/lib/isccfg/win32/libisccfg.mak @@ -50,7 +50,7 @@ CLEAN :"libisc - Win32 ReleaseCLEAN" CLEAN : !ENDIF -@erase "$(INTDIR)\DLLMain.obj" - -@erase "$(INTDIR)\aclconf.c.obj" + -@erase "$(INTDIR)\aclconf.obj" -@erase "$(INTDIR)\log.obj" -@erase "$(INTDIR)\namedconf.obj" -@erase "$(INTDIR)\parser.obj" @@ -75,7 +75,7 @@ DEF_FILE= \ ".\libisccfg.def" LINK32_OBJS= \ "$(INTDIR)\DLLMain.obj" \ - "$(INTDIR)\aclconf.c.obj" \ + "$(INTDIR)\aclconf.obj" \ "$(INTDIR)\log.obj" \ "$(INTDIR)\parser.obj" \ "$(INTDIR)\version.obj" \ @@ -112,8 +112,8 @@ CLEAN : !ENDIF -@erase "$(INTDIR)\DLLMain.obj" -@erase "$(INTDIR)\DLLMain.sbr" - -@erase "$(INTDIR)\aclconf.c.obj" - -@erase "$(INTDIR)\aclconf.c.sbr" + -@erase "$(INTDIR)\aclconf.obj" + -@erase "$(INTDIR)\aclconf.sbr" -@erase "$(INTDIR)\log.obj" -@erase "$(INTDIR)\log.sbr" -@erase "$(INTDIR)\namedconf.obj" @@ -140,7 +140,7 @@ BSC32=bscmake.exe BSC32_FLAGS=/nologo /o"$(OUTDIR)\libisccfg.bsc" BSC32_SBRS= \ "$(INTDIR)\DLLMain.sbr" \ - "$(INTDIR)\aclconf.c.sbr" \ + "$(INTDIR)\aclconf.sbr" \ "$(INTDIR)\log.sbr" \ "$(INTDIR)\parser.sbr" \ "$(INTDIR)\version.sbr" \ @@ -157,7 +157,7 @@ DEF_FILE= \ ".\libisccfg.def" LINK32_OBJS= \ "$(INTDIR)\DLLMain.obj" \ - "$(INTDIR)\aclconf.c.obj" \ + "$(INTDIR)\aclconf.obj" \ "$(INTDIR)\log.obj" \ "$(INTDIR)\parser.obj" \ "$(INTDIR)\version.obj" \ @@ -228,19 +228,19 @@ SOURCE=.\DLLMain.c !ENDIF -SOURCE=..\aclconf.c.c +SOURCE=..\aclconf.c !IF "$(CFG)" == "libisccfg - Win32 Release" -"$(INTDIR)\aclconf.c.obj" : $(SOURCE) "$(INTDIR)" +"$(INTDIR)\aclconf.obj" : $(SOURCE) "$(INTDIR)" $(CPP) $(CPP_PROJ) $(SOURCE) !ELSEIF "$(CFG)" == "libisccfg - Win32 Debug" -"$(INTDIR)\aclconf.c.obj" "$(INTDIR)\aclconf.c.sbr" : $(SOURCE) "$(INTDIR)" +"$(INTDIR)\aclconf.obj" "$(INTDIR)\aclconf.sbr" : $(SOURCE) "$(INTDIR)" $(CPP) $(CPP_PROJ) $(SOURCE) From 51d912d3a5040acc0b875a9dd0b5070e1a87d126 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 21:55:23 +0000 Subject: [PATCH 082/130] still had some sec\dst references --- lib/dns/win32/libdns.dsp | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/lib/dns/win32/libdns.dsp b/lib/dns/win32/libdns.dsp index 44f76e62e7..1e238079a1 100644 --- a/lib/dns/win32/libdns.dsp +++ b/lib/dns/win32/libdns.dsp @@ -646,51 +646,51 @@ SOURCE=..\zt.c # PROP Default_Filter "c" # Begin Source File -SOURCE=..\sec\dst\dst_api.c +SOURCE=..\dst_api.c # End Source File # Begin Source File -SOURCE=..\sec\dst\dst_lib.c +SOURCE=..\dst_lib.c # End Source File # Begin Source File -SOURCE=..\sec\dst\dst_parse.c +SOURCE=..\dst_parse.c # End Source File # Begin Source File -SOURCE=..\sec\dst\dst_result.c +SOURCE=..\dst_result.c # End Source File # Begin Source File -SOURCE=..\sec\dst\gssapi_link.c +SOURCE=..\gssapi_link.c # End Source File # Begin Source File -SOURCE=..\sec\dst\gssapictx.c +SOURCE=..\gssapictx.c # End Source File # Begin Source File -SOURCE=..\sec\dst\hmac_link.c +SOURCE=..\hmac_link.c # End Source File # Begin Source File -SOURCE=..\sec\dst\key.c +SOURCE=..\key.c # End Source File # Begin Source File -SOURCE=..\sec\dst\openssl_link.c +SOURCE=..\openssl_link.c # End Source File # Begin Source File -SOURCE=..\sec\dst\openssldh_link.c +SOURCE=..\openssldh_link.c # End Source File # Begin Source File -SOURCE=..\sec\dst\openssldsa_link.c +SOURCE=..\openssldsa_link.c # End Source File # Begin Source File -SOURCE=..\sec\dst\opensslrsa_link.c +SOURCE=..\opensslrsa_link.c # End Source File # End Group # Begin Source File From f012e9e68a7bf5377f3d99fcf3489518c5428eb2 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 22:33:29 +0000 Subject: [PATCH 083/130] link against libbns --- lib/isccfg/win32/libisccfg.dsp | 4 ++-- lib/isccfg/win32/libisccfg.mak | 30 ++++++++++++++++++++++++++---- 2 files changed, 28 insertions(+), 6 deletions(-) diff --git a/lib/isccfg/win32/libisccfg.dsp b/lib/isccfg/win32/libisccfg.dsp index 5e3658f711..d0a0bf5107 100644 --- a/lib/isccfg/win32/libisccfg.dsp +++ b/lib/isccfg/win32/libisccfg.dsp @@ -54,7 +54,7 @@ BSC32=bscmake.exe # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 -# ADD LINK32 user32.lib advapi32.lib ws2_32.lib ../../isc/win32/Release/libisc.lib /nologo /dll /machine:I386 /out:"../../../Build/Release/libisccfg.dll" +# ADD LINK32 user32.lib advapi32.lib ws2_32.lib ../../dns/win32/Release/libdns.lib ../../isc/win32/Release/libisc.lib /nologo /dll /machine:I386 /out:"../../../Build/Release/libisccfg.dll" !ELSEIF "$(CFG)" == "libisccfg - Win32 Debug" @@ -81,7 +81,7 @@ BSC32=bscmake.exe # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept -# ADD LINK32 user32.lib advapi32.lib ws2_32.lib ../../isc/win32/debug/libisc.lib /nologo /dll /debug /machine:I386 /out:"../../../Build/Debug/libisccfg.dll" /pdbtype:sept +# ADD LINK32 user32.lib advapi32.lib ws2_32.lib ../../dns/win32/debug/libdns.lib ../../isc/win32/debug/libisc.lib /nologo /dll /debug /machine:I386 /out:"../../../Build/Debug/libisccfg.dll" /pdbtype:sept !ENDIF diff --git a/lib/isccfg/win32/libisccfg.mak b/lib/isccfg/win32/libisccfg.mak index 94a9a9fd0b..92f63506be 100644 --- a/lib/isccfg/win32/libisccfg.mak +++ b/lib/isccfg/win32/libisccfg.mak @@ -40,12 +40,12 @@ ALL : "..\..\..\Build\Release\libisccfg.dll" !ELSE -ALL : "libisc - Win32 Release" "..\..\..\Build\Release\libisccfg.dll" +ALL : "libdns - Win32 Release" "libisc - Win32 Release" "..\..\..\Build\Release\libisccfg.dll" !ENDIF !IF "$(RECURSE)" == "1" -CLEAN :"libisc - Win32 ReleaseCLEAN" +CLEAN :"libdns - Win32 ReleaseCLEAN" "libisc - Win32 ReleaseCLEAN" !ELSE CLEAN : !ENDIF @@ -70,7 +70,7 @@ BSC32_FLAGS=/nologo /o"$(OUTDIR)\libisccfg.bsc" BSC32_SBRS= \ LINK32=link.exe -LINK32_FLAGS=user32.lib advapi32.lib ws2_32.lib ../../isc/win32/Release/libisc.lib /nologo /dll /incremental:no /pdb:"$(OUTDIR)\libisccfg.pdb" /machine:I386 /def:".\libisccfg.def" /out:"../../../Build/Release/libisccfg.dll" /implib:"$(OUTDIR)\libisccfg.lib" +LINK32_FLAGS=user32.lib advapi32.lib ws2_32.lib ../../dns/win32/Release/libdns.lib ../../isc/win32/Release/libisc.lib /nologo /dll /incremental:no /pdb:"$(OUTDIR)\libisccfg.pdb" /machine:I386 /def:".\libisccfg.def" /out:"../../../Build/Release/libisccfg.dll" /implib:"$(OUTDIR)\libisccfg.lib" DEF_FILE= \ ".\libisccfg.def" LINK32_OBJS= \ @@ -80,6 +80,7 @@ LINK32_OBJS= \ "$(INTDIR)\parser.obj" \ "$(INTDIR)\version.obj" \ "$(INTDIR)\namedconf.obj" \ + "..\..\isc\win32\Release\libdns.lib" "..\..\isc\win32\Release\libisc.lib" "..\..\..\Build\Release\libisccfg.dll" : "$(OUTDIR)" $(DEF_FILE) $(LINK32_OBJS) @@ -152,7 +153,7 @@ BSC32_SBRS= \ << LINK32=link.exe -LINK32_FLAGS=user32.lib advapi32.lib ws2_32.lib ../../isc/win32/debug/libisc.lib /nologo /dll /incremental:yes /pdb:"$(OUTDIR)\libisccfg.pdb" /debug /machine:I386 /def:".\libisccfg.def" /out:"../../../Build/Debug/libisccfg.dll" /implib:"$(OUTDIR)\libisccfg.lib" /pdbtype:sept +LINK32_FLAGS=user32.lib advapi32.lib ws2_32.lib ../../dns/win32/debug/libdns.lib ../../isc/win32/debug/libisc.lib /nologo /dll /incremental:yes /pdb:"$(OUTDIR)\libisccfg.pdb" /debug /machine:I386 /def:".\libisccfg.def" /out:"../../../Build/Debug/libisccfg.dll" /implib:"$(OUTDIR)\libisccfg.lib" /pdbtype:sept DEF_FILE= \ ".\libisccfg.def" LINK32_OBJS= \ @@ -162,6 +163,7 @@ LINK32_OBJS= \ "$(INTDIR)\parser.obj" \ "$(INTDIR)\version.obj" \ "$(INTDIR)\namedconf.obj" \ + "..\..\isc\win32\Debug\libdns.lib" "..\..\isc\win32\Debug\libisc.lib" "..\..\..\Build\Debug\libisccfg.dll" : "$(OUTDIR)" $(DEF_FILE) $(LINK32_OBJS) @@ -318,6 +320,16 @@ SOURCE=.\version.c !IF "$(CFG)" == "libisccfg - Win32 Release" +"libdns - Win32 Release" : + cd "..\..\dns\win32" + $(MAKE) /$(MAKEFLAGS) /F ".\libdns.mak" CFG="libdns - Win32 Release" + cd "..\..\isccfg\win32" + +"libdns - Win32 ReleaseCLEAN" : + cd "..\..\dns\win32" + $(MAKE) /$(MAKEFLAGS) /F ".\libdns.mak" CFG="libdns - Win32 Release" RECURSE=1 CLEAN + cd "..\..\isccfg\win32" + "libisc - Win32 Release" : cd "..\..\isc\win32" $(MAKE) /$(MAKEFLAGS) /F ".\libisc.mak" CFG="libisc - Win32 Release" @@ -330,6 +342,16 @@ SOURCE=.\version.c !ELSEIF "$(CFG)" == "libisccfg - Win32 Debug" +"libdns - Win32 Debug" : + cd "..\..\dns\win32" + $(MAKE) /$(MAKEFLAGS) /F ".\libdns.mak" CFG="libdns - Win32 Debug" + cd "..\..\isccfg\win32" + +"libdns - Win32 DebugCLEAN" : + cd "..\..\dns\win32" + $(MAKE) /$(MAKEFLAGS) /F ".\libdns.mak" CFG="libdns - Win32 Debug" RECURSE=1 CLEAN + cd "..\..\isccfg\win32" + "libisc - Win32 Debug" : cd "..\..\isc\win32" $(MAKE) /$(MAKEFLAGS) /F ".\libisc.mak" CFG="libisc - Win32 Debug" From fb343de948d4a339889728f460a0f5fcc09b8f54 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 22:37:41 +0000 Subject: [PATCH 084/130] missing \ --- lib/isccfg/win32/libisccfg.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/isccfg/win32/libisccfg.mak b/lib/isccfg/win32/libisccfg.mak index 92f63506be..3731b103bf 100644 --- a/lib/isccfg/win32/libisccfg.mak +++ b/lib/isccfg/win32/libisccfg.mak @@ -80,7 +80,7 @@ LINK32_OBJS= \ "$(INTDIR)\parser.obj" \ "$(INTDIR)\version.obj" \ "$(INTDIR)\namedconf.obj" \ - "..\..\isc\win32\Release\libdns.lib" + "..\..\isc\win32\Release\libdns.lib" \ "..\..\isc\win32\Release\libisc.lib" "..\..\..\Build\Release\libisccfg.dll" : "$(OUTDIR)" $(DEF_FILE) $(LINK32_OBJS) From af8db42e08f3e17f1d9a2809c57b3f2bc70f6d7c Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 22:41:53 +0000 Subject: [PATCH 085/130] /isc/dns --- lib/isccfg/win32/libisccfg.mak | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/isccfg/win32/libisccfg.mak b/lib/isccfg/win32/libisccfg.mak index 3731b103bf..e17ac84a62 100644 --- a/lib/isccfg/win32/libisccfg.mak +++ b/lib/isccfg/win32/libisccfg.mak @@ -80,7 +80,7 @@ LINK32_OBJS= \ "$(INTDIR)\parser.obj" \ "$(INTDIR)\version.obj" \ "$(INTDIR)\namedconf.obj" \ - "..\..\isc\win32\Release\libdns.lib" \ + "..\..\dns\win32\Release\libdns.lib" \ "..\..\isc\win32\Release\libisc.lib" "..\..\..\Build\Release\libisccfg.dll" : "$(OUTDIR)" $(DEF_FILE) $(LINK32_OBJS) @@ -163,7 +163,7 @@ LINK32_OBJS= \ "$(INTDIR)\parser.obj" \ "$(INTDIR)\version.obj" \ "$(INTDIR)\namedconf.obj" \ - "..\..\isc\win32\Debug\libdns.lib" + "..\..\dns\win32\Debug\libdns.lib" "..\..\isc\win32\Debug\libisc.lib" "..\..\..\Build\Debug\libisccfg.dll" : "$(OUTDIR)" $(DEF_FILE) $(LINK32_OBJS) From 6b49f693596207c594c753b6b2d07ed165c491a5 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 22:46:59 +0000 Subject: [PATCH 086/130] add new functions --- lib/dns/win32/libdns.def | 13 +++++++++++++ lib/isc/win32/libisc.def | 2 ++ lib/isccfg/win32/libisccfg.def | 4 ++-- 3 files changed, 17 insertions(+), 2 deletions(-) diff --git a/lib/dns/win32/libdns.def b/lib/dns/win32/libdns.def index 6da850ec33..394a76dbfb 100644 --- a/lib/dns/win32/libdns.def +++ b/lib/dns/win32/libdns.def @@ -753,4 +753,17 @@ dns_resolver_resetmustbesecure dns_resolver_setmustbesecure dns_dumpctx_detach dns_master_dumptostreaminc +dns_acache_setdb +dns_acache_attach +dns_acache_detach +dns_acache_putdb +dns_acache_shutdown +dns_acache_cancelentry +dns_acache_createentry +dns_acache_setdb +dns_acache_setentry +dns_acache_getentry +dns_acache_attachentry +dns_acache_detachentry + diff --git a/lib/isc/win32/libisc.def b/lib/isc/win32/libisc.def index e0c7cd2c16..0ecc39e4c2 100644 --- a/lib/isc/win32/libisc.def +++ b/lib/isc/win32/libisc.def @@ -435,6 +435,8 @@ isc_timermgr_poke isc_net_probe_ipv6pktinfo isc_string_strlcat isc_string_strlcpy +isc_netaddr_prefixok +isc_sockaddr_compare ; Exported Data diff --git a/lib/isccfg/win32/libisccfg.def b/lib/isccfg/win32/libisccfg.def index ca8c11c3ce..1423a7e2e9 100644 --- a/lib/isccfg/win32/libisccfg.def +++ b/lib/isccfg/win32/libisccfg.def @@ -36,8 +36,8 @@ cfg_obj_log cfg_log_init cfg_obj_line cfg_obj_file - - +cfg_acl_fromconfig +cfg_aclconfctx_init ; Exported Data From d99ef741b7731c42e98d3d8c374b6f86aae08868 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 22:55:57 +0000 Subject: [PATCH 087/130] remove aclconf --- bin/named/win32/named.dsp | 8 -------- bin/named/win32/named.mak | 24 ------------------------ 2 files changed, 32 deletions(-) diff --git a/bin/named/win32/named.dsp b/bin/named/win32/named.dsp index 454b1edaab..4831c3ec9b 100644 --- a/bin/named/win32/named.dsp +++ b/bin/named/win32/named.dsp @@ -88,10 +88,6 @@ LINK32=link.exe # PROP Default_Filter "cpp;c;cxx;rc;def;r;odl;idl;hpj;bat" # Begin Source File -SOURCE=..\aclconf.c -# End Source File -# Begin Source File - SOURCE=..\builtin.c # End Source File # Begin Source File @@ -216,10 +212,6 @@ SOURCE=..\zoneconf.c # PROP Default_Filter "h;hpp;hxx;hm;inl" # Begin Source File -SOURCE=..\include\named\aclconf.h -# End Source File -# Begin Source File - SOURCE=..\include\named\client.h # End Source File # Begin Source File diff --git a/bin/named/win32/named.mak b/bin/named/win32/named.mak index d32c87209b..50e3ffa290 100644 --- a/bin/named/win32/named.mak +++ b/bin/named/win32/named.mak @@ -48,7 +48,6 @@ CLEAN :"libdns - Win32 ReleaseCLEAN" "libisc - Win32 ReleaseCLEAN" "libbind9 - W !ELSE CLEAN : !ENDIF - -@erase "$(INTDIR)\aclconf.obj" -@erase "$(INTDIR)\builtin.obj" -@erase "$(INTDIR)\client.obj" -@erase "$(INTDIR)\config.obj" @@ -93,7 +92,6 @@ BSC32_SBRS= \ LINK32=link.exe LINK32_FLAGS=user32.lib advapi32.lib kernel32.lib ws2_32.lib ../../../lib/isc/win32/Release/libisc.lib ../../../lib/dns/win32/Release/libdns.lib ../../../lib/isccc/win32/Release/libisccc.lib ../../../lib/lwres/win32/Release/liblwres.lib ../../../lib/isccfg/win32/Release/libisccfg.lib ../../../lib/bind9/win32/Release/libbind9.lib /nologo /subsystem:console /incremental:no /pdb:"$(OUTDIR)\named.pdb" /machine:I386 /out:"../../../Build/Release/named.exe" LINK32_OBJS= \ - "$(INTDIR)\aclconf.obj" \ "$(INTDIR)\client.obj" \ "$(INTDIR)\config.obj" \ "$(INTDIR)\control.obj" \ @@ -159,8 +157,6 @@ CLEAN :"libdns - Win32 DebugCLEAN" "libisc - Win32 DebugCLEAN" "libbind9 - Win32 !ELSE CLEAN : !ENDIF - -@erase "$(INTDIR)\aclconf.obj" - -@erase "$(INTDIR)\aclconf.sbr" -@erase "$(INTDIR)\builtin.obj" -@erase "$(INTDIR)\builtin.sbr" -@erase "$(INTDIR)\client.obj" @@ -236,7 +232,6 @@ CPP_PROJ=/nologo /MDd /W3 /Gm /GX /ZI /Od /I "./" /I "../../../" /I "../win32/in BSC32=bscmake.exe BSC32_FLAGS=/nologo /o"$(OUTDIR)\named.bsc" BSC32_SBRS= \ - "$(INTDIR)\aclconf.sbr" \ "$(INTDIR)\client.sbr" \ "$(INTDIR)\config.sbr" \ "$(INTDIR)\control.sbr" \ @@ -276,7 +271,6 @@ BSC32_SBRS= \ LINK32=link.exe LINK32_FLAGS=user32.lib advapi32.lib kernel32.lib ws2_32.lib ../../../lib/isc/win32/Debug/libisc.lib ../../../lib/dns/win32/Debug/libdns.lib ../../../lib/isccc/win32/Debug/libisccc.lib ../../../lib/lwres/win32/Debug/liblwres.lib ../../../lib/isccfg/win32/Debug/libisccfg.lib ../../../lib/bind9/win32/Debug/libbind9.lib /nologo /subsystem:console /incremental:yes /pdb:"$(OUTDIR)\named.pdb" /map:"$(INTDIR)\named.map" /debug /machine:I386 /out:"../../../Build/Debug/named.exe" /pdbtype:sept LINK32_OBJS= \ - "$(INTDIR)\aclconf.obj" \ "$(INTDIR)\client.obj" \ "$(INTDIR)\config.obj" \ "$(INTDIR)\control.obj" \ @@ -362,24 +356,6 @@ LINK32_OBJS= \ !IF "$(CFG)" == "named - Win32 Release" || "$(CFG)" == "named - Win32 Debug" -SOURCE=..\aclconf.c - -!IF "$(CFG)" == "named - Win32 Release" - - -"$(INTDIR)\aclconf.obj" : $(SOURCE) "$(INTDIR)" - $(CPP) $(CPP_PROJ) $(SOURCE) - - -!ELSEIF "$(CFG)" == "named - Win32 Debug" - - -"$(INTDIR)\aclconf.obj" "$(INTDIR)\aclconf.sbr" : $(SOURCE) "$(INTDIR)" - $(CPP) $(CPP_PROJ) $(SOURCE) - - -!ENDIF - SOURCE=..\builtin.c !IF "$(CFG)" == "named - Win32 Release" From 5a61d4774900ea2c14b71b90c9a705a3f08234be Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 23:07:30 +0000 Subject: [PATCH 088/130] add missing functions --- lib/dns/win32/libdns.def | 1138 ++++++++++++++++---------------- lib/isccfg/win32/libisccfg.def | 61 +- 2 files changed, 595 insertions(+), 604 deletions(-) diff --git a/lib/dns/win32/libdns.def b/lib/dns/win32/libdns.def index 394a76dbfb..1b458addce 100644 --- a/lib/dns/win32/libdns.def +++ b/lib/dns/win32/libdns.def @@ -3,767 +3,757 @@ LIBRARY libdns ; Exported Functions EXPORTS -dns_acl_create -dns_acl_appendelement +dns_acache_attach +dns_acache_attachentry +dns_acache_cancelentry +dns_acache_create +dns_acache_createentry +dns_acache_detach +dns_acache_detachentry +dns_acache_getentry +dns_acache_putdb +dns_acache_setcachesize +dns_acache_setcleaninginterval +dns_acache_setdb +dns_acache_setentry +dns_acache_shutdown dns_acl_any -dns_acl_none +dns_acl_appendelement dns_acl_attach +dns_acl_create dns_acl_detach -dns_aclelement_equal +dns_acl_elementmatch dns_acl_equal dns_acl_isinsecure -dns_aclenv_init +dns_acl_match +dns_acl_none +dns_aclelement_equal +dns_aclelement_match dns_aclenv_copy dns_aclenv_destroy -dns_acl_match -dns_aclelement_match -dns_adb_create +dns_aclenv_init +dns_adb_adjustsrtt dns_adb_attach -dns_adb_detach -dns_adb_whenshutdown -dns_adb_shutdown -dns_adb_createfind dns_adb_cancelfind +dns_adb_changeflags +dns_adb_create +dns_adb_createfind dns_adb_destroyfind +dns_adb_detach dns_adb_dump dns_adb_dumpfind -dns_adb_marklame -dns_adb_adjustsrtt -dns_adb_changeflags dns_adb_findaddrinfo -dns_adb_freeaddrinfo dns_adb_flush +dns_adb_freeaddrinfo +dns_adb_marklame dns_adb_setadbsize -dns_byaddr_create +dns_adb_shutdown +dns_adb_whenshutdown dns_byaddr_cancel -dns_byaddr_destroy +dns_byaddr_create dns_byaddr_createptrname -dns_cache_create +dns_byaddr_createptrname2 +dns_byaddr_destroy dns_cache_attach -dns_cache_detach dns_cache_attachdb -dns_cache_setfilename -dns_cache_load -dns_cache_dump dns_cache_clean -dns_cache_setcleaninginterval -dns_cache_setcachesize +dns_cache_create +dns_cache_detach +dns_cache_dump dns_cache_flush -dns_rdatacallbacks_init -dns_rdatacallbacks_init_stdio +dns_cache_load +dns_cache_setcachesize +dns_cache_setcleaninginterval +dns_cache_setfilename dns_cert_fromtext dns_cert_totext +dns_compress_add +dns_compress_findglobal +dns_compress_getedns +dns_compress_getmethods dns_compress_init dns_compress_invalidate -dns_compress_setmethods -dns_compress_getmethods -dns_compress_getedns -dns_compress_findglobal -dns_compress_add dns_compress_rollback -dns_decompress_init -dns_decompress_invalidate -dns_decompress_setmethods -dns_decompress_getmethods -dns_decompress_edns -dns_decompress_type -dns_db_create -dns_db_attach -dns_db_detach -dns_db_ondestroy -dns_db_iscache -dns_db_iszone -dns_db_isstub -dns_db_issecure -dns_db_origin -dns_db_class -dns_db_beginload -dns_db_endload -dns_db_load -dns_db_dump -dns_db_currentversion -dns_db_newversion -dns_db_attachversion -dns_db_closeversion -dns_db_findnode -dns_db_find -dns_db_findzonecut -dns_db_attachnode -dns_db_detachnode -dns_db_expirenode -dns_db_printnode -dns_db_createiterator -dns_db_findrdataset -dns_db_allrdatasets +dns_compress_setmethods +dns_counter_fromtext dns_db_addrdataset -dns_db_subtractrdataset +dns_db_allrdatasets +dns_db_attach +dns_db_attachnode +dns_db_attachversion +dns_db_beginload +dns_db_class +dns_db_closeversion +dns_db_create +dns_db_createiterator +dns_db_createsoatuple +dns_db_currentversion dns_db_deleterdataset +dns_db_detach +dns_db_detachnode +dns_db_diff +dns_db_dump +dns_db_endload +dns_db_expirenode +dns_db_find +dns_db_findnode +dns_db_findrdataset +dns_db_findzonecut +dns_db_getnsnode +dns_db_getsoanode dns_db_getsoaserial -dns_db_overmem -dns_db_nodecount +dns_db_iscache dns_db_ispersistent +dns_db_issecure +dns_db_isstub +dns_db_iszone +dns_db_load +dns_db_newversion +dns_db_nodecount +dns_db_ondestroy +dns_db_origin +dns_db_overmem +dns_db_printnode dns_db_register +dns_db_setnsnode +dns_db_setsoanode +dns_db_subtractrdataset dns_db_unregister +dns_dbiterator_current dns_dbiterator_destroy dns_dbiterator_first dns_dbiterator_last -dns_dbiterator_seek -dns_dbiterator_prev dns_dbiterator_next -dns_dbiterator_current -dns_dbiterator_pause dns_dbiterator_origin +dns_dbiterator_pause +dns_dbiterator_prev +dns_dbiterator_seek dns_dbiterator_setcleanmode -dns_dbtable_create -dns_dbtable_attach -dns_dbtable_detach dns_dbtable_add -dns_dbtable_remove dns_dbtable_adddefault -dns_dbtable_getdefault -dns_dbtable_removedefault +dns_dbtable_attach +dns_dbtable_create +dns_dbtable_detach dns_dbtable_find - -dns_difftuple_create -dns_difftuple_free -dns_difftuple_copy -dns_diff_init -dns_diff_clear +dns_dbtable_getdefault +dns_dbtable_remove +dns_dbtable_removedefault +dns_decompress_edns +dns_decompress_getmethods +dns_decompress_init +dns_decompress_invalidate +dns_decompress_setmethods +dns_decompress_type dns_diff_append dns_diff_appendminimal -dns_diff_sort dns_diff_apply +dns_diff_applysilently +dns_diff_clear +dns_diff_init dns_diff_load dns_diff_print -dns_dispatchmgr_create -dns_dispatchmgr_destroy -dns_dispatchmgr_setblackhole -dns_dispatchmgr_getblackhole -dns_dispatch_getudp -dns_dispatch_createtcp -dns_dispatch_attach -dns_dispatch_detach -dns_dispatch_starttcp +dns_diff_sort +dns_difftuple_copy +dns_difftuple_create +dns_difftuple_free dns_dispatch_addresponse -dns_dispatch_removeresponse -dns_dispatch_getsocket -dns_dispatch_getlocaladdress +dns_dispatch_attach dns_dispatch_cancel dns_dispatch_changeattributes +dns_dispatch_createtcp +dns_dispatch_detach +dns_dispatch_getlocaladdress +dns_dispatch_getsocket +dns_dispatch_getudp dns_dispatch_importrecv +dns_dispatch_removeresponse +dns_dispatch_starttcp +dns_dispatchmgr_create +dns_dispatchmgr_destroy +dns_dispatchmgr_getblackhole +dns_dispatchmgr_setblackhole +dns_dispatchmgr_setblackportlist +dns_dnssec_findzonekeys +dns_dnssec_findzonekeys2 dns_dnssec_keyfromrdata dns_dnssec_sign -dns_dnssec_verify -dns_dnssec_findzonekeys dns_dnssec_signmessage +dns_dnssec_verify dns_dnssec_verifymessage -dns_fwdtable_create +dns_ds_buildrdata +dns_dumpctx_detach dns_fwdtable_add -dns_fwdtable_find +dns_fwdtable_create dns_fwdtable_destroy -dns_db_createsoatuple -dns_journal_open -dns_journal_destroy +dns_fwdtable_find dns_journal_begin_transaction -dns_journal_writediff dns_journal_commit -dns_journal_writediff -dns_journal_write_transaction -dns_diff_sort -dns_journal_writediff -dns_journal_first_serial -dns_journal_last_serial -dns_journal_iter_init -dns_journal_first_rr -dns_journal_next_rr -dns_journal_iter_init dns_journal_current_rr -dns_journal_rollforward +dns_journal_destroy +dns_journal_first_rr +dns_journal_first_serial +dns_journal_iter_init +dns_journal_last_serial +dns_journal_next_rr +dns_journal_open dns_journal_print -dns_db_diff +dns_journal_rollforward +dns_journal_write_transaction +dns_journal_writediff dns_keyflags_fromtext -dns_keytable_create -dns_keytable_attach -dns_keytable_detach +dns_keynode_key dns_keytable_add +dns_keytable_attach +dns_keytable_create +dns_keytable_detach +dns_keytable_detachkeynode +dns_keytable_finddeepestmatch dns_keytable_findkeynode dns_keytable_findnextkeynode -dns_keytable_finddeepestmatch -dns_keytable_detachkeynode dns_keytable_issecuredomain -dns_keynode_key dns_lib_initmsgcat -dns_log_init -dns_log_setcontext -dns_lookup_create -dns_lookup_cancel -dns_lookup_destroy -dns_master_loadfile -dns_master_loadstream -dns_master_loadbuffer -dns_master_loadfileinc -dns_master_loadstreaminc -dns_master_loadbufferinc -dns_loadctx_detach dns_loadctx_attach dns_loadctx_cancel -dns_master_dumptostream +dns_loadctx_detach +dns_log_init +dns_log_setcontext +dns_lookup_cancel +dns_lookup_create +dns_lookup_destroy dns_master_dump -dns_master_rdatasettotext -dns_master_questiontotext -dns_rdataset_towire -dns_master_dumpnodetostream dns_master_dumpnode -dns_message_gettempname +dns_master_dumpnodetostream +dns_master_dumptostream +dns_master_dumptostreaminc +dns_master_loadbuffer +dns_master_loadbufferinc +dns_master_loadfile +dns_master_loadfileinc +dns_master_loadstream +dns_master_loadstreaminc +dns_master_questiontotext +dns_master_rdatasettotext +dns_master_stylecreate +dns_master_styledestroy +dns_message_addname +dns_message_checksig dns_message_create -dns_message_reset -dns_message_destroy -dns_message_sectiontotext -dns_message_pseudosectiontotext -dns_message_totext -dns_message_parse -dns_message_firstname -dns_message_renderbegin -dns_message_renderend -dns_message_renderchangebuffer -dns_message_renderend -dns_message_renderreserve -dns_message_renderrelease -dns_message_rendersection -dns_message_renderheader -dns_message_renderend -dns_message_renderend -dns_message_renderreset -dns_message_firstname -dns_message_nextname dns_message_currentname +dns_message_destroy dns_message_findname dns_message_findtype -dns_message_movename -dns_message_addname +dns_message_firstname +dns_message_getopt +dns_message_getquerytsig +dns_message_getrawmessage +dns_message_getsig0 +dns_message_getsig0key dns_message_gettempname dns_message_gettempoffsets dns_message_gettemprdata -dns_message_gettemprdataset dns_message_gettemprdatalist +dns_message_gettemprdataset +dns_message_gettimeadjust +dns_message_gettsig +dns_message_gettsigkey +dns_message_movename +dns_message_nextname +dns_message_parse +dns_message_peekheader +dns_message_pseudosectiontotext dns_message_puttempname dns_message_puttemprdata -dns_message_puttemprdataset dns_message_puttemprdatalist -dns_message_peekheader -dns_message_reply -dns_message_getopt -dns_message_setopt -dns_message_gettsig -dns_message_settsigkey -dns_message_gettsigkey -dns_message_setquerytsig -dns_message_getquerytsig -dns_message_getsig0 -dns_message_setsig0key -dns_message_getsig0key -dns_message_takebuffer -dns_message_signer -dns_message_checksig -dns_message_getrawmessage -dns_message_setsortorder +dns_message_puttemprdataset +dns_message_rechecksig +dns_message_renderbegin +dns_message_renderchangebuffer +dns_message_renderend +dns_message_renderheader +dns_message_renderrelease +dns_message_renderreserve +dns_message_renderreset dns_message_rendersection +dns_message_reply +dns_message_reset +dns_message_resetsig +dns_message_sectiontotext +dns_message_setopt +dns_message_setquerytsig +dns_message_setsig0key +dns_message_setsortorder dns_message_settimeadjust -dns_message_gettimeadjust -dns_name_init -dns_name_reset -dns_name_invalidate -dns_name_setbuffer -dns_name_hasbuffer -dns_name_isabsolute -dns_name_iswildcard -dns_name_hash -dns_name_fullcompare -dns_name_compare -dns_name_equal -dns_name_rdatacompare -dns_name_issubdomain -dns_name_matcheswildcard -dns_name_countlabels -dns_name_getlabel -dns_name_getlabelsequence +dns_message_settsigkey +dns_message_signer +dns_message_takebuffer +dns_message_totext dns_name_clone -dns_name_fromregion -dns_name_toregion -dns_name_fromwire -dns_name_towire -dns_name_fromtext -dns_name_totext -dns_name_tofilenametext -dns_name_downcase +dns_name_compare dns_name_concatenate -dns_name_split +dns_name_copy +dns_name_countlabels +dns_name_digest +dns_name_downcase dns_name_dup dns_name_dupwithoffsets -dns_name_free -dns_name_digest dns_name_dynamic -dns_name_print +dns_name_equal dns_name_format -dns_name_copy +dns_name_free +dns_name_fromregion +dns_name_fromtext +dns_name_fromwire +dns_name_fullcompare +dns_name_getlabel +dns_name_getlabelsequence +dns_name_hasbuffer +dns_name_hash +dns_name_init +dns_name_internalwildcard +dns_name_invalidate +dns_name_isabsolute +dns_name_issubdomain +dns_name_iswildcard +dns_name_matcheswildcard +dns_name_print +dns_name_rdatacompare +dns_name_reset +dns_name_setbuffer +dns_name_split +dns_name_tofilenametext +dns_name_toregion +dns_name_totext +dns_name_towire dns_ncache_add dns_ncache_towire -dns_nsec_buildrdata dns_nsec_build +dns_nsec_buildrdata dns_nsec_typepresent -dns_soa_getserial -dns_soa_setserial -dns_soa_getminimum -dns_peerlist_new -dns_peerlist_attach -dns_peerlist_detach -dns_peerlist_addpeer -dns_peerlist_peerbyaddr -dns_peerlist_currpeer -dns_peer_new +dns_order_add +dns_order_attach +dns_order_create +dns_order_detach +dns_order_find dns_peer_attach dns_peer_detach -dns_peer_setbogus dns_peer_getbogus - - -dns_peer_setrequestixfr -dns_peer_getrequestixfr -dns_peer_setprovideixfr -dns_peer_getprovideixfr -dns_peer_setsupportedns -dns_peer_getsupportedns -dns_peer_settransfers -dns_peer_gettransfers -dns_peer_settransferformat -dns_peer_gettransferformat -dns_peer_setkeybycharp dns_peer_getkey +dns_peer_getprovideixfr +dns_peer_getrequestixfr +dns_peer_getsupportedns +dns_peer_gettransferformat +dns_peer_gettransfers +dns_peer_new +dns_peer_setbogus dns_peer_setkey -dns_name_concatenate -dns_name_totext -dns_rbt_create +dns_peer_setkeybycharp +dns_peer_setprovideixfr +dns_peer_setrequestixfr +dns_peer_setsupportedns +dns_peer_settransferformat +dns_peer_settransfers +dns_peer_settransfersource +dns_peerlist_addpeer +dns_peerlist_attach +dns_peerlist_currpeer +dns_peerlist_detach +dns_peerlist_new +dns_peerlist_peerbyaddr +dns_portlist_add +dns_portlist_create +dns_portlist_detach dns_rbt_addname dns_rbt_addnode -dns_rbt_findname -dns_rbt_findnode +dns_rbt_create dns_rbt_deletename dns_rbt_deletenode -dns_rbt_namefromnode -dns_rbt_fullnamefromnode -dns_rbt_formatnodename -dns_rbt_nodecount dns_rbt_destroy +dns_rbt_findname +dns_rbt_findnode +dns_rbt_formatnodename +dns_rbt_fullnamefromnode +dns_rbt_namefromnode +dns_rbt_nodecount dns_rbt_printall -dns_rbtnodechain_init -dns_rbtnodechain_reset -dns_rbtnodechain_invalidate dns_rbtnodechain_current dns_rbtnodechain_first +dns_rbtnodechain_init +dns_rbtnodechain_invalidate dns_rbtnodechain_last -dns_rbtnodechain_prev dns_rbtnodechain_next +dns_rbtnodechain_prev +dns_rbtnodechain_reset dns_rcode_fromtext dns_rcode_totext -dns_tsigrcode_fromtext -dns_tsigrcode_totext -dns_rdata_init -dns_rdata_reset +dns_rdata_additionaldata +dns_rdata_checkowner dns_rdata_clone dns_rdata_compare -dns_rdata_fromregion -dns_rdata_toregion -dns_rdata_fromwire -dns_rdata_towire -dns_rdata_fromtext - -dns_rdata_totext -dns_rdata_tofmttext -dns_rdata_fromstruct -dns_rdata_tostruct -dns_rdata_freestruct -dns_rdatatype_ismeta -dns_rdatatype_issingleton -dns_rdataclass_ismeta -dns_rdatatype_isdnssec -dns_rdatatype_iszonecutauth -dns_rdatatype_isknown -dns_rdata_additionaldata -dns_rdata_digest -dns_rdatatype_questiononly -dns_rdatatype_notquestion -dns_rdatatype_attributes dns_rdata_covers -dns_rdataclass_fromtext -dns_rdataclass_totext +dns_rdata_digest +dns_rdata_freestruct +dns_rdata_fromregion +dns_rdata_fromstruct +dns_rdata_fromtext +dns_rdata_fromwire +dns_rdata_init +dns_rdata_reset +dns_rdata_tofmttext +dns_rdata_toregion +dns_rdata_tostruct +dns_rdata_totext +dns_rdata_towire +dns_rdatacallbacks_init +dns_rdatacallbacks_init_stdio dns_rdataclass_format +dns_rdataclass_fromtext +dns_rdataclass_ismeta +dns_rdataclass_totext dns_rdatalist_init dns_rdatalist_tordataset -dns_rdataset_init -dns_rdataset_invalidate -dns_rdataset_disassociate -dns_rdataset_isassociated -dns_rdataset_makequestion +dns_rdataset_additionaldata dns_rdataset_clone dns_rdataset_count -dns_rdataset_first -dns_rdataset_next dns_rdataset_current +dns_rdataset_disassociate +dns_rdataset_first +dns_rdataset_getadditional +dns_rdataset_getnoqname +dns_rdataset_init +dns_rdataset_invalidate +dns_rdataset_isassociated +dns_rdataset_makequestion +dns_rdataset_next +dns_rdataset_putadditional +dns_rdataset_setadditional dns_rdataset_totext dns_rdataset_towire dns_rdataset_towiresorted -dns_rdataset_additionaldata +dns_rdatasetiter_current dns_rdatasetiter_destroy dns_rdatasetiter_first dns_rdatasetiter_next -dns_rdatasetiter_current -dns_rdataslab_fromrdataset -dns_rdataslab_size -dns_rdataslab_merge -dns_rdataslab_subtract dns_rdataslab_equal -dns_rdatatype_fromtext -dns_rdatatype_totext +dns_rdataslab_fromrdataset +dns_rdataslab_merge +dns_rdataslab_size +dns_rdataslab_subtract +dns_rdatatype_atparent +dns_rdatatype_attributes dns_rdatatype_format -dns_requestmgr_create -dns_requestmgr_whenshutdown -dns_requestmgr_shutdown -dns_requestmgr_attach -dns_requestmgr_detach -dns_request_create -dns_request_createvia -dns_request_createraw +dns_rdatatype_fromtext +dns_rdatatype_isdnssec +dns_rdatatype_isknown +dns_rdatatype_ismeta +dns_rdatatype_issingleton +dns_rdatatype_iszonecutauth +dns_rdatatype_notquestion +dns_rdatatype_questiononly +dns_rdatatype_totext dns_request_cancel +dns_request_create +dns_request_createraw +dns_request_createvia +dns_request_createvia3 +dns_request_destroy dns_request_getresponse dns_request_usedtcp -dns_request_destroy -dns_resolver_createfetch -dns_resolver_create -dns_resolver_freeze -dns_resolver_prime -dns_resolver_whenshutdown -dns_resolver_shutdown +dns_requestmgr_attach +dns_requestmgr_create +dns_requestmgr_detach +dns_requestmgr_shutdown +dns_requestmgr_whenshutdown +dns_resolver_addalternate dns_resolver_attach -dns_resolver_detach -dns_resolver_createfetch dns_resolver_cancelfetch +dns_resolver_create +dns_resolver_createfetch dns_resolver_destroyfetch +dns_resolver_detach +dns_resolver_disable_algorithm dns_resolver_dispatchmgr dns_resolver_dispatchv4 dns_resolver_dispatchv6 +dns_resolver_freeze +dns_resolver_getlamettl +dns_resolver_getudpsize +dns_resolver_nrunning +dns_resolver_prime +dns_resolver_reset_algorithms +dns_resolver_resetmustbesecure +dns_resolver_setlamettl +dns_resolver_setmustbesecure +dns_resolver_setudpsize +dns_resolver_shutdown dns_resolver_socketmgr dns_resolver_taskmgr -dns_resolver_getlamettl -dns_resolver_setlamettl -dns_resolver_nrunning -dns_result_totext +dns_resolver_whenshutdown dns_result_register dns_result_torcode +dns_result_totext dns_rootns_create +dns_sdb_putnamedrr +dns_sdb_putrdata +dns_sdb_putrr +dns_sdb_putsoa dns_sdb_register dns_sdb_unregister -dns_sdb_putrr -dns_sdb_putnamedrr -dns_sdb_putsoa -dns_sdb_putrdata dns_secalg_fromtext dns_secalg_totext dns_secproto_fromtext dns_secproto_totext -dns_ssutable_create -dns_ssutable_attach -dns_ssutable_detach +dns_soa_getminimum +dns_soa_getserial +dns_soa_setserial dns_ssutable_addrule +dns_ssutable_attach dns_ssutable_checkrules +dns_ssutable_create +dns_ssutable_detach dns_stats_alloccounters dns_stats_freecounters -dns_tcpmsg_init -dns_tcpmsg_setmaxsize -dns_tcpmsg_readmessage dns_tcpmsg_cancelread -dns_tcpmsg_keepbuffer +dns_tcpmsg_init dns_tcpmsg_invalidate -dns_time64_fromtext +dns_tcpmsg_keepbuffer +dns_tcpmsg_readmessage +dns_tcpmsg_setmaxsize dns_time32_fromtext -dns_time64_totext dns_time32_totext +dns_time64_fromtext +dns_time64_totext dns_timer_setidle -dns_tkeyctx_create -dns_tkeyctx_destroy -dns_tkey_processquery +dns_tkey_builddeletequery dns_tkey_builddhquery dns_tkey_buildgssquery -dns_tkey_builddeletequery +dns_tkey_processdeleteresponse dns_tkey_processdhresponse dns_tkey_processgssresponse -dns_tkey_processdeleteresponse -dns_tsigkey_create -dns_tsigkey_createfromkey -dns_tsigkey_attach -dns_tsigkey_detach -dns_tsigkey_setdeleted +dns_tkey_processquery +dns_tkeyctx_create +dns_tkeyctx_destroy dns_tsig_sign dns_tsig_verify +dns_tsigkey_attach +dns_tsigkey_create +dns_tsigkey_createfromkey +dns_tsigkey_detach dns_tsigkey_find +dns_tsigkey_setdeleted dns_tsigkeyring_create dns_tsigkeyring_destroy -dns_ttl_totext -dns_counter_fromtext +dns_tsigrcode_fromtext +dns_tsigrcode_totext dns_ttl_fromtext -dns_validator_create +dns_ttl_totext dns_validator_cancel +dns_validator_create dns_validator_destroy -dns_view_create -dns_view_attach -dns_view_detach -dns_view_flushanddetach -dns_view_weakattach -dns_view_weakdetach -dns_view_createresolver -dns_view_setcache -dns_view_sethints -dns_view_setkeyring -dns_view_setdstport +dns_view_adddelegationonly dns_view_addzone -dns_view_freeze -dns_view_find -dns_view_simplefind -dns_view_findzonecut -dns_viewlist_find -dns_view_findzone -dns_view_load -dns_view_loadnew -dns_view_gettsig -dns_view_getpeertsig +dns_view_attach dns_view_checksig +dns_view_create +dns_view_createresolver +dns_view_detach dns_view_dialup dns_view_dumpdbtostream +dns_view_excludedelegationonly +dns_view_find +dns_view_findzone +dns_view_findzonecut +dns_view_flushanddetach dns_view_flushcache -dns_xfrin_create -dns_xfrin_shutdown -dns_xfrin_detach +dns_view_flushname +dns_view_freeze +dns_view_freezezones +dns_view_getpeertsig +dns_view_gettsig +dns_view_load +dns_view_loadnew +dns_view_setcache +dns_view_setdstport +dns_view_sethints +dns_view_setkeyring +dns_view_setrootdelonly +dns_view_simplefind +dns_view_weakattach +dns_view_weakdetach +dns_viewlist_find dns_xfrin_attach -dns_zone_create -dns_zone_setclass -dns_zone_getclass -dns_zone_settype -dns_zone_setview -dns_zone_getview -dns_zone_setorigin -dns_zone_getorigin -dns_zone_setfile -dns_zone_getfile -dns_zone_load +dns_xfrin_create +dns_xfrin_detach +dns_xfrin_shutdown dns_zone_attach -dns_zone_detach -dns_zone_iattach -dns_zone_idetach -dns_zone_setflag -dns_zone_getdb -dns_zone_setdbtype -dns_zone_markdirty -dns_zone_expire -dns_zone_refresh -dns_zone_flush -dns_zone_dump -dns_zone_dumptostream -dns_zone_maintenance -dns_zone_setmasters -dns_zone_setmasterswithkeys -dns_zone_setmasters -dns_zone_setalsonotify -dns_zone_unload -dns_zone_setoption - -dns_zone_getoptions -dns_zone_setminrefreshtime -dns_zone_setmaxrefreshtime -dns_zone_setminretrytime -dns_zone_setmaxretrytime -dns_zone_setxfrsource4 -dns_zone_getxfrsource4 -dns_zone_setxfrsource6 -dns_zone_getxfrsource6 -dns_zone_setnotifysrc4 -dns_zone_getnotifysrc4 -dns_zone_setnotifysrc6 -dns_zone_getnotifysrc6 -dns_zone_setnotifyacl -dns_zone_setqueryacl -dns_zone_setupdateacl -dns_zone_setforwardacl -dns_zone_setxfracl -dns_zone_getnotifyacl -dns_zone_getqueryacl -dns_zone_getupdateacl -dns_zone_getforwardacl -dns_zone_getxfracl -dns_zone_clearupdateacl +dns_zone_checknames dns_zone_clearforwardacl dns_zone_clearnotifyacl dns_zone_clearqueryacl +dns_zone_clearupdateacl dns_zone_clearxfracl -dns_zone_setchecknames +dns_zone_create +dns_zone_detach +dns_zone_dialup +dns_zone_dump +dns_zone_dumptostream +dns_zone_expire +dns_zone_first +dns_zone_flush +dns_zone_forcereload +dns_zone_forwardupdate +dns_zone_fulldumptostream dns_zone_getchecknames -dns_zone_setjournalsize -dns_zone_getjournalsize -dns_zone_notifyreceive -dns_zone_setmaxxfrin -dns_zone_getmaxxfrin -dns_zone_setmaxxfrout -dns_zone_getmaxxfrout -dns_zone_setjournal -dns_zone_getjournal -dns_zone_gettype -dns_zone_settask -dns_zone_gettask -dns_zone_notify -dns_zone_replacedb +dns_zone_getclass +dns_zone_getdb +dns_zone_getfile +dns_zone_getforwardacl dns_zone_getidlein -dns_zone_setidlein dns_zone_getidleout -dns_zone_setidleout -dns_zone_getssutable -dns_zone_setssutable +dns_zone_getjournal +dns_zone_getjournalsize +dns_zone_getkeydirectory +dns_zone_getmaxxfrin +dns_zone_getmaxxfrout dns_zone_getmctx dns_zone_getmgr -dns_zone_setsigvalidityinterval +dns_zone_getnotifyacl +dns_zone_getnotifysrc4 +dns_zone_getnotifysrc6 +dns_zone_getoptions +dns_zone_getorigin +dns_zone_getqueryacl dns_zone_getsigvalidityinterval -dns_zone_setnotifytype -dns_zone_forwardupdate -dns_zone_next -dns_zone_first -dns_zonemgr_create -dns_zonemgr_managezone -dns_zonemgr_forcemaint -dns_zonemgr_shutdown -dns_zonemgr_attach -dns_zonemgr_detach -dns_zonemgr_releasezone -dns_zonemgr_settransfersin -dns_zonemgr_getttransfersin -dns_zonemgr_settransfersperns -dns_zonemgr_getttransfersperns -dns_zonemgr_setiolimit -dns_zonemgr_getiolimit -dns_zonemgr_setserialqueryrate -dns_zonemgr_getserialqueryrate -dns_zonemgr_getcount -dns_zone_forcereload -dns_zone_isforced -dns_zone_setstatistics +dns_zone_getssutable dns_zone_getstatscounters -dns_zone_dialup -dns_zone_setdialup -dns_zone_log -dns_zonekey_iszonekey -dns_zt_create -dns_zt_mount -dns_zt_unmount -dns_zt_find -dns_zt_detach -dns_zt_flushanddetach -dns_zt_attach -dns_zt_load -dns_zt_apply -dst_lib_init -dst_lib_destroy -dst_algorithm_supported -dst_context_create -dst_context_destroy -dst_context_adddata -dst_context_sign -dst_context_verify -dst_key_computesecret -dst_key_fromfile -dst_key_fromnamedfile -dst_key_tofile -dst_key_fromdns -dst_key_todns -dst_key_frombuffer -dst_key_tobuffer -dst_key_fromgssapi -dst_key_generate -dst_key_compare -dst_key_paramcompare -dst_key_free -dst_key_name -dst_key_size -dst_key_proto -dst_key_alg -dst_key_flags -dst_key_id -dst_key_class -dst_key_isprivate -dst_key_iszonekey -dst_key_isnullkey -dst_key_buildfilename -dst_key_sigsize -dst_key_secretsize -dst_region_computeid -dst_gssapi_acquirecred -dst_gssapi_initctx -dst_gssapi_acceptctx -dst_lib_initmsgcat -dst_result_totext -dst_result_register -dns_ds_buildrdata -dns_order_create -dns_order_add -dns_order_find -dns_order_attach -dns_order_detach -dns_byaddr_createptrname2 -dns_diff_applysilently -dns_master_stylecreate -dns_master_styledestroy -dns_message_resetsig -dns_message_rechecksig -dns_rdatatype_atparent -dns_zone_name -dns_view_flushname -dns_zone_setupdatedisabled +dns_zone_gettask +dns_zone_gettype +dns_zone_getupdateacl dns_zone_getupdatedisabled -dns_zone_getkeydirectory -dns_zone_setkeydirectory -dns_dnssec_findzonekeys2 -dns_zone_fulldumptostream -dns_request_createvia3 +dns_zone_getview +dns_zone_getxfracl +dns_zone_getxfrsource4 +dns_zone_getxfrsource6 +dns_zone_iattach +dns_zone_idetach +dns_zone_isforced +dns_zone_load +dns_zone_log +dns_zone_maintenance +dns_zone_markdirty +dns_zone_name +dns_zone_next +dns_zone_notify +dns_zone_notifyreceive +dns_zone_refresh +dns_zone_replacedb +dns_zone_setalsonotify dns_zone_setaltxfrsource4 dns_zone_setaltxfrsource6 -dns_zone_checknames +dns_zone_setchecknames +dns_zone_setclass +dns_zone_setdbtype +dns_zone_setdialup +dns_zone_setfile +dns_zone_setflag +dns_zone_setforwardacl +dns_zone_setidlein +dns_zone_setidleout +dns_zone_setjournal +dns_zone_setjournalsize +dns_zone_setkeydirectory +dns_zone_setmasters +dns_zone_setmasterswithkeys +dns_zone_setmaxrefreshtime +dns_zone_setmaxretrytime +dns_zone_setmaxxfrin +dns_zone_setmaxxfrout +dns_zone_setminrefreshtime +dns_zone_setminretrytime +dns_zone_setnotifyacl +dns_zone_setnotifydelay +dns_zone_setnotifysrc4 +dns_zone_setnotifysrc6 +dns_zone_setnotifytype +dns_zone_setoption +dns_zone_setorigin +dns_zone_setqueryacl +dns_zone_setsigvalidityinterval +dns_zone_setssutable +dns_zone_setstatistics +dns_zone_settask +dns_zone_settype +dns_zone_setupdateacl +dns_zone_setupdatedisabled +dns_zone_setview +dns_zone_setxfracl +dns_zone_setxfrsource4 +dns_zone_setxfrsource6 +dns_zone_unload +dns_zonekey_iszonekey +dns_zonemgr_attach +dns_zonemgr_create +dns_zonemgr_detach +dns_zonemgr_forcemaint +dns_zonemgr_getcount +dns_zonemgr_getiolimit +dns_zonemgr_getserialqueryrate +dns_zonemgr_getttransfersin +dns_zonemgr_getttransfersperns +dns_zonemgr_managezone +dns_zonemgr_releasezone dns_zonemgr_resumexfrs -dns_portlist_add -dns_resolver_getudpsize -dns_acl_elementmatch -dns_rdata_checkowner -dns_rdataset_getnoqname -dns_portlist_detach -dns_dispatchmgr_setblackportlist -dns_portlist_create -dns_view_excludedelegationonly -dns_view_setrootdelonly -dns_resolver_reset_algorithms -dns_resolver_setudpsize -dns_peer_settransfersource -dns_resolver_disable_algorithm -dns_resolver_addalternate -dns_view_adddelegationonly -dns_resolver_resetmustbesecure -dns_resolver_setmustbesecure -dns_dumpctx_detach -dns_master_dumptostreaminc -dns_acache_setdb -dns_acache_attach -dns_acache_detach -dns_acache_putdb -dns_acache_shutdown -dns_acache_cancelentry -dns_acache_createentry -dns_acache_setdb -dns_acache_setentry -dns_acache_getentry -dns_acache_attachentry -dns_acache_detachentry - - +dns_zonemgr_setiolimit +dns_zonemgr_setserialqueryrate +dns_zonemgr_settransfersin +dns_zonemgr_settransfersperns +dns_zonemgr_shutdown +dns_zt_apply +dns_zt_attach +dns_zt_create +dns_zt_detach +dns_zt_find +dns_zt_flushanddetach +dns_zt_load +dns_zt_mount +dns_zt_unmount +dst_algorithm_supported +dst_context_adddata +dst_context_create +dst_context_destroy +dst_context_sign +dst_context_verify +dst_gssapi_acceptctx +dst_gssapi_acquirecred +dst_gssapi_initctx +dst_key_alg +dst_key_buildfilename +dst_key_class +dst_key_compare +dst_key_computesecret +dst_key_flags +dst_key_free +dst_key_frombuffer +dst_key_fromdns +dst_key_fromfile +dst_key_fromgssapi +dst_key_fromnamedfile +dst_key_generate +dst_key_id +dst_key_isnullkey +dst_key_isprivate +dst_key_iszonekey +dst_key_name +dst_key_paramcompare +dst_key_proto +dst_key_secretsize +dst_key_sigsize +dst_key_size +dst_key_tobuffer +dst_key_todns +dst_key_tofile +dst_lib_destroy +dst_lib_init +dst_lib_initmsgcat +dst_region_computeid +dst_result_register +dst_result_totext diff --git a/lib/isccfg/win32/libisccfg.def b/lib/isccfg/win32/libisccfg.def index 1423a7e2e9..22383b1030 100644 --- a/lib/isccfg/win32/libisccfg.def +++ b/lib/isccfg/win32/libisccfg.def @@ -3,41 +3,42 @@ LIBRARY libisccfg ; Exported Functions EXPORTS -cfg_parser_create -cfg_parser_setcallback -cfg_parse_file -cfg_parse_buffer -cfg_parser_destroy -cfg_obj_isvoid -cfg_obj_ismap -cfg_map_get -cfg_map_getname -cfg_obj_istuple -cfg_tuple_get -cfg_obj_isuint32 -cfg_obj_asuint32 -cfg_obj_isuint64 -cfg_obj_asuint64 -cfg_obj_isstring -cfg_obj_asstring -cfg_obj_isboolean -cfg_obj_asboolean -cfg_obj_issockaddr -cfg_obj_assockaddr -cfg_obj_isnetprefix -cfg_obj_asnetprefix -cfg_obj_islist +cfg_acl_fromconfig +cfg_aclconfctx_destroy +cfg_aclconfctx_init cfg_list_first cfg_list_next cfg_listelt_value -cfg_obj_istype -cfg_obj_destroy -cfg_obj_log cfg_log_init -cfg_obj_line +cfg_map_get +cfg_map_getname +cfg_obj_asboolean +cfg_obj_asnetprefix +cfg_obj_assockaddr +cfg_obj_asstring +cfg_obj_asuint32 +cfg_obj_asuint64 +cfg_obj_destroy cfg_obj_file -cfg_acl_fromconfig -cfg_aclconfctx_init +cfg_obj_isboolean +cfg_obj_islist +cfg_obj_ismap +cfg_obj_isnetprefix +cfg_obj_issockaddr +cfg_obj_isstring +cfg_obj_istuple +cfg_obj_istype +cfg_obj_isuint32 +cfg_obj_isuint64 +cfg_obj_isvoid +cfg_obj_line +cfg_obj_log +cfg_parse_buffer +cfg_parse_file +cfg_parser_create +cfg_parser_destroy +cfg_parser_setcallback +cfg_tuple_get ; Exported Data From 7d62f929dfac118466a36829ad7bb9c2ea72928c Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 9 Feb 2005 23:20:50 +0000 Subject: [PATCH 089/130] add missing function --- lib/dns/win32/libdns.def | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/dns/win32/libdns.def b/lib/dns/win32/libdns.def index 1b458addce..e8f5fa3a07 100644 --- a/lib/dns/win32/libdns.def +++ b/lib/dns/win32/libdns.def @@ -646,6 +646,7 @@ dns_zone_notify dns_zone_notifyreceive dns_zone_refresh dns_zone_replacedb +dns_zone_setacache dns_zone_setalsonotify dns_zone_setaltxfrsource4 dns_zone_setaltxfrsource6 From 5cf023372424c1a59fda4a994e3c85c08c26e2f1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tatuya=20JINMEI=20=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= Date: Thu, 10 Feb 2005 04:33:24 +0000 Subject: [PATCH 090/130] 1313. [placeholder] rt13505 --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index d2db06b255..62d31ce997 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1313. [placeholder] rt13505 + 1812. [port] win32: IN6_IS_ADDR_UNSPECIFIED macro is incorrect. [RT #13453] From 1ae9abe209092e1fcc681a7fde817005e5e2e3b8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tatuya=20JINMEI=20=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= Date: Thu, 10 Feb 2005 04:40:22 +0000 Subject: [PATCH 091/130] typo. (sorry) --- CHANGES | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHANGES b/CHANGES index 62d31ce997..f234543682 100644 --- a/CHANGES +++ b/CHANGES @@ -1,4 +1,4 @@ -1313. [placeholder] rt13505 +1813. [placeholder] rt13505 1812. [port] win32: IN6_IS_ADDR_UNSPECIFIED macro is incorrect. [RT #13453] From 3aca8e5bf3740bbcc3bb13dde242d7cc369abb27 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 10 Feb 2005 05:53:43 +0000 Subject: [PATCH 092/130] 1758. [func] Don't send notify messages to self. [RT #12933] --- CHANGES | 2 +- bin/named/client.c | 60 ++++++++++++++++++++++- bin/named/include/named/client.h | 10 +++- bin/named/include/named/interfacemgr.h | 5 +- bin/named/interfacemgr.c | 66 +++++++++++++++++++++++++- bin/named/zoneconf.c | 5 +- lib/dns/include/dns/types.h | 6 ++- lib/dns/include/dns/zone.h | 16 ++++++- lib/dns/win32/libdns.def | 1 + lib/dns/zone.c | 58 +++++++++++++++++++++- 10 files changed, 220 insertions(+), 9 deletions(-) diff --git a/CHANGES b/CHANGES index f234543682..0b31ccc29b 100644 --- a/CHANGES +++ b/CHANGES @@ -145,7 +145,7 @@ 1759. [bug] Named failed to startup if the OS supported IPv6 but had no IPv6 interfaces configured. [RT #12942] -1758. [placeholder] rt12933 +1758. [func] Don't send notify messages to self. [RT #12933] 1757. [func] host now can turn on memory debugging flags with '-m'. diff --git a/bin/named/client.c b/bin/named/client.c index b7533fe12d..689306a850 100644 --- a/bin/named/client.c +++ b/bin/named/client.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: client.c,v 1.222 2004/09/26 22:34:32 marka Exp $ */ +/* $Id: client.c,v 1.223 2005/02/10 05:53:41 marka Exp $ */ #include @@ -1110,6 +1110,64 @@ allowed(isc_netaddr_t *addr, dns_name_t *signer, dns_acl_t *acl) { return (ISC_FALSE); } +/* + * Callback to see if a non-recursive query coming from 'srcaddr' to + * 'destaddr', with optional key 'mykey' for class 'rdclass' would be + * delivered to 'myview'. + * + * We run this unlocked as both the view list and the interface list + * are updated when the approprite task has exclusivity. + */ +isc_boolean_t +ns_client_isself(dns_view_t *myview, dns_tsigkey_t *mykey, + isc_sockaddr_t *srcaddr, isc_sockaddr_t *dstaddr, + dns_rdataclass_t rdclass, void *arg) +{ + dns_view_t *view; + dns_tsigkey_t *key; + isc_netaddr_t netsrc; + isc_netaddr_t netdst; + + UNUSED(arg); + + if (!ns_interfacemgr_listeningon(ns_g_server->interfacemgr, dstaddr)) + return (ISC_FALSE); + + isc_netaddr_fromsockaddr(&netsrc, srcaddr); + isc_netaddr_fromsockaddr(&netdst, dstaddr); + + for (view = ISC_LIST_HEAD(ns_g_server->viewlist); + view != NULL; + view = ISC_LIST_NEXT(view, link)) { + dns_name_t *tsig = NULL; + + if (view->matchrecursiveonly) + continue; + + if (rdclass != view->rdclass) + continue; + + if (mykey != NULL) { + isc_boolean_t match; + isc_result_t result; + + tsig = &mykey->name; + result = dns_view_gettsig(view, tsig, &key); + if (result != ISC_R_SUCCESS) + continue; + match = dst_key_compare(mykey->key, key->key); + dns_tsigkey_detach(&key); + if (!match) + continue; + } + + if (allowed(&netsrc, tsig, view->matchclients) && + allowed(&netdst, tsig, view->matchdestinations)) + break; + } + return (ISC_TF(view == myview)); +} + /* * Handle an incoming request event from the socket (UDP case) * or tcpmsg (TCP case). diff --git a/bin/named/include/named/client.h b/bin/named/include/named/client.h index dbbc77ce27..9dc9d7d52a 100644 --- a/bin/named/include/named/client.h +++ b/bin/named/include/named/client.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: client.h,v 1.70 2004/07/23 02:57:27 marka Exp $ */ +/* $Id: client.h,v 1.71 2005/02/10 05:53:42 marka Exp $ */ #ifndef NAMED_CLIENT_H #define NAMED_CLIENT_H 1 @@ -334,4 +334,12 @@ ns_client_dumprecursing(FILE *f, ns_clientmgr_t *manager); * Dump the outstanding recursive queries to 'f'. */ +isc_boolean_t +ns_client_isself(dns_view_t *myview, dns_tsigkey_t *mykey, + isc_sockaddr_t *srcaddr, isc_sockaddr_t *destaddr, + dns_rdataclass_t rdclass, void *arg); +/* + * Isself callback. + */ + #endif /* NAMED_CLIENT_H */ diff --git a/bin/named/include/named/interfacemgr.h b/bin/named/include/named/interfacemgr.h index 9c4d422ef7..2e98aab3dc 100644 --- a/bin/named/include/named/interfacemgr.h +++ b/bin/named/include/named/interfacemgr.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: interfacemgr.h,v 1.27 2004/04/29 01:37:13 marka Exp $ */ +/* $Id: interfacemgr.h,v 1.28 2005/02/10 05:53:42 marka Exp $ */ #ifndef NAMED_INTERFACEMGR_H #define NAMED_INTERFACEMGR_H 1 @@ -170,4 +170,7 @@ ns_interface_shutdown(ns_interface_t *ifp); void ns_interfacemgr_dumprecursing(FILE *f, ns_interfacemgr_t *mgr); +isc_boolean_t +ns_interfacemgr_listeningon(ns_interfacemgr_t *mgr, isc_sockaddr_t *addr); + #endif /* NAMED_INTERFACEMGR_H */ diff --git a/bin/named/interfacemgr.c b/bin/named/interfacemgr.c index 3b58baa171..3cd8739e7d 100644 --- a/bin/named/interfacemgr.c +++ b/bin/named/interfacemgr.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: interfacemgr.c,v 1.78 2004/08/10 04:55:39 jinmei Exp $ */ +/* $Id: interfacemgr.c,v 1.79 2005/02/10 05:53:41 marka Exp $ */ #include @@ -50,11 +50,15 @@ struct ns_interfacemgr { ns_listenlist_t * listenon6; dns_aclenv_t aclenv; /* Localhost/localnets ACLs */ ISC_LIST(ns_interface_t) interfaces; /* List of interfaces. */ + ISC_LIST(isc_sockaddr_t) listenon; }; static void purge_old_interfaces(ns_interfacemgr_t *mgr); +static void +clearlistenon(ns_interfacemgr_t *mgr); + isc_result_t ns_interfacemgr_create(isc_mem_t *mctx, isc_taskmgr_t *taskmgr, isc_socketmgr_t *socketmgr, @@ -85,6 +89,7 @@ ns_interfacemgr_create(isc_mem_t *mctx, isc_taskmgr_t *taskmgr, mgr->listenon6 = NULL; ISC_LIST_INIT(mgr->interfaces); + ISC_LIST_INIT(mgr->listenon); /* * The listen-on lists are initially empty. @@ -117,6 +122,7 @@ ns_interfacemgr_destroy(ns_interfacemgr_t *mgr) { dns_aclenv_destroy(&mgr->aclenv); ns_listenlist_detach(&mgr->listenon4); ns_listenlist_detach(&mgr->listenon6); + clearlistenon(mgr); DESTROYLOCK(&mgr->lock); mgr->magic = 0; isc_mem_put(mgr->mctx, mgr, sizeof(*mgr)); @@ -536,6 +542,43 @@ setup_locals(ns_interfacemgr_t *mgr, isc_interface_t *interface) { return (ISC_R_SUCCESS); } +static void +setup_listenon(ns_interfacemgr_t *mgr, isc_interface_t *interface, + in_port_t port) +{ + isc_sockaddr_t *addr; + isc_sockaddr_t *old; + + addr = isc_mem_get(mgr->mctx, sizeof(*addr)); + if (addr == NULL) + return; + + isc_sockaddr_fromnetaddr(addr, &interface->address, port); + + for (old = ISC_LIST_HEAD(mgr->listenon); + old != NULL; + old = ISC_LIST_NEXT(old, link)) + if (isc_sockaddr_equal(addr, old)) + break; + + if (old != NULL) + isc_mem_put(mgr->mctx, addr, sizeof(*addr)); + else + ISC_LIST_APPEND(mgr->listenon, addr, link); +} + +static void +clearlistenon(ns_interfacemgr_t *mgr) { + isc_sockaddr_t *old; + + old = ISC_LIST_HEAD(mgr->listenon); + while (old != NULL) { + ISC_LIST_UNLINK(mgr->listenon, old, link); + isc_mem_put(mgr->mctx, old, sizeof(*old)); + old = ISC_LIST_HEAD(mgr->listenon); + } +} + static isc_result_t do_scan(ns_interfacemgr_t *mgr, ns_listenlist_t *ext_listen, isc_boolean_t verbose) @@ -552,6 +595,7 @@ do_scan(ns_interfacemgr_t *mgr, ns_listenlist_t *ext_listen, isc_sockaddr_t listen_addr; ns_interface_t *ifp; isc_boolean_t log_explicit = ISC_FALSE; + isc_boolean_t dolistenon; if (ext_listen != NULL) adjusting = ISC_TRUE; @@ -642,6 +686,7 @@ do_scan(ns_interfacemgr_t *mgr, ns_listenlist_t *ext_listen, result = clearacl(mgr->mctx, &mgr->aclenv.localnets); if (result != ISC_R_SUCCESS) goto cleanup_iter; + clearlistenon(mgr); } for (result = isc_interfaceiter_first(iter); @@ -687,6 +732,7 @@ do_scan(ns_interfacemgr_t *mgr, ns_listenlist_t *ext_listen, } ll = (family == AF_INET) ? mgr->listenon4 : mgr->listenon6; + dolistenon = ISC_TRUE; for (le = ISC_LIST_HEAD(ll->elts); le != NULL; le = ISC_LIST_NEXT(le, link)) @@ -723,6 +769,11 @@ do_scan(ns_interfacemgr_t *mgr, ns_listenlist_t *ext_listen, if (match <= 0) continue; + if (adjusting == ISC_FALSE && dolistenon == ISC_TRUE) { + setup_listenon(mgr, &interface, le->port); + dolistenon = ISC_FALSE; + } + /* * The case of "any" IPv6 address will require * special considerations later, so remember it. @@ -909,3 +960,16 @@ ns_interfacemgr_dumprecursing(FILE *f, ns_interfacemgr_t *mgr) { } UNLOCK(&mgr->lock); } + +isc_boolean_t +ns_interfacemgr_listeningon(ns_interfacemgr_t *mgr, isc_sockaddr_t *addr) { + isc_sockaddr_t *old; + + old = ISC_LIST_HEAD(mgr->listenon); + for (old = ISC_LIST_HEAD(mgr->listenon); + old != NULL; + old = ISC_LIST_NEXT(old, link)) + if (isc_sockaddr_equal(old, addr)) + return (ISC_TRUE); + return (ISC_FALSE); +} diff --git a/bin/named/zoneconf.c b/bin/named/zoneconf.c index e02427219e..cd026617ea 100644 --- a/bin/named/zoneconf.c +++ b/bin/named/zoneconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zoneconf.c,v 1.118 2005/01/11 23:10:04 marka Exp $ */ +/* $Id: zoneconf.c,v 1.119 2005/02/10 05:53:42 marka Exp $ */ #include @@ -35,6 +35,7 @@ #include #include +#include #include #include #include @@ -494,6 +495,8 @@ ns_zone_configure(cfg_obj_t *config, cfg_obj_t *vconfig, cfg_obj_t *zconfig, RETERR(dns_zone_setnotifysrc6(zone, cfg_obj_assockaddr(obj))); ns_add_reserved_dispatch(ns_g_server, cfg_obj_assockaddr(obj)); + dns_zone_setisself(zone, ns_client_isself, NULL); + RETERR(configure_zone_acl(zconfig, vconfig, config, "allow-transfer", ac, zone, dns_zone_setxfracl, diff --git a/lib/dns/include/dns/types.h b/lib/dns/include/dns/types.h index 625380b417..d64d182253 100644 --- a/lib/dns/include/dns/types.h +++ b/lib/dns/include/dns/types.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: types.h,v 1.111 2004/12/21 10:45:19 jinmei Exp $ */ +/* $Id: types.h,v 1.112 2005/02/10 05:53:43 marka Exp $ */ #ifndef DNS_TYPES_H #define DNS_TYPES_H 1 @@ -299,4 +299,8 @@ typedef void typedef int (*dns_rdatasetorderfunc_t)(dns_rdata_t *rdata, void *arg); +typedef isc_boolean_t +(*dns_isselffunc_t)(dns_view_t *, dns_tsigkey_t *, isc_sockaddr_t *, + isc_sockaddr_t *, dns_rdataclass_t, void *); + #endif /* DNS_TYPES_H */ diff --git a/lib/dns/include/dns/zone.h b/lib/dns/include/dns/zone.h index 78a3e28587..3df380b588 100644 --- a/lib/dns/include/dns/zone.h +++ b/lib/dns/include/dns/zone.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.h,v 1.131 2005/01/11 23:10:05 marka Exp $ */ +/* $Id: zone.h,v 1.132 2005/02/10 05:53:43 marka Exp $ */ #ifndef DNS_ZONE_H #define DNS_ZONE_H 1 @@ -1464,6 +1464,20 @@ dns_zone_getnotifydelay(dns_zone_t *zone); * 'zone' to be valid. */ +void +dns_zone_setisself(dns_zone_t *zone, dns_isselffunc_t isself, void *arg); +/* + * Set the isself callback function and arguement. + * + * isc_boolean_t + * isself(dns_view_t *myview, dns_tsigkey_t *mykey, isc_netaddr_t *srcaddr, + * isc_netaddr_t *destaddr, dns_rdataclass_t rdclass, void *arg); + * + * 'isself' returns ISC_TRUE if a non-recursive query from 'srcaddr' to + * 'destaddr' with optional key 'mykey' for class 'rdclass' would be + * delivered to 'myview'. + */ + ISC_LANG_ENDDECLS #endif /* DNS_ZONE_H */ diff --git a/lib/dns/win32/libdns.def b/lib/dns/win32/libdns.def index e8f5fa3a07..f4be1fd88f 100644 --- a/lib/dns/win32/libdns.def +++ b/lib/dns/win32/libdns.def @@ -659,6 +659,7 @@ dns_zone_setflag dns_zone_setforwardacl dns_zone_setidlein dns_zone_setidleout +dns_zone_setisself dns_zone_setjournal dns_zone_setjournalsize dns_zone_setkeydirectory diff --git a/lib/dns/zone.c b/lib/dns/zone.c index 7d3a664eba..9dcea3dae1 100644 --- a/lib/dns/zone.c +++ b/lib/dns/zone.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.c,v 1.430 2005/02/03 05:07:35 marka Exp $ */ +/* $Id: zone.c,v 1.431 2005/02/10 05:53:42 marka Exp $ */ #include @@ -223,6 +223,8 @@ struct dns_zone { */ isc_uint64_t *counters; isc_uint32_t notifydelay; + dns_isselffunc_t isself; + void *isselfarg; }; #define DNS_ZONE_FLAG(z,f) (ISC_TF(((z)->flags & (f)) != 0)) @@ -586,6 +588,8 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) { zone->statelist = NULL; zone->counters = NULL; zone->notifydelay = 5; + zone->isself = NULL; + zone->isselfarg = NULL; zone->magic = ZONE_MAGIC; @@ -2741,6 +2745,46 @@ notify_isqueued(dns_zone_t *zone, dns_name_t *name, isc_sockaddr_t *addr) { return (ISC_FALSE); } +static isc_boolean_t +notify_isself(dns_zone_t *zone, isc_sockaddr_t *dst) { + dns_tsigkey_t *key = NULL; + isc_sockaddr_t src; + isc_sockaddr_t any; + isc_boolean_t isself; + isc_netaddr_t dstaddr; + + if (zone->view == NULL || zone->isself == NULL) + return (ISC_FALSE); + + switch (isc_sockaddr_pf(dst)) { + case PF_INET: + src = zone->notifysrc4; + isc_sockaddr_any(&any); + break; + case PF_INET6: + src = zone->notifysrc6; + isc_sockaddr_any6(&any); + break; + default: + return (ISC_FALSE); + } + + /* + * When sending from any the kernel will assign a source address + * that matches the destination address. + */ + if (isc_sockaddr_eqaddr(&any, &src)) + src = *dst; + + isc_netaddr_fromsockaddr(&dstaddr, dst); + (void)dns_view_getpeertsig(zone->view, &dstaddr, &key); + isself = (zone->isself)(zone->view, key, &src, dst, zone->rdclass, + zone->isselfarg); + if (key != NULL) + dns_tsigkey_detach(&key); + return (isself); +} + static void notify_destroy(dns_notify_t *notify, isc_boolean_t locked) { isc_mem_t *mctx; @@ -2988,6 +3032,8 @@ notify_send(dns_notify_t *notify) { dst = ai->sockaddr; if (notify_isqueued(notify->zone, NULL, &dst)) continue; + if (notify_isself(notify->zone, &dst)) + continue; new = NULL; result = notify_create(notify->mctx, (notify->flags & DNS_NOTIFY_NOSOA), @@ -7013,6 +7059,16 @@ dns_zone_checknames(dns_zone_t *zone, dns_name_t *name, dns_rdata_t *rdata) { return (ISC_R_SUCCESS); } +void +dns_zone_setisself(dns_zone_t *zone, dns_isselffunc_t isself, void *arg) { + REQUIRE(DNS_ZONE_VALID(zone)); + + LOCK_ZONE(zone); + zone->isself = isself; + zone->isselfarg = arg; + UNLOCK_ZONE(zone); +} + void dns_zone_setnotifydelay(dns_zone_t *zone, isc_uint32_t delay) { REQUIRE(DNS_ZONE_VALID(zone)); From 413988c8166976498250c0ebb2e3a645d0366bd3 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 10 Feb 2005 23:35:53 +0000 Subject: [PATCH 093/130] newcopyrights --- util/copyrights | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/util/copyrights b/util/copyrights index 4fd98d431d..26c94f4ce3 100644 --- a/util/copyrights +++ b/util/copyrights @@ -89,17 +89,17 @@ ./bin/named/Makefile.in MAKE 1998,1999,2000,2001,2002,2004,2005 ./bin/named/aclconf.c C 1999,2000,2001,2002,2004 ./bin/named/builtin.c C 2001,2002,2003,2004 -./bin/named/client.c C 1999,2000,2001,2002,2003,2004 +./bin/named/client.c C 1999,2000,2001,2002,2003,2004,2005 ./bin/named/config.c C 2001,2002,2003,2004,2005 ./bin/named/control.c C 2001,2002,2003,2004 ./bin/named/controlconf.c C 2001,2002,2003,2004,2005 ./bin/named/include/named/aclconf.h C 1999,2000,2001,2004 ./bin/named/include/named/builtin.h C 2001,2004 -./bin/named/include/named/client.h C 1999,2000,2001,2002,2003,2004 +./bin/named/include/named/client.h C 1999,2000,2001,2002,2003,2004,2005 ./bin/named/include/named/config.h C 2001,2002,2004 ./bin/named/include/named/control.h C 2001,2002,2003,2004,2005 ./bin/named/include/named/globals.h C 1999,2000,2001,2002,2003,2004 -./bin/named/include/named/interfacemgr.h C 1999,2000,2001,2002,2004 +./bin/named/include/named/interfacemgr.h C 1999,2000,2001,2002,2004,2005 ./bin/named/include/named/listenlist.h C 2000,2001,2004 ./bin/named/include/named/log.h C 1999,2000,2001,2002,2004 ./bin/named/include/named/logconf.h C 1999,2000,2001,2004 @@ -118,7 +118,7 @@ ./bin/named/include/named/update.h C 1999,2000,2001,2004 ./bin/named/include/named/xfrout.h C 1999,2000,2001,2004 ./bin/named/include/named/zoneconf.h C 1999,2000,2001,2002,2004,2005 -./bin/named/interfacemgr.c C 1999,2000,2001,2002,2004 +./bin/named/interfacemgr.c C 1999,2000,2001,2002,2004,2005 ./bin/named/listenlist.c C 2000,2001,2004 ./bin/named/log.c C 1999,2000,2001,2002,2004 ./bin/named/logconf.c C 1999,2000,2001,2004 @@ -1694,7 +1694,7 @@ ./lib/dns/include/dns/tkey.h C 1999,2000,2001,2004 ./lib/dns/include/dns/tsig.h C 1999,2000,2001,2002,2004 ./lib/dns/include/dns/ttl.h C 1999,2000,2001,2004 -./lib/dns/include/dns/types.h C 1998,1999,2000,2001,2002,2003,2004 +./lib/dns/include/dns/types.h C 1998,1999,2000,2001,2002,2003,2004,2005 ./lib/dns/include/dns/validator.h C 2000,2001,2002,2003,2004 ./lib/dns/include/dns/version.h C 2001,2004 ./lib/dns/include/dns/view.h C 1999,2000,2001,2002,2003,2004,2005 From 08097713a4bffb99a51956ae6674dd9f45fd79b2 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 11 Feb 2005 00:01:58 +0000 Subject: [PATCH 094/130] update copyright notice --- bin/named/client.c | 4 ++-- bin/named/include/named/client.h | 4 ++-- bin/named/include/named/interfacemgr.h | 4 ++-- bin/named/interfacemgr.c | 4 ++-- lib/dns/include/dns/types.h | 4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/bin/named/client.c b/bin/named/client.c index 689306a850..c8d168132b 100644 --- a/bin/named/client.c +++ b/bin/named/client.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: client.c,v 1.223 2005/02/10 05:53:41 marka Exp $ */ +/* $Id: client.c,v 1.224 2005/02/11 00:01:57 marka Exp $ */ #include diff --git a/bin/named/include/named/client.h b/bin/named/include/named/client.h index 9dc9d7d52a..dc2572f142 100644 --- a/bin/named/include/named/client.h +++ b/bin/named/include/named/client.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: client.h,v 1.71 2005/02/10 05:53:42 marka Exp $ */ +/* $Id: client.h,v 1.72 2005/02/11 00:01:57 marka Exp $ */ #ifndef NAMED_CLIENT_H #define NAMED_CLIENT_H 1 diff --git a/bin/named/include/named/interfacemgr.h b/bin/named/include/named/interfacemgr.h index 2e98aab3dc..1838affe95 100644 --- a/bin/named/include/named/interfacemgr.h +++ b/bin/named/include/named/interfacemgr.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: interfacemgr.h,v 1.28 2005/02/10 05:53:42 marka Exp $ */ +/* $Id: interfacemgr.h,v 1.29 2005/02/11 00:01:57 marka Exp $ */ #ifndef NAMED_INTERFACEMGR_H #define NAMED_INTERFACEMGR_H 1 diff --git a/bin/named/interfacemgr.c b/bin/named/interfacemgr.c index 3cd8739e7d..1e6a377c67 100644 --- a/bin/named/interfacemgr.c +++ b/bin/named/interfacemgr.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: interfacemgr.c,v 1.79 2005/02/10 05:53:41 marka Exp $ */ +/* $Id: interfacemgr.c,v 1.80 2005/02/11 00:01:57 marka Exp $ */ #include diff --git a/lib/dns/include/dns/types.h b/lib/dns/include/dns/types.h index d64d182253..5fd54ce836 100644 --- a/lib/dns/include/dns/types.h +++ b/lib/dns/include/dns/types.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: types.h,v 1.112 2005/02/10 05:53:43 marka Exp $ */ +/* $Id: types.h,v 1.113 2005/02/11 00:01:58 marka Exp $ */ #ifndef DNS_TYPES_H #define DNS_TYPES_H 1 From 686bcdcb4c63e8dd9bbe9607265061a4d3934bbc Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 16 Feb 2005 23:46:28 +0000 Subject: [PATCH 095/130] placeholder --- CHANGES | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/CHANGES b/CHANGES index 0b31ccc29b..9b6c7776ca 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,7 @@ +1815. [placeholder] rt13086 + +1814. [placeholder] rt13455 + 1813. [placeholder] rt13505 1812. [port] win32: IN6_IS_ADDR_UNSPECIFIED macro is incorrect. From 4c0903254bbdbb2d4f6c68c336c2fd651296bd47 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 17 Feb 2005 05:49:01 +0000 Subject: [PATCH 096/130] typo in comment --- lib/dns/include/dns/master.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/dns/include/dns/master.h b/lib/dns/include/dns/master.h index a0f8be6165..a60aa947aa 100644 --- a/lib/dns/include/dns/master.h +++ b/lib/dns/include/dns/master.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: master.h,v 1.40 2005/01/10 23:43:24 marka Exp $ */ +/* $Id: master.h,v 1.41 2005/02/17 05:49:01 marka Exp $ */ #ifndef DNS_MASTER_H #define DNS_MASTER_H 1 @@ -45,7 +45,7 @@ * matches as fatal */ #define DNS_MASTER_CHECKNAMES 0x00000100 #define DNS_MASTER_CHECKNAMESFAIL 0x00000200 -#define DNS_MASTER_CHECKWILDCARD 0x00000400 /* Check for internal wilcards. */ +#define DNS_MASTER_CHECKWILDCARD 0x00000400 /* Check for internal wildcards. */ ISC_LANG_BEGINDECLS From 3d79c437d8cc10651b22601b55f4098b4cfe5979 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 18 Feb 2005 00:27:07 +0000 Subject: [PATCH 097/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 9b6c7776ca..e86f975f7b 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1816. [placeholder] rt13597 + 1815. [placeholder] rt13086 1814. [placeholder] rt13455 From eefe1fcace1c50a1defe4cb780ed33c3d3e998f9 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 21 Feb 2005 21:39:47 +0000 Subject: [PATCH 098/130] new draft --- ...-ietf-dnsop-ipv6-dns-configuration-05.txt} | 942 ++++++++++-------- 1 file changed, 524 insertions(+), 418 deletions(-) rename doc/draft/{draft-ietf-dnsop-ipv6-dns-configuration-04.txt => draft-ietf-dnsop-ipv6-dns-configuration-05.txt} (67%) diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-04.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-05.txt similarity index 67% rename from doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-04.txt rename to doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-05.txt index 1a3ccaff12..ed63a23ddf 100644 --- a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-04.txt +++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-05.txt @@ -1,27 +1,28 @@ - DNS Operations WG Internet-Draft J. Jeong (ed.) ETRI/University of Minnesota -Expires: March 2005 28 September 2004 +Expires: August 2005 19 February 2005 IPv6 Host Configuration of DNS Server Information Approaches - draft-ietf-dnsop-ipv6-dns-configuration-04.txt + draft-ietf-dnsop-ipv6-dns-configuration-05.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. + 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. - + 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 @@ -29,107 +30,107 @@ Status of this Memo progress." The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. + http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. + http://www.ietf.org/shadow.html" - This Internet-Draft will expire on March 27, 2005. + This Internet-Draft will expire on August 19, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2005). 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 + attributes of three solutions: RA option, DHCPv6 option, and + Well-known anycast addresses for recursive DNS servers. -Jeong, et al. Expires - March 2005 [Page 1] +Jeong, et al. Expires - August 2005 [Page 1] -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - guideline for IPv6 DNS configuration to select approaches suitable - for their host DNS configuration. + Additionally, it suggests four deployment scenarios considering + multi-solution resolution. Therefore, this document will give the + audience a guideline for IPv6 DNS configuration to select the + 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........................................6 - 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.........................................10 - 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. Appendix A - Link-layer Multicast Acknowledgements with RA - Option........................................................21 - 11. Authors' Addresses............................................22 - 12. Intellectual Property Statement...............................23 + 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.........................................6 + 3.2. DHCPv6 Option..............................................6 + 3.2.1. Advantages...........................................8 + 3.2.2. Disadvantages........................................8 + 3.2.3. Observations.........................................9 + 3.3. Well-known Anycast Addresses...............................9 + 3.3.1. Advantages..........................................10 + 3.3.2. Disadvantages.......................................10 + 3.3.3. Observations........................................11 + 4. Interworking among IPv6 DNS Configuration Approaches..........11 + 5. Deployment Scenarios..........................................12 + 5.1. ISP Network...............................................13 + 5.1.1. RA Option Approach..................................13 + 5.1.2. DHCPv6 Option Approach..............................13 + 5.1.3. Well-known Addresses Approach.......................14 + 5.2. Enterprise Network........................................14 + 5.3. 3GPP Network..............................................15 + 5.3.1. Currently Available Mechanisms and Recommendations..15 + 5.3.2. RA Extension........................................16 + 5.3.3. Stateless DHCPv6....................................17 + 5.3.4. Well-known Addresses................................18 + 5.3.5. Recommendations.....................................18 + 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.................................................19 + 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..............................................20 + 8. Normative References..........................................20 + 9. Informative References........................................21 + 10. Appendix A - Link-layer Multicast Acknowledgements with RA + Option.......................................................23 -Jeong, et al. Expires - March 2005 [Page 2] +Jeong, et al. Expires - August 2005 [Page 2] -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - Full Copyright Statement..........................................24 - Acknowledgement...................................................24 + 11. Authors' Addresses...........................................23 + 12. Intellectual Property Statement..............................25 + 13. Full Copyright Statement.....................................25 + Acknowledgement..................................................26 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. + Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address + Autoconfiguration provide the ways to configure either fixed or + mobile nodes with one or more IPv6 addresses, default routes and + some other parameters [3][4]. To support the 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. + DNS servers [9]. Also, it suggests the 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 @@ -137,8 +138,8 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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. + select the approaches suitable for IPv6 host configuration of + recursive DNS server. 2. Terminology @@ -156,27 +157,28 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 3.1. RA Option + + + +Jeong, et al. Expires - August 2005 [Page 3] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + 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 - - -Jeong, et al. Expires - March 2005 [Page 3] - -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 - - - works in the same way that nodes learn about routers and prefixes. + mechanisms (i.e., advertisements and solicitations) are used. This + works in the same way that nodes learn about routers and prefixes. An IPv6 host can configure the IPv6 addresses of one or more - RDNSSes via RA message periodically sent by router or solicited by + 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. + router. When advertising more than one RDNSS option, 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 @@ -185,14 +187,14 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 However, it is worth noting that some link layers (e.g., WLAN) need to acknowledge multicast packets, which may increase the amount of - link-layer traffic. This is discussed in Appendix A. + link-layer traffic [25]-[28]. This is discussed in Appendix A. The RA approach is useful in some mobile environments where the addresses of the RDNSSes are changing because the RA option includes a lifetime field that allows client to use RDNSSes nearer to the client. 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, + address [8]. However, from the viewpoint of implementation, the 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 @@ -211,94 +213,95 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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, -Jeong, et al. Expires - March 2005 [Page 4] +Jeong, et al. Expires - August 2005 [Page 4] -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - 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. + 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 types on which ND is not + possible; on such links, some other mechanisms 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 obtained - 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. + 3) All of the information a host needs to run the basic Internet + applications such as the email, web, ftp, etc., can be obtained + with the addition of this option to ND and address autoconfiguration + 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. + (e.g., Wireless LANs): Refer to Appendix A. 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 needed to learn the RDNSS information. - 5) The RA approach could be used as a model for other similar types + 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. + addresses, such as NTP server address, that are common to all + clients on a subnet would be easy to define. 3.1.2. Disadvantages - 1) ND is mostly implemented in kernel part of operating system. + 1) ND is mostly implemented in the 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, and complemented by a user-land process. DHCPv6, - however, has more flexibility for extension of service discovery - because it is an application layer protocol. + services, such as DNS servers, ND should be extended in the kernel + part, and complemented by a user-land process. DHCPv6, however, + has more flexibility for the 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. - + synchronization between another ND cache for RDNSSes in the kernel + space and the DNS configuration file in the 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 -Jeong, et al. Expires - March 2005 [Page 5] +Jeong, et al. Expires - August 2005 [Page 5] -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + what the kernel conveys, and to have the daemon do these steps, but + such a daemon is not needed 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 + router on every link where this information needs to be configured by RA option. 3.1.3. Observations - 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. + The proposed RDNSS RA option along with the IPv6 ND and + Autoconfiguration allows a host to obtain all of the information it + needs to access the basic Internet services like the web, email, + ftp, etc. This is preferable in the environments where hosts use + RAs to autoconfigure their addresses and all the 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. The environments like this include + the 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. + configuration [5]-[7]. The environments like this are most likely + the 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. @@ -313,24 +316,25 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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- + 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]. + + + +Jeong, et al. Expires - August 2005 [Page 6] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + 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 - - -Jeong, et al. Expires - March 2005 [Page 6] - -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 - - where DHCPv6 is needed for very straightforward configuration of network devices. @@ -356,7 +360,7 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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] + 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, @@ -374,22 +378,22 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 large service provider networks with tens of thousands of hosts that may initiate a DHCPv4 message exchange simultaneously. + + +Jeong, et al. Expires - August 2005 [Page 7] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + 3.2.1. Advantages The DHCPv6 option for RDNSS has a number of advantages. These include: - - -Jeong, et al. Expires - March 2005 [Page 7] - -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 - - 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 + RDNSSes along with the addresses of other network services, as well as location-specific information like time zones. 2) As a consequence, when the network administrator goes to @@ -411,7 +415,7 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 + 6) The specification for configuration of RDNSSes through DHCPv6 is available as an RFC. No new protocol extensions such as new options are necessary. @@ -429,18 +433,18 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 + + +Jeong, et al. Expires - August 2005 [Page 8] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + 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 - - -Jeong, et al. Expires - March 2005 [Page 8] - -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 - - 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, @@ -450,7 +454,7 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 + 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 @@ -465,6 +469,17 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 3.3. Well-known Anycast Addresses + Anycast uses the same routing system as unicast [11]. However, + administrative entities are local ones. The local entities may + accept unicast routes (including default routes) to anycast servers + from adjacent entities. The administrative entities should not + advertise their peers routes to their internal anycast servers, if + they want to prohibit external access from some peers to the + servers. If some advertisement is inevitable (such as the case + with default routes), the packets to the servers should be blocked + at the boundary of the entities. Thus, for this anycast, not only + unicast routing but also unicast ND protocols can be used as is. + First of all, the well-known anycast addresses approach is much different from that discussed at IPv6 Working Group in the past [9]. It should be noted that "anycast" in this memo is simpler than that @@ -473,13 +488,20 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 + + +Jeong, et al. Expires - August 2005 [Page 9] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + There is no point in having multiple RDNSSes sharing an anycast address on a single link. - - 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]. + + The approach with well-known anycast addresses is to set multiple + 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 @@ -489,24 +511,18 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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. - - -Jeong, et al. Expires - March 2005 [Page 9] - -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 - - 3.3.1. Advantages 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. + + 1) There is no delay to get the 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. + mechanisms, such as RA-based approach and DHCP based approach, as + well as factory default configuration. 3) The approach works over any environment where DNS works. @@ -516,49 +532,49 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 accesses 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. + naturally accesses 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 + 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). + + +Jeong, et al. Expires - August 2005 [Page 10] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + 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. + reduce the configuration effort of users. - Redundancy by multiple RDNSSes is better provided by multiple + The 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. + sharing the 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 + 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 - - -Jeong, et al. Expires - March 2005 [Page 10] - -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 - - 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 + provided by multiple addresses) or change dynamically. DNS packets 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] + 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 @@ -567,7 +583,7 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 + 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. @@ -582,54 +598,54 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 - March 2005 [Page 11] +Jeong, et al. Expires - August 2005 [Page 11] -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - 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 well-known anycast addresses approach fully interworks with the + other approaches. That is, the other approaches can remove the + configuration effort on servers by using the well-known addresses + as the default configuration. Moreover, the clients preconfigured + with the well-known anycast addresses can be further configured to + use other approaches to override the well-known addresses, if the + 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 as follows: - The last is that the well-known anycast addresses can be set in RA - or DHCP configuration to reduce configuration effort of users. + 1) 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 preconfigured + in IPv6 hosts' resolver configuration files. + + 2) 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. + + 3) 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 + 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 - are 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. + Regarding the DNS configuration on the IPv6 host, several + mechanisms are 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 @@ -637,6 +653,13 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 probable. The main objective of this work is to provide a useful guideline for IPv6 DNS configuration. + + +Jeong, et al. Expires - August 2005 [Page 12] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + 5.1. ISP Network A characteristic of ISP network is that multiple Customer Premises @@ -649,18 +672,11 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 + 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 - March 2005 [Page 12] - -Internet-Draft IPv6 Host Configuration of DNS Server September 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 @@ -678,19 +694,27 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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. + 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 + is already in place for DHCPv6 as RFC 3646 [7] and 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. + + + +Jeong, et al. Expires - August 2005 [Page 13] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + 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 @@ -700,8 +724,8 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 + 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. @@ -709,13 +733,6 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 - March 2005 [Page 13] - -Internet-Draft IPv6 Host Configuration of DNS Server September 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 @@ -735,22 +752,29 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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. + requests from IPv6 hosts as RDNSSes. The RDNSS configuration in + the enterprise network can be performed like in Section 4, in which + three approaches can be used together as follows: - 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. + 1) 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 + + +Jeong, et al. Expires - August 2005 [Page 14] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 2) 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 + 3) 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 @@ -764,13 +788,6 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 architecture can be found in [18], and transition to IPv6 in 3GPP networks is analyzed in [19] and [20]. - - -Jeong, et al. Expires - March 2005 [Page 14] - -Internet-Draft IPv6 Host Configuration of DNS Server September 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]. @@ -792,7 +809,7 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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). + 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 @@ -801,6 +818,13 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 RDNSS addresses manually in his/her UE. The use of well-known addresses is briefly discussed in section 5.3.4. + + +Jeong, et al. Expires - August 2005 [Page 15] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + 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 @@ -819,13 +843,6 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 - March 2005 [Page 15] - -Internet-Draft IPv6 Host Configuration of DNS Server September 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 @@ -855,6 +872,14 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 should, however, be pretty straightforward, and new IPv6 equipment could support RA extension already from the beginning. + + + +Jeong, et al. Expires - August 2005 [Page 16] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + 5.3.3. Stateless DHCPv6 DHCPv6-based solution needs the implementation of Stateless DHCP @@ -863,6 +888,7 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 @@ -874,14 +900,8 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 server, the RDNSS configuration information can be updated by the network administrator at a single source. - - -Jeong, et al. Expires - March 2005 [Page 16] - -Internet-Draft IPv6 Host Configuration of DNS Server September 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. @@ -894,23 +914,30 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 + 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 + 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]. + + +Jeong, et al. Expires - August 2005 [Page 17] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + 5.3.4. Well-known Addresses - Using well-known addresses is also a feasible and a light mechanism + 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 @@ -919,23 +946,16 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 + 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. + (also in some 3GPP UEs) as a last resort of IPv6 DNS configuration. 5.3.5. Recommendations - - -Jeong, et al. Expires - March 2005 [Page 17] - -Internet-Draft IPv6 Host Configuration of DNS Server September 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 @@ -962,6 +982,14 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 not provide IPv6. Automatic or Configured tunnels are the recommended transition mechanisms for this scenario. + + + +Jeong, et al. Expires - August 2005 [Page 18] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + 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 @@ -972,9 +1000,9 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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. + 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 @@ -983,14 +1011,6 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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 - March 2005 [Page 18] - -Internet-Draft IPv6 Host Configuration of DNS Server September 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 @@ -1014,48 +1034,72 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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. + In some deployment scenarios [19], where cryptographic security is + required for applications, the secret information for the + cryptographic security is preconfigured through which application + specific configuration data, including those for DNS, can be + + +Jeong, et al. Expires - August 2005 [Page 19] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 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 + autoconfiguration 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. + already assumed that the local environment is secure enough that + the information from the local autoconfiguration server has + acceptable security even without cryptographic security. Thus, the + communication between the local DNS client and local DNS server has + the acceptable security. + + In autoconfiguring recursive servers, DNSSEC may be overkill, + because DNSSEC [29] needs the configuration and reconfiguration of + clients at root key roll-over [30][31]. Even if additional keys + for secure key roll-over are added at the initial configuration, + they are as vulnerable as the original keys to some forms of + attacks, such as social hacking. Another problem of using DNSSEC + and autoconfiguration together is that DNSSEC requires secure time, + which means secure communication with autoconfigured time servers, + which requires configured secret information. Therefore, in order + that the autoconfiguration may be secure, it requires configured + secret information. + + If DNSSEC [29] is used and the signatures are verified on the + client host, the misconfiguration of a DNS server may be simply + denial of service. Also, if local routing environment is not + reliable, clients may be directed to a false resolver with the same + IP address as the true one. For security considerations of each approach, refer to the corresponding drafts [5]-[9]. 7. Acknowledgements - - - -Jeong, et al. Expires - March 2005 [Page 19] - -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 - - This draft has greatly benefited from inputs by David Meyer, Rob Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. - The authors appreciate their contribution. + The authors appreciate their contributions. 8. Normative References [1] S. Bradner, "Intellectual Property Rights in IETF Technology", RFC 3668, February 2004. + + +Jeong, et al. Expires - August 2005 [Page 20] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + [2] S. Bradner, "IETF Rights in Contributions", RFC 3667, February 2004. @@ -1078,15 +1122,17 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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, Work in Progress. + Discovery based on Router Advertisement", + draft-jeong-dnsop-ipv6-dns-discovery-04.txt, February 2005, + Work in Progress. - [9] M. Ohta, "Preconfigured DNS Server Addresses", draft-ohta- - preconfigured-dns-01.txt, February 2004, Work in Progress. + [9] M. Ohta, "Preconfigured DNS Server Addresses", + draft-ohta-preconfigured-dns-01.txt, February 2004, Work in + Progress. - [10] S. Venaas, T. Chown and B. Volz, "Information Refresh Time - Option for DHCPv6", draft-ietf-dhc-lifetime-02.txt, September - 2004, Work in Progress. + [10] S. Venaas, T. Chown and B. Volz, "Information Refresh Time + Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt, January + 2005, Work in Progress. [11] C. Partridge, T. Mendez and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. @@ -1094,25 +1140,27 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 [12] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. - - -Jeong, et al. Expires - March 2005 [Page 20] - -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 - - [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6 - into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis- - 03.txt, June 2004, Work in Progress. + into ISP Networks", + draft-ietf-v6ops-isp-scenarios-analysis-03.txt, June 2004, + Work in Progress. - [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft- - ietf-send-ndopt-06.txt, July 2004, Work in Progress. + [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", + draft-ietf-send-ndopt-06.txt, July 2004, Work in Progress. + + +Jeong, et al. Expires - August 2005 [Page 21] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + [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-05.txt, July 2004, Work in Progress. + [16] J. Bound et al., "IPv6 Enterprise Network Scenarios", + draft-ietf-v6ops-ent-scenarios-05.txt, July 2004, Work in + Progress. [17] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December @@ -1125,7 +1173,7 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 RFC 3574, August 2003. [20] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-10.txt, May 2004, + Networks", draft-ietf-v6ops-3gpp-analysis-11.txt, October 2004, Work in Progress. [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); @@ -1136,44 +1184,72 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 June 2003. [23] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering - Requirements for Stateless DHCPv6", draft-ietf-dhc-stateless- - dhcpv6-renumbering-01.txt, March 2004, Work in Progress. + Requirements for Stateless DHCPv6", + draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt, October + 2004, Work in Progress. [24] C. Huitema et al., "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April 2004. -10. Appendix A - Link-layer Multicast Acknowledgements with RA Option + [25] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access + Control (MAC) and Physical Layer (PHY) Specifications", March + 1999. + + [26] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) specifications: High-speed + Physical Layer in the 5 GHZ Band", September 1999. + + [27] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) specifications: Higher-Speed + Physical Layer Extension in the 2.4 GHz Band", September 1999. + + + +Jeong, et al. Expires - August 2005 [Page 22] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + [28] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access + Control (MAC) and Physical Layer (PHY) specifications: Further + Higher Data Rate Extension in the 2.4 GHz Band", April 2003. + + [29] D. Eastlake, "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [30] O. Kolkman and R. Gieben, "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practices-03.txt, + December 2004. + + [31] G. Guette and O. Courtay, "Requirements for Automated Key + Rollover in DNSSEC", + draft-ietf-dnsop-key-rollover-requirements-02.txt, January + 2005. + +10. Appendix A - Link-layer Multicast Acknowledgements with RA Option One benefit of RA option is to be able to multicast the advertisements, reducing the need for duplicated unicast communications. - - - -Jeong, et al. Expires - March 2005 [Page 21] - -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 - - - However, some link-layers may not support this as well as others. + However, some link-layers may not support this as well as others. Consider, for example, WLAN networks where multicast is unreliable. The unreliability problem is caused by lack of ACK for multicast, especially on the path from the Access Point (AP) to the Station - (STA), which is specific to CSMA/CA of WLAN. Namely, multicast - packet is unacknowledged on the path from the AP to the STA, but - acknowledged in the reverse direction from the STA to the AP. For - example, when a router is placed at wired network connected to an - AP, a host may sometimes not receive RA message advertised through - the AP. + (STA), which is specific to CSMA/CA of WLAN [25]-[28]. Namely, + multicast packet is unacknowledged on the path from the AP to the + STA, but acknowledged in the reverse direction from the STA to the + AP [25]. For example, when a router is placed at wired network + connected to an AP, a host may sometimes not receive RA message + advertised through the AP. The fact that this problem has not been addressed in Neighbor Discovery [3] indicates that the extra link-layer acknowledgements have not been considered a serious problem till now. - A possible mitigation technique could be to map all-nodes link- - local multicast address to the link-layer broadcast address, and to - rely on the ND retransmissions for message delivery. + A possible mitigation technique could be to map all-nodes link-local + multicast address to the link-layer broadcast address, and to rely + on the ND retransmissions for message delivery. 11. Authors' Addresses @@ -1182,6 +1258,13 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 117 Pleasant Street SE Minneapolis, MN 55455 USA + + +Jeong, et al. Expires - August 2005 [Page 23] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + Phone: +1 651 587 7774 EMail: jjeong@cs.umn.edu @@ -1204,13 +1287,6 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 Phone: +1 650 625 2004 EMail: bob.hinden@nokia.com - - -Jeong, et al. Expires - March 2005 [Page 22] - -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 - - Ted Lemon Nominum, Inc. 950 Charter Street @@ -1237,6 +1313,13 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 Korea Phone: +82 31 200 4508 + + +Jeong, et al. Expires - August 2005 [Page 24] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + EMail: soohong.park@samsung.com Suresh Satapati @@ -1257,16 +1340,6 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 12. Intellectual Property Statement - The following intellectual property notice is copied from RFC3668, - Section 5. - - -Jeong, et al. Expires - March 2005 [Page 23] - -Internet-Draft IPv6 Host Configuration of DNS Server September 2004 - - - 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 @@ -1286,19 +1359,23 @@ Internet-Draft IPv6 Host Configuration of DNS Server September 2004 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. + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. -Full Copyright Statement +13. Full Copyright Statement - 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 + Copyright (C) The Internet Society (2005). 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. - + rights. + + +Jeong, et al. Expires - August 2005 [Page 25] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 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 @@ -1314,8 +1391,37 @@ Acknowledgement Internet Society. - - -Jeong, et al. Expires - March 2005 [Page 24] - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong, et al. Expires - August 2005 [Page 26] + From 4423c99613db1399dbb5c51e86ef0d351a1418c2 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 23 Feb 2005 01:09:23 +0000 Subject: [PATCH 099/130] 1814. [func] UNIX domain controls are now supported. --- CHANGES | 2 +- bin/named/controlconf.c | 152 +++++++- bin/rndc/rndc.c | 29 +- config.h.in | 9 +- configure | 182 ++++++++- configure.in | 20 +- lib/bind9/check.c | 146 ++++++- lib/dns/dispatch.c | 5 +- lib/isc/include/isc/netaddr.h | 13 +- lib/isc/include/isc/platform.h.in | 7 +- lib/isc/include/isc/sockaddr.h | 19 +- lib/isc/include/isc/socket.h | 43 ++- lib/isc/netaddr.c | 41 +- lib/isc/sockaddr.c | 47 ++- lib/isc/unix/include/isc/net.h | 8 +- lib/isc/unix/net.c | 12 +- lib/isc/unix/socket.c | 206 +++++++++- lib/isc/win32/include/isc/net.h | 13 +- lib/isc/win32/include/isc/platform.h | 8 +- lib/isc/win32/libisc.def | 550 +++++++++++++-------------- lib/isc/win32/net.c | 7 +- lib/isc/win32/socket.c | 19 +- lib/isccfg/namedconf.c | 52 ++- 23 files changed, 1259 insertions(+), 331 deletions(-) diff --git a/CHANGES b/CHANGES index e86f975f7b..0b75aa7cfb 100644 --- a/CHANGES +++ b/CHANGES @@ -2,7 +2,7 @@ 1815. [placeholder] rt13086 -1814. [placeholder] rt13455 +1814. [func] UNIX domain controls are now supported. 1813. [placeholder] rt13505 diff --git a/bin/named/controlconf.c b/bin/named/controlconf.c index 571c660081..63d830439d 100644 --- a/bin/named/controlconf.c +++ b/bin/named/controlconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: controlconf.c,v 1.42 2005/01/12 01:56:06 marka Exp $ */ +/* $Id: controlconf.c,v 1.43 2005/02/23 01:06:36 marka Exp $ */ #include @@ -96,6 +96,10 @@ struct controllistener { isc_boolean_t exiting; controlkeylist_t keys; controlconnectionlist_t connections; + isc_sockettype_t type; + isc_uint32_t perm; + isc_uint32_t owner; + isc_uint32_t group; ISC_LINK(controllistener_t) link; }; @@ -191,6 +195,8 @@ shutdown_listener(controllistener_t *listener) { isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_CONTROL, ISC_LOG_NOTICE, "stopping command channel on %s", socktext); + if (listener->type == isc_sockettype_unix) + isc_socket_cleanunix(&listener->address, ISC_TRUE); listener->exiting = ISC_TRUE; } @@ -595,7 +601,8 @@ control_newconn(isc_task_t *task, isc_event_t *event) { sock = nevent->newsocket; (void)isc_socket_getpeername(sock, &peeraddr); - if (!address_ok(&peeraddr, listener->acl)) { + if (listener->type == isc_sockettype_tcp && + !address_ok(&peeraddr, listener->acl)) { char socktext[ISC_SOCKADDR_FORMATSIZE]; isc_sockaddr_format(&peeraddr, socktext, sizeof(socktext)); isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, @@ -915,7 +922,8 @@ static void update_listener(ns_controls_t *cp, controllistener_t **listenerp, cfg_obj_t *control, cfg_obj_t *config, isc_sockaddr_t *addr, - cfg_aclconfctx_t *aclconfctx, const char *socktext) + cfg_aclconfctx_t *aclconfctx, const char *socktext, + isc_sockettype_t type) { controllistener_t *listener; cfg_obj_t *allow; @@ -993,7 +1001,7 @@ update_listener(ns_controls_t *cp, /* * Now, keep the old access list unless a new one can be made. */ - if (control != NULL) { + if (control != NULL && type == isc_sockettype_tcp) { allow = cfg_tuple_get(control, "allow"); result = cfg_acl_fromconfig(allow, config, ns_g_lctx, aclconfctx, listener->mctx, @@ -1013,13 +1021,34 @@ update_listener(ns_controls_t *cp, "command channel %s: %s", socktext, isc_result_totext(result)); + if (result == ISC_R_SUCCESS && type == isc_sockettype_unix) { + isc_uint32_t perm, owner, group; + perm = cfg_obj_asuint32(cfg_tuple_get(control, "perm")); + owner = cfg_obj_asuint32(cfg_tuple_get(control, "owner")); + group = cfg_obj_asuint32(cfg_tuple_get(control, "group")); + result = ISC_R_SUCCESS; + if (listener->perm != perm || listener->owner != owner || + listener->group != group) + result = isc_socket_permunix(&listener->address, perm, + owner, group); + if (result == ISC_R_SUCCESS) { + listener->perm = perm; + listener->owner = owner; + listener->group = group; + } else + cfg_obj_log(control, ns_g_lctx, ISC_LOG_WARNING, + "couldn't update ownership/permission for " + "command channel %s", socktext); + } + *listenerp = listener; } static void add_listener(ns_controls_t *cp, controllistener_t **listenerp, cfg_obj_t *control, cfg_obj_t *config, isc_sockaddr_t *addr, - cfg_aclconfctx_t *aclconfctx, const char *socktext) + cfg_aclconfctx_t *aclconfctx, const char *socktext, + isc_sockettype_t type) { isc_mem_t *mctx = cp->server->mctx; controllistener_t *listener; @@ -1042,6 +1071,10 @@ add_listener(ns_controls_t *cp, controllistener_t **listenerp, listener->listening = ISC_FALSE; listener->exiting = ISC_FALSE; listener->acl = NULL; + listener->type = type; + listener->perm = 0; + listener->owner = 0; + listener->group = 0; ISC_LINK_INIT(listener, link); ISC_LIST_INIT(listener->keys); ISC_LIST_INIT(listener->connections); @@ -1049,7 +1082,7 @@ add_listener(ns_controls_t *cp, controllistener_t **listenerp, /* * Make the acl. */ - if (control != NULL) { + if (control != NULL && type == isc_sockettype_tcp) { allow = cfg_tuple_get(control, "allow"); result = cfg_acl_fromconfig(allow, config, ns_g_lctx, aclconfctx, mctx, &new_acl); @@ -1087,20 +1120,35 @@ add_listener(ns_controls_t *cp, controllistener_t **listenerp, if (result == ISC_R_SUCCESS) { int pf = isc_sockaddr_pf(&listener->address); if ((pf == AF_INET && isc_net_probeipv4() != ISC_R_SUCCESS) || +#ifdef ISC_PLATFORM_HAVESYSUNH + (pf == AF_UNIX && isc_net_probeunix() != ISC_R_SUCCESS) || +#endif (pf == AF_INET6 && isc_net_probeipv6() != ISC_R_SUCCESS)) result = ISC_R_FAMILYNOSUPPORT; } + if (result == ISC_R_SUCCESS && type == isc_sockettype_unix) + isc_socket_cleanunix(&listener->address, ISC_FALSE); + if (result == ISC_R_SUCCESS) result = isc_socket_create(ns_g_socketmgr, isc_sockaddr_pf(&listener->address), - isc_sockettype_tcp, - &listener->sock); + type, &listener->sock); if (result == ISC_R_SUCCESS) result = isc_socket_bind(listener->sock, &listener->address); + if (result == ISC_R_SUCCESS && type == isc_sockettype_unix) { + listener->perm = cfg_obj_asuint32(cfg_tuple_get(control, + "perm")); + listener->owner = cfg_obj_asuint32(cfg_tuple_get(control, + "owner")); + listener->group = cfg_obj_asuint32(cfg_tuple_get(control, + "group")); + result = isc_socket_permunix(&listener->address, listener->perm, + listener->owner, listener->group); + } if (result == ISC_R_SUCCESS) result = control_listen(listener); @@ -1183,9 +1231,6 @@ ns_controls_configure(ns_controls_t *cp, cfg_obj_t *config, * The parser handles BIND 8 configuration file * syntax, so it allows unix phrases as well * inet phrases with no keys{} clause. - * - * "unix" phrases have been reported as - * unsupported by the parser. */ control = cfg_listelt_value(element2); @@ -1206,7 +1251,8 @@ ns_controls_configure(ns_controls_t *cp, cfg_obj_t *config, socktext); update_listener(cp, &listener, control, config, - addr, aclconfctx, socktext); + addr, aclconfctx, socktext, + isc_sockettype_tcp); if (listener != NULL) /* @@ -1221,7 +1267,81 @@ ns_controls_configure(ns_controls_t *cp, cfg_obj_t *config, */ add_listener(cp, &listener, control, config, addr, aclconfctx, - socktext); + socktext, + isc_sockettype_tcp); + + if (listener != NULL) + ISC_LIST_APPEND(new_listeners, + listener, link); + } + } + for (element = cfg_list_first(controlslist); + element != NULL; + element = cfg_list_next(element)) { + cfg_obj_t *controls; + cfg_obj_t *unixcontrols = NULL; + + controls = cfg_listelt_value(element); + (void)cfg_map_get(controls, "unix", &unixcontrols); + if (unixcontrols == NULL) + continue; + + for (element2 = cfg_list_first(unixcontrols); + element2 != NULL; + element2 = cfg_list_next(element2)) { + cfg_obj_t *control; + cfg_obj_t *path; + isc_sockaddr_t addr; + isc_result_t result; + + /* + * The parser handles BIND 8 configuration file + * syntax, so it allows unix phrases as well + * inet phrases with no keys{} clause. + */ + control = cfg_listelt_value(element2); + + path = cfg_tuple_get(control, "path"); + result = isc_sockaddr_frompath(&addr, + cfg_obj_asstring(path)); + if (result != ISC_R_SUCCESS) { + isc_log_write(ns_g_lctx, + NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_CONTROL, + ISC_LOG_DEBUG(9), + "control channel '%s': %s", + cfg_obj_asstring(path), + isc_result_totext(result)); + continue; + } + + isc_log_write(ns_g_lctx, + NS_LOGCATEGORY_GENERAL, + NS_LOGMODULE_CONTROL, + ISC_LOG_DEBUG(9), + "processing control channel '%s'", + cfg_obj_asstring(path)); + + update_listener(cp, &listener, control, config, + &addr, aclconfctx, + cfg_obj_asstring(path), + isc_sockettype_unix); + + if (listener != NULL) + /* + * Remove the listener from the old + * list, so it won't be shut down. + */ + ISC_LIST_UNLINK(cp->listeners, + listener, link); + else + /* + * This is a new listener. + */ + add_listener(cp, &listener, control, + config, &addr, aclconfctx, + cfg_obj_asstring(path), + isc_sockettype_unix); if (listener != NULL) ISC_LIST_APPEND(new_listeners, @@ -1252,7 +1372,8 @@ ns_controls_configure(ns_controls_t *cp, cfg_obj_t *config, isc_sockaddr_format(&addr, socktext, sizeof(socktext)); update_listener(cp, &listener, NULL, NULL, - &addr, NULL, socktext); + &addr, NULL, socktext, + isc_sockettype_tcp); if (listener != NULL) /* @@ -1266,7 +1387,8 @@ ns_controls_configure(ns_controls_t *cp, cfg_obj_t *config, * This is a new listener. */ add_listener(cp, &listener, NULL, NULL, - &addr, NULL, socktext); + &addr, NULL, socktext, + isc_sockettype_tcp); if (listener != NULL) ISC_LIST_APPEND(new_listeners, diff --git a/bin/rndc/rndc.c b/bin/rndc/rndc.c index b064a35b1d..ebe7304acf 100644 --- a/bin/rndc/rndc.c +++ b/bin/rndc/rndc.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rndc.c,v 1.102 2005/01/17 04:11:33 marka Exp $ */ +/* $Id: rndc.c,v 1.103 2005/02/23 01:06:36 marka Exp $ */ /* * Principal Author: DCL @@ -141,10 +141,18 @@ get_addresses(const char *host, in_port_t port) { isc_result_t result; int found = 0, count; - count = SERVERADDRS - nserveraddrs; - result = bind9_getaddresses(host, port, &serveraddrs[nserveraddrs], - count, &found); - nserveraddrs += found; + if (*host == '/') { + result = isc_sockaddr_frompath(&serveraddrs[nserveraddrs], + host); + if (result == ISC_R_SUCCESS) + nserveraddrs++; + } else { + count = SERVERADDRS - nserveraddrs; + result = bind9_getaddresses(host, port, + &serveraddrs[nserveraddrs], + count, &found); + nserveraddrs += found; + } if (result != ISC_R_SUCCESS) fatal("couldn't get address for '%s': %s", host, isc_result_totext(result)); @@ -358,6 +366,8 @@ rndc_connected(isc_task_t *task, isc_event_t *event) { static void rndc_startconnect(isc_sockaddr_t *addr, isc_task_t *task) { isc_result_t result; + int pf; + isc_sockettype_t type; char socktext[ISC_SOCKADDR_FORMATSIZE]; @@ -365,9 +375,12 @@ rndc_startconnect(isc_sockaddr_t *addr, isc_task_t *task) { notify("using server %s (%s)", servername, socktext); - DO("create socket", isc_socket_create(socketmgr, - isc_sockaddr_pf(addr), - isc_sockettype_tcp, &sock)); + pf = isc_sockaddr_pf(addr); + if (pf == AF_INET || pf == AF_INET6) + type = isc_sockettype_tcp; + else + type = isc_sockettype_unix; + DO("create socket", isc_socket_create(socketmgr, pf, type, &sock)); switch (isc_sockaddr_pf(addr)) { case AF_INET: DO("bind socket", isc_socket_bind(sock, &local4)); diff --git a/config.h.in b/config.h.in index 778afff595..aaca05ad65 100644 --- a/config.h.in +++ b/config.h.in @@ -16,7 +16,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: config.h.in,v 1.64 2004/12/04 06:48:43 marka Exp $ */ +/* $Id: config.h.in,v 1.65 2005/02/23 01:09:23 marka Exp $ */ /*** *** This file is not to be included by any public header files, because @@ -218,12 +218,19 @@ int sigwait(const unsigned int *set, int *sig); /* Define to 1 if you have the header file. */ #undef HAVE_SYS_TYPES_H +/* Define to 1 if you have the header file. */ +#undef HAVE_SYS_UN_H + /* Define if running under Compaq TruCluster */ #undef HAVE_TRUCLUSTER /* Define to 1 if you have the header file. */ #undef HAVE_UNISTD_H +/* Define if connect does not honour the permission on the UNIX domain socket. + */ +#undef NEED_SECURE_DIRECTORY + /* Define to the address where bug reports for this package should be sent. */ #undef PACKAGE_BUGREPORT diff --git a/configure b/configure index 3c3849a866..ceeee67b90 100755 --- a/configure +++ b/configure @@ -1,5 +1,5 @@ #! /bin/sh -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 1996-2003 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -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.357 2004/12/09 02:16:28 marka Exp $ +# $Id: configure,v 1.358 2005/02/23 01:09:23 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.371 . +# From configure.in Revision: 1.372 . # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.59. # @@ -495,7 +495,7 @@ ac_includes_default="\ # include #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_SOCKADDR_LEN_T 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 LIBTOOL_ALLOW_UNDEFINED LIBTOOL_IN_MAIN 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_SOCKADDR_LEN_T 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 LIBTOOL_ALLOW_UNDEFINED LIBTOOL_IN_MAIN 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_HAVESYSUNH 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. @@ -26461,6 +26461,179 @@ fi done + +for ac_header in sys/un.h +do +as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh` +if eval "test \"\${$as_ac_Header+set}\" = set"; then + echo "$as_me:$LINENO: checking for $ac_header" >&5 +echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6 +if eval "test \"\${$as_ac_Header+set}\" = set"; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +fi +echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_Header'}'`" >&5 +echo "${ECHO_T}`eval echo '${'$as_ac_Header'}'`" >&6 +else + # Is the header compilable? +echo "$as_me:$LINENO: checking $ac_header usability" >&5 +echo $ECHO_N "checking $ac_header usability... $ECHO_C" >&6 +cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ +$ac_includes_default +#include <$ac_header> +_ACEOF +rm -f conftest.$ac_objext +if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 + (eval $ac_compile) 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_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_header_compiler=yes +else + echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + +ac_header_compiler=no +fi +rm -f conftest.err conftest.$ac_objext conftest.$ac_ext +echo "$as_me:$LINENO: result: $ac_header_compiler" >&5 +echo "${ECHO_T}$ac_header_compiler" >&6 + +# Is the header present? +echo "$as_me:$LINENO: checking $ac_header presence" >&5 +echo $ECHO_N "checking $ac_header presence... $ECHO_C" >&6 +cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ +#include <$ac_header> +_ACEOF +if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5 + (eval $ac_cpp conftest.$ac_ext) 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); } >/dev/null; then + if test -s conftest.err; then + ac_cpp_err=$ac_c_preproc_warn_flag + ac_cpp_err=$ac_cpp_err$ac_c_werror_flag + else + ac_cpp_err= + fi +else + ac_cpp_err=yes +fi +if test -z "$ac_cpp_err"; then + ac_header_preproc=yes +else + echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + + ac_header_preproc=no +fi +rm -f conftest.err conftest.$ac_ext +echo "$as_me:$LINENO: result: $ac_header_preproc" >&5 +echo "${ECHO_T}$ac_header_preproc" >&6 + +# So? What about this header? +case $ac_header_compiler:$ac_header_preproc:$ac_c_preproc_warn_flag in + yes:no: ) + { echo "$as_me:$LINENO: WARNING: $ac_header: accepted by the compiler, rejected by the preprocessor!" >&5 +echo "$as_me: WARNING: $ac_header: accepted by the compiler, rejected by the preprocessor!" >&2;} + { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with the compiler's result" >&5 +echo "$as_me: WARNING: $ac_header: proceeding with the compiler's result" >&2;} + ac_header_preproc=yes + ;; + no:yes:* ) + { echo "$as_me:$LINENO: WARNING: $ac_header: present but cannot be compiled" >&5 +echo "$as_me: WARNING: $ac_header: present but cannot be compiled" >&2;} + { echo "$as_me:$LINENO: WARNING: $ac_header: check for missing prerequisite headers?" >&5 +echo "$as_me: WARNING: $ac_header: check for missing prerequisite headers?" >&2;} + { echo "$as_me:$LINENO: WARNING: $ac_header: see the Autoconf documentation" >&5 +echo "$as_me: WARNING: $ac_header: see the Autoconf documentation" >&2;} + { echo "$as_me:$LINENO: WARNING: $ac_header: section \"Present But Cannot Be Compiled\"" >&5 +echo "$as_me: WARNING: $ac_header: section \"Present But Cannot Be Compiled\"" >&2;} + { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with the preprocessor's result" >&5 +echo "$as_me: WARNING: $ac_header: proceeding with the preprocessor's result" >&2;} + { echo "$as_me:$LINENO: WARNING: $ac_header: in the future, the compiler will take precedence" >&5 +echo "$as_me: WARNING: $ac_header: in the future, the compiler will take precedence" >&2;} + ( + cat <<\_ASBOX +## ------------------------------------------ ## +## Report this to the AC_PACKAGE_NAME lists. ## +## ------------------------------------------ ## +_ASBOX + ) | + sed "s/^/$as_me: WARNING: /" >&2 + ;; +esac +echo "$as_me:$LINENO: checking for $ac_header" >&5 +echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6 +if eval "test \"\${$as_ac_Header+set}\" = set"; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + eval "$as_ac_Header=\$ac_header_preproc" +fi +echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_Header'}'`" >&5 +echo "${ECHO_T}`eval echo '${'$as_ac_Header'}'`" >&6 + +fi +if test `eval echo '${'$as_ac_Header'}'` = yes; then + cat >>confdefs.h <<_ACEOF +#define `echo "HAVE_$ac_header" | $as_tr_cpp` 1 +_ACEOF + ISC_PLATFORM_HAVESYSUNH="#define ISC_PLATFORM_HAVESYSUNH 1" + +else + ISC_PLATFORM_HAVESYSUNH="#undef ISC_PLATFORM_HAVESYSUNH" + +fi + +done + + + +case "$host" in +*-solaris*) + +cat >>confdefs.h <<\_ACEOF +#define NEED_SECURE_DIRECTORY 1 +_ACEOF + + ;; +*-sunos*) + +cat >>confdefs.h <<\_ACEOF +#define NEED_SECURE_DIRECTORY 1 +_ACEOF + + ;; +esac + # # Time Zone Stuff # @@ -28416,6 +28589,7 @@ 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 +s,@ISC_PLATFORM_HAVESYSUNH@,$ISC_PLATFORM_HAVESYSUNH,;t t s,@ISC_PLATFORM_RLIMITTYPE@,$ISC_PLATFORM_RLIMITTYPE,;t t s,@ISC_PLATFORM_USEDECLSPEC@,$ISC_PLATFORM_USEDECLSPEC,;t t s,@LWRES_PLATFORM_USEDECLSPEC@,$LWRES_PLATFORM_USEDECLSPEC,;t t diff --git a/configure.in b/configure.in index dfccf318c8..1acbc9de56 100644 --- a/configure.in +++ b/configure.in @@ -18,7 +18,7 @@ AC_DIVERT_PUSH(1)dnl esyscmd([sed "s/^/# /" COPYRIGHT])dnl AC_DIVERT_POP()dnl -AC_REVISION($Revision: 1.371 $) +AC_REVISION($Revision: 1.372 $) AC_INIT(lib/dns/name.c) AC_PREREQ(2.13) @@ -1798,6 +1798,24 @@ case "$enable_linux_caps" in esac AC_CHECK_HEADERS(sys/prctl.h) +AC_CHECK_HEADERS(sys/un.h, +ISC_PLATFORM_HAVESYSUNH="#define ISC_PLATFORM_HAVESYSUNH 1" +, +ISC_PLATFORM_HAVESYSUNH="#undef ISC_PLATFORM_HAVESYSUNH" +) +AC_SUBST(ISC_PLATFORM_HAVESYSUNH) + +case "$host" in +*-solaris*) + AC_DEFINE(NEED_SECURE_DIRECTORY, 1, + [Define if connect does not honour the permission on the UNIX domain socket.]) + ;; +*-sunos*) + AC_DEFINE(NEED_SECURE_DIRECTORY, 1, + [Define if connect does not honour the permission on the UNIX domain socket.]) + ;; +esac + # # Time Zone Stuff # diff --git a/lib/bind9/check.c b/lib/bind9/check.c index 5f45ea4de4..6a99fc534a 100644 --- a/lib/bind9/check.c +++ b/lib/bind9/check.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: check.c,v 1.55 2005/01/17 00:46:02 marka Exp $ */ +/* $Id: check.c,v 1.56 2005/02/23 01:06:37 marka Exp $ */ #include @@ -1411,6 +1411,147 @@ bind9_check_logging(cfg_obj_t *config, isc_log_t *logctx, isc_mem_t *mctx) { return (result); } +static isc_result_t +key_exists(cfg_obj_t *keylist, const char *keyname) { + cfg_listelt_t *element; + const char *str; + cfg_obj_t *obj; + + if (keylist == NULL) + return (ISC_R_NOTFOUND); + for (element = cfg_list_first(keylist); + element != NULL; + element = cfg_list_next(element)) + { + obj = cfg_listelt_value(element); + str = cfg_obj_asstring(cfg_map_getname(obj)); + if (strcasecmp(str, keyname) == 0) + return (ISC_R_SUCCESS); + } + return (ISC_R_NOTFOUND); +} + +static isc_result_t +bind9_check_controlskeys(cfg_obj_t *control, cfg_obj_t *keylist, + isc_log_t *logctx) +{ + isc_result_t result = ISC_R_SUCCESS, tresult; + cfg_obj_t *control_keylist; + cfg_listelt_t *element; + cfg_obj_t *key; + + control_keylist = cfg_tuple_get(control, "keys"); + if (cfg_obj_isvoid(control_keylist)) + return (ISC_R_SUCCESS); + + for (element = cfg_list_first(control_keylist); + element != NULL; + element = cfg_list_next(element)) + { + key = cfg_listelt_value(element); + tresult = key_exists(keylist, cfg_obj_asstring(key)); + if (tresult != ISC_R_SUCCESS) { + cfg_obj_log(key, logctx, ISC_LOG_ERROR, + "unknown key '%s'", cfg_obj_asstring(key)); + result = tresult; + } + } + return (result); +} + +static isc_result_t +bind9_check_controls(cfg_obj_t *config, isc_log_t *logctx, isc_mem_t *mctx) { + isc_result_t result = ISC_R_SUCCESS, tresult; + cfg_aclconfctx_t actx; + cfg_listelt_t *element, *element2; + cfg_obj_t *allow; + cfg_obj_t *control; + cfg_obj_t *controls; + cfg_obj_t *controlslist = NULL; + cfg_obj_t *inetcontrols; + cfg_obj_t *unixcontrols; + cfg_obj_t *keylist = NULL; + const char *path; + isc_uint32_t perm, mask; + dns_acl_t *acl = NULL; + isc_sockaddr_t addr; + int i; + + (void)cfg_map_get(config, "controls", &controlslist); + if (controlslist == NULL) + return (ISC_R_SUCCESS); + + (void)cfg_map_get(config, "key", &keylist); + + /* + * INET: Check allow clause. + * UNIX: Check "perm" for sanity, check path length. + */ + for (element = cfg_list_first(controlslist); + element != NULL; + element = cfg_list_next(element)) { + controls = cfg_listelt_value(element); + unixcontrols = NULL; + inetcontrols = NULL; + (void)cfg_map_get(controls, "unix", &unixcontrols); + (void)cfg_map_get(controls, "inet", &inetcontrols); + for (element2 = cfg_list_first(inetcontrols); + element2 != NULL; + element2 = cfg_list_next(element2)) { + control = cfg_listelt_value(element2); + allow = cfg_tuple_get(control, "allow"); + cfg_aclconfctx_init(&actx); + tresult = cfg_acl_fromconfig(allow, config, logctx, + &actx, mctx, &acl); + if (acl != NULL) + dns_acl_detach(&acl); + if (tresult != ISC_R_SUCCESS) + result = tresult; + tresult = bind9_check_controlskeys(control, keylist, + logctx); + if (tresult != ISC_R_SUCCESS) + result = tresult; + } + for (element2 = cfg_list_first(unixcontrols); + element2 != NULL; + element2 = cfg_list_next(element2)) { + control = cfg_listelt_value(element2); + path = cfg_obj_asstring(cfg_tuple_get(control, "path")); + tresult = isc_sockaddr_frompath(&addr, path); + if (tresult == ISC_R_NOSPACE) { + cfg_obj_log(control, logctx, ISC_LOG_ERROR, + "unix control '%s': path too long", + path); + result = ISC_R_NOSPACE; + } + perm = cfg_obj_asuint32(cfg_tuple_get(control, "perm")); + for (i = 0; i < 3; i++) { +#ifdef NEED_SECURE_DIRECTORY + mask = (0x1 << (i*3)); /* SEARCH */ +#else + mask = (0x6 << (i*3)); /* READ + WRITE */ +#endif + if ((perm & mask) == mask) + break; + } + if (i == 0) { + cfg_obj_log(control, logctx, ISC_LOG_WARNING, + "unix control '%s' allows access " + "to everyone", path); + } else if (i == 3) { + cfg_obj_log(control, logctx, ISC_LOG_WARNING, + "unix control '%s' allows access " + "to nobody", path); + } + tresult = bind9_check_controlskeys(control, keylist, + logctx); + if (tresult != ISC_R_SUCCESS) + result = tresult; + } + } + return (result); +} + isc_result_t bind9_check_namedconf(cfg_obj_t *config, isc_log_t *logctx, isc_mem_t *mctx) { cfg_obj_t *options = NULL; @@ -1441,6 +1582,9 @@ bind9_check_namedconf(cfg_obj_t *config, isc_log_t *logctx, isc_mem_t *mctx) { if (bind9_check_logging(config, logctx, mctx) != ISC_R_SUCCESS) result = ISC_R_FAILURE; + if (bind9_check_controls(config, logctx, mctx) != ISC_R_SUCCESS) + result = ISC_R_FAILURE; + if (options != NULL && check_order(options, logctx) != ISC_R_SUCCESS) result = ISC_R_FAILURE; diff --git a/lib/dns/dispatch.c b/lib/dns/dispatch.c index ecf5bd4a7c..755c99765b 100644 --- a/lib/dns/dispatch.c +++ b/lib/dns/dispatch.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dispatch.c,v 1.120 2004/09/01 04:25:20 marka Exp $ */ +/* $Id: dispatch.c,v 1.121 2005/02/23 01:06:37 marka Exp $ */ #include @@ -926,6 +926,9 @@ startrecv(dns_dispatch_t *disp) { INSIST(disp->recv_pending == 0); disp->recv_pending = 1; break; + default: + INSIST(0); + break; } } diff --git a/lib/isc/include/isc/netaddr.h b/lib/isc/include/isc/netaddr.h index ae6b57e291..07c81a5d87 100644 --- a/lib/isc/include/isc/netaddr.h +++ b/lib/isc/include/isc/netaddr.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: netaddr.h,v 1.27 2005/01/17 23:58:33 marka Exp $ */ +/* $Id: netaddr.h,v 1.28 2005/02/23 01:06:38 marka Exp $ */ #ifndef ISC_NETADDR_H #define ISC_NETADDR_H 1 @@ -24,6 +24,11 @@ #include #include +#ifdef ISC_PLATFORM_HAVESYSUNH +#include +#include +#endif + ISC_LANG_BEGINDECLS struct isc_netaddr { @@ -31,6 +36,9 @@ struct isc_netaddr { union { struct in_addr in; struct in6_addr in6; +#ifdef ISC_PLATFORM_HAVESYSUNH + char un[sizeof(((struct sockaddr_un *)0)->sun_path)]; +#endif } type; isc_uint32_t zone; }; @@ -95,6 +103,9 @@ isc_netaddr_fromin(isc_netaddr_t *netaddr, const struct in_addr *ina); void isc_netaddr_fromin6(isc_netaddr_t *netaddr, const struct in6_addr *ina6); +isc_result_t +isc_netaddr_frompath(isc_netaddr_t *netaddr, const char *path); + void isc_netaddr_setzone(isc_netaddr_t *netaddr, isc_uint32_t zone); diff --git a/lib/isc/include/isc/platform.h.in b/lib/isc/include/isc/platform.h.in index a991004d2e..e4428080ea 100644 --- a/lib/isc/include/isc/platform.h.in +++ b/lib/isc/include/isc/platform.h.in @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: platform.h.in,v 1.34 2004/03/05 05:10:59 marka Exp $ */ +/* $Id: platform.h.in,v 1.35 2005/02/23 01:06:38 marka Exp $ */ #ifndef ISC_PLATFORM_H #define ISC_PLATFORM_H 1 @@ -210,6 +210,11 @@ */ @ISC_PLATFORM_NEEDMEMMOVE@ +/* + * Define if the platform has . + */ +@ISC_PLATFORM_HAVESYSUNH@ + #ifndef ISC_PLATFORM_USEDECLSPEC #define LIBISC_EXTERNAL_DATA #define LIBDNS_EXTERNAL_DATA diff --git a/lib/isc/include/isc/sockaddr.h b/lib/isc/include/isc/sockaddr.h index 3f1a1c0c83..f7afe8e5e8 100644 --- a/lib/isc/include/isc/sockaddr.h +++ b/lib/isc/include/isc/sockaddr.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: sockaddr.h,v 1.43 2004/11/22 23:29:10 marka Exp $ */ +/* $Id: sockaddr.h,v 1.44 2005/02/23 01:06:38 marka Exp $ */ #ifndef ISC_SOCKADDR_H #define ISC_SOCKADDR_H 1 @@ -23,12 +23,18 @@ #include #include #include +#ifdef ISC_PLATFORM_HAVESYSUNH +#include +#endif struct isc_sockaddr { union { struct sockaddr sa; struct sockaddr_in sin; struct sockaddr_in6 sin6; +#ifdef ISC_PLATFORM_HAVESYSUNH + struct sockaddr_un sun; +#endif } type; unsigned int length; /* XXXRTH beginning? */ ISC_LINK(struct isc_sockaddr) link; @@ -210,6 +216,17 @@ isc_sockaddr_issitelocal(isc_sockaddr_t *sa); * Returns ISC_TRUE if the address is a sitelocal address. */ +isc_result_t +isc_sockaddr_frompath(isc_sockaddr_t *sockaddr, const char *path); +/* + * Create a UNIX domain sockaddr that refers to path. + * + * Returns: + * ISC_R_NOSPACE + * ISC_R_NOTIMPLEMENTED + * ISC_R_SUCCESS + */ + #define ISC_SOCKADDR_FORMATSIZE \ sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:XXX.XXX.XXX.XXX#YYYYY") /* diff --git a/lib/isc/include/isc/socket.h b/lib/isc/include/isc/socket.h index 43df237f1d..3e2fc7a11a 100644 --- a/lib/isc/include/isc/socket.h +++ b/lib/isc/include/isc/socket.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: socket.h,v 1.57 2004/03/05 05:11:01 marka Exp $ */ +/* $Id: socket.h,v 1.58 2005/02/23 01:06:39 marka Exp $ */ #ifndef ISC_SOCKET_H #define ISC_SOCKET_H 1 @@ -144,7 +144,8 @@ struct isc_socket_connev { typedef enum { isc_sockettype_udp = 1, - isc_sockettype_tcp = 2 + isc_sockettype_tcp = 2, + isc_sockettype_unix = 3 } isc_sockettype_t; /* @@ -349,7 +350,7 @@ isc_socket_listen(isc_socket_t *sock, unsigned int backlog); * * Requires: * - * 'socket' is a valid, bound TCP socket. + * 'socket' is a valid, bound TCP socket or a valid, bound UNIX socket. * * Returns: * @@ -699,6 +700,42 @@ isc_socket_ipv6only(isc_socket_t *sock, isc_boolean_t yes); * 'sock' is a valid socket. */ +void +isc_socket_cleanunix(isc_sockaddr_t *addr, isc_boolean_t active); + +/* + * Cleanup UNIX domain sockets in the file-system. If 'active' is true + * then just unlink the socket. If 'active' is false try to determine + * if there is a listener of the socket or not. If no listener is found + * then unlink socket. + * + * Prior to unlinking the path is tested to see if it a socket. + * + * Note: there are a number of race conditions which cannot be avoided + * both in the filesystem and any application using UNIX domain + * sockets (e.g. socket is tested between bind() and listen(), + * the socket is deleted and replaced in the file-system between + * stat() and unlink()). + */ + +isc_boolean_t +isc_socket_permunix(isc_sockaddr_t *sockaddr, isc_uint32_t perm, + isc_uint32_t owner, isc_uint32_t group); +/* + * Set ownership and file permissions on the UNIX domain socket. + * + * Note: On Solaris and SunOS this secures the directory containing + * the socket as Solaris and SunOS do not honour the filesytem + * permissions on the socket. + * + * Requires: + * 'sockaddr' to be a valid UNIX domain sockaddr. + * + * Returns: + * ISC_R_SUCCESS + * ISC_R_FAILURE + */ + ISC_LANG_ENDDECLS #endif /* ISC_SOCKET_H */ diff --git a/lib/isc/netaddr.c b/lib/isc/netaddr.c index aa48a88e5f..55a2c60a90 100644 --- a/lib/isc/netaddr.c +++ b/lib/isc/netaddr.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: netaddr.c,v 1.31 2005/01/19 23:22:50 marka Exp $ */ +/* $Id: netaddr.c,v 1.32 2005/02/23 01:06:37 marka Exp $ */ #include @@ -51,6 +51,12 @@ isc_netaddr_equal(const isc_netaddr_t *a, const isc_netaddr_t *b) { a->zone != b->zone) return (ISC_FALSE); break; +#ifdef ISC_PLATFORM_HAVESYSUNH + case AF_UNIX: + if (strcmp(a->type.un, b->type.un) != 0) + return (ISC_FALSE); + break; +#endif default: return (ISC_FALSE); } @@ -135,6 +141,14 @@ isc_netaddr_totext(const isc_netaddr_t *netaddr, isc_buffer_t *target) { case AF_INET6: type = &netaddr->type.in6; break; +#ifdef ISC_PLATFORM_HAVESYSUNH + case AF_UNIX: + alen = strlen(netaddr->type.un); + if (alen > isc_buffer_availablelength(target)) + return (ISC_R_NOSPACE); + isc_buffer_putmem(target, netaddr->type.un, alen); + return (ISC_R_SUCCESS); +#endif default: return (ISC_R_FAILURE); } @@ -282,6 +296,25 @@ isc_netaddr_fromin6(isc_netaddr_t *netaddr, const struct in6_addr *ina6) { netaddr->type.in6 = *ina6; } +isc_result_t +isc_netaddr_frompath(isc_netaddr_t *netaddr, const char *path) { +#ifdef ISC_PLATFORM_HAVESYSUNH + if (strlen(path) > sizeof(netaddr->type.un) - 1) + return (ISC_R_NOSPACE); + + memset(netaddr, 0, sizeof(*netaddr)); + netaddr->family = AF_UNIX; + strcpy(netaddr->type.un, path); + netaddr->zone = 0; + return (ISC_R_SUCCESS); +#else + UNUSED(netaddr); + UNUSED(path); + return (ISC_R_NOTIMPLEMENTED); +#endif +} + + void isc_netaddr_setzone(isc_netaddr_t *netaddr, isc_uint32_t zone) { /* we currently only support AF_INET6. */ @@ -312,6 +345,12 @@ isc_netaddr_fromsockaddr(isc_netaddr_t *t, const isc_sockaddr_t *s) { t->zone = 0; #endif break; +#ifdef ISC_PLATFORM_HAVESYSUNH + case AF_UNIX: + memcpy(t->type.un, s->type.sun.sun_path, sizeof(t->type.un)); + t->zone = 0; + break; +#endif default: INSIST(0); } diff --git a/lib/isc/sockaddr.c b/lib/isc/sockaddr.c index 2eac099293..388b147aba 100644 --- a/lib/isc/sockaddr.c +++ b/lib/isc/sockaddr.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: sockaddr.c,v 1.61 2004/11/22 23:29:10 marka Exp $ */ +/* $Id: sockaddr.c,v 1.62 2005/02/23 01:06:38 marka Exp $ */ #include @@ -130,6 +130,23 @@ isc_sockaddr_totext(const isc_sockaddr_t *sockaddr, isc_buffer_t *target) { case AF_INET6: snprintf(pbuf, sizeof(pbuf), "%u", ntohs(sockaddr->type.sin6.sin6_port)); break; +#ifdef ISC_PLAFORM_HAVESYSUNH + case AF_UNIX: + plen = strlen(sockaddr->type.sun.sun_path); + if (plen >= isc_buffer_availablelength(target)) + return (ISC_R_NOSPACE); + + isc_buffer_putmem(target, sockaddr->type.sun.sun_path, plen); + + /* + * Null terminate after used region. + */ + isc_buffer_availableregion(target, &avail); + INSIST(avail.length >= 1); + avail.base[0] = '\0'; + + return (ISC_R_SUCCESS); +#endif default: return (ISC_R_FAILURE); } @@ -421,8 +438,12 @@ isc_boolean_t isc_sockaddr_ismulticast(isc_sockaddr_t *sockaddr) { isc_netaddr_t netaddr; - isc_netaddr_fromsockaddr(&netaddr, sockaddr); - return (isc_netaddr_ismulticast(&netaddr)); + if (sockaddr->type.sa.sa_family == AF_INET || + sockaddr->type.sa.sa_family == AF_INET6) { + isc_netaddr_fromsockaddr(&netaddr, sockaddr); + return (isc_netaddr_ismulticast(&netaddr)); + } + return (ISC_FALSE); } isc_boolean_t @@ -457,3 +478,23 @@ isc_sockaddr_islinklocal(isc_sockaddr_t *sockaddr) { } return (ISC_FALSE); } + +isc_result_t +isc_sockaddr_frompath(isc_sockaddr_t *sockaddr, const char *path) { +#ifdef ISC_PLATFORM_HAVESYSUNH + if (strlen(path) >= sizeof(sockaddr->type.sun.sun_path)) + return (ISC_R_NOSPACE); + memset(sockaddr, 0, sizeof(*sockaddr)); + sockaddr->length = sizeof(sockaddr->type.sun); + sockaddr->type.sun.sun_family = AF_UNIX; +#ifdef ISC_PLATFORM_HAVESALEN + sockaddr->type.sun.sun_len = sizeof(sockaddr->type.sun); +#endif + strcpy(sockaddr->type.sun.sun_path, path); + return (ISC_R_SUCCESS); +#else + UNUSED(sockaddr); + UNUSED(path); + return (ISC_R_NOTIMPLEMENTED); +#endif +} diff --git a/lib/isc/unix/include/isc/net.h b/lib/isc/unix/include/isc/net.h index 2044a3cc3d..0818a9084c 100644 --- a/lib/isc/unix/include/isc/net.h +++ b/lib/isc/unix/include/isc/net.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: net.h,v 1.40 2004/04/29 01:37:13 marka Exp $ */ +/* $Id: net.h,v 1.41 2005/02/23 01:06:39 marka Exp $ */ #ifndef ISC_NET_H #define ISC_NET_H 1 @@ -303,6 +303,12 @@ isc_net_enableipv4(void); void isc_net_enableipv6(void); +isc_result_t +isc_net_probeunix(void); +/* + * Returns whether UNIX domain sockets are supported. + */ + #ifdef ISC_PLATFORM_NEEDNTOP const char * isc_net_ntop(int af, const void *src, char *dst, size_t size); diff --git a/lib/isc/unix/net.c b/lib/isc/unix/net.c index b8576f35be..cb4b3ae630 100644 --- a/lib/isc/unix/net.c +++ b/lib/isc/unix/net.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: net.c,v 1.30 2004/04/29 01:37:13 marka Exp $ */ +/* $Id: net.c,v 1.31 2005/02/23 01:06:39 marka Exp $ */ #include @@ -43,6 +43,7 @@ static isc_once_t once_ipv6only = ISC_ONCE_INIT; static isc_once_t once_ipv6pktinfo = ISC_ONCE_INIT; static isc_result_t ipv4_result = ISC_R_NOTFOUND; static isc_result_t ipv6_result = ISC_R_NOTFOUND; +static isc_result_t unix_result = ISC_R_NOTFOUND; static isc_result_t ipv6only_result = ISC_R_NOTFOUND; static isc_result_t ipv6pktinfo_result = ISC_R_NOTFOUND; @@ -137,6 +138,9 @@ initialize_action(void) { #endif #endif #endif +#ifdef ISC_PLATFORM_HAVESYSUNH + unix_result = try_proto(PF_UNIX); +#endif } static void @@ -156,6 +160,12 @@ isc_net_probeipv6(void) { return (ipv6_result); } +isc_result_t +isc_net_probeunix(void) { + initialize(); + return (unix_result); +} + #ifdef ISC_PLATFORM_HAVEIPV6 #ifdef WANT_IPV6 static void diff --git a/lib/isc/unix/socket.c b/lib/isc/unix/socket.c index e932769cc8..2e12083b24 100644 --- a/lib/isc/unix/socket.c +++ b/lib/isc/unix/socket.c @@ -15,13 +15,17 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: socket.c,v 1.243 2004/11/18 21:31:47 marka Exp $ */ +/* $Id: socket.c,v 1.244 2005/02/23 01:06:39 marka Exp $ */ #include #include #include #include +#include +#ifdef ISC_PLATFORM_HAVESYSUNH +#include +#endif #include #include @@ -1364,6 +1368,9 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type, case isc_sockettype_tcp: sock->fd = socket(pf, SOCK_STREAM, IPPROTO_TCP); break; + case isc_sockettype_unix: + sock->fd = socket(pf, SOCK_STREAM, 0); + break; } #ifdef F_DUPFD @@ -1430,7 +1437,8 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type, } #ifdef SO_BSDCOMPAT - if (setsockopt(sock->fd, SOL_SOCKET, SO_BSDCOMPAT, + if (type != isc_sockettype_unix && + setsockopt(sock->fd, SOL_SOCKET, SO_BSDCOMPAT, (void *)&on, sizeof(on)) < 0) { isc__strerror(errno, strbuf, sizeof(strbuf)); UNEXPECTED_ERROR(__FILE__, __LINE__, @@ -2844,6 +2852,190 @@ isc_socket_sendto2(isc_socket_t *sock, isc_region_t *region, return (socket_send(sock, event, task, address, pktinfo, flags)); } +void +isc_socket_cleanunix(isc_sockaddr_t *sockaddr, isc_boolean_t active) { +#ifdef ISC_PLATFORM_HAVESYSUNH + int s; + struct stat sb; + char strbuf[ISC_STRERRORSIZE]; + + if (sockaddr->type.sa.sa_family != AF_UNIX) + return; + +#ifndef S_ISSOCK +#if defined(S_IFMT) && defined(S_IFSOCK) +#define S_ISSOCK(mode) ((mode & S_IFMT)==S_IFSOCK) +#elif defined(_S_IFMT) && defined(S_IFSOCK) +#define S_ISSOCK(mode) ((mode & _S_IFMT)==S_IFSOCK) +#endif +#endif + +#ifndef S_ISFIFO +#if defined(S_IFMT) && defined(S_IFIFO) +#define S_ISFIFO(mode) ((mode & S_IFMT)==S_IFIFO) +#elif defined(_S_IFMT) && defined(S_IFIFO) +#define S_ISFIFO(mode) ((mode & _S_IFMT)==S_IFIFO) +#endif +#endif + +#if !defined(S_ISFIFO) && !defined(S_ISSOCK) +#error You need to define S_ISFIFO and S_ISSOCK as appropriate for your platform. See . +#endif + +#ifndef S_ISFIFO +#define S_ISFIFO(mode) 0 +#endif + +#ifndef S_ISSOCK +#define S_ISSOCK(mode) 0 +#endif + + if (active) { + if (stat(sockaddr->type.sun.sun_path, &sb) < 0) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, + ISC_LOGMODULE_SOCKET, ISC_LOG_ERROR, + "isc_socket_cleanunix: stat(%s): %s", + sockaddr->type.sun.sun_path, strbuf); + return; + } + if (!(S_ISSOCK(sb.st_mode) || S_ISFIFO(sb.st_mode))) { + isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, + ISC_LOGMODULE_SOCKET, ISC_LOG_ERROR, + "isc_socket_cleanunix: %s: not a socket", + sockaddr->type.sun.sun_path); + return; + } + if (unlink(sockaddr->type.sun.sun_path) < 0) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, + ISC_LOGMODULE_SOCKET, ISC_LOG_ERROR, + "isc_socket_cleanunix: unlink(%s): %s", + sockaddr->type.sun.sun_path, strbuf); + } + return; + } + + s = socket(AF_UNIX, SOCK_STREAM, 0); + if (s < 0) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, + ISC_LOGMODULE_SOCKET, ISC_LOG_WARNING, + "isc_socket_cleanunix: socket(%s): %s", + sockaddr->type.sun.sun_path, strbuf); + return; + } + + if (stat(sockaddr->type.sun.sun_path, &sb) < 0) { + switch (errno) { + case ENOENT: /* We exited cleanly last time */ + break; + default: + isc__strerror(errno, strbuf, sizeof(strbuf)); + isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, + ISC_LOGMODULE_SOCKET, ISC_LOG_WARNING, + "isc_socket_cleanunix: stat(%s): %s", + sockaddr->type.sun.sun_path, strbuf); + break; + } + goto cleanup; + } + + if (!(S_ISSOCK(sb.st_mode) || S_ISFIFO(sb.st_mode))) { + isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, + ISC_LOGMODULE_SOCKET, ISC_LOG_WARNING, + "isc_socket_cleanunix: %s: not a socket", + sockaddr->type.sun.sun_path); + goto cleanup; + } + + if (connect(s, (struct sockaddr *)&sockaddr->type.sun, + sizeof(sockaddr->type.sun)) < 0) { + switch (errno) { + case ECONNREFUSED: + case ECONNRESET: + if (unlink(sockaddr->type.sun.sun_path) < 0) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, + ISC_LOGMODULE_SOCKET, + ISC_LOG_WARNING, + "isc_socket_cleanunix: " + "unlink(%s): %s", + sockaddr->type.sun.sun_path, + strbuf); + } + break; + default: + isc__strerror(errno, strbuf, sizeof(strbuf)); + isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, + ISC_LOGMODULE_SOCKET, ISC_LOG_WARNING, + "isc_socket_cleanunix: connect(%s): %s", + sockaddr->type.sun.sun_path, strbuf); + break; + } + } + cleanup: + close(s); +#else + UNUSED(sockaddr); + UNUSED(active); +#endif +} + +isc_boolean_t +isc_socket_permunix(isc_sockaddr_t *sockaddr, isc_uint32_t perm, + isc_uint32_t owner, isc_uint32_t group) +{ +#ifdef ISC_PLATFORM_HAVESYSUNH + isc_result_t result = ISC_R_SUCCESS; + char strbuf[ISC_STRERRORSIZE]; + char path[sizeof(sockaddr->type.sun.sun_path)]; +#ifdef NEED_SECURE_DIRECTORY + char *slash; +#endif + + REQUIRE(sockaddr->type.sa.sa_family == AF_UNIX); + INSIST(strlen(sockaddr->type.sun.sun_path) < sizeof(path)); + strcpy(path, sockaddr->type.sun.sun_path); + +#ifdef NEED_SECURE_DIRECTORY + slash = strrchr(path, '/'); + if (slash != NULL) { + if (slash != path) + *slash = '\0'; + else + strcpy(path, "/"); + } else + strcpy(path, "."); +#endif + + if (chmod(path, perm) < 0) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, + ISC_LOGMODULE_SOCKET, ISC_LOG_ERROR, + "isc_socket_permunix: chmod(%s, %d): %s", + path, perm, strbuf); + result = ISC_R_FAILURE; + } + if (chown(path, owner, group) < 0) { + isc__strerror(errno, strbuf, sizeof(strbuf)); + isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL, + ISC_LOGMODULE_SOCKET, ISC_LOG_ERROR, + "isc_socket_permunix: chown(%s, %d, %d): %s", + path, owner, group, + strbuf); + result = ISC_R_FAILURE; + } + return (result); +#else + UNUSED(sockaddr); + UNUSED(perm); + UNUSED(owner); + UNUSED(group); + return (ISC_R_NOTIMPLEMENTED); +#endif +} + isc_result_t isc_socket_bind(isc_socket_t *sock, isc_sockaddr_t *sockaddr) { char strbuf[ISC_STRERRORSIZE]; @@ -2860,6 +3052,10 @@ isc_socket_bind(isc_socket_t *sock, isc_sockaddr_t *sockaddr) { /* * Only set SO_REUSEADDR when we want a specific port. */ +#ifdef AF_UNIX + if (sock->pf == AF_UNIX) + goto bind_socket; +#endif if (isc_sockaddr_getport(sockaddr) != (in_port_t)0 && setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on, sizeof(on)) < 0) { @@ -2869,6 +3065,9 @@ isc_socket_bind(isc_socket_t *sock, isc_sockaddr_t *sockaddr) { ISC_MSG_FAILED, "failed")); /* Press on... */ } +#ifdef AF_UNIX + bind_socket: +#endif if (bind(sock->fd, &sockaddr->type.sa, sockaddr->length) < 0) { UNLOCK(&sock->lock); switch (errno) { @@ -2945,7 +3144,8 @@ isc_socket_listen(isc_socket_t *sock, unsigned int backlog) { REQUIRE(!sock->listener); REQUIRE(sock->bound); - REQUIRE(sock->type == isc_sockettype_tcp); + REQUIRE(sock->type == isc_sockettype_tcp || + sock->type == isc_sockettype_unix); if (backlog == 0) backlog = SOMAXCONN; diff --git a/lib/isc/win32/include/isc/net.h b/lib/isc/win32/include/isc/net.h index 86497492cf..333051509e 100644 --- a/lib/isc/win32/include/isc/net.h +++ b/lib/isc/win32/include/isc/net.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: net.h,v 1.23 2004/04/29 01:37:14 marka Exp $ */ +/* $Id: net.h,v 1.24 2005/02/23 01:06:40 marka Exp $ */ #ifndef ISC_NET_H #define ISC_NET_H 1 @@ -258,6 +258,17 @@ isc_net_probeipv6(void); * ISC_R_UNEXPECTED */ +isc_result_t +isc_net_probeunix(void); +/* + * Check if UNIX domain sockets are supported. + * + * Returns: + * + * ISC_R_SUCCESS + * ISC_R_NOTFOUND + */ + isc_result_t isc_net_probe_ipv6only(void); /* diff --git a/lib/isc/win32/include/isc/platform.h b/lib/isc/win32/include/isc/platform.h index a94d039dfd..c489d44684 100644 --- a/lib/isc/win32/include/isc/platform.h +++ b/lib/isc/win32/include/isc/platform.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: platform.h,v 1.10 2004/04/19 04:16:55 marka Exp $ */ +/* $Id: platform.h,v 1.11 2005/02/23 01:06:40 marka Exp $ */ #ifndef ISC_PLATFORM_H #define ISC_PLATFORM_H 1 @@ -55,6 +55,12 @@ * and we don't want to redeclare it. */ #define ISC_PLATFORM_NONSTDHERRNO + +/* + * Define if the platform has . + */ +#undef ISC_PLATFORM_HAVESYSUNH + /* * Set up a macro for importing and exporting from the DLL */ diff --git a/lib/isc/win32/libisc.def b/lib/isc/win32/libisc.def index 0ecc39e4c2..aad975428d 100644 --- a/lib/isc/win32/libisc.def +++ b/lib/isc/win32/libisc.def @@ -3,87 +3,118 @@ LIBRARY libisc ; Exported Functions EXPORTS -isc_assertion_setcallback -isc_assertion_typetotext -isc_base64_totext -isc_base64_decodestring -isc_base64_tobuffer -isc_bitstring_init -isc_bitstring_invalidate -isc_bitstring_copy -isc_buffer_allocate -isc_buffer_free -isc__buffer_init -isc__buffer_invalidate -isc__buffer_region -isc__buffer_usedregion -isc__buffer_availableregion +NTReportError +closelog +isc__buffer_activeregion isc__buffer_add -isc__buffer_subtract +isc__buffer_availableregion +isc__buffer_back isc__buffer_clear isc__buffer_consumedregion -isc__buffer_remainingregion -isc__buffer_activeregion -isc__buffer_setactive isc__buffer_first isc__buffer_forward -isc__buffer_back -isc_buffer_compact -isc_buffer_getuint8 -isc__buffer_putuint8 -isc_buffer_getuint16 -isc__buffer_putuint16 -isc_buffer_getuint32 -isc__buffer_putuint32 +isc__buffer_init +isc__buffer_invalidate isc__buffer_putmem isc__buffer_putstr +isc__buffer_putuint16 +isc__buffer_putuint32 +isc__buffer_putuint8 +isc__buffer_region +isc__buffer_remainingregion +isc__buffer_setactive +isc__buffer_subtract +isc__buffer_usedregion +isc__mem_allocate +isc__mem_free +isc__mem_get +isc__mem_put +isc__mem_putanddetach +isc__mem_strdup +isc__mempool_get +isc__mempool_put +isc__strerror +isc_app_block +isc_app_finish +isc_app_onrun +isc_app_reload +isc_app_run +isc_app_shutdown +isc_app_start +isc_app_unblock +isc_assertion_setcallback +isc_assertion_typetotext +isc_base64_decodestring +isc_base64_tobuffer +isc_base64_totext +isc_bitstring_copy +isc_bitstring_init +isc_bitstring_invalidate +isc_buffer_allocate +isc_buffer_compact isc_buffer_copyregion -isc_bufferlist_usedcount +isc_buffer_free +isc_buffer_getuint16 +isc_buffer_getuint32 +isc_buffer_getuint8 isc_bufferlist_availablecount +isc_bufferlist_usedcount isc_commandline_parse - - -isc_entropy_create -isc_entropy_attach -isc_entropy_detach -isc_entropy_createfilesource -isc_entropy_destroysource -isc_entropy_createsamplesource -isc_entropy_createcallbacksource -isc_entropy_stopcallbacksources +isc_condition_broadcast +isc_condition_destroy +isc_condition_init +isc_condition_signal +isc_condition_wait +isc_condition_waituntil +isc_dir_chdir +isc_dir_chroot +isc_dir_close +isc_dir_init +isc_dir_open +isc_dir_read +isc_dir_reset isc_entropy_addcallbacksample isc_entropy_addsample +isc_entropy_attach +isc_entropy_create +isc_entropy_createcallbacksource +isc_entropy_createfilesource +isc_entropy_createsamplesource +isc_entropy_destroysource +isc_entropy_detach isc_entropy_getdata isc_entropy_putdata isc_entropy_stats +isc_entropy_stopcallbacksources isc_entropy_usebestsource -isc_error_setunexpected -isc_error_setfatal -isc_error_unexpected isc_error_fatal isc_error_runtimecheck +isc_error_setfatal +isc_error_setunexpected +isc_error_unexpected isc_event_allocate isc_event_free -isc_file_settime +isc_file_absolutepath +isc_file_basename +isc_file_exists isc_file_getmodtime +isc_file_isabsolute +isc_file_ischdiridempotent +isc_file_iscurrentdir isc_file_mktemplate isc_file_openunique +isc_file_progname isc_file_remove isc_file_rename -isc_file_exists -isc_file_ischdiridempotent -isc_file_isabsolute -isc_file_iscurrentdir -isc_file_template isc_file_renameunique -isc_file_basename -isc_file_progname isc_file_safemovefile -isc_file_absolutepath +isc_file_settime +isc_file_template +isc_file_truncate isc_fsaccess_add +isc_fsaccess_changeowner isc_fsaccess_remove isc_fsaccess_set -isc_fsaccess_changeowner isc_hash_calc isc_hash_create isc_hash_ctxattach @@ -93,350 +124,319 @@ isc_hash_ctxdetach isc_hash_ctxinit isc_hash_destroy isc_hash_init -isc_hex_totext isc_hex_decodestring isc_hex_tobuffer +isc_hex_totext isc_hmacmd5_init isc_hmacmd5_invalidate -isc_hmacmd5_update isc_hmacmd5_sign +isc_hmacmd5_update isc_hmacmd5_verify isc_interfaceiter_create -isc_interfaceiter_first isc_interfaceiter_current -isc_interfaceiter_next isc_interfaceiter_destroy -isc_lex_setcomments +isc_interfaceiter_first +isc_interfaceiter_next +isc_interval_iszero +isc_interval_set +isc_keyboard_canceled +isc_keyboard_close +isc_keyboard_getchar +isc_keyboard_open +isc_lex_close isc_lex_create isc_lex_destroy isc_lex_getcomments -isc_lex_setcomments +isc_lex_getlasttokentext +isc_lex_getmastertoken +isc_lex_getsourceline +isc_lex_getsourcename isc_lex_getspecials -isc_lex_setspecials +isc_lex_gettoken +isc_lex_isfile +isc_lex_openbuffer isc_lex_openfile isc_lex_openstream -isc_lex_openbuffer -isc_lex_close -isc_lex_gettoken -isc_lex_getmastertoken +isc_lex_setcomments +isc_lex_setcomments +isc_lex_setspecials isc_lex_ungettoken -isc_lex_getlasttokentext -isc_lex_getsourcename -isc_lex_getsourceline -isc_lex_isfile -isc_lfsr_init isc_lfsr_generate -isc_lfsr_skip isc_lfsr_generate32 +isc_lfsr_init +isc_lfsr_skip isc_lib_initmsgcat -isc_log_createchannel -isc_log_createchannel +isc_log_categorybyname +isc_log_closefilelogs isc_log_create -isc_logconfig_create -isc_logconfig_get -isc_logconfig_use +isc_log_createchannel +isc_log_createchannel +isc_log_createchannel isc_log_destroy -isc_logconfig_destroy +isc_log_getdebuglevel +isc_log_getduplicateinterval +isc_log_gettag +isc_log_ivwrite +isc_log_ivwrite1 +isc_log_iwrite +isc_log_iwrite1 +isc_log_modulebyname +isc_log_opensyslog isc_log_registercategories isc_log_registermodules -isc_log_createchannel -isc_log_usechannel -isc_log_write -isc_log_vwrite -isc_log_write1 -isc_log_vwrite1 -isc_log_iwrite -isc_log_ivwrite -isc_log_iwrite1 -isc_log_ivwrite1 +isc_log_setcontext isc_log_setdebuglevel -isc_log_getdebuglevel +isc_log_setduplicateinterval +isc_log_settag +isc_log_usechannel +isc_log_vwrite +isc_log_vwrite1 isc_log_wouldlog isc_log_write -isc_log_setduplicateinterval -isc_log_getduplicateinterval -isc_log_settag -isc_log_gettag -isc_log_opensyslog -isc_log_closefilelogs -isc_log_categorybyname -isc_log_modulebyname -isc_log_setcontext +isc_log_write +isc_log_write1 +isc_logconfig_create +isc_logconfig_destroy +isc_logconfig_get +isc_logconfig_use +isc_md5_final isc_md5_init isc_md5_invalidate isc_md5_update -isc_md5_final isc_mem_attach -isc_mem_detach -isc_mem_detach +isc_mem_attach isc_mem_create isc_mem_createx -isc_mem_attach -isc_mem_detach isc_mem_destroy -isc_mem_ondestroy -isc_mem_stats -isc_mem_setdestroycheck -isc_mem_setquota +isc_mem_detach +isc_mem_detach +isc_mem_detach isc_mem_getquota isc_mem_inuse +isc_mem_ondestroy +isc_mem_setdestroycheck +isc_mem_setquota isc_mem_setwater +isc_mem_stats +isc_mempool_associatelock isc_mempool_create isc_mempool_destroy -isc_mempool_setname -isc_mempool_associatelock -isc_mempool_getfreemax -isc_mempool_setfreemax -isc_mempool_getfreecount -isc_mempool_getmaxalloc -isc_mempool_setmaxalloc isc_mempool_getallocated isc_mempool_getfillcount +isc_mempool_getfreecount +isc_mempool_getfreemax +isc_mempool_getmaxalloc isc_mempool_setfillcount -isc__mem_get -isc__mem_putanddetach -isc__mem_put -isc__mem_allocate -isc__mem_free -isc__mem_strdup -isc__mempool_get -isc__mempool_put -isc_msgcat_open +isc_mempool_setfreemax +isc_mempool_setmaxalloc +isc_mempool_setname isc_msgcat_close isc_msgcat_get -isc_mutexblock_init +isc_msgcat_open isc_mutexblock_destroy -isc_netaddr_equal -isc_netaddr_eqprefix -isc_netaddr_masktoprefixlen -isc_netaddr_totext -isc_netaddr_format -isc_netaddr_fromsockaddr -isc_netaddr_fromin -isc_netaddr_fromin6 +isc_mutexblock_init +isc_net_aton +isc_net_aton +isc_net_disableipv4 +isc_net_disableipv6 +isc_net_ntop +isc_net_ntop +isc_net_probe_ipv6only +isc_net_probe_ipv6pktinfo +isc_net_probeipv4 +isc_net_probeipv4 +isc_net_probeipv6 +isc_net_probeipv6 +isc_net_probeunix +isc_net_pton +isc_net_pton isc_netaddr_any isc_netaddr_any6 -isc_netaddr_ismulticast +isc_netaddr_eqprefix +isc_netaddr_equal +isc_netaddr_format +isc_netaddr_fromin +isc_netaddr_fromin6 +isc_netaddr_frompath +isc_netaddr_fromsockaddr isc_netaddr_fromv4mapped +isc_netaddr_ismulticast +isc_netaddr_masktoprefixlen +isc_netaddr_prefixok isc_netaddr_setzone +isc_netaddr_totext isc_netscope_pton -isc_ntpaths_init isc_ntpaths_get +isc_ntpaths_init +isc_once_do isc_ondestroy_init -isc_ondestroy_register isc_ondestroy_notify -isc_task_sendanddetach +isc_ondestroy_register isc_os_ncpus -isc_quota_init -isc_quota_destroy -isc_quota_soft -isc_quota_reserve -isc_quota_release +isc_parse_uint16 +isc_parse_uint32 +isc_parse_uint8 isc_quota_attach +isc_quota_destroy isc_quota_detach -isc_random_seed +isc_quota_init +isc_quota_release +isc_quota_reserve +isc_quota_soft isc_random_get isc_random_jitter +isc_random_seed +isc_ratelimiter_attach isc_ratelimiter_create +isc_ratelimiter_detach +isc_ratelimiter_enqueue isc_ratelimiter_setinterval isc_ratelimiter_setpertic -isc_ratelimiter_enqueue isc_ratelimiter_shutdown -isc_ratelimiter_attach -isc_ratelimiter_detach -isc_resource_setlimit +isc_region_compare isc_resource_getlimit -isc_result_totext +isc_resource_setlimit isc_result_register +isc_result_totext +isc_rwlock_destroy +isc_rwlock_downgrade isc_rwlock_init isc_rwlock_lock isc_rwlock_trylock +isc_rwlock_tryupgrade isc_rwlock_unlock -isc_rwlock_destroy -isc_serial_lt +isc_serial_eq +isc_serial_ge isc_serial_gt isc_serial_le -isc_serial_ge -isc_serial_eq +isc_serial_lt isc_serial_ne +isc_sha1_final isc_sha1_init isc_sha1_invalidate isc_sha1_update -isc_sha1_final -isc_sockaddr_equal -isc_sockaddr_eqaddr -isc_sockaddr_eqaddrprefix -isc_sockaddr_hash isc_sockaddr_any isc_sockaddr_any6 isc_sockaddr_anyofpf +isc_sockaddr_compare +isc_sockaddr_eqaddr +isc_sockaddr_eqaddrprefix +isc_sockaddr_equal +isc_sockaddr_format isc_sockaddr_fromin isc_sockaddr_fromin6 -isc_sockaddr_v6fromin isc_sockaddr_fromnetaddr +isc_sockaddr_frompath +isc_sockaddr_getport +isc_sockaddr_hash +isc_sockaddr_isexperimental +isc_sockaddr_ismulticast isc_sockaddr_pf isc_sockaddr_setport -isc_sockaddr_getport isc_sockaddr_totext -isc_sockaddr_format -isc_sockaddr_ismulticast -isc_socket_create -isc_socket_cancel -;isc_socket_shutdown -isc_socket_attach -isc_socket_detach -isc_socket_bind -isc_socket_listen +isc_sockaddr_v6fromin isc_socket_accept +isc_socket_attach +isc_socket_bind +isc_socket_cancel +isc_socket_cleanunix isc_socket_connect +isc_socket_create +isc_socket_detach +isc_socket_filter isc_socket_getpeername isc_socket_getsockname +isc_socket_gettype +isc_socket_ipv6only +isc_socket_isbound +isc_socket_listen +isc_socket_permunix isc_socket_recv -isc_socket_recvv isc_socket_recv2 +isc_socket_recvv isc_socket_send isc_socket_sendto -isc_socket_sendv -isc_socket_sendtov isc_socket_sendto2 +isc_socket_sendtov +isc_socket_sendv isc_socketmgr_create isc_socketmgr_destroy -isc_socket_gettype -isc_socket_isbound -isc_stdio_open isc_stdio_close -isc_stdio_seek -isc_stdio_read -isc_stdio_write isc_stdio_flush +isc_stdio_open +isc_stdio_read +isc_stdio_seek isc_stdio_sync -isc_string_touint64 +isc_stdio_write +isc_stdtime_get isc_string_separate +isc_string_strlcat +isc_string_strlcpy +isc_string_strlcpy +isc_string_touint64 isc_symtab_create +isc_symtab_define isc_symtab_destroy isc_symtab_lookup -isc_symtab_define isc_symtab_undefine -isc_task_create +isc_syslog_facilityfromstring isc_task_attach -isc_task_detach -isc_task_send -isc_task_sendanddetach -isc_task_purgerange -isc_task_purge -isc_task_purgeevent -isc_task_unsendrange -isc_task_unsend -isc_task_onshutdown -isc_task_shutdown +isc_task_beginexclusive +isc_task_create isc_task_destroy -isc_task_setname +isc_task_detach +isc_task_endexclusive +isc_task_endexclusive +isc_task_getcurrenttime isc_task_getname isc_task_gettag -isc_task_beginexclusive -isc_task_endexclusive -isc_task_endexclusive +isc_task_onshutdown +isc_task_purge +isc_task_purgeevent +isc_task_purgerange +isc_task_send +isc_task_sendanddetach +isc_task_sendanddetach +isc_task_setname +isc_task_shutdown +isc_task_unsend +isc_task_unsendrange isc_taskmgr_create isc_taskmgr_destroy isc_taskpool_create -isc_taskpool_gettask isc_taskpool_destroy -isc_timer_create -isc_timer_reset -isc_timer_touch -isc_timer_attach -isc_timer_detach -isc_timermgr_create -isc_timermgr_destroy -isc_condition_init -isc_condition_wait -isc_condition_signal -isc_condition_broadcast -isc_condition_destroy -isc_condition_waituntil -isc_dir_init -isc_dir_open -isc_dir_read -isc_dir_reset -isc_dir_close -isc_dir_chdir -isc_dir_chroot -isc_net_probeipv4 -isc_net_probeipv6 -isc_net_ntop -isc_net_pton -isc_net_aton -isc_once_do -isc_stdtime_get - +isc_taskpool_gettask +isc_thread_create isc_thread_create isc_thread_join +isc_thread_join +isc_thread_setconcurrency isc_thread_setconcurrency -isc_interval_set -isc_time_subtract -isc_interval_iszero -isc_time_settoepoch -isc_time_isepoch -isc_time_now -isc_time_nowplusinterval -isc_time_compare isc_time_add -isc_time_subtract +isc_time_compare +isc_time_isepoch isc_time_microdiff isc_time_nanoseconds -isc_keyboard_open -isc_keyboard_close -isc_keyboard_getchar -isc_keyboard_canceled -isc_app_start -isc_app_onrun -isc_app_run -isc_app_shutdown -isc_app_reload -isc_app_finish -isc_app_block -isc_app_unblock -isc_thread_create -isc_thread_join -isc_thread_setconcurrency -isc_net_probeipv4 -isc_net_probeipv6 -isc_net_ntop -isc_net_pton -isc_net_aton -openlog -syslog -closelog -isc_syslog_facilityfromstring -NTReportError - -isc_file_truncate -isc__strerror -isc_parse_uint32 -isc_parse_uint16 -isc_parse_uint8 +isc_time_now +isc_time_nowplusinterval +isc_time_settoepoch +isc_time_subtract +isc_time_subtract +isc_timer_attach +isc_timer_create +isc_timer_detach +isc_timer_reset +isc_timer_touch +isc_timermgr_create +isc_timermgr_destroy +isc_timermgr_poke isc_win32os_majorversion isc_win32os_minorversion isc_win32os_servicepackmajor isc_win32os_servicepackminor isc_win32os_versioncheck -isc_socket_ipv6only -isc_region_compare -isc_socket_filter -isc_string_strlcpy -isc_rwlock_tryupgrade -isc_rwlock_downgrade -isc_sockaddr_isexperimental -isc_net_disableipv4 -isc_net_disableipv6 -isc_task_getcurrenttime -isc_net_probe_ipv6only -isc_timermgr_poke -isc_net_probe_ipv6pktinfo -isc_string_strlcat -isc_string_strlcpy -isc_netaddr_prefixok -isc_sockaddr_compare +openlog +syslog ; Exported Data diff --git a/lib/isc/win32/net.c b/lib/isc/win32/net.c index b86eabd062..5061bf735b 100644 --- a/lib/isc/win32/net.c +++ b/lib/isc/win32/net.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: net.c,v 1.10 2004/04/29 01:37:14 marka Exp $ */ +/* $Id: net.c,v 1.11 2005/02/23 01:06:40 marka Exp $ */ #include @@ -148,6 +148,11 @@ isc_net_probeipv6(void) { return (ipv6_result); } +isc_result_t +isc_net_probeunix(void) { + return (ISC_R_NOTFOUND); +} + #ifdef ISC_PLATFORM_HAVEIPV6 #ifdef WANT_IPV6 static void diff --git a/lib/isc/win32/socket.c b/lib/isc/win32/socket.c index 8a6073259c..dfe3da6c8a 100644 --- a/lib/isc/win32/socket.c +++ b/lib/isc/win32/socket.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: socket.c,v 1.35 2004/09/01 04:38:43 marka Exp $ */ +/* $Id: socket.c,v 1.36 2005/02/23 01:06:40 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 @@ -3761,3 +3761,20 @@ isc_socket_ipv6only(isc_socket_t *sock, isc_boolean_t yes) { } #endif } + +void +isc_socket_cleanunix(isc_sockaddr_t *addr, isc_boolean_t active) { + UNUSED(addr); + UNUSED(active); +} + +isc_result_t +isc_socket_permunix(isc_sockaddr_t *addr, isc_uint32_t perm, + isc_uint32_t owner, isc_uint32_t group) +{ + UNUSED(addr); + UNUSED(perm); + UNUSED(owner); + UNUSED(group); + return (ISC_R_NOTIMPLEMENTED); +} diff --git a/lib/isccfg/namedconf.c b/lib/isccfg/namedconf.c index 52e86a2851..4b49a134b0 100644 --- a/lib/isccfg/namedconf.c +++ b/lib/isccfg/namedconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: namedconf.c,v 1.46 2005/01/17 00:46:04 marka Exp $ */ +/* $Id: namedconf.c,v 1.47 2005/02/23 01:06:41 marka Exp $ */ #include @@ -1206,12 +1206,12 @@ static cfg_type_t cfg_type_optional_keyref = { /* * A "controls" statement is represented as a map with the multivalued - * "inet" and "unix" clauses. Inet controls are tuples; unix controls - * are cfg_unsupported_t objects. + * "inet" and "unix" clauses. */ static keyword_type_t controls_allow_kw = { "allow", &cfg_type_bracketed_aml }; + static cfg_type_t cfg_type_controls_allow = { "controls_allow", parse_keyvalue, print_keyvalue, doc_keyvalue, @@ -1220,6 +1220,7 @@ static cfg_type_t cfg_type_controls_allow = { static keyword_type_t controls_keys_kw = { "keys", &cfg_type_keylist }; + static cfg_type_t cfg_type_controls_keys = { "controls_keys", parse_optional_keyvalue, print_keyvalue, doc_optional_keyvalue, @@ -1232,16 +1233,57 @@ static cfg_tuplefielddef_t inetcontrol_fields[] = { { "keys", &cfg_type_controls_keys, 0 }, { NULL, NULL, 0 } }; + static cfg_type_t cfg_type_inetcontrol = { "inetcontrol", cfg_parse_tuple, cfg_print_tuple, cfg_doc_tuple, &cfg_rep_tuple, inetcontrol_fields }; +static keyword_type_t controls_perm_kw = { + "perm", &cfg_type_uint32 }; + +static cfg_type_t cfg_type_controls_perm = { + "controls_perm", parse_keyvalue, + print_keyvalue, doc_keyvalue, + &cfg_rep_uint32, &controls_perm_kw +}; + +static keyword_type_t controls_owner_kw = { + "owner", &cfg_type_uint32 }; + +static cfg_type_t cfg_type_controls_owner = { + "controls_owner", parse_keyvalue, + print_keyvalue, doc_keyvalue, + &cfg_rep_uint32, &controls_owner_kw +}; + +static keyword_type_t controls_group_kw = { + "group", &cfg_type_uint32 }; + +static cfg_type_t cfg_type_controls_group = { + "controls_allow", parse_keyvalue, + print_keyvalue, doc_keyvalue, + &cfg_rep_uint32, &controls_group_kw +}; + +static cfg_tuplefielddef_t unixcontrol_fields[] = { + { "path", &cfg_type_qstring, 0 }, + { "perm", &cfg_type_controls_perm, 0 }, + { "owner", &cfg_type_controls_owner, 0 }, + { "group", &cfg_type_controls_group, 0 }, + { "keys", &cfg_type_controls_keys, 0 }, + { NULL, NULL, 0 } +}; + +static cfg_type_t cfg_type_unixcontrol = { + "unixcontrol", cfg_parse_tuple, cfg_print_tuple, cfg_doc_tuple, &cfg_rep_tuple, + unixcontrol_fields +}; + static cfg_clausedef_t controls_clauses[] = { { "inet", &cfg_type_inetcontrol, CFG_CLAUSEFLAG_MULTI }, - { "unix", &cfg_type_unsupported, - CFG_CLAUSEFLAG_MULTI|CFG_CLAUSEFLAG_NOTIMP }, + { "unix", &cfg_type_unixcontrol, CFG_CLAUSEFLAG_MULTI }, { NULL, NULL, 0 } }; From 65b15657bf19c983abfb8327304ccc01f60c8cdd Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 23 Feb 2005 03:08:42 +0000 Subject: [PATCH 100/130] regen --- doc/misc/options | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/misc/options b/doc/misc/options index 5bcfb9765c..b64655d034 100644 --- a/doc/misc/options +++ b/doc/misc/options @@ -133,7 +133,8 @@ options { controls { inet ( | | * ) [ port ( | * ) ] allow { ; ... } [ keys { ; ... } ]; - unix ; // not implemented + unix perm owner group + [ keys { ; ... } ]; }; acl { ; ... }; From fca6550a9766fe9b0e203ff91399fae4ef3f4030 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 23 Feb 2005 23:35:11 +0000 Subject: [PATCH 101/130] newcopyrights --- util/copyrights | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/util/copyrights b/util/copyrights index 26c94f4ce3..f67f68263f 100644 --- a/util/copyrights +++ b/util/copyrights @@ -823,7 +823,7 @@ ./config.h.win32 C 1999,2000,2001,2004 ./config.sub X 1999,2000,2001 ./configure X 1998,1999,2000,2001 -./configure.in SH 1998,1999,2000,2001,2002,2003,2004 +./configure.in SH 1998,1999,2000,2001,2002,2003,2004,2005 ./conftools/perllib/dnsconf/DNSConf-macros.h C 2000,2001,2004 ./conftools/perllib/dnsconf/DNSConf.i C 2000,2001,2004 ./conftools/perllib/dnsconf/Makefile.PL PERL 2000,2001,2004 @@ -1612,7 +1612,7 @@ ./lib/dns/dbiterator.c C 1999,2000,2001,2004 ./lib/dns/dbtable.c C 1999,2000,2001,2004 ./lib/dns/diff.c C 2000,2001,2002,2003,2004,2005 -./lib/dns/dispatch.c C 1999,2000,2001,2002,2003,2004 +./lib/dns/dispatch.c C 1999,2000,2001,2002,2003,2004,2005 ./lib/dns/dnssec.c C 1999,2000,2001,2002,2003,2004 ./lib/dns/ds.c C 2002,2003,2004 ./lib/dns/dst_api.c C.NAI 1999,2000,2001,2002,2003,2004 @@ -1928,7 +1928,7 @@ ./lib/isc/include/isc/ondestroy.h C 2000,2001,2004 ./lib/isc/include/isc/os.h C 2000,2001,2004 ./lib/isc/include/isc/parseint.h C 2001,2002,2004 -./lib/isc/include/isc/platform.h.in C 1999,2000,2001,2002,2003,2004 +./lib/isc/include/isc/platform.h.in C 1999,2000,2001,2002,2003,2004,2005 ./lib/isc/include/isc/print.h C 1999,2000,2001,2003,2004 ./lib/isc/include/isc/quota.h C 2000,2001,2004 ./lib/isc/include/isc/random.h C 1999,2000,2001,2004 @@ -1941,8 +1941,8 @@ ./lib/isc/include/isc/rwlock.h C 1998,1999,2000,2001,2003,2004 ./lib/isc/include/isc/serial.h C 1999,2000,2001,2004 ./lib/isc/include/isc/sha1.h C 2000,2001,2004 -./lib/isc/include/isc/sockaddr.h C 1998,1999,2000,2001,2002,2003,2004 -./lib/isc/include/isc/socket.h C 1998,1999,2000,2001,2002,2004 +./lib/isc/include/isc/sockaddr.h C 1998,1999,2000,2001,2002,2003,2004,2005 +./lib/isc/include/isc/socket.h C 1998,1999,2000,2001,2002,2004,2005 ./lib/isc/include/isc/stdio.h C 2000,2001,2004 ./lib/isc/include/isc/stdlib.h C 2003,2004 ./lib/isc/include/isc/string.h C 2000,2001,2003,2004 @@ -2005,7 +2005,7 @@ ./lib/isc/rwlock.c C 1998,1999,2000,2001,2003,2004 ./lib/isc/serial.c C 1999,2000,2001,2004 ./lib/isc/sha1.c C 2000,2001,2003,2004 -./lib/isc/sockaddr.c C 1999,2000,2001,2002,2003,2004 +./lib/isc/sockaddr.c C 1999,2000,2001,2002,2003,2004,2005 ./lib/isc/string.c C 1999,2000,2001,2003,2004 ./lib/isc/strtoul.c C 2003,2004 ./lib/isc/symtab.c C 1996,1997,1998,1999,2000,2001,2004 @@ -2033,7 +2033,7 @@ ./lib/isc/unix/include/isc/dir.h C 1999,2000,2001,2004 ./lib/isc/unix/include/isc/int.h C 1999,2000,2001,2004 ./lib/isc/unix/include/isc/keyboard.h C 2000,2001,2004 -./lib/isc/unix/include/isc/net.h C 1999,2000,2001,2002,2003,2004 +./lib/isc/unix/include/isc/net.h C 1999,2000,2001,2002,2003,2004,2005 ./lib/isc/unix/include/isc/netdb.h C 1999,2000,2001,2004 ./lib/isc/unix/include/isc/offset.h C 2000,2001,2004 ./lib/isc/unix/include/isc/stat.h C 2004 @@ -2044,10 +2044,10 @@ ./lib/isc/unix/interfaceiter.c C 1999,2000,2001,2002,2003,2004 ./lib/isc/unix/ipv6.c C 1999,2000,2001,2004 ./lib/isc/unix/keyboard.c C 2000,2001,2004 -./lib/isc/unix/net.c C 1999,2000,2001,2002,2003,2004 +./lib/isc/unix/net.c C 1999,2000,2001,2002,2003,2004,2005 ./lib/isc/unix/os.c C 2000,2001,2004 ./lib/isc/unix/resource.c C 2000,2001,2004 -./lib/isc/unix/socket.c C 1998,1999,2000,2001,2002,2003,2004 +./lib/isc/unix/socket.c C 1998,1999,2000,2001,2002,2003,2004,2005 ./lib/isc/unix/socket_p.h C 2000,2001,2004 ./lib/isc/unix/stdio.c C 2000,2001,2004 ./lib/isc/unix/stdtime.c C 1999,2000,2001,2004 @@ -2078,13 +2078,13 @@ ./lib/isc/win32/include/isc/ipv6.h C 2000,2001,2002,2004,2005 ./lib/isc/win32/include/isc/keyboard.h C 2000,2001,2004 ./lib/isc/win32/include/isc/mutex.h C 1998,1999,2000,2001,2004 -./lib/isc/win32/include/isc/net.h C 1999,2000,2001,2002,2003,2004 +./lib/isc/win32/include/isc/net.h C 1999,2000,2001,2002,2003,2004,2005 ./lib/isc/win32/include/isc/netdb.h C 1999,2000,2001,2004 ./lib/isc/win32/include/isc/ntgroups.h C 2001,2004 ./lib/isc/win32/include/isc/ntpaths.h C 2000,2001,2004 ./lib/isc/win32/include/isc/offset.h C 2000,2001,2004 ./lib/isc/win32/include/isc/once.h C 1999,2000,2001,2004 -./lib/isc/win32/include/isc/platform.h C 2001,2004 +./lib/isc/win32/include/isc/platform.h C 2001,2004,2005 ./lib/isc/win32/include/isc/stat.h C 2000,2001,2003,2004 ./lib/isc/win32/include/isc/stdtime.h C 1999,2000,2001,2004 ./lib/isc/win32/include/isc/strerror.h C 2001,2004 @@ -2099,14 +2099,14 @@ ./lib/isc/win32/libisc.dsp X 2001 ./lib/isc/win32/libisc.dsw X 2001 ./lib/isc/win32/libisc.mak X 2001 -./lib/isc/win32/net.c C 1999,2000,2001,2002,2003,2004 +./lib/isc/win32/net.c C 1999,2000,2001,2002,2003,2004,2005 ./lib/isc/win32/netdb.h C 2000,2001,2004 ./lib/isc/win32/ntgroups.c C 2001,2004 ./lib/isc/win32/ntpaths.c C 2001,2004 ./lib/isc/win32/once.c C 1999,2000,2001,2004 ./lib/isc/win32/os.c C 2000,2001,2002,2004 ./lib/isc/win32/resource.c C 2000,2001,2004 -./lib/isc/win32/socket.c C 2000,2001,2002,2003,2004 +./lib/isc/win32/socket.c C 2000,2001,2002,2003,2004,2005 ./lib/isc/win32/stdio.c C 2000,2001,2004 ./lib/isc/win32/stdtime.c C 1999,2000,2001,2004 ./lib/isc/win32/strerror.c C 2001,2002,2004 From c2a5a4a3cf815bce5fcc28180d9301a3d76023a5 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 24 Feb 2005 00:33:35 +0000 Subject: [PATCH 102/130] update copyright notice --- configure.in | 4 ++-- lib/dns/dispatch.c | 4 ++-- lib/isc/include/isc/platform.h.in | 4 ++-- lib/isc/include/isc/sockaddr.h | 4 ++-- lib/isc/include/isc/socket.h | 4 ++-- lib/isc/sockaddr.c | 4 ++-- lib/isc/unix/include/isc/net.h | 4 ++-- lib/isc/unix/net.c | 4 ++-- lib/isc/unix/socket.c | 4 ++-- lib/isc/win32/include/isc/net.h | 4 ++-- lib/isc/win32/include/isc/platform.h | 4 ++-- lib/isc/win32/net.c | 4 ++-- lib/isc/win32/socket.c | 4 ++-- 13 files changed, 26 insertions(+), 26 deletions(-) diff --git a/configure.in b/configure.in index 1acbc9de56..80d6b260ab 100644 --- a/configure.in +++ b/configure.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 1998-2003 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -18,7 +18,7 @@ AC_DIVERT_PUSH(1)dnl esyscmd([sed "s/^/# /" COPYRIGHT])dnl AC_DIVERT_POP()dnl -AC_REVISION($Revision: 1.372 $) +AC_REVISION($Revision: 1.373 $) AC_INIT(lib/dns/name.c) AC_PREREQ(2.13) diff --git a/lib/dns/dispatch.c b/lib/dns/dispatch.c index 755c99765b..c1d6c202a5 100644 --- a/lib/dns/dispatch.c +++ b/lib/dns/dispatch.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dispatch.c,v 1.121 2005/02/23 01:06:37 marka Exp $ */ +/* $Id: dispatch.c,v 1.122 2005/02/24 00:33:33 marka Exp $ */ #include diff --git a/lib/isc/include/isc/platform.h.in b/lib/isc/include/isc/platform.h.in index e4428080ea..200d897a78 100644 --- a/lib/isc/include/isc/platform.h.in +++ b/lib/isc/include/isc/platform.h.in @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: platform.h.in,v 1.35 2005/02/23 01:06:38 marka Exp $ */ +/* $Id: platform.h.in,v 1.36 2005/02/24 00:33:34 marka Exp $ */ #ifndef ISC_PLATFORM_H #define ISC_PLATFORM_H 1 diff --git a/lib/isc/include/isc/sockaddr.h b/lib/isc/include/isc/sockaddr.h index f7afe8e5e8..f26e711525 100644 --- a/lib/isc/include/isc/sockaddr.h +++ b/lib/isc/include/isc/sockaddr.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: sockaddr.h,v 1.44 2005/02/23 01:06:38 marka Exp $ */ +/* $Id: sockaddr.h,v 1.45 2005/02/24 00:33:34 marka Exp $ */ #ifndef ISC_SOCKADDR_H #define ISC_SOCKADDR_H 1 diff --git a/lib/isc/include/isc/socket.h b/lib/isc/include/isc/socket.h index 3e2fc7a11a..575aa009d5 100644 --- a/lib/isc/include/isc/socket.h +++ b/lib/isc/include/isc/socket.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: socket.h,v 1.58 2005/02/23 01:06:39 marka Exp $ */ +/* $Id: socket.h,v 1.59 2005/02/24 00:33:34 marka Exp $ */ #ifndef ISC_SOCKET_H #define ISC_SOCKET_H 1 diff --git a/lib/isc/sockaddr.c b/lib/isc/sockaddr.c index 388b147aba..3bffb6128a 100644 --- a/lib/isc/sockaddr.c +++ b/lib/isc/sockaddr.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: sockaddr.c,v 1.62 2005/02/23 01:06:38 marka Exp $ */ +/* $Id: sockaddr.c,v 1.63 2005/02/24 00:33:33 marka Exp $ */ #include diff --git a/lib/isc/unix/include/isc/net.h b/lib/isc/unix/include/isc/net.h index 0818a9084c..c56537fe14 100644 --- a/lib/isc/unix/include/isc/net.h +++ b/lib/isc/unix/include/isc/net.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: net.h,v 1.41 2005/02/23 01:06:39 marka Exp $ */ +/* $Id: net.h,v 1.42 2005/02/24 00:33:34 marka Exp $ */ #ifndef ISC_NET_H #define ISC_NET_H 1 diff --git a/lib/isc/unix/net.c b/lib/isc/unix/net.c index cb4b3ae630..e7f067bdfa 100644 --- a/lib/isc/unix/net.c +++ b/lib/isc/unix/net.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: net.c,v 1.31 2005/02/23 01:06:39 marka Exp $ */ +/* $Id: net.c,v 1.32 2005/02/24 00:33:34 marka Exp $ */ #include diff --git a/lib/isc/unix/socket.c b/lib/isc/unix/socket.c index 2e12083b24..c0f045c45e 100644 --- a/lib/isc/unix/socket.c +++ b/lib/isc/unix/socket.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: socket.c,v 1.244 2005/02/23 01:06:39 marka Exp $ */ +/* $Id: socket.c,v 1.245 2005/02/24 00:33:34 marka Exp $ */ #include diff --git a/lib/isc/win32/include/isc/net.h b/lib/isc/win32/include/isc/net.h index 333051509e..13c99b177a 100644 --- a/lib/isc/win32/include/isc/net.h +++ b/lib/isc/win32/include/isc/net.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: net.h,v 1.24 2005/02/23 01:06:40 marka Exp $ */ +/* $Id: net.h,v 1.25 2005/02/24 00:33:35 marka Exp $ */ #ifndef ISC_NET_H #define ISC_NET_H 1 diff --git a/lib/isc/win32/include/isc/platform.h b/lib/isc/win32/include/isc/platform.h index c489d44684..bb58ae44c6 100644 --- a/lib/isc/win32/include/isc/platform.h +++ b/lib/isc/win32/include/isc/platform.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: platform.h,v 1.11 2005/02/23 01:06:40 marka Exp $ */ +/* $Id: platform.h,v 1.12 2005/02/24 00:33:35 marka Exp $ */ #ifndef ISC_PLATFORM_H #define ISC_PLATFORM_H 1 diff --git a/lib/isc/win32/net.c b/lib/isc/win32/net.c index 5061bf735b..20b5e25ac0 100644 --- a/lib/isc/win32/net.c +++ b/lib/isc/win32/net.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: net.c,v 1.11 2005/02/23 01:06:40 marka Exp $ */ +/* $Id: net.c,v 1.12 2005/02/24 00:33:35 marka Exp $ */ #include diff --git a/lib/isc/win32/socket.c b/lib/isc/win32/socket.c index dfe3da6c8a..b7855b7746 100644 --- a/lib/isc/win32/socket.c +++ b/lib/isc/win32/socket.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: socket.c,v 1.36 2005/02/23 01:06:40 marka Exp $ */ +/* $Id: socket.c,v 1.37 2005/02/24 00:33:35 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 From 4f7f21e50d55df1d278b6710ab166227b89bef95 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 24 Feb 2005 03:22:23 +0000 Subject: [PATCH 103/130] new draft --- ....txt => draft-ietf-dnsext-dhcid-rr-09.txt} | 91 +- ...raft-ietf-dnsext-dnssec-experiments-00.txt | 841 +++++++++++ .../draft-ietf-dnsext-dnssec-opt-in-06.txt | 1177 +++++++++++++++ .../draft-ietf-dnsext-dnssec-trans-00.txt | 784 ---------- .../draft-ietf-dnsext-dnssec-trans-02.txt | 839 +++++++++++ ...5.txt => draft-ietf-dnsext-ecc-key-06.txt} | 410 +++-- ...t => draft-ietf-dnsext-insensitive-05.txt} | 1336 +++++++++-------- ...s-37.txt => draft-ietf-dnsext-mdns-38.txt} | 730 +++++---- ...-00.txt => draft-ietf-dnsext-nsec3-01.txt} | 427 ++++-- ...xt => draft-ietf-dnsext-rfc2538bis-01.txt} | 253 ++-- ...raft-ietf-dnsext-trustupdate-timers-00.txt | 729 +++++++++ ....txt => draft-ietf-dnsext-tsig-sha-01.txt} | 83 +- .../draft-ietf-dnsext-wcard-clarify-03.txt | 818 ---------- .../draft-ietf-dnsext-wcard-clarify-05.txt | 842 +++++++++++ doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt | 1120 -------------- doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt | 1123 ++++++++++++++ ...dnsop-dnssec-operational-practices-03.txt} | 1193 ++++++++------- .../draft-ietf-dnsop-inaddr-required-05.txt | 301 ---- .../draft-ietf-dnsop-inaddr-required-06.txt | 424 ++++++ ...etf-dnsop-key-rollover-requirements-01.txt | 391 ----- ...etf-dnsop-key-rollover-requirements-02.txt | 389 +++++ 21 files changed, 8969 insertions(+), 5332 deletions(-) rename doc/draft/{draft-ietf-dnsext-dhcid-rr-08.txt => draft-ietf-dnsext-dhcid-rr-09.txt} (88%) create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-opt-in-06.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-trans-00.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt rename doc/draft/{draft-ietf-dnsext-ecc-key-05.txt => draft-ietf-dnsext-ecc-key-06.txt} (71%) rename doc/draft/{draft-ietf-dnsext-insensitive-04.txt => draft-ietf-dnsext-insensitive-05.txt} (83%) rename doc/draft/{draft-ietf-dnsext-mdns-37.txt => draft-ietf-dnsext-mdns-38.txt} (84%) rename doc/draft/{draft-ietf-dnsext-nsec3-00.txt => draft-ietf-dnsext-nsec3-01.txt} (79%) rename doc/draft/{draft-ietf-dnsext-rfc2538bis-00.txt => draft-ietf-dnsext-rfc2538bis-01.txt} (87%) create mode 100644 doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt rename doc/draft/{draft-ietf-dnsext-tsig-sha-00.txt => draft-ietf-dnsext-tsig-sha-01.txt} (83%) delete mode 100644 doc/draft/draft-ietf-dnsext-wcard-clarify-03.txt create mode 100644 doc/draft/draft-ietf-dnsext-wcard-clarify-05.txt delete mode 100644 doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt create mode 100644 doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt rename doc/draft/{draft-ietf-dnsop-dnssec-operational-practices-02.txt => draft-ietf-dnsop-dnssec-operational-practices-03.txt} (68%) delete mode 100644 doc/draft/draft-ietf-dnsop-inaddr-required-05.txt create mode 100644 doc/draft/draft-ietf-dnsop-inaddr-required-06.txt delete mode 100644 doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt create mode 100644 doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt similarity index 88% rename from doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt rename to doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt index 09776618f2..2cd972473d 100644 --- a/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt +++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt @@ -1,20 +1,22 @@ + + DNSEXT M. Stapp Internet-Draft Cisco Systems, Inc. -Expires: January 14, 2005 T. Lemon +Expires: August 13, 2005 T. Lemon A. Gustafsson Nominum, Inc. - July 16, 2004 + February 9, 2005 A DNS RR for Encoding DHCP Information (DHCID RR) - + Status of this Memo This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each + 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 @@ -30,17 +32,17 @@ Status of this Memo 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 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. + This Internet-Draft will expire on August 13, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2005). Abstract @@ -48,15 +50,15 @@ Abstract 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] +Stapp, et al. Expires August 13, 2005 [Page 1] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 + proposes storing client identifiers in the DNS to unambiguously 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. @@ -79,8 +81,8 @@ Table of Contents 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 - 9.2 Informative References . . . . . . . . . . . . . . . . . . . 8 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8 + 9.2 Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 @@ -107,10 +109,9 @@ Table of Contents - -Stapp, et al. Expires January 14, 2005 [Page 2] +Stapp, et al. Expires August 13, 2005 [Page 2] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 1. Terminology @@ -164,9 +165,9 @@ Internet-Draft The DHCID RR July 2004 -Stapp, et al. Expires January 14, 2005 [Page 3] +Stapp, et al. Expires August 13, 2005 [Page 3] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 3.1 DHCID RDATA format @@ -220,9 +221,9 @@ Internet-Draft The DHCID RR July 2004 -Stapp, et al. Expires January 14, 2005 [Page 4] +Stapp, et al. Expires August 13, 2005 [Page 4] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 some variable-length identifying data. @@ -276,9 +277,9 @@ Internet-Draft The DHCID RR July 2004 -Stapp, et al. Expires January 14, 2005 [Page 5] +Stapp, et al. Expires August 13, 2005 [Page 5] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 3.5.1 Example 1 @@ -289,8 +290,8 @@ Internet-Draft The DHCID RR July 2004 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). + 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 @@ -305,8 +306,8 @@ Internet-Draft The DHCID RR July 2004 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). + 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 @@ -332,9 +333,9 @@ Internet-Draft The DHCID RR July 2004 -Stapp, et al. Expires January 14, 2005 [Page 6] +Stapp, et al. Expires August 13, 2005 [Page 6] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 that the client desires to use to compute a client identity hash, and @@ -388,9 +389,9 @@ Internet-Draft The DHCID RR July 2004 -Stapp, et al. Expires January 14, 2005 [Page 7] +Stapp, et al. Expires August 13, 2005 [Page 7] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 9. References @@ -403,8 +404,8 @@ Internet-Draft The DHCID RR 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. + [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. @@ -420,8 +421,8 @@ Internet-Draft The DHCID RR July 2004 [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. - [8] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. + [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. @@ -431,8 +432,8 @@ Internet-Draft The DHCID RR July 2004 (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. + "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. @@ -444,9 +445,9 @@ Internet-Draft The DHCID RR July 2004 -Stapp, et al. Expires January 14, 2005 [Page 8] +Stapp, et al. Expires August 13, 2005 [Page 8] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 Authors' Addresses @@ -458,7 +459,7 @@ Authors' Addresses USA Phone: 978.936.1535 - EMail: mjs@cisco.com + Email: mjs@cisco.com Ted Lemon @@ -467,7 +468,7 @@ Authors' Addresses Redwood City, CA 94063 USA - EMail: mellon@nominum.com + Email: mellon@nominum.com Andreas Gustafsson @@ -476,7 +477,7 @@ Authors' Addresses Redwood City, CA 94063 USA - EMail: gson@nominum.com + Email: gson@nominum.com @@ -500,9 +501,9 @@ Authors' Addresses -Stapp, et al. Expires January 14, 2005 [Page 9] +Stapp, et al. Expires August 13, 2005 [Page 9] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 Intellectual Property Statement @@ -543,7 +544,7 @@ Disclaimer of Validity Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2005). 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. @@ -556,6 +557,6 @@ Acknowledgment -Stapp, et al. Expires January 14, 2005 [Page 10] +Stapp, et al. Expires August 13, 2005 [Page 10] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt new file mode 100644 index 0000000000..6c897b92b1 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt @@ -0,0 +1,841 @@ + + +Network Working Group D. Blacka +Internet-Draft Verisign, Inc. +Expires: August 3, 2005 February 2, 2005 + + + DNSSEC Experiments + draft-ietf-dnsext-dnssec-experiments-00 + +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 August 3, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + In the long history of the development of the DNS security [1] + extensions (DNSSEC), a number of alternate methodologies and + modifications have been proposed and rejected for practical, rather + than strictly technical, reasons. There is a desire to be able to + experiment with these alternate methods in the public DNS. This + document describes a methodology for deploying alternate, + non-backwards-compatible, DNSSEC methodologies in an experimental + fashion without disrupting the deployment of standard DNSSEC. + + + +Blacka Expires August 3, 2005 [Page 1] + +Internet-Draft DNSSEC Experiments February 2005 + + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . 8 + 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 11 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 10.1 Normative References . . . . . . . . . . . . . . . . . . . 13 + 10.2 Informative References . . . . . . . . . . . . . . . . . . 13 + Editorial Comments . . . . . . . . . . . . . . . . . . . . . 14 + Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 2] + +Internet-Draft DNSSEC Experiments February 2005 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [4]) and the DNS security extensions ([1], [2], and [3]. + + 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 [5]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 3] + +Internet-Draft DNSSEC Experiments February 2005 + + +2. Overview + + Historically, experimentation with DNSSEC alternatives has been a + problematic endeavor. There has typically been a desire to both + introduce non-backwards-compatible changes to DNSSEC, and to try + these changes on real zones in the public DNS. This creates a + problem when the change to DNSSEC would make all or part of the zone + using those changes appear bogus or otherwise broken to existing + DNSSEC-aware resolvers. + + This document describes a standard methodology for setting up public + DNSSEC experiments. This methodology addresses the issue of + co-existence with standard DNSSEC and DNS by using unknown algorithm + identifiers to hide the experimental DNSSEC protocol modifications + from standard DNSSEC-aware resolvers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 4] + +Internet-Draft DNSSEC Experiments February 2005 + + +3. Experiments + + When discussing DNSSEC experiments, it is necessary to classify these + experiments into two broad categories: + + Backwards-Compatible: describes experimental changes that, while not + strictly adhering to the DNSSEC standard, are nonetheless + interoperable with clients and server that do implement the DNSSEC + standard. + Non-Backwards-Compatible: describes experiments that would cause a + standard DNSSEC-aware resolver to (incorrectly) determine that all + or part of a zone is bogus, or to otherwise not interoperable with + standard DNSSEC clients and servers. + + Not included in these terms are experiments with the core DNS + protocol itself. + + The methodology described in this document is not necessary for + backwards-compatible experiments, although it certainly could be used + if desired. + + Note that, in essence, this metholodolgy would also be used to + introduce a new DNSSEC algorithm, independently from any DNSSEC + experimental protocol change. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 5] + +Internet-Draft DNSSEC Experiments February 2005 + + +4. Method + + The core of the methodology is the use of only "unknown" algorithms + to sign the experimental zone, and more importantly, having only + unknown algorithm DS records for the delegation to the zone at the + parent. + + This technique works because of the way DNSSEC-compliant validators + are expected to work in the presence of a DS set with only unknown + algorithms. From [3], Section 5.2: + + 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. + + And further: + + 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. + + While this behavior isn't strictly mandatory (as marked by MUST), it + is unlikely that a validator would not implement the behavior, or, + more to the point, it will not violate this behavior in an unsafe way + (see below (Section 6).) + + Because we are talking about experiments, it is recommended that + private algorithm numbers be used (see [2], appendix A.1.1 + [Comment.1].) Normally, instead of actually inventing new signing + algorithms, the recommended path is to create alternate algorithm + identifiers that are aliases for the existing, known algorithms. + While, strictly speaking, it is only necessary to create an alternate + identifier for the mandatory algorithms (currently, this is only + algorithm 5, RSASHA1), it is RECOMMENDED that all OPTIONAL defined + algorithms be aliased as well. + + It is RECOMMENDED that for a particular DNSSEC experiment, a + particular domain name base is chosen for all new algorithms, then + the algorithm number (or name) is prepended to it. For example, for + experiment A, the base name of "dnssec-experiment-a.example.com" is + chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are + defined to be "3.dnssec-experiment-a.example.com" and + "5.dnssec-experiment-a.example.com". However, any unique identifier + will suffice. + + + +Blacka Expires August 3, 2005 [Page 6] + +Internet-Draft DNSSEC Experiments February 2005 + + + Using this method, resolvers (or, more specificially, DNSSEC + validators) essentially indicate their ability to understand the + DNSSEC experiment's semantics by understanding what the new algorithm + identifiers signify. + + This method creates two classes of DNSSEC-aware servers and + resolvers: servers and resolvers that are aware of the experiment + (and thus recognize the experiments algorithm identifiers and + experimental semantics), and servers and resolvers that are unware of + the experiment. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 7] + +Internet-Draft DNSSEC Experiments February 2005 + + +5. Defining an Experiment + + The DNSSEC experiment must define the particular set of (previously + unknown) algorithms that identify the experiment, and define what + each unknown algorithm identifier means. Typically, unless the + experiment is actually experimenting with a new DNSSEC algorithm, + this will be a mapping of private algorithm identifiers to existing, + known algorithms. + + Typically, the experiment will choose a DNS name as the algorithm + identifier base. This DNS name SHOULD be under the control of the + authors of the experiment. Then the experiment will define a mapping + between known mandatory and optional algorithms into this private + algorithm identifier space. Alternately, the experiment MAY use the + OID private algorithm space instead (using algorithm number 254), or + may choose non-private algorithm numbers, although this would require + an IANA allocation (see below (Section 9).) + + For example, an experiment might specify in its description the DNS + name "dnssec-experiment-a.example.com" as the base name, and provide + the mapping of "3.dnssec-experiment-a.example.com" is an alias of + DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is + an alias of DNSSEC algorithm 5 (RSASHA1). + + Resolvers MUST then only recognize the experiment's semantics when + present in a zone signed by one or more of these private algorithms. + + In general, however, resolvers involved in the experiment are + expected to understand both standard DNSSEC and the defined + experimental DNSSEC protocol, although this isn't, strictly speaking, + required. + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 8] + +Internet-Draft DNSSEC Experiments February 2005 + + +6. Considerations + + There are a number of considerations with using this methodology. + + 1. Under some circumstances, it may be that the experiment will not + be sufficiently masked by this technique and may cause resolution + problem for resolvers not aware of the experiment. For instance, + the resolver may look at the not validatable response and + conclude that the response is bogus, either due to local policy + or implementation details. This is not expected to be the common + case, however. + 2. It will, in general, not be possible for DNSSEC-aware resolvers + not aware of the experiment to build a chain of trust through an + experimental zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 9] + +Internet-Draft DNSSEC Experiments February 2005 + + +7. Transitions + + If an experiment is successful, there may be a desire to move the + experiment to a standards-track extension. One way to do so would be + to move from private algorithm numbers to IANA allocated algorithm + numbers, with otherwise the same meaning. This would still leave a + divide between resolvers that understood the extension versus + resolvers that did not. It would, in essence, create an additional + version of DNSSEC. + + An alternate technique might be to do a typecode rollover, thus + actually creating a definitive new version of DNSSEC. There may be + other transition techniques available, as well. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 10] + +Internet-Draft DNSSEC Experiments February 2005 + + +8. Security Considerations + + Zones using this methodology will be considered insecure by all + resolvers except those aware of the experiment. It is not generally + possible to create a secure delegation from an experimental zone that + will be followed by resolvers unaware of the experiment. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 11] + +Internet-Draft DNSSEC Experiments February 2005 + + +9. IANA Considerations + + IANA may need to allocate new DNSSEC algorithm numbers if that + transition approach is taken, or the experiment decides to use + allocated numbers to begin with. No IANA action is required to + deploy an experiment using private algorithm identifiers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 12] + +Internet-Draft DNSSEC Experiments February 2005 + + +10. References + +10.1 Normative References + + [1] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [2] Arends, R., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + + [3] Arends, R., "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-09 (work in + progress), October 2004. + +10.2 Informative References + + [4] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 13] + +Internet-Draft DNSSEC Experiments February 2005 + + +Editorial Comments + + [Comment.1] Note: how private algorithms work in DNSSEC is not well + explained in the DNSSECbis RFCs. In particular, how to + validate that the DS records contain only unknown + algorithms is not explained at all. + + +Author's Address + + David Blacka + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 14] + +Internet-Draft DNSSEC Experiments February 2005 + + +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 (2005). 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. + + + + +Blacka Expires August 3, 2005 [Page 15] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-06.txt new file mode 100644 index 0000000000..c4103183d5 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-06.txt @@ -0,0 +1,1177 @@ + + +DNSEXT R. Arends +Internet-Draft Telematica Instituut +Expires: August 4, 2005 M. Kosters + D. Blacka + Verisign, Inc. + February 3, 2005 + + + DNSSEC Opt-In + draft-ietf-dnsext-dnssec-opt-in-06 + +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 August 4, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + In the DNS security extensions (DNSSEC, defined in RFC 2535bis, [3], + [4], and [5]), delegations to unsigned subzones are cryptographically + secured. Maintaining this cryptography is not practical or + necessary. This document describes an experimental "Opt-In" model + that allows administrators to omit this cryptography and manage the + + + +Arends, et al. Expires August 4, 2005 [Page 1] + +Internet-Draft DNSSEC Opt-In February 2005 + + + cost of adopting DNSSEC with large zones. + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 5 + 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1 Server Considerations . . . . . . . . . . . . . . . . . . 7 + 4.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . 7 + 4.1.2 Insecure Delegation Responses . . . . . . . . . . . . 7 + 4.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . 7 + 4.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . 8 + 4.2 Client Considerations . . . . . . . . . . . . . . . . . . 8 + 4.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . 8 + 4.2.2 Validation Process Changes . . . . . . . . . . . . . . 8 + 4.2.3 NSEC Record Caching . . . . . . . . . . . . . . . . . 9 + 4.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . 9 + 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 13 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 + 11.2 Informative References . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 + A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 20 + Intellectual Property and Copyright Statements . . . . . . . . 21 + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 2] + +Internet-Draft DNSSEC Opt-In February 2005 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [1]), DNS security extensions ([3], [4], and [5], referred to in this + document as "RFC 2535bis"), and DNSSEC terminology (RFC 3090 [10]) is + assumed. + + The following abbreviations and terms are used in this document: + + RR: is used to refer to a DNS resource record. + RRset: refers to a Resource Record Set, as defined by [8]. In this + document, the RRset is also defined to include the covering RRSIG + records, if any exist. + signed name: refers to a DNS name that has, at minimum, a (signed) + NSEC record. + unsigned name: refers to a DNS name that does not (at least) have a + NSEC record. + covering NSEC record/RRset: is the NSEC record used to prove + (non)existence of a particular name or RRset. This means that for + a RRset or name 'N', the covering NSEC record has the name 'N', or + has an owner name less than 'N' and "next" name greater than 'N'. + delegation: refers to a NS RRset with a name different from the + current zone apex (non-zone-apex), signifying a delegation to a + subzone. + secure delegation: refers to a signed name containing a delegation + (NS RRset), and a signed DS RRset, signifying a delegation to a + signed subzone. + insecure delegation: refers to a signed name containing a delegation + (NS RRset), but lacking a DS RRset, signifying a delegation to an + unsigned subzone. + Opt-In insecure delegation: refers to an unsigned name containing + only a delegation NS RRset. The covering NSEC record uses the + Opt-In methodology described in this document. + + The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [7]. + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 3] + +Internet-Draft DNSSEC Opt-In February 2005 + + +2. Overview + + The cost to cryptographically secure delegations to unsigned zones is + high for large delegation-centric zones and zones where insecure + delegations will be updated rapidly. For these zones, the costs of + maintaining the NSEC record chain may be extremely high relative to + the gain of cryptographically authenticating existence of unsecured + zones. + + This document describes an experimental method of eliminating the + superfluous cryptography present in secure delegations to unsigned + zones. Using "Opt-In", a zone administrator can choose to remove + insecure delegations from the NSEC chain. This is accomplished by + extending the semantics of the NSEC record by using a redundant bit + in the type map. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 4] + +Internet-Draft DNSSEC Opt-In February 2005 + + +3. Experimental Status + + This document describes an EXPERIMENTAL extension to DNSSEC. It + interoperates with non-experimental DNSSEC using the technique + described in [6]. This experiment is identified with the following + private algorithms (using algorithm 253): + + "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA, + and + "4.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5, + RSASHA1. + + Servers wishing to sign and serve zones that utilize Opt-In MUST sign + the zone with one or more of these private algorithms. This requires + the signing tools and servers to support private algorithms, as well + as Opt-In. + + Resolvers wishing to validate Opt-In zones MUST only do so when the + zone is signed using one or more of these private algorithms. + + The remainder of this document assumes that the servers and resolvers + involved are aware of and are involved in this experiment. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 5] + +Internet-Draft DNSSEC Opt-In February 2005 + + +4. Protocol Additions + + In RFC 2535bis, delegation NS RRsets are not signed, but are instead + accompanied by a NSEC RRset of the same name and a DS record. The + security status of the subzone is determined by the presence or + absence of the DS RRset, cryptographically proven by the NSEC record. + Opt-In expands this definition by allowing insecure delegations to + exist within an otherwise signed zone without the corresponding NSEC + record at the delegation's owner name. These insecure delegations + are proven insecure by using a covering NSEC record. + + Since this represents a change of the interpretation of NSEC records, + resolvers must be able to distinguish between RFC 2535bis NSEC + records and Opt-In NSEC records. This is accomplished by "tagging" + the NSEC records that cover (or potentially cover) insecure + delegation nodes. This tag is indicated by the absence of the NSEC + bit in the type map. Since the NSEC bit in the type map merely + indicates the existence of the record itself, this bit is redundant + and safe for use as a tag. + + An Opt-In tagged NSEC record does not assert the (non)existence of + the delegations that it covers (except for a delegation with the same + name). This allows for the addition or removal of these delegations + without recalculating or resigning records in the NSEC chain. + However, Opt-In tagged NSEC records do assert the (non)existence of + other RRsets. + + An Opt-In NSEC record MAY have the same name as an insecure + delegation. In this case, the delegation is proven insecure by the + lack of a DS bit in type map and the signed NSEC record does assert + the existence of the delegation. + + Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC + records and RFC 2535bis NSEC records. If a NSEC record is not + Opt-In, there MUST NOT be any insecure delegations (or any other + records) between it and the RRsets indicated by the 'next domain + name' in the NSEC RDATA. If it is Opt-In, there MUST only be + insecure delegations between it and the next node indicated by the + 'next domain name' in the NSEC RDATA. + + In summary, + + o An Opt-In NSEC type is identified by a zero-valued (or + not-specified) NSEC bit in the type bit map of the NSEC record. + o A RFC2535bis NSEC type is identified by a one-valued NSEC bit in + the type bit map of the NSEC record. + + and, + + + +Arends, et al. Expires August 4, 2005 [Page 6] + +Internet-Draft DNSSEC Opt-In February 2005 + + + o An Opt-In NSEC record does not assert the non-existence of a name + between its owner name and "next" name, although it does assert + that any name in this span MUST be an insecure delegation. + o An Opt-In NSEC record does assert the (non)existence of RRsets + with the same owner name. + +4.1 Server Considerations + + Opt-In imposes some new requirements on authoritative DNS servers. + +4.1.1 Delegations Only + + This specification dictates that only insecure delegations may exist + between the owner and "next" names of an Opt-In tagged NSEC record. + Signing tools SHOULD NOT generate signed zones that violate this + restriction. Servers SHOULD refuse to load and/or serve zones that + violate this restriction. + +4.1.2 Insecure Delegation Responses + + When returning an Opt-In insecure delegation, the server MUST return + the covering NSEC RRset in the Authority section. + + In RFC 2535bis, NSEC records already must be returned along with the + insecure delegation. The primary difference that this proposal + introduces is that the Opt-In tagged NSEC record will have a + different owner name from the delegation RRset. This may require + implementations to do a NSEC search on cached responses. + +4.1.3 Wildcards and Opt-In + + RFC 2535bis describes the practice of returning NSEC records to prove + the non-existence of an applicable wildcard in non-existent name + responses. This NSEC record can be described as a "negative wildcard + proof". The use of Opt-In NSEC records changes the necessity for + this practice. For non-existent name responses when the query name + (qname) is covered by an Opt-In tagged NSEC record, servers MAY + choose to omit the wildcard proof record, and clients MUST NOT treat + the absence of this NSEC record as a validation error. + + The intent of the RFC 2535bis negative wildcard proof requirement is + to prevent malicious users from undetectably removing valid wildcard + responses. In order for this cryptographic proof to work, the + resolver must be able to prove: + + 1. The exact qname does not exist. This is done by the "normal" + NSEC record. + + + + +Arends, et al. Expires August 4, 2005 [Page 7] + +Internet-Draft DNSSEC Opt-In February 2005 + + + 2. No applicable wildcard exists. This is done by returning a NSEC + record proving that the wildcard does not exist (this is the + negative wildcard proof). + + However, if the NSEC record covering the exact qname is an Opt-In + NSEC record, the resolver will not be able to prove the first part of + this equation, as the qname might exist as an insecure delegation. + Thus, since the total proof cannot be completed, the negative + wildcard proof NSEC record is not useful. + + The negative wildcard proof is also not useful when returned as part + of an Opt-In insecure delegation response for a similar reason: the + resolver cannot prove that the qname does or does not exist, and + therefore cannot prove that a wildcard expansion is valid. + + The presence of an Opt-In tagged NSEC record does not change the + practice of returning a NSEC along with a wildcard expansion. Even + though the Opt-In NSEC will not be able to prove that the wildcard + expansion is valid, it will prove that the wildcard expansion is not + masking any signed records. + +4.1.4 Dynamic Update + + Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In + particular, it introduces the need for rules that describe when to + add or remove a delegation name from the NSEC chain. This document + does not attempt to define these rules. Until these rules are + defined, servers MUST NOT process DNS Dynamic Update requests against + zones that use Opt-In NSEC records. + +4.2 Client Considerations + + Opt-In imposes some new requirements on security-aware resolvers + (caching or otherwise). + +4.2.1 Delegations Only + + As stated in the "Server Considerations" section above, this + specification restricts the namespace covered by Opt-In tagged NSEC + records to insecure delegations only. Thus, resolvers MUST reject as + invalid any records that fall within an Opt-In NSEC record's span + that are not NS records or corresponding glue records. + +4.2.2 Validation Process Changes + + This specification does not change the resolver's resolution + algorithm. However, it does change the DNSSEC validation process. + Resolvers MUST be able to use Opt-In tagged NSEC records to + + + +Arends, et al. Expires August 4, 2005 [Page 8] + +Internet-Draft DNSSEC Opt-In February 2005 + + + cryptographically prove the validity and security status (as + insecure) of a referral. Resolvers determine the security status of + the referred-to zone as follows: + + o In RFC 2535bis, the security status is proven by the existence or + absence of a DS RRset at the same name as the delegation. The + existence of the DS RRset indicates that the referred-to zone is + signed. The absence of the DS RRset is proven using a verified + NSEC record of the same name that does not have the DS bit set in + the type map. This NSEC record MAY also be tagged as Opt-In. + o Using Opt-In, the security status is proven by the existence of a + DS record (for signed) or the presence of a verified Opt-In tagged + NSEC record that covers the delegation name. That is, the NSEC + record does not have the NSEC bit set in the type map, and the + delegation name falls between the NSEC's owner and "next" name. + + Using Opt-In does not substantially change the nature of following + referrals within DNSSEC. At every delegation point, the resolver + will have cryptographic proof that the subzone is signed or unsigned. + + When receiving either an Opt-In insecure delegation response or a + non-existent name response where that name is covered by an Opt-In + tagged NSEC record, the resolver MUST NOT require proof (in the form + of a NSEC record) that a wildcard did not exist. + +4.2.3 NSEC Record Caching + + Caching resolvers MUST be able to retrieve the appropriate covering + Opt-In NSEC record when returning referrals that need them. This + requirement differs from RFC 2535bis in that the covering NSEC will + not have the same owner name as the delegation. Some implementations + may have to use new methods for finding these NSEC records. + +4.2.4 Use of the AD bit + + The AD bit, as defined by [2] and [5], MUST NOT be set when: + + o sending a non-existent name (NXDOMAIN) response where the covering + NSEC is tagged as Opt-In. + o sending an Opt-In insecure delegation response, unless the + covering (Opt-In) NSEC record's owner name equals the delegation + name. + + This rule is based on what the Opt-In NSEC record actually proves: + for names that exist between the Opt-In NSEC record's owner and + "next" names, the Opt-In NSEC record cannot prove the non-existence + or existence of the name. As such, not all data in the response has + been cryptographically verified, so the AD bit cannot be set. + + + +Arends, et al. Expires August 4, 2005 [Page 9] + +Internet-Draft DNSSEC Opt-In February 2005 + + +5. Benefits + + Using Opt-In allows administrators of large and/or changing + delegation-centric zones to minimize the overhead involved in + maintaining the security of the zone. + + Opt-In accomplishes this by eliminating the need for NSEC records for + insecure delegations. This, in a zone with a large number of + delegations to unsigned subzones, can lead to substantial space + savings (both in memory and on disk). Additionally, Opt-In allows + for the addition or removal of insecure delegations without modifying + the NSEC record chain. Zones that are frequently updating insecure + delegations (e.g., TLDs) can avoid the substantial overhead of + modifying and resigning the affected NSEC records. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 10] + +Internet-Draft DNSSEC Opt-In February 2005 + + +6. Example + + Consider the zone EXAMPLE, shown below. This is a zone where all of + the NSEC records are tagged as Opt-In. + + Example A: Fully Opt-In Zone. + + EXAMPLE. SOA ... + EXAMPLE. RRSIG SOA ... + EXAMPLE. NS FIRST-SECURE.EXAMPLE. + EXAMPLE. RRSIG NS ... + EXAMPLE. DNSKEY ... + EXAMPLE. RRSIG DNSKEY ... + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS RRSIG DNSKEY + EXAMPLE. RRSIG NSEC ... + + FIRST-SECURE.EXAMPLE. A ... + FIRST-SECURE.EXAMPLE. RRSIG A ... + FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG + FIRST-SECURE.EXAMPLE. RRSIG NSEC ... + + NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NS.NOT-SECURE.EXAMPLE. A ... + + NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG + NOT-SECURE-2.EXAMPLE RRSIG NSEC ... + + SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. + SECOND-SECURE.EXAMPLE. DS ... + SECOND-SECURE.EXAMPLE. RRSIG DS ... + SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY + SECOND-SECURE.EXAMPLE. RRSIG NSEC ... + + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE. + NS.UNSIGNED.EXAMPLE. A ... + + + In this example, a query for a signed RRset (e.g., + "FIRST-SECURE.EXAMPLE A"), or a secure delegation + ("WWW.SECOND-SECURE.EXAMPLE A") will result in a normal RFC 2535bis + response. + + A query for a nonexistent RRset will result in a response that + differs from RFC 2535bis by: the NSEC record will be tagged as + Opt-In, there may be no NSEC record proving the non-existence of a + matching wildcard record, and the AD bit will not be set. + + + + +Arends, et al. Expires August 4, 2005 [Page 11] + +Internet-Draft DNSSEC Opt-In February 2005 + + + A query for an insecure delegation RRset (or a referral) will return + both the answer (in the Authority section) and the corresponding + Opt-In NSEC record to prove that it is not secure. + + Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A + + + RCODE=NOERROR, AD=0 + + Answer Section: + + Authority Section: + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE + SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS + SECOND-SECURE.EXAMPLE. RRSIG NSEC ... + + Additional Section: + NS.UNSIGNED.EXAMPLE. A ... + + In the Example A.1 zone, the EXAMPLE. node MAY use either style of + NSEC record, because there are no insecure delegations that occur + between it and the next node, FIRST-SECURE.EXAMPLE. In other words, + Example A would still be a valid zone if the NSEC record for EXAMPLE. + was changed to the following RR: + + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS + RRSIG DNSKEY NSEC ) + + However, the other NSEC records (FIRST-SECURE.EXAMPLE. and + SECOND-SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are + insecure delegations in the range they define. (NOT-SECURE.EXAMPLE. + and UNSIGNED.EXAMPLE., respectively). + + NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that + is part of the NSEC chain and also covered by an Opt-In tagged NSEC + record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot + be removed from the zone without modifying and resigning the prior + NSEC record. Delegations with names that fall between + NOT-SECURE-2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or + removed without resigning any NSEC records. + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 12] + +Internet-Draft DNSSEC Opt-In February 2005 + + +7. Transition Issues + + Opt-In is not backwards compatible with RFC 2535bis. RFC 2535bis + compliant DNSSEC implementations will not recognize Opt-In tagged + NSEC records as different from RFC 2535bis NSEC records. Because of + this, RFC 2535bis implementations will reject all Opt-In insecure + delegations within a zone as invalid. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 13] + +Internet-Draft DNSSEC Opt-In February 2005 + + +8. Security Considerations + + Opt-In allows for unsigned names, in the form of delegations to + unsigned subzones, to exist within an otherwise signed zone. All + unsigned names are, by definition, insecure, and their validity or + existence cannot by cryptographically proven. + + In general: + + o Records with unsigned names (whether existing or not) suffer from + the same vulnerabilities as records in an unsigned zone. These + vulnerabilites are described in more detail in [12] (note in + particular sections 2.3, "Name Games" and 2.6, "Authenticated + Denial"). + o Records with signed names have the same security whether or not + Opt-In is used. + + Note that with or without Opt-In, an insecure delegation may have its + contents undetectably altered by an attacker. Because of this, the + primary difference in security that Opt-In introduces is the loss of + the ability to prove the existence or nonexistence of an insecure + delegation within the span of an Opt-In NSEC record. + + In particular, this means that a malicious entity may be able to + insert or delete records with unsigned names. These records are + normally NS records, but this also includes signed wildcard + expansions (while the wildcard record itself is signed, its expanded + name is an unsigned name). + + For example, if a resolver received the following response from the + example zone above: + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 14] + +Internet-Draft DNSSEC Opt-In February 2005 + + + Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A + + RCODE=NOERROR + + Answer Section: + + Authority Section: + DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \ + RRSIG DNSKEY + EXAMPLE. RRSIG NSEC ... + + Additional Section: + + + The resolver would have no choice but to believe that the referral to + NS.FORGED. is valid. If a wildcard existed that would have been + expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could + have undetectably removed it and replaced it with the forged + delegation. + + Note that being able to add a delegation is functionally equivalent + to being able to add any record type: an attacker merely has to forge + a delegation to nameserver under his/her control and place whatever + records needed at the subzone apex. + + While in particular cases, this issue may not present a significant + security problem, in general it should not be lightly dismissed. + Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. + In particular, zone signing tools SHOULD NOT default to Opt-In, and + MAY choose to not support Opt-In at all. + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 15] + +Internet-Draft DNSSEC Opt-In February 2005 + + +9. IANA Considerations + + None. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 16] + +Internet-Draft DNSSEC Opt-In February 2005 + + +10. Acknowledgments + + The contributions, suggestions and remarks of the following persons + (in alphabetic order) to this draft are acknowledged: + + Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf + Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning, + Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian + Wellington. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 17] + +Internet-Draft DNSSEC Opt-In February 2005 + + +11. References + +11.1 Normative References + + [1] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [3] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [4] Arends, R., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + + [5] Arends, R., "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-09 (work in + progress), October 2004. + + [6] Blacka, D., "DNSSEC Experiments", + draft-blacka-dnssec-experiments-00 (work in progress), December + 2004. + +11.2 Informative References + + [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [9] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC + 2137, April 1997. + + [10] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, + December 2001. + + [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + + + + + +Arends, et al. Expires August 4, 2005 [Page 18] + +Internet-Draft DNSSEC Opt-In February 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Mark Kosters + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: markk@verisign.com + URI: http://www.verisignlabs.com + + + David Blacka + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 19] + +Internet-Draft DNSSEC Opt-In February 2005 + + +Appendix A. Implementing Opt-In using "Views" + + In many cases, it may be convenient to implement an Opt-In zone by + combining two separately maintained "views" of a zone at request + time. In this context, "view" refers to a particular version of a + zone, not to any specific DNS implementation feature. + + In this scenario, one view is the secure view, the other is the + insecure (or legacy) view. The secure view consists of an entirely + signed zone using Opt-In tagged NSEC records. The insecure view + contains no DNSSEC information. It is helpful, although not + necessary, for the secure view to be a subset (minus DNSSEC records) + of the insecure view. + + In addition, the only RRsets that may solely exist in the insecure + view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and + the zone apex NS RRset) MUST be signed and in the secure view. + + These two views may be combined at request time to provide a virtual, + single Opt-In zone. The following algorithm is used when responding + to each query: + V_A is the secure view as described above. + V_B is the insecure view as described above. + R_A is a response generated from V_A, following RFC 2535bis. + R_B is a response generated from V_B, following DNS resolution as + per RFC 1035 [1]. + R_C is the response generated by combining R_A with R_B, as + described below. + A query is DNSSEC-aware if it either has the DO bit [11] turned + on, or is for a DNSSEC-specific record type. + + + + 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, + generate and return R_B, otherwise + 2. Generate R_A. + 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise + 4. Generate R_B and combine it with R_A to form R_C: + For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the + records from R_A into R_B, EXCEPT the AUTHORITY section SOA + record, if R_B's RCODE = NOERROR. + 5. Return R_C. + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 20] + +Internet-Draft DNSSEC Opt-In February 2005 + + +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 (2005). 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 August 4, 2005 [Page 21] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-00.txt deleted file mode 100644 index 94ff297f8a..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-trans-00.txt +++ /dev/null @@ -1,784 +0,0 @@ - - -DNS Extensions Working Group R. Arends -Internet-Draft Telematica Instituut -Expires: December 7, 2004 P. Koch - Universitaet Bielefeld - J. Schlyter - NIC-SE - June 8, 2004 - - - Evaluating DNSSEC Transition Mechanisms - draft-ietf-dnsext-dnssec-trans-00.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on December 7, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document collects and summarizes different proposals for - alternative and additional strategies for authenticated denial in DNS - responses, evaluates these proposals and gives a recommendation for a - way forward. - - - - - - - - -Arends, et al. Expires December 7, 2004 [Page 1] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . 3 - 2.1 Mechanisms Updating DNSSEC-bis . . . . . . . . . . . . . . . 4 - 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . . . . 4 - 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . . . . 4 - 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . . . . 5 - 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . . . . 7 - 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . . . . 8 - 2.2 Mechanisms not Updating DNSSEC-bis . . . . . . . . . . . . . 9 - 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . . . . 9 - 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . . . . 9 - 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . . . . 10 - 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . . 13 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires December 7, 2004 [Page 2] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -1. Introduction - - The working group consents on not including NSEC-alt in the - DNSSEC-bis documents. The working group considers to take up - "prevention of zone enumeration" as a work item. - - There may be multiple mechanisms to allow for co-existence with - DNSSEC-bis. The chairs allow the working group a little over a week - (up to June 12) to come to consensus on a possible modification to - the document to enable gentle rollover. If that consensus cannot be - reached the DNSSEC-bis documents will go out as-is. - - To ease the process of getting consensus, a summary of the proposed - solutions and analysis of the pros and cons were written during the - weekend. - - This summary includes: - - An inventory of the proposed mechanisms to make a transition to - future work on authenticated denial of existence. - List the known Pros and Cons, possibly provide new arguments, and - possible security considerations of these mechanisms. - Provide a recommendation on a way forward that is least disruptive - to the DNSSEC-bis specifications as they stand and keep an open - path to other methods for authenticated denial existence. - - The descriptions of the proposals in this document are coarse and do - not cover every detail necessary for implementation. In any case, - documentation and further study is needed before implementaion and/or - deployment, including those which seem to be solely operational in - nature. - -2. Transition Mechanisms - - In the light of recent discussions and past proposals, we have found - several ways to allow for transition to future expansion of - authenticated denial. We tried to illuminate the paths and pitfalls - in these ways forward. Some proposals lead to a versioning of DNSSEC, - where DNSSEC-bis may co-exist with DNSSEC-ter, other proposals are - 'clean' but may cause delay, while again others may be plain hacks. - - Some paths do not introduce versioning, and might require the current - DNSSEC-bis documents to be fully updated to allow for extensions to - authenticated denial mechanisms. Other paths introduce versioning and - do not (or minimally) require DNSSEC-bis documents to be updated, - allowing DNSSEC-bis to be deployed, while future versions can be - drafted independent from or partially depending on DNSSEC-bis. - - - - -Arends, et al. Expires December 7, 2004 [Page 3] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -2.1 Mechanisms Updating DNSSEC-bis - -2.1.1 Dynamic NSEC Synthesis - - This proposal assumes that NSEC RRs and the authenticating RRSIG will - be generated dynamically to just cover the (non existent) query name. - The owner name is (the) one preceding the name queried for, the Next - Owner Name Field has the value of the Query Name Field + 1 (first - successor in canonical ordering). A separate key (the normal ZSK or a - separate ZSK per authoritative server) would be used for RRSIGs on - NSEC RRs. This is a defense against enumeration, though it has the - presumption of online signing. - -2.1.1.1 Coexistence and Migration - - There is no change in interpretation other then that the next owner - name might or might not exist. - -2.1.1.2 Limitations - - This introduces an unbalanced cost between query and response - generation due to dynamic generation of signatures. - -2.1.1.3 Amendments to DNSSEC-bis - - The current DNSSEC-bis documents might need to be updated to indicate - that the next owner name might not be an existing name in the zone. - This is not a real change to the spec since implementers have been - warned not to synthesize with previously cached NSEC records. A - specific bit to identify the dynamic signature generating Key might - be useful as well, to prevent it from being used to fake positive - data. - -2.1.1.4 Cons - - Unbalanced cost is a ground for DDoS. Though this protects against - enumeration, it is not really a path for versioning. - -2.1.1.5 Pros - - Hardly any amendments to DNSSEC-bis. - -2.1.2 Add Versioning/Subtyping to Current NSEC - - This proposal introduces versioning for the NSEC RR type (a.k.a. - subtyping) by adding a (one octet) version field to the NSEC RDATA. - Version number 0 is assigned to the current (DNSSEC-bis) meaning, - making this an 'Must Be Zero' (MBZ) for the to be published docset. - - - -Arends, et al. Expires December 7, 2004 [Page 4] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -2.1.2.1 Coexistence and Migration - - Since the versioning is done inside the NSEC RR, different versions - may coexist. However, depending on future methods, that may or may - not be useful inside a single zone. Resolvers cannot ask for specific - NSEC versions but may be able to indicate version support by means of - a to be defined EDNS option bit. - -2.1.2.2 Limitations - - There are no technical limitations, though it will cause delay to - allow testing of the (currently unknown) new NSEC interpretation. - - Since the versioning and signaling is done inside the NSEC RR, future - methods will likely be restricted to a single RR type authenticated - denial (as opposed to e.g. NSEC-alt, which currently proposes three - RR types). - -2.1.2.3 Amendments to DNSSEC-bis - - Full Update of the current DNSSEC-bis documents to provide for new - fields in NSEC, while specifying behavior in case of unknown field - values. - -2.1.2.4 Cons - - Though this is a clean and clear path without versioning DNSSEC, it - takes some time to design, gain consensus, update the current - dnssec-bis document, test and implement a new authenticated denial - record. - -2.1.2.5 Pros - - Does not introduce an iteration to DNSSEC while providing a clear and - clean migration strategy. - -2.1.3 Type Bit Map NSEC Indicator - - Bits in the type-bit-map are reused or allocated to signify the - interpretation of NSEC. - - This proposal assumes that future extensions make use of the existing - NSEC RDATA syntax, while it may need to change the interpretation of - the RDATA or introduce an alternative denial mechanism, invoked by - the specific type-bit-map-bits. - - - - - - -Arends, et al. Expires December 7, 2004 [Page 5] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -2.1.3.1 Coexistence and migration - - Old and new NSEC meaning could coexist, depending how the signaling - would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR - types are available as well as those covering meta/query types or - types to be specifically allocated. - -2.1.3.2 Limitations - - This mechanism uses an NSEC field that was not designed for that - purpose. Similar methods were discussed during the Opt-In discussion - and the Silly-State discussion. - -2.1.3.3 Amendments to DNSSEC-bis - - The specific type-bit-map-bits must be allocated and they need to be - specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) - interpretation. Also, behaviour of the resolver and validator must be - documented in case unknown values are encountered for the MBZ field. - Currently the protocol document specifies that the validator MUST - ignore the setting of the NSEC and the RRSIG bits, while other bits - are only used for the specific purpose of the type-bit-map field - -2.1.3.4 Cons - - The type-bit-map was not designed for this purpose. It is a - straightforward hack. Text in protocol section 5.4 was put in - specially to defend against this usage. - -2.1.3.5 Pros - - No change needed to the on-the-wire protocol as specified in the - current docset. - -2.1.4 New Apex Type - - This introduces a new Apex type (parallel to the zone's SOA) - indicating the DNSSEC version (or authenticated denial) used in or - for this zone. - -2.1.4.1 Coexistence and Migration - - Depending on the design of this new RR type multiple denial - mechanisms may coexist in a zone. Old validators will not understand - and thus ignore the new type, so interpretation of the new NSEC - scheme may fail, negative responses may appear 'bogus'. - - - - - -Arends, et al. Expires December 7, 2004 [Page 6] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -2.1.4.2 Limitations - - A record of this kind is likely to carry additional feature/ - versioning indications unrelated to the current question of - authenticated denial. - -2.1.4.3 Amendments to DNSSEC-bis - - The current DNSSEC-bis documents need to be updated to indicate that - the absence of this type indicates dnssec-bis, and that the (mere) - presence of this type indicated unknown versions. - -2.1.4.4 Cons - - The only other 'zone' or 'apex' record is the SOA record. Though this - proposal is not new, it is yet unknown how it might fulfill - authenticated denial extensions. This new RR type would only provide - for a generalized signaling mechanism, not the new authenticated - denial scheme. Since it is likely to be general in nature, due to - this generality consensus is not to be reached soon. - -2.1.4.5 Pros - - This approach would allow for a lot of other per zone information to - be transported or signaled to both (slave) servers and resolvers. - -2.1.5 NSEC White Lies - - This proposal disables one part of NSEC (the pointer part) by means - of a special target (root, apex, owner, ...), leaving intact only the - ability to authenticate denial of existence of RR sets, not denial of - existence of domain names (NXDOMAIN). It may be necessary to have one - working NSEC to prove the absence of a wildcard. - -2.1.5.1 Coexistence and Migration - - The NSEC target can be specified per RR, so standard NSEC and 'white - lie' NSEC can coexist in a zone. There is no need for migration - because no versioning is introduced or intended. - -2.1.5.2 Limitations - - This proposal breaks the protocol and is applicable to certain types - of zones only (no wildcard, no deep names, delegation only). Most of - the burden is put on the resolver side and operational consequences - are yet to be studied. - - - - - -Arends, et al. Expires December 7, 2004 [Page 7] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -2.1.5.3 Amendments to DNSSEC-bis - - The current DNSSEC-bis documents need to be updated to indicate that - the NXDOMAIN responses may be insecure. - -2.1.5.4 Cons - - Strictly speaking this breaks the protocol and doesn't fully fulfill - the requirements for authenticated denial of existence. Security - implications need to be carefully documented: search path problems - (forged denial of existence may lead to wrong expansion of non-FQDNs, - cf. RFC 1535); replay attacks to deny existence of records - -2.1.5.5 Pros - - Hardly any amendments to DNSSEC-bis. Operational "trick" that is - available anyway. - -2.1.6 NSEC Optional via DNSSKEY Flag - - A new DNSKEY may be defined to declare NSEC optional per zone. - -2.1.6.1 Coexistence and Migration - - Current resolvers/validators will not understand the Flag bit and - will have to treat negative responses as bogus. Otherwise, no - migration path is needed since NSEC is simply turned off. - -2.1.6.2 Limitations - - NSEC can only be made completely optional at the cost of being unable - to prove unsecure delegations (absence of DS RR). A next to this - approach would just disable authenticated denial for non-existence of - nodes. - -2.1.6.3 Amendments to DNSSEC-bis - - New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to - be specified in the light of absence of authenticated denial. - -2.1.6.4 Cons - - Doesn't fully meet requirements. Operational consequences to be - studied. - -2.1.6.5 Pros - - Official version of the "trick" presented in (8). Operational - - - -Arends, et al. Expires December 7, 2004 [Page 8] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - - problems can be addressed during future work on validators. - -2.2 Mechanisms not Updating DNSSEC-bis - -2.2.1 Partial Type-code and Signal Rollover - - Carefully crafted type code/signal rollover to define a new - authenticated denial space that extends/replaces DNSSEC-bis - authenticated denial space. This particular path is illuminated by - Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> - posted to 2004-06-02. - -2.2.1.1 Coexistence and Migration - - To protect the current resolver for future versions, a new DNSSEC-OK - bit must be allocated to make clear it does or does not understand - the future version. Also, a new DS type needs to be allocated to - allow differentiation between a current signed delegation and a - 'future' signed delegation. Also, current NSEC needs to be rolled - into a new authenticated denial type. - -2.2.1.2 Limitations - - None. - -2.2.1.3 Amendments to DNSSEC-bis - - None. - -2.2.1.4 Cons - - It is cumbersome to carefully craft an TCR that 'just fits'. The - DNSSEC-bis protocol has many 'borderline' cases that needs special - consideration. It might be easier to do a full TCR, since a few of - the types and signals need upgrading anyway. - -2.2.1.5 Pros - - Graceful adoption of future versions of NSEC, while there are no - amendments to DNSSEC-bis. - -2.2.2 A Complete Type-code and Signal Rollover - - A new DNSSEC space is defined which can exist independent of current - DNSSEC-bis space. - - This proposal assumes that all current DNSSEC type-codes (RRSIG/ - DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any future - - - -Arends, et al. Expires December 7, 2004 [Page 9] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - - versions of DNSSEC. Any future version of DNSSEC has its own types to - allow for keys, signatures, authenticated denial, etcetera. - -2.2.2.1 Coexistence and Migration - - Both spaces can co-exist. They can be made completely orthogonal. - -2.2.2.2 Limitations - - None. - -2.2.2.3 Amendments to DNSSEC-bis - - None. - -2.2.2.4 Cons - - With this path we abandon the current DNSSEC-bis. Though it is easy - to role specific well-known and well-tested parts into the re-write, - once deployment has started this path is very expensive for - implementers, registries, registrars and registrants as well as - resolvers/users. A TCR is not to be expected to occur frequently, so - while a next generation authenticated denial may be enabled by a TCR, - it is likely that that TCR will only be agreed upon if it serves a - whole basket of changes or additions. A quick introduction of NSEC-ng - should not be expected from this path. - -2.2.2.5 Pros - - No amendments/changes to current DNSSEC-bis docset needed. It is - always there as last resort. - -2.2.3 Unknown Algorithm in RRSIG - - This proposal assumes that future extensions make use of the existing - NSEC RDATA syntax, while it may need to change the interpretation of - the RDATA or introduce an alternative denial mechanism, invoked by - the specific unknown signing algorithm. The different interpretation - would be signaled by use of different signature algorithms in the - RRSIG records covering the NSEC RRs. - - When an entire zone is signed with a single unknown algorithm, it - will cause implementations that follow current dnssec-bis documents - to treat individual RRsets as unsigned. - -2.2.3.1 Coexistence and migration - - Old and new NSEC RDATA interpretation or known and unknown Signatures - - - -Arends, et al. Expires December 7, 2004 [Page 10] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - - can NOT coexist in a zone since signatures cover complete (NSEC) - RRSets. - -2.2.3.2 Limitations - - Validating resolvers agnostic of new interpretation will treat the - NSEC RRset as "not signed". This affects wildcard and non-existence - proof, as well as proof for (un)secured delegations. Also, all - positive signatures (RRSIGs on RRSets other than DS, NSEC) appear - insecure/bogus to an old validator. - - The algorithm version space is split for each future version of - DNSSEC. Violation of the 'modular components' concept. We use the - 'validator' to protect the 'resolver' from unknown interpretations. - -2.2.3.3 Amendments to DNSSEC-bis - - None. - -2.2.3.4 Cons - - The algorithm field was not designed for this purpose. This is a - straightforward hack. - -2.2.3.5 Pros - - No amendments/changes to current DNSSEC-bis docset needed. - -3. Recommendation - - The authors recommend that the working group commits to and starts - work on a partial TCR, allowing gracefull transition towards a future - version of NSEC. Meanwhile, to accomodate the need for an - immediately, temporary, solution against zone-traversal, we recommend - On-Demand NSEC synthesis. - - This approach does not require any mandatory changes to DNSSEC-bis, - does not violate the protocol and fulfills the requirements. As a - side effect, it moves the cost of implementation and deployment to - the users (zone owners) of this mechanism. - - - - - - - - - - - -Arends, et al. Expires December 7, 2004 [Page 11] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - Enschede 7522 NB - Netherlands - - Phone: +31 534850485 - EMail: roy.arends@telin.nl - - - Peter Koch - Universitaet Bielefeld - - Bielefeld 33594 - Germany - - Phone: +49 521 106 2902 - EMail: pk@TechFak.Uni-Bielefeld.DE - - - Jakob Schlyter - NIC-SE - Box 5774 - Stockholm SE-114 87 - Sweden - - EMail: jakob@nic.se - URI: http://www.nic.se/ - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires December 7, 2004 [Page 12] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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 - - - -Arends, et al. Expires December 7, 2004 [Page 13] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires December 7, 2004 [Page 14] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt new file mode 100644 index 0000000000..dd8cbf0682 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt @@ -0,0 +1,839 @@ + +DNS Extensions Working Group R. Arends +Internet-Draft Telematica Instituut +Expires: August 25, 2005 P. Koch + DENIC eG + J. Schlyter + NIC-SE + February 21, 2005 + + + Evaluating DNSSEC Transition Mechanisms + draft-ietf-dnsext-dnssec-trans-02.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 August 25, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document collects and summarizes different proposals for + alternative and additional strategies for authenticated denial in DNS + responses, evaluates these proposals and gives a recommendation for a + + + +Arends, et al. Expires August 25, 2005 [Page 1] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + way forward. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3 + 2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4 + 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4 + 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5 + 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6 + 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6 + 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7 + 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8 + 2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9 + 2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9 + 2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10 + 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10 + 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11 + 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11 + 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13 + 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 25, 2005 [Page 2] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +1. Introduction + + This report shall document the process of dealing with the NSEC + walking problem late in the Last Call for + [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol, + I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion + that took place in the DNSEXT WG during the first half of June 2004 + as well as some additional ideas that came up subsequently. + + This is an edited excerpt of the chairs' mail to the WG: + The working group consents on not including NSEC-alt in the + DNSSEC-bis documents. The working group considers to take up + "prevention of zone enumeration" as a work item. + There may be multiple mechanisms to allow for co-existence with + DNSSEC-bis. The chairs allow the working group a little over a + week (up to June 12, 2004) to come to consensus on a possible + modification to the document to enable gentle rollover. If that + consensus cannot be reached the DNSSEC-bis documents will go out + as-is. + + To ease the process of getting consensus, a summary of the proposed + solutions and analysis of the pros and cons were written during the + weekend. + + This summary includes: + + An inventory of the proposed mechanisms to make a transition to + future work on authenticated denial of existence. + List the known Pros and Cons, possibly provide new arguments, and + possible security considerations of these mechanisms. + Provide a recommendation on a way forward that is least disruptive + to the DNSSEC-bis specifications as they stand and keep an open + path to other methods for authenticated denial of existence. + + The descriptions of the proposals in this document are coarse and do + not cover every detail necessary for implementation. In any case, + documentation and further study is needed before implementaion and/or + deployment, including those which seem to be solely operational in + nature. + +2. Transition Mechanisms + + In the light of recent discussions and past proposals, we have found + several ways to allow for transition to future expansion of + authenticated denial. We tried to illuminate the paths and pitfalls + in these ways forward. Some proposals lead to a versioning of + DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other + proposals are 'clean' but may cause delay, while again others may be + + + +Arends, et al. Expires August 25, 2005 [Page 3] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + plain hacks. + + Some paths do not introduce versioning, and might require the current + DNSSEC-bis documents to be fully updated to allow for extensions to + authenticated denial mechanisms. Other paths introduce versioning + and do not (or minimally) require DNSSEC-bis documents to be updated, + allowing DNSSEC-bis to be deployed, while future versions can be + drafted independent from or partially depending on DNSSEC-bis. + +2.1 Mechanisms With Need of Updating DNSSEC-bis + + Mechanisms in this category demand updates to the DNSSEC-bis document + set. + +2.1.1 Dynamic NSEC Synthesis + + This proposal assumes that NSEC RRs and the authenticating RRSIG will + be generated dynamically to just cover the (non existent) query name. + The owner name is (the) one preceding the name queried for, the Next + Owner Name Field has the value of the Query Name Field + 1 (first + successor in canonical ordering). A separate key (the normal ZSK or + a separate ZSK per authoritative server) would be used for RRSIGs on + NSEC RRs. This is a defense against enumeration, though it has the + presumption of online signing. + +2.1.1.1 Coexistence and Migration + + There is no change in interpretation other then that the next owner + name might or might not exist. + +2.1.1.2 Limitations + + This introduces an unbalanced cost between query and response + generation due to dynamic generation of signatures. + +2.1.1.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents might need to be updated to indicate + that the next owner name might not be an existing name in the zone. + This is not a real change to the spec since implementers have been + warned not to synthesize with previously cached NSEC records. A + specific bit to identify the dynamic signature generating key might + be useful as well, to prevent it from being used to fake positive + data. + +2.1.1.4 Cons + + Unbalanced cost is a ground for DDoS. Though this protects against + + + +Arends, et al. Expires August 25, 2005 [Page 4] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + enumeration, it is not really a path for versioning. + +2.1.1.5 Pros + + Hardly any amendments to DNSSEC-bis. + +2.1.2 Add Versioning/Subtyping to Current NSEC + + This proposal introduces versioning for the NSEC RR type (a.k.a. + subtyping) by adding a (one octet) version field to the NSEC RDATA. + Version number 0 is assigned to the current (DNSSEC-bis) meaning, + making this an 'Must Be Zero' (MBZ) for the to be published docset. + +2.1.2.1 Coexistence and Migration + + Since the versioning is done inside the NSEC RR, different versions + may coexist. However, depending on future methods, that may or may + not be useful inside a single zone. Resolvers cannot ask for + specific NSEC versions but may be able to indicate version support by + means of a to be defined EDNS option bit. + +2.1.2.2 Limitations + + There are no technical limitations, though it will cause delay to + allow testing of the (currently unknown) new NSEC interpretation. + + Since the versioning and signaling is done inside the NSEC RR, future + methods will likely be restricted to a single RR type authenticated + denial (as opposed to e.g. NSEC-alt, which currently proposes three + RR types). + +2.1.2.3 Amendments to DNSSEC-bis + + Full Update of the current DNSSEC-bis documents to provide for new + fields in NSEC, while specifying behavior in case of unknown field + values. + +2.1.2.4 Cons + + Though this is a clean and clear path without versioning DNSSEC, it + takes some time to design, gain consensus, update the current + dnssec-bis document, test and implement a new authenticated denial + record. + +2.1.2.5 Pros + + Does not introduce an iteration to DNSSEC while providing a clear and + clean migration strategy. + + + +Arends, et al. Expires August 25, 2005 [Page 5] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.3 Type Bit Map NSEC Indicator + + Bits in the type-bit-map are reused or allocated to signify the + interpretation of NSEC. + + This proposal assumes that future extensions make use of the existing + NSEC RDATA syntax, while it may need to change the interpretation of + the RDATA or introduce an alternative denial mechanism, invoked by + the specific type-bit-map-bits. + +2.1.3.1 Coexistence and migration + + Old and new NSEC meaning could coexist, depending how the signaling + would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR + types are available as well as those covering meta/query types or + types to be specifically allocated. + +2.1.3.2 Limitations + + This mechanism uses an NSEC field that was not designed for that + purpose. Similar methods were discussed during the Opt-In discussion + and the Silly-State discussion. + +2.1.3.3 Amendments to DNSSEC-bis + + The specific type-bit-map-bits must be allocated and they need to be + specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) + interpretation. Also, behaviour of the resolver and validator must + be documented in case unknown values are encountered for the MBZ + field. Currently the protocol document specifies that the validator + MUST ignore the setting of the NSEC and the RRSIG bits, while other + bits are only used for the specific purpose of the type-bit-map field + +2.1.3.4 Cons + + The type-bit-map was not designed for this purpose. It is a + straightforward hack. Text in protocol section 5.4 was put in + specially to defend against this usage. + +2.1.3.5 Pros + + No change needed to the on-the-wire protocol as specified in the + current docset. + +2.1.4 New Apex Type + + This introduces a new Apex type (parallel to the zone's SOA) + indicating the DNSSEC version (or authenticated denial) used in or + + + +Arends, et al. Expires August 25, 2005 [Page 6] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + for this zone. + +2.1.4.1 Coexistence and Migration + + Depending on the design of this new RR type multiple denial + mechanisms may coexist in a zone. Old validators will not understand + and thus ignore the new type, so interpretation of the new NSEC + scheme may fail, negative responses may appear 'bogus'. + +2.1.4.2 Limitations + + A record of this kind is likely to carry additional + feature/versioning indications unrelated to the current question of + authenticated denial. + +2.1.4.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents need to be updated to indicate that + the absence of this type indicates dnssec-bis, and that the (mere) + presence of this type indicated unknown versions. + +2.1.4.4 Cons + + The only other 'zone' or 'apex' record is the SOA record. Though + this proposal is not new, it is yet unknown how it might fulfill + authenticated denial extensions. This new RR type would only provide + for a generalized signaling mechanism, not the new authenticated + denial scheme. Since it is likely to be general in nature, due to + this generality consensus is not to be reached soon. + +2.1.4.5 Pros + + This approach would allow for a lot of other per zone information to + be transported or signaled to both (slave) servers and resolvers. + +2.1.5 NSEC White Lies + + This proposal disables one part of NSEC (the pointer part) by means + of a special target (root, apex, owner, ...), leaving intact only the + ability to authenticate denial of existence of RR sets, not denial of + existence of domain names (NXDOMAIN). It may be necessary to have + one working NSEC to prove the absence of a wildcard. + +2.1.5.1 Coexistence and Migration + + The NSEC target can be specified per RR, so standard NSEC and 'white + lie' NSEC can coexist in a zone. There is no need for migration + because no versioning is introduced or intended. + + + +Arends, et al. Expires August 25, 2005 [Page 7] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.5.2 Limitations + + This proposal breaks the protocol and is applicable to certain types + of zones only (no wildcard, no deep names, delegation only). Most of + the burden is put on the resolver side and operational consequences + are yet to be studied. + +2.1.5.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents need to be updated to indicate that + the NXDOMAIN responses may be insecure. + +2.1.5.4 Cons + + Strictly speaking this breaks the protocol and doesn't fully fulfill + the requirements for authenticated denial of existence. Security + implications need to be carefully documented: search path problems + (forged denial of existence may lead to wrong expansion of non-FQDNs + [RFC1535]) and replay attacks to deny existence of records. + +2.1.5.5 Pros + + Hardly any amendments to DNSSEC-bis. Operational "trick" that is + available anyway. + +2.1.6 NSEC Optional via DNSSKEY Flag + + A new DNSKEY may be defined to declare NSEC optional per zone. + +2.1.6.1 Coexistence and Migration + + Current resolvers/validators will not understand the Flag bit and + will have to treat negative responses as bogus. Otherwise, no + migration path is needed since NSEC is simply turned off. + +2.1.6.2 Limitations + + NSEC can only be made completely optional at the cost of being unable + to prove unsecure delegations (absence of a DS RR [RFC3658]). A next + to this approach would just disable authenticated denial for + non-existence of nodes. + +2.1.6.3 Amendments to DNSSEC-bis + + New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to + be specified in the light of absence of authenticated denial. + + + + + +Arends, et al. Expires August 25, 2005 [Page 8] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.6.4 Cons + + Doesn't fully meet requirements. Operational consequences to be + studied. + +2.1.6.5 Pros + + Official version of the "trick" presented in (8). Operational + problems can be addressed during future work on validators. + +2.1.7 New Answer Pseudo RR Type + + A new pseudo RR type may be defined that will be dynamically created + (and signed) by the responding authoritative server. The RR in the + response will cover the QNAME, QCLASS and QTYPE and will authenticate + both denial of existence of name (NXDOMAIN) or RRset. + +2.1.7.1 Coexistence and Migration + + Current resolvers/validators will not understand the pseudo RR and + will thus not be able to process negative responses so testified. A + signaling or solicitation method would have to be specified. + +2.1.7.2 Limitations + + This method can only be used with online keys and online signing + capacity. + +2.1.7.3 Amendments to DNSSEC-bis + + Signaling method needs to be defined. + +2.1.7.4 Cons + + Keys have to be held and processed online with all security + implications. An additional flag for those keys identifying them as + online or negative answer only keys should be considered. + +2.1.7.5 Pros + + Expands DNSSEC authentication to the RCODE. + +2.1.8 SIG(0) Based Authenticated Denial + + +2.1.8.1 Coexistence and Migration + + + + + +Arends, et al. Expires August 25, 2005 [Page 9] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.8.2 Limitations + + +2.1.8.3 Amendments to DNSSEC-bis + + +2.1.8.4 Cons + + +2.1.8.5 Pros + + +2.2 Mechanisms Without Need of Updating DNSSEC-bis + +2.2.1 Partial Type-code and Signal Rollover + + Carefully crafted type code/signal rollover to define a new + authenticated denial space that extends/replaces DNSSEC-bis + authenticated denial space. This particular path is illuminated by + Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> + posted to 2004-06-02. + +2.2.1.1 Coexistence and Migration + + To protect the current resolver for future versions, a new DNSSEC-OK + bit must be allocated to make clear it does or does not understand + the future version. Also, a new DS type needs to be allocated to + allow differentiation between a current signed delegation and a + 'future' signed delegation. Also, current NSEC needs to be rolled + into a new authenticated denial type. + +2.2.1.2 Limitations + + None. + +2.2.1.3 Amendments to DNSSEC-bis + + None. + +2.2.1.4 Cons + + It is cumbersome to carefully craft an TCR that 'just fits'. The + DNSSEC-bis protocol has many 'borderline' cases that needs special + consideration. It might be easier to do a full TCR, since a few of + the types and signals need upgrading anyway. + + + + + + +Arends, et al. Expires August 25, 2005 [Page 10] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.2.1.5 Pros + + Graceful adoption of future versions of NSEC, while there are no + amendments to DNSSEC-bis. + +2.2.2 A Complete Type-code and Signal Rollover + + A new DNSSEC space is defined which can exist independent of current + DNSSEC-bis space. + + This proposal assumes that all current DNSSEC type-codes + (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any + future versions of DNSSEC. Any future version of DNSSEC has its own + types to allow for keys, signatures, authenticated denial, etcetera. + +2.2.2.1 Coexistence and Migration + + Both spaces can co-exist. They can be made completely orthogonal. + +2.2.2.2 Limitations + + None. + +2.2.2.3 Amendments to DNSSEC-bis + + None. + +2.2.2.4 Cons + + With this path we abandon the current DNSSEC-bis. Though it is easy + to role specific well-known and well-tested parts into the re-write, + once deployment has started this path is very expensive for + implementers, registries, registrars and registrants as well as + resolvers/users. A TCR is not to be expected to occur frequently, so + while a next generation authenticated denial may be enabled by a TCR, + it is likely that that TCR will only be agreed upon if it serves a + whole basket of changes or additions. A quick introduction of + NSEC-ng should not be expected from this path. + +2.2.2.5 Pros + + No amendments/changes to current DNSSEC-bis docset needed. It is + always there as last resort. + +2.2.3 Unknown Algorithm in RRSIG + + This proposal assumes that future extensions make use of the existing + NSEC RDATA syntax, while it may need to change the interpretation of + + + +Arends, et al. Expires August 25, 2005 [Page 11] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + the RDATA or introduce an alternative denial mechanism, invoked by + the specific unknown signing algorithm. The different interpretation + would be signaled by use of different signature algorithms in the + RRSIG records covering the NSEC RRs. + + When an entire zone is signed with a single unknown algorithm, it + will cause implementations that follow current dnssec-bis documents + to treat individual RRsets as unsigned. + +2.2.3.1 Coexistence and migration + + Old and new NSEC RDATA interpretation or known and unknown Signatures + can NOT coexist in a zone since signatures cover complete (NSEC) + RRSets. + +2.2.3.2 Limitations + + Validating resolvers agnostic of new interpretation will treat the + NSEC RRset as "not signed". This affects wildcard and non-existence + proof, as well as proof for (un)secured delegations. Also, all + positive signatures (RRSIGs on RRSets other than DS, NSEC) appear + insecure/bogus to an old validator. + + The algorithm version space is split for each future version of + DNSSEC. Violation of the 'modular components' concept. We use the + 'validator' to protect the 'resolver' from unknown interpretations. + +2.2.3.3 Amendments to DNSSEC-bis + + None. + +2.2.3.4 Cons + + The algorithm field was not designed for this purpose. This is a + straightforward hack. + +2.2.3.5 Pros + + No amendments/changes to current DNSSEC-bis docset needed. + +3. Recommendation + + The authors recommend that the working group commits to and starts + work on a partial TCR, allowing graceful transition towards a future + version of NSEC. Meanwhile, to accomodate the need for an + immediately, temporary, solution against zone-traversal, we recommend + On-Demand NSEC synthesis. + + + + +Arends, et al. Expires August 25, 2005 [Page 12] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + This approach does not require any mandatory changes to DNSSEC-bis, + does not violate the protocol and fulfills the requirements. As a + side effect, it moves the cost of implementation and deployment to + the users (zone owners) of this mechanism. + +4. Acknowledgements + + The authors would like to thank Sam Weiler and Mark Andrews for their + input and constructive comments. + +5. References + +5.1 Normative References + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Massey, D., Larson, M. and S. + Rose, "DNS Security Introduction and Requirements", + Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October + 2004. + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., "Protocol Modifications for the DNS Security + Extensions", + Internet-Draft draft-ietf-dnsext-dnssec-protocol-09, + October 2004. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., "Resource Records for the DNS Security + Extensions", + Internet-Draft draft-ietf-dnsext-dnssec-records-11, + October 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. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + +5.2 Informative References + + [RFC1535] Gavron, E., "A Security Problem and Proposed Correction + With Widely Deployed DNS Software", RFC 1535, October + 1993. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + + + +Arends, et al. Expires August 25, 2005 [Page 13] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + RFC 2535, March 1999. + + [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, + June 1999. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + Enschede 7523 XC + The Netherlands + + Phone: +31 53 4850485 + Email: roy.arends@telin.nl + + + Peter Koch + DENIC eG + Wiesenh"uttenplatz 26 + Frankfurt 60329 + Germany + + Phone: +49 69 27235 0 + Email: pk@DENIC.DE + + + Jakob Schlyter + NIC-SE + Box 5774 + Stockholm SE-114 87 + Sweden + + Email: jakob@nic.se + URI: http://www.nic.se/ + + + + + + + + + + + + +Arends, et al. Expires August 25, 2005 [Page 14] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +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 (2005). 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 August 25, 2005 [Page 15] + + diff --git a/doc/draft/draft-ietf-dnsext-ecc-key-05.txt b/doc/draft/draft-ietf-dnsext-ecc-key-06.txt similarity index 71% rename from doc/draft/draft-ietf-dnsext-ecc-key-05.txt rename to doc/draft/draft-ietf-dnsext-ecc-key-06.txt index dc156530a9..6953f6e42f 100644 --- a/doc/draft/draft-ietf-dnsext-ecc-key-05.txt +++ b/doc/draft/draft-ietf-dnsext-ecc-key-06.txt @@ -1,13 +1,13 @@ -©À + INTERNET-DRAFT ECC Keys in the DNS -Expires: February 2005 August 2004 +Expires: June 2005 December 2004 Elliptic Curve KEYs in the DNS -------- ----- ---- -- --- --- - + Richard C. Schroeppel Donald Eastlake 3rd @@ -43,8 +43,8 @@ Status of This Document Abstract - The standard method for storing elliptic curve cryptographic keys in - the Domain Name System is specified. + The standard method for storing elliptic curve cryptographic keys and + signatures in the Domain Name System is specified. Copyright Notice @@ -81,17 +81,17 @@ Table of Contents 2. Elliptic Curve Data in Resource Records.................3 3. The Elliptic Curve Equation.............................9 4. How do I Compute Q, G, and Y?..........................10 - 5. Performance Considerations.............................11 - 6. Security Considerations................................11 - 7. IANA Considerations....................................11 - Copyright and Disclaimer..................................12 + 5. Elliptic Curve SIG Resource Records....................11 + 6. Performance Considerations.............................13 + 7. Security Considerations................................13 + 8. IANA Considerations....................................13 + Copyright and Disclaimer..................................14 - Informational References..................................13 - Normative Refrences.......................................13 - - Authors Addresses.........................................14 - Expiration and File Name..................................14 + Informational References..................................15 + Normative Refrences.......................................15 + Author's Addresses........................................16 + Expiration and File Name..................................16 @@ -128,9 +128,9 @@ INTERNET-DRAFT ECC Keys in the DNS protocol, records]. This document describes how to store elliptic curve cryptographic - (ECC) keys in the DNS so they can be used for a variety of security - purposes. A DNS elliptic curve SIG resource record is not defined. - Familiarity with ECC cryptography is assumed [Menezes]. + (ECC) keys and signatures in the DNS so they can be used for a + variety of security purposes. Familiarity with ECC cryptography is + assumed [Menezes]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this @@ -141,11 +141,8 @@ INTERNET-DRAFT ECC Keys in the DNS 2. Elliptic Curve Data in Resource Records Elliptic curve public keys are stored in the DNS within the RDATA - portions of key RRs with the structure shown below [RFC records]. - - The period of key validity may not be in the RR with the key but - could be indicated by RR(s) with signatures that authenticates the - RR(s) containing the key. + portions of key RRs, such as RRKEY and KEY [RFC records] RRs, with + the structure shown below. The research world continues to work on the issue of which is the best elliptic curve system, which finite field to use, and how to @@ -171,6 +168,9 @@ INTERNET-DRAFT ECC Keys in the DNS + + + R. Schroeppel, et al [Page 3] @@ -373,7 +373,7 @@ INTERNET-DRAFT ECC Keys in the DNS and the constant term is least important. Coefficients are ordered by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of degree D is X^D (which is not irreducible). The next is X^D+1, which - is sometimes irreducible, followed by X^D-1, which isn‚ÇÖt. Assuming + is sometimes irreducible, followed by X^D-1, which isn't. Assuming odd P, this series continues to X^D - (P-1)/2, and then goes to X^D + X, X^D + X + 1, X^D + X - 1, etc. @@ -490,7 +490,7 @@ INTERNET-DRAFT ECC Keys in the DNS of the curve point is given explicitly; the Z-coordinate is implicit. - LY,Y is the user‚ÇÖs public signing key, another curve point of + LY,Y is the user's public signing key, another curve point of order Q. The W-coordinate is given explicitly; the Z- coordinate is implicit. The LY,Y parameter pair is always present. @@ -540,7 +540,7 @@ INTERNET-DRAFT ECC Keys in the DNS The number of points on the curve is the number of solutions to the curve equation, + 1 (for the "point at infinity"). The prime Q must divide the number of points. Usually the curve is chosen first, then - the number of points is determined with Schoof‚ÇÖs algorithm. This + the number of points is determined with Schoof's algorithm. This number is factored, and if it has a large prime divisor, that number is taken as Q. @@ -567,7 +567,7 @@ INTERNET-DRAFT ECC Keys in the DNS smaller Z value (the one which does not contain the highest-order 1 bit of W (or C)) is used in subsequent calculations. - Y is specified by giving the W-coordinate of the user‚ÇÖs public + Y is specified by giving the W-coordinate of the user's public signature key. The Z-coordinate value is determined from the curve equation. As with G, there are two possible Z values; the same rule is followed for choosing which Z to use. @@ -598,41 +598,41 @@ INTERNET-DRAFT ECC Keys in the DNS -5. Performance Considerations +5. Elliptic Curve SIG Resource Records - Elliptic curve signatures use smaller moduli or field sizes than RSA - and DSA. Creation of a curve is slow, but not done very often. Key - generation is faster than RSA or DSA. + The signature portion of an RR RDATA area when using the EC + algorithm, for example in the RRSIG and SIG [RFC records] RRs is + shown below. - DNS implementations have been optimized for small transfers, - typically less than 512 octets including DNS overhead. Larger - transfers will perform correctly and and extensions have been - standardized to make larger transfers more efficient [RFC 2671]. - However, it is still advisable at this time to make reasonable - efforts to minimize the size of RR sets stored within the DNS - consistent with adequate security. + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | R, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | S, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + R and S are integers (mod Q). Their length is specified by the LQ + field of the corresponding KEY RR and can also be calculated from the + SIG RR's RDLENGTH. They are right justified, high-order-octet first. + The same conditional formula for calculating the length from LQ is + used as for all the other length fields above. + The data signed is determined as specified in [RFC 2535]. Then the + following steps are taken where Q, P, G, and Y are as specified in + the public key [Schneier]: -6. Security Considerations + hash = SHA-1 ( data ) - Keys retrieved from the DNS should not be trusted unless (1) they - have been securely obtained from a secure resolver or independently - verified by the user and (2) this secure resolver and secure - obtainment or independent verification conform to security policies - acceptable to the user. As with all cryptographic algorithms, - evaluating the necessary strength of the key is essential and - dependent on local policy. + Generate random [RFC 1750] K such that 0 < K < Q. (Never sign two + different messages with the same K. K should be chosen from a + very large space: If an opponent learns a K value for a single + signature, the user's signing key is compromised, and a forger + can sign arbitrary messages. There is no harm in signing the + same message multiple times with the same key or different + keys.) - Some specific key generation considerations are given in the body of - this document. - - - -7. IANA Considerations - - Assignment of meaning to the remaining ECC data flag bits or to - values of ECC fields outside the ranges for which meaning in defined + R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted R. Schroeppel, et al [Page 11] @@ -641,56 +641,56 @@ R. Schroeppel, et al [Page 11] INTERNET-DRAFT ECC Keys in the DNS - in this document requires an IETF consensus as defined in [RFC 2434]. - - - -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. - - - - - - - - - - - - - - - - - + as an integer, and reduced (mod Q). (R must not be 0. In + this astronomically unlikely event, generate a new random K + and recalculate R.) + S = ( K^(-1) * (hash + X*R) ) mod Q. + S must not be 0. In this astronomically unlikely event, generate a + new random K and recalculate R and S. + If S > Q/2, set S = Q - S. + The pair (R,S) is the signature. + Another party verifies the signature as follows: + Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a + valid EC sigature. + hash = SHA-1 ( data ) + Sinv = S^(-1) mod Q. + U1 = (hash * Sinv) mod Q. + U2 = (R * Sinv) mod Q. + (U1 * G + U2 * Y) is computed on the elliptic curve. + V = (the W-coordinate of this point) interpreted as an integer + and reduced (mod Q). + The signature is valid if V = R. + The reason for requiring S < Q/2 is that, otherwise, both (R,S) and + (R,Q-S) would be valid signatures for the same data. Note that a + signature that is valid for hash(data) is also valid for + hash(data)+Q or hash(data)-Q, if these happen to fall in the range + [0,2^160-1]. It's believed to be computationally infeasible to + find data that hashes to an assigned value, so this is only a + cosmetic blemish. The blemish can be eliminated by using Q > + 2^160, at the cost of having slightly longer signatures, 42 octets + instead of 40. + We must specify how a field-element E ("the W-coordinate") is to be + interpreted as an integer. The field-element E is regarded as a + radix-P integer, with the digits being the coefficients in the + polynomial basis representation of E. The digits are in the ragne + [0,P-1]. In the two most common cases, this reduces to "the + obvious thing". In the (mod P) case, E is simply a residue mod P, + and is taken as an integer in the range [0,P-1]. In the GF[2^D] R. Schroeppel, et al [Page 12] @@ -699,53 +699,53 @@ R. Schroeppel, et al [Page 12] INTERNET-DRAFT ECC Keys in the DNS -Informational References - - [RFC 1034] - P. Mockapetris, "Domain names - concepts and - facilities", 11/01/1987. - - [RFC 1035] - P. Mockapetris, "Domain names - implementation and - specification", 11/01/1987. - - [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness - Recommendations for Security", 12/29/1994. - - [RFC intro] - "DNS Security Introduction and Requirements", R. - Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress, - draft-ietf-dnsext-dnssec-intro-*.txt. - - [RFC protocol] - "Protocol Modifications for the DNS Security - Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose, - work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt. - - [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August - 1999. - - [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, - Algorithms, and Source Code in C", 1996, John Wiley and Sons - - [Menezes] - Alfred Menezes, "Elliptic Curve Public Key - Cryptosystems", 1993 Kluwer. - - [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves", - 1986, Springer Graduate Texts in mathematics #106. + case, E is in the D-bit polynomial basis representation, and is + simply taken as an integer in the range [0,(2^D)-1]. For other + fields GF[P^D], it's necessary to do some radix conversion + arithmetic. -Normative Refrences + 6. Performance Considerations - [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", March 1997. + Elliptic curve signatures use smaller moduli or field sizes than + RSA and DSA. Creation of a curve is slow, but not done very often. + Key generation is faster than RSA or DSA. - [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", October 1998. - - [RFC records] - "Resource Records for the DNS Security Extensions", - R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in - progress, draft-ietf-dnsext-dnssec-records- *.txt. + DNS implementations have been optimized for small transfers, + typically less than 512 octets including DNS overhead. Larger + transfers will perform correctly and and extensions have been + standardized to make larger transfers more efficient [RFC 2671]. + However, it is still advisable at this time to make reasonable + efforts to minimize the size of RR sets stored within the DNS + consistent with adequate security. + 7. Security Considerations + + Keys retrieved from the DNS should not be trusted unless (1) they + have been securely obtained from a secure resolver or independently + verified by the user and (2) this secure resolver and secure + obtainment or independent verification conform to security policies + acceptable to the user. As with all cryptographic algorithms, + evaluating the necessary strength of the key is essential and + dependent on local policy. + + Some specific key generation considerations are given in the body + of this document. + + + + 8. IANA Considerations + + The key and signature data structures defined herein correspond to + the value 4 in the Algorithm number field of the IANA registry + + Assignment of meaning to the remaining ECC data flag bits or to + values of ECC fields outside the ranges for which meaning in + defined in this document requires an IETF consensus as defined in + [RFC 2434]. @@ -757,33 +757,33 @@ R. Schroeppel, et al [Page 13] INTERNET-DRAFT ECC Keys in the DNS -Authors Addresses + 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. + + + + - Rich Schroeppel - 500 S. Maple Drive - Woodland Hills, UT 84653 USA - - Telephone: 1-801-423-7998(h) - 1-505-844-9079(w) - Email: rschroe@sandia.gov - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1 508-634-2066 (h) - +1 508-786-7554 (w) - EMail: Donald.Eastlake@motorola.com -Expiration and File Name - This draft expires in February 2004. - Its file name is draft-ietf-dnsext-ecc-key-05.txt. @@ -812,3 +812,119 @@ Expiration and File Name R. Schroeppel, et al [Page 14] +INTERNET-DRAFT ECC Keys in the DNS + + + Informational References + + [RFC 1034] - P. Mockapetris, "Domain names - concepts and + facilities", 11/01/1987. + + [RFC 1035] - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. + + [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness + Recommendations for Security", 12/29/1994. + + [RFC intro] - "DNS Security Introduction and Requirements", R. + Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in + progress, draft-ietf-dnsext-dnssec-intro-*.txt. + + [RFC protocol] - "Protocol Modifications for the DNS Security + Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose, + work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt. + + [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", + August 1999. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and Sons + + [Menezes] - Alfred Menezes, "Elliptic Curve Public Key + Cryptosystems", 1993 Kluwer. + + [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic + Curves", 1986, Springer Graduate Texts in mathematics #106. + + + + Normative Refrences + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", October 1998. + + [RFC records] - "Resource Records for the DNS Security Extensions", + R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in + progress, draft-ietf-dnsext-dnssec-records- *.txt. + + + + + + + + +R. Schroeppel, et al [Page 15] + + +INTERNET-DRAFT ECC Keys in the DNS + + + Author's Addresses + + Rich Schroeppel + 500 S. Maple Drive + Woodland Hills, UT 84653 USA + + Telephone: +1-505-844-9079(w) + +1-801-423-7998(h) + Email: rschroe@sandia.gov + + + 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 June 2004. + + Its file name is draft-ietf-dnsext-ecc-key-06.txt. + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 16] + + diff --git a/doc/draft/draft-ietf-dnsext-insensitive-04.txt b/doc/draft/draft-ietf-dnsext-insensitive-05.txt similarity index 83% rename from doc/draft/draft-ietf-dnsext-insensitive-04.txt rename to doc/draft/draft-ietf-dnsext-insensitive-05.txt index 4cfd417804..41fbee7a4a 100644 --- a/doc/draft/draft-ietf-dnsext-insensitive-04.txt +++ b/doc/draft/draft-ietf-dnsext-insensitive-05.txt @@ -1,639 +1,697 @@ - -INTERNET-DRAFT Donald E. Eastlake 3rd -Clarifies STD0013 Motorola Laboratories -Expires December 2004 July 2004 - - - - Domain Name System (DNS) Case Insensitivity Clarification - ------ ---- ------ ----- ---- ------------- ------------- - - - Donald E. Eastlake 3rd - - - -Status of This Document - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - Distribution of this document is unlimited. Comments should be sent - to the DNSEXT working group at namedroppers@ops.ietf.org. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026. Internet-Drafts are - working documents of the Internet Engineering Task Force (IETF), its - areas, and its working groups. Note that other groups may also - distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- - Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - -Abstract - - Domain Name System (DNS) names are "case insensitive". This document - explains exactly what that means and provides a clear specification - of the rules. This clarification should not have any interoperability - consequences. - - - - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Acknowledgements - - The contributions to this document of Rob Austein, Olafur - Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, - Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully - acknowledged. - - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Acknowledgements...........................................2 - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. Case Insensitivity of DNS Labels........................3 - 2.1 Escaping Unusual DNS Label Octets......................3 - 2.2 Example Labels with Escapes............................4 - 3. Name Lookup, Label Types, and CLASS.....................4 - 3.1 Original DNS Label Types...............................5 - 3.2 Extended Label Type Case Insensitivity Considerations..5 - 3.3 CLASS Case Insensitivity Considerations................5 - 4. Case on Input and Output................................6 - 4.1 DNS Output Case Preservation...........................6 - 4.2 DNS Input Case Preservation............................6 - 5. Internationalized Domain Names..........................7 - 6. Security Considerations.................................7 - - Copyright and Disclaimer...................................9 - Normative References.......................................9 - Informative References....................................10 - -02 to -03 Changes........................................10 - -03 to -04 Changes........................................11 - Author's Address..........................................11 - Expiration and File Name..................................11 - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT DNS Case Insensitivity - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - other information. Each node in the DNS tree has a name consisting of - zero or more labels [STD 13][RFC 1591, 2606] that are treated in a - case insensitive fashion. This document clarifies the meaning of - "case insensitive" for the DNS. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - - - -2. Case Insensitivity of DNS Labels - - DNS was specified in the era of [ASCII]. DNS names were expected to - look like most host names or Internet email address right halves (the - part after the at-sign, "@") or be numeric as in the in-addr.arpa - part of the DNS name space. For example, - - foo.example.net. - aol.com. - www.gnu.ai.mit.edu. - or 69.2.0.192.in-addr.arpa. - - Case varied alternatives to the above would be DNS names like - - Foo.ExamplE.net. - AOL.COM. - WWW.gnu.AI.mit.EDU. - or 69.2.0.192.in-ADDR.ARPA. - - However, the individual octets of which DNS names consist are not - limited to valid ASCII character codes. They are 8-bit bytes and all - values are allowed. Many applications, however, interpret them as - ASCII characters. - - - -2.1 Escaping Unusual DNS Label Octets - - In Master Files [STD 13] and other human readable and writable ASCII - contexts, an escape is needed for the byte value for period (0x2E, - ".") and all octet values outside of the inclusive range of 0x21 - ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in - the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. - - One typographic convention for octets that do not correspond to an - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT DNS Case Insensitivity - - - ASCII printing graphic is to use a back-slash followed by the value - of the octet as an unsigned integer represented by exactly three - decimal digits. - - The same convention can be used for printing ASCII characters so that - they will be treated as a normal label character. This includes the - back-slash character used in this convention itself which can be - expressed as \092 or \\ and the special label separator period (".") - which can be expressed as and \046 or \. respectively. It is - advisable to avoid using a backslash to quote an immediately - following non-printing ASCII character code to avoid implementation - difficulties. - - A back-slash followed by only one or two decimal digits is undefined. - A back-slash followed by four decimal digits produces two octets, the - first octet having the value of the first three digits considered as - a decimal number and the second octet being the character code for - the fourth decimal digit. - - - -2.2 Example Labels with Escapes - - The first example below shows embedded spaces and a period (".") - within a label. The second one show a 5 octet label where the second - octet has all bits zero, the third is a backslash, and the fourth - octet has all bits one. - - Donald\032E\.\032Eastlake\0323rd.example. - and a\000\\\255z.example. - - - -3. Name Lookup, Label Types, and CLASS - - The design decision was made that comparisons on name lookup for DNS - queries should be case insensitive [STD 13]. That is to say, a lookup - string octet with a value in the inclusive range of 0x41 to 0x5A, the - upper case ASCII letters, MUST match the identical value and also - match the corresponding value in the inclusive range 0x61 to 0x7A, - the lower case ASCII letters. And a lookup string octet with a lower - case ASCII letter value MUST similarly match the identical value and - also match the corresponding value in the upper case ASCII letter - range. - - (Historical Note: the terms "upper case" and "lower case" were - invented after movable type. The terms originally referred to the - two font trays for storing, in partitioned areas, the different - physical type elements. Before movable type, the nearest equivalent - terms were "majuscule" and "minuscule".) - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT DNS Case Insensitivity - - - One way to implement this rule would be, when comparing octets, to - subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A - before the comparison. Such an operation is commonly known as "case - folding" but implementation via case folding is not required. Note - that the DNS case insensitivity does NOT correspond to the case - folding specified in iso-8859-1 or iso-8859-2. For example, the - octets 0xDD (\221) and 0xFD (\253) do NOT match although in other - contexts, where they are interpreted as the upper and lower case - version of "Y" with an acute accent, they might. - - - -3.1 Original DNS Label Types - - DNS labels in wire encoded names have a type associated with them. - The original DNS standard [RFC 1035] had only two types. ASCII - labels, with a length of from zero to 63 octets, and indirect labels - which consist of an offset pointer to a name location elsewhere in - the wire encoding on a DNS message. (The ASCII label of length zero - is reserved for use as the name of the root node of the name tree.) - ASCII labels follow the ASCII case conventions described herein and, - as stated above, can actually contain arbitrary byte values. Indirect - labels are, in effect, replaced by the name to which they point which - is then treated with the case insensitivity rules in this document. - - - -3.2 Extended Label Type Case Insensitivity Considerations - - DNS was extended by [RFC 2671] to have additional label type numbers - available. (The only such type defined so far is the BINARY type [RFC - 2673].) - - The ASCII case insensitivity conventions only apply to ASCII labels, - that is to say, label type 0x0, whether appearing directly or invoked - by indirect labels. - - - -3.3 CLASS Case Insensitivity Considerations - - As described in [STD 13] and [RFC 2929], DNS has an additional axis - for data location called CLASS. The only CLASS in global use at this - time is the "IN" or Internet CLASS. - - The handling of DNS label case is not CLASS dependent. - - - - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT DNS Case Insensitivity - - -4. Case on Input and Output - - While ASCII label comparisons are case insensitive, [STD 13] says - case MUST be preserved on output, and preserved when convenient on - input. However, this means less than it would appear since the - preservation of case on output is NOT required when output is - optimized by the use of indirect labels, as explained below. - - - -4.1 DNS Output Case Preservation - - [STD 13] views the DNS namespace as a node tree. ASCII output is as - if a name was marshaled by taking the label on the node whose name is - to be output, converting it to a typographically encoded ASCII - string, walking up the tree outputting each label encountered, and - preceding all labels but the first with a period ("."). Wire output - follows the same sequence but each label is wire encoded and no - periods inserted. No "case conversion" or "case folding" is done - during such output operations, thus "preserving" case. However, to - optimize output, indirect labels may be used to point to names - elsewhere in the DNS answer. In determining whether the name to be - pointed to, for example the QNAME, is the "same" as the remainder of - the name being optimized, the case insensitive comparison specified - above is done. Thus such optimization MAY easily destroy the output - preservation of case. This type of optimization is commonly called - "name compression". - - - -4.2 DNS Input Case Preservation - - Originally, DNS input came from an ASCII Master File as defined in - [STD 13] or a zone transfer. DNS Dynamic update and incremental zone - transfers [RFC 1995] have been added as a source of DNS data [RFC - 2136, 3007]. When a node in the DNS name tree is created by any of - such inputs, no case conversion is done. Thus the case of ASCII - labels is preserved if they are for nodes being created. However, - when a name label is input for a node that already exist in DNS data - being held, the situation is more complex. Implementations may retain - the case first input for such a label or allow new input to override - the old case or even maintain separate copies preserving the input - case. - - For example, if data with owner name "foo.bar.example" is input and - then later data with owner name "xyz.BAR.example" is input, the name - of the label on the "bar.example" node, i.e. "bar", might or might - not be changed to "BAR" or the actual input case could be preserved. - Thus later retrieval of data stored under "xyz.bar.example" in this - case can easily return data with "xyz.BAR.example". The same - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT DNS Case Insensitivity - - - considerations apply when inputting multiple data records with owner - names differing only in case. For example, if an "A" record is stored - as the first resourced record under owner name "xyz.BAR.example" and - then a second "A" record is stored under "XYZ.BAR.example", the - second MAY be stored with the first (lower case initial label) name - or the second MAY override the first so that only an upper case - initial label is retained or both capitalizations MAY be kept. - - Note that the order of insertion into a server database of the DNS - name tree nodes that appear in a Master File is not defined so that - the results of inconsistent capitalization in a Master File are - unpredictable output capitalization. - - - -5. Internationalized Domain Names - - A scheme has been adopted for "internationalized domain names" and - "internationalized labels" as described in [RFC 3490, 3454, 3491, and - 3492]. It makes most of [UNICODE] available through a separate - application level transformation from internationalized domain name - to DNS domain name and from DNS domain name to internationalized - domain name. Any case insensitivity that internationalized domain - names and labels have varies depending on the script and is handled - entirely as part of the transformation described in [RFC 3454] and - [RFC 3491] which should be seen for further details. This is not a - part of the DNS as standardized in STD 13. - - - -6. Security Considerations - - The equivalence of certain DNS label types with case differences, as - clarified in this document, can lead to security problems. For - example, a user could be confused by believing two domain names - differing only in case were actually different names. - - Furthermore, a domain name may be used in contexts other than the - DNS. It could be used as a case sensitive index into some data base - system. Or it could be interpreted as binary data by some integrity - or authentication code system. These problems can usually be handled - by using a standardized or "canonical" form of the DNS ASCII type - labels, that is, always mapping the ASCII letter value octets in - ASCII labels to some specific pre-chosen case, either upper case or - lower case. An example of a canonical form for domain names (and also - a canonical ordering for them) appears in Section 8 of [RFC 2535]. - See also [RFC 3597]. - - Finally, a non-DNS name may be stored into DNS with the false - expectation that case will always be preserved. For example, although - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT DNS Case Insensitivity - - - this would be quite rare, on a system with case sensitive email - address local parts, an attempt to store two "RP" records that - differed only in case would probably produce unexpected results that - might have security implications. That is because the entire email - address, including the possibly case sensitive local or left hand - part, is encoded into a DNS name in a readable fashion where the case - of some letters might be changed on output as described above. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Copyright and Disclaimer - - Copyright (C) The Internet Society 2004. This document is subject to - the rights, licenses and restrictions contained in BCP 78, and except - as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Normative References - - [ASCII] - ANSI, "USA Standard Code for Information Interchange", - X3.4, American National Standards Institute: New York, 1968. - - [RFC 1034, 1035] - See [STD 13]. - - [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August - 1996. - - [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", March 1997. - - [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. - - [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", - March 1999. - - [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic - Update", November 2000. - - [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", - draft-ietf-dnsext-unknown-rrs-05.txt, March 2003. - - [STD 13] - - P. Mockapetris, "Domain names - concepts and facilities", RFC - 1034, November 1987. - - P. Mockapetris, "Domain names - implementation and - specification", RFC 1035, November 1987. - - - - - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Informative References - - [RFC 1591] - J. Postel, "Domain Name System Structure and - Delegation", March 1994. - - [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", - June 1999. - - [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain - Name System (DNS) IANA Considerations", September 2000. - - [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August - 1999. - - [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", - August 1999. - - [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of - Foo", 1 April 2001. - - [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of - Internationalized String ("stringprep")", December 2002. - - [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello, - "Internationalizing Domain Names in Applications (IDNA)", March 2003. - - [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile - for Internationalized Domain Names (IDN)", March 2003. - - [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode - for Internationalized Domain Names in Applications (IDNA)", March - 2003. - - [UNICODE] - The Unicode Consortium, "The Unicode Standard", - . - - - --02 to -03 Changes - - The following changes were made between draft version -02 and -03: - - 1. Add internationalized domain name section and references. - - 2. Change to indicate that later input of a label for an existing DNS - name tree node may or may not be normalized to the earlier input or - override it or both may be preserved. - - 3. Numerous minor wording changes. - - - -D. Eastlake 3rd [Page 10] - - -INTERNET-DRAFT DNS Case Insensitivity - - --03 to -04 Changes - - The following changes were made between draft version -03 and -04: - - 1. Change to conform to the new IPR, Copyright, etc., notice - requirements. - - 2. Change in some section headers for clarity. - - 3. Drop section on wildcards. - - 4. Add emphasis on loss of case preservation due to name compression. - - 5. Add references to RFCs 1995 and 3092. - - - -Author's Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1 508-786-7554 (w) - +1 508-634-2066 (h) - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires December 2004. - - Its file name is draft-ietf-dnsext-insensitive-04.txt. - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 11] - - + +INTERNET-DRAFT Donald E. Eastlake 3rd +Updates RFC 1034, 1035 Motorola Laboratories +Expires July 2005 January 2005 + + + + Domain Name System (DNS) Case Insensitivity Clarification + ------ ---- ------ ----- ---- ------------- ------------- + + + Donald E. Eastlake 3rd + + + +Status of This Document + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + or will be 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. + + 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 + + + +Copyright Notice + + Copyright (C) The Internet Society. All Rights Reserved. + + + +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 updates RFCs 1034 and 1035. + + +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, Thomas Narten, and Scott Seligman + are gratefully acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Copyright Notice...........................................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 + + Full Copyright Notice and Disclaimer.......................9 + Normative References.......................................9 + Informative References....................................10 + -02 to -03 Changes........................................10 + -03 to -04 Changes........................................11 + -04 to -05 Changes........................................11 + Author's Address..........................................11 + Expiration and File Name..................................12 + + + + + + + + + + + + +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. This clarification updates RFCs 1034 + and 1035 [STD 13]. + + 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. + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DNS Case Insensitivity + + + One typographic convention for octets that do not correspond to an + 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 all + 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 + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DNS Case Insensitivity + + + terms were "majuscule" and "minuscule".) + + 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 + + +Full Copyright Notice and Disclaimer + + Copyright (C) The Internet Society 2005. 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 + + [ISO 8859-1] - International Standards Organization, Standard for + Character Encodings, Latin-1. + + [ISO 8859-2] - International Standards Organization, Standard for + Character Encodings, Latin-2. + + [RFC 1591] - J. Postel, "Domain Name System Structure and + Delegation", March 1994. + + [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", + June 1999. + + [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain + Name System (DNS) IANA Considerations", September 2000. + + [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August + 1999. + + [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", + August 1999. + + [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of + Foo", 1 April 2001. + + [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of + Internationalized String ("stringprep")", December 2002. + + [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", March 2003. + + [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile + for Internationalized Domain Names (IDN)", March 2003. + + [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in Applications (IDNA)", March + 2003. + + [UNICODE] - The Unicode Consortium, "The Unicode Standard", + . + + + +-02 to -03 Changes + + The following changes were made between draft version -02 and -03: + + 1. Add internationalized domain name section and references. + + + +D. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT DNS Case Insensitivity + + + 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. + + + +-03 to -04 Changes + + The following changes were made between draft versions -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. + + + +-04 to -05 Changes + + The following changes were made between draft versions -04 and -05: + + 1. More clearly state that this draft updates RFCs 1034, 1035 [STD + 13]. + + 2. Add informative references to ISO 8859-1 and ISO 8859-2. + + 3. Fix hyphenation and capitalization nits. + + + +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 + + + + +D. Eastlake 3rd [Page 11] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Expiration and File Name + + This draft expires July 2005. + + Its file name is draft-ietf-dnsext-insensitive-05.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 12] + + diff --git a/doc/draft/draft-ietf-dnsext-mdns-37.txt b/doc/draft/draft-ietf-dnsext-mdns-38.txt similarity index 84% rename from doc/draft/draft-ietf-dnsext-mdns-37.txt rename to doc/draft/draft-ietf-dnsext-mdns-38.txt index 86d7de88a9..ac51706af2 100644 --- a/doc/draft/draft-ietf-dnsext-mdns-37.txt +++ b/doc/draft/draft-ietf-dnsext-mdns-38.txt @@ -1,14 +1,9 @@ - - - - - DNSEXT Working Group Levon Esibov INTERNET-DRAFT Bernard Aboba Category: Standards Track Dave Thaler - Microsoft -20 October 2004 + Microsoft +19 February 2005 Linklocal Multicast Name Resolution (LLMNR) @@ -35,11 +30,11 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 22, 2005. + This Internet-Draft will expire on August 22, 2005. Copyright Notice - Copyright (C) The Internet Society 2004. All rights reserved. + Copyright (C) The Internet Society 2005. All rights reserved. Abstract @@ -61,7 +56,7 @@ Esibov, Aboba & Thaler Standards Track [Page 1] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 Table of Contents @@ -74,33 +69,33 @@ Table of Contents 2.2 Sender behavior ................................. 8 2.3 Responder behavior .............................. 9 2.4 Unicast queries ................................. 11 - 2.5 Off-link detection .............................. 11 - 2.6 Responder responsibilities ...................... 12 + 2.5 Off-link detection .............................. 12 + 2.6 Responder responsibilities ...................... 13 2.7 Retransmission and jitter ....................... 13 2.8 DNS TTL ......................................... 14 2.9 Use of the authority and additional sections .... 14 -3. Usage model ........................................... 14 - 3.1 LLMNR configuration ............................. 15 +3. Usage model ........................................... 15 + 3.1 LLMNR configuration ............................. 16 4. Conflict resolution ................................... 17 - 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 ............................................ 23 - 7.1 Normative References ............................ 23 - 7.2 Informative References .......................... 23 -Acknowledgments .............................................. 25 -Authors' Addresses ........................................... 25 -Intellectual Property Statement .............................. 25 -Disclaimer of Validity ....................................... 26 -Copyright Statement .......................................... 26 - - - + 4.1 Uniqueness Verification ......................... 18 + 4.2 Conflict Detection and Defense .................. 18 + 4.3 Considerations for multiple interfaces .......... 20 + 4.4 API issues ...................................... 21 +5. Security considerations ............................... 21 + 5.1 Scope restriction ............................... 22 + 5.2 Usage restriction ............................... 23 + 5.3 Cache and port separation ....................... 23 + 5.4 Authentication .................................. 24 +6. IANA considerations ................................... 24 +7. Constants ............................................. 24 +8. References ............................................ 24 + 8.1 Normative References ............................ 24 + 8.2 Informative References .......................... 25 +Acknowledgments .............................................. 26 +Authors' Addresses ........................................... 27 +Intellectual Property Statement .............................. 27 +Disclaimer of Validity ....................................... 28 +Copyright Statement .......................................... 28 @@ -121,7 +116,7 @@ Esibov, Aboba & Thaler Standards Track [Page 2] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 1. Introduction @@ -181,7 +176,7 @@ Esibov, Aboba & Thaler Standards Track [Page 3] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 and "OPTIONAL" in this document are to be interpreted as described in @@ -241,7 +236,7 @@ Esibov, Aboba & Thaler Standards Track [Page 4] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 responder. A host MAY be configured as a sender, but not a @@ -301,7 +296,7 @@ Esibov, Aboba & Thaler Standards Track [Page 5] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 [d] Upon reception of the response, the sender processes it. @@ -329,7 +324,7 @@ INTERNET-DRAFT LLMNR 20 October 2004 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE | + |QR| Opcode | Z|TC| U| C| Z| Z| Z| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ @@ -361,7 +356,7 @@ Esibov, Aboba & Thaler Standards Track [Page 6] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 OPCODE @@ -383,6 +378,19 @@ TC TrunCation - specifies that this message was truncated due to destination address. See [RFC2181] and Section 2.4 of this specification for further discussion of the TC bit. +U UNIQUE - specifies that this message is a UNIQUEness query. The U + bit MUST NOT be set in an LLMNR response, and if set is ignored by + an LLMNR sender. If the U bit is set in an LLMNR query, this + indicates that the sender believes that it is authoritative for the + name. See Section 4.1 and 4.2 for discussion of name conflict + detection. + +C Conflict - specifies that a sender has previously received multiple + LLMNR responses to this query. The C bit MUST NOT be set in an + LLMNR response, and if set is ignored by an LLMNR sender. + Responders do not respond to LLMNR queries with the 'C' bit set; + since no response is expected, LLMNR senders do not retransmit. + 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 @@ -399,6 +407,18 @@ RCODE LLMNR response with a non-zero RCODE sent in response to a multicast query. + + + +Esibov, Aboba & Thaler Standards Track [Page 7] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + 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, @@ -412,18 +432,6 @@ RCODE with an RCODE of 3; instead, they should not respond at all. LLMNR implementations MUST support EDNS0 [RFC2671] and extended - - - -Esibov, Aboba & Thaler Standards Track [Page 7] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - RCODE values. QDCOUNT @@ -459,6 +467,18 @@ ARCOUNT may be sent. The sender MUST anticipate receiving no replies to some LLMNR + + + +Esibov, Aboba & Thaler Standards Track [Page 8] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + 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 @@ -472,18 +492,6 @@ ARCOUNT The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers - - - -Esibov, Aboba & Thaler Standards Track [Page 8] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - receive the query and respond with valid answers. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same @@ -519,6 +527,18 @@ INTERNET-DRAFT LLMNR 20 October 2004 ip6.arpa IN PTR host1. (line split for formatting reasons) IN PTR host1.example.com. + + + +Esibov, Aboba & Thaler Standards Track [Page 9] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + 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. @@ -532,18 +552,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 [b] Responders MUST direct responses to the port from which the query was sent. When queries are received via TCP this is an inherent - - - -Esibov, Aboba & Thaler Standards Track [Page 9] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - 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 MUST always be sent @@ -551,7 +559,8 @@ INTERNET-DRAFT LLMNR 20 October 2004 [c] Responders MUST respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and - reverse lookups. + reverse lookups, with the exception of queries with the 'C' bit + set, which do not elicit a response. [d] Responders MUST NOT respond to LLMNR queries for names they are not authoritative for. @@ -579,6 +588,17 @@ INTERNET-DRAFT LLMNR 20 October 2004 query is received, the responder would respond with RCODE=0 and an empty answer section. + + +Esibov, Aboba & Thaler Standards Track [Page 10] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + 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 @@ -592,18 +612,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 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 - - - -Esibov, Aboba & Thaler Standards Track [Page 10] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - 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.". @@ -639,6 +647,18 @@ INTERNET-DRAFT LLMNR 20 October 2004 Unicast UDP queries MUST be silently discarded. If TCP connection setup cannot be completed in order to send a + + + +Esibov, Aboba & Thaler Standards Track [Page 11] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + 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 @@ -652,18 +672,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 link-local address, defined in [RFC2373], or one belonging to a prefix that a Router Advertisement indicates is on-link [RFC2461]. - - - -Esibov, Aboba & Thaler Standards Track [Page 11] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - 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. @@ -700,6 +708,17 @@ INTERNET-DRAFT LLMNR 20 October 2004 received packets with recvmsg(). [RFC2292] specifies similar options for setting and retrieving the IPv6 Hop Limit. + + +Esibov, Aboba & Thaler Standards Track [Page 12] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + 2.6. Responder responsibilities It is the responsibility of the responder to ensure that RRs returned @@ -712,18 +731,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 that address MUST be valid on the local link over which LLMNR is used. - - - -Esibov, Aboba & Thaler Standards Track [Page 12] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - [b] If an IPv4 address is returned, it MUST be reachable through the link over which LLMNR is used. @@ -753,12 +760,25 @@ INTERNET-DRAFT LLMNR 20 October 2004 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. + handled by the transport layer. Queries with the 'C' bit set MUST be + sent over UDP and MUST NOT be retransmitted. 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 + + + +Esibov, Aboba & Thaler Standards Track [Page 13] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + 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 @@ -771,26 +791,16 @@ INTERNET-DRAFT LLMNR 20 October 2004 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 500ms, a - - - -Esibov, Aboba & Thaler Standards Track [Page 13] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - - minimum RTO of 100ms, and a maximum RTO of 5 seconds. + paragraph 2.5). 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). + the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by + responders responding with RRs which they have previously determined + to be UNIQUE (see Section 4 for details). + + Recommended values for constants (including LLMNR_TIMEOUT if it is + set statically) are given in Section 7. 2.8. DNS TTL @@ -817,10 +827,29 @@ INTERNET-DRAFT LLMNR 20 October 2004 [RFC2308]. The owner name of this SOA record MUST be equal to the query name. - In LLMNR, the additional section is only intended for use by EDNS0, - TSIG and SIG(0). As a result, senders MAY only include pseudo RR- - types in the additional section of a query; responders MUST ignore - the additional section of queries containing other RR types. + + + +Esibov, Aboba & Thaler Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + In LLMNR, the additional section is primarily intended for use by + EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, + senders MAY only include pseudo RR-types in the additional section of + a query; unless the 'C' bit is set, responders MUST ignore the + additional section of queries containing other RR types. + + In queries where the 'C' bit is set, the sender SHOULD include the + conflicting RRs in the additional section. Since conflict + notifications are advisory, responders SHOULD log information from + the additional section, but otherwise MUST ignore the additional + section. Senders MUST NOT cache RRs from the authority or additional section of a response as answers, though they may be used for other purposes @@ -832,18 +861,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 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, - - - -Esibov, Aboba & Thaler Standards Track [Page 14] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - robust DNS resolver implementations are more likely to avoid unnecessary LLMNR queries. @@ -870,6 +887,18 @@ INTERNET-DRAFT LLMNR 20 October 2004 will also reduce unnecessary LLMNR queries. [RFC1536] Section 6 describes name error bugs and recommended + + + +Esibov, Aboba & Thaler Standards Track [Page 15] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + searchlist processing that will reduce unnecessary RCODE=3 (authoritative name) errors, thereby also reducing unnecessary LLMNR queries. @@ -892,18 +921,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 IPv6. Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], - - - -Esibov, Aboba & Thaler Standards Track [Page 15] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - 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 @@ -930,6 +947,18 @@ INTERNET-DRAFT LLMNR 20 October 2004 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 + + + +Esibov, Aboba & Thaler Standards Track [Page 16] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + 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 @@ -952,18 +981,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 continuing to use LLMNR even once the outage is repaired. Since LLMNR only enables linklocal name resolution, this represents a degradation in capabilities. As a result, hosts without a configured - - - -Esibov, Aboba & Thaler Standards Track [Page 16] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - DNS server may wish to periodically attempt to obtain DNS configuration if permitted by the configuration mechanism in use. In the absence of other guidance, a default retry interval of one (1) @@ -982,21 +999,37 @@ INTERNET-DRAFT LLMNR 20 October 2004 type record for a name. By default, a responder SHOULD be configured to behave as though all - RRs are UNIQUE on each interface on which LLMNR is enabled. Prior to - including a UNIQUE resource record in a response, for each UNIQUE - resource record in a given interface's configuration, the host MUST - verify that there is no other host within the scope of LLMNR query - propagation that can return a resource record for the same name, type - and class on that interface. Once a responder has verified the - uniqueness of a UNIQUE resource record, if it receives an LLMNR query - for that resource record, it MUST respond. + RRs are UNIQUE on each interface on which LLMNR is enabled. - To verify uniqueness, a responder MUST send an LLMNR query for each - UNIQUE resource record. If no response is received after a suitable - number of attempts (see Section 2.7), the responder can use the - UNIQUE resource record in response to LLMNR queries. If a response - is received, the responder MUST NOT use the UNIQUE resource record in - response to LLMNR queries. + 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. + + + +Esibov, Aboba & Thaler Standards Track [Page 17] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + +4.1. Uniqueness Verification + + Prior to including a UNIQUE resource record in a response, for each + UNIQUE resource record in a given interface's configuration, the host + MUST verify that there is no other host within the scope of LLMNR + query propagation that can return a resource record for the same + name, type and class on that interface. + + Once a responder has verified the uniqueness of a UNIQUE resource + record, if it receives an LLMNR query for that resource record, with + the 'C' bit clear, it MUST respond. Uniqueness verification is carried out when the host: @@ -1010,38 +1043,105 @@ INTERNET-DRAFT LLMNR 20 October 2004 - verifies the acquisition of a new IP address and configuration on an interface - The name conflict detection mechanism doesn't prevent name conflicts - when previously partitioned segments are connected by a bridge. It + To verify uniqueness, a responder MUST send an LLMNR query with the + 'U' bit set for each UNIQUE resource record. If no response is + received, the sender retransmits the query, as specified in Section + 2.7. If a response is received, the responder MUST NOT use the UNIQUE + resource record in response to LLMNR queries. + + Periodically carrying out uniqueness verification in an attempt to + detect name conflicts is not necessary, wastes network bandwidth, and + may actually be detrimental. For example, if network links are + joined only briefly, and are separated again before any new + communication is initiated, temporary conflicts are benign and no + forced reconfiguration is required. Triggering a reconfiguration in + this case would not serve any useful purpose. LLMNR responders + SHOULD NOT periodically attempt uniqueness verification. + +4.2. Conflict Detection and Defense + + Hosts on disjoint network links may configure the same name for use + with LLMNR. If these separate network links are later joined or + bridged together, then there may be multiple hosts which are now on + the same link, trying to use the same name. + + There are several mechanisms by which ongoing name conflicts may be + detected: -Esibov, Aboba & Thaler Standards Track [Page 17] +Esibov, Aboba & Thaler Standards Track [Page 18] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 - also does not prevent deadlocks where two hosts attempt to verify - uniqueness of the same RR, yet neither can yet respond to queries - since uniqueness has not yet been verified. +[a] Receipt of a query with the 'U' bit set. Whenever an LLMNR + responder receives an LLMNR query for a UNIQUE resource record with + the 'U' bit set, if the source IP address does not match an IP + address configured on that interface, this indicates a conflict. - In order to minimize the chance of conflicts in such situations, 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. +[b] Conflict notification queries. When an LLMNR sender receives + multiple LLMNR responses to a query, it MUST send another query for + the same resource record, this time with the 'C' bit set, with the + answers received included in the Additional section. - 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. + Queries with the 'C' bit set are considered advisory and responders + MUST verify the existence of a conflict by other means before + acting on it. A responder receiving a query with the 'C' bit set + MUST NOT respond. If the resource record is not UNIQUE, then the + responder MUST ignore the query. If the resource record is UNIQUE, + then the responder MUST send its own query for the same resource + record, with the 'U' bit set. If a response is received, or if a + query with the 'U' bit set is received, then a conflict has been + detected. -4.1. Considerations for Multiple Interfaces +An LLMNR responder MUST NOT ignore conflicts once detected. An LLMNR +responder MUST respond to a conflict as described in either [1] or [2] +below: + +[1] Upon detecting a conflict, an LLMNR responder MAY elect to + immediately stop using the conflicting UNIQUE resource record in + response to LLMNR queries. + + The responder MAY also elect to configure a new name. However, + since name reconfiguration may be disruptive, this is not required, + and a responder may have been configured to respond to multiple + names so that alternative names may already be available. + +[2] If a responder currently has reasons to prefer using the name, and + it has not seen any other conflicting LLMNR queries within the last + DEFEND_INTERVAL seconds, then it MAY elect to defend its name, by + recording the time that the conflicting LLMNR query was received, + and then sending multicast queries for its UNIQUE resource records, + with the 'U' bit set. + + Having done this, an LLMNR responder can then continue to use the + name normally without any further special action. However, if this + is not the first conflicting LLMNR query the responder has seen, + and the time recorded for the previous conflicting LLMNR query is + recent, within DEFEND_INTERVAL, then the LLMNR responder MUST + immediately cease using the conflicting resource records. + + This is necessary to ensure that two hosts do not get stuck in an + + + +Esibov, Aboba & Thaler Standards Track [Page 19] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + endless loop with both hosts trying to defend the same name. + +4.3. 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. @@ -1072,18 +1172,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 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 20 October 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. @@ -1100,6 +1188,17 @@ INTERNET-DRAFT LLMNR 20 October 2004 query for the host RR for name "A" it will receive a response from hosts on both interfaces. + + +Esibov, Aboba & Thaler Standards Track [Page 20] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + Host myhost cannot distinguish between the situation shown in Figure 2, and that shown in Figure 3 where no conflict exists. @@ -1118,7 +1217,7 @@ INTERNET-DRAFT LLMNR 20 October 2004 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 +4.4. API issues [RFC2553] provides an API which can partially solve the name ambiguity problem for applications written to use this API, since the @@ -1132,18 +1231,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 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 20 October 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 @@ -1160,6 +1247,18 @@ INTERNET-DRAFT LLMNR 20 October 2004 sent to a link-scope multicast address, where every host on the logical link will be made aware of it. + + + +Esibov, Aboba & Thaler Standards Track [Page 21] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + In order to address the security vulnerabilities, the following mechanisms are contemplated: @@ -1192,18 +1291,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 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 20 October 2004 - - possible for an attacker to spoof a response to a 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 @@ -1220,6 +1307,18 @@ INTERNET-DRAFT LLMNR 20 October 2004 queries for which they are authoritative, and LLMNR does not provide wildcard query support, it is believed that this threat is minimal. + + + +Esibov, Aboba & Thaler Standards Track [Page 22] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + 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 @@ -1252,18 +1351,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 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 - - - -Esibov, Aboba & Thaler Standards Track [Page 21] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - cache, eliminating the benefits of cache separation. As a result, LLMNR is only used as a name resolution mechanism of last resort. @@ -1279,6 +1366,19 @@ INTERNET-DRAFT LLMNR 20 October 2004 LLMNR operates on a separate port from DNS, reducing the likelihood that a DNS server will unintentionally respond to an LLMNR query. + + + + +Esibov, Aboba & Thaler Standards Track [Page 23] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + 5.4. Authentication LLMNR implementations MAY support TSIG and/or SIG(0) security @@ -1307,30 +1407,38 @@ INTERNET-DRAFT LLMNR 20 October 2004 224.0.0.252, as well as link-scope multicast IPv6 address FF02:0:0:0:0:0:1:3. +7. Constants + The following timing constants are used in this protocol; they are + not intended to be user configurable. + DEFEND_INTERVAL 10 seconds (minimum interval between + defensive LLMNR queries). + JITTER_INTERVAL 100 ms + LLMNR_TIMEOUT 1 second (only if set statically) + RTOinit 500 ms (initial value of LLMNR_TIMEOUT) + RTOmax 5 seconds (maximum value of LLMNR_TIMEOUT) + RTOmin 100 ms (minimum value of LLMNR_TIMEOUT) +8. References - - - - -Esibov, Aboba & Thaler Standards Track [Page 22] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - -7. References - -7.1. Normative References +8.1. Normative References [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. + + + +Esibov, Aboba & Thaler Standards Track [Page 24] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. @@ -1368,28 +1476,29 @@ INTERNET-DRAFT LLMNR 20 October 2004 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. -7.2. Informative References +8.2. Informative References [RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested Fixes", RFC 1536, October 1993. - - -Esibov, Aboba & Thaler Standards Track [Page 23] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. + + + +Esibov, Aboba & Thaler Standards Track [Page 25] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. @@ -1432,24 +1541,24 @@ INTERNET-DRAFT LLMNR 20 October 2004 (work in progress), draft-ietf-ipn-gwg-icmp-name- lookups-09.txt, May 2002. - - - -Esibov, Aboba & Thaler Standards Track [Page 24] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - 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 + + + +Esibov, Aboba & Thaler Standards Track [Page 26] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + has also been received from Mark Andrews, Rob Austein, Randy Bush, Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, @@ -1492,24 +1601,24 @@ Intellectual Property Statement 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 - - - -Esibov, Aboba & Thaler Standards Track [Page 25] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - 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. + + + +Esibov, Aboba & Thaler Standards Track [Page 27] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + 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 @@ -1528,7 +1637,7 @@ Disclaimer of Validity Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2005). 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. @@ -1555,5 +1664,14 @@ Open Issues -Esibov, Aboba & Thaler Standards Track [Page 26] + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 28] + + + diff --git a/doc/draft/draft-ietf-dnsext-nsec3-00.txt b/doc/draft/draft-ietf-dnsext-nsec3-01.txt similarity index 79% rename from doc/draft/draft-ietf-dnsext-nsec3-00.txt rename to doc/draft/draft-ietf-dnsext-nsec3-01.txt index 2b4ac79ec2..10d8118412 100644 --- a/doc/draft/draft-ietf-dnsext-nsec3-00.txt +++ b/doc/draft/draft-ietf-dnsext-nsec3-01.txt @@ -1,13 +1,15 @@ + Network Working Group B. Laurie Internet-Draft G. Sisson -Expires: July 2, 2005 Nominet +Expires: August 2, 2005 Nominet R. Arends Telematica Instituut - january 2005 + february 2005 + DNSSEC Hash Authenticated Denial of Existence - draft-ietf-dnsext-nsec3-00 + draft-ietf-dnsext-nsec3-01 Status of this Memo @@ -34,7 +36,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 2, 2005. + This Internet-Draft will expire on August 2, 2005. Copyright Notice @@ -48,8 +50,12 @@ Abstract a listing of all ownernames. -Laurie, et al. Expires July 2, 2005 [Page 1] -Internet-Draft nsec3 january 2005 + + +Laurie, et al. Expires August 2, 2005 [Page 1] + +Internet-Draft nsec3 february 2005 + A complete zone file can be used either directly as a source of probable e-mail addresses for spam, or indirectly as a key for @@ -64,28 +70,6 @@ Internet-Draft nsec3 january 2005 names. Non-authoritative delegation point NS RR types may be excluded. - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires July 2, 2005 [Page 2] -Internet-Draft nsec3 january 2005 - Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 @@ -104,26 +88,35 @@ Table of Contents 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 8 3. Creating Additional NSEC3 RR for Empty Non Terminals . . . . . 9 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 9 - 5. Special Considerations . . . . . . . . . . . . . . . . . . . . 9 - 5.1 delegation points . . . . . . . . . . . . . . . . . . . . 10 - 5.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 10 - 5.2 Additional Complexity Caused by Wildcards . . . . . . . . 11 - 5.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 11 - 5.4.1 Avoiding Hash Collisions during generation . . . . . . 11 - 5.4.2 Second Preimage Requirement Analysis . . . . . . . . . 11 - 5.4.3 Possible Hash Value Truncation Method . . . . . . . . 12 - 6. Performance Considerations . . . . . . . . . . . . . . . . . . 12 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 9. Requirements notation . . . . . . . . . . . . . . . . . . . . 13 - 10. Security Considerations . . . . . . . . . . . . . . . . . . 13 - A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 - 11.2 Informative References . . . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 - Intellectual Property and Copyright Statements . . . . . . . . 17 + 5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 9 + 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 10 + 6.1 delegation points . . . . . . . . . . . . . . . . . . . . 10 + 6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11 + 6.2 Additional Complexity Caused by Wildcards . . . . . . . . 11 + 6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 12 + 6.4.1 Avoiding Hash Collisions during generation . . . . . . 12 + 6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 12 + 6.4.3 Possible Hash Value Truncation Method . . . . . . . . 13 + 7. Performance Considerations . . . . . . . . . . . . . . . . . . 13 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 10. Requirements notation . . . . . . . . . . . . . . . . . . . 14 + 11. Security Considerations . . . . . . . . . . . . . . . . . . 14 + A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + + + +Laurie, et al. Expires August 2, 2005 [Page 2] + +Internet-Draft nsec3 february 2005 + + + 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 + 12.2 Informative References . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 + Intellectual Property and Copyright Statements . . . . . . . . 18 @@ -131,8 +124,50 @@ Table of Contents -Laurie, et al. Expires July 2, 2005 [Page 3] -Internet-Draft nsec3 january 2005 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires August 2, 2005 [Page 3] + +Internet-Draft nsec3 february 2005 + 1. Introduction @@ -184,10 +219,13 @@ Internet-Draft nsec3 january 2005 ownername. Because this proposal uses the result of a hash function -Laurie, et al. Expires July 2, 2005 [Page 4] -Internet-Draft nsec3 january 2005 - over the original (unmodified) ownername, this result is refered to +Laurie, et al. Expires August 2, 2005 [Page 4] + +Internet-Draft nsec3 february 2005 + + + over the original (unmodified) ownername, this result is referred to as "hashed ownername". 2. The NSEC3 Resource Record @@ -235,8 +273,13 @@ Internet-Draft nsec3 january 2005 -Laurie, et al. Expires July 2, 2005 [Page 5] -Internet-Draft nsec3 january 2005 + + + +Laurie, et al. Expires August 2, 2005 [Page 5] + +Internet-Draft nsec3 february 2005 + 2.1.1 The Authoritative Only Flag Field @@ -258,7 +301,7 @@ Internet-Draft nsec3 january 2005 ownername MUST be set if the NSEC3 covers a delegation, even though the NS RR itself is not authoritative. This implies that all delegations, signed or unsigned, have an NSEC3 record associated. - This behavior is identical to NSEC behavior. + This behaviour is identical to NSEC behaviour. 2.1.2 The Hash Function Field @@ -288,8 +331,11 @@ Internet-Draft nsec3 january 2005 of 0. -Laurie, et al. Expires July 2, 2005 [Page 6] -Internet-Draft nsec3 january 2005 + +Laurie, et al. Expires August 2, 2005 [Page 6] + +Internet-Draft nsec3 february 2005 + The salt field is prepended to the original ownername before hashing in order to defend against precalculated dictionary attacks. @@ -340,8 +386,12 @@ Internet-Draft nsec3 january 2005 Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + -Laurie, et al. Expires July 2, 2005 [Page 7] -Internet-Draft nsec3 january 2005 + + +Laurie, et al. Expires August 2, 2005 [Page 7] + +Internet-Draft nsec3 february 2005 + 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 @@ -373,7 +423,7 @@ Internet-Draft nsec3 january 2005 bitmap is determined by the type code with the largest numerical value, within that block, among the set of RR types present at the NSEC3 RR's actual ownername. Trailing zero octets not specified MUST - be interpretted as zero octets. + be interpreted as zero octets. 2.2 The NSEC3 RR Presentation Format @@ -393,8 +443,11 @@ Internet-Draft nsec3 january 2005 hexadecimal digits. Whitespace is not allowed within the sequence. -Laurie, et al. Expires July 2, 2005 [Page 8] -Internet-Draft nsec3 january 2005 + +Laurie, et al. Expires August 2, 2005 [Page 8] + +Internet-Draft nsec3 february 2005 + The Salt Field is represented as 00 when the Salt Length field has value 0. @@ -409,7 +462,7 @@ Internet-Draft nsec3 january 2005 3. Creating Additional NSEC3 RR for Empty Non Terminals - In order to prove the nonexistence of a record that might be covered + In order to prove the non-existence of a record that might be covered by a wildcard, it is necessary to prove the existence of its closest encloser. A closest encloser might be an Empty Non Terminal. @@ -441,27 +494,82 @@ Internet-Draft nsec3 january 2005 original unexpanded form, including the "*" label (no wildcard substitution); -5. Special Considerations +5. Including NSEC3 RRs in a Zone - The following paragraphs clarify specific behavior explain special + Each owner name in the zone which has authoritative data or a secured -Laurie, et al. Expires July 2, 2005 [Page 9] -Internet-Draft nsec3 january 2005 +Laurie, et al. Expires August 2, 2005 [Page 9] + +Internet-Draft nsec3 february 2005 + + + delegation point NS RRset MUST have an NSEC3 resource record. + + An unsecured delegation point NS RRset MAY have an NSEC3 resource + record. This is different from NSEC records where an unsecured + delegation point NS RRset MUST have an NSEC record. + + The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + The type bitmap of every NSEC3 resource record in a signed zone MUST + indicate the presence of both the NSEC3 record itself and its + corresponding RRSIG record. + + The bitmap for the NSEC3 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. + + The following steps describe the proper construction of NSEC3 + records. + 1. Sort the zone in canonical order. + 2. For each unique original owner name, add a NSEC3 RRset, where the + ownername of the NSEC3 RR is the hashed equivalent of the + original owner name, prepended to the zone name. + 3. For each RRset at the original owner, set the corresponding bit + in the type bit map. If the RRset signifies an unsecured + delegation point, and the policy is to have Authoritative Only + RRsets, mark this NSEC3 RR. + 4. If the difference in labels between the apex and the original + ownername is greater then 1, additional NSEC3 need to be added + for every intermediate label level between the apex and the + original ownername. + 5. sort the set of NSEC3 RRs. + 6. In each NSEC3 RR, insert the Next Hashed Ownername. If the next + hashed ownername is a marked NSEC3 (from step 3), delete the + marked NSEC3 from the zone, set the Authoritative Only bit in the + current NSEC3 RRs, and repeat this step. The last NSEC3 in the + zone will contain the value of the first NSEC3 in the zone. + +6. Special Considerations + + The following paragraphs clarify specific behaviour explain special considerations for implementations. -5.1 delegation points +6.1 delegation points This proposal introduces the Authoritative Only Flag which indicates + + + +Laurie, et al. Expires August 2, 2005 [Page 10] + +Internet-Draft nsec3 february 2005 + + whether non authoritative delegation point NS records are included in the type bit Maps. As discussed in paragraph 2.1.1, a flag value of 0 indicates that the interpretation of the type bit maps is identical to NSEC records. - The following subsections describe behavior when the flag value is 1. + The following subsections describe behaviour when the flag value is + 1. -5.1.1 Unsigned Delegations +6.1.1 Unsigned Delegations Delegation point NS records are not authoritative. They are authoritative in the delegated zone. No other data exists at the @@ -498,13 +606,17 @@ Internet-Draft nsec3 january 2005 The only possible mitigation is to either not use this method, hence proving absence of unsigned delegations. - -Laurie, et al. Expires July 2, 2005 [Page 10] -Internet-Draft nsec3 january 2005 - -5.2 Additional Complexity Caused by Wildcards +6.2 Additional Complexity Caused by Wildcards If a wildcard ownername appears in a zone, the wildcard label ("*") + + + +Laurie, et al. Expires August 2, 2005 [Page 11] + +Internet-Draft nsec3 february 2005 + + is treated as a literal symbol and is treated in the same way as any other ownername for purposes of generating NSEC3 RRs. RFC 2535 [RFC2525] describes the impact of wildcards on authenticated denial @@ -512,10 +624,10 @@ Internet-Draft nsec3 january 2005 In order to prove there are no wildcards for a domain, as well as no RRs that match directly, an RR must be shown for the closest - encloser, and nonexistence must be shown for all enclosers that could - be closer. + encloser, and non-existence must be shown for all enclosers that + could be closer. -5.3 Salting +6.3 Salting Augmenting original ownernames with salt before hashing increases the cost of a dictionary of pre-generated hash-values. For every bit of @@ -525,7 +637,7 @@ Internet-Draft nsec3 january 2005 The salt value for each NSEC3 RR MUST be equal for a single version of the zone. -5.4 Hash Collision +6.4 Hash Collision Hash collisions occur when different messages have the same hash value. The expected number of domain names needed to give a 1 in 2 @@ -534,30 +646,33 @@ Internet-Draft nsec3 january 2005 collisions and assessing possible damage in the event of an attack using Hash collisions. -5.4.1 Avoiding Hash Collisions during generation +6.4.1 Avoiding Hash Collisions during generation During generation of NSEC3 RRs, hash values are supposedly unique. - In the (academic) case of a collision occuring, an alternative salt + In the (academic) case of a collision occurring, an alternative salt SHOULD be chosen and all hash values SHOULD be regenerated. If hash values are not regenerated on collision, the NSEC3 RR MUST list all authoritative RR types that exist for both owners, to avoid a replay attack, spoofing an existing type as non-existent. -5.4.2 Second Preimage Requirement Analysis +6.4.2 Second Preimage Requirement Analysis A collision resistant hash function has a second-preimage resistance property. The second-preimage resistance property means that it is computationally infeasible to find another message with the same hash value as a given message, i.e. given preimage X, to find a second - - -Laurie, et al. Expires July 2, 2005 [Page 11] -Internet-Draft nsec3 january 2005 - preimage X' <> X such that hash(X) = hash(X'). The probability of finding a second preimage is 1 in 2^160 for SHA-1 on average. To mount an attack using an existing NSEC3 RR, an adversary needs to + + + +Laurie, et al. Expires August 2, 2005 [Page 12] + +Internet-Draft nsec3 february 2005 + + find a second preimage. Assuming an adversary is capable of mounting such an extreme attack, @@ -569,7 +684,7 @@ Internet-Draft nsec3 january 2005 adversary can't mount this attack on an existing name but only on a name that the adversary can't choose and does not yet exist. -5.4.3 Possible Hash Value Truncation Method +6.4.3 Possible Hash Value Truncation Method The previous sections outlined the low probability and low impact of a second-preimage attack. When impact and probability are low, while @@ -593,25 +708,28 @@ Internet-Draft nsec3 january 2005 and limited space in DNS messages, the balance between truncation profit and collision damage may be determined by local policy. -6. Performance Considerations +7. Performance Considerations Iterated hashes will obviously impose a performance penalty on both authoritative servers and resolvers. Therefore, the number of iterations should be carefully chosen. -7. IANA Considerations +8. IANA Considerations IANA has to create a new registry for NSEC3 Hash Functions. The range for this registry is 0-127. Value 1 is marked as SHA-1. - - -Laurie, et al. Expires July 2, 2005 [Page 12] -Internet-Draft nsec3 january 2005 - Values 0, 2-126 are marked as Reserved For Future Use. Value 127 is marked as Experimental. -8. Security Considerations + + + +Laurie, et al. Expires August 2, 2005 [Page 13] + +Internet-Draft nsec3 february 2005 + + +9. Security Considerations The NSEC3 records are still susceptible to dictionary attacks (i.e. the attacker retrieves all the NSEC3 records, then calculates the @@ -635,17 +753,17 @@ Internet-Draft nsec3 january 2005 found. Hash collisions may occur. If they do, it will be impossible to - prove the nonexistence of the colliding domain - however, this is + prove the non-existence of the colliding domain - however, this is fantastically unlikely, and, in any case, DNSSEC already relies on SHA-1 to not collide. -9. Requirements notation +10. Requirements notation 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]. -10. Security Considerations +11. Security Considerations Appendix A. Example Zone @@ -655,48 +773,58 @@ Appendix A. Example Zone -Laurie, et al. Expires July 2, 2005 [Page 13] -Internet-Draft nsec3 january 2005 - example.com. 1000 IN SOA localhost. - postmaster.localhost.example.com. ( - 1 ; serial - 3600 ; refresh (1 hour) - 1800 ; retry (30 minutes) - 604800 ; expire (1 week) - 3600 ; minimum (1 hour) - ) - 1000 NS ns1.example.com. - 1000 NS ns2.example.com. + + + + + + +Laurie, et al. Expires August 2, 2005 [Page 14] + +Internet-Draft nsec3 february 2005 + + + example.com. 1000 IN SOA localhost. + postmaster.localhost.example.com. ( + 1 ; serial + 3600 ; refresh (1 hour) + 1800 ; retry (30 minutes) + 604800 ; expire (1 week) + 3600 ; minimum (1 hour) + ) + 1000 NS ns1.example.com. + 1000 NS ns2.example.com. f519593e82969842a136e0f47814c881fa163833.example.com. 3600 IN NSEC3 \ SHA-1 200 31323334 4EF8239D95C18403A509D7C336A5D0FA48FD1107 \ NS SOA RRSIG DNSKEY NSEC3 - a.example.com. 1000 IN A 1.2.3.4 - 1000 IN A 1.2.3.5 - 1000 TXT "An example" + a.example.com. 1000 IN A 1.2.3.4 + 1000 IN A 1.2.3.5 + 1000 TXT "An example" bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \ SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \ A TXT RRSIG NSEC3 - b.example.com. 1000 IN A 1.2.3.7 + b.example.com. 1000 IN A 1.2.3.7 83c06d3b7d01fbc9576c71af2bec1a1163435153.example.com. 3600 IN NSEC3 \ SHA-1 200 31323334 A33559360EECB02F36B5C1B72C109126CA4F5A0D \ A RRSIG NSEC3 - a.b.c.example.com. 1000 IN A 1.2.3.6 + a.b.c.example.com. 1000 IN A 1.2.3.6 a33559360eecb02f36b5c1b72c109126ca4f5a0d.example.com. 3600 IN NSEC3 \ SHA-1 200 31323334 BFE6EA21DEE9D228889AE11FA58C4BD551D15801 \ A RRSIG NSEC3 - ns1.example.com. 1000 IN A 1.2.3.8 + ns1.example.com. 1000 IN A 1.2.3.8 4ef8239d95c18403a509d7c336a5d0fa48fd1107.example.com. 3600 IN NSEC3 \ SHA-1 200 31323334 50016B56FD2F0FFC7B563C50FAF0E34259763BBB \ A RRSIG NSEC3 - ns2.example.com. 1000 IN A 1.2.3.9 + ns2.example.com. 1000 IN A 1.2.3.9 50016b56fd2f0ffc7b563c50faf0e34259763bbb.example.com. 3600 IN NSEC3 \ SHA-1 200 31323334 83C06D3B7D01FBC9576C71AF2BEC1A1163435153 \ A RRSIG NSEC3 -11. References -11.1 Normative References +12. References + +12.1 Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. @@ -707,8 +835,11 @@ Internet-Draft nsec3 january 2005 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate -Laurie, et al. Expires July 2, 2005 [Page 14] -Internet-Draft nsec3 january 2005 + +Laurie, et al. Expires August 2, 2005 [Page 15] + +Internet-Draft nsec3 february 2005 + Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -725,7 +856,7 @@ Internet-Draft nsec3 january 2005 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. -11.2 Informative References +12.2 Informative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. @@ -738,6 +869,7 @@ Internet-Draft nsec3 january 2005 Rollover Algorithm and a Out-Of-Band Priming Method for DNS Trust Anchors.", July 2004. + Authors' Addresses Ben Laurie @@ -749,14 +881,21 @@ Authors' Addresses Phone: +44 (20) 8735 0686 EMail: ben@algroup.co.uk + Geoffrey Sisson Nominet -Laurie, et al. Expires July 2, 2005 [Page 15] -Internet-Draft nsec3 january 2005 + + + + +Laurie, et al. Expires August 2, 2005 [Page 16] + +Internet-Draft nsec3 february 2005 + Roy Arends Telematica Instituut @@ -788,8 +927,31 @@ Internet-Draft nsec3 january 2005 -Laurie, et al. Expires July 2, 2005 [Page 16] -Internet-Draft nsec3 january 2005 + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires August 2, 2005 [Page 17] + +Internet-Draft nsec3 february 2005 + Intellectual Property Statement @@ -815,6 +977,7 @@ Intellectual Property Statement 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 @@ -825,16 +988,22 @@ Disclaimer of Validity 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 (2005). 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. -Laurie, et al. Expires July 2, 2005 [Page 17] + + +Laurie, et al. Expires August 2, 2005 [Page 18] + + diff --git a/doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt similarity index 87% rename from doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt rename to doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt index 8cd32e316b..0d0451ace1 100644 --- a/doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt +++ b/doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt @@ -1,11 +1,12 @@ + Network Working Group S. Josefsson -Internet-Draft January 24, 2005 -Expires: July 25, 2005 +Internet-Draft January 2005 +Expires: July 2, 2005 Storing Certificates in the Domain Name System (DNS) - draft-ietf-dnsext-rfc2538bis-00 + draft-ietf-dnsext-rfc2538bis-01 Status of this Memo @@ -32,7 +33,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 25, 2005. + This Internet-Draft will expire on July 2, 2005. Copyright Notice @@ -51,7 +52,7 @@ Abstract -Josefsson Expires July 25, 2005 [Page 1] +Josefsson Expires July 2, 2005 [Page 1] Internet-Draft Storing Certificates in the DNS January 2005 @@ -62,23 +63,24 @@ Table of Contents 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3 2.1 Certificate Type Values . . . . . . . . . . . . . . . . . 4 2.2 Text Representation of CERT RRs . . . . . . . . . . . . . 5 - 2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6 3.1 Content-based X.509 CERT RR Names . . . . . . . . . . . . 7 3.2 Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8 3.3 Content-based OpenPGP CERT RR Names . . . . . . . . . . . 8 3.4 Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9 + 3.5 Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9 4. Performance Considerations . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 9.2 Informative References . . . . . . . . . . . . . . . . . . . 12 A. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . . . 13 + Intellectual Property and Copyright Statements . . . . . . . . 14 @@ -106,8 +108,7 @@ Table of Contents - -Josefsson Expires July 25, 2005 [Page 2] +Josefsson Expires July 2, 2005 [Page 2] Internet-Draft Storing Certificates in the DNS January 2005 @@ -163,7 +164,7 @@ Internet-Draft Storing Certificates in the DNS January 2005 -Josefsson Expires July 25, 2005 [Page 3] +Josefsson Expires July 2, 2005 [Page 3] Internet-Draft Storing Certificates in the DNS January 2005 @@ -190,7 +191,10 @@ Internet-Draft Storing Certificates in the DNS January 2005 1 PKIX X.509 as per PKIX 2 SPKI SPKI certificate 3 PGP OpenPGP packet - 4-252 available for IANA assignment + 4 IPKIX The URL of an X.509 data object + 5 ISPKI The URL of an SPKI certificate + 6 IPGP The URL of an OpenPGP packet + 7-252 available for IANA assignment 253 URI URI private 254 OID OID private 255-65534 available for IANA assignment @@ -213,17 +217,25 @@ Internet-Draft Storing Certificates in the DNS January 2005 transferable public keys as described in section 10.1 of [5], but it MAY handle additional OpenPGP packets. - The URI private type indicates a certificate format defined by an - absolute URI. The certificate portion of the CERT RR MUST begin with - a null terminated URI [4] and the data after the null is the private -Josefsson Expires July 25, 2005 [Page 4] +Josefsson Expires July 2, 2005 [Page 4] Internet-Draft Storing Certificates in the DNS January 2005 + The IPKIX, ISPKI and IPGP types indicate a URL which will serve the + content that would have been in the "certificate, CRL or URL" field + of the corresponding (PKIX, SPKI or PGP) packet types. These types + are known as "indirect". These packet types MUST be used when the + content is too large to fit in the CERT RR, and MAY be used at the + implementations discretion. They SHOULD NOT be used where the entire + UDP packet would have fit in 512 bytes. + + The URI private type indicates a certificate format defined by an + absolute URI. The certificate portion of the CERT RR MUST begin with + a null terminated URI [4] and the data after the null is the private format certificate itself. The URI SHOULD be such that a retrieval from it will lead to documentation on the format of the certificate. Recognition of private certificate types need not be based on URI @@ -261,6 +273,14 @@ Internet-Draft Storing Certificates in the DNS January 2005 Note that the certificate / CRL portion may have internal sub-fields but these do not appear in the master file representation. For example, with type 254, there will be an OID size, an OID, and then + + + +Josefsson Expires July 2, 2005 [Page 5] + +Internet-Draft Storing Certificates in the DNS January 2005 + + the certificate / CRL proper. But only a single logical base 64 string will appear in the text representation. @@ -272,14 +292,6 @@ Internet-Draft Storing Certificates in the DNS January 2005 The following table lists the OIDs, their BER encoding, and their length prefixed hex format for use in CERT RRs: - - - -Josefsson Expires July 25, 2005 [Page 5] - -Internet-Draft Storing Certificates in the DNS January 2005 - - id-at-userCertificate = { joint-iso-ccitt(2) ds(5) at(4) 36 } == 0x 03 55 04 24 @@ -315,8 +327,16 @@ Internet-Draft Storing Certificates in the DNS January 2005 key. Further, the client might only know the hostname of a service that uses X.509 certificates or the Key ID of an OpenPGP key. - This motivate describing two different owner name guidelines. We + This motivates describing two different owner name guidelines. We call the two rules content-based owner names and purpose-based owner + + + +Josefsson Expires July 2, 2005 [Page 6] + +Internet-Draft Storing Certificates in the DNS January 2005 + + names. A content-based owner name is derived from the content of the CERT RR data; for example the Subject field in an X.509 certificate or the User ID field in OpenPGP keys. A purpose-based owner name is @@ -328,14 +348,6 @@ Internet-Draft Storing Certificates in the DNS January 2005 incoming e-mail. Implementations SHOULD use the purpose-based owner name guidelines - - - -Josefsson Expires July 25, 2005 [Page 6] - -Internet-Draft Storing Certificates in the DNS January 2005 - - described in this document, and MAY use CNAMEs at content-based owner names (or other names), pointing to the purpose-based owner name. @@ -368,11 +380,19 @@ Internet-Draft Storing Certificates in the DNS January 2005 3. If neither of the above it used but a URI containing a domain name is present, that domain name should be used. 4. If none of the above is included but a character string name is - included, then it should be treated as described for PGP names - below. + included, then it should be treated as described for OpenPGP + names below. 5. If none of the above apply, then the distinguished name (DN) should be mapped into a domain name as specified in [3]. + + + +Josefsson Expires July 2, 2005 [Page 7] + +Internet-Draft Storing Certificates in the DNS January 2005 + + Example 1: Assume that an X.509v3 certificate is issued to /CN=John Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative names of (a) string "John (the Man) Doe", (b) domain name john- @@ -384,14 +404,6 @@ Internet-Draft Storing Certificates in the DNS January 2005 Example 2: Assume that an X.509v3 certificate is issued to /CN=James Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names - - - -Josefsson Expires July 25, 2005 [Page 7] - -Internet-Draft Storing Certificates in the DNS January 2005 - - of (a) domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and (c) string "James Hacker ". Then the storage locations @@ -424,12 +436,19 @@ Internet-Draft Storing Certificates in the DNS January 2005 IPSEC Certificate Hostname of the IPSEC machine, and/or for the in-addr.arpa reverse lookup IP address. - CRLs Hostname of the issuing CA. - + An alternative approach for IPSEC is to store raw public keys [12]. 3.3 Content-based OpenPGP CERT RR Names OpenPGP signed keys (certificates) use a general character string + + + +Josefsson Expires July 2, 2005 [Page 8] + +Internet-Draft Storing Certificates in the DNS January 2005 + + User ID [5]. However, it is recommended by OpenPGP that such names include the RFC 2822 [7] email address of the party, as in "Leslie Example ". If such a format is used, the CERT @@ -441,13 +460,6 @@ Internet-Draft Storing Certificates in the DNS January 2005 If a user has more than one email address, the CNAME type can be used to reduce the amount of data stored in the DNS. For example: - - -Josefsson Expires July 25, 2005 [Page 8] - -Internet-Draft Storing Certificates in the DNS January 2005 - - $ORIGIN example.org. smith IN CERT PGP 0 0 john.smith IN CNAME smith @@ -456,15 +468,15 @@ Internet-Draft Storing Certificates in the DNS January 2005 3.4 Purpose-based OpenPGP CERT RR Names - Applications that receive an OpenPGP packet but do not know the email - address of the sender will have difficulties constructing the correct - owner name, and cannot use the content-based owner name guidelines. - However, these clients commonly know the key fingerprint or the Key - ID. The key ID is found in OpenPGP packets, and the key fingerprint - is commonly found in auxilliary data that may be available. For - these situations, it is recommended to use an owner name identical to - the key fingerprint and key ID expressed in hexadecimal [11]. For - example: + Applications that receive an OpenPGP packet containing encrypted or + signed data but do not know the email address of the sender will have + difficulties constructing the correct owner name and cannot use the + content-based owner name guidelines. However, these clients commonly + know the key fingerprint or the Key ID. The key ID is found in + OpenPGP packets, and the key fingerprint is commonly found in + auxilliary data that may be available. For these situations, it is + recommended to use an owner name identical to the key fingerprint and + key ID expressed in hexadecimal [11]. For example: $ORIGIN example.org. 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... @@ -477,9 +489,22 @@ Internet-Draft Storing Certificates in the DNS January 2005 purposes, and this may be sub-optimal when two keys with the same Key ID are stored. +3.5 Owner names for IPKIX, ISPKI, and IPGP + + These types are stored under the same owner names, both purpose- and + content-based, as the PKIX, SPKI and PGP types, respectively. + 4. Performance Considerations Current Domain Name System (DNS) implementations are optimized for + + + +Josefsson Expires July 2, 2005 [Page 9] + +Internet-Draft Storing Certificates in the DNS January 2005 + + small transfers, typically not more than 512 bytes including overhead. While larger transfers will perform correctly and work is underway to make larger transfers more efficient, it is still @@ -493,16 +518,7 @@ Internet-Draft Storing Certificates in the DNS January 2005 octets (64kb) or less. This means that each CERT RR cannot contain more than 64kb worth of payload, even if the corresponding certificate or certificate revocation list is larger. This document - do not address this limitation. - - - - - -Josefsson Expires July 25, 2005 [Page 9] - -Internet-Draft Storing Certificates in the DNS January 2005 - + address this by defining "indirect" data types for each normal type. 5. Acknowledgements @@ -513,10 +529,9 @@ Internet-Draft Storing Certificates in the DNS January 2005 contributions to the earlier work that motivated this revised document. - Florian Weimer suggested to clarify wording regarding what data can - be stored in RRDATA portion of OpenPGP CERT RRs, and that the URI - type may include hashes to secure the indirection. Olivier Dubuisson - confirmed that the X.509 OID were indeed correct. + This document was improved by suggestions and comments from Olivier + Dubuisson, Ben Laurie, Samuel Weiler, and Florian Weimer. No doubt + the list is incomplete. We apologize to anyone we left out. 6. Security Considerations @@ -533,33 +548,36 @@ Internet-Draft Storing Certificates in the DNS January 2005 verifying the certificate chain if this conforms with the user's security policy. - When the URI type is used, it should be understood that is introduce + When the URI type is used, it should be understood that it introduces an additional indirection that may allow for a new attack vector. One method to secure that indirection is to include a hash of the certificate in the URI itself. - CERT RRs are not used in connection with securing the DNS security - additions so there are no security considerations related to CERT RRs - and securing the DNS itself. + + + +Josefsson Expires July 2, 2005 [Page 10] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + CERT RRs are not used by DNSSEC [8] so there are no security + considerations related to CERT RRs and securing the DNS itself. + + If DNSSEC [8] is used then the non-existence of a CERT RR, and + consequently certificates or revocation lists, can be securely + asserted. Without DNSSEC, this is not possible. 7. IANA Considerations Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can only be assigned by an IETF standards action [6]. This document - assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE. Certificate + assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate types 0x0100 through 0xFEFF are assigned through IETF Consensus [6] based on RFC documentation of the certificate type. The availability of private types under 0x00FD and 0x00FE should satisfy most requirements for proprietary or private types. - - - -Josefsson Expires July 25, 2005 [Page 10] - -Internet-Draft Storing Certificates in the DNS January 2005 - - 8. Changes since RFC 2538 1. Editorial changes to conform with new document requirements, @@ -582,6 +600,7 @@ Internet-Draft Storing Certificates in the DNS January 2005 for purpose-based X.509 CERT owner names, and section 3.4 for purpose-based OpenPGP CERT owner names. 8. Added size considerations. + 9. Added indirect types IPKIX, ISPKI, and IPGP. 9. References @@ -590,6 +609,14 @@ Internet-Draft Storing Certificates in the DNS January 2005 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. + + + +Josefsson Expires July 2, 2005 [Page 11] + +Internet-Draft Storing Certificates in the DNS January 2005 + + [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. @@ -608,14 +635,6 @@ Internet-Draft Storing Certificates in the DNS January 2005 [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. - - - -Josefsson Expires July 25, 2005 [Page 11] - -Internet-Draft Storing Certificates in the DNS January 2005 - - [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, "DNS Security Introduction and Requirements", draft-ietf-dnsext-dnssec-intro-13 (work in progress), October @@ -633,6 +652,9 @@ Internet-Draft Storing Certificates in the DNS January 2005 [11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. + [12] Richardson, M., "A method for storing IPsec keying material in + DNS", draft-ietf-ipseckey-rr-11 (work in progress), July 2004. + Author's Address @@ -643,6 +665,14 @@ Author's Address Appendix A. Copying conditions Regarding the portion of this document that was written by Simon + + + +Josefsson Expires July 2, 2005 [Page 12] + +Internet-Draft Storing Certificates in the DNS January 2005 + + Josefsson ("the author", for the remainder of this section), the author makes no guarantees and is not responsible for any damage resulting from its use. The author grants irrevocable permission to @@ -667,7 +697,34 @@ Appendix A. Copying conditions -Josefsson Expires July 25, 2005 [Page 12] + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires July 2, 2005 [Page 13] Internet-Draft Storing Certificates in the DNS January 2005 @@ -723,6 +780,6 @@ Acknowledgment -Josefsson Expires July 25, 2005 [Page 13] +Josefsson Expires July 2, 2005 [Page 14] diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt new file mode 100644 index 0000000000..32460b89b4 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt @@ -0,0 +1,729 @@ + + +Network Working Group M. StJohns +Internet-Draft Nominum, Inc. +Expires: April 14, 2005 October 14, 2004 + + + Automated Updates of DNSSEC Trust Anchors + draft-ietf-dnsext-trustupdate-timers-00 + +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 April 14, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document describes a means for automated, authenticated and + authorized updating of DNSSEC "trust anchors". The method provides + protection against single key compromise of a key in the trust point + key set. Based on the trust established by the presence of a current + anchor, other anchors may be added at the same place in the + hierarchy, and, ultimately, supplant the existing anchor. + + This mechanism, if adopted, will require changes to resolver + + + +StJohns Expires April 14, 2005 [Page 1] + +Internet-Draft trustanchor-update October 2004 + + + management behavior (but not resolver resolution behavior), and the + addition of a single flag bit to the DNSKEY record. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 + 1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3 + 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 + 2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5 + 2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6 + 2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 + 2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 + 2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 + 2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6 + 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 + 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8 + 5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 + 5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 + 5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9 + 5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10 + 6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10 + 6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 + Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . 12 + + + + + + + + + + + + + + + + +StJohns Expires April 14, 2005 [Page 2] + +Internet-Draft trustanchor-update October 2004 + + +1. Introduction + + As part of the reality of fielding DNSSEC (Domain Name System + Security Extensions) [RFC2535][DSINTRO][DSPROT][DSREC], the community + has come to the realization that there will not be one signed name + space, but rather islands of signed name space each originating from + specific points (i.e. 'trust points') in the DNS tree. Each of + those islands will be identified by the trust point name, and + validated by at least one associated public key. For the purpose of + this document we'll call the association of that name and a + particular key a 'trust anchor'. A particular trust point can have + more than one key designated as a trust anchor. + + For a DNSSEC-aware resolver to validate information in a DNSSEC + protected branch of the hierarchy, it must have knowledge of a trust + anchor applicable to that branch. It may also have more than one + trust anchor for any given trust point. Under current rules, a chain + of trust for DNSSEC-protected data that chains its way back to ANY + known trust anchor is considered 'secure'. + + Because of the probable balkanization of the DNSSEC tree due to + signing voids at key locations, a resolver may need to know literally + thousands of trust anchors to perform its duties. (e.g. Consider an + unsigned ".COM".) Requiring the owner of the resolver to manually + manage this many relationships is problematic. It's even more + problematic when considering the eventual requirement for key + replacement/update for a given trust anchor. The mechanism described + herein won't help with the initial configuration of the trust anchors + in the resolvers, but should make trust point key + replacement/rollover more viable. + + As mentioned above, this document describes a mechanism whereby a + resolver can update the trust anchors for a given trust point, mainly + without human intervention at the resolver. There are some corner + cases discussed (e.g. multiple key compromise) that may require + manual intervention, but they should be few and far between. This + document DOES NOT discuss the general problem of the initial + configuration of trust anchors for the resolver. + +1.1 Compliance Nomenclature + + 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, [RFC2119]. + +1.2 Changes since -00 + + Resubmitted draft-stjohns-dnssec-trustupdate as a working group + + + +StJohns Expires April 14, 2005 [Page 3] + +Internet-Draft trustanchor-update October 2004 + + + draft. + + Added the concept of timer triggered resolver queries to refresh the + resolvers view of the trust anchor key RRSet. + +2. Theory of Operation + + The general concept of this mechanism is that existing trust anchors + can be used to authenticate new trust anchors at the same point in + the DNS hierarchy. When a new SEP key is added to a trust point + DNSKEY RRSet, and when that RRSet is validated by an existing trust + anchor, then the new key can be added to the set of trust anchors. + + There are some issues with this approach which need to be mitigated. + For example, a compromise of one of the existing keys could allow an + attacker to add their own 'valid' data. This implies a need for a + method to revoke an existing key regardless of whether or not that + key is compromised. As another example assuming a single key + compromise, an attacker could add a new key and revoke all the other + old keys. + +2.1 Revocation + + Assume two trust anchor keys A and B. Assume that B has been + compromised. Without a specific revocation bit, B could invalidate A + simply by sending out a signed trust point key set which didn't + contain A. To fix this, we add a mechanism which requires knowledge + of the private key of a DNSKEY to revoke that DNSKEY. + + A key is considered revoked when the resolver sees the key in a + self-signed RRSet and the key has the REVOKE bit set to '1'. Once + the resolver sees the REVOKE bit, it MUST NOT use this key as a trust + anchor or for any other purposes except validating the RRSIG over the + DNSKEY RRSet specifically for the purpose of validating the + revocation. Unlike the 'Add' operation below, revocation is + immediate and permanent upon receipt of a valid revocation at the + resolver. + + N.B. A DNSKEY with the REVOKE bit set has a different fingerprint + than one without the bit set. This affects the matching of a DNSKEY + to DS records in the parent, or the fingerprint stored at a resolver + used to configure a trust point. [msj3] + + In the given example, the attacker could revoke B because it has + knowledge of B's private key, but could not revoke A. + + + + + + +StJohns Expires April 14, 2005 [Page 4] + +Internet-Draft trustanchor-update October 2004 + + +2.2 Add Hold-Down + + Assume two trust point keys A and B. Assume that B has been + compromised. An attacker could generate and add a new trust anchor + key - C (by adding C to the DNSKEY RRSet and signing it with B), and + then invalidate the compromised key. This would result in the both + the attacker and owner being able to sign data in the zone and have + it accepted as valid by resolvers. + + To mitigate, but not completely solve, this problem, we add a + hold-down time to the addition of the trust anchor. When the + resolver sees a new SEP key in a validated trust point DNSKEY RRSet, + the resolver starts an acceptance timer, and remembers all the keys + that validated the RRSet. If the resolver ever sees the DNSKEY RRSet + without the new key but validly signed, it stops the acceptance + process and resets the acceptance timer. If all of the keys which + were originally used to validate this key are revoked prior to the + timer expiring, the resolver stops the acceptance process and resets + the timer. + + Once the timer expires, the new key will be added as a trust anchor + the next time the validated RRSet with the new key is seen at the + resolver. The resolver MUST NOT treat the new key as a trust anchor + until the hold down time expires AND it has retrieved and validated a + DNSKEY RRSet after the hold down time which contains the new key. + + N.B.: Once the resolver has accepted a key as a trust anchor, the key + MUST be considered a valid trust anchor by that resolver until + explictly revoked as described above. + + In the given example, the zone owner can recover from a compromise by + revoking B and adding a new key D and signing the DNSKEY RRSet with + both A and B. + + The reason this does not completely solve the problem has to do with + the distributed nature of DNS. The resolver only knows what it sees. + A determined attacker who holds one compromised key could keep a + single resolver from realizing that key had been compromised by + intercepting 'real' data from the originating zone and substituting + their own (e.g. using the example, signed only by B). This is no + worse than the current situation assuming a compromised key. + +2.3 Remove Hold-down + + A new key which has been seen by the resolver, but hasn't reached + it's add hold-down time, MAY be removed from the DNSKEY RRSet by the + zone owner. If the resolver sees a validated DNSKEY RRSet without + this key, it waits for the remove hold-down time and then, if the key + + + +StJohns Expires April 14, 2005 [Page 5] + +Internet-Draft trustanchor-update October 2004 + + + hasn't reappeared, SHOULD discard any information about the key. + +2.4 Active Refresh + + A resolver which has been configured for automatic update of keys + from a particular trust point MUST query that trust point (e.g. do a + lookup for the DNSKEY RRSet and related RRSIG records) no less often + than the lesser of 15 days or half the original TTL for the DNSKEY + RRSet or half the RRSIG expiration interval. The expiration interval + is the amount of time from when the RRSIG was last retrieved until + the expiration time in the RRSIG. + + If the query fails, the resolver MUST repeat the query until + satisfied no more often than once an hour and no less often than the + lesser of 1 day or 10% of the original TTL or 10% of the original + expiration interval. + +2.5 Resolver Parameters + +2.5.1 Add Hold-Down Time + + The add hold-down time is 30 days or the expiration time of the TTL + of the first trust point DNSKEY RRSet which contained the key, + whichever is greater. This ensures that at least two validated + DNSKEY RRSets which contain the new key MUST be seen by the resolver + prior to the key's acceptance. + +2.5.2 Remove Hold-Down Time + + The remove hold-down time is 30 days. + +2.5.3 Minimum Trust Anchors per Trust Point + + A compliant resolver MUST be able to manage at least five SEP keys + per trust point. + +3. Changes to DNSKEY RDATA Wire Format + + Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE' + flag. If this bit is set to '1', AND the resolver sees an + RRSIG(DNSKEY) signed by the associated key, then the resolver MUST + consider this key permanently invalid for all purposes except for + validing the revocation. + +4. State Table + + The most important thing to understand is the resolver's view of any + key at a trust point. The following state table describes that view + + + +StJohns Expires April 14, 2005 [Page 6] + +Internet-Draft trustanchor-update October 2004 + + + at various points in the key's lifetime. The table is a normative + part of this specification. The initial state of the key is 'Start'. + The resolver's view of the state of the key changes as various events + occur. + + [msj1] This is the state of a trust point key as seen from the + resolver. The column on the left indicates the current state. The + header at the top shows the next state. The intersection of the two + shows the event that will cause the state to transition from the + current state to the next. + + NEXT STATE + -------------------------------------------------- + FROM |Start |AddPend |Valid |Missing|Revoked|Removed| + ---------------------------------------------------------- + Start | |NewKey | | | | | + ---------------------------------------------------------- + AddPend |KeyRem | |AddTime| | | + ---------------------------------------------------------- + Valid | | | |KeyRem |Revbit | | + ---------------------------------------------------------- + Missing | | |KeyPres| |Revbit | | + ---------------------------------------------------------- + Revoked | | | | | |RemTime| + ---------------------------------------------------------- + Removed | | | | | | | + ---------------------------------------------------------- + + +4.1 Events + NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. + That key will become a new trust anchor for the named trust point + after its been present in the RRSet for at least 'add time'. + KeyPres The key has returned to the valid DNSKEY RRSet. + KeyRem The resolver sees a valid DNSKEY RRSet that does not contain + this key. + AddTime The key has been in every valid DNSKEY RRSet seen for at + least the 'add time'. + RemTime A revoked key has been missing from the trust point DNSKEY + RRSet for sufficient time to be removed from the trust set. + RevBit The key has appeared in the trust anchor DNSKEY RRSet with its + "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet + signed by this key. + +4.2 States + + + + + + +StJohns Expires April 14, 2005 [Page 7] + +Internet-Draft trustanchor-update October 2004 + + + Start The key doesn't yet exist as a trust anchor at the resolver. + It may or may not exist at the zone server, but hasn't yet been + seen at the resolver. + AddPend The key has been seen at the resolver, has its 'SEP' bit set, + and has been included in a validated DNSKEY RRSet. There is a + hold-down time for the key before it can be used as a trust + anchor. + Valid The key has been seen at the resolver and has been included in + all validated DNSKEY RRSets from the time it was first seen up + through the hold-down time. It is now valid for verifying RRSets + that arrive after the hold down time. Clarification: The DNSKEY + RRSet does not need to be continuously present at the resolver + (e.g. its TTL might expire). If the RRSet is seen, and is + validated (i.e. verifies against an existing trust anchor), this + key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. + Missing This is an abnormal state. The key remains as a valid trust + point key, but was not seen at the resolver in the last validated + DNSKEY RRSet. This is an abnormal state because the zone operator + should be using the REVOKE bit prior to removal. [Discussion + item: Should a missing key be considered revoked after some + period of time?] + Revoked This is the state a key moves to once the resolver sees an + RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains + this key with its REVOKE bit set to '1'. Once in this state, this + key MUST permanently be considered invalid as a trust anchor. + Removed After a fairly long hold-down time, information about this + key may be purged from the resolver. A key in the removed state + MUST NOT be considered a valid trust anchor. + +5. Scenarios + + The suggested model for operation is to have one active key and one + stand-by key at each trust point. The active key will be used to + sign the DNSKEY RRSet. The stand-by key will not normally sign this + RRSet, but the resolver will accept it as a trust anchor if/when it + sees the signature on the trust point DNSKEY RRSet. + + Since the stand-by key is not in active signing use, the associated + private key may (and SHOULD) be provided with additional protections + not normally available to a key that must be used frequently. E.g. + locked in a safe, split among many parties, etc. Notionally, the + stand-by key should be less subject to compromise than an active key, + but that will be dependent on operational concerns not addressed + here. + +5.1 Adding A Trust Anchor + + Assume an existing trust anchor key 'A'. + + + +StJohns Expires April 14, 2005 [Page 8] + +Internet-Draft trustanchor-update October 2004 + + + 1. Generate a new key pair. + 2. Create a DNSKEY record from the key pair and set the SEP and Zone + Key bits. + 3. Add the DNSKEY to the RRSet. + 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - + 'A'. + 5. Wait a while. + +5.2 Deleting a Trust Anchor + + Assume existing trust anchors 'A' and 'B' and that you want to revoke + and delete 'A'. + 1. Set the revolcation bit on key 'A'. + 2. Sign the DNSKEY RRSet with both 'A' and 'B'. + 'A' is now revoked. The operator SHOULD include the revoked 'A' in + the RRSet for at least the remove hold-down time, but then may remove + it from the DNSKEY RRSet. + +5.3 Key Roll-Over + + Assume existing keys A and B. 'A' is actively in use (i.e. has been + signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has + been in the DNSKEY RRSet and is a valid trust anchor, but wasn't + being used to sign the RRSet.) + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'A'. + 4. Sign the RRSet with 'A' and 'B'. + 'A' is now revoked, 'B' is now the active key, and 'C' will be the + stand-by key once the hold-down expires. The operator SHOULD include + the revoked 'A' in the RRSet for at least the remove hold-down time, + but may then remove it from the DNSKEY RRSet. + +5.4 Active Key Compromised + + This is the same as the mechanism for Key Roll-Over (Section 5.3) + above assuming 'A' is the active key. + +5.5 Stand-by Key Compromised + + Using the same assumptions and naming conventions as Key Roll-Over + (Section 5.3) above: + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'B'. + 4. Sign the RRSet with 'A' and 'B'. + 'B' is now revoked, 'A' remains the active key, and 'C' will be the + stand-by key once the hold-down expires. 'B' SHOULD continue to be + + + +StJohns Expires April 14, 2005 [Page 9] + +Internet-Draft trustanchor-update October 2004 + + + included in the RRSet for the remove hold-down time. + +6. Security Considerations + +6.1 Key Ownership vs Acceptance Policy + + The reader should note that, while the zone owner is responsible + creating and distributing keys, it's wholly the decision of the + resolver owner as to whether to accept such keys for the + authentication of the zone information. This implies the decision + update trust anchor keys based on trust for a current trust anchor + key is also the resolver owner's decision. + + The resolver owner (and resolver implementers) MAY choose to permit + or prevent key status updates based on this mechanism for specific + trust points. If they choose to prevent the automated updates, they + will need to establish a mechanism for manual or other out-of-band + updates outside the scope of this document. + +6.2 Multiple Key Compromise + + This scheme permits recovery as long as at least one valid trust + anchor key remains uncompromised. E.g. if there are three keys, you + can recover if two of them are compromised. The zone owner should + determine their own level of comfort with respect to the number of + active valid trust anchors in a zone and should be prepared to + implement recovery procedures once they detect a compromise. A + manual or other out-of-band update of all resolvers will be required + if all trust anchor keys at a trust point are compromised. + +6.3 Dynamic Updates + + Allowing a resolver to update its trust anchor set based in-band key + information is potentially less secure than a manual process. + However, given the nature of the DNS, the number of resolvers that + would require update if a trust anchor key were compromised, and the + lack of a standard management framework for DNS, this approach is no + worse than the existing situation. + +7 Normative References + + [DSINTRO] Arends, R., "DNS Security Introduction and Requirements", + ID draft-ietf-dnsext-dnssec-intro-09.txt, October 2004, + . + + [DSPROT] Arends, R., "Protocol Modifications for the DNS Security + Extensions", ID draft-ietf-dnsext-dnssec-protocol-05.txt, + + + +StJohns Expires April 14, 2005 [Page 10] + +Internet-Draft trustanchor-update October 2004 + + + October 2004, + . + + [DSREC] Arends, R., "Resource Records for the DNS Security + Extensions", ID draft-ietf-dnsext-dnssec-records-07.txt, + October 2004, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + +Editorial Comments + + [msj1] msj: N.B. This table is preliminary and will be revised to + match implementation experience. For example, should there + be a state for "Add hold-down expired, but haven't seen the + new RRSet"? + + [msj2] msj: To be assigned. + + [msj3] msj: For discussion: What's the implementation guidance for + resolvers currently with respect to the non-assigned flag + bits? If they consider the flag bit when doing key matching + at the trust anchor, they won't be able to match. + + +Author's Address + + Michael StJohns + Nominum, Inc. + 2385 Bay Road + Redwood City, CA 94063 + USA + + Phone: +1-301-528-4729 + EMail: Mike.StJohns@nominum.com + URI: www.nominum.com + + + + + + + + + +StJohns Expires April 14, 2005 [Page 11] + +Internet-Draft trustanchor-update October 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. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + +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. + + + + + +StJohns Expires April 14, 2005 [Page 12] + +Internet-Draft trustanchor-update October 2004 + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +StJohns Expires April 14, 2005 [Page 13] + + diff --git a/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt b/doc/draft/draft-ietf-dnsext-tsig-sha-01.txt similarity index 83% rename from doc/draft/draft-ietf-dnsext-tsig-sha-00.txt rename to doc/draft/draft-ietf-dnsext-tsig-sha-01.txt index 1133b0c87d..dbc94fe322 100644 --- a/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt +++ b/doc/draft/draft-ietf-dnsext-tsig-sha-01.txt @@ -1,13 +1,12 @@ - INTERNET-DRAFT Donald E. Eastlake 3rd UPDATES RFC 2845 Motorola Laboratories -Expires: February 2005 August 2004 +Expires: August 2005 February 2005 HMAC SHA TSIG Algorithm Identifiers ---- --- ---- --------- ----------- - + Status of This Document @@ -43,14 +42,14 @@ 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. + This document standardizes identifiers and implementation + requirements 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. + Copyright (C) The Internet Society 2005. All Rights Reserved. @@ -82,7 +81,7 @@ Table of Contents 7. Normative References....................................7 8. Informative References..................................7 - Authors Address............................................8 + Author's Address...........................................8 Expiration and File Name...................................8 @@ -131,7 +130,8 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers 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. + authentication algorithms based on US NIST SHA algorithms and HMAC + and specifies the implementation requirements for those algorithms. In section 3, this document specifies the meaning of inequality between the normal output size of the specified hash function and the @@ -168,7 +168,6 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers - D. Eastlake 3rd [Page 3] @@ -190,21 +189,23 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers 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. + the SHA family [FIPS 180-2, RFC 3874] with 224, 256, 384, and 512 + bits, may be preferred in some case particularly since increasingly + successful cryptanalytic attacks are being made on the shorter + hashes. Use of TSIG between a DNS resolver and server is by mutual + agreement. That agreement can include the support of additional + algorithms and may specify policies as to which algorithms are + acceptable. - 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. + The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the + table below for convenience. Implementations which support TSIG MUST + also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig + and the other algorithms listed below. Mandatory HMAC-MD5.SIG-ALG.REG.INT - Recommended hmac-sha1 + Mandatory hmac-sha1 Optional hmac-sha224 - Optional hmac-sha256 + Mandatory hmac-sha256 Optional hamc-sha384 Optional hmac-sha512 @@ -225,8 +226,6 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - D. Eastlake 3rd [Page 4] @@ -309,16 +308,21 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers 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 + that an HMAC never be truncated to less than half its length nor to less than 80 bits (10 octets). + Significant progress has been made recently in cryptanalysis of hash + function of the type used herein. While the results so far should not + effect HMAC, the stronger SHA-1 and SHA-256 algorithms are being made + mandatory due to caution. + See also the Security Considerations section of [RFC 2845]. 6. Copyright and Disclaimer - Copyright (C) The Internet Society 2004. This document is subject to + Copyright (C) The Internet Society 2005. 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. @@ -340,11 +344,6 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - - - - D. Eastlake 3rd [Page 6] @@ -353,8 +352,9 @@ 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. + [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US + Federal Information Processing Standard, with Change Notice 1, + February 2004. [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992. @@ -369,17 +369,10 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers 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. @@ -391,6 +384,12 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October 2003. + [RFC 3874] - "A 224-bit One-way Hash Function: SHA-224", R. Housley, + September 2004, + + + + @@ -409,7 +408,7 @@ D. Eastlake 3rd [Page 7] INTERNET-DRAFT HMAC-SHA TSIG Identifiers -Authors Address +Author's Address Donald E. Eastlake 3rd Motorola Laboratories @@ -424,9 +423,9 @@ Authors Address Expiration and File Name - This draft expires in February 2005. + This draft expires in August 2005. - Its file name is draft-ietf-dnsext-tsig-sha-00.txt + Its file name is draft-ietf-dnsext-tsig-sha-01.txt diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-03.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-03.txt deleted file mode 100644 index 8033c0c1c0..0000000000 --- a/doc/draft/draft-ietf-dnsext-wcard-clarify-03.txt +++ /dev/null @@ -1,818 +0,0 @@ - -DNSEXT Working Group E. Lewis -INTERNET DRAFT NeuStar -Expiration Date: April 2005 October 2004 - - Clarifying the Role of Wild Card Domains - in the Domain Name System - - draft-ietf-dnsext-wcard-clarify-03.txt - -Status of this Memo - - 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 becomes - aware will be disclosed, in accordance with Section 6 of 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 April 11, 2005. - - -Copyright Notice - - Copyright (C) The Internet Society (2004). - - -Abstract - - The definition of wild cards is recast from the original in RFC 1034, - in words that are more specific and in line with RFC 2119. This - document is meant to supplement the definition in RFC 1034 and not to - significantly alter the spirit or intent of that definition. - -1 Introduction - - In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the synthesis - of answers from special records called wildcards. The original - definitions are incomplete. This document clarifies and describes - the wildcard synthesis by adding to the discussion and making - limited modifications. Modifications are made only where necessary - to close inconsistencies that have led to interoperability issues. - -1.1 Motivation - - Over time many implementations have diverged in different ways from - the original definition, or at least what had been intended. Although - there is clearly a need to clarify the original documents in light - of this, the impetus for this document lay in the engineering of - the DNS security extensions [RFC TBD]. With an unclear definition - of wildcards the design of authenticated denial became entangled. - - Although this document is motivated by DNSSEC and the need to - have a separate document passed for the sake of DNSSEC, other - motivations have risen. The renewed understanding of wildcards gained - is worthy of being documented. - -1.2 The Original Definition - - This document is intended to not make changes. To reinforce - this, sections of RFC 1034 are repeated verbatim for convenience - of the reader, to help in comparison of old and new text. - - There are a few passages which are changed. This may seem to - contradict the goal of not changing the original specification, - but the changes herein are required because of inconsistencies - with the wording in RFC 1034. - - The beginning of the discussion ought to start with the definition - of the term "wildcard" as it appears in RFC 1034, section 4.3.3. - -# In the previous algorithm, special treatment was given to RRs with owner -# names starting with the label "*". Such RRs are called wildcards. -# Wildcard RRs can be thought of as instructions for synthesizing RRs. -# When the appropriate conditions are met, the name server creates RRs -# with an owner name equal to the query name and contents taken from the -# wildcard RRs. - - - This passage appears after the algorithm in which they are used is - presented. The terminology is not consistent, the word "wildcard" - is clearly defined to be a resource record. In the next sentence - the term is shifted to be an adjective, the first step on the - path to overloading the term. Wildcard has also been used to - refer to domain names that begin with a "*". - -1.3 The Clarification - - The clarification effort can be divided into three sections. One - is the use of new terminology to better describe wildcards. Changes - to words in RFC 1034 that have resulted by discovering conflicting - concepts are presented. Descriptions of special type records in the - context of being wildcards is discussed. - -1.3.1 New Terms - - The term "wildcard" has become so overloaded it is virtually useless - as a description. A few new terms will be introduced to be more - descriptive. The new terms that will be introduced are: - - Asterisk Label - a label consisting of an asterisk ("*") and no - other characters. - - Wild Card Domain Name - a domain name whose least significant - label (first when reading left to right) is an asterisk label. - Other labels might also be asterisk labels. - - Source of Synthesis - a Wild Card Domain Name when it is consulted in - the final paragraph of step 3, part c of RFC 1034's 4.3.2 algorithm. - - Closest Encloser - in RFC 1034's 4.3.2 algorithm, the name at which - the last match was possible in step 3, part c. This is the longest - sequence of exactly matching labels from the root downward in both the - sought name (QNAME) and in the zone being examined. - - - Label Match - two labels are equivalent if the label type and label - length are the same bit sequence and if the name is the label is - equivalent bit wise after down casing all of the ASCII characters. - [Ed note: do we still call them ASCII?] - - These terms will be more fully described as needed later. These - terms will be used to describe a few changes to the words in RFC - 1034. A summary of the changes appear next and will be fully - covered in later sections. - -1.3.2 Changed Text - - The definition of "existence" is changed, superficially, to exclude - empty domains that have no subdomains with resource records. This - change will not be apparent to implementations, it is needed to - make descriptions more concise. - - In RFC 1034, there is text that seems to bar having two Asterisk - Labels in a Wild Card Domain Name. There is no further discussion, - no prescribed error handling, nor enforcement described. In this - document, the use of such names will be discouraged, but implementations - will have to account for the possibility of such a name's use. - - The actions when a Source of Synthesis owns a CNAME RR are changed to - mirror the actions if an exact match name owns a CNAME RR. This - is an addition to the words in RFC 1034, section 4.3.2, step 3, - part c. - -1.3.3 Considerations with Special Types - - This clarification will describe in some detail the semantics of - wildcard CNAME RRs, wildcard NS RRs, wildcard SOA RR's, - wildcard DNAME RRs [RFC wxyz], and empty, non-terminal wildcards. - Understanding these types in the context of wildcards has been - clouded because these types incur special processing if they - are the result of an exact match. - - By the definition in RFC 1034, there can be no empty, non-terminal - "wildcards", but in the algorithm, it is possible that an empty - non-terminal is sought as the potential owner of a "wildcard." This - is one example of why the ordering of the discussion in RFC 1034 is - confusing. - - -1.4 Standards Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in the document entitled - "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119] - - Quotations of RFC 1034 (as has already been done once above) are - denoted by a '#' in the leftmost column. - - -2 "Wildcard" - - The context of the wildcard concept involves the algorithm by which - a name server prepares a response (in RFC 1034's section 4.3.2) and - the way in which a resource record (set) is identified as being a - source of synthetic data (section 4.3.3). - - Tackling the latter first, there are two objectives in defining a - means to identify a resource record set as a source of synthesis. - First is the desire to maintain all DNS data in a consistent manner. - Avoiding the need for implementations to have many internal data - structures is a good thing. Not that this means limiting quantity, - but rather types of data. The second objective impacts interoperability, - that is a master server of one implementation has to be able to - send the synthesis instructions to the slaves. Although there are - alternatives to the use of zone transfers via port 53, a truly - interoperable record synthesis approach has to be able to insert the - synthesis instructions into a zone transfer. - - The objectives in describing the synthesis of records in the context - of the name server algorithm include knowing when to employ the - process of synthesis and how the synthesis is carried out. - -2.1 Identifying a wildcard - - To provide a more accurate description of "wildcards", the definition - has to start with a discussion of the domain names that appear as - owners. - -2.1.1 Wild Card Domain Name and Asterisk Label - - A "Wild Card Domain Name" is defined by having its initial label be: - - 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) - - - The first octet is the normal label type and length for a 1 octet - long label, the second octet is the ASCII representation [RFC 20] for - the '*' character. In RFC 1034, ASCII encoding is assumed to be the - character encoding. - - A descriptive name of a label equaling that value is an "Asterisk - Label." - - RFC 1034's definition of wildcard would be "a resource record owned - by a Wild Card Domain Name." This is mentioned to help maintain some - orientation between this clarification and RFC 1034. Keep in mind, - that in "Clarifications to the DNS Specification" [RFC 2181] the name - of the basic unit of DNS data became the resource record set (RRSet) and - not the resource record. - -2.1.2 Variations on Wild Card Domain Names - - RFC 1034 and RFC 1035 do not explicitly mention the case in which a - domain name might be something like "the*.example.com." The - interpretation is that this domain name in a zone would only match - queries for "the*.example.com" and not have any other role. An - asterisk ('*') occurring other than as the sole character in - a label is simply a character forming part of the label and has no - special meaning. This is not an Asterisk Label, simply a label - an asterisk in it. The same is true for "**.example.com." and - "*the.example.com." - - [Ed note: the above paragraph reads too strong. The intent ought to - be that such names do not fall under the rules of wildcards. The - intent is not to bar any future attempts to define other forms of - synthesis - nor is the intent to encourage them.] - - The interpretation of a wild card domain specification which is not a - leaf domain is not clearly defined in RFC 1034. E.g., sub.*.example., - is not discussed, not barred. In wanting to minimize changes from - the original specification, such names are permitted. Although - "sub.*.example." is not a Wild Card Domain Name, "*.example." is. - - RRSets used to synthesize records can be owned by a Wild Card Domain - Name that has subdomains. - -2.1.3 Non-terminal Wild Card Domain Names - - In section 4.3.3, the following is stated: - -# .......................... The owner name of the wildcard RRs is of -# the form "*.", where is any domain name. -# should not contain other * labels...................... - - This covers names like "*.foo.*.example." The pre-RFC2119 wording uses - "should not" which has an ambiguous meaning. The specification does not - proscribe actions upon seeing such a name, such as whether or not a - zone containing the name should fail to be served. What if a dynamic - update (RFC2136) requested to add the name to the zone? The failure - semantics are not defined. - - The recommendation is that implementations ought to anticipate the - appearance of such names but generally discourage their use in - operations. No standards statement, such as "MAY NOT" or "SHOULD NOT" - is made here. - - The interpretation of this is, when seeking a Wild Card Domain Name - for the purposes of record synthesis, an implementation ought not to - check the domain name for subdomains. - - It is possible that a Wild Card Domain Name is an empty non-terminal. - (See the upcoming sections on empty non-terminals.) In this case, - the lookup will terminate as would any empty non-terminal match. - -2.2 Existence Rules - - The notion that a domain name 'exists' arises numerous times in - discussions about the wildcard concept. RFC 1034 raises the issue - of existence in a number of places, usually in reference to - non-existence and in reference to processing involving wildcards. - RFC 1034 contains algorithms that describe how domain names impact - the preparation of an answer and does define wildcards as a means of - synthesizing answers. Because of this a discussion on wildcards - needs to cover a definition of existence. - - - To help clarify the topic of wild cards, a positive definition of - existence is needed. Complicating matters, though, is the - realization that existence is relative. To an authoritative server, - a domain name exists if the domain name plays a role following the - algorithms of preparing a response. To a resolver, a domain name - exists if there is any data available corresponding to the name. The - difference between the two is the synthesis of records according to a - wildcard. - - For the purposes of this document, the point of view of an - authoritative server is more interesting. A domain name is said to - exist if it plays a role in the execution of the algorithms in RFC 1034. - -2.2.1. An Example - - To illustrate what is meant by existence consider this complete zone: - - - $ORIGIN example. - example. 3600 IN SOA - example. 3600 NS ns.example.com. - example. 3600 NS ns.example.net. - *.example. 3600 TXT "this is a wild card" - *.example. 3600 MX 10 host1.example. - host1.example. 3600 A 192.0.4.1 - _ssh._tcp.host1.example. 3600 SRV - _ssh._tcp.host2.example. 3600 SRV - subdel.example. 3600 NS ns.example.com. - subdel.example. 3600 NS ns.example.net. - - - A look at the domain names in a tree structure is helpful: - - | - -------------example------------ - / / \ \ - / / \ \ - / / \ \ - * host1 host2 subdel - | | - | | - _tcp _tcp - | | - | | - _ssh _ssh - - The following queries would be synthesized from the wild card: - - QNAME=host3.example. QTYPE=MX, QCLASS=IN - the answer will be a "host3.example. IN MX ..." - - - QNAME=host3.example. QTYPE=A, QCLASS=IN - the answer will reflect "no error, but no data" - because there is no A RR set at '*.example.' - - - QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN - the answer will be "foo.bar.example. IN TXT ..." - because bar.example. does not exist, but the wildcard does. - - The following queries would not be synthesized from the wild card: - - QNAME=host1.example., QTYPE=MX, QCLASS=IN - because host1.example. exists - - QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN - because *.example. exists - - QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN - because _tcp.host1.example. exists (without data) - - - QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN - because host2.example. exists (without data) - - - QNAME=host.subdel.example., QTYPE=A, QCLASS=IN - because subdel.example. exists (and is a zone cut) - - To the server, all of the domains in the tree exist. The resolver will - get answers to some names off the tree, thanks to synthesis. - -2.2.2 Empty Non-terminals - - Empty non-terminals are domain names that own no resource records but - have subdomains which do. This is defined in section 3.1 of RFC 1034: - -# The domain name space is a tree structure. Each node and leaf on the -# tree corresponds to a resource set (which may be empty). The domain -# system makes no distinctions between the uses of the interior nodes and -# leaves, and this memo uses the term "node" to refer to both. - - The parenthesized "which may be empty" specifies that empty non- - terminals are explicitly recognized. According to the definition of - existence in this document, empty non-terminals do exist at the - server. - - Pedantically reading the above paragraph can lead to an - interpretation that all possible domains exist - up to the suggested - limit of 255 octets for a domain name [RFC 1035]. For example, - www.example. may have an A RR, and as far as is practically - concerned, is a leaf of the domain tree. But the definition can be - taken to mean that sub.www.example. also exists, albeit with no data. - By extension, all possible domains exist, from the root on down. As - RFC 1034 also defines "an authoritative name error indicating that - the name does not exist" in section 4.3.1, this is not the intent of - the original document. - -2.2.3 Yet Another Definition of Existence - - RFC1034's wording is clarified by the following paragraph: - - A node is considered to have an impact on the algorithms of - 4.3.2 if it is a leaf node with any resource sets or an interior - node (with or without a resource set) that has a subdomain that - is a leaf node with a resource set. A QNAME and QCLASS matching - an existing node never results in a response code of - authoritative name error (RCODE==3). - - The terminology in the above paragraph is chosen to remain as close - to that in the original document. The term "with" is a alternate - form for "owning" in this case, hence "a leaf node owning resources - sets, or an interior node, owning or not owning any resource set, - that has a leaf node owning a resource set as a subdomain," is the - proper interpretation of the middle sentence. - - As an aside, an "authoritative name error", response code (RCODE) 3, - has been called NXDOMAIN in some RFCs, such as RFC 2136 [RFC 2136]. - NXDOMAIN is the mnemonic assigned to such an error by at least one - implementation of DNS. - - Summarizing the discussion on existence in non-RFC1034 words: - - An authoritative server is to treat a domain name as existing - during the execution of the algorithms in RFC 1034 when the - domain name conforms to the following definition. A domain name - is defined to exist if the domain name owns data or has a - subdomain that exists, or both. - - Note that at a zone boundary, the domain name owns data, including - the NS RR set. At the delegating server, the NS RR set is not - authoritative, but that is of no consequence here. The domain name - owns data, therefore, it exists. - - -2.3 When does a Wild Card Domain Name not own a wildcard (record) - - When a Wild Card Domain Name appears in a message's query section, - no special processing occurs. Asterisk Labels in such a context - only Label Matches other Asterisk Labels in the existing zone tree - when the 4.3.2 algorithm is being followed. - - When a Wild Card Domain Name appears in the resource data of a - record, no special processing occurs. An Asterisk Label in that - context literally means just an asterisk. - - -3. Impact of a Wild Card Domain On a Response - - The description of how wild cards impact response generation is in - RFC 1034, section 4.3.2. That passage contains the algorithm - followed by a server in constructing a response. Within that - algorithm, step 3, part 'c' defines the behavior of the wild card. - The algorithm is directly quoted in lines that begin with a '#' sign. - Commentary is interleaved. - - There is a documentation issue deserving some explanation. The - algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo - code, i.e., it's steps are not intended to be followed in strict - order. The "algorithm" is a suggestion. As such, in step 3, parts - a, b, and c, do not have to be implemented in that order. - - Another issue needing explanation is that RFC 1034 is a full - standard. There is another RFC, RFC 2672, which makes, or proposes - an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME - RR. RFC 2672 is a proposed standard. The dilemma in writing these - clarifications is knowing which document is the one being clarified. - Fortunately, the difference between RFC 1034 and RFC 2672 is not - significant with respect to wild card synthesis, so this document - will continue to state that it is clarifying RFC 1034. If RFC 2672 - progresses along the standards track, it will need to refer to - modifying RFC 1034's algorithm as amended here. - - -3.1 Step 2 - - Step 2 of the RFC 1034's section 4.3.2 reads: - -# 2. Search the available zones for the zone which is the nearest -# ancestor to QNAME. If such a zone is found, go to step 3, -# otherwise step 4. - - In this step, the most appropriate zone for the response is chosen. - There are two reasons to repeat this. One is that this means all - of step 3 is done within the context of a zone, which will constrain - the discussion. The other is the though behind synthesizing entire - zones and the use of Wild Card Domain Names to do so. - -3.2 Step 3 - - Step 3 is dominated by three parts, labelled a, b, and c. But the - beginning of the Step is important and needs explanation. - -# 3. Start matching down, label by label, in the zone. The -# matching process can terminate several ways: - - The word matching in this care refers to Label Matching. The concept - is based in the view of the zone as the tree of existing names. The - Query Name is considered to be an ordered sequence of labels - as - if the name were a path from the root to the owner of the desired - data. - - The process of Label Matching ends in one of three choices, the parts - a, b, and c. Once one of the parts is chosen, the other parts are - not considered. (E.g., do not execute part c and then change the - execution path to finish in part b.) The process of Label Matching - is also done independent of the Query Type. - - Parts a and b are not an issue for this clarification as they do not - relate to record synthesis. Part a generally covers a situation in - which all of the labels in the search (query) name have been matched - down the tree, e.g., the sought name exists as an exact Label Match. - Part b generally covers a situation in which any label in the sought - name Label Matches a tree label and the tree label has a NS RRSet. - -3.3 Part 'c' - - The context of part 'c' is that the process of Label Matching the - labels in the sought name has resulted in a situation in which there - is nothing corresponding in the tree. It is as if the lookup has - "fallen off the tree." - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if a -# the "*" label exists. - - - To help describe the process of looking "to see is a the [sic] - label exists" a term has been coined to describe the last label - matched. The term is "Closest Encloser." - -3.3.1 Closest Encloser and the Source of Synthesis - - The "Closest Encloser" is the node in the zone's tree of existing - domain names that is has the most matching labels with the sought - name. Each match is a "Label Match" and the order of the labels - is also the same. The Closest Encloser is an existing name in the - zone, it may be an empty non-terminal, it may even be a Wild Card - Domain Name itself. In no circumstances is the Closest Encloser - the used to synthesize records though. - - A "Source of Synthesis" is defined in the context of a lookup - process as the Wild Card Domain Name immediately descending from - the Closest Encloser provided the Wild Card Domain Name exists. - A Source of Synthesis does not guarantee having a RRSet to use - for synthesis, a Source of Synthesis may even be an empty - non-terminal. - - If a Source of Synthesis exists, it will be the Wild Card Domain Name - that is identified by an Asterisk Label below the Closest Encloser. - E.g., ". or "*.." - If the Source of Synthesis does not exist (not on the domain tree), - there will be no wildcard synthesis - - The important concept is that for any given lookup process, there - is at most one place at which wildcard synthetic records can be - obtained. If the Source of Synthesis does not exist, the lookup - terminates, the lookup does not look for other wildcard records. - - Other terms have been coined on the mailing list in the past. E.g., - it has been said that existing names block the application of - wildcard records. This is still an appropriate viewpoint, but - replacing this notion with the Closest Encloser and Source of - Synthesis the depiction of the wildcard process is clearer. - -3.3.2 Closest Encloser and Source of Synthesis Examples - - - To illustrate, using the example zone in section 2.2.1 of this document, - the following chart shows QNAMEs and the closest enclosers. - - QNAME Closest Encloser Source of Synthesis - host3.example. example. *.example. - _telnet._tcp.host1.example. _tcp.host1.example. no source - _telnet._tcp.host2.example. host2.example. no source - _telnet._tcp.host3.example. example. *.example. - _chat._udp.host3.example. example. *.example. - - - - The fact that a closest encloser will be the only superdomain that - can have a candidate wild card will have an impact when it comes to - designing pre-calculated authenticated denial of existence proofs. - - -3.3.3 Non-existent Source of Synthesis - - In RFC 1034: - -# If the "*" label does not exist, check whether the name -# we are looking for is the original QNAME in the query -# or a name we have followed due to a CNAME. If the name -# is original, set an authoritative name error in the -# response and exit. Otherwise just exit. - - - The above passage is clear, evidenced by the lack of discussion and - mis-implementation of it over the years. It is included for - completeness only. (No attempt is made to re-interpret it lest - a mistake in editing leads to confusion.) - -3.3.4 Type Matching - - RFC 1034 concludes part c with this: - -# If the "*" label does exist, match RRs at that node -# against QTYPE. If any match, copy them into the answer -# section, but set the owner of the RR to be QNAME, and -# not the node with the "*" label. Go to step 6. - - - This final paragraph covers the role of the QTYPE in the lookup process. - - Based on implementation feedback and similarities between step a and - step c a change to this passage a change has been made. - - The change is to add the following text: - - If the data at the source of synthesis is a CNAME, and - QTYPE doesn't match CNAME, copy the CNAME RR into the - answer section of the response changing the owner name - to the QNAME, change QNAME to the canonical name in the - CNAME RR, and go back to step 1. - - This is essentially the same text in step a covering the processing of - CNAME RRSets. - -4. Considerations with Special Types - - - Five types of RRSets owned by a Wild Card Domain Name have caused - confusion. Four explicit types causing confusion are SOA, NS, CNAME, - DNAME, and the fifth type - "none." - -4.1. SOA RR's at a Wild Card Domain Name - - - A Wild Card Domain Name owning an SOA RRSet means that the domain - is at the root of the zone (apex). The domain can not be a Source of - Synthesis because that is, but definition, a descendent node (of - the Closest Encloser) and a zone apex is at the top of the zone. - - Although a Wild Card Domain Name can not be a Source of Synthesis, - there is no reason to forbid the ownership of an SOA RRSet. This - means that zones with names like "*..", and even - "*..." - - Step 2 (section 3.1) does not provide a means to specify a means to - synthesize a zone. Therefore, according to the rules there, the - only way in which a zone that has a name which is a Wild Card - Domain Name is if the QNAME is in a domain below the zone's name. - - E.g., if *.example. has an SOA record, then only a query like - QNAME=*.example., QTYPE=A, QCLASS=IN would see it. As another - example, a QNAME of www.*.example. would also result in passing - through the zone. - -4.2. NS RR's at a Wild Card Domain Name - - - The semantics of a Wild Card Domain Name ownership of a NS RRSet - has been unclear. Looking through RFC 1034, the recommendation - is to have the NS RRSet act the same a any non-special type, e.g., - like an A RR. - - If the NS RRSet in question is at the top of the zone, i.e., the - name also owns an SOA RRSet, the QNAME equals the zone name. This - would trigger part 'a' of Step 3. - - In any other case, the Wild Card Domain Name owned NS RRSet would - be the only RRSet (prior to changes instituted by DNSSEC) at the - node by DNS rules. If the QNAME equals the Wild Card Domain Name - or is a subdomain of it, then the node would be considered in part - 'b' of Step 3. - - Note that there is no synthesis of records in the authority section - because part 'b' does not account for synthesis. The referral - returned would have the Wild Card Domain Name in the authority section, - unchanged. - - If the QNAME is not the same as the Wild Card Domain Name nor a - subdomain of it, then part 'c' of Step 3 has been triggered. Once - part 'c' is entered, there is no reverting to part 'b' - i.e., - once an NS RRSet is synthesized it does not mean that the server has - to consider the name delegated away. I.e., the server is not - synthesizing a record (the NS RRSet) that means the server does not - have the right to synthesize. - -4.3. CNAME RR's at a Wild Card Domain Name - - The issue of CNAME RR's owned by wild card domain names has prompted - a suggested change to the last paragraph of step 3c of the algorithm - in 4.3.2. The changed text appears in section 3.3.4 of this document. - -4.4. DNAME RR's at a Wild Card Domain Name - - The specification of the DNAME RR, which is at the proposed level of - standardization, is not as mature as the full standard in RFC 1034. - Because of this, or the reason for this is, there appears to be a - a number of issues with that definition and it's rewrite of the algorithm - in 4.3.2. For the time being, when it comes to wild card processing - issues, a DNAME can be considered to be a CNAME synthesizer. A DNAME - at a wild card domain name is effectively the same as a CNAME at a - wild card domain name. - -4.5 Empty Non-terminal Wild Card Domain Name - - - If a Source of Synthesis is an empty non-terminal, then the response - will be one of no error in the return code and no RRSet in the answer - section. - -5. Security Considerations - - This document is refining the specifications to make it more likely - that security can be added to DNS. No functional additions are being - made, just refining what is considered proper to allow the DNS, - security of the DNS, and extending the DNS to be more predictable. - -6. References - - Normative References - - [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 - - [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, - Nov-01-1987 - - [RFC 1035] Domain Names - Implementation and Specification, P.V - Mockapetris, Nov-01-1987 - - [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S - Bradner, March 1997 - - Informative References - - [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. - Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 - - [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 - - [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999 - -7. Others Contributing to This Document - - Others who have been editors of this document: Bob Halley and Robert Elz. - Others who have directly caused text to appear in the document: Paul - Vixie and Olaf Kolkman. Many others have indirect influences on the - content. - -8. Editor - - Name: Edward Lewis - Affiliation: NeuStar - Address: tbd - Phone: tbd - Email: tbd (please send comments to namedroppers) - - Comments on this document can be sent to the editors or the mailing - list for the DNSEXT WG, namedroppers@ops.ietf.org. - -9. Trailing Boilerplate - - 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. - -Expiration - - This document expires on or about 11 April 2005. diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-05.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-05.txt new file mode 100644 index 0000000000..d7ca44db0f --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-wcard-clarify-05.txt @@ -0,0 +1,842 @@ + +DNSEXT Working Group E. Lewis +INTERNET DRAFT NeuStar +Expiration Date: August 10, 2005 February 2005 + + The Role of Wildcard Domains + in the Domain Name System + + draft-ietf-dnsext-wcard-clarify-05.txt + +Status of this Memo + + 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 becomes + aware will be disclosed, in accordance with Section 6 of 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 August 10, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This is an update to the wildcard definition of RFC 1034. The + interaction with wildcards and CNAME is changed, an error + condition removed, and the words defining some concepts central to + wildcards are changed. The overall goal is not to change wildcards, + but to refine the definition of RFC 1034. + +1 Introduction + + In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the synthesis + of answers from special resource records called wildcards. The definition + in RFC 1034 is incomplete and has proven to be confusing. This document + describes the wildcard synthesis by adding to the discussion and making + limited modifications. Modifications are made to close inconsistencies + that have led to interoperability issues. This description does not + expand the service intended by the original definition. + + Staying within the spirit and style of the original documents, this + document avoids specifying rules for DNS implementations regarding + wildcards. The intention is to only describe what is needed for + interoperability, not restrict implementation choices. In addition, + consideration has been given to minimize any backwards compatibility + with implementations that have complied with RFC 1034's definition. + + This document is focused on the concept of wildcards as defined in RFC + 1034. Nothing is implied regarding alternative approaches, nor are + alternatives discussed. + + [Note to the WG - this draft is not complete, it is presented as fodder + for the upcoming meeting. Sections 4.2.3, 4.6, 3.7, and 4.8 are + particularly incomplete. I wanted to make sure there was something + recent in the draft repository before setting out on more travel. + + For 4.2.3, refer to the threads for the most recent discussions... + http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01601.html + http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01603.html + + And you might want to check out the minutes from the last IETF meeting + as well as http://www.ietf.org/proceedings/03nov/131.htm.] + +1.1 Motivation + + Many DNS implementations have diverged with respect to wildcards in + different ways from the original definition, or at from least what + had been intended. Although there is clearly a need to clarify the + original documents in light of this alone, the impetus for this document + lay in the engineering of the DNS security extensions [RFC TBD]. With + an unclear definition of wildcards the design of authenticated denial + became entangled. + + This document is intended to limit changes, only those based on + implementation experience, and to remain as close to the original + document as possible. To reinforce this, relevant sections of RFC + 1034 are repeated verbatim to help compare the old and new text. + +1.2 The Original Definition + + The context of the wildcard concept involves the algorithm by which + a name server prepares a response (in RFC 1034's section 4.3.2) and + the way in which a resource record (set) is identified as being a + source of synthetic data (section 4.3.3). + + The beginning of the discussion ought to start with the definition + of the term "wildcard" as it appears in RFC 1034, section 4.3.3. + +# In the previous algorithm, special treatment was given to RRs with owner +# names starting with the label "*". Such RRs are called wildcards. +# Wildcard RRs can be thought of as instructions for synthesizing RRs. +# When the appropriate conditions are met, the name server creates RRs +# with an owner name equal to the query name and contents taken from the +# wildcard RRs. + + This passage appears after the algorithm in which the term wildcard + is first used. In this definition, wildcard refers to resource + records. In other usage, wildcard has referred to domain names, and + it has been used to describe the operational practice of relying on + wildcards to generate answers. It is clear from this that there is + a need to define clear and unambiguous terminology in the process of + discussing wildcards. + + The mention of the use of wildcards in the preparation of a response + is contained in step 3c of RFC 1034's section 4.3.2 entitled "Algorithm." + Note that "wildcard" does not appear in the algorithm, instead references + are made to the "*" label. The portion of the algorithm relating to + wildcards is deconstructed in detail in section 3 of this document, + this is the beginning of the passage. + +# c. If at some label, a match is impossible (i.e., the +# corresponding label does not exist), look to see if a +# the "*" label exists. + + The scope of this document is the RFC 1034 definition of wildcards and + the implications of updates to those documents, such as DNSSEC. Alternate + schemes for synthesizing answers are not considered. (Note that there + is no reference listed. No document is known to describe any alternate + schemes, although there has been some mention of them in mailing lists.) + +1.3 This Document + + This document accomplishes these three items. + o Defines new terms + o Makes minor changes to avoid conflicting concepts + o Describe the actions of certain resource records as wildcards + +1.3.1 New Terms + + To help in discussing what resource records are wildcards, two terms + will be defined - "asterisk label" and "wild card domain name". These + are defined in section 2.1.1. + + To assist in clarifying the role of wildcards in the name server algorithm + in RFC 1034, 4.3.2, "source of synthesis" and "closest encloser" are + defined. These definitions are in section 3.3.2. "Label match" is + defined in section 3.2. + + The introduction of new terms ought not have an impact on any existing + implementations. The new terms are used only to make discussions of + wildcards clearer. + +1.3.2 Changed Text + + The definition of "existence" is changed, superficially. This + change will not be apparent to implementations; it is needed to + make descriptions more precise. The change appears in section 2.2.3. + + RFC 1034, section 4.3.3., seems to prohibit having two asterisk + labels in a wildcard owner name. With this document the restriction + is removed entirely. This change and its implications are in + section 2.1.3. + + The actions when a source of synthesis owns a CNAME RR are changed to + mirror the actions if an exact match name owns a CNAME RR. This + is an addition to the words in RFC 1034, section 4.3.2, step 3, + part c. The discussion of this is in section 3.3.3. + + Only the latter change represents an impact to implementations. The + definition of existence is not a protocol impact. The change to the + restriction on names is unlikely to have an impact, as there was no + discussion of how to enforce the restriction. + +1.3.3 Considerations with Special Types + + This document describes semantics of wildcard CNAME RRSets [RFC2181], + wildcard NS RRSets, wildcard SOA RRSets, wildcard DNAME RRSets + [RFC2672], wildcard DS RRSets [RFC TBD], and empty non-terminal + wildcards. Understanding these types in the context of wildcards + has been clouded because these types incur special processing if they + are the result of an exact match. This discussion is in section 4. + + These discussions do not have an implementation impact, they cover + existing knowledge of the types, but to a greater level of detail. + +1.4 Standards Terminology + + This document does not use terms as defined in "Key words for use in + RFCs to Indicate Requirement Levels." [RFC2119] + + Quotations of RFC 1034 are denoted by a '#' in the leftmost column. + +2 Wildcard Syntax + + The syntax of a wildcard is the same as any other DNS resource record, + across all classes and types. The only significant feature is the + owner name. + + Because wildcards are encoded as resource records with special names, + they are included in zone transfers and incremental zone transfers. + [RFC1995]. This feature has been underappreciated until discussions + on alternative approaches to wildcards appeared on mailing lists. + +2.1 Identifying a wildcard + + To provide a more accurate description of "wildcards", the definition + has to start with a discussion of the domain names that appear as + owners. Two new terms are needed, "Asterisk Label" and "Wild Card + Domain Name." + +2.1.1 Wild Card Domain Name and Asterisk Label + + A "wild card domain name" is defined by having its initial + (i.e., left-most or least significant) label be, in binary format: + + 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) + + The first octet is the normal label type and length for a 1 octet + long label, the second octet is the ASCII representation [RFC20] for + the '*' character. + + A descriptive name of a label equaling that value is an "asterisk + label." + + RFC 1034's definition of wildcard would be "a resource record owned + by a wild card domain name." + +2.1.2 Asterisks and Other Characters + + No label values other than that in section 2.1.1 are asterisk labels, + hence names beginning with other labels are never wild card domain + names. Labels such as 'the*' and '**' are not asterisk labels, + they do not start wild card domain names. + +2.1.3 Non-terminal Wild Card Domain Names + + In section 4.3.3, the following is stated: + +# .......................... The owner name of the wildcard RRs is of +# the form "*.", where is any domain name. +# should not contain other * labels...................... + + This restriction is lifted because the original documentation of it + is incomplete and the restriction does not serve any purpose given + years of operational experience. + + Indirectly, the above passage raises questions about wild card domain + names having subdomains and possibly being an empty non-terminal. By + thinking of domain names such as "*.example.*.example." and + "*.*.example." and focusing on the right-most asterisk label in each, + the issues become apparent. + + Although those example names have been restricted per RFC 1034, a name + such as "example.*.example." illustrates the same problems. The + sticky issue of subdomains and empty non-terminals is not removed by + the restriction. With that conclusion, the restriction appears to + be meaningless, worse yet, it implies that an implementation would have + to perform checks that do little more than waste CPU cycles. + + A wild card domain name can have subdomains. There is no need to + inspect the subdomains to see if there is another asterisk label in + any subdomain. + + A wild card domain name can be an empty non-terminal. (See the upcoming + sections on empty non-terminals.) In this case, any lookup encountering + it will terminate as would any empty non-terminal match. + +2.2 Existence Rules + + The notion that a domain name 'exists' is mentioned in the definition + of wildcards. In section 4.3.3 of RFC 1034: + +# Wildcard RRs do not apply: +# +... +# - When the query name or a name between the wildcard domain and +# the query name is know[n] to exist. For example, if a wildcard + + RFC 1034 also refers to non-existence in the process of generating + a response that results in a return code of "name error." NXDOMAIN + is introduced in RFC 2308, section 2.1 says "In this case the domain + ... does not exist." The overloading of the term "existence" is + confusing. + + For the purposes of this document, a domain name is said to exist if + it plays a role in the execution of the algorithms in RFC 1034. This + document avoids discussion determining when an authoritative name + error has occurred. + +2.2.1 An Example + + To illustrate what is meant by existence consider this complete zone: + + $ORIGIN example. + example. 3600 IN SOA + example. 3600 NS ns.example.com. + example. 3600 NS ns.example.net. + *.example. 3600 TXT "this is a wild card" + *.example. 3600 MX 10 host1.example. + sub.*.example. 3600 TXT "this is not a wild card" + host1.example. 3600 A 192.0.4.1 + _ssh._tcp.host1.example. 3600 SRV + _ssh._tcp.host2.example. 3600 SRV + subdel.example. 3600 NS ns.example.com. + subdel.example. 3600 NS ns.example.net. + + A look at the domain names in a tree structure is helpful: + + | + -------------example------------ + / / \ \ + / / \ \ + / / \ \ + * host1 host2 subdel + | | | + | | | + sub _tcp _tcp + | | + | | + _ssh _ssh + + The following queries would be synthesized from one of the wildcards: + + QNAME=host3.example. QTYPE=MX, QCLASS=IN + the answer will be a "host3.example. IN MX ..." + + QNAME=host3.example. QTYPE=A, QCLASS=IN + the answer will reflect "no error, but no data" + because there is no A RR set at '*.example.' + + QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN + the answer will be "foo.bar.example. IN TXT ..." + because bar.example. does not exist, but the wildcard does. + + The following queries would not be synthesized from any of the wildcards: + + QNAME=host1.example., QTYPE=MX, QCLASS=IN + because host1.example. exists + + QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN + because *.example. exists + + QNAME=sub.*.example., QTYPE=MX, QCLASS=IN + because sub.*.example. exists + + QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN + because _tcp.host1.example. exists (without data) + + QNAME=host.subdel.example., QTYPE=A, QCLASS=IN + because subdel.example. exists (and is a zone cut) + +2.2.2 Empty Non-terminals + + Empty non-terminals [RFC2136, Section 7.16] are domain names that own + no resource records but have subdomains that do. In section 2.2.1, + "_tcp.host1.example." is an example of a empty non-terminal name. + Empty non-terminals are introduced by this text in section 3.1 of RFC + 1034: + +# The domain name space is a tree structure. Each node and leaf on the +# tree corresponds to a resource set (which may be empty). The domain +# system makes no distinctions between the uses of the interior nodes and +# leaves, and this memo uses the term "node" to refer to both. + + The parenthesized "which may be empty" specifies that empty non- + terminals are explicitly recognized, and that empty non-terminals + "exist." + + Pedantically reading the above paragraph can lead to an + interpretation that all possible domains exist - up to the suggested + limit of 255 octets for a domain name [RFC1035]. For example, + www.example. may have an A RR, and as far as is practically + concerned, is a leaf of the domain tree. But the definition can be + taken to mean that sub.www.example. also exists, albeit with no data. + By extension, all possible domains exist, from the root on down. As + RFC 1034 also defines "an authoritative name error indicating that + the name does not exist" in section 4.3.1, this is not the intent of + the original document. + +2.2.3 Yet Another Definition of Existence + + RFC1034's wording is fixed by the following paragraph: + + The domain name space is a tree structure. Nodes in the tree either + own at least one RRSet and/or have descendants that collectively own at + least on RRSet. A node may have no RRSets if it has descendents that + do, this node is a empty non-terminal. A node may have its own RRSets + and have descendants with RRSets too. + + A node with no descendants is a leaf node. Empty leaf nodes do not + exist. + + Note that at a zone boundary, the domain name owns data, including + the NS RR set. At the delegating server, the NS RR set is not + authoritative, but that is of no consequence here. The domain name + owns data, therefore, it exists. + +2.3 When does a Wild Card Domain Name is not Special + + When a wild card domain name appears in a message's query section, + no special processing occurs. An asterisk label in a query name + only (label) matches an asterisk label in the existing zone tree + when the 4.3.2 algorithm is being followed. + + When a wild card domain name appears in the resource data of a + record, no special processing occurs. An asterisk label in that + context literally means just an asterisk. + +3. Impact of a Wild Card Domain Name On a Response + + The description of how wildcards impact response generation is in + RFC 1034, section 4.3.2. That passage contains the algorithm + followed by a server in constructing a response. Within that + algorithm, step 3, part 'c' defines the behavior of the wild card. + + The algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo + code, i.e., its steps are not intended to be followed in strict + order. The "algorithm" is a suggestion. As such, in step 3, parts + a, b, and c, do not have to be implemented in that order. + +3.1 Step 2 + + Step 2 of the RFC 1034's section 4.3.2 reads: + +# 2. Search the available zones for the zone which is the nearest +# ancestor to QNAME. If such a zone is found, go to step 3, +# otherwise step 4. + + In this step, the most appropriate zone for the response is chosen. + The significance of this step is that it means all of step 3 is being + performed within one zone. This has significance when considering + whether or not an SOA RR can be ever be used for synthesis. + +3.2 Step 3 + + Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. But the + beginning of the step is important and needs explanation. + +# 3. Start matching down, label by label, in the zone. The +# matching process can terminate several ways: + + The word 'matching' refers to label matching. The concept + is based in the view of the zone as the tree of existing names. The + query name is considered to be an ordered sequence of labels - as + if the name were a path from the root to the owner of the desired + data. (Which it is - 3rd paragraph of RFC 1034, section 3.1.) + + The process of label matching a query name ends in exactly one of three + choices, the parts 'a', 'b', and 'c'. Either the name is found, the + name is below a cut point, or the name is not found. + + Once one of the parts is chosen, the other parts are not considered. + (E.g., do not execute part 'c' and then change the execution path to + finish in part 'b'.) The process of label matching is also done + independent of the query type (QTYPE). + + Parts 'a' and 'b' are not an issue for this clarification as they do not + relate to record synthesis. Part 'a' is an exact match that results in + an answer, part 'b' is a referral. It is possible, from the description + given, that a query might fit into both part a and part b, this is + not within the scope of this document. + +3.3 Part 'c' + + The context of part 'c' is that the process of label matching the + labels of the query name has resulted in a situation in which there + is no corresponding label in the tree. It is as if the lookup has + "fallen off the tree." + +# c. If at some label, a match is impossible (i.e., the +# corresponding label does not exist), look to see if a +# the "*" label exists. + + + To help describe the process of looking 'to see if a [sic] the "*" + label exists' a term has been coined to describe the last label + matched. The term is "closest encloser." + +3.3.1 Closest Encloser and the Source of Synthesis + + The closest encloser is the node in the zone's tree of existing + domain names that has the most labels matching the query name + (consecutively, counting from the root label downward). Each match + is a "label match" and the order of the labels is the same. + + The closest encloser is, by definition, an existing name in the zone. The + closest encloser might be an empty non-terminal or even be a wild card + domain name itself. In no circumstances is the closest encloser + the used to synthesize records for the current query. + + The source of synthesis is defined in the context of a query process + as that wild card domain name immediately descending from the + closest encloser, provided that this wild card domain name exists. + "Immediately descending" means that the source of synthesis has a name + of the form .. A source of synthesis + does not guarantee having a RRSet to use for synthesis. The source of + synthesis could be an empty non-terminal. + + If the source of synthesis does not exist (not on the domain tree), + there will be no wildcard synthesis. There is no search for an alternate. + + The important concept is that for any given lookup process, there + is at most one place at which wildcard synthetic records can be + obtained. If the source of synthesis does not exist, the lookup + terminates, the lookup does not look for other wildcard records. + +3.3.2 Closest Encloser and Source of Synthesis Examples + + To illustrate, using the example zone in section 2.2.1 of this document, + the following chart shows QNAMEs and the closest enclosers. + + QNAME Closest Encloser Source of Synthesis + host3.example. example. *.example. + _telnet._tcp.host1.example. _tcp.host1.example. no source + _telnet._tcp.host2.example. host2.example. no source + _telnet._tcp.host3.example. example. *.example. + _chat._udp.host3.example. example. *.example. + foobar.*.example. *.example. no source + +3.3.3 Type Matching + + RFC 1034 concludes part 'c' with this: + +# If the "*" label does not exist, check whether the name +# we are looking for is the original QNAME in the query +# or a name we have followed due to a CNAME. If the name +# is original, set an authoritative name error in the +# response and exit. Otherwise just exit. +# +# If the "*" label does exist, match RRs at that node +# against QTYPE. If any match, copy them into the answer +# section, but set the owner of the RR to be QNAME, and +# not the node with the "*" label. Go to step 6. + + The final paragraph covers the role of the QTYPE in the lookup process. + + Based on implementation feedback and similarities between step 'a' and + step 'c' a change to this passage a change has been made. + + The change is to add the following text to step 'c': + + If the data at the source of synthesis is a CNAME, and + QTYPE doesn't match CNAME, copy the CNAME RR into the + answer section of the response changing the owner name + to the QNAME, change QNAME to the canonical name in the + CNAME RR, and go back to step 1. + + This is essentially the same text in step a covering the processing of + CNAME RRSets. + +4. Considerations with Special Types + + Sections 2 and 3 of this document discuss wildcard synthesis with + respect to names in the domain tree and ignore the impact of types. + In this section, the implication of wildcards of specific types are + discussed. The types covered are those that have proven to be the + most difficult to understand. The types are SOA, NS, CNAME, DNAME, + SRV, DS, NSEC, RRSIG and "none," i.e., empty non-terminal wild card + domain names. + +4.1 SOA RRSet at a Wild Card Domain Name + + A wild card domain name owning an SOA RRSet means that the domain + is at the root of the zone (apex). The domain can not be a source of + synthesis because that is, by definition, a descendent node (of + the closest encloser) and a zone apex is at the top of the zone. + + Although a wild card domain name owning an SOA RRSet can never be a + source of synthesis, there is no reason to forbid the ownership of + an SOA RRSet. + + E.g., given this zone: + $ORIGIN *.example. + @ 3600 IN SOA + 3600 NS ns1.example.com. + 3600 NS ns1.example.net. + www 3600 TXT "the www txt record" + + A query for www.*.example.'s TXT record would still find the "the www txt + record" answer. The reason is that the asterisk label only becomes + significant when RFC 1034's 4.3.2, step 3 part 'c' in in effect. + + Of course, there would need to be a delegation in the parent zone, + "example." for this to work too. This is covered in the next section. + +4.2 NS RRSet at a Wild Card Domain Name + + The semantics of a wild card domain name's ownership of a NS RRSet + has been unclear. There are three considerations to cover. One is + is that if the query processing lands in part 'a' or part 'b' of + RFC 1034's 4.3.2, step 3, the incidence of the wild card domain name + owning an NS RRset has no special meaning. Second, synthesized + records never appear in the authority section of a response, meaning + that referrals are never synthesized. And finally, DNSSEC validators + will have to be aware of a quirk in ownership rules. + +4.2.1 NS, *, and answers + + If the NS RRSet in question is at the top of the zone, i.e., the + name also owns an SOA RRSet, the QNAME equals the zone name. This + would trigger part 'a' of step 3. + +4.2.2 NS, *, and referrals + + If the NS RRset is not at the top of the zone and part 'b' is triggered, + this implies that the labels being matched are an asterisk label in + the QNAME and the asterisk label owning the NS RRset. In either case, + what is copied to the response will have the asterisk label in it - no + synthesis, no name substitution. + + E.g., consider the parent zone for the example in section 4.1. + $ORIGIN example. + @ 3600 IN SOA + 3600 NS ns0.example.com. + 3600 NS ns0.example.net. + * 3600 NS ns1.example.com. + 3600 NS ns1.example.net. + + If the query for www.*.example.'s TXT set arrived here, the response + would be a referral as in part 'b'. + + Response, non-authoritative, no error rcode + ANSWER: (empty) + AUTHORITY: + * 3600 NS ns1.example.com. + 3600 NS ns1.example.net. + ADDITIIONAL: (empty, or with OPT RR) + + The same response message would be sent to a query for *.example.'s NS + set. Note that the NS records in the response are not expanded, simply + copied verbatim. (Compare this the case where "*" is "star".) + + There is no synthesis of records in the authority section because part + 'b' does not specify synthesis. The referral returned would have the + wild card domain name in the authority section unchanged. + +4.2.3 NS, *, and synthesis + + If the QNAME is not the same as the wild card domain name nor a + subdomain of it, then part 'c' of step 3 has been triggered. Assuming + that "a match is impossible" a source of synthesis is sought. If + the source of synthesis owns an NS RRset and the QTYPE is NS, then + a NS RRset is synthesized and put into the answer section and marked + as an authoritative answer. If the QTYPE is not NS, then the NS RRset + is ignored, as it would have been if it were an A RR and the QTYPE was + AAAA. An NS RRSet at a wild card domain name will not result in + the generation of referral messages for non-existent domains because + part 'c' does not write anything into the authority section. + + (If we choose this, then we have to have a section 4.2.4 on DNSSEC + implications.) + +OR + + If the QNAME is not the same as the wild card domain name nor a + subdomain of it, then part 'c' of step 3 has been triggered. Assuming + that "a match is impossible" a source of synthesis is sought. If + the source of synthesis owns an NS RRset and the QTYPE is NS, then + no synthesis happens. A NS RRset is never synthesized. The proper + response is, what, no error/no data? Name error? + +OR + + If the QNAME is not the same as the wild card domain name nor a + subdomain of it, then part 'c' of step 3 has been triggered. Assuming + that "a match is impossible" a source of synthesis is sought. If + the source of synthesis owns an NS RRset then no synthesis happens. + A cut point is never a source of synthesis. The proper response is, + what, no error/no data? Name error? + +4.3 CNAME RRSet at a Wild Card Domain Name + + The issue of a CNAME RRSet owned by wild card domain names has prompted + a suggested change to the last paragraph of step 3c of the algorithm + in 4.3.2. The changed text appears in section 3.3.3 of this document. + +4.4 DNAME RRSet at a Wild Card Domain Name + + A DNAME RRset at a wild card domain name is effectively the same + as a CNAME at a wild card domain name. + +4.5 SRV RRSet at a Wild Card Domain Name + + The definition of the SRV RRset is RFC 2782 [RFC2782]. In the + definition of the record, there is some confusion over the term + "Name." The definition reads as follows: + +# The format of the SRV RR +... +# _Service._Proto.Name TTL Class SRV Priority Weight Port Target +... +# Name +# The domain this RR refers to. The SRV RR is unique in that the +# name one searches for is not this name; the example near the end +# shows this clearly. + + Do not confuse the definition "Name" with a domain name. I.e., once + removing the _Service and _Proto labels from the owner name of the + SRV RRSet, what remains could be a wild card domain name but this is + immaterial to the SRV RRSet. + + E.g., If an SRV record is: + _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. + + *.example is a wild card domain name and although it it the Name of + the SRV RR, it is not the owner (domain name). The owner domain name + is "_foo._udp.*.example." which is not a wild card domain name. + + The confusion is likely based on the mixture of the specification of + the SRV RR and the description of a "use case." + +4.6 DS RRSet at a Wild Card Domain Name + +...probably harmless... + +4.7 NSEC RRSet at a Wild Card Domain Name + +...will be present, don't know if it should be synthesized... + +4.8 RRSIG at a Wild Card Domain Name + +...need to cross check with DNSSECbis to see what is said about querying +for RRSIG... + +4.9 Empty Non-terminal Wild Card Domain Name + + If a source of synthesis is an empty non-terminal, then the response + will be one of no error in the return code and no RRSet in the answer + section. + +5. Security Considerations + + This document is refining the specifications to make it more likely + that security can be added to DNS. No functional additions are being + made, just refining what is considered proper to allow the DNS, + security of the DNS, and extending the DNS to be more predictable. + +6. References + + Normative References + + [RFC20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 + + [RFC1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, + Nov-01-1987 + + [RFC1035] Domain Names - Implementation and Specification, P.V + Mockapetris, Nov-01-1987 + + [RFC1995] IXFR ... Ohta + + [RFC2119] Key Words for Use in RFCs to Indicate Requirement Levels, S + Bradner, March 1997 + + [RFC2181] Clarifications to the DNS Specification, R. Elz and R. Bush, + July 1997. + + [RFC2782] A DNS RR for specifying the location of services (DNS SRV), + A. Gulbrandsen, et.al., February 2000. + + Informative References + + [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. + Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 + + [RFC2535] Domain Name System Security Extensions, D. Eastlake, March 1999 + + [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999 + +7. Others Contributing to This Document + + Others who have been editors of this document: Bob Halley. + Others who have directly caused text to appear in the document: Alex + Bligh, Robert Elz, Paul Vixie, David Blacka and Olaf Kolkman. + Many others have indirect influences on the content. + +8. Editor + + Name: Edward Lewis + Affiliation: NeuStar + Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US + Phone: +1-571-434-5468 + Email: ed.lewis@neustar.biz + + Comments on this document can be sent to the editor or the mailing + list for the DNSEXT WG, namedroppers@ops.ietf.org. + +9. Trailing Boilerplate + + 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. + +Expiration + + This document expires on or about August 10, 2005. + + + + diff --git a/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt deleted file mode 100644 index e9943015e4..0000000000 --- a/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt +++ /dev/null @@ -1,1120 +0,0 @@ - - -DNS Operations M. Larson -Internet-Draft P. Barber -Expires: August 16, 2004 VeriSign - February 16, 2004 - - - Observed DNS Resolution Misbehavior - draft-ietf-dnsop-bad-dns-res-02 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 16, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This Internet-Draft describes DNS name server and resolver behavior - that results in a significant query volume sent to the root and - top-level domain (TLD) name servers. In some cases we recommend - minor additions to the DNS protocol specification and corresponding - changes in name server implementations to alleviate these unnecessary - queries. The recommendations made in this document are a direct - byproduct of observation and analysis of abnormal query traffic - patterns seen at two of the thirteen root name servers and all - thirteen com/net TLD name servers. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - - - -Larson & Barber Expires August 16, 2004 [Page 1] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - document are to be interpreted as described in RFC 2119 [1]. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Observed name server misbehavior . . . . . . . . . . . . . 4 - 2.1 Aggressive requerying for delegation information . . . . . 4 - 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 5 - 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 5 - 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 6 - 2.3 Inability to follow multiple levels of out-of-zone glue . 6 - 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 7 - 2.4 Aggressive retransmission when fetching glue . . . . . . . 7 - 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8 - 2.5 Aggressive retransmission behind firewalls . . . . . . . . 8 - 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8 - 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 9 - 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 10 - 2.7 Name server records with zero TTL . . . . . . . . . . . . 10 - 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11 - 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 11 - 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11 - 2.9 Queries for domain names resembling IP addresses . . . . . 12 - 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 12 - 2.10 Misdirected recursive queries . . . . . . . . . . . . . . 12 - 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13 - 2.11 Suboptimal name server selection algorithm . . . . . . . . 13 - 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13 - 3. IANA considerations . . . . . . . . . . . . . . . . . . . 15 - 4. Security considerations . . . . . . . . . . . . . . . . . 16 - 5. Internationalization considerations . . . . . . . . . . . 17 - Normative References . . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18 - Intellectual Property and Copyright Statements . . . . . . 19 - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 2] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -1. Introduction - - Observation of query traffic received by two root name servers and - the thirteen com/net TLD name servers has revealed that a large - proportion of the total traffic often consists of "requeries". A - requery is the same question () asked - repeatedly at an unexpectedly high rate. We have observed requeries - from both a single IP address and multiple IP addresses. - - By analyzing requery events we have found that the cause of the - duplicate traffic is almost always a deficient name server, stub - resolver and/or application implementation combined with an - operational anomaly. The implementation deficiencies we have - identified to date include well-intentioned recovery attempts gone - awry, insufficient caching of failures, early abort when multiple - levels of glue records must be followed, and aggressive retry by stub - resolvers and/or applications. Anomalies that we have seen trigger - requery events include lame delegations, unusual glue records, and - anything that makes all authoritative name servers for a zone - unreachable (DoS attacks, crashes, maintenance, routing failures, - congestion, etc.). - - In the following sections, we provide a detailed explanation of the - observed behavior and recommend changes that will reduce the requery - rate. Some of the changes recommended affect the core DNS protocol - specification, described principally in RFC 1034 [2], RFC 1035 [3] - and RFC 2181 [4]. - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 3] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -2. Observed name server misbehavior - -2.1 Aggressive requerying for delegation information - - There can be times when every name server in a zone's NS RRset is - unreachable (e.g., during a network outage), unavailable (e.g., the - name server process is not running on the server host) or - misconfigured (e.g., the name server is not authoritative for the - given zone, also known as "lame"). Consider a recursive name server - that attempts to resolve a query for a domain name in such a zone and - discovers that none of the zone's name servers can provide an answer. - We have observed a recursive name server implementation that then - verifies the zone's NS RRset in its cache by querying for the zone's - delegation information: it sends a query for the zone's NS RRset to - one of the parent zone's name servers. - - For example, suppose that "example.com" has the following NS RRset: - - example.com. IN NS ns1.example.com. - example.com. IN NS ns2.example.com. - - Upon receipt of a query for "www.example.com" and assuming that - neither "ns1.example.com" nor "ns2.example.com" can provide an - answer, this recursive name server implementation immediately queries - a "com" zone name server for the "example.com" NS RRset to verify it - has the proper delegation information. This name server - implementation performs this query to a zone's parent zone for each - recursive query it receives that fails because of a completely - unresponsive set of name servers for the target zone. Consider the - effect when a popular zone experiences a catastrophic failure of all - its name servers: now every recursive query for domain names in that - zone sent to this name server implementation results in a query to - the failed zone's parent name servers. On one occasion when several - dozen popular zones became unreachable, the query load on the com/net - name servers increased by 50%. - - We believe this verification query is not reasonable. Consider the - circumstances: When a recursive name server is resolving a query for - a domain name in a zone it has not previously searched, it uses the - list of name servers in the referral from the target zone's parent. - If on its first attempt to search the target zone, none of the name - servers in the referral is reachable, a verification query to the - parent is pointless: this query to the parent would come so quickly - on the heels of the referral that it would be almost certain to - contain the same list of name servers. The chance of discovering any - new information is slim. - - The other possibility is that the recursive name server successfully - - - -Larson & Barber Expires August 16, 2004 [Page 4] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - contacts one of the target zone's name servers and then caches the NS - RRset from the authority section of a response, the proper behavior - according to section 5.4.1 of RFC 2181 [4], because the NS RRset from - the target zone is more trustworthy than delegation information from - the parent zone. If, while processing a subsequent recursive query, - the recursing name server discovers that none of the name servers - specified in the cached NS RRset is available or authoritative, - querying the parent would be wrong. An NS RRset from the parent zone - would now be less trustworthy than data already in the cache. - - For this query of the parent zone to be useful, the target zone's - entire set of name servers would have to change AND the former set of - name servers would have to be deconfigured and/or decommissioned AND - the delegation information in the parent zone would have to be - updated with the new set of name servers, all within the TTL of the - target zone's NS RRset. We believe this scenario is uncommon: - administrative best practices dictate that changes to a zone's set of - name servers happen gradually, with servers that are removed from the - NS RRset left authoritative for the zone as long as possible. The - scenarios that we can envision that would benefit from the parent - requery behavior do not outweigh its damaging effects. - -2.1.1 Recommendation - - Name servers offering recursion MUST NOT send a query for the NS - RRset of a non-responsive zone to any of the name servers for that - zone's parent zone. For the purposes of this injunction, a - non-responsive zone is defined as a zone for which every name server - listed in the zone's NS RRset: - - 1. is not authoritative for the zone (i.e., lame), or, - - 2. returns a server failure response (RCODE=2), or, - - 3. is dead or unreachable according to section 7.2 of RFC 2308 [5]. - - -2.2 Repeated queries to lame servers - - Section 2.1 describes a catastrophic failure: when every name server - for a zone is unable to provide an answer for one reason or another. - A more common occurrence is a subset of a zone's name servers being - unavailable or misconfigured. Different failure modes have different - expected durations. Some symptoms indicate problems that are - potentially transient: various types of ICMP unreachable messages - because a name server process is not running or a host or network is - unreachable, or a complete lack of a response to a query. Such - responses could be the result of a host rebooting or temporary - - - -Larson & Barber Expires August 16, 2004 [Page 5] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - outages; these events don't necessarily require any human - intervention and can be reasonably expected to be temporary. - - Other symptoms clearly indicate a condition requiring human - intervention, such as lame server: if a name server is misconfigured - and not authoritative for a zone delegated to it, it is reasonable to - assume that this condition has potential to last longer than - unreachability or unresponsiveness. Consequently, repeated queries - to known lame servers are not useful. In this case of a condition - with potential to persist for a long time, a better practice would be - to maintain a list of known lame servers and avoid querying them - repeatedly in a short interval. - -2.2.1 Recommendation - - Recursive name servers SHOULD cache name servers that they discover - are not authoritative for zones delegated to them (i.e. lame - servers). Lame servers MUST be cached against the specific query - tuple . Zone name can be - derived from the owner name of the NS record that was referenced to - query the name server that was discovered to be lame. - Implementations that perform lame server caching MUST refrain from - sending queries to known lame servers based on a time interval from - when the server is discovered to be lame. A minimum interval of - thirty minutes is RECOMMENDED. - -2.3 Inability to follow multiple levels of out-of-zone glue - - Some recursive name server implementations are unable to follow more - than one level of out-of-zone glue. For example, consider the - following delegations: - - foo.example. IN NS ns1.example.com. - foo.example. IN NS ns2.example.com. - - example.com. IN NS ns1.test.example.net. - example.com. IN NS ns2.test.example.net. - - test.example.net. IN NS ns1.test.example.net. - test.example.net. IN NS ns2.test.example.net. - - A name server processing a recursive query for "www.foo.example" must - follow two levels of indirection, first obtaining address records for - "ns1.test.example.net" and/or "ns2.test.example.net" in order to - obtain address records for "ns1.example.com" and/or "ns2.example.com" - in order to query those name servers for the address records of - "www.foo.example". While this situation may appear contrived, we - have seen multiple similar occurrences and expect more as new generic - - - -Larson & Barber Expires August 16, 2004 [Page 6] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - top-level domains (gTLDs) become active. We anticipate many zones in - the new gTLDs will use name servers in other gTLDs, increasing the - amount of inter-zone glue. - -2.3.1 Recommendation - - Clearly constructing a delegation that relies on multiple levels of - out-of-zone glue is not a good administrative practice. This issue - could be mitigated with an operational injunction in an RFC to - refrain from construction of such delegations. In our opinion the - practice is widespread enough to merit clarifications to the DNS - protocol specification to permit it on a limited basis. - - Name servers offering recursion SHOULD be able to handle at least - three levels of indirection resulting from out-of-zone glue. - -2.4 Aggressive retransmission when fetching glue - - When an authoritative name server responds with a referral, it - includes NS records in the authority section of the response. - According to the algorithm in section 4.3.2 of RFC 1034 [2], the name - server should also "put whatever addresses are available into the - additional section, using glue RRs if the addresses are not available - from authoritative data or the cache." Some name server - implementations take this address inclusion a step further with a - feature called "glue fetching". A name server that implements glue - fetching attempts to include A records for every NS record in the - authority section. If necessary, the name server issues multiple - queries of its own to obtain any missing A records. - - Problems with glue fetching can arise in the context of - "authoritative-only" name servers, which only serve authoritative - data and ignore requests for recursion. Such a server will not - generate any queries of its own. Instead it answers non-recursive - queries from resolvers looking for information in zones it serves. - With glue fetching enabled, however, an authoritative server will - generate queries whenever it needs to look up an unknown address - record to complete the additional section of a response. - - We have observed situations where a glue-fetching name server can - send queries that reach other name servers, but apparently is - prevented from receiving the responses. For example, perhaps the - name server is authoritative-only and therefore its administrators - expect it to receive only queries. Perhaps unaware of glue fetching - and presuming that the name server will generate no queries, its - administrators place the name server behind a network device that - prevents it from receiving responses. If this is the case, all - glue-fetching queries will go answered. - - - -Larson & Barber Expires August 16, 2004 [Page 7] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - We have observed name server implementations that retry excessively - when glue-fetching queries are unanswered. A single com/net name - server has received hundreds of queries per second from a single name - server. Judging from the specific queries received and based on - additional analysis, we believe these queries result from overly - aggressive glue fetching. - -2.4.1 Recommendation - - Implementers whose name servers support glue fetching should take - care to avoid sending queries at excessive rates. Implementations - should support throttling logic to detect when queries are sent but - no responses are received. - -2.5 Aggressive retransmission behind firewalls - - A common occurrence and one of the largest sources of repeated - queries at the com/net and root name servers appears to result from - resolvers behind misconfigured firewalls. In this situation, a - recursive name server is apparently allowed to send queries through a - firewall to other name servers, but not receive the responses. The - result is more queries than necessary because of retransmission, all - of which are useless because the responses are never received. Just - as with the glue-fetching scenario described in Section 2.4, the - queries are sometimes sent at excessive rates. To make matters - worse, sometimes the responses, sent in reply to legitimate queries, - trigger an alarm on the originator's intrusion detection system. We - are frequently contacted by administrators responding to such alarms - who believe our name servers are attacking their systems. - - Not only do some resolvers in this situation retransmit queries at an - excessive rate, but they continue to do so for days or even weeks. - This scenario could result from an organization with multiple - recursive name servers, only a subset of whose traffic is improperly - filtered in this manner. Stub resolvers in the organization could be - configured to query multiple name servers. Consider the case where a - stub resolver queries a filtered name server first. This name server - sends one or more queries whose replies are filtered, so it can't - respond to the stub resolver, which times out. The resolver - retransmits to a name server that is able to provide an answer. - Since resolution ultimately succeeds the underlying problem might not - be recognized or corrected. A popular stub resolver has a very - aggressive retransmission schedule, including simultaneous queries to - multiple name servers, which could explain how such a situation could - persist without being detected. - -2.5.1 Recommendation - - - - -Larson & Barber Expires August 16, 2004 [Page 8] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - The most obvious recommendation is that administrators should take - care not to place recursive name servers behind a firewall that - prohibits queries to pass through but not the resulting replies. - - Name servers should take care to avoid sending queries at excessive - rates. Implementations should support throttling logic to detect - when queries are sent but no responses are received. - -2.6 Misconfigured NS records - - Sometimes a zone administrator forgets to add the trailing dot on the - domain names in the RDATA of a zone's NS records. Consider this - fragment of the zone file for "example.com": - - $ORIGIN example.com. - example.com. 3600 IN NS ns1.example.com ; Note missing - example.com. 3600 IN NS ns2.example.com ; trailing dots - - The zone's authoritative servers will parse the NS RDATA as - "ns1.example.com.example.com" and "ns2.example.com.example.com" and - return NS records with this incorrect RDATA in responses, including - typically the authority section of every response containing records - from the "example.com" zone. - - Now consider a typical sequence of queries. A recursive name server - attempting to resolve A records for "www.example.com" with no cached - information for this zone will query a "com" authoritative server. - The "com" server responds with a referral to the "example.com" zone, - consisting of NS records with valid RDATA and associated glue - records. (This example assumes that the "example.com" zone - information is correct in the "com" zone.) The recursive name server - caches the NS RRset from the "com" server and follows the referral by - querying one of the "example.com" authoritative servers. This server - responds with the "www.example.com" A record in the answer section - and, typically, the "example.com" NS records in the authority section - and, if space in the message remains, glue A records in the - additional section. According to Section 5.4 of RFC 2181 [4], NS - records in the authority section of an authoritative answer are more - trustworthy than NS records from the authority section of a - non-authoritative answer. Thus the "example.com" NS RRset just - received from the "example.com" authoritative server displaces the - "example.com" NS RRset received moments ago from the "com" - authoritative server. - - But the "example.com" zone contains the erroneous NS RRset as shown - in the example above. Subsequent queries for names in "example.com" - will cause the server to attempt to use the incorrect NS records and - so the server will try to resolve the nonexistent names - - - -Larson & Barber Expires August 16, 2004 [Page 9] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - "ns1.example.com.example.com" and "ns2.example.com.example.com". In - this example, since all of the zone's name servers are named in the - zone itself (i.e., "ns1.example.com.example.com" and - "ns2.example.com.example.com" both end in "example.com") and all are - bogus, the recursive server cannot reach any "example.com" name - servers. Therefore attempts to resolve these names result in A - record queries to the "com' authoritative servers. Queries for such - obviously bogus glue A records occur frequently at the com/net name - servers. - -2.6.1 Recommendation - - An authoritative server can detect this situation. A trailing dot - missing from an NS record's RDATA always results by definition in a - name server name that is in the zone. But any in-zone name server - should have a corresponding glue A record also in the zone. An - authoritative name server should report an error when a zone's NS - record references an in-zone name server without a corresponding glue - A record. - -2.7 Name server records with zero TTL - - Sometimes a popular com/net subdomain's zone is configured with a TTL - of zero on the zone's NS records, which prohibits these records from - being cached and will result in a higher query volume to the zone's - authoritative servers. The zone's administrator should understand - the consequences of such a configuration and provision resources - accordingly. A zero TTL on the zone's NS RRset, however, carries - additional consequences beyond the zone itself: if a recursive name - server cannot cache a zone's NS records because of a zero TTL, it - will be forced to query that zone's parent's name servers each time - it resolves a name in the zone. The com/net authoritative servers do - see an increased query load when a popular com/net subdomain's zone - is configured with a TTL of zero on the zone's NS records. - - A zero TTL on an RRset expected to change frequently is extreme but - permissible. A zone's NS RRset is a special case, however, because - changes to it must be coordinated with the zone's parent. In most - zone parent/child relationships we are aware of, there is typically - some delay involved in effecting changes. Further, changes to the - set of a zone's authoritative name servers (and therefore to the - zone's NS RRset) are typically relatively rare: providing reliable - authoritative service requires a reasonably stable set of servers. - Therefore an extremely low or zero TTL on a zone's NS RRset rarely - makes sense, except in anticipation of an upcoming change. In this - case, when the zone's administrator has planned a change and does not - want recursive name servers throughout the Internet to cache the NS - RRset for a long period of time, a low TTL is reasonable. - - - -Larson & Barber Expires August 16, 2004 [Page 10] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -2.7.1 Recommendation - - Because of the additional load placed on a zone's parent's - authoritative servers imposed by a zero TTL on a zone's NS RRset, - under such circumstances authoritative name servers should issue a - warning when loading a zone or refuse to load the zone altogether. - -2.8 Unnecessary dynamic update messages - - The UPDATE message specified in RFC 2136 [6] allows an authorized - agent to update a zone's data on an authoritative name server using a - DNS message sent over the network. Consider the case of an agent - desiring to add a particular resource record. Because of zone cuts, - the agent does not necessarily know the proper zone to which the - record should be added. The dynamic update process requires that the - agent determine the appropriate zone so the UPDATE message can be - sent to one of the zone's authoritative servers (typically the - primary master as specified in the zone's SOA MNAME field). - - The appropriate zone to update is the closest enclosing zone, which - is the lowest zone in the name space. The closest enclosing zone - cannot be determined only by inspecting the domain name of the record - to be updated, since zone cuts can occur anywhere. One way to - determine the closest enclosing zone involves working up the name - space tree and sending repeated UPDATE messages until success. For - example, consider an agent attempting to add an A record with the - name "foo.bar.example.com". The agent could first attempt to update - the "foo.bar.example.com" zone. If the attempt failed, the update - could be directed to the "bar.example.com" zone, then the - "example.com" zone, then the "com" zone, and finally the root zone. - - A popular dynamic agent follows this algorithm. The result is many - UPDATE messages received by the root name servers, the com/net - authoritative servers, and presumably other TLD authoritative - servers. A reasonable question is why the algorithm proceeds with - sending updates all the way to TLD and root name servers. In - enterprise DNS architectures with an "internal root" design, there - could conceivably be private, non-public TLD or root zones that would - be the appropriate target for a dynamic update. However, we question - if designing an algorithm to accommodate these limited cases is worth - the load it places on the public DNS in the form of unnecessary - UPDATE messages. - -2.8.1 Recommendation - - Dynamic update agents should not attempt to send UPDATE messages to - authoritative servers for TLD zones or the root zone by default. If - this functionality is supported, it should be require specific action - - - -Larson & Barber Expires August 16, 2004 [Page 11] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - by a user to be enabled. - -2.9 Queries for domain names resembling IP addresses - - The root name servers receive a significant number of A record - queries where the qname is an IP address. The source of these - queries is unknown. It could be attributed to situations where a - user believes an application will accept either a domain name or an - IP address in a given configuration option. The user enters an IP - address, but the application assumes any input is a domain name and - attempts to resolve it, resulting in an A record lookup. There could - also be applications that produce such queries in a misguided attempt - to reverse map IP addresses. - - These queries result in Name Error (RCODE=3) responses. A recursive - name server can negatively cache such responses, but each response - requires a separate cache entry, i.e., a negative cache entry for the - domain name "192.0.2.1" does not prevent a subsequent query for the - domain name "192.0.2.2". - -2.9.1 Recommendation - - It would be desirable for the root name servers not to have to answer - these queries: they unnecessarily consume CPU resources and network - bandwidth. One possibility is for recursive name server - implementations to produce the Name Error response directly. We - suggest that implementors consider the option of synthesizing Name - Error responses at the recursive name server. The server could claim - authority for synthesized TLD zones corresponding to the first octet - of every possible IP address, e.g. 1., 2., through 255. This - behavior could be configurable in the (probably unlikely) event that - numeric TLDs are ever put into use. - - Another option is to delegate these numeric TLDs from the root zone - to a separate set of servers to absorb the traffic. The "blackhole - servers" used by the the AS 112 Project [8], which are currently - delegated the in-addr.arpa zones corresponding to RFC 1918 [7] - private use address space, would be a possible choice to receive - these delegations. - -2.10 Misdirected recursive queries - - The root name servers receive a significant number of recursive - queries (i.e., queries with the RD bit set in the header). Since - none of the root servers offer recursion, the servers' response in - such a situation ignores the request for recursion and the response - probably does not contain the data the querier anticipated. Some of - these queries result from users configuring stub resolvers to query a - - - -Larson & Barber Expires August 16, 2004 [Page 12] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - root server. (This situation is not hypothetical: we have received - complaints from users when this configuration does not work as - hoped.) Of course, users should not direct stub resolvers to use name - servers that do not offer recursion, but we are not aware of any stub - resolver implementation that offers any feedback to the user when so - configured, aside from simply "not working". - -2.10.1 Recommendation - - When the IP address of a (supposedly) recursive name server is - configured in a stub resolver using an interactive user interface, - the resolver could send a test query to verify that the server - supports recursion (i.e., the response has the RA bit set in the - header). The user could be immediately notified if the server is - non-recursive. - - The stub resolver could also report an error, either through a user - interface or in a log file, if the queried server does not support - recursion. Error reporting should be throttled to avoid a - notification or log message for every response from a non-recursive - server. - -2.11 Suboptimal name server selection algorithm - - An entire document could be devoted to the topic of problems with - different implementations of the recursive resolution algorithm. The - entire process of recursion is woefully underspecified, requiring - each implementor to design an algorithm. Sometimes implementors make - poor design choices that could be avoided if a suggested algorithm - and best practices were documented, but that is a topic for another - document. - - Some deficiencies cause significant operational impact and are - therefore worth mentioning here. One of these is name server - selection by a recursive name server. When a recursive name server - wants to contact one of a zone's authoritative name servers, how does - it choose from the NS records listed in the zone's NS RRset? If the - selection mechanism is suboptimal, queries are not spread evenly - among a zone's authoritative servers. The details of the selection - mechanism are up to the implementor, but we offer some suggestions. - -2.11.1 Recommendation - - This list is not conclusive, but reflects the changes that would - produce the most impact in terms of reducing disproportionate query - load among a zone's authoritative servers. I.e., these changes would - help spread the query load evenly. - - - - -Larson & Barber Expires August 16, 2004 [Page 13] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - o Do not make assumptions based on NS RRset order: all NS RRs should - be treated equally. (In the case of the "com" zone, for example, - most of the root servers return the NS record for - "a.gtld-servers.net" first in the authority section of referrals. - As a result, this server receives disproportionately more traffic - than the other 12 authoritative servers for "com".) - - o Use all NS records in an RRset. (For example, we are aware of - implementations that hard-coded information for a subset of the - root servers.) - - o Maintain state and favor the best-performing of a zone's - authoritative servers. A good definition of performance is - response time. Non-responsive servers can be penalized with an - extremely high response time. - - o Do not lock onto the best-performing of a zone's name servers. A - recursive name server should periodically check the performance of - all of a zone's name servers to adjust its determination of the - best-performing one. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 14] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -3. IANA considerations - - There are no new IANA considerations introduced by this - Internet-Draft. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 15] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -4. Security considerations - - Name server and resolver misbehaviors identical or similar to those - discussed in this document expose the root and TLD name servers to - increased risk of both intentional and unintentional denial of - service. - - We believe that implementation of the recommendations offered in this - document will reduce the amount of unnecessary traffic seen at root - and TLD name servers, thus reducing the opportunity for an attacker - to use such queries to his or her advantage. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 16] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -5. Internationalization considerations - - We do not believe this document introduces any new - internationalization considerations to the DNS protocol - specification. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 17] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [3] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [4] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - - [5] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC - 2308, March 1998. - - [6] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April - 1997. - - [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. - Lear, "Address Allocation for Private Internets", BCP 5, RFC - 1918, February 1996. - - [8] - - -Authors' Addresses - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Piet Barber - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: pbarber@verisign.com - - - - - -Larson & Barber Expires August 16, 2004 [Page 18] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Larson & Barber Expires August 16, 2004 [Page 19] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 20] - diff --git a/doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt new file mode 100644 index 0000000000..9537af6534 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt @@ -0,0 +1,1123 @@ + + + +DNS Operations M. Larson +Internet-Draft P. Barber +Expires: April 27, 2005 VeriSign + October 27, 2004 + + + Observed DNS Resolution Misbehavior + draft-ietf-dnsop-bad-dns-res-03 + +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 April 27, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This memo describes DNS name server and resolver behavior that + results in a significant query volume sent to the root and top-level + domain (TLD) name servers. In some cases we recommend minor + additions to the DNS protocol specification and corresponding changes + in iterative resolver implementations to alleviate these unnecessary + queries. The recommendations made in this document are a direct + byproduct of observation and analysis of abnormal query traffic + + + +Larson & Barber Expires April 27, 2005 [Page 1] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + patterns seen at two of the thirteen root name servers and all + thirteen com/net TLD name servers. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 A note about terminology in this memo . . . . . . . . . . 3 + 2. Observed iterative resolver misbehavior . . . . . . . . . . 5 + 2.1 Aggressive requerying for delegation information . . . . . 5 + 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . 6 + 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 6 + 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . 7 + 2.3 Inability to follow multiple levels of out-of-zone glue . 7 + 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . 8 + 2.4 Aggressive retransmission when fetching glue . . . . . . . 8 + 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . 9 + 2.5 Aggressive retransmission behind firewalls . . . . . . . . 9 + 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . 10 + 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 10 + 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . 11 + 2.7 Name server records with zero TTL . . . . . . . . . . . . 11 + 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . 12 + 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 12 + 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13 + 2.9 Queries for domain names resembling IP addresses . . . . . 13 + 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13 + 2.10 Misdirected recursive queries . . . . . . . . . . . . . 14 + 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . 14 + 2.11 Suboptimal name server selection algorithm . . . . . . . 14 + 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . 15 + 3. IANA considerations . . . . . . . . . . . . . . . . . . . . 16 + 4. Security considerations . . . . . . . . . . . . . . . . . . 17 + 5. Internationalization considerations . . . . . . . . . . . . 18 + 6. Normative References . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 + Intellectual Property and Copyright Statements . . . . . . . 20 + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 2] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +1. Introduction + + Observation of query traffic received by two root name servers and + the thirteen com/net TLD name servers has revealed that a large + proportion of the total traffic often consists of "requeries". A + requery is the same question () asked + repeatedly at an unexpectedly high rate. We have observed requeries + from both a single IP address and multiple IP addresses (i.e., the + same query received simultaneously from multiple IP addresses). + + By analyzing requery events we have found that the cause of the + duplicate traffic is almost always a deficient iterative resolver, + stub resolver or application implementation combined with an + operational anomaly. The implementation deficiencies we have + identified to date include well-intentioned recovery attempts gone + awry, insufficient caching of failures, early abort when multiple + levels of glue records must be followed, and aggressive retry by stub + resolvers or applications. Anomalies that we have seen trigger + requery events include lame delegations, unusual glue records, and + anything that makes all authoritative name servers for a zone + unreachable (DoS attacks, crashes, maintenance, routing failures, + congestion, etc.). + + In the following sections, we provide a detailed explanation of the + observed behavior and recommend changes that will reduce the requery + rate. Some of the changes recommended affect the core DNS protocol + specification, described principally in RFC 1034 [2], RFC 1035 [3] + and RFC 2181 [4]. + +1.1 A note about terminology in this memo + + To recast an old saying about standards, the nice thing about DNS + terms is that there are so many of them to choose from. Writing or + talking about DNS can be difficult and cause confusion resulting from + a lack of agreed-upon terms for its various components. Further + complicating matters are implementations that combine multiple roles + into one piece of software, which makes naming the result + problematic. An example is the entity that accepts recursive + queries, issues iterative queries as necessary to resolve the initial + recursive query, caches responses it receives, and which is also able + answer questions about certain zones authoritatively. Often called a + "recursive name server" or a "caching name server", it is in fact an + iterative resolver combined with an authoritative name server. + + This memo is concerned principally with the behavior of iterative + resolvers, which are typically found as part of a recursive name + server. This memo uses the more precise term "iterative resolver", + because the focus is usually on that component. In instances where + + + +Larson & Barber Expires April 27, 2005 [Page 3] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + the name server role of this entity requires mentioning, this memo + uses the term "recursive name server". For example, the name server + component of a recursive name server receives DNS queries and the + iterative resolver component sends queries. + + The advent of IPv6 requires mentioning AAAA records as well as A + records when discussing glue. To avoid continuous repetition and + qualification, this memo uses the general term "address records" to + encompass both A and AAAA records when a particular situation is + relevant to both types. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 4] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +2. Observed iterative resolver misbehavior + +2.1 Aggressive requerying for delegation information + + There can be times when every name server in a zone's NS RRset is + unreachable (e.g., during a network outage), unavailable (e.g., the + name server process is not running on the server host) or + misconfigured (e.g., the name server is not authoritative for the + given zone, also known as "lame"). Consider an iterative resolver + that attempts to resolve a query for a domain name in such a zone and + discovers that none of the zone's name servers can provide an answer. + We have observed a recursive name server implementation whose + iterative resolver then verifies the zone's NS RRset in its cache by + querying for the zone's delegation information: it sends a query for + the zone's NS RRset to one of the parent zone's name servers. + + For example, suppose that "example.com" has the following NS RRset: + + example.com. IN NS ns1.example.com. + example.com. IN NS ns2.example.com. + + Upon receipt of a query for "www.example.com" and assuming that + neither "ns1.example.com" nor "ns2.example.com" can provide an + answer, this iterative resolver implementation immediately queries a + "com" zone name server for the "example.com" NS RRset to verify it + has the proper delegation information. This implementation performs + this query to a zone's parent zone for each recursive query it + receives that fails because of a completely unresponsive set of name + servers for the target zone. Consider the effect when a popular zone + experiences a catastrophic failure of all its name servers: now every + recursive query for domain names in that zone sent to this recursive + name server implementation results in a query to the failed zone's + parent name servers. On one occasion when several dozen popular + zones became unreachable, the query load on the com/net name servers + increased by 50%. + + We believe this verification query is not reasonable. Consider the + circumstances: When an iterative resolver is resolving a query for a + domain name in a zone it has not previously searched, it uses the + list of name servers in the referral from the target zone's parent. + If on its first attempt to search the target zone, none of the name + servers in the referral is reachable, a verification query to the + parent is pointless: this query to the parent would come so quickly + on the heels of the referral that it would be almost certain to + contain the same list of name servers. The chance of discovering any + new information is slim. + + The other possibility is that the iterative resolver successfully + + + +Larson & Barber Expires April 27, 2005 [Page 5] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + contacts one of the target zone's name servers and then caches the NS + RRset from the authority section of a response, the proper behavior + according to section 5.4.1 of RFC 2181 [4], because the NS RRset from + the target zone is more trustworthy than delegation information from + the parent zone. If, while processing a subsequent recursive query, + the iterative resolver discovers that none of the name servers + specified in the cached NS RRset is available or authoritative, + querying the parent would be wrong. An NS RRset from the parent zone + would now be less trustworthy than data already in the cache. + + For this query of the parent zone to be useful, the target zone's + entire set of name servers would have to change AND the former set of + name servers would have to be deconfigured or decommissioned AND the + delegation information in the parent zone would have to be updated + with the new set of name servers, all within the TTL of the target + zone's NS RRset. We believe this scenario is uncommon: + administrative best practices dictate that changes to a zone's set of + name servers happen gradually when at all possible, with servers + removed from the NS RRset left authoritative for the zone as long as + possible. The scenarios that we can envision that would benefit from + the parent requery behavior do not outweigh its damaging effects. + +2.1.1 Recommendation + + An iterative resolver MUST NOT send a query for the NS RRset of a + non-responsive zone to any of the name servers for that zone's parent + zone. For the purposes of this injunction, a non-responsive zone is + defined as a zone for which every name server listed in the zone's NS + RRset: + 1. is not authoritative for the zone (i.e., lame), or, + 2. returns a server failure response (RCODE=2), or, + 3. is dead or unreachable according to section 7.2 of RFC 2308 [5]. + +2.2 Repeated queries to lame servers + + Section 2.1 describes a catastrophic failure: when every name server + for a zone is unable to provide an answer for one reason or another. + A more common occurrence is when a subset of a zone's name servers + are unavailable or misconfigured. Different failure modes have + different expected durations. Some symptoms indicate problems that + are potentially transient; for example, various types of ICMP + unreachable messages because a name server process is not running or + a host or network is unreachable, or a complete lack of a response to + a query. Such responses could be the result of a host rebooting or + temporary outages; these events don't necessarily require any human + intervention and can be reasonably expected to be temporary. + + Other symptoms clearly indicate a condition requiring human + + + +Larson & Barber Expires April 27, 2005 [Page 6] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + intervention, such as lame server: if a name server is misconfigured + and not authoritative for a zone delegated to it, it is reasonable to + assume that this condition has potential to last longer than + unreachability or unresponsiveness. Consequently, repeated queries + to known lame servers are not useful. In this case of a condition + with potential to persist for a long time, a better practice would be + to maintain a list of known lame servers and avoid querying them + repeatedly in a short interval. + +2.2.1 Recommendation + + Iterative resolvers SHOULD cache name servers that they discover are + not authoritative for zones delegated to them (i.e. lame servers). + Lame servers MUST be cached against the specific query tuple . Zone name can be derived from the + owner name of the NS record that was referenced to query the name + server that was discovered to be lame. Implementations that perform + lame server caching MUST refrain from sending queries to known lame + servers based on a time interval from when the server is discovered + to be lame. A minimum interval of thirty minutes is RECOMMENDED. + +2.3 Inability to follow multiple levels of out-of-zone glue + + Some iterative resolver implementations are unable to follow more + than one level of out-of-zone glue. For example, consider the + following delegations: + + foo.example. IN NS ns1.example.com. + foo.example. IN NS ns2.example.com. + + example.com. IN NS ns1.test.example.net. + example.com. IN NS ns2.test.example.net. + + test.example.net. IN NS ns1.test.example.net. + test.example.net. IN NS ns2.test.example.net. + + An iterative resolver resolving the name "www.foo.example" must + follow two levels of indirection, first obtaining address records for + "ns1.test.example.net" or "ns2.test.example.net" in order to obtain + address records for "ns1.example.com" or "ns2.example.com" in order + to query those name servers for the address records of + "www.foo.example". While this situation may appear contrived, we + have seen multiple similar occurrences and expect more as new generic + top-level domains (gTLDs) become active. We anticipate many zones in + new gTLDs will use name servers in other gTLDs, increasing the amount + of inter-zone glue. + + + + + +Larson & Barber Expires April 27, 2005 [Page 7] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +2.3.1 Recommendation + + Clearly constructing a delegation that relies on multiple levels of + out-of-zone glue is not a good administrative practice. This issue + could be mitigated with an operational injunction in an RFC to + refrain from construction of such delegations. In our opinion the + practice is widespread enough to merit clarifications to the DNS + protocol specification to permit it on a limited basis. + + Iterative resolvers SHOULD be able to handle at least three levels of + indirection resulting from out-of-zone glue. + +2.4 Aggressive retransmission when fetching glue + + When an authoritative name server responds with a referral, it + includes NS records in the authority section of the response. + According to the algorithm in section 4.3.2 of RFC 1034 [2], the name + server should also "put whatever addresses are available into the + additional section, using glue RRs if the addresses are not available + from authoritative data or the cache." Some name server + implementations take this address inclusion a step further with a + feature called "glue fetching". A name server that implements glue + fetching attempts to include address records for every NS record in + the authority section. If necessary, the name server issues multiple + queries of its own to obtain any missing address records. + + Problems with glue fetching can arise in the context of + "authoritative-only" name servers, which only serve authoritative + data and ignore requests for recursion. Such an entity will not + normally generate any queries of its own. Instead it answers + non-recursive queries from iterative resolvers looking for + information in zones it serves. With glue fetching enabled, however, + an authoritative server invokes an iterative resolver to look up an + unknown address record to complete the additional section of a + response. + + We have observed situations where the iterative resolver of a + glue-fetching name server can send queries that reach other name + servers, but is apparently prevented from receiving the responses. + For example, perhaps the name server is authoritative-only and + therefore its administrators expect it to receive only queries and + not responses. Perhaps unaware of glue fetching and presuming that + the name server's iterative resolver will generate no queries, its + administrators place the name server behind a network device that + prevents it from receiving responses. If this is the case, all + glue-fetching queries will go answered. + + We have observed name server implementations whose iterative + + + +Larson & Barber Expires April 27, 2005 [Page 8] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + resolvers retry excessively when glue-fetching queries are + unanswered. A single com/net name server has received hundreds of + queries per second from a single such source. Judging from the + specific queries received and based on additional analysis, we + believe these queries result from overly aggressive glue fetching. + +2.4.1 Recommendation + + Implementers whose name servers support glue fetching SHOULD take + care to avoid sending queries at excessive rates. Implementations + SHOULD support throttling logic to detect when queries are sent but + no responses are received. + +2.5 Aggressive retransmission behind firewalls + + A common occurrence and one of the largest sources of repeated + queries at the com/net and root name servers appears to result from + resolvers behind misconfigured firewalls. In this situation, an + iterative resolver is apparently allowed to send queries through a + firewall to other name servers, but not receive the responses. The + result is more queries than necessary because of retransmission, all + of which are useless because the responses are never received. Just + as with the glue-fetching scenario described in Section 2.4, the + queries are sometimes sent at excessive rates. To make matters + worse, sometimes the responses, sent in reply to legitimate queries, + trigger an alarm on the originator's intrusion detection system. We + are frequently contacted by administrators responding to such alarms + who believe our name servers are attacking their systems. + + Not only do some resolvers in this situation retransmit queries at an + excessive rate, but they continue to do so for days or even weeks. + This scenario could result from an organization with multiple + recursive name servers, only a subset of whose iterative resolvers' + traffic is improperly filtered in this manner. Stub resolvers in the + organization could be configured to query multiple recursive name + servers. Consider the case where a stub resolver queries a filtered + recursive name server first. The iterative resolver of this + recursive name server sends one or more queries whose replies are + filtered, so it can't respond to the stub resolver, which times out. + Then the stub resolver retransmits to a recursive name server that is + able to provide an answer. Since resolution ultimately succeeds the + underlying problem might not be recognized or corrected. A popular + stub resolver implementation has a very aggressive retransmission + schedule, including simultaneous queries to multiple recursive name + servers, which could explain how such a situation could persist + without being detected. + + + + + +Larson & Barber Expires April 27, 2005 [Page 9] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +2.5.1 Recommendation + + The most obvious recommendation is that administrators SHOULD take + care not to place iterative resolvers behind a firewall that allows + queries to pass through but not the resulting replies. + + Iterative resolvers SHOULD take care to avoid sending queries at + excessive rates. Implementations SHOULD support throttling logic to + detect when queries are sent but no responses are received. + +2.6 Misconfigured NS records + + Sometimes a zone administrator forgets to add the trailing dot on the + domain names in the RDATA of a zone's NS records. Consider this + fragment of the zone file for "example.com": + + $ORIGIN example.com. + example.com. 3600 IN NS ns1.example.com ; Note missing + example.com. 3600 IN NS ns2.example.com ; trailing dots + + The zone's authoritative servers will parse the NS RDATA as + "ns1.example.com.example.com" and "ns2.example.com.example.com" and + return NS records with this incorrect RDATA in responses, including + typically the authority section of every response containing records + from the "example.com" zone. + + Now consider a typical sequence of queries. An iterative resolver + attempting to resolve address records for "www.example.com" with no + cached information for this zone will query a "com" authoritative + server. The "com" server responds with a referral to the + "example.com" zone, consisting of NS records with valid RDATA and + associated glue records. (This example assumes that the + "example.com" zone delegation information is correct in the "com" + zone.) The iterative resolver caches the NS RRset from the "com" + server and follows the referral by querying one of the "example.com" + authoritative servers. This server responds with the + "www.example.com" address record in the answer section and, + typically, the "example.com" NS records in the authority section and, + if space in the message remains, glue address records in the + additional section. According to Section 5.4 of RFC 2181 [4], NS + records in the authority section of an authoritative answer are more + trustworthy than NS records from the authority section of a + non-authoritative answer. Thus the "example.com" NS RRset just + received from the "example.com" authoritative server overrides the + "example.com" NS RRset received moments ago from the "com" + authoritative server. + + But the "example.com" zone contains the erroneous NS RRset as shown + + + +Larson & Barber Expires April 27, 2005 [Page 10] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + in the example above. Subsequent queries for names in "example.com" + will cause the iterative resolver to attempt to use the incorrect NS + records and so it will try to resolve the nonexistent names + "ns1.example.com.example.com" and "ns2.example.com.example.com". In + this example, since all of the zone's name servers are named in the + zone itself (i.e., "ns1.example.com.example.com" and + "ns2.example.com.example.com" both end in "example.com") and all are + bogus, the iterative resolver cannot reach any "example.com" name + servers. Therefore attempts to resolve these names result in address + record queries to the "com" authoritative servers. Queries for such + obviously bogus glue address records occur frequently at the com/net + name servers. + +2.6.1 Recommendation + + An authoritative server can detect this situation. A trailing dot + missing from an NS record's RDATA always results by definition in a + name server name that exists somewhere under the SOA of the zone the + NS record appears in. Note that further levels of delegation are + possible, so a missing trailing dot could inadvertently create a name + server name that actually exists in a subzone. But in any case, the + address record must still be present in this zone, either as + authoritative data or glue. + + An authoritative name server SHOULD report an error when one of a + zone's NS records references a name server below the zone's SOA when + a corresponding address record does not exist in the zone. + +2.7 Name server records with zero TTL + + Sometimes a popular com/net subdomain's zone is configured with a TTL + of zero on the zone's NS records, which prohibits these records from + being cached and will result in a higher query volume to the zone's + authoritative servers. The zone's administrator should understand + the consequences of such a configuration and provision resources + accordingly. A zero TTL on the zone's NS RRset, however, carries + additional consequences beyond the zone itself: if an iterative + resolver cannot cache a zone's NS records because of a zero TTL, it + will be forced to query that zone's parent's name servers each time + it resolves a name in the zone. The com/net authoritative servers do + see an increased query load when a popular com/net subdomain's zone + is configured with a TTL of zero on the zone's NS records. + + A zero TTL on an RRset expected to change frequently is extreme but + permissible. A zone's NS RRset is a special case, however, because + changes to it must be coordinated with the zone's parent. In most + zone parent/child relationships we are aware of, there is typically + some delay involved in effecting changes. Further, changes to the + + + +Larson & Barber Expires April 27, 2005 [Page 11] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + set of a zone's authoritative name servers (and therefore to the + zone's NS RRset) are typically relatively rare: providing reliable + authoritative service requires a reasonably stable set of servers. + Therefore an extremely low or zero TTL on a zone's NS RRset rarely + makes sense, except in anticipation of an upcoming change. In this + case, when the zone's administrator has planned a change and does not + want iterative resolvers throughout the Internet to cache the NS + RRset for a long period of time, a low TTL is reasonable. + +2.7.1 Recommendation + + Because of the additional load placed on a zone's parent's + authoritative servers resulting from a zero TTL on a zone's NS RRset, + under such circumstances authoritative name servers SHOULD issue a + warning when loading a zone or refuse to load the zone altogether. + +2.8 Unnecessary dynamic update messages + + The UPDATE message specified in RFC 2136 [6] allows an authorized + agent to update a zone's data on an authoritative name server using a + DNS message sent over the network. Consider the case of an agent + desiring to add a particular resource record. Because of zone cuts, + the agent does not necessarily know the proper zone to which the + record should be added. The dynamic update process requires that the + agent determine the appropriate zone so the UPDATE message can be + sent to one of the zone's authoritative servers (typically the + primary master as specified in the zone's SOA MNAME field). + + The appropriate zone to update is the closest enclosing zone, which + cannot be determined only by inspecting the domain name of the record + to be updated, since zone cuts can occur anywhere. One way to + determine the closest enclosing zone entails walking up the name + space tree by sending repeated UPDATE messages until success. For + example, consider an agent attempting to add an address record with + the name "foo.bar.example.com". The agent could first attempt to + update the "foo.bar.example.com" zone. If the attempt failed, the + update could be directed to the "bar.example.com" zone, then the + "example.com" zone, then the "com" zone, and finally the root zone. + + A popular dynamic agent follows this algorithm. The result is many + UPDATE messages received by the root name servers, the com/net + authoritative servers, and presumably other TLD authoritative + servers. A valid question is why the algorithm proceeds to send + updates all the way to TLD and root name servers. This behavior is + not entirely unreasonable: in enterprise DNS architectures with an + "internal root" design, there could conceivably be private, + non-public TLD or root zones that would be the appropriate targets + for a dynamic update. + + + +Larson & Barber Expires April 27, 2005 [Page 12] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + A significant deficiency with this algorithm is that knowledge of a + given UPDATE message's failure is not helpful in directing future + UPDATE messages to the appropriate servers. A better algorithm would + be to find the closest enclosing zone by walking up the name space + with queries for SOA or NS rather than "probing" with UPDATE + messages. Once the appropriate zone is found, an UPDATE message can + be sent. In addition, the results of these queries can be cached to + aid in determining closest enclosing zones for future updates. Once + the closest enclosing zone is determined with this method, the update + will either succeed or fail and there is no need to send further + updates to higher-level zones. The important point is that walking + up the tree with queries yields cacheable information, whereas + walking up the tree by sending UPDATE messages does not. + +2.8.1 Recommendation + + Dynamic update agents SHOULD send SOA or NS queries to progressively + higher-level zones to find the closest enclosing zone for a given + name to update. Only after the appropriate zone is found should the + client send an UPDATE message to one of the zone's authoritative + servers. Update clients SHOULD NOT "probe" using UPDATE messages by + walking up the tree to progressively higher-level zones. + +2.9 Queries for domain names resembling IP addresses + + The root name servers receive a significant number of A record + queries where the qname is an IP address. The source of these + queries is unknown. It could be attributed to situations where a + user believes an application will accept either a domain name or an + IP address in a given configuration option. The user enters an IP + address, but the application assumes any input is a domain name and + attempts to resolve it, resulting in an A record lookup. There could + also be applications that produce such queries in a misguided attempt + to reverse map IP addresses. + + These queries result in Name Error (RCODE=3) responses. An iterative + resolver can negatively cache such responses, but each response + requires a separate cache entry, i.e., a negative cache entry for the + domain name "192.0.2.1" does not prevent a subsequent query for the + domain name "192.0.2.2". + +2.9.1 Recommendation + + It would be desirable for the root name servers not to have to answer + these queries: they unnecessarily consume CPU resources and network + bandwidth. One possibility is for iterative resolver implementations + to produce the Name Error response directly. We suggest that + implementors consider the option of synthesizing Name Error responses + + + +Larson & Barber Expires April 27, 2005 [Page 13] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + at the iterative resolver. The server could claim authority for + synthesized TLD zones corresponding to the first octet of every + possible IP address, e.g. 1., 2., through 255. This behavior could + be configurable in the (probably unlikely) event that numeric TLDs + are ever put into use. + + Another option is to delegate these numeric TLDs from the root zone + to a separate set of servers to absorb the traffic. The "black hole + servers" used by the the AS 112 +Project [8], which are currently + delegated the in-addr.arpa zones corresponding to RFC 1918 [7] + private use address space, would be a possible choice to receive + these delegations. + +2.10 Misdirected recursive queries + + The root name servers receive a significant number of recursive + queries (i.e., queries with the RD bit set in the header). Since + none of the root servers offers recursion, the servers' response in + such a situation ignores the request for recursion and the response + probably does not contain the data the querier anticipated. Some of + these queries result from users configuring stub resolvers to query a + root server. (This situation is not hypothetical: we have received + complaints from users when this configuration does not work as + hoped.) Of course, users should not direct stub resolvers to use name + servers that do not offer recursion, but we are not aware of any stub + resolver implementation that offers any feedback to the user when so + configured, aside from simply "not working". + +2.10.1 Recommendation + + When the IP address of a name server that supposedly offers recursion + is configured in a stub resolver using an interactive user interface, + the resolver could send a test query to verify that the server indeed + supports recursion (i.e., verify that the response has the RA bit set + in the header). The user could be immediately notified if the server + is non-recursive. + + The stub resolver could also report an error, either through a user + interface or in a log file, if the queried server does not support + recursion. Error reporting SHOULD be throttled to avoid a + notification or log message for every response from a non-recursive + server. + +2.11 Suboptimal name server selection algorithm + + An entire document could be devoted to the topic of problems with + different implementations of the recursive resolution algorithm. The + entire process of recursion is woefully under specified, requiring + + + +Larson & Barber Expires April 27, 2005 [Page 14] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + each implementor to design an algorithm. Sometimes implementors make + poor design choices that could be avoided if a suggested algorithm + and best practices were documented, but that is a topic for another + document. + + Some deficiencies cause significant operational impact and are + therefore worth mentioning here. One of these is name server + selection by an iterative resolver. When an iterative resolver wants + to contact one of a zone's authoritative name servers, how does it + choose from the NS records listed in the zone's NS RRset? If the + selection mechanism is suboptimal, queries are not spread evenly + among a zone's authoritative servers. The details of the selection + mechanism are up to the implementor, but we offer some suggestions. + +2.11.1 Recommendation + + This list is not conclusive, but reflects the changes that would + produce the most impact in terms of reducing disproportionate query + load among a zone's authoritative servers. I.e., these changes would + help spread the query load evenly. + o Do not make assumptions based on NS RRset order: all NS RRs SHOULD + be treated equally. (In the case of the "com" zone, for example, + most of the root servers return the NS record for + "a.gtld-servers.net" first in the authority section of referrals. + Apparently as a result, this server receives disproportionately + more traffic than the other 12 authoritative servers for "com".) + o Use all NS records in an RRset. (For example, we are aware of + implementations that hard-coded information for a subset of the + root servers.) + o Maintain state and favor the best-performing of a zone's + authoritative servers. A good definition of performance is + response time. Non-responsive servers can be penalized with an + extremely high response time. + o Do not lock onto the best-performing of a zone's name servers. An + iterative resolver SHOULD periodically check the performance of + all of a zone's name servers to adjust its determination of the + best-performing one. + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 15] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +3. IANA considerations + + There are no new IANA considerations introduced by this memo. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 16] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +4. Security considerations + + Name server and resolver misbehaviors identical or similar to those + discussed in this document expose the root and TLD name servers to + increased risk of both intentional and unintentional denial of + service. + + We believe that implementation of the recommendations offered in this + document will reduce the amount of unnecessary traffic seen at root + and TLD name servers, thus reducing the opportunity for an attacker + to use such queries to his or her advantage. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 17] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +5. Internationalization considerations + + We do not believe this document introduces any new + internationalization considerations to the DNS protocol + specification. + +6 Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [3] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [4] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [5] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC + 2308, March 1998. + + [6] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April + 1997. + + [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. + Lear, "Address Allocation for Private Internets", BCP 5, RFC + 1918, February 1996. + + [8] + + +Authors' Addresses + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 18] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + Piet Barber + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: pbarber@verisign.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 19] + +Internet-Draft Observed DNS Resolution Misbehavior October 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. + + + + +Larson & Barber Expires April 27, 2005 [Page 20] + + diff --git a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-02.txt b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-03.txt similarity index 68% rename from doc/draft/draft-ietf-dnsop-dnssec-operational-practices-02.txt rename to doc/draft/draft-ietf-dnsop-dnssec-operational-practices-03.txt index c8006c2c49..0f713dd77d 100644 --- a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-02.txt +++ b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-03.txt @@ -1,21 +1,20 @@ + DNSOP O. Kolkman Internet-Draft RIPE NCC -Expires: April 11, 2005 R. Gieben +Expires: June 23, 2005 R. Gieben NLnet Labs - October 11, 2004 + December 23, 2004 DNSSEC Operational Practices - draft-ietf-dnsop-dnssec-operational-practices-02.txt + draft-ietf-dnsop-dnssec-operational-practices-03.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 + 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 @@ -34,109 +33,120 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 11, 2005. + This Internet-Draft will expire on June 23, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). + 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. + This document describes a set of practices for operating the DNS with + security extensions (DNSSEC). The target audience is zone + administrators deploying DNSSEC. + + The document discusses operational aspects of using keys and + signatures in the DNS. It discusses issues as key generation, key + storage, signature generation, key rollover and related policies. -Kolkman & Gieben Expires April 11, 2005 [Page 1] + +Kolkman & Gieben Expires June 23, 2005 [Page 1] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 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 Separation . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 9 - 3.3 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 9 - 3.3.1 Difference Between ZSK and KSK Rollovers . . . . . . . 10 - 3.3.2 Zone-signing Key Rollovers . . . . . . . . . . . . . . 10 - 3.3.3 Key-signing Key Rollovers . . . . . . . . . . . . . . 14 - 3.3.4 Automated Key Rollovers . . . . . . . . . . . . . . . 15 - 4. Planning for Emergency Key Rollover . . . . . . . . . . . . . 15 - 4.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 16 - 4.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 16 - 4.3 Compromises of Keys Anchored in Resolvers . . . . . . . . 16 - 5. Parental Policies . . . . . . . . . . . . . . . . . . . . . . 17 - 5.1 Initial Key Exchanges and Parental Policies - Considerations . . . . . . . . . . . . . . . . . . . . . . 17 - 5.2 Storing Keys So Hashes Can Be Regenerated . . . . . . . . 17 - 5.3 Security Lameness Checks . . . . . . . . . . . . . . . . . 18 - 5.4 DS Signature Validity Period . . . . . . . . . . . . . . . 18 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 - 8.2 Informative References . . . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 - A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 20 - B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 21 - C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 22 - D. Document Details and Changes . . . . . . . . . . . . . . . . . 23 - D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 23 - D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 23 - Intellectual Property and Copyright Statements . . . . . . . . 25 + 1.2 Time Definitions . . . . . . . . . . . . . . . . . . . . . 4 + 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 4 + 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 5 + 3.1 Zone and Key Signing Keys . . . . . . . . . . . . . . . . 5 + 3.1.1 Motivations for the KSK and ZSK Separation . . . . . . 5 + 3.1.2 KSKs for high level zones . . . . . . . . . . . . . . 6 + 3.2 Randomness . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.3 Key Effectivity Period . . . . . . . . . . . . . . . . . . 7 + 3.4 Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 8 + 3.5 Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.6 Private Key Storage . . . . . . . . . . . . . . . . . . . 9 + 4. Signature generation, Key Rollover and Related Policies . . . 10 + 4.1 Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 10 + 4.1.1 Time Considerations . . . . . . . . . . . . . . . . . 10 + 4.2 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 12 + 4.2.1 Difference Between ZSK and KSK Rollovers . . . . . . . 12 + 4.2.2 Zone-signing Key Rollovers . . . . . . . . . . . . . . 13 + 4.2.3 Key-signing Key Rollovers . . . . . . . . . . . . . . 17 + 4.2.4 Automated Key Rollovers . . . . . . . . . . . . . . . 18 + 4.3 Planning for Emergency Key Rollover . . . . . . . . . . . 18 + 4.3.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . 19 + 4.3.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . 19 + 4.3.3 Compromises of Keys Anchored in Resolvers . . . . . . 19 + 4.4 Parental Policies . . . . . . . . . . . . . . . . . . . . 20 + 4.4.1 Initial Key Exchanges and Parental Policies + Considerations . . . . . . . . . . . . . . . . . . . . 20 + 4.4.2 Storing Keys So Hashes Can Be Regenerated . . . . . . 20 + 4.4.3 Security Lameness . . . . . . . . . . . . . . . . . . 21 + 4.4.4 DS Signature Validity Period . . . . . . . . . . . . . 21 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 22 + 7.2 Informative References . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 + A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 24 + B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 24 + C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 25 + D. Document Details and Changes . . . . . . . . . . . . . . . . . 26 + D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 27 + D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 27 + D.3 draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 27 + D.4 draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 27 + Intellectual Property and Copyright Statements . . . . . . . . 28 - - - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 2] +Kolkman & Gieben Expires June 23, 2005 [Page 2] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 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 representing 'Best Current Practices'. + and system administrators gained experience about operating the DNS + with security extensions (DNSSEC). 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 representing '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 + The structure of this document is as follows. In Section 2 we + discuss the importance of keeping the "chain of trust" intact. + Aspects of key generation and storage of private keys are discussed + in Section 3, the focus in this section is mainly on the private part + of the key(s). Section 4 describes considerations concerning the + public part of the keys. Since these public keys appear in the DNS + one has to take into account all kinds of timing issues, these are + discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the + rollover, or supersession, of keys. Finally Section 4.4 discusses + considerations on how parents deal with their children's public keys + in order to maintain chains of trust. + + 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 [7] language does not apply. + no protocol specifications, the RFC2119 [6] language does not apply. + + This document obsoletes RFC2541 [1] 1.1 The Use of the Term 'key' @@ -150,7 +160,43 @@ Internet-Draft DNSSEC Operational Practices October 2004 in the DNSKEY resource record and that it is the public part that is used in key-exchanges. -1.2 Keeping the Chain of Trust Intact + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 3] + +Internet-Draft DNSSEC Operational Practices December 2004 + + +1.2 Time Definitions + + In this document we will be using a number of time related terms. + 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. + 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. + After one stopped publishing an RRSIG in a zone file it will + take a while before the RRSIG has actually been removed from + the DNS. + o "Key effectivity period" + The period during a key pair is effective. This period is + defined as the time between the first inception time stamp and + the last expiration date of any signature made with this key. + The key effectivity period can span multiple signature validity + intervals. + o "Maximum/Minimum Zone TTL" + The maximum or minimum value of the TTLs from the complete set + of RRs in a zone. + +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 @@ -160,14 +206,6 @@ Internet-Draft DNSSEC Operational Practices October 2004 As mentioned in the introduction, the procedures herein are intended to ensure maintenance of zones, such as resigning or key rollovers, - - - -Kolkman & Gieben Expires April 11, 2005 [Page 3] - -Internet-Draft DNSSEC Operational Practices October 2004 - - be transparent to the verifying clients on the Internet. Administrators of secured zones will have to keep in mind that data @@ -179,6 +217,14 @@ Internet-Draft DNSSEC Operational Practices October 2004 For the verifying clients it is important that data from secured zones can be used to build chains of trust regardless of whether the + + + +Kolkman & Gieben Expires June 23, 2005 [Page 4] + +Internet-Draft DNSSEC Operational Practices December 2004 + + 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 @@ -188,59 +234,308 @@ Internet-Draft DNSSEC Operational Practices October 2004 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 replacing the compromised keys - as soon as possible, must be made. + as soon as possible, must be made. Then zone administrators will + have to make a trade off between keeping the chain of trust intact - + thereby allowing for attacks with the compromised key - or to + deliberately break the chain of trust and making secured sub domains + invisible to security aware resolvers. Also see Section 4.3. - The zone administrator will have to make a trade off between keeping - the chain of trust intact - thereby allowing for attacks with the - compromised key - or to deliberately break the chain of trust and - making secured sub domains invisible to security aware resolvers. - Also see Section 4. +3. Keys Generation and Storage -2. Time in DNSSEC + This section describes a number of considerations with respect to the + security of keys. It deals with the generation, effectivity period, + size and storage of private keys. - Without DNSSEC all times in DNS are relative. The SOA's refresh, +3.1 Zone and Key Signing Keys + + The DNSSEC validation protocol does not distinguish between DNSKEYs. + All DNSKEYs can be used during the validation. In practice operators + use Key Singing and Zone Signing Keys and use the so called SEP flag + to distinguish between them during operations. The dynamics and + considerations are discussed below. + + 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 RR set 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 parent 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 [2] to be set on KSKs. + +3.1.1 Motivations for the KSK and ZSK Separation + + Differentiating between the KSK to ZSK functions has several + advantages: + + o The KSK can be made stronger (i.e. using more bits in the key + material). This has little operational impact since it is only + used to sign a small fraction of the zone data. + + + +Kolkman & Gieben Expires June 23, 2005 [Page 5] + +Internet-Draft DNSSEC Operational Practices December 2004 + + + o As the KSK is only used to sign a key set, which is most probably + updated less frequently than other data in the zone, it can be + stored separately from and in a safer location than the ZSK. + o A KSK can have a longer key effectivity period. + o No parent/child interaction is required when ZSKs are updated. + + The KSK is used less than ZSK, once a key set is signed with the KSK + all the keys in the key set can be used as ZSK. If a ZSK is + compromised, it can be simply dropped from the key set. The new key + set 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. + + 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 "Signature + Validity Periods" in the order of days. + + The key-signing key is only to be used to sign the DNSKEY RRs in a + zone. If a key-signing key is to be rolled over, there will be + interactions with parties other than the zone administrator. These + can include the registry of the parent zone or administrators of + verifying resolvers that have the particular key configured as + trusted entry points. Hence, the key effectivity period 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 effectivity of the order of a few months so + that a key rollover remains an operational routine. + +3.1.2 KSKs for high level zones + + Higher level zones are generally more sensitive than lower level + zones. Anyone controlling or breaking the security of a zone thereby + obtains authority over all of its sub domains (except in the case of + resolvers that have locally configured the public key of a sub + domain). Therefore, extra care should be taken with high level zones + and strong keys used. + + The root zone is the most critical of all zones. Someone controlling + or compromising the security of the root zone would control the + entire DNS name space of all resolvers using that root zone (except + in the case of resolvers that have locally configured the public key + of a sub domain). Therefore, the utmost care must be taken in the + securing of the root zone. The strongest and most carefully handled + keys should be used. The root zone private key should always be kept + + + +Kolkman & Gieben Expires June 23, 2005 [Page 6] + +Internet-Draft DNSSEC Operational Practices December 2004 + + + off line. + + Many resolvers will start at a root server for their access to and + authentication of DNS data. Securely updating the trust anchors an + enormous population of resolvers around the world will be extremely + difficult. + +3.2 Randomness + + Careful generation of all keys is a sometimes overlooked but + absolutely essential element in any cryptographically secure system. + The strongest algorithms used with the longest keys are still of no + use if an adversary can guess enough to lower the size of the likely + key space so that it can be exhaustively searched. Technical + suggestions for the generation of random keys will be found in + RFC1750 [5]. One should carefully assess if the random number + generator used during key generation adheres to these suggestions. + + Keys with a long effectivity period are particularly sensitive as + they will represent a more valuable target and be subject to attack + for a longer time than short period keys. It is strongly recommended + that long term key generation occur off-line in a manner isolated + from the network via an air gap or, at a minimum, high level secure + hardware. + +3.3 Key Effectivity Period + + For various reasons keys in DNSSEC need to be changed once in a + while. The longer a key is in use, the greater the probability that + it will have been compromised through carelessness, accident, + espionage, or cryptanalysis. Furthermore when key rollovers are too + rare an event, they will not become part of the operational habit and + there is risk that no body on-site will remember the procedure for + rollover when the need is there. + + For Key Signing Keys a reasonable key effectivity period is 13 + months, with the intent to replace them after 12 months. An intended + key effectivity period of a month is reasonable for Zone Signing + Keys. + + Using 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. + + Key effectivity periods can be made very short, as in the order of a + few minutes. But when replacing keys one has to take the + considerations from Section 4.1 and Section 4.2 into account. + + + +Kolkman & Gieben Expires June 23, 2005 [Page 7] + +Internet-Draft DNSSEC Operational Practices December 2004 + + +3.4 Key Algorithm + + There are currently three different types of algorithms that can be + used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter + is fairly new and still needs to be standardized for usage in DNSSEC. + + RSA has been developed in an open and transparent manner. As the + patent on RSA expired in 2000, its use is now also free. + + DSA has been developed by NIST. The creation of signatures creation + is roughly the same speed as with RSA, but is 10 to 40 times as slow + for verification [11]. + + We suggest the use of RSA/SHA-1 as the preferred algorithm for the + key. 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.5 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 [10] 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 cryptographic + systems. For details we refer to the original paper. + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 8] + +Internet-Draft DNSSEC Operational Practices December 2004 + + + Year RSA Key Sizes Year RSA Key Sizes + + 2000 952 2015 1613 + 2001 990 2016 1664 + 2002 1028 2017 1717 + 2003 1068 2018 1771 + 2004 1108 2019 1825 + + + 2005 1149 2020 1881 + 2006 1191 2021 1937 + 2007 1235 2022 1995 + 2008 1279 2023 2054 + 2009 1323 2024 2113 + + + 2026 2236 2025 2174 + 2010 1369 2027 2299 + 2011 1416 2028 2362 + 2012 1464 2029 2427 + 2013 1513 + 2014 1562 + + For example, should you wish your key to last three years from 2003, + check the RSA key size values for 2006 in this table. In this case + it should be at least 1191 bits. + + When determining a key size one should take into account that a large + key will be slower during generation and verification. For RSA, + verification, the most common operation, will vary roughly with the + square of the key size signing will vary with the cube of the key + size length, and key generation will vary with the fourth power of + the modulus length. Besides larger keys will increase the sizes of + the RRSIG and DNSKEY records and will therefore increase the chance + of DNS UDP packet overflow. Also see Section 3.1.1. + +3.6 Private Key Storage + + It is recommended that, where possible, zone private keys and the + zone file master copy be kept and used in off-line, non-network + connected, physically secure machines only. Periodically an + application can be run to add authentication to a zone by adding + RRSIG and NSEC RRs. Then the augmented file can be transferred, + perhaps by sneaker-net, to the networked zone primary server machine. + + The ideal situation is to have a one way information flow to the + network to avoid the possibility of tampering from the network. + Keeping the zone master file on-line on the network and simply + + + +Kolkman & Gieben Expires June 23, 2005 [Page 9] + +Internet-Draft DNSSEC Operational Practices December 2004 + + + cycling it through an off-line signer does not do this. The on-line + version could still be tampered with if the host it resides on is + compromised. For maximum security, the master copy of the zone file + should be off net and should not be updated based on an unsecured + network mediated communication. + + In general keeping a zone-file off-line will not be practical and the + machines on which zone files are maintained will be connected to a + network. Operators are advised to take security measures to shield + unauthorized access to the master copy. + + For dynamically updated secured zones RFC2137 [7] both the master + copy and the private key that is used to update signatures on updated + RRs will need to be on line. + +4. Signature generation, Key Rollover and Related Policies + +4.1 Time in DNSSEC + + Without DNSSEC all times in DNS are relative. The SOA RR's refresh, retry and expiration timers are counters that are used to determine the time elapsed after a slave server synchronized (or tried to synchronize) with a master server. The Time to Live (TTL) value and - the SOA minimum TTL parameter [8] are used to determine how long a + the SOA RR minimum TTL parameter [8] are used to determine how long a forwarder should cache data after it has been fetched from an authoritative server. By using a signature validity period, 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. - The following definitions apply: - o "Signature validity period" - - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 4] - -Internet-Draft DNSSEC Operational Practices October 2004 - - - 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. - 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 all signatures are refreshed at zone (re)signing then the - signature publication period is equal to the signature validity - period. - o "Maximum/Minimum Zone TTL" - The maximum or minimum value of the TTLs from the complete set - of RRs in a zone. - -2.2 Time Considerations +4.1.1 Time Considerations Because of the expiration of signatures, one should consider the following. @@ -249,12 +544,23 @@ Internet-Draft DNSSEC Operational Practices October 2004 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. Section - 7.1 [5] suggests that "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". As a result query load - on authoritative servers would peak at signature expiration - time, as this is also the time at which records simultaneously - expire from caches. + 7.1 of [3] suggests that "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". As a result + query load on authoritative servers would peak at signature + expiration time, as this is also the time at which records + simultaneously expire from caches. + + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 10] + +Internet-Draft DNSSEC Operational Practices December 2004 + + 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. @@ -265,21 +571,13 @@ Internet-Draft DNSSEC Operational Practices October 2004 caches. This in turn may lead to peaks in the load on authoritative servers. o We suggest the minimum zone TTL to be long enough to both fetch - and verify all the RRs in the authentication chain. A low TTL can - cause two problems: + and verify all the RRs in the authentication chain. A low TTL + could cause two problems: 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 set that is returned for the initial - - - -Kolkman & Gieben Expires April 11, 2005 [Page 5] - -Internet-Draft DNSSEC Operational Practices October 2004 - - query. 2. Frequent verification causes load on recursive nameservers. Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from @@ -309,6 +607,16 @@ Internet-Draft DNSSEC Operational Practices October 2004 data served by the particular slave servers while security aware resolvers will experience problems because of answers being marked as bogus. + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 11] + +Internet-Draft DNSSEC Operational Practices December 2004 + + 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 @@ -323,186 +631,16 @@ Internet-Draft DNSSEC Operational Practices October 2004 not DNSSEC specific but may influence the choice of your signature validity intervals. -3. Keys - - The DNSSEC validation protocol does not distinguish between DNSKEYs. - All DNSKEYs can be used during the validation. In practice operators - use Key Singing and Zone Signing Keys and use the so called SEP flag - - - -Kolkman & Gieben Expires April 11, 2005 [Page 6] - -Internet-Draft DNSSEC Operational Practices October 2004 - - - to distinguish between them during operations. The dynamics and - considerations are discussed below. - - 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 RR set 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 parent 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 Separation - - Differentiating between the KSK to ZSK functions has several - advantages: - - o The KSK can be made stronger (i.e. using more bits in the key - material). This 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 key set, which is most probably - updated less frequently than other data in the zone, it can be - stored separately from and 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 key set is signed with the KSK - all the keys in the key set can be used as ZSK. If a ZSK is - compromised, it can be simply dropped from the key set. The new key - set 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. - - 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 "Signature - Validity Periods" in the order of days. - - The key-signing key is only to be used to sign the DNSKEY RRs in a - zone. If a key-signing key is to be rolled over, there will be - interactions with parties other than the zone administrator. These - can include the registry of the parent zone or administrators of - verifying resolvers that have the particular key configured as - - - -Kolkman & Gieben Expires April 11, 2005 [Page 7] - -Internet-Draft DNSSEC Operational Practices October 2004 - - - 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. - -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 - - There are currently three different types of algorithms that can be - used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter - is fairly new and still needs to be standardized for usage in DNSSEC. - - RSA has been developed in an open and transparent manner. As the - patent on RSA expired in 2000, its use is now also free. - - DSA has been developed by NIST. The creation of signatures creation - is roughly the same speed as with RSA, but is 10 to 40 times as slow - for verification [11]. - - We suggest the use of RSA/SHA-1 as the preferred algorithm for the - key. 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. - - - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 8] - -Internet-Draft DNSSEC Operational Practices October 2004 - - -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 [10] 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 cryptographic - systems. For details we refer to the original paper. - - - Year RSA Key Sizes Year RSA Key Sizes - - 2000 952 2015 1613 - 2001 990 2016 1664 - 2002 1028 2017 1717 - 2003 1068 2018 1771 - 2004 1108 2019 1825 - - - 2005 1149 2020 1881 - 2006 1191 2021 1937 - 2007 1235 2022 1995 - 2008 1279 2023 2054 - 2009 1323 2024 2113 - - - 2026 2236 2025 2174 - 2010 1369 2027 2299 - 2011 1416 2028 2362 - 2012 1464 2029 2427 - 2013 1513 - 2014 1562 - - For example, should you wish your key to last three years from 2003, - check the RSA key size values for 2006 in this table. In this case - 1191. - -3.3 Key Rollovers - - A DNSSEC key cannot be used forever (see RFC2541 [2] and Section - 3.2). So key rollovers are a fact of life when using DNSSEC. Zone - administrators who are in the process of rolling their keys have to - 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. - - - -Kolkman & Gieben Expires April 11, 2005 [Page 9] - -Internet-Draft DNSSEC Operational Practices October 2004 +4.2 Key Rollovers + A DNSSEC key cannot be used forever (see Section 3.3). So key + rollovers -- or supersessions, as they are sometimes called -- are a + fact of life when using DNSSEC. Zone administrators who are in the + process of rolling their keys have to 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 @@ -512,11 +650,11 @@ Internet-Draft DNSSEC Operational Practices October 2004 signed with a new key against an old key that lives in a local cache, also resulting in data being marked bogus. -3.3.1 Difference Between ZSK and KSK Rollovers +4.2.1 Difference Between ZSK and KSK Rollovers 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.2.1) and double signature (Section Section 3.3.2.2). + Section 4.2.2.1) and double signature (Section Section 4.2.2.2). As the KSK is used to validate the key set and because the KSK is not changed during a ZSK rollover, a cache is able to validate the new @@ -525,6 +663,16 @@ Internet-Draft DNSSEC Operational Practices October 2004 KSK from DNSKEY1 to DNSKEY2 using the NONE working pre-publish method. + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 12] + +Internet-Draft DNSSEC Operational Practices December 2004 + + normal pre-roll roll after SOA0 SOA1 SOA2 SOA3 @@ -544,25 +692,17 @@ Internet-Draft DNSSEC Operational Practices October 2004 by DNSKEY2. It will then try to validate the key set with DNSKEY1 and will fail. -3.3.2 Zone-signing Key Rollovers +4.2.2 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 key sets 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.2.2, the other uses key pre-publication (Section - 3.3.2.1). The pros, cons and recommendations are described in + in Section 4.2.2.2, the other uses key pre-publication (Section + 4.2.2.1). The pros, cons and recommendations are described in + Section 4.2.2.3. - - -Kolkman & Gieben Expires April 11, 2005 [Page 10] - -Internet-Draft DNSSEC Operational Practices October 2004 - - - Section 3.3.2.3. - -3.3.2.1 Pre-publish key set Rollover +4.2.2.1 Pre-publish key set 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 "pre-publish @@ -574,6 +714,21 @@ Internet-Draft DNSSEC Operational Practices October 2004 as is the case with the double signature ZSK rollover. A small "HOWTO" for this kind of rollover can be found in Appendix B. + + + + + + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 13] + +Internet-Draft DNSSEC Operational Practices December 2004 + + normal pre-roll roll after SOA0 SOA1 SOA2 SOA3 @@ -607,15 +762,6 @@ Internet-Draft DNSSEC Operational Practices October 2004 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. - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 11] - -Internet-Draft DNSSEC Operational Practices October 2004 - - after: DNSKEY 10 is removed from the zone. The key set, now only containing DNSKEY 11 is resigned with the DNSKEY 1. @@ -625,6 +771,20 @@ Internet-Draft DNSSEC Operational Practices October 2004 DNSKEY 12 and again a newer one, numbered 13, in "2nd after": + + + + + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 14] + +Internet-Draft DNSSEC Operational Practices December 2004 + + normal roll after SOA0 SOA2 SOA3 @@ -654,7 +814,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 secure manner and does not need to be 'fetched' every time a zone needs to be signed. -3.3.2.2 Double Signature Zone-signing Key Rollover +4.2.2.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". @@ -667,9 +827,18 @@ Internet-Draft DNSSEC Operational Practices October 2004 -Kolkman & Gieben Expires April 11, 2005 [Page 12] + + + + + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 15] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 normal roll after @@ -715,7 +884,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 during the rollover. New data can be introduced in the zone as long as it is signed with both keys. -3.3.2.3 Pros and Cons of the Schemes +4.2.2.3 Pros and Cons of the Schemes @@ -723,9 +892,9 @@ Internet-Draft DNSSEC Operational Practices October 2004 -Kolkman & Gieben Expires April 11, 2005 [Page 13] +Kolkman & Gieben Expires June 23, 2005 [Page 16] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 Pre-publish-key set rollover: This rollover does not involve signing @@ -733,13 +902,13 @@ Internet-Draft DNSSEC Operational Practices October 2004 the new key is published in the key set and thus available for cryptanalysis attacks. A small disadvantage is that this process requires four steps. Also the pre-publish scheme will not work - for KSKs as explained in Section 3.3. + for KSKs as explained in Section 4.2. 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.3 Key-signing Key Rollovers +4.2.3 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 @@ -779,9 +948,9 @@ Internet-Draft DNSSEC Operational Practices October 2004 -Kolkman & Gieben Expires April 11, 2005 [Page 14] +Kolkman & Gieben Expires June 23, 2005 [Page 17] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 after: DNSKEY1 has been removed. @@ -797,10 +966,10 @@ Internet-Draft DNSSEC Operational Practices October 2004 interaction has not been developed further discussion is out of scope for this document. -3.3.4 Automated Key Rollovers +4.2.4 Automated Key Rollovers As keys must be renewed periodically, there are some motivation to - automate the rollover process (also see [12]) + automate the rollover process. Consider that: o ZSK rollovers are easy to automate as only the local zone is involved. @@ -808,10 +977,10 @@ Internet-Draft DNSSEC Operational Practices October 2004 Data exchange is needed to provide the new keys to the parent, consequently, this data must be authenticated and integrity must be guaranteed in order to avoid attacks on the rollover. - o All time and TTL considerations presented in Section 3.3 apply to + o All time and TTL considerations presented in Section 4.2 apply to an automated rollover. -4. Planning for Emergency Key Rollover +4.3 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 @@ -835,9 +1004,9 @@ Internet-Draft DNSSEC Operational Practices October 2004 -Kolkman & Gieben Expires April 11, 2005 [Page 15] +Kolkman & Gieben Expires June 23, 2005 [Page 18] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 chooses to break the authentication chain to the compromised key, @@ -849,7 +1018,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 where the spoof takes place. -4.1 KSK Compromise +4.3.1 KSK Compromise When the KSK has been compromised the parent must be notified as soon as possible using secure means. The key set of the zone should be @@ -867,7 +1036,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 dispute. An out of band and secure notify mechanism to contact a parent is needed in this case. -4.2 ZSK Compromise +4.3.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 @@ -879,7 +1048,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 compromised key may lead to verification problems. The pre-publication scheme as discussed above minimizes such problems. -4.3 Compromises of Keys Anchored in Resolvers +4.3.3 Compromises of Keys Anchored in Resolvers A key can also be pre-configured in resolvers. For instance, if DNSSEC is successfully deployed the root key will be pre-configured @@ -891,9 +1060,9 @@ Internet-Draft DNSSEC Operational Practices October 2004 -Kolkman & Gieben Expires April 11, 2005 [Page 16] +Kolkman & Gieben Expires June 23, 2005 [Page 19] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 about to be rolled over. This communication will of course need to @@ -904,9 +1073,9 @@ Internet-Draft DNSSEC Operational Practices October 2004 DNS, for example, looking them up on an x.509 secured announcement website. -5. Parental Policies +4.4 Parental Policies -5.1 Initial Key Exchanges and Parental Policies Considerations +4.4.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 @@ -920,7 +1089,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 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 + download tool can make use of the SEP bit [2] to select the proper key from a DNSSEC key set; 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. @@ -932,7 +1101,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 is fetched via the DNS. The parent can never be sure whether the DNSKEY RRs have been spoofed or not. -5.2 Storing Keys So Hashes Can Be Regenerated +4.4.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 @@ -947,12 +1116,12 @@ Internet-Draft DNSSEC Operational Practices October 2004 -Kolkman & Gieben Expires April 11, 2005 [Page 17] +Kolkman & Gieben Expires June 23, 2005 [Page 20] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 -5.3 Security Lameness Checks +4.4.3 Security Lameness Security Lameness is defined as what happens when a parent has a DS RR pointing to a non-existing DNSKEY RR. During key exchange a @@ -966,7 +1135,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 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 +4.4.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 minimizes the time a @@ -976,11 +1145,11 @@ Internet-Draft DNSSEC Operational Practices October 2004 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. + validity periods 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. + The maximum signature validity period of the DS record depends on how + long child zones are willing to be vulnerable after a key compromise. Other considerations, such as how often the zone is (re)signed can also be taken into account. @@ -988,81 +1157,92 @@ Internet-Draft DNSSEC Operational Practices October 2004 good compromise between the operational constraints of the parent and minimizing damage for the child. -6. Security Considerations + In addition to the signature validity period, which sets the lower + bounds on the amount of times the zone owner will need to sign the + zone data and which sets an upper bound to the time a child is + vulnerable after key compromise there is the TTL value on the DS RRs. + By lowering the TTL the authoritative servers will see more queries, + on the other hand a low TTL increases the speed with which new DS RRs + propagate through the DNS. As argued in Section 4.1.1 the TTL should + be a fraction of the signature validity period. + +5. Security Considerations DNSSEC adds data integrity to the DNS. This document tries to assess + + + +Kolkman & Gieben Expires June 23, 2005 [Page 21] + +Internet-Draft DNSSEC Operational Practices December 2004 + + 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 +6. 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 - - - -Kolkman & Gieben Expires April 11, 2005 [Page 18] - -Internet-Draft DNSSEC Operational Practices October 2004 - - - workshops, discussions and try outs. + 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 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, Jelte Jansen. + random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael + Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette + and Olivier Courtay, Sam Weiler, Jelte Jansen. + + Some material in this document has been shamelessly copied from + RFC2541 [1] by Donald Eastlake. Mike StJohns designed the key exchange between parent and child - mentioned in the last paragraph of Section 3.3.3 + mentioned in the last paragraph of Section 4.2.3 - Section 3.3.4 was supplied by G. Guette and O. Courtay. + Section 4.2.4 was supplied by G. Guette and O. Courtay. 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 +7. References -8.1 Normative References +7.1 Normative References - [1] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [2] Eastlake, D., "DNS Security Operational Considerations", RFC + [1] Eastlake, D., "DNS Security Operational Considerations", RFC 2541, March 1999. - [3] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. + [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. - [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. - - [5] Arends, R., "DNS Security Introduction and Requirements", + [3] Arends, R., "DNS Security Introduction and Requirements", draft-ietf-dnsext-dnssec-intro-11 (work in progress), March 2003. - [6] Arends, R., "Protocol Modifications for the DNS Security + [4] Arends, R., "Protocol Modifications for the DNS Security Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in progress), March 2003. -8.2 Informative References - [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement + +Kolkman & Gieben Expires June 23, 2005 [Page 22] + +Internet-Draft DNSSEC Operational Practices December 2004 + + +7.2 Informative References + + [5] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - - -Kolkman & Gieben Expires April 11, 2005 [Page 19] - -Internet-Draft DNSSEC Operational Practices October 2004 - + [7] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC + 2137, April 1997. [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. @@ -1076,10 +1256,6 @@ Internet-Draft DNSSEC Operational Practices October 2004 [11] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", 1996. - [12] Guette, G., "Requirements for Automated Key Rollover in - DNSsec", draft-ietf-dnsop-key-rollover-requirements-01 (work in - progress), August 2004. - Authors' Addresses @@ -1103,6 +1279,16 @@ Authors' Addresses EMail: miek@nlnetlabs.nl URI: http://www.nlnetlabs.nl + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 23] + +Internet-Draft DNSSEC Operational Practices December 2004 + + Appendix A. Terminology In this document there is some jargon used that is defined in other @@ -1111,41 +1297,35 @@ Appendix A. Terminology of the meaning. Note that these explanations should not be seen as authoritative. - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 20] - -Internet-Draft DNSSEC Operational Practices October 2004 - - + Anchored Key: A DNSKEY configured in resolvers around the globe. + This key is hard to update, hence the term anchored. + Bogus: Also see Section 5 of [3]. An RRset in DNSSEC is marked + "Bogus" when a signature of a RRset does not validate against a + DNSKEY. + Key-Signing Key or KSK: A Key-Signing Key (KSK) is a key that is used + exclusively for signing the apex key set. The fact that a key is + a KSK is only relevant to the signing tool. 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. + Key Rollover: A key rollover (also called key supersession in some + environments) is the act of replacing one key pair by another at + the end of a key effectivity period. + Secure Entry Point key or 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. + Singing the Zone File: The term used for the event where an + administrator joyfully signs its zone file while producing melodic + sound patterns. 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 key set. 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. - 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: Also see Section 5 of [5]. An RRset in DNSSEC is marked - "Bogus" when a signature of a RRset does not validate against a - DNSKEY. - Singing the Zone File: The term used for the event where an - administrator joyfully signs its zone file while producing melodic - sound patterns. + Zone-Signing Key or 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. Zone Administrator: The 'role' that is responsible for signing a zone and publishing it on the primary authoritative server. @@ -1154,7 +1334,17 @@ 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 caches here follows the "HOWTO". - Key notation: + + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 24] + +Internet-Draft DNSSEC Operational Practices December 2004 + + Step 0: The preparation: Create two keys and publish both in your key set. Mark one of the keys as "active" and the other as "published". Use the "active" key for signing your zone data. @@ -1167,15 +1357,6 @@ Appendix B. Zone-signing Key Rollover Howto 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". - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 21] - -Internet-Draft DNSSEC Operational Practices October 2004 - - Step 3: It is safe to engage in a new rollover (Step 1) after at least one "signature validity period". @@ -1212,6 +1393,14 @@ Appendix C. Typographic Conventions cmL62SI6iAX46xGNQAdQ... ) 600 NS a.iana-servers.net. 600 NS b.iana-servers.net. + + + +Kolkman & Gieben Expires June 23, 2005 [Page 25] + +Internet-Draft DNSSEC Operational Practices December 2004 + + 600 RRSIG NS 5 2 600 20130507213204 ( 20130407213204 14 example.net. SO5epiJei19AjXoUpFnQ ... ) @@ -1224,14 +1413,6 @@ Appendix C. Typographic Conventions 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( 20130422213204 14 example.net. J4zCe8QX4tXVGjV4e1r9... ) - - - -Kolkman & Gieben Expires April 11, 2005 [Page 22] - -Internet-Draft DNSSEC Operational Practices October 2004 - - 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( 20130422213204 15 example.net. keVDCOpsSeDReyV6O... ) @@ -1269,8 +1450,15 @@ Appendix D. Document Details and Changes This section is to be removed by the RFC editor if and when the document is published. - $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.29 2004/ - 10/11 11:27:10 dnssec Exp $ + + +Kolkman & Gieben Expires June 23, 2005 [Page 26] + +Internet-Draft DNSSEC Operational Practices December 2004 + + + $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.7 + 2004/12/23 12:20:29 dnssec Exp $ D.1 draft-ietf-dnsop-dnssec-operational-practices-00 @@ -1280,14 +1468,6 @@ D.1 draft-ietf-dnsop-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 - - - -Kolkman & Gieben Expires April 11, 2005 [Page 23] - -Internet-Draft DNSSEC Operational Practices October 2004 - - draft. Bad to Bogus @@ -1298,6 +1478,27 @@ Internet-Draft DNSSEC Operational Practices October 2004 Updates from Sam Weiler added +D.3 draft-ietf-dnsop-dnssec-operational-practices-02 + + Style and errors corrected. + + Added Automatic rollover requirements from + I-D.ietf-dnsop-key-rollover-requirements. + +D.4 draft-ietf-dnsop-dnssec-operational-practices-03 + + Added the definition of Key effectivity period and used that term + instead of Key validity period. + + Modified the order of the sections, based on a suggestion by Rip + Loomis. + + Included parts from RFC2541 [1]. Most of its ground was allready + covered. This document obsoletes RFC2541 [1]. Section 3.1.2 + deserves some review as it in contrast to RFC2541 does _not_ give + recomendations about root-zone keys. + + added a paragraph to Section 4.4.4 @@ -1307,41 +1508,9 @@ Internet-Draft DNSSEC Operational Practices October 2004 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 24] +Kolkman & Gieben Expires June 23, 2005 [Page 27] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 Intellectual Property Statement @@ -1395,6 +1564,6 @@ Acknowledgment -Kolkman & Gieben Expires April 11, 2005 [Page 25] +Kolkman & Gieben Expires June 23, 2005 [Page 28] diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-05.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-05.txt deleted file mode 100644 index 8809913a00..0000000000 --- a/doc/draft/draft-ietf-dnsop-inaddr-required-05.txt +++ /dev/null @@ -1,301 +0,0 @@ - - - - - - -INTERNET-DRAFT D. Senie -Category: BCP Amaranth Networks Inc. -Expires in six months April 2004 - - Encouraging the use of DNS IN-ADDR Mapping - draft-ietf-dnsop-inaddr-required-05.txt - -Status of this Memo - - - This draft, is intended to be become a Best Current Practice RFC. - Distribution of this document is unlimited. Comments should be sent - to the Domain Name Server Operations working group mailing list - or to the author. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of [RFC2026]. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - To view the list Internet-Draft Shadow Directories, see - http://www.ietf.org/shadow.html. - -Copyright Notice - - Copyright (C) The Internet Society (2000-2002). All Rights Reserved. - -Abstract - - Mapping of addresses to names has been a feature of DNS. Many sites, - implement it, many others don’t. Some applications attempt to use it - as a part of a security strategy. The goal of this document is to - encourage proper deployment of address to name mappings, and provide - guidance for their use. - -1. Introduction - - The Domain Name Service has provision for providing mapping of IP - addresses to host names. It is common practice to ensure both name to - address, and address to name mappings are provided for networks. This - practice, while documented, has never been documented as a - requirement placed upon those who control address blocks. This - - - -Senie [Page 1] - - - - - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004 - - - document fills this gap. - - 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]. - -2. Discussion - - From the early days of the Domain Name Service [RFC 883] a special - domain has been set aside for resolving mappings of IP addresses to - domain names. This was refined in [RFC1035], describing the .IN- - ADDR.ARPA in use today. - - The assignment of blocks of IP Address space was delegated to three - regional registries. Guidelines for the registries are specified in - [RFC2050], which requires regional registries to maintain IN-ADDR - records on the large blocks of space issued to ISPs and others. - - ARIN’s policy requires ISPs to maintain IN-ADDR for /16 or larger - allocations. For smaller allocations, ARIN can provide IN-ADDR for - /24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to - update IN-ADDR, however the present version of its policy document - for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft - copies of this document. As of this writing, it appears APNIC has no - actual policy on IN-ADDR. RIPE appears to have the strongest policy - in this area [ripe-185] indicating Local Internet Registries are - required to perform IN-ADDR services, and delegate those as - appropriate when address blocks are delegated. - - As we can see, the regional registries have their own policies for - requirements for IN-ADDR maintenance. It should be noted, however, - that many address blocks were allocated before the creation of the - regional registries, and thus it is unclear whether any of the - policies of the registries are binding on those who hold blocks from - that era. - - Registries allocate address blocks on CIDR [RFC1519] boundaries. - Unfortunately the IN-ADDR zones are based on classful allocations. - Guidelines [RFC2317] for delegating on non-octet-aligned boundaries - exist, but are not always implemented. - -3. Effects of missing IN-ADDR - - Many applications use DNS lookups for security checks. To ensure - validity of claimed names, some applications will look up IN-ADDR - records to get names, and then look up the resultant name to see if - it maps back to the address originally known. Failure to resolve - matching names is seen as a potential security concern. - - - -Senie [Page 2] - - - - - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004 - - - Some popular FTP sites will flat-out reject users, even for anonymous - FTP, if the IN-ADDR lookup fails or if the result of the IN-ADDR - lookup when itself resolved, does not match. Some Telnet servers also - implement this check. - - Web sites are in some cases using IN-ADDR checks to verify whether - the client is located within a certain geopolitical entity. This is - being employed for downloads of crypto software, for example, where - export of that software is prohibited to some locales. Credit card - anti-fraud systems also use these methods for geographic placement - purposes. - - The popular TCP Wrappers program found on most Unix and Linux systems - has options to enforce IN-ADDR checks and to reject any client that - does not resolve. - - Wider-scale implementation of IN-ADDR on dialup, CDPD and other such - client-oriented portions of the Internet would result in lower - latency for queries (due to lack of negative caching), and lower name - server load and DNS traffic. - - Some anti-spam (anti junk email) systems use IN-ADDR to verify return - addresses before accepting email. - - Many web servers look up the IN-ADDR of visitors to be used in log - analysis. This adds to the server load, but in the case of IN-ADDR - unavailability, it can lead to delayed responses for users. - - Traceroutes with descriptive IN-ADDR naming proves useful when - debugging problems spanning large areas. When this information is - missing, the traceroutes take longer, and it takes additional steps - to determine that network is the cause of problems. - -4. Requirements - - 4.1 Delegation Requirements - - Regional Registries and any Local Registries to whom they delegate - SHOULD establish and convey a policy to those to whom they delegate - blocks that IN-ADDR mappings are required. Policies SHOULD require - those receiving delegations to provide IN-ADDR service and/or - delegate to downstream customers. - - Network operators SHOULD define and implement policies and procedures - which delegate IN-ADDR to their clients who wish to run their own IN- - ADDR DNS services, and provide IN-ADDR services for those who do not - have the resources to do it themselves. Delegation mechanisms MUST - permit the downstream customer to implement and comply with IETF - - - -Senie [Page 3] - - - - - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004 - - - recommendations application of IN-ADDR to CIDR [RFC2317]. - - All IP address space assigned and in use SHOULD be resolved by IN- - ADDR records. All PTR records MUST use canonical names. - - All IP addresses in use within a block SHOULD have an IN-ADDR - mapping. Those addresses not in use, and those that are not valid for - use (zeros or ones broadcast addresses within a CIDR block) need not - have mappings. - - It should be noted that due to CIDR, many addresses that appear to be - otherwise valid host addresses may actually be zeroes or ones - broadcast addresses. As such, attempting to audit a site’s degree of - compliance can only be done with knowledge of the internal routing - structure of the site. However, any host that originates an IP packet - necessarily will have a valid host address, and must therefore have - an IN-ADDR mapping. - - 4.2 Application Requirements - - Applications SHOULD NOT rely on IN-ADDR for proper operation. The use - of IN-ADDR, sometimes in conjunction with a lookup of the name - resulting from the PTR record provides no real security, can lead to - erroneous results and generally just increases load on DNS servers. - Further, in cases where address block holders fail to properly - configure IN-ADDR, users of those blocks are penalized. - -5. Security Considerations - - This document has no negative impact on security. While it could be - argued that lack of PTR record capabilities provides a degree of - anonymity, this is really not valid. Trace routes, whois lookups and - other sources will still provide methods for discovering identity. - - By recommending applications avoid using IN-ADDR as a security - mechanism this document points out that this practice, despite its - use by many applications, is an ineffective form of security. - Applications should use better mechanisms of authentication. - -6. References - - [RFC883] P.V. Mockapetris, "Domain names: Implementation - specification," RFC883, November 1983. - - [RFC1035] P.V. Mockapetris, "Domain Names: Implementation - Specification," RFC 1035, November 1987. - - [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR): - - - -Senie [Page 4] - - - - - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004 - - - an Address Assignment and Aggregation Strategy," RFC 1519, September - 1993. - - [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", - RFC 2026, BCP 9, October 1996. - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997. - - [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation - Guidelines", RFC2050, BCP 12, Novebmer 1996. - - [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation," - RFC 2317, March 1998. - - [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date - unknown, http://www.arin.net/regserv/initial-isp.html - - [APNIC] "Policies For IPv4 Address Space Management in the Asia - Pacific Region," APNIC-086, 13 January 2003. - - [RIPE185] "European Internet Registry Policies and Procedures," - ripe-185, October 26, 1998. http://www.ripe.net/docs/ripe-185.html - - -7. Acknowledgements - - Thanks to Peter Koch and Gary Miller for their input, and to many - people who encouraged me to write this document. - -8. Author’s Address - - Daniel Senie - Amaranth Networks Inc. - 324 Still River Road - Bolton, MA 01740 - - Phone: (978) 779-5100 - - EMail: dts@senie.com - - - - - - - - - - - -Senie [Page 5] - - diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-06.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-06.txt new file mode 100644 index 0000000000..812440c783 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-inaddr-required-06.txt @@ -0,0 +1,424 @@ + +draft-ietf-dnsop-inaddr-required-06.txt + +INTERNET-DRAFT D. Senie +Category: BCP Amaranth Networks Inc. +Expires in six months February 2005 + + Encouraging the use of DNS IN-ADDR Mapping + +Status of this Memo + + 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 becomes + aware will be disclosed, in accordance with Section 6 of 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 + +Abstract + + Mapping of addresses to names has been a feature of DNS. Many sites, + implement it, many others don't. Some applications attempt to use it + as a part of a security strategy. The goal of this document is to + encourage proper deployment of address to name mappings, and provide + guidance for their use. + +Copyright Notice + + Copyright (C) The Internet Society. (2005) + +1. Introduction + + The Domain Name Service has provision for providing mapping of IP + addresses to host names. It is common practice to ensure both name to + address, and address to name mappings are provided for networks. This + practice, while documented, has never been required, though it is + generally encouraged. This document both encourages the presence of + + + +Senie [Page 1] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + these mappings and discourages reliance on such mappings for security + checks. + + 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]. + +2. Discussion + + + From the early days of the Domain Name Service [RFC883] a special + domain has been set aside for resolving mappings of IP addresses to + domain names. This was refined in [RFC1035], describing the .IN- + ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA + was added [RFC3152]. This document uses IPv4 CIDR block sizes and + allocation strategy where there are differences and uses IPv4 + terminology. Aside from these differences, this document can and + should be applied to both address spaces. + + The assignment of blocks of IP address space was delegated to three + regional registries. Guidelines for the registries are specified in + [RFC2050], which requires regional registries to maintain IN-ADDR + records on the large blocks of space issued to ISPs and others. + + ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger + allocations. For smaller allocations, ARIN can provide IN-ADDR for + /24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to + update IN-ADDR, however the present version of its policy document + for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft + copies of this document. As of this writing, it appears APNIC has no + actual policy on IN-ADDR. RIPE appears to have the strongest policy + in this area [RIPE302] indicating Local Internet Registries should + provide IN-ADDR services, and delegate those as appropriate when + address blocks are delegated. + + As we can see, the regional registries have their own policies for + recommendations and/or requirements for IN-ADDR maintenance. It + should be noted, however, that many address blocks were allocated + before the creation of the regional registries, and thus it is + unclear whether any of the policies of the registries are binding on + those who hold blocks from that era. + + Registries allocate address blocks on CIDR [RFC1519] boundaries. + Unfortunately the IN-ADDR zones are based on classful allocations. + Guidelines [RFC2317] for delegating on non-octet-aligned boundaries + exist, but are not always implemented. + +3. Examples of impact of missing IN-ADDR + + + +Senie [Page 2] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + These are some examples of problems that may be introduced by + reliance on IN-ADDR. + + Some applications use DNS lookups for security checks. To ensure + validity of claimed names, some applications will look up IN-ADDR + records to get names, and then look up the resultant name to see if + it maps back to the address originally known. Failure to resolve + matching names is seen as a potential security concern. + + Some FTP sites will flat-out reject users, even for anonymous FTP, if + the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when + itself resolved, does not match. Some Telnet servers also implement + this check. + + Web sites are in some cases using IN-ADDR checks to verify whether + the client is located within a certain geopolitical entity. This + approach has been employed for downloads of crypto software, for + example, where export of that software is prohibited to some locales. + Credit card anti-fraud systems also use these methods for geographic + placement purposes. + + The popular TCP Wrappers program found on most Unix and Linux systems + has options to enforce IN-ADDR checks and to reject any client that + does not resolve. This program also has a way to check to see that + the name given by a PTR record then resolves back to the same IP + address. This method provdes more comfort but no appreciable + additional security. + + Some anti-spam (anti junk email) systems use IN-ADDR to verify the + presence of a PTR record, or validate the PTR value points back to + the same address. + + Many web servers look up the IN-ADDR of visitors to be used in log + analysis. This adds to the server load, but in the case of IN-ADDR + unavailability, it can lead to delayed responses for users. + + Traceroutes with descriptive IN-ADDR naming proves useful when + debugging problems spanning large areas. When this information is + missing, the traceroutes take longer, and it takes additional steps + to determine that network is the cause of problems. + + Wider-scale implementation of IN-ADDR on dialup, wireless access and + other such client-oriented portions of the Internet would result in + lower latency for queries (due to lack of negative caching), and + lower name server load and DNS traffic. + +4. Recommendations + + + + +Senie [Page 3] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + 4.1 Delegation Recommendations + + + Regional Registries and any Local Registries to whom they delegate + should establish and convey a policy to those to whom they delegate + blocks that IN-ADDR mappings are recommended. Policies should + recommend those receiving delegations to provide IN-ADDR service + and/or delegate to downstream customers. + + Network operators should define and implement policies and procedures + which delegate IN-ADDR to their clients who wish to run their own IN- + ADDR DNS services, and provide IN-ADDR services for those who do not + have the resources to do it themselves. Delegation mechanisms should + permit the downstream customer to implement and comply with IETF + recommendations application of IN-ADDR to CIDR [RFC2317]. + + All IP address space assigned and in use should be resolved by IN- + ADDR records. All PTR records must use canonical names. + + All IP addresses in use within a block should have an IN-ADDR + mapping. Those addresses not in use, and those that are not valid for + use (zeros or ones broadcast addresses within a CIDR block) need not + have mappings. + + It should be noted that due to CIDR, many addresses that appear to be + otherwise valid host addresses may actually be zeroes or ones + broadcast addresses. As such, attempting to audit a site's degree of + compliance may only be done with knowledge of the internal subnet + architecture of the site. It can be assumed, however, any host that + originates an IP packet necessarily will have a valid host address, + and must therefore have an IN-ADDR mapping. + +4.2 Application Recommendations + + + Applications SHOULD NOT rely on IN-ADDR for proper operation. The use + of IN-ADDR, sometimes in conjunction with a lookup of the name + resulting from the PTR record provides no real security, can lead to + erroneous results and generally just increases load on DNS servers. + Further, in cases where address block holders fail to properly + configure IN-ADDR, users of those blocks are penalized. + +5. Security Considerations + + This document has no negative impact on security. While it could be + argued that lack of PTR record capabilities provides a degree of + anonymity, this is really not valid. Trace routes, whois lookups and + other sources will still provide methods for discovering identity. + + + +Senie [Page 4] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + By recommending applications avoid using IN-ADDR as a security + mechanism this document points out that this practice, despite its + use by many applications, is an ineffective form of security. + Applications should use better mechanisms of authentication. + +6. IANA Considerations + + There are no IANA considerations for this document. + +7. References + +7.1 Normative References + + [RFC883] P.V. Mockapetris, "Domain names: Implementation + specification," RFC883, November 1983. + + [RFC1035] P.V. Mockapetris, "Domain Names: Implementation + Specification," RFC 1035, November 1987. + + [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR): + an Address Assignment and Aggregation Strategy," RFC 1519, September + 1993. + + [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", + RFC 2026, BCP 9, October 1996. + + [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. + + [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation + Guidelines", RFC2050, BCP 12, Novebmer 1996. + + [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation," + RFC 2317, March 1998. + + [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August + 2001. + +7.2 Informative References + + [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date + unknown, +http://www.arin.net/regserv/initial-isp.html + + [APNIC] "Policies For IPv4 Address Space Management in the Asia + Pacific Region," APNIC-086, 13 January 2003. + + [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6 + Address Space in the RIPE NCC Service Region", RIPE-302, April 26, + + + +Senie [Page 5] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + 2004. +http://www.ripe.net//ripe/docs/rev-del.html + + + +8. Acknowledgements + + Thanks to Peter Koch and Gary Miller for their input, and to many + people who encouraged me to write this document. + +9. Author's Address + + Daniel Senie + Amaranth Networks Inc. + 324 Still River Road + Bolton, MA 01740 + + Phone: (978) 779-5100 + + EMail: dts@senie.com + +10. 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 + + + +Senie [Page 6] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Senie [Page 7] + + + + + + + diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt deleted file mode 100644 index 2311ee6c18..0000000000 --- a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt +++ /dev/null @@ -1,391 +0,0 @@ - -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/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt new file mode 100644 index 0000000000..6bece56182 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt @@ -0,0 +1,389 @@ + +DNSOP G. Guette +Internet-Draft IRISA / INRIA +Expires: July 19, 2005 O. Courtay + Thomson R&D + January 18, 2005 + + Requirements for Automated Key Rollover in DNSSEC + draft-ietf-dnsop-key-rollover-requirements-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 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 July 19, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). 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 during an automated rollover + process. This document is essentially about in-band key rollover. + + + + +Guette & Courtay Expires July 19, 2005 [Page 1] +Internet-Draft Automated Rollover Requirements January 2005 + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3 + 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Messages authentication and information exchanged . . . . . . 5 + 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5 + 6. Security consideration . . . . . . . . . . . . . . . . . . . . 6 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 + 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 + A. Documents details and changes . . . . . . . . . . . . . . . . 7 + Intellectual Property and Copyright Statements . . . . . . . . 8 + + + + + + + + + + + + + + + + + + + +Guette & Courtay Expires July 19, 2005 [Page 2] +Internet-Draft Automated Rollover Requirements January 2005 + +1. Introduction + + The DNS security extensions (DNSSEC) [4][6][5][7] 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 + exchanges between parents and children is necessary for large zones + because there are too many changes to handle. + + 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 is 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 a protocol to perform + the automated key rollover process and focusses on interaction + between parent and child zone. + +2. The Key Rollover Process + + Key rollover consists of 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. + + During a ZSK rollover, all changes are local to the zone that renews + its key: there is no need to contact other zones administrators to + propagate the performed changes because a ZSK has no associated DS + record in the parent zone. + + During a KSK rollover, new DS RR(s) must be created and stored in the + parent zone. In consequence, data must be exchanged between child + and parent zones. + + The key rollover is built from two parts of different nature: + o An algorithm that generates new keys and signs the zone file. It + can be local to the zone, + o the interaction between parent and child zones. + + One example of manual key rollover [3] is: + o The child zone creates a new KSK, + + +Guette & Courtay Expires July 19, 2005 [Page 3] +Internet-Draft Automated Rollover Requirements January 2005 + + o the child zone waits for the creation of the DS RR in its parent + zone, + o the child zone deletes the old key, + o the parent zone deletes the old DS RR. + + This document concentrates on defining interactions between entities + present in key rollover process. + +3. Basic Requirements + + This section provides the requirements for automated key rollover in + case of normal use. Exceptional case like emergency rollover is + specifically described later in this document. + + The main condition during a key rollover is that the chain of trust + must be preserved to every validating DNS client. No matter if this + client retrieves some of the RRs from recursive caching name server + or from the authoritative servers for the zone involved in the + rollover. + + Automated key rollover solution may be interrupted by a manual + intervention. This manual intervention should not compromise the + security state of the chain of trust. If the chain is safe before + the manual intervention, the chain of trust must remain safe during + and after the manual intervention + + 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 and/or to verify that the changes had been taken into account + in the parent zone. Hence, the child zone can also avoid some + critical cases where all child key are changed prior to the DS RR + creation. + + By keeping some resource records during a given time, the recursive + cache servers can act on the automated rollover. The existence of + recursive cache servers must be taken into account by automated + rollover solution. + + Indeed, during an automated key rollover a name server could have to + retrieve some DNSSEC data. An automated key rollover solution must + ensure that these data are not old DNSSEC material retrieved from a + recursive name server. + + + +Guette & Courtay Expires July 19, 2005 [Page 4] +Internet-Draft Automated Rollover Requirements January 2005 + +4. Messages authentication and information exchanged + + This section addresses in-band rollover, security of out-of-band + mechanisms is out of scope of this document. + + The security provided by DNSSEC must not be compromised by the key + rollover, thus every exchanged message must be authenticated to avoid + fake rollover messages from malicious parties. + + Once the changes related to a KSK are made in a child zone, there are + two ways for the parent zone to take this changes into account: + o the child zone notify directly or not directly its parent zone in + order to create the new DS RR and store this DS RR in parent zone + file, + o or the parent zone poll the child zone. + + In both cases, the parent zone must receive all the child keys that + need the creation of associated DS RRs in the parent zone. + + Because errors could occur during the transmission of keys between + child and parent, the key exchange protocol must be fault tolerant. + Should an error occured during the automated key rollover, an + automated key rollover solution must be able to keep the zone files + in a consistent state. + +5. Emergency Rollover + + Emergency key rollover is a special case of rollover decided by the + zone administrator generally for security reasons. In consequence, + emergency key rollover can break some of the requirement described + above. + + A zone key might be compromised and an attacker can use the + compromised key to create and sign fake records. To avoid this, the + zone administrator may change the compromised key or all its keys as + soon as possible, without waiting for the creation of new DS RRs in + its parent zone. + + Fast changes may 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 the administrator wants to prevent + the compromised key from being used (to spoof DNS data). + + Parent and child zones sharing an automated rollover mechanism, + should have an out-of-band way to re-establish a consistent state at + the delegation point (DS and DNSKEY RRs). This allows to avoid that + a malicious party uses the compromised key to roll the zone keys. + + +Guette & Courtay Expires July 19, 2005 [Page 5] +Internet-Draft Automated Rollover Requirements January 2005 + +6. Security consideration + + The automated key rollover process in DNSSEC allows automated renewal + of any kind of DNS key (ZSK or KSK). It is essential that parent + side and child side can do mutual authentication. Moreover, + integrity of the material exchanged between the parent and child zone + must be provided to ensure the right DS are created. + + As in any application using public key cryptography, in DNSSEC a key + may be compromised. What to do in such a case can be describe in the + zone local policy and can violate some requirements described in this + draft. The emergency rollover can break the chain of trust in order + to protect the zone against the use of the compromised key. + +7. Acknowledgments + + The authors want to thank members of IDsA project for their + contribution to this document. + +8 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. + + [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] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + + [6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October + + +Guette & Courtay Expires July 19, 2005 [Page 6] +Internet-Draft Automated Rollover Requirements January 2005 + + 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 + +Appendix A. Documents details and changes + + This section is to be removed by the RFC editor if and when the + document is published. + + Section about NS RR rollover has been removed + + Remarks from Samuel Weiler and Rip Loomis added + + Clarification about in-band rollover and in emergency section + + Section 3, details about recursive cache servers added + + + + + + + + +Guette & Courtay Expires July 19, 2005 [Page 7] +Internet-Draft Automated Rollover Requirements January 2005 + +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 + IETF Documents can be found in BCP 78 and 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 which may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr.org. + + + Full Copyright Statement + + Copyright (C) The Internet Society (2005). 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. + + Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + +Guette & Courtay Expires July 19, 2005 [Page 8] From 25899e7f1ff0db5322362ada01f7aec3006ff0be Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tatuya=20JINMEI=20=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= Date: Sat, 26 Feb 2005 04:58:44 +0000 Subject: [PATCH 104/130] 1817. [placeholder] rt13587 --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 0b75aa7cfb..7cf9294647 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1817. [placeholder] rt13587 + 1816. [placeholder] rt13597 1815. [placeholder] rt13086 From 77b101ced9801cdb226919784bfc1aa0650ace6a Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 3 Mar 2005 04:46:18 +0000 Subject: [PATCH 105/130] 1818. [bug] 'named-checkconf -z' triggered an INSIST. [RT #13599] --- CHANGES | 2 ++ bin/check/named-checkconf.c | 13 ++++++++++++- 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/CHANGES b/CHANGES index 7cf9294647..04c9acdda2 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1818. [bug] 'named-checkconf -z' triggered an INSIST. [RT #13599] + 1817. [placeholder] rt13587 1816. [placeholder] rt13597 diff --git a/bin/check/named-checkconf.c b/bin/check/named-checkconf.c index 5c4ae7ba50..5cb55d4782 100644 --- a/bin/check/named-checkconf.c +++ b/bin/check/named-checkconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named-checkconf.c,v 1.28 2004/03/05 04:57:20 marka Exp $ */ +/* $Id: named-checkconf.c,v 1.29 2005/03/03 04:46:18 marka Exp $ */ #include @@ -25,6 +25,8 @@ #include #include +#include +#include #include #include #include @@ -35,6 +37,7 @@ #include +#include #include #include @@ -203,6 +206,7 @@ main(int argc, char **argv) { isc_mem_t *mctx = NULL; isc_result_t result; int exit_status = 0; + isc_entropy_t *ectx = NULL; isc_boolean_t load_zones = ISC_FALSE; while ((c = isc_commandline_parse(argc, argv, "djt:vz")) != EOF) { @@ -252,6 +256,10 @@ main(int argc, char **argv) { RUNTIME_CHECK(setup_logging(mctx, &logc) == ISC_R_SUCCESS); + RUNTIME_CHECK(isc_entropy_create(mctx, &ectx) == ISC_R_SUCCESS); + RUNTIME_CHECK(isc_hash_create(mctx, ectx, DNS_NAME_MAXWIRE) + == ISC_R_SUCCESS); + dns_result_register(); RUNTIME_CHECK(cfg_parser_create(mctx, logc, &parser) == ISC_R_SUCCESS); @@ -280,6 +288,9 @@ main(int argc, char **argv) { isc_log_destroy(&logc); + isc_hash_destroy(); + isc_entropy_detach(&ectx); + isc_mem_destroy(&mctx); return (exit_status); From f8f37672a57524560fbdde52484e6ae3de1c3354 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 3 Mar 2005 05:28:46 +0000 Subject: [PATCH 106/130] newcopyrights --- util/copyrights | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util/copyrights b/util/copyrights index f67f68263f..b6d467cf97 100644 --- a/util/copyrights +++ b/util/copyrights @@ -13,7 +13,7 @@ ./bin/check/check-tool.c C 2000,2001,2002,2004,2005 ./bin/check/check-tool.h C 2000,2001,2002,2004 ./bin/check/named-checkconf.8 MAN 2000,2001,2002,2004 -./bin/check/named-checkconf.c C 1999,2000,2001,2002,2004 +./bin/check/named-checkconf.c C 1999,2000,2001,2002,2004,2005 ./bin/check/named-checkconf.docbook SGML 2001,2002,2004 ./bin/check/named-checkconf.html HTML 2001,2002,2004 ./bin/check/named-checkzone.8 MAN 2000,2001,2002,2004,2005 From 35538d7a7df83c7d2713ae86255cebd799715f54 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 3 Mar 2005 06:33:05 +0000 Subject: [PATCH 107/130] update copyright notice --- bin/check/named-checkconf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bin/check/named-checkconf.c b/bin/check/named-checkconf.c index 5cb55d4782..109d17e1ce 100644 --- a/bin/check/named-checkconf.c +++ b/bin/check/named-checkconf.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named-checkconf.c,v 1.29 2005/03/03 04:46:18 marka Exp $ */ +/* $Id: named-checkconf.c,v 1.30 2005/03/03 06:33:05 marka Exp $ */ #include From 39c7fc7e00af20144b94ef332943f62c1b3a622f Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 4 Mar 2005 02:56:21 +0000 Subject: [PATCH 108/130] 1811. [func] Preserve the case of domain names in rdata during zone transfers. [RT #13547] --- CHANGES | 3 ++- bin/named/xfrout.c | 3 ++- lib/dns/compress.c | 33 ++++++++++++++++++++++++++++----- lib/dns/include/dns/compress.h | 23 ++++++++++++++++++++++- lib/dns/include/dns/name.h | 4 +++- lib/dns/name.c | 31 ++++++++++++++++++++++++++++++- 6 files changed, 87 insertions(+), 10 deletions(-) diff --git a/CHANGES b/CHANGES index 04c9acdda2..4fb51bc062 100644 --- a/CHANGES +++ b/CHANGES @@ -13,7 +13,8 @@ 1812. [port] win32: IN6_IS_ADDR_UNSPECIFIED macro is incorrect. [RT #13453] -1811. [placeholder] rt13547 +1811. [func] Preserve the case of domain names in rdata during + zone transfers. [RT #13547] 1810. [placeholder] rt13212 diff --git a/bin/named/xfrout.c b/bin/named/xfrout.c index 0d260870dc..fa134001a8 100644 --- a/bin/named/xfrout.c +++ b/bin/named/xfrout.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: xfrout.c,v 1.116 2004/04/02 05:13:25 marka Exp $ */ +/* $Id: xfrout.c,v 1.117 2005/03/04 02:56:20 marka Exp $ */ #include @@ -1511,6 +1511,7 @@ sendstream(xfrout_ctx_t *xfr) { if ((xfr->client->attributes & NS_CLIENTATTR_TCP) != 0) { CHECK(dns_compress_init(&cctx, -1, xfr->mctx)); + dns_compress_setsensitive(&cctx, ISC_TRUE); cleanup_cctx = ISC_TRUE; CHECK(dns_message_renderbegin(msg, &cctx, &xfr->txbuf)); CHECK(dns_message_rendersection(msg, DNS_SECTION_QUESTION, 0)); diff --git a/lib/dns/compress.c b/lib/dns/compress.c index 76638175d1..2a6cbe9a04 100644 --- a/lib/dns/compress.c +++ b/lib/dns/compress.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: compress.c,v 1.52 2004/03/05 05:09:18 marka Exp $ */ +/* $Id: compress.c,v 1.53 2005/03/04 02:56:20 marka Exp $ */ #define DNS_NAME_USEINLINE 1 @@ -82,13 +82,31 @@ void dns_compress_setmethods(dns_compress_t *cctx, unsigned int allowed) { REQUIRE(VALID_CCTX(cctx)); - cctx->allowed = allowed; + cctx->allowed &= ~DNS_COMPRESS_ALL; + cctx->allowed |= (allowed & DNS_COMPRESS_ALL); } unsigned int dns_compress_getmethods(dns_compress_t *cctx) { REQUIRE(VALID_CCTX(cctx)); - return (cctx->allowed); + return (cctx->allowed & DNS_COMPRESS_ALL); +} + +void +dns_compress_setsensitive(dns_compress_t *cctx, isc_boolean_t sensitive) { + REQUIRE(VALID_CCTX(cctx)); + + if (sensitive) + cctx->allowed |= DNS_COMPRESS_CASESENSITIVE; + else + cctx->allowed &= ~DNS_COMPRESS_CASESENSITIVE; +} + +isc_boolean_t +dns_compress_getsensitive(dns_compress_t *cctx) { + REQUIRE(VALID_CCTX(cctx)); + + return (ISC_TF((cctx->allowed & DNS_COMPRESS_CASESENSITIVE) != 0)); } int @@ -138,8 +156,13 @@ dns_compress_findglobal(dns_compress_t *cctx, dns_name_t *name, for (node = cctx->table[hash]; node != NULL; node = node->next) { NODENAME(node, &nname); - if (dns_name_equal(&nname, &tname)) - break; + if ((cctx->allowed & DNS_COMPRESS_CASESENSITIVE) != 0) { + if (dns_name_caseequal(&nname, &tname)) + break; + } else { + if (dns_name_equal(&nname, &tname)) + break; + } } if (node != NULL) break; diff --git a/lib/dns/include/dns/compress.h b/lib/dns/include/dns/compress.h index 0bfd9403a8..29d903e0ec 100644 --- a/lib/dns/include/dns/compress.h +++ b/lib/dns/include/dns/compress.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: compress.h,v 1.32 2004/03/05 05:09:41 marka Exp $ */ +/* $Id: compress.h,v 1.33 2005/03/04 02:56:21 marka Exp $ */ #ifndef DNS_COMPRESS_H #define DNS_COMPRESS_H 1 @@ -30,6 +30,7 @@ ISC_LANG_BEGINDECLS #define DNS_COMPRESS_NONE 0x00 /* no compression */ #define DNS_COMPRESS_GLOBAL14 0x01 /* "normal" compression. */ #define DNS_COMPRESS_ALL 0x01 /* all compression. */ +#define DNS_COMPRESS_CASESENSITIVE 0x02 /* case sensitive compression. */ /* * Direct manipulation of the structures is strongly discouraged. @@ -122,6 +123,26 @@ dns_compress_getmethods(dns_compress_t *cctx); * allowed compression bitmap. */ +void +dns_compress_setsensitive(dns_compress_t *cctx, isc_boolean_t sensitive); + +/* + * Preserve the case of compressed domain names. + * + * Requires: + * 'cctx' to be initialized. + */ + +isc_boolean_t +dns_compress_getsensitive(dns_compress_t *cctx); +/* + * Return whether case is to be preservered when compressing + * domain names. + * + * Requires: + * 'cctx' to be initialized. + */ + int dns_compress_getedns(dns_compress_t *cctx); diff --git a/lib/dns/include/dns/name.h b/lib/dns/include/dns/name.h index 8e8d0cd4fc..8528495ede 100644 --- a/lib/dns/include/dns/name.h +++ b/lib/dns/include/dns/name.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: name.h,v 1.113 2005/01/10 23:43:25 marka Exp $ */ +/* $Id: name.h,v 1.114 2005/03/04 02:56:21 marka Exp $ */ #ifndef DNS_NAME_H #define DNS_NAME_H 1 @@ -417,6 +417,8 @@ dns_name_compare(const dns_name_t *name1, const dns_name_t *name2); isc_boolean_t dns_name_equal(const dns_name_t *name1, const dns_name_t *name2); +isc_boolean_t +dns_name_caseequal(const dns_name_t *name1, const dns_name_t *name2); /* * Are 'name1' and 'name2' equal? * diff --git a/lib/dns/name.c b/lib/dns/name.c index a9fba7c708..e95189de97 100644 --- a/lib/dns/name.c +++ b/lib/dns/name.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: name.c,v 1.148 2005/01/10 23:43:22 marka Exp $ */ +/* $Id: name.c,v 1.149 2005/03/04 02:56:21 marka Exp $ */ #include @@ -699,6 +699,35 @@ dns_name_equal(const dns_name_t *name1, const dns_name_t *name2) { return (ISC_TRUE); } +isc_boolean_t +dns_name_caseequal(const dns_name_t *name1, const dns_name_t *name2) { + + /* + * Are 'name1' and 'name2' equal? + * + * Note: It makes no sense for one of the names to be relative and the + * other absolute. If both names are relative, then to be meaningfully + * compared the caller must ensure that they are both relative to the + * same domain. + */ + + REQUIRE(VALID_NAME(name1)); + REQUIRE(VALID_NAME(name2)); + /* + * Either name1 is absolute and name2 is absolute, or neither is. + */ + REQUIRE((name1->attributes & DNS_NAMEATTR_ABSOLUTE) == + (name2->attributes & DNS_NAMEATTR_ABSOLUTE)); + + if (name1->length != name2->length) + return (ISC_FALSE); + + if (memcmp(name1->ndata, name2->ndata, name1->length) != 0) + return (ISC_FALSE); + + return (ISC_TRUE); +} + int dns_name_rdatacompare(const dns_name_t *name1, const dns_name_t *name2) { unsigned int l1, l2, l, count1, count2, count; From c941e32d221fbb0cb760e3bc24c7f221c0cf8b97 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 4 Mar 2005 03:53:22 +0000 Subject: [PATCH 109/130] 1819. [bug] The validator needed to check both the algorithm and digest types of the DS to determine if it could be used to introduce a secure zone. [RT #13593] --- CHANGES | 4 ++++ lib/dns/ds.c | 7 ++++++- lib/dns/include/dns/ds.h | 8 +++++++- lib/dns/include/dns/resolver.h | 8 +++++++- lib/dns/resolver.c | 10 +++++++++- lib/dns/validator.c | 34 ++++++++++++++++++++++------------ 6 files changed, 55 insertions(+), 16 deletions(-) diff --git a/CHANGES b/CHANGES index 4fb51bc062..288f910b90 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,7 @@ +1819. [bug] The validator needed to check both the algorithm and + digest types of the DS to determine if it could be + used to introduce a secure zone. [RT #13593] + 1818. [bug] 'named-checkconf -z' triggered an INSIST. [RT #13599] 1817. [placeholder] rt13587 diff --git a/lib/dns/ds.c b/lib/dns/ds.c index 44cb4d32d2..7bcf1fb37e 100644 --- a/lib/dns/ds.c +++ b/lib/dns/ds.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: ds.c,v 1.4 2004/03/05 05:09:19 marka Exp $ */ +/* $Id: ds.c,v 1.5 2005/03/04 03:53:20 marka Exp $ */ #include @@ -81,3 +81,8 @@ dns_ds_buildrdata(dns_name_t *owner, dns_rdata_t *key, return (dns_rdata_fromstruct(rdata, key->rdclass, dns_rdatatype_ds, &ds, &b)); } + +isc_boolean_t +dns_ds_digest_supported(unsigned int digest_type) { + return (ISC_TF(digest_type == DNS_DSDIGEST_SHA1)); +} diff --git a/lib/dns/include/dns/ds.h b/lib/dns/include/dns/ds.h index 40e3c6a8ec..3e2f7a90fe 100644 --- a/lib/dns/include/dns/ds.h +++ b/lib/dns/include/dns/ds.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: ds.h,v 1.3 2004/03/05 05:09:42 marka Exp $ */ +/* $Id: ds.h,v 1.4 2005/03/04 03:53:21 marka Exp $ */ #ifndef DNS_DS_H #define DNS_DS_H 1 @@ -51,6 +51,12 @@ dns_ds_buildrdata(dns_name_t *owner, dns_rdata_t *key, * to 'buffer'. */ +isc_boolean_t +dns_ds_digest_supported(unsigned int digest_type); +/* + * Is this digest algorithm supported by dns_ds_buildrdata()? + */ + ISC_LANG_ENDDECLS #endif /* DNS_DS_H */ diff --git a/lib/dns/include/dns/resolver.h b/lib/dns/include/dns/resolver.h index 0f35a6ba71..1aaa335be0 100644 --- a/lib/dns/include/dns/resolver.h +++ b/lib/dns/include/dns/resolver.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: resolver.h,v 1.41 2004/04/15 23:40:26 marka Exp $ */ +/* $Id: resolver.h,v 1.42 2005/03/04 03:53:22 marka Exp $ */ #ifndef DNS_RESOLVER_H #define DNS_RESOLVER_H 1 @@ -416,6 +416,12 @@ dns_resolver_algorithm_supported(dns_resolver_t *resolver, dns_name_t *name, * crypto libraries if not specifically disabled. */ +isc_boolean_t +dns_resolver_digest_supported(dns_resolver_t *resolver, unsigned int digest_type); +/* + * Is this digest type supported. + */ + void dns_resolver_resetmustbesecure(dns_resolver_t *resolver); diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c index 9680424404..5eaba1668b 100644 --- a/lib/dns/resolver.c +++ b/lib/dns/resolver.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: resolver.c,v 1.303 2005/02/08 23:51:31 marka Exp $ */ +/* $Id: resolver.c,v 1.304 2005/03/04 03:53:21 marka Exp $ */ #include @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -6520,6 +6521,13 @@ dns_resolver_algorithm_supported(dns_resolver_t *resolver, dns_name_t *name, return (dst_algorithm_supported(alg)); } +isc_boolean_t +dns_resolver_digest_supported(dns_resolver_t *resolver, unsigned int digest) { + + UNUSED(resolver); + return (dns_ds_digest_supported(digest)); +} + void dns_resolver_resetmustbesecure(dns_resolver_t *resolver) { diff --git a/lib/dns/validator.c b/lib/dns/validator.c index 0989855cec..8668beb3ad 100644 --- a/lib/dns/validator.c +++ b/lib/dns/validator.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: validator.c,v 1.126 2005/02/09 05:19:30 marka Exp $ */ +/* $Id: validator.c,v 1.127 2005/03/04 03:53:21 marka Exp $ */ #include @@ -1561,6 +1561,9 @@ dlv_validatezonekey(dns_validator_t *val) { dns_rdataset_current(val->dlv, &dlvrdata); (void)dns_rdata_tostruct(&dlvrdata, &dlv, NULL); + if (!dns_resolver_digest_supported(val->view->resolver, + dlv.digest_type)) + continue; if (!dns_resolver_algorithm_supported(val->view->resolver, val->event->name, dlv.algorithm)) @@ -1647,7 +1650,7 @@ dlv_validatezonekey(dns_validator_t *val) { val->event->rdataset->trust = dns_trust_answer; val->event->sigrdataset->trust = dns_trust_answer; validator_log(val, ISC_LOG_DEBUG(3), - "no supported algorithm (dlv)"); + "no supported algorithm/digest (dlv)"); return (ISC_R_SUCCESS); } else return (DNS_R_NOVALIDSIG); @@ -1848,6 +1851,10 @@ validatezonekey(dns_validator_t *val) { dns_rdataset_current(val->dsset, &dsrdata); (void)dns_rdata_tostruct(&dsrdata, &ds, NULL); + if (!dns_resolver_digest_supported(val->view->resolver, + ds.digest_type)) + continue; + if (!dns_resolver_algorithm_supported(val->view->resolver, val->event->name, ds.algorithm)) @@ -1940,7 +1947,7 @@ validatezonekey(dns_validator_t *val) { val->event->rdataset->trust = dns_trust_answer; val->event->sigrdataset->trust = dns_trust_answer; validator_log(val, ISC_LOG_DEBUG(3), - "no supported algorithm (ds)"); + "no supported algorithm/digest (ds)"); return (ISC_R_SUCCESS); } else return (DNS_R_NOVALIDSIG); @@ -2193,7 +2200,7 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) { } static isc_boolean_t -check_ds_algorithm(dns_validator_t *val, dns_name_t *name, +check_ds(dns_validator_t *val, dns_name_t *name, dns_rdataset_t *rdataset) { dns_rdata_t dsrdata = DNS_RDATA_INIT; dns_rdata_ds_t ds; @@ -2205,9 +2212,13 @@ check_ds_algorithm(dns_validator_t *val, dns_name_t *name, dns_rdataset_current(rdataset, &dsrdata); (void)dns_rdata_tostruct(&dsrdata, &ds, NULL); - if (dns_resolver_algorithm_supported(val->view->resolver, - name, ds.algorithm)) + if (dns_resolver_digest_supported(val->view->resolver, + ds.digest_type) && + dns_resolver_algorithm_supported(val->view->resolver, + name, ds.algorithm)) { + dns_rdata_reset(&dsrdata); return (ISC_TRUE); + } dns_rdata_reset(&dsrdata); } return (ISC_FALSE); @@ -2385,8 +2396,8 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) { } else { validator_log(val, ISC_LOG_DEBUG(3), "resuming proveunsecure"); if (val->frdataset.trust >= dns_trust_secure && - !check_ds_algorithm(val, dns_fixedname_name(&val->fname), - &val->frdataset)) { + !check_ds(val, dns_fixedname_name(&val->fname), + &val->frdataset)) { if (val->mustbesecure) { validator_log(val, ISC_LOG_WARNING, "must be secure failure"); @@ -2394,7 +2405,7 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) { goto out; } validator_log(val, ISC_LOG_DEBUG(3), - "no supported algorithm (ds)"); + "no supported algorithm/digest (ds)"); val->event->rdataset->trust = dns_trust_answer; result = ISC_R_SUCCESS; goto out; @@ -2453,10 +2464,9 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) { * continue. */ if (val->frdataset.trust >= dns_trust_secure) { - if (!check_ds_algorithm(val, tname, - &val->frdataset)) { + if (!check_ds(val, tname, &val->frdataset)) { validator_log(val, ISC_LOG_DEBUG(3), - "no supported algorithm (ds)"); + "no supported algorithm/digest (ds)"); if (val->mustbesecure) { validator_log(val, ISC_LOG_WARNING, From 6d7007e807241ae0a32de8db8d3bf434626026ea Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 4 Mar 2005 06:22:17 +0000 Subject: [PATCH 110/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index 288f910b90..f9c2a21702 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1820. [placeholder] rt13659 + 1819. [bug] The validator needed to check both the algorithm and digest types of the DS to determine if it could be used to introduce a secure zone. [RT #13593] From 7c40ffd67bd1e73907f83a79a6ff8c635f4a4a74 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 4 Mar 2005 23:34:59 +0000 Subject: [PATCH 111/130] newcopyrights --- util/copyrights | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/util/copyrights b/util/copyrights index b6d467cf97..cb7a55187b 100644 --- a/util/copyrights +++ b/util/copyrights @@ -159,7 +159,7 @@ ./bin/named/win32/named.mak X 2001 ./bin/named/win32/ntservice.c C 1999,2000,2001,2002,2004 ./bin/named/win32/os.c C 1999,2000,2001,2002,2004 -./bin/named/xfrout.c C 1999,2000,2001,2002,2003,2004 +./bin/named/xfrout.c C 1999,2000,2001,2002,2003,2004,2005 ./bin/named/zoneconf.c C 1999,2000,2001,2002,2003,2004,2005 ./bin/nsupdate/.cvsignore X 2000,2001 ./bin/nsupdate/Makefile.in MAKE 2000,2001,2002,2004 @@ -1607,14 +1607,14 @@ ./lib/dns/byaddr.c C 2000,2001,2002,2003,2004 ./lib/dns/cache.c C 1999,2000,2001,2002,2003,2004 ./lib/dns/callbacks.c C 1999,2000,2001,2004 -./lib/dns/compress.c C 1999,2000,2001,2004 +./lib/dns/compress.c C 1999,2000,2001,2004,2005 ./lib/dns/db.c C 1999,2000,2001,2003,2004 ./lib/dns/dbiterator.c C 1999,2000,2001,2004 ./lib/dns/dbtable.c C 1999,2000,2001,2004 ./lib/dns/diff.c C 2000,2001,2002,2003,2004,2005 ./lib/dns/dispatch.c C 1999,2000,2001,2002,2003,2004,2005 ./lib/dns/dnssec.c C 1999,2000,2001,2002,2003,2004 -./lib/dns/ds.c C 2002,2003,2004 +./lib/dns/ds.c C 2002,2003,2004,2005 ./lib/dns/dst_api.c C.NAI 1999,2000,2001,2002,2003,2004 ./lib/dns/dst_internal.h C.NAI 2000,2001,2002,2004 ./lib/dns/dst_lib.c C 1999,2000,2001,2004 @@ -1641,14 +1641,14 @@ ./lib/dns/include/dns/cache.h C 1999,2000,2001,2004 ./lib/dns/include/dns/callbacks.h C 1999,2000,2001,2002,2004 ./lib/dns/include/dns/cert.h C 1999,2000,2001,2004 -./lib/dns/include/dns/compress.h C 1999,2000,2001,2002,2004 +./lib/dns/include/dns/compress.h C 1999,2000,2001,2002,2004,2005 ./lib/dns/include/dns/db.h C 1999,2000,2001,2002,2003,2004 ./lib/dns/include/dns/dbiterator.h C 1999,2000,2001,2004 ./lib/dns/include/dns/dbtable.h C 1999,2000,2001,2004 ./lib/dns/include/dns/diff.h C 2000,2001,2004 ./lib/dns/include/dns/dispatch.h C 1999,2000,2001,2002,2003,2004 ./lib/dns/include/dns/dnssec.h C 1999,2000,2001,2002,2004 -./lib/dns/include/dns/ds.h C 2002,2004 +./lib/dns/include/dns/ds.h C 2002,2004,2005 ./lib/dns/include/dns/events.h C 1999,2000,2001,2002,2004 ./lib/dns/include/dns/fixedname.h C 1999,2000,2001,2004 ./lib/dns/include/dns/forward.h C 2000,2001,2004 @@ -1679,7 +1679,7 @@ ./lib/dns/include/dns/rdataslab.h C 1999,2000,2001,2002,2004 ./lib/dns/include/dns/rdatatype.h C 1998,1999,2000,2001,2004 ./lib/dns/include/dns/request.h C 2000,2001,2002,2004 -./lib/dns/include/dns/resolver.h C 1999,2000,2001,2003,2004 +./lib/dns/include/dns/resolver.h C 1999,2000,2001,2003,2004,2005 ./lib/dns/include/dns/result.h C 1998,1999,2000,2001,2002,2003,2004 ./lib/dns/include/dns/rootns.h C 1999,2000,2001,2004,2005 ./lib/dns/include/dns/sdb.h C 2000,2001,2004 From 408767b505b2391706ea9096cf5b0be53409a64f Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Sun, 6 Mar 2005 15:30:37 +0000 Subject: [PATCH 112/130] update copyright notice --- bin/named/xfrout.c | 4 ++-- lib/dns/compress.c | 4 ++-- lib/dns/ds.c | 4 ++-- lib/dns/include/dns/compress.h | 4 ++-- lib/dns/include/dns/ds.h | 4 ++-- lib/dns/include/dns/resolver.h | 4 ++-- 6 files changed, 12 insertions(+), 12 deletions(-) diff --git a/bin/named/xfrout.c b/bin/named/xfrout.c index fa134001a8..dc9298e233 100644 --- a/bin/named/xfrout.c +++ b/bin/named/xfrout.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: xfrout.c,v 1.117 2005/03/04 02:56:20 marka Exp $ */ +/* $Id: xfrout.c,v 1.118 2005/03/06 15:30:36 marka Exp $ */ #include diff --git a/lib/dns/compress.c b/lib/dns/compress.c index 2a6cbe9a04..8987ce2aae 100644 --- a/lib/dns/compress.c +++ b/lib/dns/compress.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: compress.c,v 1.53 2005/03/04 02:56:20 marka Exp $ */ +/* $Id: compress.c,v 1.54 2005/03/06 15:30:37 marka Exp $ */ #define DNS_NAME_USEINLINE 1 diff --git a/lib/dns/ds.c b/lib/dns/ds.c index 7bcf1fb37e..1e2aa20f72 100644 --- a/lib/dns/ds.c +++ b/lib/dns/ds.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2002, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: ds.c,v 1.5 2005/03/04 03:53:20 marka Exp $ */ +/* $Id: ds.c,v 1.6 2005/03/06 15:30:37 marka Exp $ */ #include diff --git a/lib/dns/include/dns/compress.h b/lib/dns/include/dns/compress.h index 29d903e0ec..c43e9dd95a 100644 --- a/lib/dns/include/dns/compress.h +++ b/lib/dns/include/dns/compress.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: compress.h,v 1.33 2005/03/04 02:56:21 marka Exp $ */ +/* $Id: compress.h,v 1.34 2005/03/06 15:30:37 marka Exp $ */ #ifndef DNS_COMPRESS_H #define DNS_COMPRESS_H 1 diff --git a/lib/dns/include/dns/ds.h b/lib/dns/include/dns/ds.h index 3e2f7a90fe..54a4c2f948 100644 --- a/lib/dns/include/dns/ds.h +++ b/lib/dns/include/dns/ds.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: ds.h,v 1.4 2005/03/04 03:53:21 marka Exp $ */ +/* $Id: ds.h,v 1.5 2005/03/06 15:30:37 marka Exp $ */ #ifndef DNS_DS_H #define DNS_DS_H 1 diff --git a/lib/dns/include/dns/resolver.h b/lib/dns/include/dns/resolver.h index 1aaa335be0..13cdd4a3a1 100644 --- a/lib/dns/include/dns/resolver.h +++ b/lib/dns/include/dns/resolver.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2001, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: resolver.h,v 1.42 2005/03/04 03:53:22 marka Exp $ */ +/* $Id: resolver.h,v 1.43 2005/03/06 15:30:37 marka Exp $ */ #ifndef DNS_RESOLVER_H #define DNS_RESOLVER_H 1 From 989d7b844bdf2d804fda57b9b53a4eff3a6bea91 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 14 Mar 2005 23:25:17 +0000 Subject: [PATCH 113/130] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index f9c2a21702..d19816ad0a 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1821. [placeholder] + 1820. [placeholder] rt13659 1819. [bug] The validator needed to check both the algorithm and From 93f429295a682f44940c8f4e2b05773c50da4e7d Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 14 Mar 2005 23:36:04 +0000 Subject: [PATCH 114/130] 1791. [bug] 'host -t a' still printed out AAAA and MX records. [RT #13230] --- CHANGES | 3 ++- bin/dig/host.c | 4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/CHANGES b/CHANGES index d19816ad0a..6ce3f82308 100644 --- a/CHANGES +++ b/CHANGES @@ -72,7 +72,8 @@ 1792. [func] New zone option "notify-delay". Specify a minimum delay between sets of NOTIFY messages. -1791. [placeholder] rt13230 +1791. [bug] 'host -t a' still printed out AAAA and MX records. + [RT #13230] 1790. [cleanup] Move lib/dns/sec/dst up into lib/dns. This should allow parallel make to succeed. diff --git a/bin/dig/host.c b/bin/dig/host.c index 18134020f2..1f2bea6531 100644 --- a/bin/dig/host.c +++ b/bin/dig/host.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: host.c,v 1.99 2004/11/10 22:04:25 marka Exp $ */ +/* $Id: host.c,v 1.100 2005/03/14 23:36:04 marka Exp $ */ #include #include @@ -580,6 +580,7 @@ pre_parse_args(int argc, char **argv) { } } isc_commandline_reset = ISC_TRUE; + isc_commandline_index = 1; } static void @@ -648,6 +649,7 @@ parse_args(isc_boolean_t is_batchfile, int argc, char **argv) { } else list_type = rdtype; list_addresses = ISC_FALSE; + default_lookups = ISC_FALSE; break; case 'c': tr.base = isc_commandline_argument; From 4038ab55037184d76153afd3c469aa8c85adf85d Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 14 Mar 2005 23:39:20 +0000 Subject: [PATCH 115/130] newcopyrights --- util/copyrights | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util/copyrights b/util/copyrights index cb7a55187b..f4bc25327d 100644 --- a/util/copyrights +++ b/util/copyrights @@ -34,7 +34,7 @@ ./bin/dig/dig.html HTML 2000,2001,2002,2003,2004 ./bin/dig/dighost.c C 2000,2001,2002,2003,2004 ./bin/dig/host.1 MAN 2000,2001,2002,2004 -./bin/dig/host.c C 2000,2001,2002,2003,2004 +./bin/dig/host.c C 2000,2001,2002,2003,2004,2005 ./bin/dig/host.docbook SGML 2000,2001,2002,2004 ./bin/dig/host.html HTML 2000,2001,2002,2004 ./bin/dig/include/dig/dig.h C 2000,2001,2002,2003,2004 From b101c1e9989d0a010a3146ad823e168d15cb10c7 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 14 Mar 2005 23:41:29 +0000 Subject: [PATCH 116/130] 1822. [bug] check-names test for RT was reversed. [RT #13382] --- CHANGES | 2 ++ lib/dns/rdata/generic/rt_21.c | 4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/CHANGES b/CHANGES index 6ce3f82308..9188b26b1f 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1822. [bug] check-names test for RT was reversed. [RT #13382] + 1821. [placeholder] 1820. [placeholder] rt13659 diff --git a/lib/dns/rdata/generic/rt_21.c b/lib/dns/rdata/generic/rt_21.c index 05b250471b..2f334056ec 100644 --- a/lib/dns/rdata/generic/rt_21.c +++ b/lib/dns/rdata/generic/rt_21.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rt_21.c,v 1.41 2004/03/05 05:10:17 marka Exp $ */ +/* $Id: rt_21.c,v 1.42 2005/03/14 23:41:29 marka Exp $ */ /* reviewed: Thu Mar 16 15:02:31 PST 2000 by brister */ @@ -300,7 +300,7 @@ checknames_rt(ARGS_CHECKNAMES) { isc_region_consume(®ion, 2); dns_name_init(&name, NULL); dns_name_fromregion(&name, ®ion); - if (dns_name_ishostname(&name, ISC_FALSE)) { + if (!dns_name_ishostname(&name, ISC_FALSE)) { if (bad != NULL) dns_name_clone(&name, bad); return (ISC_FALSE); From b326d7e3a3a50eb65dd06db007d2fddc62606bbf Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 14 Mar 2005 23:55:57 +0000 Subject: [PATCH 117/130] 1795. [bug] "rndc dumpb" was not fully documented. Minor formating issues with "rndc dumpdb -all". [RT #13396] --- CHANGES | 3 ++- bin/named/server.c | 27 +++++++++++++++++++++++---- bin/rndc/rndc.c | 5 +++-- 3 files changed, 28 insertions(+), 7 deletions(-) diff --git a/CHANGES b/CHANGES index 9188b26b1f..ec1bfcce2d 100644 --- a/CHANGES +++ b/CHANGES @@ -64,7 +64,8 @@ 1796. [func] "rndc freeze/thaw" now freezes/thaws all zones. -1795. [placeholder] rt13396 +1795. [bug] "rndc dumpb" was not fully documented. Minor + formating issues with "rndc dumpdb -all". [RT #13396] 1794. [func] Named and named-checkzone can now both check for non-terminal wildcard records. diff --git a/bin/named/server.c b/bin/named/server.c index 62394c121b..34112712c5 100644 --- a/bin/named/server.c +++ b/bin/named/server.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.c,v 1.438 2005/01/17 00:46:01 marka Exp $ */ +/* $Id: server.c,v 1.439 2005/03/14 23:55:56 marka Exp $ */ #include @@ -3714,6 +3714,15 @@ add_view_tolist(struct dumpcontext *dctx, dns_view_t *view) { struct viewlistentry *vle; isc_result_t result = ISC_R_SUCCESS; + /* + * Prevent duplicate views. + */ + for (vle = ISC_LIST_HEAD(dctx->viewlist); + vle != NULL; + vle = ISC_LIST_NEXT(vle, link)) + if (vle->view == view) + return (ISC_R_SUCCESS); + vle = isc_mem_get(dctx->mctx, sizeof *vle); if (vle == NULL) return (ISC_R_NOMEMORY); @@ -3777,9 +3786,11 @@ dumpdone(void *arg, isc_result_t result) { if (dctx->view == NULL) goto done; INSIST(dctx->zone == NULL); - } + } else + goto resume; nextview: fprintf(dctx->fp, ";\n; Start view %s\n;\n", dctx->view->view->name); + resume: if (dctx->zone == NULL && dctx->cache == NULL && dctx->dumpcache) { style = &dns_master_style_cache; /* start cache dump */ @@ -3840,9 +3851,12 @@ dumpdone(void *arg, isc_result_t result) { &dctx->mdctx); if (result == DNS_R_CONTINUE) return; - if (result == ISC_R_NOTIMPLEMENTED) + if (result == ISC_R_NOTIMPLEMENTED) { fprintf(dctx->fp, "; %s\n", dns_result_totext(result)); + result = ISC_R_SUCCESS; + goto nextzone; + } if (result != ISC_R_SUCCESS) goto cleanup; } @@ -3866,7 +3880,6 @@ dumpdone(void *arg, isc_result_t result) { dumpcontext_destroy(dctx); } - isc_result_t ns_server_dumpdb(ns_server_t *server, char *args) { struct dumpcontext *dctx = NULL; @@ -3922,6 +3935,7 @@ ns_server_dumpdb(ns_server_t *server, char *args) { ptr = next_token(&args, " \t"); } + nextview: for (view = ISC_LIST_HEAD(server->viewlist); view != NULL; view = ISC_LIST_NEXT(view, link)) @@ -3930,6 +3944,11 @@ ns_server_dumpdb(ns_server_t *server, char *args) { continue; CHECK(add_view_tolist(dctx, view)); } + if (ptr != NULL) { + ptr = next_token(&args, " \t"); + if (ptr != NULL) + goto nextview; + } dumpdone(dctx, ISC_R_SUCCESS); return (ISC_R_SUCCESS); diff --git a/bin/rndc/rndc.c b/bin/rndc/rndc.c index ebe7304acf..9212e1f394 100644 --- a/bin/rndc/rndc.c +++ b/bin/rndc/rndc.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rndc.c,v 1.103 2005/02/23 01:06:36 marka Exp $ */ +/* $Id: rndc.c,v 1.104 2005/03/14 23:55:57 marka Exp $ */ /* * Principal Author: DCL @@ -111,7 +111,8 @@ command is one of the following:\n\ reconfig Reload configuration file and new zones only.\n\ stats Write server statistics to the statistics file.\n\ querylog Toggle query logging.\n\ - dumpdb Dump cache(s) to the dump file (named_dump.db).\n\ + dumpdb [-all|-cache|-zones] [view ...]\n\ + Dump cache(s) to the dump file (named_dump.db).\n\ stop Save pending updates to master files and stop the server.\n\ stop -p Save pending updates to master files and stop the server\n\ reporting process id.\n\ From 5a4854e226ce5eca99bcfb5557b36ea210bb25bc Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 15 Mar 2005 00:09:07 +0000 Subject: [PATCH 118/130] 1823. [bug] Wrong macro used to check for point to point interface. [RT#13418] --- CHANGES | 3 +++ lib/isc/unix/ifiter_sysctl.c | 4 ++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/CHANGES b/CHANGES index ec1bfcce2d..666ee3a295 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,6 @@ +1823. [bug] Wrong macro used to check for point to point interface. + [RT#13418] + 1822. [bug] check-names test for RT was reversed. [RT #13382] 1821. [placeholder] diff --git a/lib/isc/unix/ifiter_sysctl.c b/lib/isc/unix/ifiter_sysctl.c index e2902b9f05..d39c3ec49c 100644 --- a/lib/isc/unix/ifiter_sysctl.c +++ b/lib/isc/unix/ifiter_sysctl.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: ifiter_sysctl.c,v 1.20 2004/03/05 05:11:45 marka Exp $ */ +/* $Id: ifiter_sysctl.c,v 1.21 2005/03/15 00:09:07 marka Exp $ */ /* * Obtain the list of network interfaces using sysctl. @@ -251,7 +251,7 @@ internal_current(isc_interfaceiter_t *iter) { iter->current.name); if (dst_sa != NULL && - (iter->current.flags & IFF_POINTOPOINT) != 0) + (iter->current.flags & INTERFACE_F_POINTTOPOINT) != 0) get_addr(family, &iter->current.dstaddress, dst_sa, iter->current.name); From bc29bb9062ab804cd79f4a1f8f366af8a040b636 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 15 Mar 2005 00:20:59 +0000 Subject: [PATCH 119/130] 1824. [bug] Memory leak on dns_zone_setdbtype() failure. [RT #13510] --- CHANGES | 3 +++ lib/dns/zone.c | 5 +++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/CHANGES b/CHANGES index 666ee3a295..720ef4eaa2 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,6 @@ +1824. [bug] Memory leak on dns_zone_setdbtype() failure. + [RT #13510] + 1823. [bug] Wrong macro used to check for point to point interface. [RT#13418] diff --git a/lib/dns/zone.c b/lib/dns/zone.c index 9dcea3dae1..7bbaec0d5c 100644 --- a/lib/dns/zone.c +++ b/lib/dns/zone.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.c,v 1.431 2005/02/10 05:53:42 marka Exp $ */ +/* $Id: zone.c,v 1.432 2005/03/15 00:20:59 marka Exp $ */ #include @@ -606,7 +606,8 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) { free_mutex: DESTROYLOCK(&zone->lock); - return (ISC_R_NOMEMORY); + isc_mem_putanddetach(&zone->mctx, zone, sizeof(*zone)); + return (result); } /* From 3cbc87c31f76262980d54ddbcdda7875be37b684 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 15 Mar 2005 00:32:42 +0000 Subject: [PATCH 120/130] 1825. [bug] Missing unlock on out of memory error from in rbtdb.c:subtractrdataset(). [RT #13519] --- CHANGES | 3 +++ lib/dns/rbtdb.c | 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/CHANGES b/CHANGES index 720ef4eaa2..17f266f88b 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,6 @@ +1825. [bug] Missing unlock on out of memory error from in + rbtdb.c:subtractrdataset(). [RT #13519] + 1824. [bug] Memory leak on dns_zone_setdbtype() failure. [RT #13510] diff --git a/lib/dns/rbtdb.c b/lib/dns/rbtdb.c index 30959ddaa5..4f334d7f7e 100644 --- a/lib/dns/rbtdb.c +++ b/lib/dns/rbtdb.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rbtdb.c,v 1.201 2004/12/21 10:45:17 jinmei Exp $ */ +/* $Id: rbtdb.c,v 1.202 2005/03/15 00:32:42 marka Exp $ */ /* * Principal Author: Bob Halley @@ -4435,6 +4435,7 @@ subtractrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version, changed = add_changed(rbtdb, rbtversion, rbtnode); if (changed == NULL) { free_rdataset(rbtdb->common.mctx, newheader); + UNLOCK(&rbtdb->node_locks[rbtnode->locknum].lock); return (ISC_R_NOMEMORY); } From a2037d7177cfb137b6cfed8ce99cad184dc0004b Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 15 Mar 2005 00:46:29 +0000 Subject: [PATCH 121/130] style --- bin/named/client.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/bin/named/client.c b/bin/named/client.c index c8d168132b..d33620a819 100644 --- a/bin/named/client.c +++ b/bin/named/client.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: client.c,v 1.224 2005/02/11 00:01:57 marka Exp $ */ +/* $Id: client.c,v 1.225 2005/03/15 00:46:29 marka Exp $ */ #include @@ -1661,8 +1661,7 @@ client_timeout(isc_task_t *task, isc_event_t *event) { } static isc_result_t -client_create(ns_clientmgr_t *manager, ns_client_t **clientp) -{ +client_create(ns_clientmgr_t *manager, ns_client_t **clientp) { ns_client_t *client; isc_result_t result; From 52188225731669cd571984c45a1407a55c74ee78 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 15 Mar 2005 01:11:01 +0000 Subject: [PATCH 122/130] 1826. [bug] Missing DESTROYLOCK() in isc_mem_createx() on out of memory error. [RT #13537] --- CHANGES | 7 +++++-- lib/isc/mem.c | 29 +++++++++++++++-------------- 2 files changed, 20 insertions(+), 16 deletions(-) diff --git a/CHANGES b/CHANGES index 17f266f88b..b2fa4d3545 100644 --- a/CHANGES +++ b/CHANGES @@ -1,5 +1,8 @@ -1825. [bug] Missing unlock on out of memory error from in - rbtdb.c:subtractrdataset(). [RT #13519] +1826. [bug] Missing DESTROYLOCK() in isc_mem_createx() on out + of memory error. [RT #13537] + +1825. [bug] Missing UNLOCK() on out of memory error from in + rbtdb.c:subtractrdataset(). [RT #13519] 1824. [bug] Memory leak on dns_zone_setdbtype() failure. [RT #13510] diff --git a/lib/isc/mem.c b/lib/isc/mem.c index 059a2b32b7..4643459d47 100644 --- a/lib/isc/mem.c +++ b/lib/isc/mem.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: mem.c,v 1.116 2004/03/18 02:58:06 marka Exp $ */ +/* $Id: mem.c,v 1.117 2005/03/15 01:11:01 marka Exp $ */ #include @@ -717,6 +717,15 @@ isc_mem_createx(size_t init_max_size, size_t target_size, if (ctx == NULL) return (ISC_R_NOMEMORY); + if (isc_mutex_init(&ctx->lock) != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_mutex_init() %s", + isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL, + ISC_MSG_FAILED, "failed")); + (memfree)(arg, ctx); + return (ISC_R_UNEXPECTED); + } + if (init_max_size == 0U) ctx->max_size = DEF_MAX_SIZE; else @@ -775,15 +784,6 @@ isc_mem_createx(size_t init_max_size, size_t target_size, ctx->highest = NULL; #endif /* ISC_MEM_USE_INTERNAL_MALLOC */ - if (isc_mutex_init(&ctx->lock) != ISC_R_SUCCESS) { - UNEXPECTED_ERROR(__FILE__, __LINE__, - "isc_mutex_init() %s", - isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL, - ISC_MSG_FAILED, "failed")); - result = ISC_R_UNEXPECTED; - goto error; - } - #if ISC_MEM_TRACKLINES if ((isc_mem_debugging & ISC_MEM_DEBUGRECORD) != 0) { unsigned int i; @@ -805,17 +805,18 @@ isc_mem_createx(size_t init_max_size, size_t target_size, return (ISC_R_SUCCESS); error: - if (ctx) { - if (ctx->stats) + if (ctx != NULL) { + if (ctx->stats != NULL) (memfree)(arg, ctx->stats); #if ISC_MEM_USE_INTERNAL_MALLOC - if (ctx->freelists) + if (ctx->freelists != NULL) (memfree)(arg, ctx->freelists); #endif /* ISC_MEM_USE_INTERNAL_MALLOC */ #if ISC_MEM_TRACKLINES - if (ctx->debuglist) + if (ctx->debuglist != NULL) (ctx->memfree)(ctx->arg, ctx->debuglist); #endif /* ISC_MEM_TRACKLINES */ + DESTROYLOCK(&ctx->lock); (memfree)(arg, ctx); } From e50b75e36ca79f84e2c9b2a12f6e28cbf22aaa83 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 15 Mar 2005 01:29:10 +0000 Subject: [PATCH 123/130] 1804. [bug] Ensure that if we are queried for glue that it fits in the additional section or TC is set to tell the client to retry using TCP. [RT #10114] --- CHANGES | 4 ++- bin/named/query.c | 40 ++++++++++++++++++++++++- lib/dns/include/dns/rdataset.h | 35 +++++++++++----------- lib/dns/message.c | 53 +++++++++++++++++++++++++++++++++- 4 files changed, 112 insertions(+), 20 deletions(-) diff --git a/CHANGES b/CHANGES index b2fa4d3545..a31feab484 100644 --- a/CHANGES +++ b/CHANGES @@ -54,7 +54,9 @@ 1805. [bug] Pending status was not being cleared when DLV was active. [RT #13501] -1804. [placeholder] rt10114 +1804. [bug] Ensure that if we are queried for glue that it fits + in the additional section or TC is set to tell the + client to retry using TCP. [RT #10114] 1803. [placeholder] rt13483 diff --git a/bin/named/query.c b/bin/named/query.c index 62f9ffacea..119ecbc476 100644 --- a/bin/named/query.c +++ b/bin/named/query.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: query.c,v 1.262 2004/12/21 10:45:15 jinmei Exp $ */ +/* $Id: query.c,v 1.263 2005/03/15 01:29:09 marka Exp $ */ #include @@ -2886,6 +2886,34 @@ query_addnoqnameproof(ns_client_t *client, dns_rdataset_t *rdataset) { query_releasename(client, &fname); } +static inline void +answer_in_glue(ns_client_t *client, dns_rdatatype_t qtype) { + dns_name_t *name; + dns_message_t *msg; + dns_section_t section = DNS_SECTION_ADDITIONAL; + dns_rdataset_t *rdataset = NULL; + + msg = client->message; + for (name = ISC_LIST_HEAD(msg->sections[section]); + name != NULL; + name = ISC_LIST_NEXT(name, link)) + if (dns_name_equal(name, client->query.qname)) { + for (rdataset = ISC_LIST_HEAD(name->list); + rdataset != NULL; + rdataset = ISC_LIST_NEXT(rdataset, link)) + if (rdataset->type == qtype) + break; + break; + } + if (rdataset != NULL) { + ISC_LIST_UNLINK(msg->sections[section], name, link); + ISC_LIST_PREPEND(msg->sections[section], name, link); + ISC_LIST_UNLINK(name->list, rdataset, link); + ISC_LIST_PREPEND(name->list, rdataset, link); + rdataset->attributes |= DNS_RDATASETATTR_REQUIREDGLUE; + } +} + /* * Do the bulk of query processing for the current query of 'client'. * If 'event' is non-NULL, we are returning from recursion and 'qtype' @@ -3906,6 +3934,16 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) */ setup_query_sortlist(client); + /* + * If this is a referral and the answer to the question + * is in the glue sort it to the start of the additional + * section. + */ + if (client->message->counts[DNS_SECTION_ANSWER] == 0 && + client->message->rcode == dns_rcode_noerror && + (qtype == dns_rdatatype_a || qtype == dns_rdatatype_aaaa)) + answer_in_glue(client, qtype); + if (client->message->rcode == dns_rcode_nxdomain && client->view->auth_nxdomain == ISC_TRUE) client->message->flags |= DNS_MESSAGEFLAG_AA; diff --git a/lib/dns/include/dns/rdataset.h b/lib/dns/include/dns/rdataset.h index a286600bad..1b932d8e19 100644 --- a/lib/dns/include/dns/rdataset.h +++ b/lib/dns/include/dns/rdataset.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rdataset.h,v 1.52 2004/12/21 10:45:19 jinmei Exp $ */ +/* $Id: rdataset.h,v 1.53 2005/03/15 01:29:10 marka Exp $ */ #ifndef DNS_RDATASET_H #define DNS_RDATASET_H 1 @@ -161,22 +161,23 @@ struct dns_rdataset { * Used by message.c to indicate that the rdataset's rdata had differing * TTL values, and the rdataset->ttl holds the smallest. */ -#define DNS_RDATASETATTR_QUESTION 0x0001 -#define DNS_RDATASETATTR_RENDERED 0x0002 /* Used by message.c */ -#define DNS_RDATASETATTR_ANSWERED 0x0004 /* Used by server. */ -#define DNS_RDATASETATTR_CACHE 0x0008 /* Used by resolver. */ -#define DNS_RDATASETATTR_ANSWER 0x0010 /* Used by resolver. */ -#define DNS_RDATASETATTR_ANSWERSIG 0x0020 /* Used by resolver. */ -#define DNS_RDATASETATTR_EXTERNAL 0x0040 /* Used by resolver. */ -#define DNS_RDATASETATTR_NCACHE 0x0080 /* Used by resolver. */ -#define DNS_RDATASETATTR_CHAINING 0x0100 /* Used by resolver. */ -#define DNS_RDATASETATTR_TTLADJUSTED 0x0200 /* Used by message.c */ -#define DNS_RDATASETATTR_FIXEDORDER 0x0400 -#define DNS_RDATASETATTR_RANDOMIZE 0x0800 -#define DNS_RDATASETATTR_CHASE 0x1000 /* Used by resolver. */ -#define DNS_RDATASETATTR_NXDOMAIN 0x2000 -#define DNS_RDATASETATTR_NOQNAME 0x4000 -#define DNS_RDATASETATTR_CHECKNAMES 0x8000 /* Used by resolver. */ +#define DNS_RDATASETATTR_QUESTION 0x00000001 +#define DNS_RDATASETATTR_RENDERED 0x00000002 /* Used by message.c */ +#define DNS_RDATASETATTR_ANSWERED 0x00000004 /* Used by server. */ +#define DNS_RDATASETATTR_CACHE 0x00000008 /* Used by resolver. */ +#define DNS_RDATASETATTR_ANSWER 0x00000010 /* Used by resolver. */ +#define DNS_RDATASETATTR_ANSWERSIG 0x00000020 /* Used by resolver. */ +#define DNS_RDATASETATTR_EXTERNAL 0x00000040 /* Used by resolver. */ +#define DNS_RDATASETATTR_NCACHE 0x00000080 /* Used by resolver. */ +#define DNS_RDATASETATTR_CHAINING 0x00000100 /* Used by resolver. */ +#define DNS_RDATASETATTR_TTLADJUSTED 0x00000200 /* Used by message.c */ +#define DNS_RDATASETATTR_FIXEDORDER 0x00000400 +#define DNS_RDATASETATTR_RANDOMIZE 0x00000800 +#define DNS_RDATASETATTR_CHASE 0x00001000 /* Used by resolver. */ +#define DNS_RDATASETATTR_NXDOMAIN 0x00002000 +#define DNS_RDATASETATTR_NOQNAME 0x00004000 +#define DNS_RDATASETATTR_CHECKNAMES 0x00008000 /* Used by resolver. */ +#define DNS_RDATASETATTR_REQUIREDGLUE 0x00010000 /* * _OMITDNSSEC: diff --git a/lib/dns/message.c b/lib/dns/message.c index e13c544f98..735e72b038 100644 --- a/lib/dns/message.c +++ b/lib/dns/message.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: message.c,v 1.223 2004/05/05 01:32:58 marka Exp $ */ +/* $Id: message.c,v 1.224 2005/03/15 01:29:09 marka Exp $ */ /*** *** Imports @@ -1783,6 +1783,57 @@ dns_message_rendersection(dns_message_t *msg, dns_section_t sectionid, if (msg->reserved == 0 && (options & DNS_MESSAGERENDER_PARTIAL) != 0) partial = ISC_TRUE; + /* + * Render required glue first. Set TC if it won't fit. + */ + name = ISC_LIST_HEAD(*section); + if (name != NULL) { + rdataset = ISC_LIST_HEAD(name->list); + if (rdataset != NULL && + (rdataset->attributes & DNS_RDATASETATTR_REQUIREDGLUE) != 0 && + (rdataset->attributes & DNS_RDATASETATTR_RENDERED) == 0) { + void *order_arg = msg->order_arg; + st = *(msg->buffer); + count = 0; + if (partial) + result = dns_rdataset_towirepartial(rdataset, + name, + msg->cctx, + msg->buffer, + msg->order, + order_arg, + rd_options, + &count, + NULL); + else + result = dns_rdataset_towiresorted(rdataset, + name, + msg->cctx, + msg->buffer, + msg->order, + order_arg, + rd_options, + &count); + total += count; + if (partial && result == ISC_R_NOSPACE) { + msg->flags |= DNS_MESSAGEFLAG_TC; + msg->buffer->length += msg->reserved; + msg->counts[sectionid] += total; + return (result); + } + if (result != ISC_R_SUCCESS) { + INSIST(st.used < 65536); + dns_compress_rollback(msg->cctx, + (isc_uint16_t)st.used); + *(msg->buffer) = st; /* rollback */ + msg->buffer->length += msg->reserved; + msg->counts[sectionid] += total; + return (result); + } + rdataset->attributes |= DNS_RDATASETATTR_RENDERED; + } + } + do { name = ISC_LIST_HEAD(*section); if (name == NULL) { From 8cd830d7c806cac681b057e0c0185f29992fa35f Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 15 Mar 2005 01:41:28 +0000 Subject: [PATCH 124/130] 1802. [bug] Handle connection resets better. [RT #11280] --- CHANGES | 2 +- lib/dns/resolver.c | 3 ++- lib/isc/unix/socket.c | 13 +++++++++---- 3 files changed, 12 insertions(+), 6 deletions(-) diff --git a/CHANGES b/CHANGES index a31feab484..f803a20d88 100644 --- a/CHANGES +++ b/CHANGES @@ -60,7 +60,7 @@ 1803. [placeholder] rt13483 -1802. [placeholder] rt11280 +1802. [bug] Handle connection resets better. [RT #11280] 1801. [func] Report differences between hints and real NS rrset and associated address records. diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c index 5eaba1668b..eacbf94716 100644 --- a/lib/dns/resolver.c +++ b/lib/dns/resolver.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: resolver.c,v 1.304 2005/03/04 03:53:21 marka Exp $ */ +/* $Id: resolver.c,v 1.305 2005/03/15 01:41:28 marka Exp $ */ #include @@ -1427,6 +1427,7 @@ resquery_connected(isc_task_t *task, isc_event_t *event) { case ISC_R_CONNREFUSED: case ISC_R_NOPERM: case ISC_R_ADDRNOTAVAIL: + case ISC_R_CONNECTIONRESET: /* * No route to remote. */ diff --git a/lib/isc/unix/socket.c b/lib/isc/unix/socket.c index c0f045c45e..6f8eb5f08b 100644 --- a/lib/isc/unix/socket.c +++ b/lib/isc/unix/socket.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: socket.c,v 1.245 2005/02/24 00:33:34 marka Exp $ */ +/* $Id: socket.c,v 1.246 2005/03/15 01:41:28 marka Exp $ */ #include @@ -284,7 +284,7 @@ socket_log(isc_socket_t *sock, isc_sockaddr_t *address, const char *fmt, ...) { char msgbuf[2048]; - char peerbuf[256]; + char peerbuf[ISC_SOCKADDR_FORMATSIZE]; va_list ap; if (! isc_log_wouldlog(isc_lctx, level)) @@ -3294,6 +3294,7 @@ isc_socket_connect(isc_socket_t *sock, isc_sockaddr_t *addr, ERROR_MATCH(ENOBUFS, ISC_R_NORESOURCES); ERROR_MATCH(EPERM, ISC_R_HOSTUNREACH); ERROR_MATCH(EPIPE, ISC_R_NOTCONNECTED); + ERROR_MATCH(ECONNRESET, ISC_R_CONNECTIONRESET); #undef ERROR_MATCH } @@ -3363,6 +3364,7 @@ internal_connect(isc_task_t *me, isc_event_t *ev) { int cc; ISC_SOCKADDR_LEN_T optlen; char strbuf[ISC_STRERRORSIZE]; + char peerbuf[ISC_SOCKADDR_FORMATSIZE]; UNUSED(me); INSIST(ev->ev_type == ISC_SOCKEVENT_INTW); @@ -3439,13 +3441,16 @@ internal_connect(isc_task_t *me, isc_event_t *ev) { ERROR_MATCH(EPERM, ISC_R_HOSTUNREACH); ERROR_MATCH(EPIPE, ISC_R_NOTCONNECTED); ERROR_MATCH(ETIMEDOUT, ISC_R_TIMEDOUT); + ERROR_MATCH(ECONNRESET, ISC_R_CONNECTIONRESET); #undef ERROR_MATCH default: dev->result = ISC_R_UNEXPECTED; + isc_sockaddr_format(&sock->address, peerbuf, + sizeof(peerbuf)); isc__strerror(errno, strbuf, sizeof(strbuf)); UNEXPECTED_ERROR(__FILE__, __LINE__, - "internal_connect: connect() %s", - strbuf); + "internal_connect: connect(%s) %s", + peerbuf, strbuf); } } else { dev->result = ISC_R_SUCCESS; From 5d3083c4b5b11dfb653b15fd0eeb8e0cc9b175e0 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 15 Mar 2005 01:49:30 +0000 Subject: [PATCH 125/130] 1827. [bug] host: update usage message for '-a'. [RT #37116] --- CHANGES | 2 ++ bin/dig/host.c | 4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/CHANGES b/CHANGES index f803a20d88..f11a430cf0 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1827. [bug] host: update usage message for '-a'. [RT #37116] + 1826. [bug] Missing DESTROYLOCK() in isc_mem_createx() on out of memory error. [RT #13537] diff --git a/bin/dig/host.c b/bin/dig/host.c index 1f2bea6531..5e6a2ea1fe 100644 --- a/bin/dig/host.c +++ b/bin/dig/host.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: host.c,v 1.100 2005/03/14 23:36:04 marka Exp $ */ +/* $Id: host.c,v 1.101 2005/03/15 01:49:30 marka Exp $ */ #include #include @@ -128,7 +128,7 @@ show_usage(void) { fputs( "Usage: host [-aCdlriTwv] [-c class] [-N ndots] [-t type] [-W time]\n" " [-R number] [-m flag] hostname [server]\n" -" -a is equivalent to -v -t *\n" +" -a is equivalent to -v -t ANY\n" " -c specifies query class for non-IN data\n" " -C compares SOA records on authoritative nameservers\n" " -d is equivalent to -v\n" From 7d9b632906c756b215d65a3a08d77fe022807c2d Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 15 Mar 2005 02:03:11 +0000 Subject: [PATCH 126/130] 1828. [bug] isc_rwlock_init() failed to properly cleanup if it encountered a error. [RT #13549] --- CHANGES | 3 +++ lib/isc/rwlock.c | 16 +++++++++++++--- 2 files changed, 16 insertions(+), 3 deletions(-) diff --git a/CHANGES b/CHANGES index f11a430cf0..1426b9b6fd 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,6 @@ +1828. [bug] isc_rwlock_init() failed to properly cleanup if it + encountered a error. [RT #13549] + 1827. [bug] host: update usage message for '-a'. [RT #37116] 1826. [bug] Missing DESTROYLOCK() in isc_mem_createx() on out diff --git a/lib/isc/rwlock.c b/lib/isc/rwlock.c index 638c854faa..887143910a 100644 --- a/lib/isc/rwlock.c +++ b/lib/isc/rwlock.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rwlock.c,v 1.37 2004/03/05 05:10:49 marka Exp $ */ +/* $Id: rwlock.c,v 1.38 2005/03/15 02:03:11 marka Exp $ */ #include @@ -109,7 +109,9 @@ isc_rwlock_init(isc_rwlock_t *rwl, unsigned int read_quota, isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL, ISC_MSG_FAILED, "failed"), isc_result_totext(result)); - return (ISC_R_UNEXPECTED); + result = ISC_R_UNEXPECTED; + goto destroy_lock; + } result = isc_condition_init(&rwl->writeable); if (result != ISC_R_SUCCESS) { @@ -118,12 +120,20 @@ isc_rwlock_init(isc_rwlock_t *rwl, unsigned int read_quota, isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL, ISC_MSG_FAILED, "failed"), isc_result_totext(result)); - return (ISC_R_UNEXPECTED); + result = ISC_R_UNEXPECTED; + goto destroy_rcond; } rwl->magic = RWLOCK_MAGIC; return (ISC_R_SUCCESS); + + destroy_rcond: + (void)isc_condition_destroy(&rwl->readable); + destroy_lock: + DESTROYLOCK(&rwl->lock); + + return (result); } static isc_result_t From cdb15282589682b664dfb70428a3c1750fe05250 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 15 Mar 2005 02:11:28 +0000 Subject: [PATCH 127/130] dumpb -> dumpdb --- CHANGES | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHANGES b/CHANGES index 1426b9b6fd..938eb6d5cd 100644 --- a/CHANGES +++ b/CHANGES @@ -83,7 +83,7 @@ 1796. [func] "rndc freeze/thaw" now freezes/thaws all zones. -1795. [bug] "rndc dumpb" was not fully documented. Minor +1795. [bug] "rndc dumpdb" was not fully documented. Minor formating issues with "rndc dumpdb -all". [RT #13396] 1794. [func] Named and named-checkzone can now both check for From e9aca33f362d017fe0d5f7b729bce646038cf1ee Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 15 Mar 2005 02:15:13 +0000 Subject: [PATCH 128/130] 1809. [bug] "make distclean" failed for libbind if the platform is not supported. --- CHANGES | 3 ++- lib/bind/port/unknown/include/Makefile.in | 5 +++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/CHANGES b/CHANGES index 938eb6d5cd..da745bcd43 100644 --- a/CHANGES +++ b/CHANGES @@ -45,7 +45,8 @@ 1810. [placeholder] rt13212 -1809. [placeholder] rt13463 +1809. [bug] "make distclean" failed for libbind if the platform + is not supported. 1808. [bug] zone.c:notify_zone() contained a race condition, zone->db could change underneath it. [RT #13511] diff --git a/lib/bind/port/unknown/include/Makefile.in b/lib/bind/port/unknown/include/Makefile.in index 99e5985489..5e3b7fd730 100644 --- a/lib/bind/port/unknown/include/Makefile.in +++ b/lib/bind/port/unknown/include/Makefile.in @@ -12,3 +12,8 @@ # 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. + +all: + exit 1 + +@BIND9_MAKE_RULES@ From e90994e3f358bdc6fe03005da08567c807a14c1d Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 15 Mar 2005 02:48:58 +0000 Subject: [PATCH 129/130] 1799. [bug] 'rndc flushname' failed to flush negative cache entries. [RT #13438] --- CHANGES | 3 ++- lib/dns/cache.c | 25 ++++--------------------- 2 files changed, 6 insertions(+), 22 deletions(-) diff --git a/CHANGES b/CHANGES index da745bcd43..6f0768a267 100644 --- a/CHANGES +++ b/CHANGES @@ -74,7 +74,8 @@ 1800. [bug] Changes #1719 allowed a INSIST to be triggered. [RT #13428] -1799. [placeholder] rt13438 +1799. [bug] 'rndc flushname' failed to flush negative cache + entries. [RT #13438] 1798. [func] The server syntax has been extended to support a range of servers. [RT #11132] diff --git a/lib/dns/cache.c b/lib/dns/cache.c index 8c6450a4aa..b0ee8e201d 100644 --- a/lib/dns/cache.c +++ b/lib/dns/cache.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: cache.c,v 1.57 2004/03/05 05:09:18 marka Exp $ */ +/* $Id: cache.c,v 1.58 2005/03/15 02:48:58 marka Exp $ */ #include @@ -1021,27 +1021,10 @@ dns_cache_flushname(dns_cache_t *cache, dns_name_t *name) { dns_rdataset_init(&rdataset); dns_rdatasetiter_current(iter, &rdataset); - - for (result = dns_rdataset_first(&rdataset); - result == ISC_R_SUCCESS; - result = dns_rdataset_next(&rdataset)) - { - dns_rdata_t rdata = DNS_RDATA_INIT; - dns_rdatatype_t covers; - - dns_rdataset_current(&rdataset, &rdata); - if (rdata.type == dns_rdatatype_rrsig) - covers = dns_rdata_covers(&rdata); - else - covers = 0; - result = dns_db_deleterdataset(cache->db, node, NULL, - rdata.type, covers); - if (result != ISC_R_SUCCESS && - result != DNS_R_UNCHANGED) - break; - } + result = dns_db_deleterdataset(cache->db, node, NULL, + rdataset.type, rdataset.covers); dns_rdataset_disassociate(&rdataset); - if (result != ISC_R_NOMORE) + if (result != ISC_R_SUCCESS && result != DNS_R_UNCHANGED) break; } if (result == ISC_R_NOMORE) From 9738408dcbd4c1f7eb2b105c83388608fafd7808 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 15 Mar 2005 22:58:49 +0000 Subject: [PATCH 130/130] 1810. [bug] configure, lib/bind/configure make different default decisions about whether to do a threaded build. [RT #13212] --- CHANGES | 4 +- config.threads.in | 152 ++++++++++++++++++++++++++++++++++++++++ configure.in | 156 +----------------------------------------- lib/bind/configure.in | 87 ++--------------------- 4 files changed, 161 insertions(+), 238 deletions(-) create mode 100644 config.threads.in diff --git a/CHANGES b/CHANGES index 6f0768a267..1e7d0cb6d6 100644 --- a/CHANGES +++ b/CHANGES @@ -43,7 +43,9 @@ 1811. [func] Preserve the case of domain names in rdata during zone transfers. [RT #13547] -1810. [placeholder] rt13212 +1810. [bug] configure, lib/bind/configure make different default + decisions about whether to do a threaded build. + [RT #13212] 1809. [bug] "make distclean" failed for libbind if the platform is not supported. diff --git a/config.threads.in b/config.threads.in new file mode 100644 index 0000000000..f2816c447f --- /dev/null +++ b/config.threads.in @@ -0,0 +1,152 @@ +# +# Begin pthreads checking. +# +# First, decide whether to use multithreading or not. +# +# Enable multithreading by default on systems where it is known +# to work well, and where debugging of multithreaded programs +# is supported. +# + +AC_MSG_CHECKING(whether to build with thread support) + +case $host in +*-dec-osf*) + use_threads=true ;; +[*-solaris2.[0-6]]) + # Thread signals are broken on Solaris 2.6; they are sometimes + # delivered to the wrong thread. + use_threads=false ;; +*-solaris*) + use_threads=true ;; +*-ibm-aix*) + use_threads=true ;; +*-hp-hpux10*) + use_threads=false ;; +*-hp-hpux11*) + use_threads=true ;; +*-sgi-irix*) + use_threads=true ;; +*-sco-sysv*uw*|*-*-sysv*UnixWare*) + # UnixWare + use_threads=false ;; +*-*-sysv*OpenUNIX*) + # UnixWare + use_threads=true ;; +*-netbsd*) + if test -r /usr/lib/libpthread.so ; then + use_threads=true + else + # Socket I/O optimizations introduced in 9.2 expose a + # bug in unproven-pthreads; see PR #12650 + use_threads=false + fi + ;; +*-openbsd*) + # OpenBSD users have reported that named dumps core on + # startup when built with threads. + use_threads=false ;; +*-freebsd*) + use_threads=false ;; +*-bsdi[234]*) + # Thread signals do not work reliably on some versions of BSD/OS. + use_threads=false ;; +*-bsdi5*) + use_threads=true ;; +*-linux*) + # Threads are disabled on Linux by default because most + # Linux kernels produce unusable core dumps from multithreaded + # programs, and because of limitations in setuid(). + use_threads=false ;; +*) + use_threads=false ;; +esac + +AC_ARG_ENABLE(threads, + [ --enable-threads enable multithreading]) +case "$enable_threads" in + yes) + use_threads=true + ;; + no) + use_threads=false + ;; + '') + # Use system-dependent default + ;; + *) + AC_MSG_ERROR([--enable-threads takes yes or no]) + ;; +esac + +if $use_threads +then + AC_MSG_RESULT(yes) +else + AC_MSG_RESULT(no) +fi + +if $use_threads +then + # + # Search for / configure pthreads in a system-dependent fashion. + # + case "$host" in + *-netbsd*) + # NetBSD has multiple pthreads implementations. The + # recommended one to use is "unproven-pthreads". The + # older "mit-pthreads" may also work on some NetBSD + # versions. The PTL2 thread library does not + # currently work with bind9, but can be chosen with + # the --with-ptl2 option for those who wish to + # experiment with it. + CC="gcc" + AC_MSG_CHECKING(which NetBSD thread library to use) + + AC_ARG_WITH(ptl2, +[ --with-ptl2 on NetBSD, use the ptl2 thread library (experimental)], + use_ptl2="$withval", use_ptl2="no") + + : ${LOCALBASE:=/usr/pkg} + + if test "X$use_ptl2" = "Xyes" + then + AC_MSG_RESULT(PTL2) + AC_MSG_WARN( +[linking with PTL2 is highly experimental and not expected to work]) + CC=ptlgcc + else + if test -r /usr/lib/libpthread.so + then + AC_MSG_RESULT(native) + LIBS="-lpthread $LIBS" + else + if test ! -d $LOCALBASE/pthreads + then + AC_MSG_RESULT(none) + AC_MSG_ERROR("could not find thread libraries") + fi + + if $use_threads + then + AC_MSG_RESULT(mit-pthreads/unproven-pthreads) + pkg="$LOCALBASE/pthreads" + lib1="-L$pkg/lib -Wl,-R$pkg/lib" + lib2="-lpthread -lm -lgcc -lpthread" + LIBS="$lib1 $lib2 $LIBS" + CPPFLAGS="$CPPFLAGS -I$pkg/include" + STD_CINCLUDES="$STD_CINCLUDES -I$pkg/include" + fi + fi + fi + ;; + *) + AC_CHECK_LIB(pthread, pthread_create,, + AC_CHECK_LIB(pthread, __pthread_create,, + AC_CHECK_LIB(pthread, __pthread_create_system,, + AC_CHECK_LIB(c_r, pthread_create,, + AC_CHECK_LIB(c, pthread_create,, + AC_MSG_ERROR("could not find thread libraries")))))) + ;; + esac +fi diff --git a/configure.in b/configure.in index 80d6b260ab..87b8bf6e76 100644 --- a/configure.in +++ b/configure.in @@ -18,7 +18,7 @@ AC_DIVERT_PUSH(1)dnl esyscmd([sed "s/^/# /" COPYRIGHT])dnl AC_DIVERT_POP()dnl -AC_REVISION($Revision: 1.373 $) +AC_REVISION($Revision: 1.374 $) AC_INIT(lib/dns/name.c) AC_PREREQ(2.13) @@ -608,158 +608,7 @@ esac # AC_CHECK_FUNC(arc4random, AC_DEFINE(HAVE_ARC4RANDOM)) -# -# Begin pthreads checking. -# -# First, decide whether to use multithreading or not. -# -# Enable multithreading by default on systems where it is known -# to work well, and where debugging of multithreaded programs -# is supported. -# - -AC_MSG_CHECKING(whether to build with thread support) - -case $host in -*-dec-osf*) - use_threads=true ;; -[*-solaris2.[0-6]]) - # Thread signals are broken on Solaris 2.6; they are sometimes - # delivered to the wrong thread. - use_threads=false ;; -*-solaris*) - use_threads=true ;; -*-ibm-aix*) - use_threads=true ;; -*-hp-hpux10*) - use_threads=false ;; -*-hp-hpux11*) - use_threads=true ;; -*-sgi-irix*) - use_threads=true ;; -*-sco-sysv*uw*|*-*-sysv*UnixWare*) - # UnixWare - use_threads=false ;; -*-*-sysv*OpenUNIX*) - # UnixWare - use_threads=true ;; -*-netbsd*) - if test -r /usr/lib/libpthread.so ; then - use_threads=true - else - # Socket I/O optimizations introduced in 9.2 expose a - # bug in unproven-pthreads; see PR #12650 - use_threads=false - fi - ;; -*-openbsd*) - # OpenBSD users have reported that named dumps core on - # startup when built with threads. - use_threads=false ;; -*-freebsd*) - use_threads=false ;; -*-bsdi[234]*) - # Thread signals do not work reliably on some versions of BSD/OS. - use_threads=false ;; -*-bsdi5*) - use_threads=true ;; -*-linux*) - # Threads are disabled on Linux by default because most - # Linux kernels produce unusable core dumps from multithreaded - # programs, and because of limitations in setuid(). - use_threads=false ;; -*) - use_threads=false ;; -esac - -AC_ARG_ENABLE(threads, - [ --enable-threads enable multithreading]) -case "$enable_threads" in - yes) - use_threads=true - ;; - no) - use_threads=false - ;; - '') - # Use system-dependent default - ;; - *) - AC_MSG_ERROR([--enable-threads takes yes or no]) - ;; -esac - -if $use_threads -then - AC_MSG_RESULT(yes) -else - AC_MSG_RESULT(no) -fi - -if $use_threads -then - # - # Search for / configure pthreads in a system-dependent fashion. - # - case "$host" in - *-netbsd*) - # NetBSD has multiple pthreads implementations. The - # recommended one to use is "unproven-pthreads". The - # older "mit-pthreads" may also work on some NetBSD - # versions. The PTL2 thread library does not - # currently work with bind9, but can be chosen with - # the --with-ptl2 option for those who wish to - # experiment with it. - CC="gcc" - AC_MSG_CHECKING(which NetBSD thread library to use) - - AC_ARG_WITH(ptl2, -[ --with-ptl2 on NetBSD, use the ptl2 thread library (experimental)], - use_ptl2="$withval", use_ptl2="no") - - : ${LOCALBASE:=/usr/pkg} - - if test "X$use_ptl2" = "Xyes" - then - AC_MSG_RESULT(PTL2) - AC_MSG_WARN( -[linking with PTL2 is highly experimental and not expected to work]) - CC=ptlgcc - else - if test -r /usr/lib/libpthread.so - then - AC_MSG_RESULT(native) - LIBS="-lpthread $LIBS" - else - if test ! -d $LOCALBASE/pthreads - then - AC_MSG_RESULT(none) - AC_MSG_ERROR("could not find thread libraries") - fi - - if $use_threads - then - AC_MSG_RESULT(mit-pthreads/unproven-pthreads) - pkg="$LOCALBASE/pthreads" - lib1="-L$pkg/lib -Wl,-R$pkg/lib" - lib2="-lpthread -lm -lgcc -lpthread" - LIBS="$lib1 $lib2 $LIBS" - CPPFLAGS="$CPPFLAGS -I$pkg/include" - STD_CINCLUDES="$STD_CINCLUDES -I$pkg/include" - fi - fi - fi - ;; - *) - AC_CHECK_LIB(pthread, pthread_create,, - AC_CHECK_LIB(pthread, __pthread_create,, - AC_CHECK_LIB(pthread, __pthread_create_system,, - AC_CHECK_LIB(c_r, pthread_create,, - AC_CHECK_LIB(c, pthread_create,, - AC_MSG_ERROR("could not find thread libraries")))))) - ;; - esac -fi +sinclude(config.threads.in)dnl if $use_threads then @@ -884,7 +733,6 @@ fi AC_SUBST(ALWAYS_DEFINES) AC_SUBST(ISC_PLATFORM_USETHREADS) - ISC_THREAD_DIR=$thread_dir AC_SUBST(ISC_THREAD_DIR) diff --git a/lib/bind/configure.in b/lib/bind/configure.in index 19a8fb9ea5..6017dcbfd4 100644 --- a/lib/bind/configure.in +++ b/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.99 $) +AC_REVISION($Revision: 1.100 $) AC_INIT(resolv/herror.c) AC_PREREQ(2.13) @@ -315,86 +315,7 @@ case "$use_randomdev" in ;; esac -# -# Begin pthreads checking. -# -# First, decide whether to use multithreading or not. -# -AC_MSG_CHECKING(whether to look for thread support) -AC_ARG_ENABLE(threads, - [ --disable-threads disable multithreading]) -case "$enable_threads" in - yes|'') - AC_MSG_RESULT(yes) - use_threads=true - ;; - no) - AC_MSG_RESULT(no) - use_threads=false - ;; - *) - AC_MSG_ERROR([--enable-threads takes yes or no]) - ;; -esac - -if $use_threads -then - # - # Search for / configure pthreads in a system-dependent fashion. - # - case "$host" in - *-netbsd*) - # NetBSD has multiple pthreads implementations. The - # recommended one to use is "unproven-pthreads". The - # older "mit-pthreads" may also work on some NetBSD - # versions. The PTL2 thread library does not - # currently work with bind9, but can be chosen with - # the --with-ptl2 option for those who wish to - # experiment with it. - CC="gcc" - AC_MSG_CHECKING(which NetBSD thread library to use) - - AC_ARG_WITH(ptl2, -[ --with-ptl2 on NetBSD, use the ptl2 thread library (experimental)], - use_ptl2="$withval", use_ptl2="no") - - : ${LOCALBASE:=/usr/pkg} - - if test "X$use_ptl2" = "Xyes" - then - AC_MSG_RESULT(PTL2) - AC_MSG_WARN( -[linking with PTL2 is highly experimental and not expected to work]) - CC=ptlgcc - else - if test ! -d $LOCALBASE/pthreads - then - AC_MSG_RESULT(none) - use_threads=false - fi - - if $use_threads - then - AC_MSG_RESULT(mit-pthreads/unproven-pthreads) - pkg="$LOCALBASE/pthreads" - lib1="-L$pkg/lib -Wl,-R$pkg/lib" - lib2="-lpthread -lm -lgcc -lpthread" - LIBS="$lib1 $lib2 $LIBS" - CPPFLAGS="$CPPFLAGS -I$pkg/include" - STD_CINCLUDES="$STD_CINCLUDES -I$pkg/include" - fi - fi - ;; - *) - AC_CHECK_LIB(pthread, pthread_create,, - AC_CHECK_LIB(pthread, __pthread_create,, - AC_CHECK_LIB(pthread, __pthread_create_system,, - AC_CHECK_LIB(c_r, pthread_create,, - AC_CHECK_LIB(c, pthread_create,, - use_threads=false))))) - ;; - esac -fi +sinclude(config.threads.in)dnl if $use_threads then @@ -520,8 +441,6 @@ else thread_dir=nothreads fi -AC_CHECK_FUNC(strlcat, AC_DEFINE(HAVE_STRLCAT)) - AC_SUBST(ALWAYS_DEFINES) AC_SUBST(DO_PTHREADS) AC_SUBST(WANT_IRS_THREADSGR_OBJS) @@ -529,6 +448,8 @@ AC_SUBST(WANT_IRS_THREADSPW_OBJS) AC_SUBST(WANT_IRS_THREADS_OBJS) AC_SUBST(WANT_THREADS_OBJS) +AC_CHECK_FUNC(strlcat, AC_DEFINE(HAVE_STRLCAT)) + AC_CHECK_FUNC(if_nametoindex, [USE_IFNAMELINKID="#define USE_IFNAMELINKID 1"], [USE_IFNAMELINKID="#undef USE_IFNAMELINKID"])