[Midnightbsd-cvs] src: contrib/bind9: Resolve conflicts.
laffer1 at midnightbsd.org
laffer1 at midnightbsd.org
Fri Apr 18 14:36:33 EDT 2008
Log Message:
-----------
Resolve conflicts.
Modified Files:
--------------
src/contrib/bind9:
CHANGES (r1.3 -> r1.4)
version (r1.3 -> r1.4)
src/contrib/bind9/bin/named:
client.c (r1.2 -> r1.3)
query.c (r1.3 -> r1.4)
src/contrib/bind9/lib/dns:
dispatch.c (r1.2 -> r1.3)
resolver.c (r1.4 -> r1.5)
validator.c (r1.2 -> r1.3)
src/contrib/bind9/lib/dns/include/dns:
dispatch.h (r1.2 -> r1.3)
validator.h (r1.2 -> r1.3)
Removed Files:
-------------
src/contrib/bind9/bin/named:
aclconf.c
src/contrib/bind9/bin/named/include/named:
aclconf.h
src/contrib/bind9/doc/draft:
draft-ietf-dnsext-dhcid-rr-09.txt
draft-ietf-dnsext-dnssec-online-signing-00.txt
draft-ietf-dnsext-insensitive-06.txt
draft-ietf-dnsext-nsec3-02.txt
draft-ietf-dnsext-trustupdate-timers-01.txt
draft-ietf-dnsext-tsig-sha-04.txt
draft-ietf-dnsext-wcard-clarify-08.txt
draft-ietf-dnsop-bad-dns-res-04.txt
draft-ietf-dnsop-dnssec-operational-practices-04.txt
draft-ietf-dnsop-serverid-04.txt
-------------- next part --------------
Index: client.c
===================================================================
RCS file: /home/cvs/src/contrib/bind9/bin/named/client.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -L contrib/bind9/bin/named/client.c -L contrib/bind9/bin/named/client.c -u -r1.2 -r1.3
--- contrib/bind9/bin/named/client.c
+++ contrib/bind9/bin/named/client.c
@@ -1,8 +1,8 @@
/*
- * Copyright (C) 2004-2006 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
*
@@ -15,13 +15,14 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: client.c,v 1.176.2.13.4.31 2006/07/22 01:09:38 marka Exp $ */
+/* $Id: client.c,v 1.219.18.28 2007/08/28 07:20:00 tbox Exp $ */
#include <config.h>
#include <isc/formatcheck.h>
#include <isc/mutex.h>
#include <isc/once.h>
+#include <isc/platform.h>
#include <isc/print.h>
#include <isc/stdio.h>
#include <isc/string.h>
@@ -33,12 +34,13 @@
#include <dns/dispatch.h>
#include <dns/events.h>
#include <dns/message.h>
+#include <dns/peer.h>
#include <dns/rcode.h>
-#include <dns/resolver.h>
#include <dns/rdata.h>
#include <dns/rdataclass.h>
#include <dns/rdatalist.h>
#include <dns/rdataset.h>
+#include <dns/resolver.h>
#include <dns/tsig.h>
#include <dns/view.h>
#include <dns/zone.h>
@@ -53,7 +55,9 @@
*** Client
***/
-/*
+/*! \file
+ * Client Routines
+ *
* Important note!
*
* All client state changes, other than that from idle to listening, occur
@@ -87,6 +91,25 @@
#define SEND_BUFFER_SIZE 4096
#define RECV_BUFFER_SIZE 4096
+#ifdef ISC_PLATFORM_USETHREADS
+#define NMCTXS 100
+/*%<
+ * Number of 'mctx pools' for clients. (Should this be configurable?)
+ * When enabling threads, we use a pool of memory contexts shared by
+ * client objects, since concurrent access to a shared context would cause
+ * heavy contentions. The above constant is expected to be enough for
+ * completely avoiding contentions among threads for an authoritative-only
+ * server.
+ */
+#else
+#define NMCTXS 0
+/*%<
+ * If named with built without thread, simply share manager's context. Using
+ * a separate context in this case would simply waste memory.
+ */
+#endif
+
+/*% nameserver client manager structure */
struct ns_clientmgr {
/* Unlocked. */
unsigned int magic;
@@ -96,15 +119,20 @@
isc_mutex_t lock;
/* Locked by lock. */
isc_boolean_t exiting;
- client_list_t active; /* Active clients */
- client_list_t recursing; /* Recursing clients */
- client_list_t inactive; /* To be recycled */
+ client_list_t active; /*%< Active clients */
+ client_list_t recursing; /*%< Recursing clients */
+ client_list_t inactive; /*%< To be recycled */
+#if NMCTXS > 0
+ /*%< mctx pool for clients. */
+ unsigned int nextmctx;
+ isc_mem_t * mctxpool[NMCTXS];
+#endif
};
#define MANAGER_MAGIC ISC_MAGIC('N', 'S', 'C', 'm')
#define VALID_MANAGER(m) ISC_MAGIC_VALID(m, MANAGER_MAGIC)
-/*
+/*!
* Client object states. Ordering is significant: higher-numbered
* states are generally "more active", meaning that the client can
* have more dynamically allocated data, outstanding events, etc.
@@ -117,12 +145,12 @@
*/
#define NS_CLIENTSTATE_FREED 0
-/*
+/*%<
* The client object no longer exists.
*/
#define NS_CLIENTSTATE_INACTIVE 1
-/*
+/*%<
* The client object exists and has a task and timer.
* Its "query" struct and sendbuf are initialized.
* It is on the client manager's list of inactive clients.
@@ -130,7 +158,7 @@
*/
#define NS_CLIENTSTATE_READY 2
-/*
+/*%<
* The client object is either a TCP or a UDP one, and
* it is associated with a network interface. It is on the
* client manager's list of active clients.
@@ -143,7 +171,7 @@
*/
#define NS_CLIENTSTATE_READING 3
-/*
+/*%<
* The client object is a TCP client object that has received
* a connection. It has a tcpsocket, tcpmsg, TCP quota, and an
* outstanding TCP read request. This state is not used for
@@ -151,14 +179,14 @@
*/
#define NS_CLIENTSTATE_WORKING 4
-/*
+/*%<
* The client object has received a request and is working
* on it. It has a view, and it may have any of a non-reset OPT,
* recursion quota, and an outstanding write request.
*/
#define NS_CLIENTSTATE_MAX 9
-/*
+/*%<
* Sentinel value used to indicate "no state". When client->newstate
* has this value, we are not attempting to exit the current state.
* Must be greater than any valid state.
@@ -171,6 +199,8 @@
#define NS_CLIENT_DROPPORT 1
#endif
+unsigned int ns_client_requests;
+
static void client_read(ns_client_t *client);
static void client_accept(ns_client_t *client);
static void client_udprecv(ns_client_t *client);
@@ -227,7 +257,7 @@
}
}
-/*
+/*%
* Check for a deactivation or shutdown request and take appropriate
* action. Returns ISC_TRUE if either is in progress; in this case
* the caller must no longer use the client object as it may have been
@@ -489,7 +519,7 @@
CTRACE("free");
client->magic = 0;
- isc_mem_put(client->mctx, client, sizeof(*client));
+ isc_mem_putanddetach(&client->mctx, client, sizeof(*client));
goto unlock;
}
@@ -510,7 +540,7 @@
return (ISC_TRUE);
}
-/*
+/*%
* The client's task has received the client's control event
* as part of the startup process.
*/
@@ -536,7 +566,7 @@
}
-/*
+/*%
* The client's task has received a shutdown event.
*/
static void
@@ -591,6 +621,7 @@
client->udpsize = 512;
client->extflags = 0;
+ client->ednsversion = -1;
dns_message_reset(client->message, DNS_MESSAGE_INTENTPARSE);
if (client->recursionquota != NULL)
@@ -705,7 +736,7 @@
ns_client_next(client, ISC_R_SUCCESS);
}
-/*
+/*%
* We only want to fail with ISC_R_NOSPACE when called from
* ns_client_sendraw() and not when called from ns_client_send(),
* tcpbuffer is NULL when called from ns_client_sendraw() and
@@ -1149,7 +1180,7 @@
rdatalist->ttl = (client->extflags & DNS_MESSAGEEXTFLAG_REPLYPRESERVE);
/*
- * No ENDS options in the default case.
+ * No EDNS options in the default case.
*/
rdata->data = NULL;
rdata->length = 0;
@@ -1182,6 +1213,64 @@
}
/*
+ * 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 = NULL;
+ dns_name_t *tsig = NULL;
+ 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)) {
+
+ 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).
*/
@@ -1215,6 +1304,8 @@
NS_CLIENTSTATE_READING :
NS_CLIENTSTATE_READY);
+ ns_client_requests++;
+
if (event->ev_type == ISC_SOCKEVENT_RECVDONE) {
INSIST(!TCP_CLIENT(client));
sevent = (isc_socketevent_t *)event;
@@ -1392,8 +1483,6 @@
*/
opt = dns_message_getopt(client->message);
if (opt != NULL) {
- unsigned int version;
-
/*
* Set the client's UDP buffer size.
*/
@@ -1412,22 +1501,24 @@
client->extflags = (isc_uint16_t)(opt->ttl & 0xFFFF);
/*
- * Create an OPT for our reply.
+ * Do we understand this version of EDNS?
+ *
+ * XXXRTH need library support for this!
*/
- result = client_addopt(client);
- if (result != ISC_R_SUCCESS) {
+ client->ednsversion = (opt->ttl & 0x00FF0000) >> 16;
+ if (client->ednsversion > 0) {
+ result = client_addopt(client);
+ if (result == ISC_R_SUCCESS)
+ result = DNS_R_BADVERS;
ns_client_error(client, result);
goto cleanup;
}
-
/*
- * Do we understand this version of ENDS?
- *
- * XXXRTH need library support for this!
+ * Create an OPT for our reply.
*/
- version = (opt->ttl & 0x00FF0000) >> 16;
- if (version != 0) {
- ns_client_error(client, DNS_R_BADVERS);
+ result = client_addopt(client);
+ if (result != ISC_R_SUCCESS) {
+ ns_client_error(client, result);
goto cleanup;
}
}
@@ -1493,6 +1584,7 @@
"failed to get request's "
"destination: %s",
isc_result_totext(result));
+ ns_client_next(client, ISC_R_SUCCESS);
goto cleanup;
}
}
@@ -1581,21 +1673,29 @@
char tsigrcode[64];
isc_buffer_t b;
dns_name_t *name = NULL;
+ dns_rcode_t status;
+ isc_result_t tresult;
- isc_buffer_init(&b, tsigrcode, sizeof(tsigrcode) - 1);
- RUNTIME_CHECK(dns_tsigrcode_totext(client->message->tsigstatus,
- &b) == ISC_R_SUCCESS);
- tsigrcode[isc_buffer_usedlength(&b)] = '\0';
/* There is a signature, but it is bad. */
if (dns_message_gettsig(client->message, &name) != NULL) {
char namebuf[DNS_NAME_FORMATSIZE];
dns_name_format(name, namebuf, sizeof(namebuf));
+ status = client->message->tsigstatus;
+ isc_buffer_init(&b, tsigrcode, sizeof(tsigrcode) - 1);
+ tresult = dns_tsigrcode_totext(status, &b);
+ INSIST(tresult == ISC_R_SUCCESS);
+ tsigrcode[isc_buffer_usedlength(&b)] = '\0';
ns_client_log(client, DNS_LOGCATEGORY_SECURITY,
NS_LOGMODULE_CLIENT, ISC_LOG_ERROR,
"request has invalid signature: "
"TSIG %s: %s (%s)", namebuf,
isc_result_totext(result), tsigrcode);
} else {
+ status = client->message->sig0status;
+ isc_buffer_init(&b, tsigrcode, sizeof(tsigrcode) - 1);
+ tresult = dns_tsigrcode_totext(status, &b);
+ INSIST(tresult == ISC_R_SUCCESS);
+ tsigrcode[isc_buffer_usedlength(&b)] = '\0';
ns_client_log(client, DNS_LOGCATEGORY_SECURITY,
NS_LOGMODULE_CLIENT, ISC_LOG_ERROR,
"request has invalid signature: %s (%s)",
@@ -1637,6 +1737,19 @@
"recursion not available");
/*
+ * Adjust maximum UDP response size for this client.
+ */
+ if (client->udpsize > 512) {
+ dns_peer_t *peer = NULL;
+ isc_uint16_t udpsize = view->maxudp;
+ (void) dns_peerlist_peerbyaddr(view->peers, &netaddr, &peer);
+ if (peer != NULL)
+ dns_peer_getmaxudp(peer, &udpsize);
+ if (client->udpsize > udpsize)
+ client->udpsize = udpsize;
+ }
+
+ /*
* Dispatch the request.
*/
switch (client->message->opcode) {
@@ -1697,9 +1810,42 @@
}
static isc_result_t
+get_clientmctx(ns_clientmgr_t *manager, isc_mem_t **mctxp) {
+ isc_mem_t *clientmctx;
+#if NMCTXS > 0
+ isc_result_t result;
+#endif
+
+ /*
+ * Caller must be holding the manager lock.
+ */
+#if NMCTXS > 0
+ INSIST(manager->nextmctx < NMCTXS);
+ clientmctx = manager->mctxpool[manager->nextmctx];
+ if (clientmctx == NULL) {
+ result = isc_mem_create(0, 0, &clientmctx);
+ if (result != ISC_R_SUCCESS)
+ return (result);
+
+ manager->mctxpool[manager->nextmctx] = clientmctx;
+ manager->nextmctx++;
+ if (manager->nextmctx == NMCTXS)
+ manager->nextmctx = 0;
+ }
+#else
+ clientmctx = manager->mctx;
+#endif
+
+ isc_mem_attach(clientmctx, mctxp);
+
+ return (ISC_R_SUCCESS);
+}
+
+static isc_result_t
client_create(ns_clientmgr_t *manager, ns_client_t **clientp) {
ns_client_t *client;
isc_result_t result;
+ isc_mem_t *mctx = NULL;
/*
* Caller must be holding the manager lock.
@@ -1711,9 +1857,16 @@
REQUIRE(clientp != NULL && *clientp == NULL);
- client = isc_mem_get(manager->mctx, sizeof(*client));
- if (client == NULL)
+ result = get_clientmctx(manager, &mctx);
+ if (result != ISC_R_SUCCESS)
+ return (result);
+
+ client = isc_mem_get(mctx, sizeof(*client));
+ if (client == NULL) {
+ isc_mem_detach(&mctx);
return (ISC_R_NOMEMORY);
+ }
+ client->mctx = mctx;
client->task = NULL;
result = isc_task_create(manager->taskmgr, 0, &client->task);
@@ -1730,7 +1883,7 @@
client->timerset = ISC_FALSE;
client->message = NULL;
- result = dns_message_create(manager->mctx, DNS_MESSAGE_INTENTPARSE,
+ result = dns_message_create(client->mctx, DNS_MESSAGE_INTENTPARSE,
&client->message);
if (result != ISC_R_SUCCESS)
goto cleanup_timer;
@@ -1738,7 +1891,7 @@
/* XXXRTH Hardwired constants */
client->sendevent = (isc_socketevent_t *)
- isc_event_allocate(manager->mctx, client,
+ isc_event_allocate(client->mctx, client,
ISC_SOCKEVENT_SENDDONE,
client_senddone, client,
sizeof(isc_socketevent_t));
@@ -1747,14 +1900,14 @@
goto cleanup_message;
}
- client->recvbuf = isc_mem_get(manager->mctx, RECV_BUFFER_SIZE);
+ client->recvbuf = isc_mem_get(client->mctx, RECV_BUFFER_SIZE);
if (client->recvbuf == NULL) {
result = ISC_R_NOMEMORY;
goto cleanup_sendevent;
}
client->recvevent = (isc_socketevent_t *)
- isc_event_allocate(manager->mctx, client,
+ isc_event_allocate(client->mctx, client,
ISC_SOCKEVENT_RECVDONE,
client_request, client,
sizeof(isc_socketevent_t));
@@ -1764,7 +1917,6 @@
}
client->magic = NS_CLIENT_MAGIC;
- client->mctx = manager->mctx;
client->manager = NULL;
client->state = NS_CLIENTSTATE_INACTIVE;
client->newstate = NS_CLIENTSTATE_MAX;
@@ -1786,6 +1938,7 @@
client->opt = NULL;
client->udpsize = 512;
client->extflags = 0;
+ client->ednsversion = -1;
client->next = NULL;
client->shutdown = NULL;
client->shutdown_arg = NULL;
@@ -1834,7 +1987,7 @@
isc_event_free((isc_event_t **)&client->recvevent);
cleanup_recvbuf:
- isc_mem_put(manager->mctx, client->recvbuf, RECV_BUFFER_SIZE);
+ isc_mem_put(client->mctx, client->recvbuf, RECV_BUFFER_SIZE);
cleanup_sendevent:
isc_event_free((isc_event_t **)&client->sendevent);
@@ -1851,7 +2004,7 @@
isc_task_detach(&client->task);
cleanup_client:
- isc_mem_put(manager->mctx, client, sizeof(*client));
+ isc_mem_putanddetach(&client->mctx, client, sizeof(*client));
return (result);
}
@@ -2104,12 +2257,23 @@
static void
clientmgr_destroy(ns_clientmgr_t *manager) {
+#if NMCTXS > 0
+ int i;
+#endif
+
REQUIRE(ISC_LIST_EMPTY(manager->active));
REQUIRE(ISC_LIST_EMPTY(manager->inactive));
REQUIRE(ISC_LIST_EMPTY(manager->recursing));
MTRACE("clientmgr_destroy");
+#if NMCTXS > 0
+ for (i = 0; i < NMCTXS; i++) {
+ if (manager->mctxpool[i] != NULL)
+ isc_mem_detach(&manager->mctxpool[i]);
+ }
+#endif
+
DESTROYLOCK(&manager->lock);
manager->magic = 0;
isc_mem_put(manager->mctx, manager, sizeof(*manager));
@@ -2121,6 +2285,9 @@
{
ns_clientmgr_t *manager;
isc_result_t result;
+#if NMCTXS > 0
+ int i;
+#endif
manager = isc_mem_get(mctx, sizeof(*manager));
if (manager == NULL)
@@ -2137,6 +2304,11 @@
ISC_LIST_INIT(manager->active);
ISC_LIST_INIT(manager->inactive);
ISC_LIST_INIT(manager->recursing);
+#if NMCTXS > 0
+ manager->nextmctx = 0;
+ for (i = 0; i < NMCTXS; i++)
+ manager->mctxpool[i] = NULL; /* will be created on-demand */
+#endif
manager->magic = MANAGER_MAGIC;
MTRACE("create");
Index: query.c
===================================================================
RCS file: /home/cvs/src/contrib/bind9/bin/named/query.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -L contrib/bind9/bin/named/query.c -L contrib/bind9/bin/named/query.c -u -r1.3 -r1.4
--- contrib/bind9/bin/named/query.c
+++ contrib/bind9/bin/named/query.c
@@ -1,8 +1,8 @@
/*
- * Copyright (C) 2004-2006 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
*
@@ -15,7 +15,9 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: query.c,v 1.198.2.13.4.43 2006/08/31 03:57:11 marka Exp $ */
+/* $Id: query.c,v 1.257.18.40 2007/09/26 03:08:14 each Exp $ */
+
+/*! \file */
#include <config.h>
@@ -27,8 +29,13 @@
#include <dns/adb.h>
#include <dns/byaddr.h>
#include <dns/db.h>
+#ifdef DLZ
+#include <dns/dlz.h>
+#endif
+#include <dns/dnssec.h>
#include <dns/events.h>
#include <dns/message.h>
+#include <dns/ncache.h>
#include <dns/order.h>
#include <dns/rdata.h>
#include <dns/rdataclass.h>
@@ -51,24 +58,34 @@
#include <named/sortlist.h>
#include <named/xfrout.h>
+/*% Partial answer? */
#define PARTIALANSWER(c) (((c)->query.attributes & \
NS_QUERYATTR_PARTIALANSWER) != 0)
+/*% Use Cache? */
#define USECACHE(c) (((c)->query.attributes & \
NS_QUERYATTR_CACHEOK) != 0)
+/*% Recursion OK? */
#define RECURSIONOK(c) (((c)->query.attributes & \
NS_QUERYATTR_RECURSIONOK) != 0)
+/*% Recursing? */
#define RECURSING(c) (((c)->query.attributes & \
NS_QUERYATTR_RECURSING) != 0)
+/*% Cache glue ok? */
#define CACHEGLUEOK(c) (((c)->query.attributes & \
NS_QUERYATTR_CACHEGLUEOK) != 0)
+/*% Want Recursion? */
#define WANTRECURSION(c) (((c)->query.attributes & \
NS_QUERYATTR_WANTRECURSION) != 0)
+/*% Want DNSSEC? */
#define WANTDNSSEC(c) (((c)->attributes & \
NS_CLIENTATTR_WANTDNSSEC) != 0)
+/*% No authority? */
#define NOAUTHORITY(c) (((c)->query.attributes & \
NS_QUERYATTR_NOAUTHORITY) != 0)
+/*% No additional? */
#define NOADDITIONAL(c) (((c)->query.attributes & \
NS_QUERYATTR_NOADDITIONAL) != 0)
+/*% Secure? */
#define SECURE(c) (((c)->query.attributes & \
NS_QUERYATTR_SECURE) != 0)
@@ -92,10 +109,19 @@
#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);
-/*
+static isc_boolean_t
+validate(ns_client_t *client, dns_db_t *db, dns_name_t *name,
+ dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset);
+
+/*%
* Increment query statistics counters.
*/
static inline void
@@ -144,7 +170,12 @@
static void
query_next(ns_client_t *client, isc_result_t result) {
- inc_stats(client, dns_statscounter_failure);
+ if (result == DNS_R_DUPLICATE)
+ inc_stats(client, dns_statscounter_duplicate);
+ else if (result == DNS_R_DROP)
+ inc_stats(client, dns_statscounter_dropped);
+ else
+ inc_stats(client, dns_statscounter_failure);
ns_client_next(client, result);
}
@@ -187,7 +218,7 @@
isc_buffer_t *dbuf, *dbuf_next;
ns_dbversion_t *dbversion, *dbversion_next;
- /*
+ /*%
* Reset the query state of a client to its default state.
*/
@@ -266,7 +297,7 @@
isc_result_t result;
CTRACE("query_newnamebuf");
- /*
+ /*%
* Allocate a name buffer.
*/
@@ -289,7 +320,7 @@
isc_region_t r;
CTRACE("query_getnamebuf");
- /*
+ /*%
* Return a name buffer with space for a maximal name, allocating
* a new one if necessary.
*/
@@ -325,7 +356,7 @@
isc_region_t r;
CTRACE("query_keepname");
- /*
+ /*%
* 'name' is using space in 'dbuf', but 'dbuf' has not yet been
* adjusted to take account of that. We do the adjustment.
*/
@@ -342,7 +373,7 @@
query_releasename(ns_client_t *client, dns_name_t **namep) {
dns_name_t *name = *namep;
- /*
+ /*%
* 'name' is no longer needed. Return it to our pool of temporary
* names. If it is using a name buffer, relinquish its exclusive
* rights on the buffer.
@@ -479,7 +510,7 @@
client->query.authdb = NULL;
client->query.authzone = NULL;
client->query.authdbset = ISC_FALSE;
- client->query.isreferral = ISC_FALSE;
+ client->query.isreferral = ISC_FALSE;
query_reset(client, ISC_FALSE);
result = query_newdbversion(client, 3);
if (result != ISC_R_SUCCESS) {
@@ -499,7 +530,7 @@
{
ns_dbversion_t *dbversion;
- /*
+ /*%
* We may already have done a query related to this
* database. If so, we must be sure to make subsequent
* queries from the same version.
@@ -532,42 +563,23 @@
}
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
* (the query target) was looked for. This prevents following
- * CNAMES or DNAMES into other zones and prevents returning
+ * CNAMES or DNAMES into other zones and prevents returning
* additional data from other zones.
*/
if (!client->view->additionalfromauth &&
@@ -644,7 +656,7 @@
ISC_LOG_DEBUG(3),
"%s approved", msg);
}
- } else {
+ } else {
ns_client_aclmsg("query", name, qtype,
client->view->rdclass,
msg, sizeof(msg));
@@ -683,17 +695,63 @@
*/
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);
@@ -713,7 +771,7 @@
REQUIRE(dbp != NULL && *dbp == NULL);
- /*
+ /*%
* Find a cache database to answer the query.
* This may fail with DNS_R_REFUSED if the client
* is not allowed to use the cache.
@@ -745,7 +803,7 @@
if (check_acl) {
isc_boolean_t log = ISC_TF((options & DNS_GETDB_NOLOG) == 0);
char msg[NS_CLIENT_ACLMSGSIZE("query (cache)")];
-
+
result = ns_client_checkaclsilent(client,
client->view->queryacl,
ISC_TRUE);
@@ -811,9 +869,85 @@
{
isc_result_t result;
+#ifdef DLZ
+ isc_result_t tresult;
+ unsigned int namelabels;
+ unsigned int zonelabels;
+ dns_zone_t *zone = NULL;
+ dns_db_t *tdbp;
+
+ REQUIRE(zonep != NULL && *zonep == NULL);
+
+ tdbp = NULL;
+
+ /* Calculate how many labels are in name. */
+ namelabels = dns_name_countlabels(name);
+ zonelabels = 0;
+
+ /* Try to find name in bind's standard database. */
+ result = query_getzonedb(client, name, qtype, options, &zone,
+ dbp, versionp);
+
+ /* See how many labels are in the zone's name. */
+ if (result == ISC_R_SUCCESS && zone != NULL)
+ zonelabels = dns_name_countlabels(dns_zone_getorigin(zone));
+ /*
+ * If # zone labels < # name labels, try to find an even better match
+ * Only try if a DLZ driver is loaded for this view
+ */
+ if (zonelabels < namelabels && client->view->dlzdatabase != NULL) {
+ tresult = dns_dlzfindzone(client->view, name,
+ zonelabels, &tdbp);
+ /* If we successful, we found a better match. */
+ if (tresult == ISC_R_SUCCESS) {
+ /*
+ * If the previous search returned a zone, detach it.
+ */
+ if (zone != NULL)
+ dns_zone_detach(&zone);
+
+ /*
+ * If the previous search returned a database,
+ * detach it.
+ */
+ if (*dbp != NULL)
+ dns_db_detach(dbp);
+
+ /*
+ * If the previous search returned a version, clear it.
+ */
+ *versionp = NULL;
+
+ /*
+ * Get our database version.
+ */
+ dns_db_currentversion(tdbp, versionp);
+
+ /*
+ * Be sure to return our database.
+ */
+ *dbp = tdbp;
+
+ /*
+ * We return a null zone, No stats for DLZ zones.
+ */
+ zone = NULL;
+ result = tresult;
+ }
+ }
+#else
result = query_getzonedb(client, name, qtype, options,
zonep, dbp, versionp);
+#endif
+
+ /* If successfull, Transfer ownership of zone. */
if (result == ISC_R_SUCCESS) {
+#ifdef DLZ
+ *zonep = zone;
+#endif
+ /*
+ * If neither attempt above succeeded, return the cache instead
+ */
*is_zonep = ISC_TRUE;
} else if (result == ISC_R_NOTFOUND) {
result = query_getcachedb(client, name, qtype, dbp, options);
@@ -975,10 +1109,23 @@
* 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,
+ /*
+ * Attempt to validate glue.
+ */
+ if (sigrdataset == NULL) {
+ sigrdataset = query_newrdataset(client);
+ if (sigrdataset == NULL)
+ goto cleanup;
+ }
+ result = dns_db_find(db, name, version, type,
+ client->query.dboptions | DNS_DBFIND_GLUEOK,
client->now, &node, fname, rdataset,
sigrdataset);
+ if (result == DNS_R_GLUE &&
+ validate(client, db, fname, rdataset, sigrdataset))
+ result = ISC_R_SUCCESS;
+ if (!WANTDNSSEC(client))
+ query_putrdataset(client, &sigrdataset);
if (result == ISC_R_SUCCESS)
goto found;
@@ -1098,73 +1245,601 @@
INSIST(sigrdataset == NULL ||
! dns_rdataset_isassociated(sigrdataset));
}
- if (result == ISC_R_SUCCESS) {
- mname = NULL;
- if (!query_isduplicate(client, fname,
- dns_rdatatype_a, &mname)) {
- if (mname != NULL) {
- query_releasename(client, &fname);
- fname = mname;
- } else
- need_addname = ISC_TRUE;
- ISC_LIST_APPEND(fname->list, rdataset, link);
- added_something = ISC_TRUE;
- if (sigrdataset != NULL &&
- dns_rdataset_isassociated(sigrdataset))
- {
- ISC_LIST_APPEND(fname->list,
- sigrdataset, link);
- sigrdataset =
- query_newrdataset(client);
- }
- rdataset = query_newrdataset(client);
- if (rdataset == NULL)
- goto addname;
- if (WANTDNSSEC(client) && sigrdataset == NULL)
- goto addname;
- } else {
- dns_rdataset_disassociate(rdataset);
- if (sigrdataset != NULL &&
- dns_rdataset_isassociated(sigrdataset))
- dns_rdataset_disassociate(sigrdataset);
- }
+ if (result == ISC_R_SUCCESS) {
+ mname = NULL;
+ if (!query_isduplicate(client, fname,
+ dns_rdatatype_a, &mname)) {
+ if (mname != NULL) {
+ query_releasename(client, &fname);
+ fname = mname;
+ } else
+ need_addname = ISC_TRUE;
+ ISC_LIST_APPEND(fname->list, rdataset, link);
+ added_something = ISC_TRUE;
+ if (sigrdataset != NULL &&
+ dns_rdataset_isassociated(sigrdataset))
+ {
+ ISC_LIST_APPEND(fname->list,
+ sigrdataset, link);
+ sigrdataset =
+ query_newrdataset(client);
+ }
+ rdataset = query_newrdataset(client);
+ if (rdataset == NULL)
+ goto addname;
+ if (WANTDNSSEC(client) && sigrdataset == NULL)
+ goto addname;
+ } else {
+ dns_rdataset_disassociate(rdataset);
+ if (sigrdataset != NULL &&
+ dns_rdataset_isassociated(sigrdataset))
+ dns_rdataset_disassociate(sigrdataset);
+ }
+ }
+ result = dns_db_findrdataset(db, node, version,
+ dns_rdatatype_aaaa, 0,
+ client->now, rdataset,
+ sigrdataset);
+ if (result == DNS_R_NCACHENXDOMAIN)
+ goto addname;
+ if (result == DNS_R_NCACHENXRRSET) {
+ dns_rdataset_disassociate(rdataset);
+ INSIST(sigrdataset == NULL ||
+ ! dns_rdataset_isassociated(sigrdataset));
+ }
+ if (result == ISC_R_SUCCESS) {
+ mname = NULL;
+ if (!query_isduplicate(client, fname,
+ dns_rdatatype_aaaa, &mname)) {
+ if (mname != NULL) {
+ query_releasename(client, &fname);
+ fname = mname;
+ } else
+ need_addname = ISC_TRUE;
+ ISC_LIST_APPEND(fname->list, rdataset, link);
+ added_something = ISC_TRUE;
+ if (sigrdataset != NULL &&
+ dns_rdataset_isassociated(sigrdataset))
+ {
+ ISC_LIST_APPEND(fname->list,
+ sigrdataset, link);
+ sigrdataset = NULL;
+ }
+ rdataset = NULL;
+ }
+ }
+ }
+
+ addname:
+ CTRACE("query_addadditional: addname");
+ /*
+ * If we haven't added anything, then we're done.
+ */
+ if (!added_something)
+ goto cleanup;
+
+ /*
+ * We may have added our rdatasets to an existing name, if so, then
+ * need_addname will be ISC_FALSE. Whether we used an existing name
+ * or a new one, we must set fname to NULL to prevent cleanup.
+ */
+ if (need_addname)
+ dns_message_addname(client->message, fname,
+ DNS_SECTION_ADDITIONAL);
+ fname = NULL;
+
+ /*
+ * In a few cases, we want to add additional data for additional
+ * data. It's simpler to just deal with special cases here than
+ * to try to create a general purpose mechanism and allow the
+ * rdata implementations to do it themselves.
+ *
+ * This involves recursion, but the depth is limited. The
+ * most complex case is adding a SRV rdataset, which involves
+ * recursing to add address records, which in turn can cause
+ * recursion to add KEYs.
+ */
+ if (type == dns_rdatatype_srv && trdataset != NULL) {
+ /*
+ * If we're adding SRV records to the additional data
+ * section, it's helpful if we add the SRV additional data
+ * as well.
+ */
+ eresult = dns_rdataset_additionaldata(trdataset,
+ query_addadditional,
+ client);
+ }
+
+ cleanup:
+ CTRACE("query_addadditional: cleanup");
+ query_putrdataset(client, &rdataset);
+ if (sigrdataset != NULL)
+ query_putrdataset(client, &sigrdataset);
+ if (fname != NULL)
+ query_releasename(client, &fname);
+ if (node != NULL)
+ dns_db_detachnode(db, &node);
+ if (db != NULL)
+ dns_db_detach(&db);
+ if (zone != NULL)
+ dns_zone_detach(&zone);
+
+ CTRACE("query_addadditional: done");
+ return (eresult);
+}
+
+static inline void
+query_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 | DNS_DBFIND_GLUEOK,
+ 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;
+
+ 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 we can't promote glue/pending from the cache to secure
+ * then drop it.
+ */
+ if (result == ISC_R_SUCCESS &&
+ additionaltype == dns_rdatasetadditional_fromcache &&
+ (rdataset->trust == dns_trust_pending ||
+ rdataset->trust == dns_trust_glue) &&
+ !validate(client, db, fname, rdataset, sigrdataset)) {
+ dns_rdataset_disassociate(rdataset);
+ if (dns_rdataset_isassociated(sigrdataset))
+ dns_rdataset_disassociate(sigrdataset);
+ result = ISC_R_NOTFOUND;
+ }
+ if (result == DNS_R_NCACHENXDOMAIN)
+ goto setcache;
+ if (result == DNS_R_NCACHENXRRSET) {
+ dns_rdataset_disassociate(rdataset);
+ /*
+ * Negative cache entries don't have sigrdatasets.
+ */
+ INSIST(! dns_rdataset_isassociated(sigrdataset));
+ }
+ if (result == ISC_R_SUCCESS) {
+ /* Remember the result as a cache */
+ ISC_LIST_APPEND(cfname.list, rdataset, link);
+ if (dns_rdataset_isassociated(sigrdataset)) {
+ ISC_LIST_APPEND(cfname.list, sigrdataset, link);
+ sigrdataset = query_newrdataset(client);
+ }
+ rdataset = query_newrdataset(client);
+ if (sigrdataset == NULL || rdataset == NULL) {
+ /* do not cache incomplete information */
+ goto foundcache;
}
- result = dns_db_findrdataset(db, node, version,
- dns_rdatatype_aaaa, 0,
- client->now, rdataset,
- sigrdataset);
- if (result == DNS_R_NCACHENXDOMAIN)
- goto addname;
- if (result == DNS_R_NCACHENXRRSET) {
- dns_rdataset_disassociate(rdataset);
- INSIST(sigrdataset == NULL ||
- ! dns_rdataset_isassociated(sigrdataset));
+ }
+
+ /* Find AAAA RRset with sig RRset */
+ result = dns_db_findrdataset(db, node, version, dns_rdatatype_aaaa,
+ 0, client->now, rdataset, sigrdataset);
+ /*
+ * If we can't promote glue/pending from the cache to secure
+ * then drop it.
+ */
+ if (result == ISC_R_SUCCESS &&
+ additionaltype == dns_rdatasetadditional_fromcache &&
+ (rdataset->trust == dns_trust_pending ||
+ rdataset->trust == dns_trust_glue) &&
+ !validate(client, db, fname, rdataset, sigrdataset)) {
+ dns_rdataset_disassociate(rdataset);
+ if (dns_rdataset_isassociated(sigrdataset))
+ dns_rdataset_disassociate(sigrdataset);
+ result = ISC_R_NOTFOUND;
+ }
+ if (result == ISC_R_SUCCESS) {
+ ISC_LIST_APPEND(cfname.list, rdataset, link);
+ rdataset = NULL;
+ if (dns_rdataset_isassociated(sigrdataset)) {
+ ISC_LIST_APPEND(cfname.list, sigrdataset, link);
+ sigrdataset = NULL;
}
- if (result == ISC_R_SUCCESS) {
- mname = NULL;
- if (!query_isduplicate(client, fname,
- dns_rdatatype_aaaa, &mname)) {
+ }
+
+ 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_APPEND(fname->list, rdataset, link);
+ ISC_LIST_UNLINK(cfname.list, crdataset, link);
+ ISC_LIST_APPEND(fname->list, crdataset, link);
added_something = ISC_TRUE;
- if (sigrdataset != NULL &&
- dns_rdataset_isassociated(sigrdataset))
- {
- ISC_LIST_APPEND(fname->list,
- sigrdataset, link);
- sigrdataset = NULL;
- }
- rdataset = NULL;
- }
+ need_sigrrset = ISC_TRUE;
+ } else
+ need_sigrrset = ISC_FALSE;
+ } else if (crdataset->type == dns_rdatatype_rrsig &&
+ 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;
}
}
- addname:
- CTRACE("query_addadditional: addname");
+ CTRACE("query_addadditional2: addname");
+
/*
* If we haven't added anything, then we're done.
*/
@@ -1181,33 +1856,17 @@
DNS_SECTION_ADDITIONAL);
fname = NULL;
- /*
- * In a few cases, we want to add additional data for additional
- * data. It's simpler to just deal with special cases here than
- * to try to create a general purpose mechanism and allow the
- * rdata implementations to do it themselves.
- *
- * This involves recursion, but the depth is limited. The
- * most complex case is adding a SRV rdataset, which involves
- * recursing to add address records, which in turn can cause
- * recursion to add KEYs.
- */
- if (type == dns_rdatatype_srv && trdataset != NULL) {
- /*
- * If we're adding SRV records to the additional data
- * section, it's helpful if we add the SRV additional data
- * as well.
- */
- eresult = dns_rdataset_additionaldata(trdataset,
- query_addadditional,
- client);
- }
-
cleanup:
- CTRACE("query_addadditional: cleanup");
- query_putrdataset(client, &rdataset);
+ 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)
@@ -1217,7 +1876,7 @@
if (zone != NULL)
dns_zone_detach(&zone);
- CTRACE("query_addadditional: done");
+ CTRACE("query_addadditional2: done");
return (eresult);
}
@@ -1225,6 +1884,8 @@
query_addrdataset(ns_client_t *client, dns_name_t *fname,
dns_rdataset_t *rdataset)
{
+ client_additionalctx_t additionalctx;
+
/*
* Add 'rdataset' and any pertinent additional data to
* 'fname', a name in the response message for 'client'.
@@ -1238,6 +1899,8 @@
rdataset->attributes |= dns_order_find(client->view->order,
fname, rdataset->type,
rdataset->rdclass);
+ rdataset->attributes |= DNS_RDATASETATTR_LOADORDER;
+
if (NOADDITIONAL(client))
return;
@@ -1246,8 +1909,10 @@
*
* 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);
CTRACE("query_addrdataset: done");
}
@@ -1260,7 +1925,7 @@
dns_rdataset_t *rdataset, *mrdataset, *sigrdataset;
isc_result_t result;
- /*
+ /*%
* To the current response for 'client', add the answer RRset
* '*rdatasetp' and an optional signature set '*sigrdatasetp', with
* owner name '*namep', to section 'section', unless they are
@@ -1328,11 +1993,12 @@
}
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;
@@ -1344,8 +2010,6 @@
name = NULL;
rdataset = NULL;
node = NULL;
- dns_fixedname_init(&foundname);
- fname = dns_fixedname_name(&foundname);
/*
* Get resources and make 'name' be the database origin.
@@ -1371,9 +2035,23 @@
/*
* Find the SOA.
*/
- result = dns_db_find(db, name, NULL, dns_rdatatype_soa,
- client->query.dboptions, 0, &node,
- fname, rdataset, sigrdataset);
+ result = dns_db_getoriginnode(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) {
/*
* This is bad. We tried to get the SOA RR at the zone top
@@ -1429,7 +2107,7 @@
}
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;
@@ -1476,13 +2154,22 @@
/*
* 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_getoriginnode(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) {
- 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!
@@ -1575,6 +2262,161 @@
return (ISC_R_SUCCESS);
}
+/*
+ * Mark the RRsets as secure. Update the cache (db) to reflect the
+ * change in trust level.
+ */
+static void
+mark_secure(ns_client_t *client, dns_db_t *db, dns_name_t *name,
+ dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset)
+{
+ isc_result_t result;
+ dns_dbnode_t *node = NULL;
+
+ rdataset->trust = dns_trust_secure;
+ sigrdataset->trust = dns_trust_secure;
+
+ /*
+ * Save the updated secure state. Ignore failures.
+ */
+ result = dns_db_findnode(db, name, ISC_TRUE, &node);
+ if (result != ISC_R_SUCCESS)
+ return;
+ (void)dns_db_addrdataset(db, node, NULL, client->now, rdataset,
+ 0, NULL);
+ (void)dns_db_addrdataset(db, node, NULL, client->now, sigrdataset,
+ 0, NULL);
+ dns_db_detachnode(db, &node);
+}
+
+/*
+ * Find the secure key that corresponds to rrsig.
+ * Note: 'keyrdataset' maintains state between sucessive calls,
+ * there may be multiple keys with the same keyid.
+ * Return ISC_FALSE if we have exhausted all the possible keys.
+ */
+static isc_boolean_t
+get_key(ns_client_t *client, dns_db_t *db, dns_rdata_rrsig_t *rrsig,
+ dns_rdataset_t *keyrdataset, dst_key_t **keyp)
+{
+ isc_result_t result;
+ dns_dbnode_t *node = NULL;
+ isc_boolean_t secure = ISC_FALSE;
+
+ if (!dns_rdataset_isassociated(keyrdataset)) {
+ result = dns_db_findnode(db, &rrsig->signer, ISC_FALSE, &node);
+ if (result != ISC_R_SUCCESS)
+ return (ISC_FALSE);
+
+ result = dns_db_findrdataset(db, node, NULL,
+ dns_rdatatype_dnskey, 0,
+ client->now, keyrdataset, NULL);
+ dns_db_detachnode(db, &node);
+ if (result != ISC_R_SUCCESS)
+ return (ISC_FALSE);
+
+ if (keyrdataset->trust != dns_trust_secure)
+ return (ISC_FALSE);
+
+ result = dns_rdataset_first(keyrdataset);
+ } else
+ result = dns_rdataset_next(keyrdataset);
+
+ for ( ; result == ISC_R_SUCCESS;
+ result = dns_rdataset_next(keyrdataset)) {
+ dns_rdata_t rdata = DNS_RDATA_INIT;
+ isc_buffer_t b;
+
+ dns_rdataset_current(keyrdataset, &rdata);
+ isc_buffer_init(&b, rdata.data, rdata.length);
+ isc_buffer_add(&b, rdata.length);
+ result = dst_key_fromdns(&rrsig->signer, rdata.rdclass, &b,
+ client->mctx, keyp);
+ if (result != ISC_R_SUCCESS)
+ continue;
+ if (rrsig->algorithm == (dns_secalg_t)dst_key_alg(*keyp) &&
+ rrsig->keyid == (dns_keytag_t)dst_key_id(*keyp) &&
+ dst_key_iszonekey(*keyp)) {
+ secure = ISC_TRUE;
+ break;
+ }
+ dst_key_free(keyp);
+ }
+ return (secure);
+}
+
+static isc_boolean_t
+verify(dst_key_t *key, dns_name_t *name, dns_rdataset_t *rdataset,
+ dns_rdata_t *rdata, isc_mem_t *mctx, isc_boolean_t acceptexpired)
+{
+ isc_result_t result;
+ dns_fixedname_t fixed;
+ isc_boolean_t ignore = ISC_FALSE;
+
+ dns_fixedname_init(&fixed);
+
+again:
+ result = dns_dnssec_verify2(name, rdataset, key, ignore, mctx,
+ rdata, NULL);
+ if (result == DNS_R_SIGEXPIRED && acceptexpired) {
+ ignore = ISC_TRUE;
+ goto again;
+ }
+ if (result == ISC_R_SUCCESS || result == DNS_R_FROMWILDCARD)
+ return (ISC_TRUE);
+ return (ISC_FALSE);
+}
+
+/*
+ * Validate the rdataset if possible with available records.
+ */
+static isc_boolean_t
+validate(ns_client_t *client, dns_db_t *db, dns_name_t *name,
+ dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset)
+{
+ isc_result_t result;
+ dns_rdata_t rdata = DNS_RDATA_INIT;
+ dns_rdata_rrsig_t rrsig;
+ dst_key_t *key = NULL;
+ dns_rdataset_t keyrdataset;
+
+ if (sigrdataset == NULL || !dns_rdataset_isassociated(sigrdataset))
+ return (ISC_FALSE);
+
+ for (result = dns_rdataset_first(sigrdataset);
+ result == ISC_R_SUCCESS;
+ result = dns_rdataset_next(sigrdataset)) {
+
+ dns_rdata_reset(&rdata);
+ dns_rdataset_current(sigrdataset, &rdata);
+ result = dns_rdata_tostruct(&rdata, &rrsig, NULL);
+ if (result != ISC_R_SUCCESS)
+ return (ISC_FALSE);
+ if (!dns_resolver_algorithm_supported(client->view->resolver,
+ name, rrsig.algorithm))
+ continue;
+ if (!dns_name_issubdomain(name, &rrsig.signer))
+ continue;
+ dns_rdataset_init(&keyrdataset);
+ do {
+ if (!get_key(client, db, &rrsig, &keyrdataset, &key))
+ break;
+ if (verify(key, name, rdataset, &rdata, client->mctx,
+ client->view->acceptexpired)) {
+ dst_key_free(&key);
+ dns_rdataset_disassociate(&keyrdataset);
+ mark_secure(client, db, name, rdataset,
+ sigrdataset);
+ return (ISC_TRUE);
+ }
+ dst_key_free(&key);
+ } while (1);
+ if (dns_rdataset_isassociated(&keyrdataset))
+ dns_rdataset_disassociate(&keyrdataset);
+ }
+ return (ISC_FALSE);
+}
+
static void
query_addbestns(ns_client_t *client) {
dns_db_t *db, *zdb;
@@ -1622,7 +2464,11 @@
rdataset = query_newrdataset(client);
if (fname == NULL || rdataset == NULL)
goto cleanup;
- if (WANTDNSSEC(client)) {
+ /*
+ * Get the RRSIGs if the client requested them or if we may
+ * need to validate answers from the cache.
+ */
+ if (WANTDNSSEC(client) || !is_zone) {
sigrdataset = query_newrdataset(client);
if (sigrdataset == NULL)
goto cleanup;
@@ -1698,16 +2544,27 @@
zsigrdataset = NULL;
}
- if ((client->query.dboptions & DNS_DBFIND_PENDINGOK) == 0 &&
- (rdataset->trust == dns_trust_pending ||
- (sigrdataset != NULL && sigrdataset->trust == dns_trust_pending)))
+ /*
+ * Attempt to validate RRsets that are pending or that are glue.
+ */
+ if ((rdataset->trust == dns_trust_pending ||
+ (sigrdataset != NULL && sigrdataset->trust == dns_trust_pending))
+ && !validate(client, db, fname, rdataset, sigrdataset) &&
+ (client->query.dboptions & DNS_DBFIND_PENDINGOK) == 0)
goto cleanup;
- if (WANTDNSSEC(client) && SECURE(client) &&
- (rdataset->trust == dns_trust_glue ||
- (sigrdataset != NULL && sigrdataset->trust == dns_trust_glue)))
+ if ((rdataset->trust == dns_trust_glue ||
+ (sigrdataset != NULL && sigrdataset->trust == dns_trust_glue)) &&
+ !validate(client, db, fname, rdataset, sigrdataset) &&
+ SECURE(client) && WANTDNSSEC(client))
goto cleanup;
+ /*
+ * If the client doesn't want DNSSEC we can discard the sigrdataset
+ * now.
+ */
+ if (!WANTDNSSEC(client))
+ query_putrdataset(client, &sigrdataset);
query_addrrset(client, &fname, &rdataset, &sigrdataset, dbuf,
DNS_SECTION_AUTHORITY);
@@ -1735,7 +2592,9 @@
}
static void
-query_addds(ns_client_t *client, dns_db_t *db, dns_dbnode_t *node) {
+query_addds(ns_client_t *client, dns_db_t *db, dns_dbnode_t *node,
+ dns_dbversion_t *version)
+{
dns_name_t *rname;
dns_rdataset_t *rdataset, *sigrdataset;
isc_result_t result;
@@ -1756,12 +2615,12 @@
/*
* Look for the DS record, which may or may not be present.
*/
- result = dns_db_findrdataset(db, node, NULL, dns_rdatatype_ds, 0,
+ result = dns_db_findrdataset(db, node, version, dns_rdatatype_ds, 0,
client->now, rdataset, sigrdataset);
/*
* If we didn't find it, look for an NSEC. */
if (result == ISC_R_NOTFOUND)
- result = dns_db_findrdataset(db, node, NULL,
+ result = dns_db_findrdataset(db, node, version,
dns_rdatatype_nsec, 0, client->now,
rdataset, sigrdataset);
if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND)
@@ -1800,7 +2659,8 @@
static void
query_addwildcardproof(ns_client_t *client, dns_db_t *db,
- dns_name_t *name, isc_boolean_t ispositive)
+ dns_dbversion_t *version, dns_name_t *name,
+ isc_boolean_t ispositive)
{
isc_buffer_t *dbuf, b;
dns_name_t *fname;
@@ -1837,20 +2697,20 @@
* Given:
* example SOA
* example NSEC b.example
- * b.example A
- * b.example NSEC a.d.example
- * a.d.example A
- * a.d.example NSEC g.f.example
- * g.f.example A
- * g.f.example NSEC z.i.example
- * z.i.example A
- * z.i.example NSEC example
+ * b.example A
+ * b.example NSEC a.d.example
+ * a.d.example A
+ * a.d.example NSEC g.f.example
+ * g.f.example A
+ * g.f.example NSEC z.i.example
+ * z.i.example A
+ * z.i.example NSEC example
*
* QNAME:
* a.example -> example NSEC b.example
- * owner common example
- * next common example
- * wild *.example
+ * owner common example
+ * next common example
+ * wild *.example
* d.b.example -> b.example NSEC a.d.example
* owner common b.example
* next common example
@@ -1861,7 +2721,7 @@
* wild *.f.example
* j.example -> z.i.example NSEC example
* owner common example
- * next common example
+ * next common example
* wild *.f.example
*/
options = client->query.dboptions | DNS_DBFIND_NOWILD;
@@ -1881,7 +2741,7 @@
if (fname == NULL || rdataset == NULL || sigrdataset == NULL)
goto cleanup;
- result = dns_db_find(db, name, NULL, dns_rdatatype_nsec, options,
+ result = dns_db_find(db, name, version, dns_rdatatype_nsec, options,
0, &node, fname, rdataset, sigrdataset);
if (node != NULL)
dns_db_detachnode(db, &node);
@@ -1922,7 +2782,7 @@
name = wname;
goto again;
}
- }
+ }
cleanup:
if (rdataset != NULL)
query_putrdataset(client, &rdataset);
@@ -1933,8 +2793,9 @@
}
static void
-query_addnxrrsetnsec(ns_client_t *client, dns_db_t *db, dns_name_t **namep,
- dns_rdataset_t **rdatasetp, dns_rdataset_t **sigrdatasetp)
+query_addnxrrsetnsec(ns_client_t *client, dns_db_t *db,
+ dns_dbversion_t *version, dns_name_t **namep,
+ dns_rdataset_t **rdatasetp, dns_rdataset_t **sigrdatasetp)
{
dns_name_t *name;
dns_rdataset_t *sigrdataset;
@@ -1971,8 +2832,7 @@
return;
/* XXX */
- query_addwildcardproof(client, db,
- client->query.qname,
+ query_addwildcardproof(client, db, version, client->query.qname,
ISC_TRUE);
/*
@@ -2068,6 +2928,7 @@
{
isc_result_t result;
dns_rdataset_t *rdataset, *sigrdataset;
+ isc_sockaddr_t *peeraddr;
inc_stats(client, dns_statscounter_recursion);
@@ -2149,14 +3010,19 @@
if (client->query.timerset == ISC_FALSE)
ns_client_settimeout(client, 60);
- result = dns_resolver_createfetch(client->view->resolver,
- client->query.qname,
- qtype, qdomain, nameservers,
- NULL, client->query.fetchoptions,
- client->task,
- query_resume, client,
- rdataset, sigrdataset,
- &client->query.fetch);
+ if ((client->attributes & NS_CLIENTATTR_TCP) == 0)
+ peeraddr = &client->peeraddr;
+ else
+ peeraddr = NULL;
+ result = dns_resolver_createfetch2(client->view->resolver,
+ client->query.qname,
+ qtype, qdomain, nameservers,
+ NULL, peeraddr, client->message->id,
+ client->query.fetchoptions,
+ client->task,
+ query_resume, client,
+ rdataset, sigrdataset,
+ &client->query.fetch);
if (result == ISC_R_SUCCESS) {
/*
@@ -2193,7 +3059,7 @@
rdata_tonetaddr(const dns_rdata_t *rdata, isc_netaddr_t *netaddr) {
struct in_addr ina;
struct in6_addr in6a;
-
+
switch (rdata->type) {
case dns_rdatatype_a:
INSIST(rdata->length == 4);
@@ -2246,7 +3112,7 @@
isc_netaddr_t netaddr;
dns_rdatasetorderfunc_t order = NULL;
const void *order_arg = NULL;
-
+
isc_netaddr_fromsockaddr(&netaddr, &client->peeraddr);
switch (ns_sortlist_setup(client->view->sortlist,
&netaddr, &order_arg)) {
@@ -2331,6 +3197,111 @@
}
}
+#define NS_NAME_INIT(A,B) \
+ { \
+ DNS_NAME_MAGIC, \
+ A, sizeof(A), sizeof(B), \
+ DNS_NAMEATTR_READONLY | DNS_NAMEATTR_ABSOLUTE, \
+ B, NULL, { (void *)-1, (void *)-1}, \
+ {NULL, NULL} \
+ }
+
+static unsigned char inaddr10_offsets[] = { 0, 3, 11, 16 };
+static unsigned char inaddr172_offsets[] = { 0, 3, 7, 15, 20 };
+static unsigned char inaddr192_offsets[] = { 0, 4, 8, 16, 21 };
+
+static unsigned char inaddr10[] = "\00210\007IN-ADDR\004ARPA";
+
+static unsigned char inaddr16172[] = "\00216\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr17172[] = "\00217\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr18172[] = "\00218\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr19172[] = "\00219\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr20172[] = "\00220\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr21172[] = "\00221\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr22172[] = "\00222\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr23172[] = "\00223\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr24172[] = "\00224\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr25172[] = "\00225\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr26172[] = "\00226\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr27172[] = "\00227\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr28172[] = "\00228\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr29172[] = "\00229\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr30172[] = "\00230\003172\007IN-ADDR\004ARPA";
+static unsigned char inaddr31172[] = "\00231\003172\007IN-ADDR\004ARPA";
+
+static unsigned char inaddr168192[] = "\003168\003192\007IN-ADDR\004ARPA";
+
+static dns_name_t rfc1918names[] = {
+ NS_NAME_INIT(inaddr10, inaddr10_offsets),
+ NS_NAME_INIT(inaddr16172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr17172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr18172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr19172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr20172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr21172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr22172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr23172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr24172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr25172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr26172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr27172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr28172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr29172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr30172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr31172, inaddr172_offsets),
+ NS_NAME_INIT(inaddr168192, inaddr192_offsets)
+};
+
+
+static unsigned char prisoner_data[] = "\010prisoner\004iana\003org";
+static unsigned char hostmaster_data[] = "\012hostmaster\014root-servers\003org";
+
+static unsigned char prisoner_offsets[] = { 0, 9, 14, 18 };
+static unsigned char hostmaster_offsets[] = { 0, 11, 24, 28 };
+
+static dns_name_t prisoner = NS_NAME_INIT(prisoner_data, prisoner_offsets);
+static dns_name_t hostmaster = NS_NAME_INIT(hostmaster_data, hostmaster_offsets);
+
+static void
+warn_rfc1918(ns_client_t *client, dns_name_t *fname, dns_rdataset_t *rdataset) {
+ unsigned int i;
+ dns_rdata_t rdata = DNS_RDATA_INIT;
+ dns_rdata_soa_t soa;
+ dns_rdataset_t found;
+ isc_result_t result;
+
+ for (i = 0; i < (sizeof(rfc1918names)/sizeof(*rfc1918names)); i++) {
+ if (dns_name_issubdomain(fname, &rfc1918names[i])) {
+ dns_rdataset_init(&found);
+ result = dns_ncache_getrdataset(rdataset,
+ &rfc1918names[i],
+ dns_rdatatype_soa,
+ &found);
+ if (result != ISC_R_SUCCESS)
+ return;
+
+ result = dns_rdataset_first(&found);
+ RUNTIME_CHECK(result == ISC_R_SUCCESS);
+ dns_rdataset_current(&found, &rdata);
+ result = dns_rdata_tostruct(&rdata, &soa, NULL);
+ if (result != ISC_R_SUCCESS)
+ return;
+ if (dns_name_equal(&soa.origin, &prisoner) &&
+ dns_name_equal(&soa.contact, &hostmaster)) {
+ char buf[DNS_NAME_FORMATSIZE];
+ dns_name_format(fname, buf, sizeof(buf));
+ ns_client_log(client, DNS_LOGCATEGORY_SECURITY,
+ NS_LOGMODULE_QUERY,
+ ISC_LOG_WARNING,
+ "RFC 1918 response from "
+ "Internet for %s", buf);
+ }
+ dns_rdataset_disassociate(&found);
+ return;
+ }
+ }
+}
+
/*
* Do the bulk of query processing for the current query of 'client'.
* If 'event' is non-NULL, we are returning from recursion and 'qtype'
@@ -2434,7 +3405,7 @@
goto resume;
}
-
+
/*
* Not returning from recursion.
*/
@@ -2527,10 +3498,20 @@
if (is_zone)
authoritative = ISC_TRUE;
-
+
if (event == NULL && client->query.restarts == 0) {
if (is_zone) {
- dns_zone_attach(zone, &client->query.authzone);
+#ifdef DLZ
+ if (zone != NULL) {
+ /*
+ * if is_zone = true, zone = NULL then this is
+ * a DLZ zone. Don't attempt to attach zone.
+ */
+#endif
+ dns_zone_attach(zone, &client->query.authzone);
+#ifdef DLZ
+ }
+#endif
dns_db_attach(db, &client->query.authdb);
}
client->query.authdbset = ISC_TRUE;
@@ -2625,7 +3606,11 @@
if (result == ISC_R_SUCCESS)
client->query.attributes |=
NS_QUERYATTR_RECURSING;
- else {
+ else if (result == DNS_R_DUPLICATE ||
+ result == DNS_R_DROP) {
+ /* Duplicate query. */
+ QUERY_ERROR(result);
+ } else {
/* Unable to recurse. */
QUERY_ERROR(DNS_R_SERVFAIL);
}
@@ -2723,7 +3708,7 @@
dbuf, DNS_SECTION_AUTHORITY);
client->query.gluedb = NULL;
if (WANTDNSSEC(client) && dns_db_issecure(db))
- query_addds(client, db, node);
+ query_addds(client, db, node, version);
} else {
/*
* We might have a better answer or delegation
@@ -2795,6 +3780,9 @@
if (result == ISC_R_SUCCESS)
client->query.attributes |=
NS_QUERYATTR_RECURSING;
+ else if (result == DNS_R_DUPLICATE ||
+ result == DNS_R_DROP)
+ QUERY_ERROR(result);
else
QUERY_ERROR(DNS_R_SERVFAIL);
} else {
@@ -2824,7 +3812,7 @@
client->query.attributes &=
~NS_QUERYATTR_CACHEGLUEOK;
if (WANTDNSSEC(client))
- query_addds(client, db, node);
+ query_addds(client, db, node, version);
}
}
goto cleanup;
@@ -2851,7 +3839,7 @@
/*
* 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;
@@ -2861,8 +3849,9 @@
*/
if (WANTDNSSEC(client)) {
if (dns_rdataset_isassociated(rdataset))
- query_addnxrrsetnsec(client, db, &fname,
- &rdataset, &sigrdataset);
+ query_addnxrrsetnsec(client, db, version,
+ &fname, &rdataset,
+ &sigrdataset);
}
goto cleanup;
case DNS_R_EMPTYWILD:
@@ -2891,10 +3880,14 @@
* the containing zone of an arbitrary name with a stub
* resolver and not have it cached.
*/
- if (qtype == dns_rdatatype_soa)
- result = query_addsoa(client, db, ISC_TRUE);
+ if (qtype == dns_rdatatype_soa &&
+#ifdef DLZ
+ zone != NULL &&
+#endif
+ dns_zone_getzeronosoattl(zone))
+ 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;
@@ -2907,7 +3900,7 @@
query_addrrset(client, &fname, &rdataset,
&sigrdataset,
NULL, DNS_SECTION_AUTHORITY);
- query_addwildcardproof(client, db,
+ query_addwildcardproof(client, db, version,
client->query.qname,
ISC_FALSE);
}
@@ -2930,6 +3923,14 @@
if (result == DNS_R_NCACHENXDOMAIN)
client->message->rcode = dns_rcode_nxdomain;
/*
+ * Look for RFC 1918 leakage from Internet.
+ */
+ if (result == DNS_R_NCACHENXDOMAIN &&
+ qtype == dns_rdatatype_ptr &&
+ client->message->rdclass == dns_rdataclass_in &&
+ dns_name_countlabels(fname) == 7)
+ warn_rfc1918(client, fname, rdataset);
+ /*
* We don't call query_addrrset() because we don't need any
* of its extra features (and things would probably break!).
*/
@@ -3090,7 +4091,7 @@
dns_message_puttempname(client->message, &tname);
if (result == ISC_R_NOSPACE) {
/*
- * RFC 2672, section 4.1, subsection 3c says
+ * RFC2672, section 4.1, subsection 3c says
* we should return YXDOMAIN if the constructed
* name would be too long.
*/
@@ -3212,6 +4213,21 @@
* an error unless we were searching for
* glue. Ugh.
*/
+ if (!is_zone) {
+ authoritative = ISC_FALSE;
+ dns_rdatasetiter_destroy(&rdsiter);
+ if (RECURSIONOK(client)) {
+ result = query_recurse(client,
+ qtype,
+ NULL,
+ NULL);
+ if (result == ISC_R_SUCCESS)
+ client->query.attributes |=
+ NS_QUERYATTR_RECURSING;
+ else
+ QUERY_ERROR(DNS_R_SERVFAIL); }
+ goto addauth;
+ }
/*
* We were searching for SIG records in
* a nonsecure zone. Send a "no error,
@@ -3220,7 +4236,8 @@
/*
* 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 {
@@ -3249,6 +4266,13 @@
noqname = rdataset;
else
noqname = NULL;
+ /*
+ * BIND 8 priming queries need the additional section.
+ */
+ if (is_zone && qtype == dns_rdatatype_ns &&
+ dns_name_equal(client->query.qname, dns_rootname))
+ client->query.attributes &= ~NS_QUERYATTR_NOADDITIONAL;
+
query_addrrset(client, &fname, &rdataset, sigrdatasetp, dbuf,
DNS_SECTION_ANSWER);
if (noqname != NULL)
@@ -3272,7 +4296,7 @@
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);
@@ -3285,7 +4309,7 @@
* DNSSEC wildcard proofs.
*/
if (need_wildcardproof && dns_db_issecure(db))
- query_addwildcardproof(client, db,
+ query_addwildcardproof(client, db, version,
dns_fixedname_name(&wildcardname),
ISC_TRUE);
cleanup:
@@ -3337,13 +4361,22 @@
if (eresult != ISC_R_SUCCESS &&
(!PARTIALANSWER(client) || WANTRECURSION(client))) {
- /*
- * If we don't have any answer to give the client,
- * or if the client requested recursion and thus wanted
- * the complete answer, send an error response.
- */
- query_error(client, eresult);
- ns_client_detach(&client);
+ if (eresult == DNS_R_DUPLICATE || eresult == DNS_R_DROP) {
+ /*
+ * This was a duplicate query that we are
+ * recursing on. Don't send a response now.
+ * The original query will still cause a response.
+ */
+ query_next(client, eresult);
+ } else {
+ /*
+ * If we don't have any answer to give the client,
+ * or if the client requested recursion and thus wanted
+ * the complete answer, send an error response.
+ */
+ query_error(client, eresult);
+ }
+ ns_client_detach(&client);
} else if (!RECURSING(client)) {
/*
* We are done. Set up sortlist data for the message
@@ -3418,14 +4451,16 @@
if (!client->view->enablednssec) {
message->flags &= ~DNS_MESSAGEFLAG_CD;
client->extflags &= ~DNS_MESSAGEEXTFLAG_DO;
+ if (client->opt != NULL)
+ client->opt->ttl &= ~DNS_MESSAGEEXTFLAG_DO;
}
if ((message->flags & DNS_MESSAGEFLAG_RD) != 0)
client->query.attributes |= NS_QUERYATTR_WANTRECURSION;
-
+
if ((client->extflags & DNS_MESSAGEEXTFLAG_DO) != 0)
client->attributes |= NS_CLIENTATTR_WANTDNSSEC;
-
+
if (client->view->minimalresponses)
client->query.attributes |= (NS_QUERYATTR_NOAUTHORITY |
NS_QUERYATTR_NOADDITIONAL);
@@ -3521,13 +4556,17 @@
* If the client has requested that DNSSEC checking be disabled,
* allow lookups to return pending data and instruct the resolver
* to return data before validation has completed.
+ *
+ * We don't need to set DNS_DBFIND_PENDINGOK when validation is
+ * disabled as there will be no pending data.
*/
if (message->flags & DNS_MESSAGEFLAG_CD ||
qtype == dns_rdatatype_rrsig)
{
client->query.dboptions |= DNS_DBFIND_PENDINGOK;
client->query.fetchoptions |= DNS_FETCHOPT_NOVALIDATE;
- }
+ } else if (!client->view->enablevalidation)
+ client->query.fetchoptions |= DNS_FETCHOPT_NOVALIDATE;
/*
* Allow glue NS records to be added to the authority section
@@ -3555,7 +4594,7 @@
* Set AD. We must clear it if we add non-validated data to a
* response.
*/
- if (client->view->enablednssec)
+ if (WANTDNSSEC(client))
message->flags |= DNS_MESSAGEFLAG_AD;
qclient = NULL;
--- contrib/bind9/bin/named/aclconf.c
+++ /dev/null
@@ -1,252 +0,0 @@
-/*
- * Copyright (C) 2004-2006 Internet Systems Consortium, Inc. ("ISC")
- * Copyright (C) 1999-2002 Internet Software Consortium.
- *
- * Permission to use, copy, modify, and distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- * PERFORMANCE OF THIS SOFTWARE.
- */
-
-/* $Id: aclconf.c,v 1.27.12.7 2006/03/02 00:37:20 marka Exp $ */
-
-#include <config.h>
-
-#include <isc/mem.h>
-#include <isc/string.h> /* Required for HP/UX (and others?) */
-#include <isc/util.h>
-
-#include <isccfg/namedconf.h>
-
-#include <dns/acl.h>
-#include <dns/fixedname.h>
-#include <dns/log.h>
-
-#include <named/aclconf.h>
-
-#define LOOP_MAGIC ISC_MAGIC('L','O','O','P')
-
-void
-ns_aclconfctx_init(ns_aclconfctx_t *ctx) {
- ISC_LIST_INIT(ctx->named_acl_cache);
-}
-
-void
-ns_aclconfctx_destroy(ns_aclconfctx_t *ctx) {
- dns_acl_t *dacl, *next;
- for (dacl = ISC_LIST_HEAD(ctx->named_acl_cache);
- dacl != NULL;
- dacl = next)
- {
- next = ISC_LIST_NEXT(dacl, nextincache);
- dns_acl_detach(&dacl);
- }
-}
-
-/*
- * Find the definition of the named acl whose name is "name".
- */
-static isc_result_t
-get_acl_def(const cfg_obj_t *cctx, const char *name, const cfg_obj_t **ret) {
- isc_result_t result;
- const cfg_obj_t *acls = NULL;
- const cfg_listelt_t *elt;
-
- result = cfg_map_get(cctx, "acl", &acls);
- if (result != ISC_R_SUCCESS)
- return (result);
- for (elt = cfg_list_first(acls);
- elt != NULL;
- elt = cfg_list_next(elt)) {
- const cfg_obj_t *acl = cfg_listelt_value(elt);
- const char *aclname = cfg_obj_asstring(cfg_tuple_get(acl, "name"));
- if (strcasecmp(aclname, name) == 0) {
- *ret = cfg_tuple_get(acl, "value");
- return (ISC_R_SUCCESS);
- }
- }
- return (ISC_R_NOTFOUND);
-}
-
-static isc_result_t
-convert_named_acl(const cfg_obj_t *nameobj, const cfg_obj_t *cctx,
- ns_aclconfctx_t *ctx, isc_mem_t *mctx,
- dns_acl_t **target)
-{
- isc_result_t result;
- const cfg_obj_t *cacl = NULL;
- dns_acl_t *dacl;
- dns_acl_t loop;
- const char *aclname = cfg_obj_asstring(nameobj);
-
- /* Look for an already-converted version. */
- for (dacl = ISC_LIST_HEAD(ctx->named_acl_cache);
- dacl != NULL;
- dacl = ISC_LIST_NEXT(dacl, nextincache))
- {
- if (strcasecmp(aclname, dacl->name) == 0) {
- if (ISC_MAGIC_VALID(dacl, LOOP_MAGIC)) {
- cfg_obj_log(nameobj, dns_lctx, ISC_LOG_ERROR,
- "acl loop detected: %s", aclname);
- return (ISC_R_FAILURE);
- }
- dns_acl_attach(dacl, target);
- return (ISC_R_SUCCESS);
- }
- }
- /* Not yet converted. Convert now. */
- result = get_acl_def(cctx, aclname, &cacl);
- if (result != ISC_R_SUCCESS) {
- cfg_obj_log(nameobj, dns_lctx, ISC_LOG_WARNING,
- "undefined ACL '%s'", aclname);
- return (result);
- }
- /*
- * Add a loop detection element.
- */
- memset(&loop, 0, sizeof(loop));
- ISC_LINK_INIT(&loop, nextincache);
- DE_CONST(aclname, loop.name);
- loop.magic = LOOP_MAGIC;
- ISC_LIST_APPEND(ctx->named_acl_cache, &loop, nextincache);
- result = ns_acl_fromconfig(cacl, cctx, ctx, mctx, &dacl);
- ISC_LIST_UNLINK(ctx->named_acl_cache, &loop, nextincache);
- loop.magic = 0;
- loop.name = NULL;
- if (result != ISC_R_SUCCESS)
- return (result);
- dacl->name = isc_mem_strdup(dacl->mctx, aclname);
- if (dacl->name == NULL)
- return (ISC_R_NOMEMORY);
- ISC_LIST_APPEND(ctx->named_acl_cache, dacl, nextincache);
- dns_acl_attach(dacl, target);
- return (ISC_R_SUCCESS);
-}
-
-static isc_result_t
-convert_keyname(const cfg_obj_t *keyobj, isc_mem_t *mctx, dns_name_t *dnsname) {
- isc_result_t result;
- isc_buffer_t buf;
- dns_fixedname_t fixname;
- unsigned int keylen;
- const char *txtname = cfg_obj_asstring(keyobj);
-
- keylen = strlen(txtname);
- isc_buffer_init(&buf, txtname, keylen);
- isc_buffer_add(&buf, keylen);
- dns_fixedname_init(&fixname);
- result = dns_name_fromtext(dns_fixedname_name(&fixname), &buf,
- dns_rootname, ISC_FALSE, NULL);
- if (result != ISC_R_SUCCESS) {
- cfg_obj_log(keyobj, dns_lctx, ISC_LOG_WARNING,
- "key name '%s' is not a valid domain name",
- txtname);
- return (result);
- }
- return (dns_name_dup(dns_fixedname_name(&fixname), mctx, dnsname));
-}
-
-isc_result_t
-ns_acl_fromconfig(const cfg_obj_t *caml,
- const cfg_obj_t *cctx,
- ns_aclconfctx_t *ctx,
- isc_mem_t *mctx,
- dns_acl_t **target)
-{
- isc_result_t result;
- unsigned int count;
- dns_acl_t *dacl = NULL;
- dns_aclelement_t *de;
- const cfg_listelt_t *elt;
-
- REQUIRE(target != NULL && *target == NULL);
-
- count = 0;
- for (elt = cfg_list_first(caml);
- elt != NULL;
- elt = cfg_list_next(elt))
- count++;
-
- result = dns_acl_create(mctx, count, &dacl);
- if (result != ISC_R_SUCCESS)
- return (result);
-
- de = dacl->elements;
- for (elt = cfg_list_first(caml);
- elt != NULL;
- elt = cfg_list_next(elt))
- {
- const cfg_obj_t *ce = cfg_listelt_value(elt);
- if (cfg_obj_istuple(ce)) {
- /* This must be a negated element. */
- ce = cfg_tuple_get(ce, "value");
- de->negative = ISC_TRUE;
- } else {
- de->negative = ISC_FALSE;
- }
-
- if (cfg_obj_isnetprefix(ce)) {
- /* Network prefix */
- de->type = dns_aclelementtype_ipprefix;
-
- cfg_obj_asnetprefix(ce,
- &de->u.ip_prefix.address,
- &de->u.ip_prefix.prefixlen);
- } else if (cfg_obj_istype(ce, &cfg_type_keyref)) {
- /* Key name */
- de->type = dns_aclelementtype_keyname;
- dns_name_init(&de->u.keyname, NULL);
- result = convert_keyname(ce, mctx, &de->u.keyname);
- if (result != ISC_R_SUCCESS)
- goto cleanup;
- } else if (cfg_obj_islist(ce)) {
- /* Nested ACL */
- de->type = dns_aclelementtype_nestedacl;
- result = ns_acl_fromconfig(ce, cctx, ctx, mctx,
- &de->u.nestedacl);
- if (result != ISC_R_SUCCESS)
- goto cleanup;
- } else if (cfg_obj_isstring(ce)) {
- /* ACL name */
- const char *name = cfg_obj_asstring(ce);
- if (strcasecmp(name, "localhost") == 0) {
- de->type = dns_aclelementtype_localhost;
- } else if (strcasecmp(name, "localnets") == 0) {
- de->type = dns_aclelementtype_localnets;
- } else if (strcasecmp(name, "any") == 0) {
- de->type = dns_aclelementtype_any;
- } else if (strcasecmp(name, "none") == 0) {
- de->type = dns_aclelementtype_any;
- de->negative = ISC_TF(! de->negative);
- } else {
- de->type = dns_aclelementtype_nestedacl;
- result = convert_named_acl(ce, cctx, ctx, mctx,
- &de->u.nestedacl);
- if (result != ISC_R_SUCCESS)
- goto cleanup;
- }
- } else {
- cfg_obj_log(ce, dns_lctx, ISC_LOG_WARNING,
- "address match list contains "
- "unsupported element type");
- result = ISC_R_FAILURE;
- goto cleanup;
- }
- de++;
- dacl->length++;
- }
-
- *target = dacl;
- return (ISC_R_SUCCESS);
-
- cleanup:
- dns_acl_detach(&dacl);
- return (result);
-}
Index: CHANGES
===================================================================
RCS file: /home/cvs/src/contrib/bind9/CHANGES,v
retrieving revision 1.3
retrieving revision 1.4
diff -L contrib/bind9/CHANGES -L contrib/bind9/CHANGES -u -r1.3 -r1.4
--- contrib/bind9/CHANGES
+++ contrib/bind9/CHANGES
@@ -1,12 +1,380 @@
- --- 9.3.4 released ---
+ --- 9.4.2 released ---
+ --- 9.4.2rc2 released ---
+
+2259. [bug] Reverse incorrect LIBINTERFACE bump of libisc
+ in 9.4.2rc1. Applications built against 9.4.2rc1
+ will need to be rebuilt.
+
+2258. [bug] Fallback from IXFR/TSIG to SOA/AXFR/TSIG broken.
+ [RT #17241]
+
+2257. [bug] win32: Use the full path to vcredist_x86.exe when
+ calling it. [RT #17222]
+
+2256. [bug] win32: Correctly register the installation location of
+ bindevt.dll. [RT #17159]
+
+2255. [bug] L.ROOT-SERVERS.NET is now 199.7.83.42.
+
+2254. [bug] timer.c:dispatch() failed to lock timer->lock
+ when reading timer->idle allowing it to see
+ intermediate values as timer->idle was reset by
+ isc_timer_touch(). [RT #17243]
+
+ --- 9.4.2rc1 released ---
+
+2251. [doc] Update memstatistics-file documentation to reflect
+ reality. Note there is behaviour change for BIND 9.5.
+ [RT #17113]
+
+2249. [bug] Only set Authentic Data bit if client requested
+ DNSSEC, per RFC 3655 [RT #17175]
+
+2248. [cleanup] Fix several errors reported by Coverity. [RT #17160]
+
+2245. [bug] Validating lack of DS records at trust anchors wasn't
+ working. [RT #17151]
+
+2238. [bug] It was possible to trigger a REQUIRE when a
+ validation was cancelled. [RT #17106]
+
+2237. [bug] libbind: res_init() was not thread aware. [RT #17123]
+
+2236. [bug] dnssec-signzone failed to preserve the case of
+ of wildcard owner names. [RT #17085]
+
+2235. [bug] <isc/atomic.h> was not being installed. [RT #17135]
+
+2234. [port] Correct some compiler warnings on SCO OSr5 [RT #17134]
+
+2232. [bug] dns_adb_findaddrinfo() could fail and return
+ ISC_R_SUCCESS. [RT #17137]
+
+2231. [bug] Building dlzbdb (contrib/dlz/bin/dlzbdb) was broken.
+ [RT #17088]
+
+2230. [bug] We could INSIST reading a corrupted journal.
+ [RT #17132]
+
+2228. [contrib] contrib: Change 2188 was incomplete.
+
+2227. [cleanup] Tidied up the FAQ. [RT #17121]
+
+2225. [bug] More support for systems with no IPv4 addresses.
+ [RT #17111]
+
+2224. [bug] Defer journal compaction if a xfrin is in progress.
+ [RT #17119]
+
+2223. [bug] Make a new journal when compacting. [RT #17119]
+
+2221. [bug] Set the event result code to reflect the actual
+ record returned to caller when a cache update is
+ rejected due to a more credible answer existing.
+ [RT #17017]
+
+2220. [bug] win32: Address a race condition in final shutdown of
+ the Windows socket code. [RT #17028]
+
+2219. [bug] Apply zone consistancy checks to additions, not
+ removals, when updating. [RT #17049]
+
+2218. [bug] Remove unnecessary REQUIRE from dns_validator_create().
+ [RT #16976]
+
+2216. [cleanup] Fix a number of errors reported by Coverity.
+ [RT #17094]
+
+2215. [bug] Bad REQUIRE check isc_hmacsha1_verify(). [RT #17094]
+
+2214. [bug] Deregister OpenSSL lock callback when cleaning
+ up. Reorder OpenSSL cleanup so that RAND_cleanup()
+ is called before the locks are destroyed. [RT #17098]
+
+2213. [bug] SIG0 diagnostic failure messages were looking at the
+ wrong status code. [RT #17101]
+
+2212. [func] 'host -m' now causes memory statistics and active
+ memory to be printed at exit. [RT 17028]
+
+2210. [bug] Deleting class specific records via UPDATE could
+ fail. [RT #17074]
+
+2209. [port] osx: linking against user supplied static OpenSSL
+ libraries failed as the system ones were still being
+ found. [RT #17078]
+
+2208. [port] win32: make sure both build methods produce the
+ same output. [RT #17058]
+
+2207. [port] Some implementations of getaddrinfo() fail to set
+ ai_canonname correctly. [RT #17061]
+
+ --- 9.4.2b1 released ---
+
+2206. [security] "allow-query-cache" and "allow-recursion" now
+ cross inherit from each other.
+
+ If allow-query-cache is not set in named.conf then
+ allow-recursion is used if set, otherwise allow-query
+ is used if set, otherwise the default (localnets;
+ localhost;) is used.
+
+ If allow-recursion is not set in named.conf then
+ allow-query-cache is used if set, otherwise allow-query
+ is used if set, otherwise the default (localnets;
+ localhost;) is used.
+
+ [RT #16987]
+
+2205. [bug] libbind: change #2119 broke thread support. [RT #16982]
+
+2203. [security] Query id generation was cryptographically weak.
+ [RT # 16915]
+
+2202. [security] The default acls for allow-query-cache and
+ allow-recursion were not being applied. [RT #16960]
+
+2200. [bug] The search for cached NSEC records was stopping to
+ early leading to excessive DLV queries. [RT #16930]
+
+2199. [bug] win32: don't call WSAStartup() while loading dlls.
+ [RT #16911]
+
+2198. [bug] win32: RegCloseKey() could be called when
+ RegOpenKeyEx() failed. [RT #16911]
+
+2197. [bug] Add INSIST to catch negative responses which are
+ not setting the event result code appropriately.
+ [RT #16909]
+
+2196. [port] win32: yield processor while waiting for once to
+ to complete. [RT #16958]
+
+2194. [bug] Close journal before calling 'done' in xfrin.c.
+
+2193. [port] win32: BINDInstall.exe is now linked statically.
+ [RT #16906]
+
+2192. [port] win32: use vcredist_x86.exe to install Visual
+ Studio's redistributable dlls if building with
+ Visual Stdio 2005 or later.
+
+2189. [bug] Handle socket() returning EINTR. [RT #15949]
+
+2188. [contrib] queryperf: autoconf changes to make the search for
+ libresolv or libbind more robust. [RT #16299]
+
+2187. [bug] query_addds(), query_addwildcardproof() and
+ query_addnxrrsetnsec() should take a version
+ arguement. [RT #16368]
+
+2186. [port] cygwin: libbind: check for struct sockaddr_storage
+ independently of IPv6. [RT #16482]
+
+2185. [port] sunos: libbind: check for ssize_t, memmove() and
+ memchr(). [RT #16463]
+
+2183. [bug] dnssec-signzone didn't handle offline private keys
+ well. [RT #16832]
+
+2182. [bug] dns_dispatch_createtcp() and dispatch_createudp()
+ could return ISC_R_SUCCESS when they ran out of
+ memory. [RT #16365]
+
+2181. [port] sunos: libbind: add paths.h from BIND 8. [RT #16462]
+
+2180. [cleanup] Remove bit test from 'compress_test' as they
+ are no longer needed. [RT #16497]
+
+2178. [bug] 'rndc reload' of a slave or stub zone resulted in
+ a reference leak. [RT #16867]
+
+2177. [bug] Array bounds overrun on read (rcodetext) at
+ debug level 10+. [RT #16798]
+
+2176. [contrib] dbus update to handle race condition during
+ initialisation (Bugzilla 235809). [RT #16842]
+
+2175. [bug] win32: windows broadcast condition variable support
+ was broken. [RT #16592]
+
+2174. [bug] I/O errors should always be fatal when reading
+ master files. [RT #16825]
+
+2173. [port] win32: When compiling with MSVS 2005 SP1 we also
+ need to ship Microsoft.VC80.MFCLOC.
+
+2171. [bug] Handle breaks in DNSSEC trust chains where the parent
+ servers are not DS aware (DS queries to the parent
+ return a referral to the child).
+
+2170. [func] Add acache processing to test suite. [RT #16711]
+
+2169. [bug] host, nslookup: when reporting NXDOMAIN report the
+ given name and not the last name searched for.
+ [RT #16763]
+
+2168. [bug] nsupdate: in non-interactive mode treat syntax errors
+ as fatal errors. [RT #16785]
+
+2167. [bug] When re-using a automatic zone named failed to
+ attach it to the new view. [RT #16786]
+
+2166. [bug] When running in batch mode, dig could misinterpret
+ a server address as a name to be looked up, causing
+ unexpected output. [RT #16743]
+
+2164. [bug] The code to determine how named-checkzone /
+ named-compilezone was called failed under windows.
+ [RT #16764]
+
+2162. [func] Allow "rrset-order fixed" to be disabled at compile
+ time. [RT #16665]
+
+2161. [bug] 'rndc flush' could report a false success. [RT #16698]
+
+2160. [bug] libisc wasn't handling NULL ifa_addr pointers returned
+ from getifaddrs(). [RT #16708]
+
+2159. [bug] Array bounds overrun in acache processing. [RT #16710]
+
+2158. [bug] ns_client_isself() failed to initialise key
+ leading to a REQUIRE failure. [RT #16688]
+
+2156. [bug] Fix node reference leaks in lookup.c:lookup_find(),
+ resolver.c:validated() and resolver.c:cache_name().
+ Fix a memory leak in rbtdb.c:free_noqname().
+ Make lookup.c:lookup_find() robust against
+ event leaks. [RT #16685]
+
+2155. [contrib] SQLite sdb module from jaboydjr at netwalk.com.
+ [RT #16694]
+
+2153. [bug] nsupdate could leak memory. [RT #16691]
+
+2152. [cleanup] Use sizeof(buf) instead of fixed number in
+ dighost.c:get_trusted_key(). [RT #16678]
+
+2151. [bug] Missing newline in usage message for journalprint.
+ [RT #16679]
+
+2150. [bug] 'rrset-order cyclic' uniformly distribute the
+ starting point for the first response for a given
+ RRset. [RT #16655]
+
+2149. [bug] isc_mem_checkdestroyed() failed to abort on
+ if there were still active memory contexts.
+ [RT #16672]
+
+2147. [bug] libbind: remove potential buffer overflow from
+ hmac_link.c. [RT #16437]
+
+2146. [cleanup] Silence Linux's spurious "obsolete setsockopt
+ SO_BSDCOMPAT" message. [RT #16641]
+
+2145. [bug] Check DS/DLV digest lengths for known digests.
+ [RT #16622]
+
+2144. [cleanup] Suppress logging of SERVFAIL from forwarders.
+ [RT #16619]
+
+2143. [bug] We failed to restart the IPv6 client when the
+ kernel failed to return the destination the
+ packet was sent to. [RT #16613]
+
+2142. [bug] Handle master files with a modification time that
+ matches the epoch. [RT# 16612]
+
+2141. [bug] dig/host should not be setting IDN_ASCCHECK (IDN
+ equivalent of LDH checks). [RT #16609]
+
+2140. [bug] libbind: missing unlock on pthread_key_create()
+ failures. [RT #16654]
+
+2139. [bug] dns_view_find() was being called with wrong type
+ in adb.c. [RT #16670]
+
+2119. [compat] libbind: allow res_init() to succeed enough to
+ return the default domain even if it was unable
+ to allocate memory.
+
+ --- 9.4.1 released ---
+
+2172. [bug] query_addsoa() was being called with a non zone db.
+ [RT #16834]
+
+ --- 9.4.0 released ---
+
+2138. [bug] Lock order reversal in resolver.c. [RT #16653]
+
+2137. [port] Mips little endian and/or mips 64 bit are now
+ supported for atomic operations. [RT#16648]
+
+2136. [bug] nslookup/host looped if there was no search list
+ and the host didn't exist. [RT #16657]
+
+2135. [bug] Uninitialised rdataset in sdlz.c. [RT# 16656]
+
+2133. [port] powerpc: Support both IBM and MacOS Power PC
+ assembler syntaxes. [RT #16647]
+
+2132. [bug] Missing unlock on out of memory in
+ dns_dispatchmgr_setudp().
+
+2131. [contrib] dlz/mysql: AXFR was broken. [RT #16630]
+
+2128. [doc] xsltproc --nonet, update DTD versions. [RT #16635]
+
+ --- 9.4.0rc2 released ---
+
+2127. [port] Improved OpenSSL 0.9.8 support. [RT #16563]
2126. [security] Serialise validation of type ANY responses. [RT #16555]
+2125. [bug] dns_zone_getzeronosoattl() REQUIRE failure if DLZ
+ was defined. [RT #16574]
+
2124. [security] It was possible to dereference a freed fetch
context. [RT #16584]
- --- 9.3.3 released ---
+2120. [doc] Fix markup on nsupdate man page. [RT #16556]
+
+ --- 9.4.0rc1 released ---
+
+2118. [bug] Handle response with long chains of domain name
+ compression pointers which point to other compression
+ pointers. [RT #16427]
+
+2117. [bug] DNSSEC fixes: named could fail to cache NSEC records
+ which could lead to validation failures. named didn't
+ handle negative DS responses that were in the process
+ of being validated. Check CNAME bit before accepting
+ NODATA proof. To be able to ignore a child NSEC there
+ must be SOA (and NS) set in the bitmap. [RT #16399]
+
+2116. [bug] 'rndc reload' could cause the cache to continually
+ be cleaned. [RT #16401]
+
+2115. [bug] 'rndc reconfig' could trigger a INSIST if the
+ number of masters for a zone was reduced. [RT #16444]
+
+2114. [bug] dig/host/nslookup: searches for names with multiple
+ labels were failing. [RT #16447]
+
+2113. [bug] nsupdate: if a zone is specified it should be used
+ for server discover. [RT# 16455]
+
+2112. [security] Warn if weak RSA exponent is used. [RT #16460]
+
+2111. [bug] Fix a number of errors reported by Coverity.
+ [RT #16507]
+
+2110. [bug] "minimal-response yes;" interacted badly with BIND 8
+ priming queries. [RT #16491]
+
+2109. [port] libbind: silence aix 5.3 compiler warnings. [RT #16502]
2107. [bug] dighost.c: more cleanup of buffers. [RT #16499]
@@ -17,14 +385,24 @@
2102. [port] Silence solaris 10 warnings.
+ --- 9.4.0b4 released ---
+
2101. [bug] OpenSSL version checks were not quite right.
[RT #16476]
2100. [port] win32: copy libeay32.dll to Build\Debug.
+ Copy Debug\named-checkzone to Debug\named-compilezone.
2099. [port] win32: more manifiest issues.
- --- 9.3.3rc3 released ---
+2098. [bug] Race in rbtdb.c:no_references(), which occasionally
+ triggered an INSIST failure about the node lock
+ reference. [RT #16411]
+
+ --- 9.4.0b3 released ---
+
+2097. [bug] named could reference a destroyed memory context
+ after being reloaded / reconfigured. [RT #16428]
2096. [bug] libbind: handle applications that fail to detect
res_init() failures better.
@@ -34,6 +412,8 @@
2094. [contrib] Update named-bootconf. [RT# 16404]
+2093. [bug] named-checkzone -s was broken.
+
2092. [bug] win32: dig, host, nslookup. Use registry config
if resolv.conf does not exist or no nameservers
listed. [RT #15877]
@@ -51,6 +431,9 @@
2088. [security] Change the default RSA exponent from 3 to 65537.
[RT #16391]
+2087. [port] libisc failed to compile on OS's w/o a vsnprintf.
+ [RT #16382]
+
2086. [port] libbind: FreeBSD now has get*by*_r() functions.
[RT #16403]
@@ -62,7 +445,7 @@
2082. [doc] Document 'cache-file' as a test only option.
- --- 9.3.3rc2 released ---
+ --- 9.4.0b2 released ---
2081. [port] libbind: minor 64-bit portability fix in memcluster.c.
[RT #16360]
@@ -70,16 +453,30 @@
2080. [port] libbind: res_init.c did not compile on older versions
of Solaris. [RT #16363]
+2079. [bug] The lame cache was not handling multiple types
+ correctly. [RT #16361]
+
+2078. [bug] dnssec-checkzone output style "default" was badly
+ named. It is now called "relative". [RT #16326]
+
+2077. [bug] 'dnssec-signzone -O raw' wasn't outputing the
+ complete signed zone. [RT #16326]
+
2076. [bug] Several files were missing #include <config.h>
causing build failures on OSF. [RT #16341]
+2075. [bug] The spillat timer event hander could leak memory.
+ [RT #16357]
+
2074. [bug] dns_request_createvia2(), dns_request_createvia3(),
dns_request_createraw2() and dns_request_createraw3()
failed to send multiple UDP requests. [RT #16349]
-2066. [security] Handle SIG queries gracefully. [RT #16300]
+2073. [bug] Incorrect semantics check for update policy "wildcard".
+ [RT #16353]
- --- 9.3.3rc1 released ---
+2072. [bug] We were not generating valid HMAC SHA digests.
+ [RT #16320]
2071. [port] Test whether gcc accepts -fno-strict-aliasing.
[RT #16324]
@@ -89,9 +486,14 @@
2069. [bug] Cross compiling was not working. [RT #16330]
+2068. [cleanup] Lower incremental tuning message to debug 1.
+ [RT #16319]
+
2067. [bug] 'rndc' could close the socket too early triggering
a INSIST under Windows. [RT #16317]
+2066. [security] Handle SIG queries gracefully. [RT #16300]
+
2065. [bug] libbind: probe for HPUX prototypes for
endprotoent_r() and endservent_r(). [RT 16313]
@@ -103,8 +505,24 @@
2062. [bug] 'dig +nssearch' was reusing a buffer before it had
been returned by the socket code. [RT #16307]
-2057. [bug] Make setting "ra" dependent on both allow-query and
- allow-recursion. [RT #16290]
+2061. [bug] Accept expired wildcard message reversed. [RT #16296]
+
+2060. [bug] Enabling DLZ support could leave views partially
+ configured. [RT #16295]
+
+ --- 9.4.0b1 released ---
+
+2059. [bug] Search into cache rbtdb could trigger an INSIST
+ failure while cleaning up a stale rdataset.
+ [RT #16292]
+
+2058. [bug] Adjust how we calculate rtt estimates in the presence
+ of authoritative servers that drop EDNS and/or CD
+ requests. Also fallback to EDNS/512 and plain DNS
+ faster for zones with less than 3 servers. [RT #16187]
+
+2057. [bug] Make setting "ra" dependent on both allow-query-cache
+ and allow-recursion. [RT #16290]
2056. [bug] dig: ixfr= was not being treated case insensitively
at all times. [RT #15955]
@@ -138,9 +556,31 @@
2047. [bug] Failed to initialise the interface flags to zero.
[RT #16245]
+2046. [bug] rbtdb.c:rdataset_setadditional() could cause duplicate
+ cleanup [RT #16247].
+
+2045. [func] Use lock buckets for acache entries to limit memory
+ consumption. [RT #16183]
+
+2044. [port] Add support for atomic operations for Itanium.
+ [RT #16179]
+
2043. [port] nsupdate/nslookup: Force the flushing of the prompt
for interactive sessions. [RT#16148]
+2042. [bug] named-checkconf was incorrectly rejecting the
+ logging category "config". [RT #16117]
+
+2041. [bug] "configure --with-dlz-bdb=yes" produced a bad
+ set of libraries to be linked. [RT #16129]
+
+2040. [bug] rbtdb no_references() could trigger an INSIST
+ failure with --enable-atomic. [RT #16022]
+
+2039. [func] Check that all buffers passed to the socket code
+ have been retrieved when the socket event is freed.
+ [RT #16122]
+
2038. [bug] dig/nslookup/host was unlinking from wrong list
when handling errors. [RT #16122]
@@ -153,7 +593,12 @@
2034. [bug] gcc: set -fno-strict-aliasing. [RT #16124]
- --- 9.3.3b1 released ---
+2033. [bug] We wern't creating multiple client memory contexts
+ on demand as expected. [RT #16095]
+
+ --- 9.4.0a6 released ---
+
+2032. [bug] Remove a INSIST in query_addadditional2(). [RT #16074]
2031. [bug] Emit a error message when "rndc refresh" is called on
a non slave/stub zone. [RT # 16073]
@@ -172,21 +617,80 @@
2026. [bug] Rate limit the two recursive client exceeded messages.
[RT #16044]
+2025. [func] Update "zone serial unchanged" message. [RT #16026]
+
2024. [bug] named emited spurious "zone serial unchanged"
messages on reload. [RT #16027]
2023. [bug] "make install" should create ${localstatedir}/run and
${sysconfdir} if they do not exist. [RT #16033]
+2022. [bug] If dnssec validation is disabled only assert CD if
+ CD was requested. [RT #16037]
+
+2021. [bug] dnssec-enable no; triggered a REQUIRE. [RT #16037]
+
+2020. [bug] rdataset_setadditional() could leak memory. [RT #16034]
+
+2019. [tuning] Reduce the amount of work performed per quantum
+ when cleaning the cache. [RT #15986]
+
+2018. [bug] Checking if the HMAC MD5 private file was broken.
+ [RT #15960]
+
+2017. [bug] allow-query default was not correct. [RT #15946]
+
2016. [bug] Return a partial answer if recursion is not
allowed but requested and we had the answer
to the original qname. [RT #15945]
+ --- 9.4.0a5 released ---
+
+2015. [cleanup] use-additional-cache is now acache-enable for
+ consistancy. Default acache-enable off in BIND 9.4
+ as it requires memory usage to be configured.
+ It may be enabled by default in BIND 9.5 once we
+ have more experience with it.
+
+2014. [func] Statistics about acache now recorded and sent
+ to log. [RT #15976]
+
2013. [bug] Handle unexpected TSIGs on unsigned AXFR/IXFR
responses more gracefully. [RT #15941]
+2012. [func] Don't insert new acache entries if acache is full.
+ [RT #15970]
+
+2011. [func] dnssec-signzone can now update the SOA record of
+ the signed zone, either as an increment or as the
+ system time(). [RT #15633]
+
+ --- 9.4.0a4 released ---
+
2009. [bug] libbind: coverity fixes. [RT #15808]
+2008. [func] It is now posssible to enable/disable DNSSEC
+ validation from rndc. This is useful for the
+ mobile hosts where the current connection point
+ breaks DNSSEC (firewall/proxy). [RT #15592]
+
+ rndc validation newstate [view]
+
+2007. [func] It is now possible to explicitly enable DNSSEC
+ validation. default dnssec-validation no; to
+ be changed to yes in 9.5.0. [RT #15674]
+
+2006. [security] Allow-query-cache and allow-recursion now default
+ to the builtin acls "localnets" and "localhost".
+
+ This is being done to make caching servers less
+ attractive as reflective amplifying targets for
+ spoofed traffic. This still leave authoritative
+ servers exposed.
+
+ The best fix is for full BCP 38 deployment to
+ remove spoofed traffic.
+
2005. [bug] libbind: Retransmission timeouts should be
based on which attempt it is to the nameserver
and not the nameserver itself. [RT #13548]
@@ -202,8 +706,13 @@
2002. [bug] libbind: tighten the constraints on when
struct addrinfo._ai_pad exists. [RT #15783]
+2001. [func] Check the KSK flag when updating a secure dynamic zone.
+ New zone option "update-check-ksk yes;". [RT #15817]
+
2000. [bug] memmove()/strtol() fix was incomplete. [RT #15812]
+1999. [func] Implement "rrset-order fixed". [RT #13662]
+
1998. [bug] Restrict handling of fifos as sockets to just SunOS.
This allows named to connect to entropy gathering
daemons that use fifos instead of sockets. [RT #15840]
@@ -212,6 +721,9 @@
when a positive one for the type was learnt.
[RT #15818]
+1996. [bug] nsupdate: if a zone has been specified it should
+ appear in the output of 'show'. [RT #15797]
+
1995. [bug] 'host' was reporting multiple "is an alias" messages.
[RT #15702]
@@ -221,6 +733,9 @@
after the timestamp if "print-time yes" was specified.
[RT #15844]
+1992. [bug] Not all incoming zone transfer messages included the
+ view. [RT #15825]
+
1991. [cleanup] The configuration data, once read, should be treated
as readonly. Expand the use of const to enforce this
at compile time. [RT #15813]
@@ -232,6 +747,13 @@
1989. [bug] win32: don't check the service password when
re-installing. [RT #15882]
+1988. [bug] Remove a bus error from the SHA256/SHA512 support.
+ [RT #15878]
+
+1987. [func] DS/DLV SHA256 digest algorithm support. [RT #15608]
+
+1986. [func] Report when a zone is removed. [RT #15849]
+
1985. [protocol] DLV has now been assigned a official type code of
32769. [RT #15807]
@@ -243,6 +765,12 @@
zone. You do not however have to upgrade all
servers for a zone with DLV records simultaniously.
+1984. [func] dig, nslookup and host now advertise a 4096 byte
+ EDNS UDP buffer size by default. [RT #15855]
+
+1983. [func] Two new update policies. "selfsub" and "selfwild".
+ [RT #12895]
+
1982. [bug] DNSKEY was being accepted on the parent side of
a delegation. KEY is still accepted there for
RFC 3007 validated updates. [RT #15620]
@@ -250,6 +778,9 @@
1981. [bug] win32: condition.c:wait() could fail to reattain
the mutex lock.
+1980. [func] dnssec-signzone: output the SOA record as the
+ first record in the signed zone. [RT #15758]
+
1979. [port] linux: allow named to drop core after changing
user ids. [RT #15753]
@@ -264,7 +795,10 @@
hex strings with comments. [RT #15814]
1974. [doc] List each of the zone types and associated zone
- options seperately in the ARM.
+ options separately in the ARM.
+
+1973. [func] TSIG HMACSHA1, HMACSHA224, HMACSHA256, HMACSHA384 and
+ HMACSHA512 support. [RT #13606]
1972. [contrib] DBUS dynamic forwarders integation from
Jason Vas Dias <jvdias at redhat.com>.
@@ -280,9 +814,16 @@
1968. [bug] Missing lock in resolver.c:validated(). [RT #15739]
+1967. [func] dig/nslookup/host: warn about missing "QR". [RT #15779]
+
1966. [bug] Don't set CD when we have fallen back to plain DNS.
[RT #15727]
+1965. [func] Suppress spurious "recusion requested but not
+ available" warning with 'dig +qr'. [RT #15780].
+
+1964. [func] Separate out MX and SRV to CNAME checks. [RT #15723]
+
1963. [port] Tru64 4.0E doesn't support send() and recv().
[RT #15586]
@@ -295,6 +836,10 @@
1960. [bug] Update code should set NSEC ttls from SOA MINIMUM.
[RT #15465]
+1959. [func] Control the zeroing of the negative response TTL to
+ a soa query. Defaults "zero-no-soa-ttl yes;" and
+ "zero-no-soa-ttl-cache no;". [RT #15460]
+
1958. [bug] Named failed to update the zone's secure state
until the zone was reloaded. [RT #15412]
@@ -307,6 +852,15 @@
1955. [bug] Pre-allocate the cache cleaning interator. [RT #14998]
+1954. [func] Named now falls back to advertising EDNS with a
+ 512 byte receive buffer if the initial EDNS queries
+ fail. [RT #14852]
+
+1953. [func] The maximum EDNS UDP response named will send can
+ now be set in named.conf (max-udp-size). This is
+ independent of the advertised receive buffer
+ (edns-udp-size). [RT #14852]
+
1952. [port] hpux: tell the linker to build a runtime link
path "-Wl,+b:". [RT #14816].
@@ -318,19 +872,36 @@
a TCP socket. This prevents the source address being
set for TCP connections. [RT #15628]
+1949. [func] Addition memory leakage checks. [RT #15544]
+
1948. [bug] If was possible to trigger a REQUIRE failure in
xfrin.c:maybe_free() if named ran out of memory.
[RT #15568]
+1947. [func] It is now possible to configure named to accept
+ expired RRSIGs. Default "dnssec-accept-expired no;".
+ Setting "dnssec-accept-expired yes;" leaves named
+ vulnerable to replay attacks. [RT #14685]
+
1946. [bug] resume_dslookup() could trigger a REQUIRE failure
when using forwarders. [RT #15549]
+1945. [cleanup] dnssec-keygen: RSA (RSAMD5) is nolonger recommended.
+ To generate a RSAMD5 key you must explicitly request
+ RSAMD5. [RT #13780]
+
1944. [cleanup] isc_hash_create() does not need a read/write lock.
[RT #15522]
1943. [bug] Set the loadtime after rolling forward the journal.
[RT #15647]
+1597. [func] Allow notify-source and query-source to be specified
+ on a per server basis similar to transfer-source.
+ [RT #6496]
+
+ --- 9.4.0a3 released ---
+
1942. [bug] If the name of a DNSKEY match that of one in
trusted-keys do not attempt to validate the DNSKEY
using the parents DS RRset. [RT #15649]
@@ -341,31 +912,46 @@
1940. [bug] Fixed a number of error conditions reported by
Coverity.
-1939. [bug] The resolver could dereference a null pointer after
+1939. [bug] The resolver could dereference a null pointer after
validation if all the queries have timed out.
[RT #15528]
1938. [bug] The validator was not correctly handling unsecure
negative responses at or below a SEP. [RT #15528]
+1937. [bug] sdlz doesn't handle RRSIG records. [RT #15564]
+
+1936. [bug] The validator could leak memory. [RT #15544]
+
+1935. [bug] 'acache' was DO sensitive. [RT #15430]
+
+1934. [func] Validate pending NS RRsets, in the authority section,
+ prior to returning them if it can be done without
+ requiring DNSKEYs to be fetched. [RT #15430]
+
1919. [contrib] queryperf: a set of new features: collecting/printing
response delays, printing intermediate results, and
adjusting query rate for the "target" qps.
- --- 9.3.2 released ---
-
- --- 9.3.2rc1 released ---
+ --- 9.4.0a2 released ---
-1936. [bug] The validator could leak memory. [RT #15544]
+1933. [bug] dump_rdataset_raw() had a incorrect INSIST. [RT #15534]
1932. [bug] hpux: LDFLAGS was getting corrupted. [RT #15530]
- --- 9.3.2b2 released ---
+1931. [bug] Per-client mctx could require a huge amount of memory,
+ particularly for a busy caching server. [RT #15519]
1930. [port] HPUX: ia64 support. [RT #15473]
1929. [port] FreeBSD: extend use of PTHREAD_SCOPE_SYSTEM.
+1928. [bug] Race in rbtdb.c:currentversion(). [RT #15517]
+
+1927. [bug] Access to soanode or nsnode in rbtdb violated the
+ lock order rule and could cause a dead lock.
+ [RT# 15518]
+
1926. [bug] The Windows installer did not check for empty
passwords. BINDinstall was being installed in
the wrong place. [RT #15483]
@@ -377,17 +963,35 @@
1923. [bug] ns_client_detach() called too early. [RT #15499]
- --- 9.3.2b1 released ---
+1922. [bug] check-tool.c:setup_logging() missing call to
+ dns_log_setcontext().
+
+1921. [bug] Client memory contexts were not using internal
+ malloc. [RT# 15434]
+
+1920. [bug] The cache rbtdb lock array was too small to
+ have the desired performance characteristics.
+ [RT #15454]
+
+ --- 9.4.0a1 released ---
+
+1918. [bug] Memory leak when checking acls. [RT #15391]
1917. [doc] funcsynopsisinfo wasn't being treated as verbatim
when generating man pages. [RT #15385]
+1916. [func] Integrate contibuted IDN code from JPNIC. [RT #15383]
+
1915. [bug] dig +ndots was broken. [RT #15215]
1914. [protocol] DS is required to accept mnemonic algorithms
(RFC 4034). Still emit numeric algorithms for
compatability with RFC 3658. [RT #15354]
+1913. [func] Integrate contibuted DLZ code into named. [RT #11382]
+
+1912. [port] aix: atomic locking for powerpc. [RT #15020]
+
1911. [bug] Update windows socket code. [RT #14965]
1910. [bug] dig's +sigchase code overhauled. [RT #14933]
@@ -395,44 +999,113 @@
1909. [bug] The DLV code has been re-worked to make no longer
query order sensitive. [RT #14933]
+1908. [func] dig now warns if 'RA' is not set in the answer when
+ 'RD' was set in the query. host/nslookup skip servers
+ that fail to set 'RA' when 'RD' is set unless a server
+ is explicitly set. [RT #15005]
+
+1907. [func] host/nslookup now continue (default)/fail on SERVFAIL.
+ [RT #15006]
+
+1906. [func] dig now has a '-q queryname' and '+showsearch' options.
+ [RT #15034]
+
1905. [bug] Strings returned from cfg_obj_asstring() should be
- treated as read-only. [RT #15256]
+ treated as read-only. The prototype for
+ cfg_obj_asstring() has been updated to reflect this.
+ [RT #15256]
+
+1904. [func] Automatic empty zone creation for D.F.IP6.ARPA and
+ friends. Note: RFC 1918 zones are not yet covered by
+ this but are likely to be in a future release.
+
+ New options: empty-server, empty-contact,
+ empty-zones-enable and disable-empty-zone.
+
+1903. [func] ISC string copy API.
+
+1902. [func] Attempt to make the amount of work performed in a
+ iteration self tuning. The covers nodes clean from
+ the cache per iteration, nodes written to disk when
+ rewriting a master file and nodes destroyed per
+ iteration when destroying a zone or a cache.
+ [RT #14996]
1901. [cleanup] Don't add DNSKEY records to the additional section.
1900. [bug] ixfr-from-differences failed to ensure that the
serial number increased. [RT #15036]
-1896. [bug] Extend ISC_SOCKADDR_FORMATSIZE and
+1899. [func] named-checkconf now validates update-policy entries.
+ [RT #14963]
+
+1898. [bug] Extend ISC_SOCKADDR_FORMATSIZE and
ISC_NETADDR_FORMATSIZE to allow for scope details.
-1894. [bug] Recursive clients soft quota support wasn't working
+1897. [func] x86 and x86_64 now have separate atomic locking
+ implementations.
+
+1896. [bug] Recursive clients soft quota support wasn't working
as expected. [RT #15103]
-1893. [bug] A escaped character is, potentially, converted to
+1895. [bug] A escaped character is, potentially, converted to
the output character set too early. [RT #14666]
-1892. [port] Use uintptr_t if available. [RT #14606]
+1894. [doc] Review ARM for BIND 9.4.
+
+1893. [port] Use uintptr_t if available. [RT #14606]
+
+1892. [func] Support for SPF rdata type. [RT #15033]
+
+1891. [port] freebsd: pthread_mutex_init can fail if it runs out
+ of memory. [RT #14995]
+
+1890. [func] Raise the UDP recieve buffer size to 32k if it is
+ less than 32k. [RT #14953]
1889. [port] sunos: non blocking i/o support. [RT #14951]
+1888. [func] Support for IPSECKEY rdata type. [RT #14967]
+
1887. [bug] The cache could delete expired records too fast for
clients with a virtual time in the past. [RT #14991]
1886. [bug] fctx_create() could return success even though it
failed. [RT #14993]
+1885. [func] dig: report the number of extra bytes still left in
+ the packet after processing all the records.
+
1884. [cleanup] dighost.c: move external declarations into <dig/dig.h>.
1883. [bug] dnssec-signzone, dnssec-keygen: handle negative debug
levels. [RT #14962]
+1882. [func] Limit the number of recursive clients that can be
+ waiting for a single query (<qname,qtype,qclass>) to
+ resolve. New options clients-per-query and
+ max-clients-per-query.
+
1881. [func] Add a system test for named-checkconf. [RT #14931]
+1880. [func] The lame cache is now done on a <qname,qclass,qtype>
+ basis as some servers only appear to be lame for
+ certain query types. [RT #14916]
+
+1879. [func] "USE INTERNAL MALLOC" is now runtime selectable.
+ [RT #14892]
+
+1878. [func] Detect duplicates of UDP queries we are recursing on
+ and drop them. New stats category "duplicate".
+ [RT #2471]
+
1877. [bug] Fix unreasonably low quantum on call to
dns_rbt_destroy2(). Remove unnecessay unhash_node()
call. [RT #14919]
+1876. [func] Additional memory debugging support to track size
+ and mctx arguments. [RT #14814]
+
1875. [bug] process_dhtkey() was using the wrong memory context
to free some memory. [RT #14890]
@@ -443,6 +1116,15 @@
1872. [port] win32: Handle ERROR_NETNAME_DELETED. [RT #13753]
+1870. [func] Added framework for handling multiple EDNS versions.
+ [RT #14873]
+
+1869. [func] dig can now specify the EDNS version when making
+ a query. [RT #14873]
+
+1868. [func] edns-udp-size can now be overridden on a per
+ server basis. [RT #14851]
+
1867. [bug] It was possible to trigger a INSIST in
dlv_validatezonekey(). [RT #14846]
@@ -458,12 +1140,21 @@
1863. [bug] rrset-order "fixed" error messages not complete.
+1862. [func] Add additional zone data constancy checks.
+ named-checkzone has extended checking of NS, MX and
+ SRV record and the hosts they reference.
+ named has extended post zone load checks.
+ New zone options: check-mx and integrity-check.
+ [RT #4940]
+
1861. [bug] dig could trigger a INSIST on certain malformed
responses. [RT #14801]
1860. [port] solaris 2.8: hack_shutup_pthreadmutexinit was
incorrectly set. [RT #14775]
+1859. [func] Add support for CH A record. [RT #14695]
+
1858. [bug] The flush-zones-on-shutdown option wasn't being
parsed. [RT #14686]
@@ -486,6 +1177,8 @@
1852. [cleanup] Remove last vestiges of dnssec-signkey and
dnssec-makekeyset (removed from Makefile years ago).
+1851. [doc] Doxygen comment markup. [RT #11398]
+
1850. [bug] Memory leak in lwres_getipnodebyaddr(). [RT #14591]
1849. [doc] All forms of the man pages (docbook, man, html) should
@@ -520,6 +1213,9 @@
1841. [bug] "dig +nssearch" now makes a recursive query to
find the list of nameservers to query. [RT #13694]
+1840. [func] dnssec-signzone can now randomize signature end times
+ (dnssec-signzone -j jitter). [RT #13609]
+
1839. [bug] <isc/hash.h> was not being installed.
1838. [cleanup] Don't allow Linux capabilities to be inherited.
@@ -564,16 +1260,23 @@
1822. [bug] check-names test for RT was reversed. [RT #13382]
-1821. [doc] acls definitions are no longer required to be
- in named.conf prior to reference. They can be
- defined after being referenced.
-
1820. [bug] Gracefully handle acl loops. [RT #13659]
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. [func] Add support for additional zone file formats for
+ improving loading performance. The masterfile-format
+ option in named.conf can be used to specify a
+ non-default format. A separate command
+ named-compilezone was provided to generate zone files
+ in the new format. Additionally, the -I and -O options
+ for dnssec-signzone specify the input and output
+ formats.
+
1816. [port] UnixWare: failed to compile lib/isc/unix/net.c.
[RT #13597]
@@ -581,6 +1284,21 @@
without also setting the zone and it encountered
a CNAME and was using TSIG. [RT #13086]
+1814. [func] UNIX domain controls are now supported.
+
+1813. [func] Restructured the data locking framework using
+ architecture dependent atomic operations (when
+ available), improving response performance on
+ multi-processor machines significantly.
+ x86, x86_64, alpha, powerpc, and mips are currently
+ supported.
+
+1812. [port] win32: IN6_IS_ADDR_UNSPECIFIED macro is incorrect.
+ [RT #13453]
+
+1811. [func] Preserve the case of domain names in rdata during
+ zone transfers. [RT #13547]
+
1810. [bug] configure, lib/bind/configure make different default
decisions about whether to do a threaded build.
[RT #13212]
@@ -588,9 +1306,19 @@
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]
+
1807. [bug] When forwarding (forward only) set the active domain
from the forward zone name. [RT #13526]
-
+
+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]
+
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]
@@ -600,40 +1328,36 @@
1802. [bug] Handle connection resets better. [RT #11280]
+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]
+
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]
+
+1797. [func] named-checkconf now check acls to verify that they
+ only refer to existing acls. [RT #13101]
+
+1796. [func] "rndc freeze/thaw" now freezes/thaws all zones.
+
1795. [bug] "rndc dumpdb" was not fully documented. Minor
formating issues with "rndc dumpdb -all". [RT #13396]
-1791. [bug] 'host -t a' still printed out AAAA and MX records.
- [RT #13230]
+1794. [func] Named and named-checkzone can now both check for
+ non-terminal wildcard records.
- --- 9.3.1 released ---
+1793. [func] Extend adjusting TTL warning messages. [RT #13378]
-1818. [bug] 'named-checkconf -z' triggered an INSIST. [RT #13599]
+1792. [func] New zone option "notify-delay". Specify a minimum
+ delay between sets of NOTIFY messages.
- --- 9.3.1rc1 released ---
-
-1812. [port] win32: IN6_IS_ADDR_UNSPECIFIED macro is incorrect.
- [RT #13453]
-
-1808. [bug] zone.c:notify_zone() contained a race condition,
- zone->db could change underneath it. [RT #13511]
-
-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]
-
- --- 9.3.1beta2 released ---
-
-1800. [bug] Changes #1719 allowed a INSIST to be triggered.
- [RT #13428]
-
- --- 9.3.1beta1 released ---
+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.
@@ -706,6 +1430,9 @@
if there was no SOA record in the replacment db.
[RT #13016]
+1763. [func] Perform sanity checks on NS records which refer to
+ 'in zone' names. [RT #13002]
+
1762. [bug] isc_interfaceiter_create() could return ISC_R_SUCCESS
even when it failed. [RT #12995]
@@ -718,6 +1445,16 @@
1759. [bug] Named failed to startup if the OS supported IPv6
but had no IPv6 interfaces configured. [RT #12942]
+1758. [func] Don't send notify messages to self. [RT #12933]
+
+1757. [func] host now can turn on memory debugging flags with '-m'.
+
+1756. [func] named-checkconf now checks the logging configuration.
+ [RT #12352]
+
+1755. [func] allow-update is now settable at the options / view
+ level. [RT #6636]
+
1754. [bug] We wern't always attempting to query the parent
server for the DS records at the zone cut.
[RT #12774]
@@ -737,9 +1474,14 @@
1749. [bug] 'check-names response ignore;' failed to ignore.
[RT #12866]
+1748. [func] dig now returns the byte count for axfr/ixfr.
+
1747. [bug] BIND 8 compatability: named/named-checkconf failed
to parse "host-statistics-max" in named.conf.
+1746. [func] Make public the function to read a key file,
+ dst_key_read_public(). [RT #12450]
+
1745. [bug] Dig/host/nslookup accept replies from link locals
regardless of scope if no scope was specified when
query was sent. [RT #12745]
@@ -796,6 +1538,8 @@
1730. [port] Determine the length type used by the socket API.
[RT #12581]
+1729. [func] Improve check-names error messages.
+
1728. [doc] Update check-names documentation.
1727. [bug] named-checkzone: check-names support didn't match
@@ -833,6 +1577,9 @@
1716. [doc] named.conf(5) was being installed in the wrong
location. [RT# 12441]
+1715. [func] 'dig +trace' now randomly selects the next servers
+ to try. Report if there is a bad delegation.
+
1714. [bug] dig/host/nslookup were only trying the first
address when a nameserver was specified by name.
[RT #12286]
@@ -843,13 +1590,12 @@
1712. [bug] Missing FULLCHECK for "trusted-key" in dig.
- --- 9.3.0 released ---
-
1711. [func] 'rndc unfreeze' has been deprecated by 'rndc thaw'.
- --- 9.3.0rc4 released ---
+1710. [func] 'rndc notify zone [class [view]]' resend the NOTIFY
+ messages for the specified zone. [RT #9479]
-1709. [port] solaris: add SMF support.
+1709. [port] solaris: add SMF support from Sun.
1708. [cleanup] Replaced dns_fullname_hash() with dns_name_fullhash()
for conformance to the name space convention. Binary
@@ -861,6 +1607,8 @@
1706. [bug] 'rndc stop' failed to cause zones to be flushed
sometimes. [RT #12328]
+1705. [func] Allow the journal's name to be changed via named.conf.
+
1704. [port] lwres needed a snprintf() implementation for
platforms without snprintf(). Add missing
"#include <isc/print.h>". [RT #12321]
@@ -885,8 +1633,6 @@
specified one of listening addresses and a
different port than the listening port. [RT #12257]
- --- 9.3.0rc3 released ---
-
1696. [bug] dnssec-signzone failed to clean out nodes that
consisted of only NSEC and RRSIG records.
[RT #12154]
@@ -918,10 +1664,11 @@
1686. [bug] Named sent a extraneous NOTIFY when it received a
redundant UPDATE request. [RT #11943]
- --- 9.3.0rc2 released ---
-
1685. [bug] Change #1679 loop tests weren't quite right.
+1684. [func] ixfr-from-differences now takes master and slave in
+ addition to yes and no at the options and view levels.
+
1683. [bug] dig +sigchase could leak memory. [RT #11445]
1682. [port] Update configure test for (long long) printf format.
@@ -930,6 +1677,8 @@
1681. [bug] Only set SO_REUSEADDR when a port is specified in
isc_socket_bind(). [RT #11742]
+1680. [func] rndc: the source address can now be specified.
+
1679. [bug] When there was a single nameserver with multiple
addresses for a zone not all addresses were tried.
[RT #11706]
@@ -938,6 +1687,13 @@
1677. [bug] dig: +aaonly didn't work, +aaflag undocumented.
+1676. [func] New option "allow-query-cache". This lets
+ allow-query be used to specify the default zone
+ access level rather than having to have every
+ zone override the global value. allow-query-cache
+ can be set at both the options and view levels.
+ If allow-query-cache is not set allow-query applies.
+
1675. [bug] named would sometimes add extra NSEC records to
the authority section.
@@ -963,21 +1719,22 @@
1666. [bug] The optional port on hostnames in dual-stack-servers
was being ignored.
+1665. [func] rndc now allows addresses to be set in the
+ server clauses.
+
+1664. [bug] nsupdate needed KEY for SIG(0), not DNSKEY.
+
1663. [func] Look for OpenSSL by default.
+1662. [bug] Change #1658 failed to change one use of 'type'
+ to 'keytype'.
+
1661. [bug] Restore dns_name_concatenate() call in
adb.c:set_target(). [RT #11582]
1660. [bug] win32: connection_reset_fix() was being called
unconditionally. [RT #11595]
- --- 9.3.0rc1 released ---
-
-1664. [bug] nsupdate needed KEY for SIG(0), not DNSKEY.
-
-1662. [bug] Change #1658 failed to change one use of 'type'
- to 'keytype'.
-
1659. [cleanup] Cleanup some messages that were referring to KEY vs
DNSKEY, NXT vs NSEC and SIG vs RRSIG.
@@ -1034,8 +1791,6 @@
1641. [bug] Update the check-names description in ARM. [RT #11389]
- --- 9.3.0beta4 released ---
-
1640. [bug] win32: isc_socket_cancel(ISC_SOCKCANCEL_ACCEPT) was
incorrectly closing the socket. [RT #11291]
@@ -1080,12 +1835,6 @@
1625. [bug] named failed to load/transfer RFC2535 signed zones
which contained CNAMES. [RT# 11237]
-1606. [bug] DLV insecurity proof was failing.
-
-1605. [func] New dns_db_find() option DNS_DBFIND_COVERINGNSEC.
-
- --- 9.3.0beta3 released ---
-
1624. [bug] zonemgr_putio() call should be locked. [RT# 11163]
1623. [bug] A serial number of zero was being displayed in the
@@ -1130,16 +1879,6 @@
address type to be looked up with "@server".
[RT #11069]
-1600. [bug] Duplicate zone pre-load checks were not case
- insensitive.
-
-1599. [bug] Fix memory leak on error path when checking named.conf.
-
-1598. [func] Specify that certain parts of the namespace must
- be secure (dnssec-must-be-secure).
-
- --- 9.3.0beta2 released ---
-
1609. [func] dig now has support to chase DNSSEC signature chains.
Requires -DDIG_SIGCHASE=1 to be set in STD_CDEFINES.
@@ -1153,6 +1892,10 @@
1607. [bug] dig, host and nslookup were still using random()
to generate query ids. [RT# 11013]
+1606. [bug] DLV insecurity proof was failing.
+
+1605. [func] New dns_db_find() option DNS_DBFIND_COVERINGNSEC.
+
1604. [bug] A xfrout_ctx_create() failure would result in
xfrout_ctx_destroy() being called with a
partially initialized structure.
@@ -1167,15 +1910,26 @@
"allow-recursion" active' warning from view "_bind".
[RT# 10920]
+1600. [bug] Duplicate zone pre-load checks were not case
+ insensitive.
+
+1599. [bug] Fix memory leak on error path when checking named.conf.
+
+1598. [func] Specify that certain parts of the namespace must
+ be secure (dnssec-must-be-secure).
+
+1596. [func] Accept 'notify-source' style syntax for query-source.
+
+1595. [func] New notify type 'master-only'. Enable notify for
+ master zones only.
+
1594. [bug] 'rndc dumpdb' could prevent named from answering
queries while the dump was in progress. [RT #10565]
1593. [bug] rndc should return "unknown command" to unknown
commands. [RT# 10642]
- --- 9.3.0beta1 released ---
-
-1592. [bug] configure_view() could leak a dispatch. [RT #10675]
+1592. [bug] configure_view() could leak a dispatch. [RT# 10675]
1591. [bug] libbind: updated to BIND 8.4.5.
@@ -1190,6 +1944,8 @@
1586. [func] "check-names" is now implemented.
+1585. [placeholder]
+
1584. [bug] "make test" failed with a read only source tree.
[RT #10461]
@@ -1284,7 +2040,7 @@
[RT #6427]
1555. [func] 'rrset-order cyclic' no longer has a random starting
- point. [RT #7572]
+ point per query. [RT #7572]
1554. [bug] dig, host, nslookup failed when no nameservers
were specified in /etc/resolv.conf. [RT #8232]
@@ -1320,6 +2076,8 @@
1543. [bug] Logging using "versions unlimited" did not work.
+1542. [placeholder]
+
1541. [func] NSEC now uses new bitmap format.
1540. [bug] "rndc reload <dynamiczone>" was silently accepted.
@@ -1328,12 +2086,16 @@
1539. [bug] Open UDP sockets for notify-source and transfer-source
that use reserved ports at startup. [RT #9475]
+1538. [placeholder] rt9997
+
1537. [func] New option "querylog". If set specify whether query
logging is to be enabled or disabled at startup.
1536. [bug] Windows socket code failed to log a error description
when returning ISC_R_UNEXPECTED. [RT #9998]
+1535. [placeholder]
+
1534. [bug] Race condition when priming cache. [RT# 9940]
1533. [func] Warn if both "recursion no;" and "allow-recursion"
@@ -1357,6 +2119,12 @@
1527. [cleanup] Reduce the number of gettimeofday() calls without
losing necessary timer granularity.
+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.
[RT# 9360]
@@ -1435,11 +2203,91 @@
1500. [bug] host failed to lookup MX records. Also look up
AAAA records.
+1499. [bug] isc_random need to be seeded better if arc4random()
+ is not used.
+
+1498. [port] bsdos: 5.x support.
+
+1497. [placeholder]
+
+1496. [port] test for pthread_attr_setstacksize().
+
+1495. [cleanup] Replace hash functions with universal hash.
+
+1494. [security] Turn on RSA BLINDING as a precaution.
+
+1493. [placeholder]
+
+1492. [cleanup] Preserve rwlock quota context when upgrading /
+ downgrading. [RT #5599]
+
+1491. [bug] dns_master_dump*() would produce extraneous $ORIGIN
+ lines. [RT #6206]
+
+1490. [bug] Accept reading state as well as working state in
+ ns_client_next(). [RT #6813]
+
+1489. [compat] Treat 'allow-update' on slave zones as a warning.
+ [RT #3469]
+
+1488. [bug] Don't override trust levels for glue addresses.
+ [RT #5764]
+
+1487. [bug] A REQUIRE() failure could be triggered if a zone was
+ queued for transfer and the zone was then removed.
+ [RT #6189]
+
+1486. [bug] isc_print_snprintf() '%%' consumed one too many format
+ characters. [RT# 8230]
+
+1485. [bug] gen failed to handle high type values. [RT #6225]
+
+1484. [bug] The number of records reported after a AXFR was wrong.
+ [RT #6229]
+
+1483. [bug] dig axfr failed if the message id in the answer failed
+ to match that in the request. Only the id in the first
+ message is required to match. [RT #8138]
+
+1482. [bug] named could fail to start if the kernel supports
+ IPv6 but no interfaces are configured. Similarly
+ for IPv4. [RT #6229]
+
+1481. [bug] Refresh and stub queries failed to use masters keys
+ if specified. [RT #7391]
+
+1480. [bug] Provide replay protection for rndc commands. Full
+ replay protection requires both rndc and named to
+ be updated. Partial replay protection (limited
+ exposure after restart) is provided if just named
+ is updated.
+
+1479. [bug] cfg_create_tuple() failed to handle out of
+ memory cleanup. parse_list() would leak memory
+ on syntax errors.
+
+1478. [port] ifconfig.sh didn't account for other virtual
+ interfaces. It now takes a optional argument
+ to specify the first interface number. [RT #3907]
+
+1477. [bug] memory leak using stub zones and TSIG.
+
+1476. [placeholder]
+
1475. [port] Probe for old sprintf().
1474. [port] Provide strtoul() and memmove() for platforms
without them.
+1473. [bug] create_map() and create_string() failed to handle out
+ of memory cleanup. [RT #6813]
+
+1472. [contrib] idnkit-1.0 from JPNIC, replaces mdnkit.
+
+1471. [bug] libbind: updated to BIND 8.4.0.
+
+1470. [bug] Incorrect length passed to snprintf. [RT #5966]
+
1469. [func] Log end of outgoing zone transfer at same level
as the start of transfer is logged. [RT #4441]
@@ -1448,11 +2296,36 @@
1467. [func] $GENERATES now supports optional class and ttl.
+1466. [bug] lwresd configuration errors resulted in memory
+ and lock leaks. [RT #5228]
+
+1465. [bug] isc_base64_decodestring() and isc_base64_tobuffer()
+ failed to check that trailing bits were zero allowing
+ some invalid base64 strings to be accepted. [RT #5397]
+
+1464. [bug] Preserve "out of zone" data for outgoing zone
+ transfers. [RT #5192]
+
+1463. [bug] dns_rdata_from{wire,struct}() failed to catch bad
+ NXT bit maps. [RT #5577]
+
+1462. [bug] parse_sizeval() failed to check the token type.
+ [RT #5586]
+
+1461. [bug] Remove deadlock from rbtdb code. [RT #5599]
+
+1460. [bug] inet_pton() failed to reject certain malformed
+ IPv6 literals.
+
+1459. [placeholder]
+
1458. [cleanup] sprintf() -> snprintf().
1457. [port] Provide strlcat() and strlcpy() for platforms without
them.
+1456. [contrib] gen-data-queryperf.py from Stephane Bortzmeyer.
+
1455. [bug] <netaddr> missing from server grammar in
doc/misc/options. [RT #5616]
@@ -1462,6 +2335,25 @@
Use --enable-getifaddrs=glibc to force the use of
this version under linux machines.
+1453. [doc] ARM: $GENERATE example wasn't accurate. [RT #5298]
+
+1452. [placeholder]
+
+1451. [bug] rndc-confgen didn't exit with a error code for all
+ failures. [RT #5209]
+
+1450. [bug] Fetching expired glue failed under certain
+ circumstances. [RT #5124]
+
+1449. [bug] query_addbestns() didn't handle running out of memory
+ gracefully.
+
+1448. [bug] Handle empty wildcards labels.
+
+1447. [bug] We were casting (unsigned int) to and from (void *).
+ rdataset->private4 is now rdataset->privateuint4
+ to reflect a type change.
+
1446. [func] Implemented undocumented alternate transfer sources
from BIND 8. See use-alt-transfer-source,
alt-transfer-source and alt-transfer-source-v6.
@@ -1473,6 +2365,10 @@
content based on IP address. If you are not certain
ISC recommends setting use-alt-transfer-source no;
+1445. [bug] DNS_ADBFIND_STARTATROOT broke stub zones. This has
+ been replaced with DNS_ADBFIND_STARTATZONE which
+ causes the search to start using the closest zone.
+
1444. [func] dns_view_findzonecut2() allows you to specify if the
cache should be searched for zone cuts.
@@ -1491,11 +2387,25 @@
certain source ports (avoid-v4-udp-ports,
avoid-v6-udp-ports).
+1439. [bug] Named could return NOERROR with certain NOTIFY
+ failures. Return NOTAUTH if the NOTIFY zone is
+ not being served.
+
1438. [func] Log TSIG (if any) when logging NOTIFY requests.
+1437. [bug] Leave space for stdio to work in. [RT #5033]
+
1436. [func] dns_zonemgr_resumexfrs() can be used to restart
stalled transfers.
+1435. [bug] zmgr_resume_xfrs() was being called read locked
+ rather than write locked. zmgr_resume_xfrs()
+ was not being called if the zone was being
+ shutdown.
+
+1434. [bug] "rndc reconfig" failed to initiate the initial
+ zone transfer of new slave zones.
+
1433. [bug] named could trigger a REQUIRE failure if it could
not get a file descriptor when attempting to write
a master file. [RT #4347]
@@ -1503,17 +2413,44 @@
1432. [func] The advertised EDNS UDP buffer size can now be set
via named.conf (edns-udp-size).
+1431. [bug] isc_print_snprintf() "%s" with precision could walk off
+ end of argument. [RT #5191]
+
1430. [port] linux: IPv6 interface scanning support.
+1429. [bug] Prevent the cache getting locked to old servers.
+
+1428. [placeholder]
+
+1427. [bug] Race condition in adb with threaded build.
+
+1426. [placeholder]
+
+1425. [port] linux/libbind: define __USE_MISC when testing *_r()
+ function prototypes in netdb.h. [RT #4921]
+
+1424. [bug] EDNS version not being correctly printed.
+
+1423. [contrib] queryperf: added A6 and SRV.
+
1422. [func] Log name/type/class when denying a query. [RT #4663]
1421. [func] Differentiate updates that don't succeed due to
prerequisites (unsuccessful) vs other reasons
(failed).
+1420. [port] solaris: work around gcc optimizer bug.
+
+1419. [port] openbsd: use /dev/arandom. [RT #4950]
+
+1418. [bug] 'rndc reconfig' did not cause new slaves to load.
+
1417. [func] ID.SERVER/CHAOS is now a built in zone.
See "server-id" for how to configure.
+1416. [bug] Empty node should return NOERROR NODATA, not NXDOMAIN.
+ [RT #4715]
+
1415. [func] DS TTL now derived from NS ttl. NXT TTL now derived
from SOA MINIMUM.
@@ -1526,10 +2463,22 @@
has IPv6 address and you only support IPv4 or the
reverse. See dual-stack-servers.
+1411. [bug] empty nodes should stop wildcard matches. [RT #4802]
+
1410. [func] Handle records that live in the parent zone, e.g. DS.
1409. [bug] DS should have attribute DNS_RDATATYPEATTR_DNSSEC.
+1408. [bug] "make distclean" was not complete. [RT #4700]
+
+1407. [bug] lfsr incorrectly implements the shift register.
+ [RT #4617]
+
+1406. [bug] dispatch initializes one of the LFSR's with a incorrect
+ polynomial. [RT #4617]
+
+1405. [func] Use arc4random() if available.
+
1404. [bug] libbind: ns_name_ntol() could overwrite a zero length
buffer.
@@ -1540,666 +2489,86 @@
1402. [cleanup] A6 has been moved to experimental and is no longer
fully supported.
+1401. [bug] adb wasn't clearing state when the timer expired.
+
1400. [bug] Block the addition of wildcard NS records by IXFR
or UPDATE. [RT #3502]
-1398. [doc] ARM: notify-also should have been also-notify.
- [RT #4345]
-
-1396. [func] dnssec-signzone: adjust the default signing time by
- 1 hour to allow for clock skew.
-
-1394. [func] It is now possible to check if a particular element is
- in a acl. Remove duplicate entries from the localnets
- acl.
-
-1393. [port] Bind to individual IPv6 interfaces if IPV6_IPV6ONLY
- is not available in the kernel to prevent accidently
- listening on IPv4 interfaces.
-
-1392. [bug] named-checkzone: update usage.
-
-1391. [func] Add support for IPv6 scoped addresses in named.
-
-1390. [func] host now supports ixfr.
-
-1386. [bug] named-checkzone -z stopped on errors in a zone.
- [RT #3653]
-
-1383. [func] Track the serial number in a IXFR response and log if
- a mismatch occurs. This is a more specific error than
- "not exact". [RT #3445]
-
-1380. [func] 'rndc recursing' dump recursing queries to
- 'recursing-file = "named.recursing";'.
-
-1379. [func] 'rndc status' now reports tcp and recursion quota
- states.
-
-1378. [func] Improved positive feedback for 'rndc {reload|refresh}.
-
-1377. [func] dns_zone_load{new}() now reports if the zone was
- loaded, queued for loading to up to date.
-
-1376. [func] New function dns_zone_logc() to log to specified
- category.
-
-1375. [func] 'rndc dumpdb' now dumps the adb cache along with the
- data cache.
-
-1374. [func] dns_adb_dump() now logs the lame zones associated
- with each server.
-
-1371. [bug] notify-source-v6, transfer-source-v6 and
- query-source-v6 with explicit addresses and using the
- same ports as named was listening on could interfere
- with named's ability to answer queries sent to those
- addresses.
-
-1368. [func] remove support for bitstring labels.
-
-1367. [func] Use response times to select forwarders.
-
-1365. [func] "localhost" and "localnets" acls now include IPv6
- addresses / prefixes.
-
-1364. [func] Log file name when unable to open memory statistics
- and dump database files. [RT# 3437]
-
-1363. [func] Listen-on-v6 now supports specific addresses.
-
-1362. [bug] remove IFF_RUNNING test when scanning interfaces.
-
-1361. [func] log the reason for rejecting a server when resolving
- queries.
-
-1355. [bug] Fix DNSSEC wildcard proof for CNAME/DNAME.
-
-1344. [func] Log if the serial number on the master has gone
- backwards.
- If you have multiple machines specified in the masters
- clause you may want to set 'multi-master yes;' to
- suppress this warning.
-
-1343. [func] Log successful notifies received (info). Adjust log
- level for failed notifies to notice.
-
-1342. [func] Log remote address with TCP dispatch failures.
-
-1341. [func] Allow a rate limiter to be stalled.
-
-1339. [func] dig, host and nslookup now use IP6.ARPA for nibble
- lookups. Bit string lookups are no longer attempted.
-
-1336. [func] Nibble lookups under IP6.ARPA are now supported by
- dns_byaddr_create(). dns_byaddr_createptrname() is
- deprecated, use dns_byaddr_createptrname2() instead.
-
-1332. [func] Report the current serial with periodic commits when
- rolling forward the journal.
-
-1331. [func] Generate DNSSEC wildcard proofs.
-
-1329. [func] named-checkzone will now check if nameservers that
- appear to be IP addresses. Available modes "fail",
- "warn" (default) and "ignore" the results of the
- check.
-
-1328. [bug] The validator could incorrectly verify an invalid
- negative proof.
-
-1322. [bug] dnssec-signzone usage message was misleading.
-
-1321. [bug] If the last RRset in a zone is glue, dnssec-signzone
- would incorrectly duplicate its output and sign it.
-
-1313. [func] Query log now says if the query was signed (S) or
- if EDNS was used (E).
-
-1312. [func] Log TSIG key used w/ outgoing zone transfers.
-
-1309. [func] Log that a zone transfer was covered by a TSIG.
-
-1308. [func] DS (delegation signer) support.
-
-1304. [func] New function: dns_zone_name().
-
-1303. [func] Option 'flush-zones-on-shutdown <boolean>;'.
-
-1302. [func] Extended rndc dumpdb to support dumping of zones and
- view selection: 'dumpdb [-all|-zones|-cache] [view]'.
-
-1301. [func] New category 'update-security'.
-
-1300. [port] Compaq Trucluster support.
-
-1293. [func] Entropy can now be retrieved from EGDs. [RT #2438]
-
-1292. [func] Enable IPv6 support when using ioctl style interface
- scanning and OS supports SIOCGLIFADDR using struct
- if_laddrreq.
-
-1291. [func] Enable IPv6 support when using sysctl style interface
- scanning.
-
-1290. [func] "dig axfr" now reports the number of messages
- as well as the number of records.
-
-1285. [func] lwres: probe the system to see what address families
- are currently in use.
-
-1283. [func] Use "dataready" accept filter if available.
-
-1281. [func] Log zone when unable to get private keys to update
- zone. Log zone when NXT records are missing from
- secure zone.
-
-1278. [func] dig: now supports +[no]cl +[no]ttlid.
-
-1277. [func] You can now create your own customized printing
- styles: dns_master_stylecreate() and
- dns_master_styledestroy().
-
-1271. [bug] "recursion available: {denied,approved}" was too
- confusing.
-
-1267. [func] isc_file_openunique() now creates file using mode
- 0666 rather than 0600.
-
-1254. [func] preferred-glue option from BIND 8.3.
-
-1250. [func] Nsupdate will report the address the update was
- sent to.
-
-1247. [bug] Don't reset the interface index for link/site local
- addresses. [RT #2576]
-
-1246. [func] New functions isc_sockaddr_issitelocal(),
- isc_sockaddr_islinklocal(), isc_netaddr_issitelocal()
- and isc_netaddr_islinklocal().
-
-1243. [bug] It was possible to trigger a REQUIRE() in
- dns_message_findtype(). [RT #2659]
-
-1235. [func] Report 'out of memory' errors from openssl.
-
-1234. [bug] contrib/sdb: 'zonetodb' failed to call
- dns_result_register(). DNS_R_SEENINCLUDE should not
- be fatal.
-
-1233. [bug] The flags field of a KEY record can be expressed in
- hex as well as decimal.
-
-1226. [func] Use EDNS for zone refresh queries. [RT #2551]
-
-1225. [func] dns_message_setopt() no longer requires that
- dns_message_renderbegin() to have been called.
-
-1224. [bug] 'rrset-order' and 'sortlist' should be additive
- not exclusive.
-
-1223. [func] 'rrset-order' partially works 'cyclic' and 'random'
- are supported.
-
-1220. [func] Support for APL rdata type.
-
-1219. [func] Named now reports the TSIG extended error code when
- signature verification fails. [RT #1651]
-
-1217. [func] Report locations of previous key definition when a
- duplicate is detected.
-
-1213. [func] Report view associated with client if it is not a
- standard view (_default or _bind).
-
-1203. [func] Report locations of previous acl and zone definitions
- when a duplicate is detected.
-
-1202. [func] New functions: cfg_obj_line() and cfg_obj_file().
-
-1192. [bug] The seconds fields in LOC records were restricted
- to three decimal places. More decimal places should
- be allowed but warned about.
-
-1190. [func] Add the "rndc freeze" and "rndc unfreeze" commands.
- [RT #2394]
-
-1187. [bug] named was incorrectly returning DNSSEC records
- in negative responses when the DO bit was not set.
-
-1181. [func] Add the "key-directory" configuration statement,
- which allows the server to look for online signing
- keys in alternate directories.
-
-1180. [func] dnssec-keygen should always generate keys with
- protocol 3 (DNSSEC), since it's less confusing
- that way.
-
-1179. [func] Add SIG(0) support to nsupdate.
-
-1177. [func] Report view when loading zones if it is not a
- standard view (_default or _bind). [RT #2270]
-
-1171. [func] Added function isc_region_compare(), updated files in
- lib/dns to use this function instead of local one.
-
-1169. [func] Identify recursive queries in the query log.
-
-1163. [func] isc_time_formattimestamp() now includes the year.
-
-1159. [bug] MD and MF are not permitted to be loaded by RFC1123.
-
-1158. [func] Report the client's address when logging notify
- messages.
-
-1157. [func] match-clients and match-destinations now accept
- keys. [RT #2045]
-
-1155. [func] Recover from master files being removed from under
- us.
-
-1153. [func] 'rndc {stop|halt} -p' now reports the process id
- of the instance of named being shutdown.
-
-1151. [bug] nslookup failed to check that the arguments to
- the port, timeout, and retry options were
- valid integers and in range. [RT #2099]
-
-1150. [bug] named incorrectly accepted TTL values
- containing plus or minus signs, such as
- 1d+1h-1s.
-
-1149. [func] New function isc_parse_uint32().
-
-1148. [func] 'rndc-confgen -a' now provides positive feedback.
-
-1147. [func] Set IPV6_V6ONLY on IPv6 sockets if supported by
- the OS. listen-on-v6 { any; }; should no longer
- result in IPv4 queries be accepted. Similarly
- control { inet :: ... }; should no longer result
- in IPv4 connections being accepted. This can be
- overridden at compile time by defining
- ISC_ALLOW_MAPPED=1.
-
-1146. [func] Allow IPV6_IPV6ONLY to be set/cleared on a socket if
- supported by the OS by a new function
- isc_socket_ipv6only().
-
-1145. [func] "host" no longer reports a NOERROR/NODATA response
- by printing nothing. [RT #2065]
-
-1143. [bug] When a trusted-keys statement was present and named
- was built without crypto support, it would leak memory.
-
-1139. [func] It is now possible to flush a given name from the
- cache(s) via 'rndc flushname name [view]'. [RT #2051]
-
-1138. [func] It is now possible to flush a given name from the
- cache by calling the new function
- dns_cache_flushname().
-
-1137. [func] It is now possible to flush a given name from the
- ADB by calling the new function dns_adb_flushname().
-
-1135. [func] You can now override the default syslog() facility for
- named/lwresd at compile time. [RT #1982]
-
-1132. [func] Improve UPDATE prerequisite failure diagnostic messages.
-
-1128. [func] sdb drivers can now provide RR data in either text
- or wire format, the latter using the new functions
- dns_sdb_putrdata() and dns_sdb_putnamedrdata().
-
-1127. [func] rndc: If the server to contact has multiple addresses,
- try all of them.
-
-1119. [func] Added support in Win32 for NTFS file/directory ACL's
- for access control.
-
-1115. [func] Set maximum values for cleaning-interval,
- heartbeat-interval, interface-interval,
- max-transfer-idle-in, max-transfer-idle-out,
- max-transfer-time-in, max-transfer-time-out,
- statistics-interval of 28 days and
- sig-validity-interval of 3660 days. [RT #2002]
-
-1110. [bug] dig should only accept valid abbreviations of +options.
- [RT #2003]
-
-1105. [port] OpenUNIX 8 enable threads by default. [RT #1970]
-
-1080. [bug] BIND 8 compatibility: accept bare IP prefixes
- as the second element of a two-element top level
- sort list statement. [RT #1964]
-
-1079. [bug] BIND 8 compatibility: accept bare elements at top
- level of sort list treating them as if they were
- a single element list. [RT #1963]
-
-1077. [func] Do not accept further recursive clients when
- the total number of recursive lookups being
- processed exceeds max-recursive-clients, even
- if some of the lookups are internally generated.
- [RT #1915, #1938]
-
-1073. [bug] The ADB cache cleaning should also be space driven.
- [RT #1915, #1938]
-
-1067. [func] Allow quotas to be soft, isc_quota_soft().
-
-1065. [func] Runtime support to select new / old style interface
- scanning using ioctls.
-
-1060. [func] Move refresh, stub and notify UDP retry processing
- into dns_request.
-
-1059. [func] dns_request now support will now retry UDP queries,
- dns_request_createvia2() and dns_request_createraw2().
-
-1058. [func] Limited lifetime ticker timers are now available,
- isc_timertype_limited.
-
-1055. [func] Version and hostname queries can now be disabled
- using "version none;" and "hostname none;",
- respectively.
-
-1049. [func] "pid-file none;" will disable writing a pid file.
- [RT #1848]
-
-1037. [bug] Negative responses whose authority section contain
- SOA or NS records whose owner names are not equal
- equal to or parents of the query name should be
- rejected. [RT #1862]
-
-1036. [func] Silently drop requests received via multicast as
- long as there is no final multicast DNS standard.
-
-1035. [bug] If we respond to multicast queries (which we
- currently do not), respond from a unicast address
- as specified in RFC 1123. [RT #137]
-
-1034. [bug] Ignore the RD bit on multicast queries as specified
- in RFC 1123. [RT #137]
-
-1032. [func] hostname.bind/txt/chaos now returns the name of
- the machine hosting the nameserver. This is useful
- in diagnosing problems with anycast servers.
-
-1025. [bug] Don't use multicast addresses to resolve iterative
- queries. [RT #101]
-
-1024. [port] Compilation failed on HP-UX 11.11 due to
- incompatible use of the SIOCGLIFCONF macro
- name. [RT #1831]
-
-1023. [func] Accept hints without TTLs.
-
-1011. [cleanup] Removed isc_dir_current().
-
-1009. [port] OpenUNIX 8 support. [RT #1728]
-
-1008. [port] libtool.m4, ltmain.sh from libtool-1.4.2.
-
-1007. [port] config.guess, config.sub from autoconf-2.52.
-
-1003. [func] Add the +retry option to dig.
-
- 999. [func] "rndc retransfer zone [class [view]]" added.
- [RT #1752]
-
- 998. [func] named-checkzone now has arguments to specify the
- chroot directory (-t) and working directory (-w).
- [RT #1755]
-
- 997. [func] Add support for RSA-SHA1 keys (RFC3110).
-
- 996. [func] Issue warning if the configuration filename contains
- the chroot path.
-
- 994. [func] Treat non-authoritative responses to queries for type
- NS as referrals even if the NS records are in the
- answer section, because BIND 8 servers incorrectly
- send them that way. This is necessary for DNSSEC
- validation of the NS records of a secure zone to
- succeed when the parent is a BIND 8 server. [RT #1706]
-
- 993. [func] dig: -v now reports the version.
-
- 991. [func] Lower UDP refresh timeout messages to level
- debug 1.
-
- 985. [func] Consider network interfaces to be up iff they have
- a nonzero IP address rather than based on the
- IFF_UP flag. [RT #1160]
-
- 983. [func] The server now supports generating IXFR difference
- sequences for non-dynamic zones by comparing zone
- versions, when enabled using the new config
- option "ixfr-from-differences". [RT #1727]
-
- 982. [func] If "memstatistics-file" is set in options the memory
- statistics will be written to it.
-
- 981. [func] The dnssec tools can now take multiple '-r randomfile'
- arguments.
-
- 979. [func] Incremental master file dumping. dns_master_dumpinc(),
- dns_master_dumptostreaminc(), dns_dumpctx_attach(),
- dns_dumpctx_detach(), dns_dumpctx_cancel(),
- dns_dumpctx_db() and dns_dumpctx_version().
-
- 976. [func] named-checkconf can now test load master zones
- (named-checkconf -z). [RT #1468]
-
- 970. [func] 'max-journal-size' can now be used to set a target
- size for a journal.
-
- 969. [func] dig now supports the undocumented dig 8 feature
- of allowing arbitrary labels, not just dotted
- decimal quads, with the -x option. This can be
- used to conveniently look up RFC2317 names as in
- "dig -x 10.0.0.0-127". [RT #827, #1576, #1598]
-
- --- 9.2.3rc1 released ---
-
-1499. [bug] isc_random need to be seeded better if arc4random()
- is not used.
-
-1498. [port] bsdos: 5.x support.
-
-1497. [protocol] dig, nslookup and host now perform nibble lookups
- under IP6.ARPA, use -i for IP6.INT (dig and host).
- lwres now uses IP6.ARPA.
-
-1496. [port] test for pthread_attr_setstacksize().
-
-1495. [cleanup] Replace hash functions with universal hash.
-
-1494. [security] Turn on RSA BLINDING as a precaution.
-
-1493. [doc] A6 and "bitstring" labels are now experimental.
-
-1492. [cleanup] Preserve rwlock quota context when upgrading /
- downgrading. [RT #5599]
-
-1491. [bug] dns_master_dump*() would produce extraneous $ORIGIN
- lines. [RT #6206]
-
-1490. [bug] Accept reading state as well as working state in
- ns_client_next(). [RT #6813]
-
-1489. [compat] Treat 'allow-update' on slave zones as a warning.
- [RT #3469]
-
-1488. [bug] Don't override trust levels for glue addresses.
- [RT #5764]
-
-1487. [bug] A REQUIRE() failure could be triggered if a zone was
- queued for transfer and the zone was then removed.
- [RT #6189]
-
-1486. [bug] isc_print_snprintf() '%%' consumed one too many format
- characters. [RT# 8230]
-
-1485. [bug] gen failed to handle high type values. [RT #6225]
-
-1484. [bug] The number of records reported after a AXFR was wrong.
- [RT #6229]
-
-1483. [bug] dig axfr failed if the message id in the answer failed
- to match that in the request. Only the id in the first
- message is required to match. [RT #8138]
-
-1482. [bug] named could fail to start if the kernel supports
- IPv6 but no interfaces are configured. Similarly
- for IPv4. [RT #6229]
-
-1481. [bug] Refresh and stub queries failed to use masters keys
- if specified. [RT #7391]
-
-1480. [bug] Provide replay protection for rndc commands. Full
- replay protection requires both rndc and named to
- be updated. Partial replay protection (limited
- exposure after restart) is provided if just named
- is updated.
-
-1479. [bug] cfg_create_tuple() failed to handle out of
- memory cleanup. parse_list() would leak memory
- on syntax errors.
-
-1478. [port] ifconfig.sh didn't account for other virtual
- interfaces. It now takes a optional argument
- to specify the first interface number. [RT #3907]
-
-1477. [bug] memory leak using stub zones and TSIG.
-
-1476. [port] win32: port unreachables were blocking further i/o
- on sockets (Windows 2000 SP2 and later).
-
-1473. [bug] create_map() and create_string() failed to handle out
- of memory cleanup. [RT #6813]
-
-1472. [contrib] idnkit-1.0 from JPNIC, replaces mdnkit.
-
-1471. [bug] libbind: updated to BIND 8.4.0.
-
-1470. [bug] Incorrect length passed to snprintf. [RT #5966]
-
-1466. [bug] lwresd configuration errors resulted in memory
- and lock leaks. [RT #5228]
-
-1465. [bug] isc_base64_decodestring() and isc_base64_tobuffer()
- failed to check that trailing bits were zero allowing
- some invalid base64 strings to be accepted. [RT #5397]
-
-1464. [bug] Preserve "out of zone" data for outgoing zone
- transfers. [RT #5192]
-
-1463. [bug] dns_rdata_from{wire,struct}() failed to catch bad
- NXT bit maps. [RT #5577]
-
-1462. [bug] parse_sizeval() failed to check the token type.
- [RT #5586]
-
-1461. [bug] Remove deadlock from rbtdb code. [RT #5599]
-
-1460. [bug] inet_pton() failed to reject certain malformed
- IPv6 literals.
-
-1459. [bug] win32: we were leaking a bits in the exception
- fd_set resulting in "Socket operation on non-socket"
- errors from select(). [RT #2966]
-
-1456. [contrib] gen-data-queryperf.py from Stephane Bortzmeyer.
-
-1453. [doc] ARM: $GENERATE example wasn't accurate. [RT #5298]
-
-1452. [bug] Bad #ifdef, ISC_RFC2335 -> ISC_RFC2535.
-
-1451. [bug] rndc-confgen didn't exit with a error code for all
- failures. [RT #5209]
-
-1450. [bug] Fetching expired glue failed under certain
- circumstances. [RT #5124]
-
-1449. [bug] query_addbestns() didn't handle running out of memory
- gracefully.
-
-1448. [bug] Handle empty wildcards labels.
-
-1447. [bug] We were casting (unsigned int) to and from (void *).
- rdataset->private4 is now rdataset->privateuint4
- to reflect a type change.
-
-1445. [bug] DNS_ADBFIND_STARTATROOT broke stub zones. This has
- been replaced with DNS_ADBFIND_STARTATZONE which
- causes the search to start using the closest zone.
+1399. [bug] Use serial number arithmetic when testing SIG
+ timestamps. [RT #4268]
-1439. [bug] Named could return NOERROR with certain NOTIFY
- failures. Return NOTAUTH if the NOTIFY zone is
- not being served.
+1398. [doc] ARM: notify-also should have been also-notify.
+ [RT #4345]
-1435. [bug] zmgr_resume_xfrs() was being called read locked
- rather than write locked. zmgr_resume_xfrs()
- was not being called if the zone was being
- shutdown.
+1397. [bug] J.ROOT-SERVERS.NET is now 192.58.128.30.
-1437. [bug] Leave space for stdio to work in. [RT #5033]
+1396. [func] dnssec-signzone: adjust the default signing time by
+ 1 hour to allow for clock skew.
-1434. [bug] "rndc reconfig" failed to initiate the initial
- zone transfer of new slave zones.
+1395. [port] OpenSSL 0.9.7 defines CRYPTO_LOCK_ENGINE but doesn't
+ have a working implementation. [RT #4079]
-1431. [bug] isc_print_snprintf() "%s" with precision could walk off
- end of argument. [RT #5191]
+1394. [func] It is now possible to check if a particular element is
+ in a acl. Remove duplicate entries from the localnets
+ acl.
-1429. [bug] Prevent the cache getting locked to old servers.
+1393. [port] Bind to individual IPv6 interfaces if IPV6_IPV6ONLY
+ is not available in the kernel to prevent accidently
+ listening on IPv4 interfaces.
-1424. [bug] EDNS version not being correctly printed.
+1392. [bug] named-checkzone: update usage.
-1423. [contrib] queryperf: added A6 and SRV.
+1391. [func] Add support for IPv6 scoped addresses in named.
-1420. [port] solaris: work around gcc optimizer bug.
+1390. [func] host now supports ixfr.
-1419. [port] openbsd: use /dev/arandom. [RT #4950]
+1389. [bug] named could fail to rotate long log files. [RT #3666]
-1418. [bug] 'rndc reconfig' did not cause new slaves to load.
+1388. [port] irix: check for sys/sysctl.h and NET_RT_IFLIST before
+ defining HAVE_IFLIST_SYSCTL. [RT #3770]
-1416. [bug] Empty node should return NOERROR NODATA, not NXDOMAIN.
- [RT #4715]
+1387. [bug] named could crash due to an access to invalid memory
+ space (which caused an assertion failure) in
+ incremental cleaning. [RT #3588]
-1411. [bug] empty nodes should stop wildcard matches. [RT #4802]
+1386. [bug] named-checkzone -z stopped on errors in a zone.
+ [RT #3653]
-1408. [bug] "make distclean" was not complete. [RT #4700]
+1385. [bug] Setting serial-query-rate to 10 would trigger a
+ REQUIRE failure.
-1407. [bug] lfsr incorrectly implements the shift register.
- [RT #4617]
+1384. [bug] host was incompatible with BIND 8 in its exit code and
+ in the output with the -l option. [RT #3536]
-1406. [bug] dispatch initializes one of the LFSR's with a incorrect
- polynomial. [RT #4617]
+1383. [func] Track the serial number in a IXFR response and log if
+ a mismatch occurs. This is a more specific error than
+ "not exact". [RT #3445]
-1405. [func] Use arc4random() if available.
+1382. [bug] make install failed with --enable-libbind. [RT #3656]
-1401. [bug] adb wasn't clearing state when the timer expired.
+1381. [bug] named failed to correctly process answers that
+ contained DNAME records where the resulting CNAME
+ resulted in a negative answer.
-1399. [bug] Use serial number arithmetic when testing SIG
- timestamps. [RT #4268]
+1380. [func] 'rndc recursing' dump recursing queries to
+ 'recursing-file = "named.recursing";'.
-1397. [bug] J.ROOT-SERVERS.NET is now 192.58.128.30.
+1379. [func] 'rndc status' now reports tcp and recursion quota
+ states.
-1389. [bug] named could fail to rotate long log files. [RT #3666]
+1378. [func] Improved positive feedback for 'rndc {reload|refresh}.
-1388. [port] irix: check for sys/sysctl.h and NET_RT_IFLIST before
- defining HAVE_IFLIST_SYSCTL. [RT #3770]
+1377. [func] dns_zone_load{new}() now reports if the zone was
+ loaded, queued for loading to up to date.
-1387. [bug] named could crash due to an access to invalid memory
- space (which caused an assertion failure) in
- incremental cleaning. [RT #3588]
+1376. [func] New function dns_zone_logc() to log to specified
+ category.
-1385. [bug] Setting serial-query-rate to 10 would trigger a
- REQUIRE failure.
+1375. [func] 'rndc dumpdb' now dumps the adb cache along with the
+ data cache.
-1384. [bug] host was incompatible with BIND 8 in its exit code and
- in the output with the -l option. [RT #3536]
+1374. [func] dns_adb_dump() now logs the lame zones associated
+ with each server.
1373. [bug] Recovery from expired glue failed under certain
circumstances.
@@ -2208,55 +2577,35 @@
sharing the same port for listening and querying, and
changing listening addresses several times. [RT# 3509]
+1371. [bug] notify-source-v6, transfer-source-v6 and
+ query-source-v6 with explicit addresses and using the
+ same ports as named was listening on could interfere
+ with named's ability to answer queries sent to those
+ addresses.
+
1370. [bug] dig '+[no]recurse' was incorrectly documented.
1369. [bug] Adding an NS record as the lexicographically last
record in a secure zone didn't work.
-1366. [contrib] queryperf usage was incomplete. Add '-h' for help.
-
-1348. [port] win32: Rewrote code to use I/O Completion Ports
- in socket.c and eliminating a host of socket
- errors. Performance is enhanced.
-
-1333. [contrib] queryperf now reports a summary of returned
- rcodes (-c), rcodes are printed in mnemonic form (-v).
-
-1299. [bug] Set AI_ADDRCONFIG when looking up addresses
- via getaddrinfo() (affects dig, host, nslookup, rndc
- and nsupdate).
-
-1199. [doc] ARM reference to RFC 2157 should have been RFC 1918.
- [RT #2436]
-
-1122. [tuning] Resolution timeout reduced from 90 to 30 seconds.
- [RT #2046]
-
- 992. [doc] dig: ~/.digrc is now documented.
-
- --- 9.2.2 released ---
-
-1428. [port] hpux: temporary work around of hpux 11.11 interface
- scanning.
+1368. [func] remove support for bitstring labels.
-1427. [bug] Race condition in adb with threaded build.
+1367. [func] Use response times to select forwarders.
-1426. [cleanup] Disable RFC2535 style DNSSEC. This is incompatible
- with the forthcoming DS style DNSSEC.
+1366. [contrib] queryperf usage was incomplete. Add '-h' for help.
-1425. [port] linux/libbind: define __USE_MISC when testing *_r()
- function prototypes in netdb.h. [RT #4921]
+1365. [func] "localhost" and "localnets" acls now include IPv6
+ addresses / prefixes.
-1395. [port] OpenSSL 0.9.7 defines CRYPTO_LOCK_ENGINE but doesn't
- have a working implementation. [RT #4079]
+1364. [func] Log file name when unable to open memory statistics
+ and dump database files. [RT# 3437]
-1382. [bug] make install failed with --enable-libbind. [RT #3656]
+1363. [func] Listen-on-v6 now supports specific addresses.
-1381. [bug] named failed to correctly process answers that
- contained DNAME records where the resulting CNAME
- resulted in a negative answer.
+1362. [bug] remove IFF_RUNNING test when scanning interfaces.
- --- 9.2.2rc1 released ---
+1361. [func] log the reason for rejecting a server when resolving
+ queries.
1360. [bug] --enable-libbind would fail when not built in the
source tree for certain OS's.
@@ -2271,6 +2620,8 @@
1356. [tuning] Reduce the number of events / quantum for zone tasks.
+1355. [bug] Fix DNSSEC wildcard proof for CNAME/DNAME.
+
1354. [doc] lwres man pages had illegal nroff.
1353. [contrib] sdb/ldap to version 0.9.
@@ -2288,26 +2639,68 @@
1349. [security] Minimum OpenSSL version now 0.9.6e (was 0.9.5a).
http://www.cert.org/advisories/CA-2002-23.html
-1346. [bug] Win32: select timeout in socket.c was too small
- as value given was meant to be milliseconds and
- timeval structure requires microseconds. This
- caused high CPU loads with a compute bound loop.
- [RT #3358]
+1348. [port] win32: Rewrote code to use I/O Completion Ports
+ in socket.c and eliminating a host of socket
+ errors. Performance is enhanced.
+
+1347. [placeholder]
+
+1346. [placeholder]
1345. [port] Use a explicit -Wformat with gcc. Not all versions
include it in -Wall.
+1344. [func] Log if the serial number on the master has gone
+ backwards.
+ If you have multiple machines specified in the masters
+ clause you may want to set 'multi-master yes;' to
+ suppress this warning.
+
+1343. [func] Log successful notifies received (info). Adjust log
+ level for failed notifies to notice.
+
+1342. [func] Log remote address with TCP dispatch failures.
+
+1341. [func] Allow a rate limiter to be stalled.
+
1340. [bug] Delay and spread out the startup refresh load.
+1339. [func] dig, host and nslookup now use IP6.ARPA for nibble
+ lookups. Bit string lookups are no longer attempted.
+
+1338. [placeholder]
+
+1337. [placeholder]
+
+1336. [func] Nibble lookups under IP6.ARPA are now supported by
+ dns_byaddr_create(). dns_byaddr_createptrname() is
+ deprecated, use dns_byaddr_createptrname2() instead.
+
1335. [bug] When performing a nonexistence proof, the validator
should discard parent NXTs from higher in the DNS.
1334. [bug] When signing/verifying rdatasets, duplicate rdatas
need to be suppressed.
+1333. [contrib] queryperf now reports a summary of returned
+ rcodes (-c), rcodes are printed in mnemonic form (-v).
+
+1332. [func] Report the current serial with periodic commits when
+ rolling forward the journal.
+
+1331. [func] Generate DNSSEC wildcard proofs.
+
1330. [bug] When processing events (non-threaded) only allow
the task one chance to use to use its quantum.
+1329. [func] named-checkzone will now check if nameservers that
+ appear to be IP addresses. Available modes "fail",
+ "warn" (default) and "ignore" the results of the
+ check.
+
+1328. [bug] The validator could incorrectly verify an invalid
+ negative proof.
+
1327. [bug] The validator would incorrectly mark data as insecure
when seeing a bogus signature before a correct
signature.
@@ -2322,6 +2715,11 @@
1323. [port] linux: Slackware 4.0 needs <asm/unistd.h>. [RT #3205]
+1322. [bug] dnssec-signzone usage message was misleading.
+
+1321. [bug] If the last RRset in a zone is glue, dnssec-signzone
+ would incorrectly duplicate its output and sign it.
+
1320. [doc] query-source-v6 was missing from options section.
[RT #3218]
@@ -2339,11 +2737,20 @@
1314. [port] Handle ECONNRESET from sendmsg() [unix].
+1313. [func] Query log now says if the query was signed (S) or
+ if EDNS was used (E).
+
+1312. [func] Log TSIG key used w/ outgoing zone transfers.
+
1311. [bug] lwres_getrrsetbyname leaked memory. [RT #3159]
1310. [bug] 'rndc stop' failed to cause zones to be flushed
sometimes. [RT #3157]
+1309. [func] Log that a zone transfer was covered by a TSIG.
+
+1308. [func] DS (delegation signer) support.
+
1307. [bug] nsupdate: allow white space base64 key data.
1306. [bug] Badly encoded LOC record when the size, horizontal
@@ -2352,6 +2759,21 @@
1305. [bug] Document that internal zones are included in the
rndc status results.
+1304. [func] New function: dns_zone_name().
+
+1303. [func] Option 'flush-zones-on-shutdown <boolean>;'.
+
+1302. [func] Extended rndc dumpdb to support dumping of zones and
+ view selection: 'dumpdb [-all|-zones|-cache] [view]'.
+
+1301. [func] New category 'update-security'.
+
+1300. [port] Compaq Trucluster support.
+
+1299. [bug] Set AI_ADDRCONFIG when looking up addresses
+ via getaddrinfo() (affects dig, host, nslookup, rndc
+ and nsupdate).
+
1298. [bug] The CINCLUDES macro in lib/dns/sec/dst/Makefile
could be left with a trailing "\" after configure
has been run.
@@ -2369,6 +2791,18 @@
IPv6 reverse resolution. Try IP6.ARPA then IP6.INT
for nibble style resolution.
+1293. [func] Entropy can now be retrieved from EGDs. [RT #2438]
+
+1292. [func] Enable IPv6 support when using ioctl style interface
+ scanning and OS supports SIOCGLIFADDR using struct
+ if_laddrreq.
+
+1291. [func] Enable IPv6 support when using sysctl style interface
+ scanning.
+
+1290. [func] "dig axfr" now reports the number of messages
+ as well as the number of records.
+
1289. [port] See if -ldl is required for OpenSSL? [RT #2672]
1288. [bug] Adjusted REQUIRE's in lib/dns/name.c to better
@@ -2381,16 +2815,31 @@
1286. [bug] dns_name_downcase() enforce requirement that
target != NULL or name->buffer != NULL.
+1285. [func] lwres: probe the system to see what address families
+ are currently in use.
+
1284. [bug] The RTT estimate on unused servers was not aged.
[RT #2569]
+1283. [func] Use "dataready" accept filter if available.
+
1282. [port] libbind: hpux 11.11 interface scanning.
+1281. [func] Log zone when unable to get private keys to update
+ zone. Log zone when NXT records are missing from
+ secure zone.
+
1280. [bug] libbind: escape '(' and ')' when converting to
presentation form.
1279. [port] Darwin uses (unsigned long) for size_t. [RT #2590]
+1278. [func] dig: now supports +[no]cl +[no]ttlid.
+
+1277. [func] You can now create your own customized printing
+ styles: dns_master_stylecreate() and
+ dns_master_styledestroy().
+
1276. [bug] libbind: const pointer conflicts in res_debug.c.
1275. [port] libbind: hpux: treat all hpux systems as BIG_ENDIAN.
@@ -2402,6 +2851,9 @@
1272. [contrib] Berkeley DB 4.0 sdb implementation from
Nuno Miguel Rodrigues <nmr at co.sapo.pt>.
+1271. [bug] "recursion available: {denied,approved}" was too
+ confusing.
+
1270. [bug] Check that system inet_pton() and inet_ntop() support
AF_INET6.
@@ -2410,6 +2862,9 @@
1268. [port] Openserver: the value FD_SETSIZE depends on whether
<sys/param.h> is included or not. Be consistent.
+1267. [func] isc_file_openunique() now creates file using mode
+ 0666 rather than 0600.
+
1266. [bug] ISC_LINK_INIT, ISC_LINK_UNLINK, ISC_LIST_DEQUEUE,
__ISC_LINK_UNLINKUNSAFE and __ISC_LIST_DEQUEUEUNSAFE
are not C++ compatible, use *_TYPE versions instead.
@@ -2417,6 +2872,8 @@
1265. [bug] libbind: LINK_INIT and UNLINK were not compatible with
C++, use LINK_INIT_TYPE and UNLINK_TYPE instead.
+1264. [placeholder]
+
1263. [bug] Reference after free error if dns_dispatchmgr_create()
failed.
@@ -2446,6 +2903,8 @@
next name, and for NOERROR NODATA responses, check
that the type is not present in the NXT bitmap.
+1254. [func] preferred-glue option from BIND 8.3.
+
1253. [bug] The dnssec system test failed to remove the correct
files.
@@ -2453,48 +2912,38 @@
the answer was coming from against the address it was
sent to. [RT# 2692]
-1248. [bug] DESTDIR was not being propagated between makes.
-
-1245. [bug] Treat ENOBUFS, ENOMEM and ENFILE as soft errors for
- accept().
-
-1242. [bug] named-checkzone failed if a journal existed. [RT #2657]
-
-1241. [bug] Drop received UDP messages with a zero source port
- as these are invariably forged. [RT #2621]
-
-1209. [bug] Dig, host, nslookup were not checking the message ids
- on the responses. [RT #2454]
-
-1097. [func] libbind: RES_PRF_TRUNC for dig.
-
-1096. [func] libbind: "DNSSEC OK" (DO) support.
+1251. [port] win32: a make file contained absolute version specific
+ references.
-1095. [func] libbind: resolver option: no-tld-query. disables
- trying unqualified as a tld. no_tld_query is also
- supported for FreeBSD compatibility.
+1250. [func] Nsupdate will report the address the update was
+ sent to.
-1094. [func] libbind: add support gcc's format string checking.
+1249. [bug] Missing masters clause was not handled gracefully.
+ [RT #2703]
-1089. [func] libbind: inet_{cidr,net}_{pton,ntop}() now have IPv6
- support.
+1248. [bug] DESTDIR was not being propagated between makes.
- --- 9.2.1 released ---
+1247. [bug] Don't reset the interface index for link/site local
+ addresses. [RT #2576]
-1251. [port] win32: a make file contained absolute version specific
- references.
+1246. [func] New functions isc_sockaddr_issitelocal(),
+ isc_sockaddr_islinklocal(), isc_netaddr_issitelocal()
+ and isc_netaddr_islinklocal().
-1249. [bug] Missing masters clause was not handled gracefully.
- [RT #2703]
+1245. [bug] Treat ENOBUFS, ENOMEM and ENFILE as soft errors for
+ accept().
1244. [bug] Receiving a TCP message from a blackhole address would
prevent further messages being received over that
interface.
-1178. [bug] Follow and cache (if appropriate) A6 and other
- data chains to completion in the additional section.
+1243. [bug] It was possible to trigger a REQUIRE() in
+ dns_message_findtype(). [RT #2659]
- --- 9.2.1rc2 released ---
+1242. [bug] named-checkzone failed if a journal existed. [RT #2657]
+
+1241. [bug] Drop received UDP messages with a zero source port
+ as these are invariably forged. [RT #2621]
1240. [bug] It was possible to leak zone references by
specifying an incorrect zone to rndc.
@@ -2511,6 +2960,15 @@
1236. [bug] dns_rdata{class,type}_fromtext() didn't handle non
NULL terminated text regions. [RT #2588]
+1235. [func] Report 'out of memory' errors from openssl.
+
+1234. [bug] contrib/sdb: 'zonetodb' failed to call
+ dns_result_register(). DNS_R_SEENINCLUDE should not
+ be fatal.
+
+1233. [bug] The flags field of a KEY record can be expressed in
+ hex as well as decimal.
+
1232. [bug] unix/errno2result() didn't handle EADDRNOTAVAIL.
1231. [port] HPUX 11.11 recvmsg() can return spurious EADDRNOTAVAIL.
@@ -2526,15 +2984,34 @@
if a number was expected and some other token was
found. [RT#2532]
+1226. [func] Use EDNS for zone refresh queries. [RT #2551]
+
+1225. [func] dns_message_setopt() no longer requires that
+ dns_message_renderbegin() to have been called.
+
+1224. [bug] 'rrset-order' and 'sortlist' should be additive
+ not exclusive.
+
+1223. [func] 'rrset-order' partially works 'cyclic' and 'random'
+ are supported.
+
1222. [bug] Specifying 'port *' did not always result in a system
selected (non-reserved) port being used. [RT #2537]
1221. [bug] Zone types 'master', 'slave' and 'stub' were not being
compared case insensitively. [RT #2542]
+1220. [func] Support for APL rdata type.
+
+1219. [func] Named now reports the TSIG extended error code when
+ signature verification fails. [RT #1651]
+
1218. [bug] Named incorrectly returned SERVFAIL rather than
NOTAUTH when there was a TSIG BADTIME error. [RT #2519]
+1217. [func] Report locations of previous key definition when a
+ duplicate is detected.
+
1216. [bug] Multiple server clauses for the same server were not
reported. [RT #2514]
@@ -2543,6 +3020,9 @@
1214. [bug] Win32: isc_file_renameunique() could leave zero length
files behind.
+1213. [func] Report view associated with client if it is not a
+ standard view (_default or _bind).
+
1212. [port] libbind: 64k answer buffers were causing stack space
to be exceeded for certain OS. Use heap space instead.
@@ -2552,12 +3032,13 @@
1210. [bug] libbind: getnameinfo() failed to lookup IPv4 mapped /
compatible addresses. [RT #2461]
+1209. [bug] Dig, host, nslookup were not checking the message ids
+ on the responses. [RT #2454]
+
1208. [bug] dns_master_load*() failed to log a error message if
an error was detected when parsing the ownername of
a record. [RT #2448]
- --- 9.2.1rc1 released ---
-
1207. [bug] libbind: getaddrinfo() could call freeaddrinfo() with
an invalid pointer.
@@ -2570,6 +3051,11 @@
1204. [bug] libbind: res_nupdate() failed to update the name
server addresses before sending the update.
+1203. [func] Report locations of previous acl and zone definitions
+ when a duplicate is detected.
+
+1202. [func] New functions: cfg_obj_line() and cfg_obj_file().
+
1201. [bug] Require that if 'callbacks' is passed to
dns_rdata_fromtext(), callbacks->error and
callbacks->warn are initialized.
@@ -2577,6 +3063,9 @@
1200. [bug] Log 'errno' that we are unable to convert to
isc_result_t. [RT #2404]
+1199. [doc] ARM reference to RFC 2157 should have been RFC 1918.
+ [RT #2436]
+
1198. [bug] OPT printing style was not consistent with the way the
header fields are printed. The DO bit was not reported
if set. Report if any of the MBZ bits are set.
@@ -2592,11 +3081,20 @@
1194. [bug] Not all duplicate zone definitions were being detected
at the named.conf checking stage. [RT #2431]
-1193. [bug] Best effort parsing didn't handle packet truncation.
+1193. [bug] dig +besteffort parsing didn't handle packet
+ truncation. dns_message_parse() has new flag
+ DNS_MESSAGE_IGNORETRUNCATION.
+
+1192. [bug] The seconds fields in LOC records were restricted
+ to three decimal places. More decimal places should
+ be allowed but warned about.
1191. [bug] A dynamic update removing the last non-apex name in
a secure zone would fail. [RT #2399]
+1190. [func] Add the "rndc freeze" and "rndc unfreeze" commands.
+ [RT #2394]
+
1189. [bug] On some systems, malloc(0) returns NULL, which
could cause the caller to report an out of memory
error. [RT #2398]
@@ -2604,6 +3102,9 @@
1188. [bug] Dynamic updates of a signed zone would fail if
some of the zone private keys were unavailable.
+1187. [bug] named was incorrectly returning DNSSEC records
+ in negative responses when the DO bit was not set.
+
1186. [bug] isc_hex_tobuffer(,,length = 0) failed to unget the
EOL token when reading to end of line.
@@ -2619,14 +3120,30 @@
1182. [bug] The server could throw an assertion failure when
constructing a negative response packet.
+1181. [func] Add the "key-directory" configuration statement,
+ which allows the server to look for online signing
+ keys in alternate directories.
+
+1180. [func] dnssec-keygen should always generate keys with
+ protocol 3 (DNSSEC), since it's less confusing
+ that way.
+
+1179. [func] Add SIG(0) support to nsupdate.
+
+1178. [bug] Follow and cache (if appropriate) A6 and other
+ data chains to completion in the additional section.
+
+1177. [func] Report view when loading zones if it is not a
+ standard view (_default or _bind). [RT #2270]
+
1176. [doc] Document that allow-v6-synthesis is only performed
for clients that are supplied recursive service.
[RT #2260]
-1175. [bug] named-checkzone failed to call dns_result_register()
- at startup which could result in runtime
- exceptions when printing "out of memory" errors.
- [RT #2335]
+1175. [bug] named-checkzone and named-checkconf failed to call
+ dns_result_register() at startup which could
+ result in runtime exceptions when printing
+ "out of memory" errors. [RT #2335]
1174. [bug] Win32: add WSAECONNRESET to the expected errors
from connect(). [RT #2308]
@@ -2637,9 +3154,14 @@
1172. [doc] Add CERT, GPOS, KX, NAPTR, NSAP, PX and TXT to
table of RR types in ARM.
+1171. [func] Added function isc_region_compare(), updated files in
+ lib/dns to use this function instead of local one.
+
1170. [bug] Don't attempt to print the token when a I/O error
occurs when parsing named.conf. [RT #2275]
+1169. [func] Identify recursive queries in the query log.
+
1168. [bug] Empty also-notify clauses were not handled. [RT #2309]
1167. [contrib] nslint-2.1a3 (from author).
@@ -2652,6 +3174,8 @@
1164. [bug] Empty masters clauses in slave / stub zones were not
handled gracefully. [RT #2262]
+1163. [func] isc_time_formattimestamp() now includes the year.
+
1162. [bug] The allow-notify option was not accepted in slave
zone statements.
@@ -2661,18 +3185,62 @@
1160. [bug] Generating Diffie-Hellman keys longer than 1024
bits could fail. [RT #2241]
+1159. [bug] MD and MF are not permitted to be loaded by RFC1123.
+
+1158. [func] Report the client's address when logging notify
+ messages.
+
+1157. [func] match-clients and match-destinations now accept
+ keys. [RT #2045]
+
1156. [port] The configure test for strsep() incorrectly
succeeded on certain patched versions of
AIX 4.3.3. [RT #2190]
+1155. [func] Recover from master files being removed from under
+ us.
+
1154. [bug] Don't attempt to obtain the netmask of a interface
if there is no address configured. [RT #2176]
+1153. [func] 'rndc {stop|halt} -p' now reports the process id
+ of the instance of named being shutdown.
+
1152. [bug] libbind: read buffer overflows.
+1151. [bug] nslookup failed to check that the arguments to
+ the port, timeout, and retry options were
+ valid integers and in range. [RT #2099]
+
+1150. [bug] named incorrectly accepted TTL values
+ containing plus or minus signs, such as
+ 1d+1h-1s.
+
+1149. [func] New function isc_parse_uint32().
+
+1148. [func] 'rndc-confgen -a' now provides positive feedback.
+
+1147. [func] Set IPV6_V6ONLY on IPv6 sockets if supported by
+ the OS. listen-on-v6 { any; }; should no longer
+ result in IPv4 queries be accepted. Similarly
+ control { inet :: ... }; should no longer result
+ in IPv4 connections being accepted. This can be
+ overridden at compile time by defining
+ ISC_ALLOW_MAPPED=1.
+
+1146. [func] Allow IPV6_IPV6ONLY to be set/cleared on a socket if
+ supported by the OS by a new function
+ isc_socket_ipv6only().
+
+1145. [func] "host" no longer reports a NOERROR/NODATA response
+ by printing nothing. [RT #2065]
+
1144. [bug] rndc-confgen would crash if both the -a and -t
options were specified. [RT #2159]
+1143. [bug] When a trusted-keys statement was present and named
+ was built without crypto support, it would leak memory.
+
1142. [bug] dnssec-signzone would fail to delete temporary files
in some failure cases. [RT #2144]
@@ -2682,52 +3250,24 @@
[RT #2139, #2164]
1140. [bug] rndc-confgen did not accept IPv6 addresses as arguments
- to the -s option. [RT #2138]
-
-1136. [bug] CNAME records synthesized from DNAMEs did not
- have a TTL of zero as required by RFC2672.
- [RT #2129]
-
-1125. [bug] rndc: -k option was missing from usage message.
- [RT #2057]
-
-1124. [doc] dig: +[no]dnssec, +[no]besteffort and +[no]fail
- are now documented. [RT #2052]
-
-1123. [bug] dig +[no]fail did not match description. [RT #2052]
-
-1109. [bug] nsupdate accepted illegal ttl values.
-
-1108. [bug] On Win32, rndc was hanging when named was not running
- due to failure to select for exceptional conditions
- in select(). [RT #1870]
-
-1081. [bug] Multicast queries were incorrectly identified
- based on the source address, not the destination
- address.
-
-1072. [bug] The TCP client quota could be exceeded when
- recursion occurred. [RT #1937]
-
-1071. [bug] Sockets listening for TCP DNS connections
- specified an excessive listen backlog. [RT #1937]
-
-1070. [bug] Copy DNSSEC OK (DO) to response as specified by
- draft-ietf-dnsext-dnssec-okbit-03.txt.
+ to the -s option. [RT #2138]
-1014. [bug] Some queries would cause statistics counters to
- increment more than once or not at all. [RT #1321]
+1139. [func] It is now possible to flush a given name from the
+ cache(s) via 'rndc flushname name [view]'. [RT #2051]
-1012. [bug] The -p option to named did not behave as documented.
+1138. [func] It is now possible to flush a given name from the
+ cache by calling the new function
+ dns_cache_flushname().
- 988. [bug] 'additional-from-auth no;' did not work reliably
- in the case of queries answered from the cache.
- [RT #1436]
+1137. [func] It is now possible to flush a given name from the
+ ADB by calling the new function dns_adb_flushname().
- 995. [bug] dig, host, nslookup: using a raw IPv6 address as a
- target address should be fatal on a IPv4 only system.
+1136. [bug] CNAME records synthesized from DNAMEs did not
+ have a TTL of zero as required by RFC2672.
+ [RT #2129]
- --- 9.2.0 released ---
+1135. [func] You can now override the default syslog() facility for
+ named/lwresd at compile time. [RT #1982]
1134. [bug] Multi-threaded servers could deadlock in ferror()
when reloading zone files. [RT #1951, #1998]
@@ -2735,7 +3275,7 @@
1133. [bug] IN6_IS_ADDR_LOOPBACK was not portably defined on
platforms without IN6_IS_ADDR_LOOPBACK. [RT #2106]
- --- 9.2.0rc10 released ---
+1132. [func] Improve UPDATE prerequisite failure diagnostic messages.
1131. [bug] The match-destinations view option did not work with
IPv6 destinations. [RT #2073, #2074]
@@ -2747,16 +3287,37 @@
1129. [bug] Multi-threaded servers could crash under heavy
resolution load due to a race condition. [RT #2018]
+1128. [func] sdb drivers can now provide RR data in either text
+ or wire format, the latter using the new functions
+ dns_sdb_putrdata() and dns_sdb_putnamedrdata().
+
+1127. [func] rndc: If the server to contact has multiple addresses,
+ try all of them.
+
1126. [bug] The server could access a freed event if shut
down while a client start event was pending
delivery. [RT #2061]
+1125. [bug] rndc: -k option was missing from usage message.
+ [RT #2057]
+
+1124. [doc] dig: +[no]dnssec, +[no]besteffort and +[no]fail
+ are now documented. [RT #2052]
+
+1123. [bug] dig +[no]fail did not match description. [RT #2052]
+
+1122. [tuning] Resolution timeout reduced from 90 to 30 seconds.
+ [RT #2046]
+
1121. [bug] The server could attempt to access a NULL zone
table if shut down while resolving.
[RT #1587, #2054]
1120. [bug] Errors in options were not fatal. [RT #2002]
+1119. [func] Added support in Win32 for NTFS file/directory ACL's
+ for access control.
+
1118. [bug] On multi-threaded servers, a race condition
could cause an assertion failure in resolver.c
during resolver shutdown. [RT #2029]
@@ -2770,16 +3331,32 @@
or transfers-per-ns to a value greater than
2147483647 disabled transfers. [RT #2002]
+1115. [func] Set maximum values for cleaning-interval,
+ heartbeat-interval, interface-interval,
+ max-transfer-idle-in, max-transfer-idle-out,
+ max-transfer-time-in, max-transfer-time-out,
+ statistics-interval of 28 days and
+ sig-validity-interval of 3660 days. [RT #2002]
+
1114. [port] Ignore more accept() errors. [RT #2021]
1113. [bug] The allow-update-forwarding option was ignored
when specified in a view. [RT #2014]
+1112. [placeholder]
+
1111. [bug] Multi-threaded servers could deadlock processing
recursive queries due to a locking hierarchy
violation in adb.c. [RT #2017]
- --- 9.2.0rc9 released ---
+1110. [bug] dig should only accept valid abbreviations of +options.
+ [RT #2003]
+
+1109. [bug] nsupdate accepted illegal ttl values.
+
+1108. [bug] On Win32, rndc was hanging when named was not running
+ due to failure to select for exceptional conditions
+ in select(). [RT #1870]
1107. [bug] nsupdate could catch an assertion failure if an
invalid domain name was given as the argument to
@@ -2788,6 +3365,8 @@
1106. [bug] After seeing an out of range TTL, nsupdate would
treat all TTLs as out of range. [RT #2001]
+1105. [port] OpenUNIX 8 enable threads by default. [RT #1970]
+
1104. [bug] Invalid arguments to the transfer-format option
could cause an assertion failure. [RT #1995]
@@ -2805,6 +3384,16 @@
1098. [bug] libbind: HMAC-MD5 key files are now mode 0600.
+1097. [func] libbind: RES_PRF_TRUNC for dig.
+
+1096. [func] libbind: "DNSSEC OK" (DO) support.
+
+1095. [func] libbind: resolver option: no-tld-query. disables
+ trying unqualified as a tld. no_tld_query is also
+ supported for FreeBSD compatibility.
+
+1094. [func] libbind: add support gcc's format string checking.
+
1093. [doc] libbind: miscellaneous nroff fixes.
1092. [bug] libbind: get*by*() failed to check if res_init() had
@@ -2818,6 +3407,9 @@
wasting space. We weren't suppressing duplicate
addresses.
+1089. [func] libbind: inet_{cidr,net}_{pton,ntop}() now have IPv6
+ support.
+
1088. [port] libbind: MPE/iX C.70 (incomplete)
1087. [bug] libbind: struct __res_state too large on 64 bit arch.
@@ -2837,9 +3429,27 @@
to be sent to syslog in addition to stderr.
[RT #1974]
+1081. [bug] Multicast queries were incorrectly identified
+ based on the source address, not the destination
+ address.
+
+1080. [bug] BIND 8 compatibility: accept bare IP prefixes
+ as the second element of a two-element top level
+ sort list statement. [RT #1964]
+
+1079. [bug] BIND 8 compatibility: accept bare elements at top
+ level of sort list treating them as if they were
+ a single element list. [RT #1963]
+
1078. [bug] We failed to correct bad tv_usec values in one case.
[RT #1966]
+1077. [func] Do not accept further recursive clients when
+ the total number of recursive lookups being
+ processed exceeds max-recursive-clients, even
+ if some of the lookups are internally generated.
+ [RT #1915, #1938]
+
1076. [bug] A badly defined global key could trigger an assertion
on load/reload if views were used. [RT #1947]
@@ -2849,13 +3459,30 @@
1074. [bug] Running out of memory in dump_rdataset() could
cause an assertion failure. [RT #1946]
- --- 9.2.0rc8 released ---
+1073. [bug] The ADB cache cleaning should also be space driven.
+ [RT #1915, #1938]
+
+1072. [bug] The TCP client quota could be exceeded when
+ recursion occurred. [RT #1937]
+
+1071. [bug] Sockets listening for TCP DNS connections
+ specified an excessive listen backlog. [RT #1937]
+
+1070. [bug] Copy DNSSEC OK (DO) to response as specified by
+ draft-ietf-dnsext-dnssec-okbit-03.txt.
+
+1069. [placeholder]
1068. [bug] errno could be overwritten by catgets(). [RT #1921]
+1067. [func] Allow quotas to be soft, isc_quota_soft().
+
1066. [bug] Provide a thread safe wrapper for strerror().
[RT #1689]
+1065. [func] Runtime support to select new / old style interface
+ scanning using ioctls.
+
1064. [bug] Do not shut down active network interfaces if we
are unable to scan the interface list. [RT #1921]
@@ -2871,6 +3498,15 @@
maximum cache size was in progress, the server
could catch an assertion failure. [RT #1912]
+1060. [func] Move refresh, stub and notify UDP retry processing
+ into dns_request.
+
+1059. [func] dns_request now support will now retry UDP queries,
+ dns_request_createvia2() and dns_request_createraw2().
+
+1058. [func] Limited lifetime ticker timers are now available,
+ isc_timertype_limited.
+
1057. [bug] Reloading the server after adding a "file" clause
to a zone statement could cause the server to
crash due to a typo in change 1016.
@@ -2878,7 +3514,9 @@
1056. [bug] Rndc could catch an assertion failure on SIGINT due
to an uninitialized variable. [RT #1908]
- --- 9.2.0rc7 released ---
+1055. [func] Version and hostname queries can now be disabled
+ using "version none;" and "hostname none;",
+ respectively.
1054. [bug] On Win32, cfg_categories and cfg_modules need to be
exported from the libisccfg DLL.
@@ -2900,6 +3538,9 @@
failed to include the correct error code, file
name, and line number. [RT #1890]
+1049. [func] "pid-file none;" will disable writing a pid file.
+ [RT #1848]
+
1048. [bug] Servers built with -DISC_MEM_USE_INTERNAL_MALLOC=1
didn't work.
@@ -2937,11 +3578,28 @@
TKEY queries with an owner name other than the root
could cause an assertion failure. [RT #1866, #1869]
+1037. [bug] Negative responses whose authority section contain
+ SOA or NS records whose owner names are not equal
+ equal to or parents of the query name should be
+ rejected. [RT #1862]
+
+1036. [func] Silently drop requests received via multicast as
+ long as there is no final multicast DNS standard.
+
+1035. [bug] If we respond to multicast queries (which we
+ currently do not), respond from a unicast address
+ as specified in RFC 1123. [RT #137]
+
+1034. [bug] Ignore the RD bit on multicast queries as specified
+ in RFC 1123. [RT #137]
+
1033. [bug] Always respond to requests with an unsupported opcode
with NOTIMP, even if we don't have a matching view
or cannot determine the class.
- --- 9.2.0rc6 released ---
+1032. [func] hostname.bind/txt/chaos now returns the name of
+ the machine hosting the nameserver. This is useful
+ in diagnosing problems with anycast servers.
1031. [bug] libbind.a: isc__gettimeofday() infinite recursion.
[RT #1858]
@@ -2960,13 +3618,20 @@
1027. [bug] RRs having the reserved type 0 should be rejected.
[RT #1471]
-1026. [port] Recognize OpenUNIX 8 in config.guess. [RT #1830]
+1026. [placeholder]
+
+1025. [bug] Don't use multicast addresses to resolve iterative
+ queries. [RT #101]
+
+1024. [port] Compilation failed on HP-UX 11.11 due to
+ incompatible use of the SIOCGLIFCONF macro
+ name. [RT #1831]
+
+1023. [func] Accept hints without TTLs.
1022. [bug] Don't report empty root hints as "extra data".
[RT #1802]
- --- 9.2.0rc5 released ---
-
1021. [bug] On Win32, log message timestamps were one month
later than they should have been, and the server
would exhibit unspecified behavior in December.
@@ -2991,16 +3656,27 @@
"size" option failed to create numbered log
files. [RT #1783]
- --- 9.2.0rc4 released ---
+1014. [bug] Some queries would cause statistics counters to
+ increment more than once or not at all. [RT #1321]
1013. [bug] It was possible to cancel a query twice when marking
a server as bogus or by having a blackhole acl.
[RT #1776]
+1012. [bug] The -p option to named did not behave as documented.
+
+1011. [cleanup] Removed isc_dir_current().
+
1010. [bug] The server could attempt to execute a command channel
command after initiating server shutdown, causing
an assertion failure. [RT #1766]
+1009. [port] OpenUNIX 8 support. [RT #1728]
+
+1008. [port] libtool.m4, ltmain.sh from libtool-1.4.2.
+
+1007. [port] config.guess, config.sub from autoconf-2.52.
+
1006. [bug] If a KEY RR was found missing during DNSSEC validation,
an assertion failure could subsequently be triggered
in the resolver. [RT #1763]
@@ -3010,6 +3686,8 @@
1004. [port] Deal with recvfrom() returning EHOSTDOWN. [RT #1770]
+1003. [func] Add the +retry option to dig.
+
1002. [bug] When reporting an unknown class name in named.conf,
including the file name and line number. [RT #1759]
@@ -3020,31 +3698,83 @@
1000. [bug] BIND 8 compatibility: accept "HESIOD" as an alias
for class "HS". [RT #1759]
- --- 9.2.0rc3 released ---
+ 999. [func] "rndc retransfer zone [class [view]]" added.
+ [RT #1752]
+
+ 998. [func] named-checkzone now has arguments to specify the
+ chroot directory (-t) and working directory (-w).
+ [RT #1755]
+
+ 997. [func] Add support for RSA-SHA1 keys (RFC3110).
+
+ 996. [func] Issue warning if the configuration filename contains
+ the chroot path.
+
+ 995. [bug] dig, host, nslookup: using a raw IPv6 address as a
+ target address should be fatal on a IPv4 only system.
+
+ 994. [func] Treat non-authoritative responses to queries for type
+ NS as referrals even if the NS records are in the
+ answer section, because BIND 8 servers incorrectly
+ send them that way. This is necessary for DNSSEC
+ validation of the NS records of a secure zone to
+ succeed when the parent is a BIND 8 server. [RT #1706]
+
+ 993. [func] dig: -v now reports the version.
+
+ 992. [doc] dig: ~/.digrc is now documented.
+
+ 991. [func] Lower UDP refresh timeout messages to level
+ debug 1.
990. [bug] The rndc-confgen man page was not installed.
989. [bug] Report filename if $INCLUDE fails for file related
errors. [RT #1736]
+ 988. [bug] 'additional-from-auth no;' did not work reliably
+ in the case of queries answered from the cache.
+ [RT #1436]
+
987. [bug] "dig -help" didn't show "+[no]stats".
986. [bug] "dig +noall" failed to clear stats and command
printing.
+ 985. [func] Consider network interfaces to be up iff they have
+ a nonzero IP address rather than based on the
+ IFF_UP flag. [RT #1160]
+
984. [bug] Multi-threading should be enabled by default on
Solaris 2.7 and newer, but it wasn't.
- --- 9.2.0rc2 released ---
+ 983. [func] The server now supports generating IXFR difference
+ sequences for non-dynamic zones by comparing zone
+ versions, when enabled using the new config
+ option "ixfr-from-differences". [RT #1727]
+
+ 982. [func] If "memstatistics-file" is set in options the memory
+ statistics will be written to it.
+
+ 981. [func] The dnssec tools can now take multiple '-r randomfile'
+ arguments.
980. [bug] Incoming zone transfers restarting after an error
could trigger an assertion failure. [RT #1692]
+ 979. [func] Incremental master file dumping. dns_master_dumpinc(),
+ dns_master_dumptostreaminc(), dns_dumpctx_attach(),
+ dns_dumpctx_detach(), dns_dumpctx_cancel(),
+ dns_dumpctx_db() and dns_dumpctx_version().
+
978. [bug] dns_db_attachversion() had an invalid REQUIRE()
condition.
977. [bug] Improve "not at top of zone" error message.
+ 976. [func] named-checkconf can now test load master zones
+ (named-checkconf -z). [RT #1468]
+
975. [bug] "max-cache-size default;" as a view option
caused an assertion failure.
@@ -3058,6 +3788,17 @@
972. [bug] The file modification time code in zone.c was using the
wrong epoch. [RT #1667]
+ 971. [placeholder]
+
+ 970. [func] 'max-journal-size' can now be used to set a target
+ size for a journal.
+
+ 969. [func] dig now supports the undocumented dig 8 feature
+ of allowing arbitrary labels, not just dotted
+ decimal quads, with the -x option. This can be
+ used to conveniently look up RFC2317 names as in
+ "dig -x 10.0.0.0-127". [RT #827, #1576, #1598]
+
968. [bug] On win32, the isc_time_now() function was unnecessarily
calling strtime(). [RT #1671]
@@ -3267,6 +4008,8 @@
910. [port] Some pre-RFC2133 IPv6 implementations do not define
IN6ADDR_ANY_INIT. [RT #1416]
+ 909. [placeholder]
+
908. [func] New program, rndc-confgen, to simplify setting up rndc.
907. [func] The ability to get entropy from either the
@@ -3349,6 +4092,46 @@
887. [port] Detect broken compilers that can't call static
functions from inline functions. [RT #1212]
+ 886. [placeholder]
+
+ 885. [placeholder]
+
+ 884. [placeholder]
+
+ 883. [placeholder]
+
+ 882. [placeholder]
+
+ 881. [placeholder]
+
+ 880. [placeholder]
+
+ 879. [placeholder]
+
+ 878. [placeholder]
+
+ 877. [placeholder]
+
+ 876. [placeholder]
+
+ 875. [placeholder]
+
+ 874. [placeholder]
+
+ 873. [placeholder]
+
+ 872. [placeholder]
+
+ 871. [placeholder]
+
+ 870. [placeholder]
+
+ 869. [placeholder]
+
+ 868. [placeholder]
+
+ 867. [placeholder]
+
866. [func] Close debug only file channels when debug is set to
zero. [RT #1246]
@@ -4156,6 +4939,8 @@
to be non-null. Also 'done' will not be called if
dns_master_load*inc() fails immediately. [RT #565]
+ 619. [placeholder]
+
618. [bug] Queries to a signed zone could sometimes cause
an assertion failure.
@@ -4388,6 +5173,8 @@
548. [func] The lexer now ungets tokens more correctly.
+ 547. [placeholder]
+
546. [func] Option 'lame-ttl' is now implemented.
545. [func] Name limit and counting options removed from dig;
@@ -4413,6 +5200,8 @@
538. [bug] fix buffer overruns by 1 in lwres_getnameinfo().
+ 537. [placeholder]
+
536. [func] Use transfer-source{-v6} when sending refresh queries.
Transfer-source{-v6} now take a optional port
parameter for setting the UDP source port. The port
@@ -4986,6 +5775,8 @@
364. [func] Added additional-from-{cache,auth}
+ 363. [placeholder]
+
362. [bug] rndc no longer aborts if the configuration file is
missing an options statement. [RT #209]
@@ -5037,8 +5828,7 @@
347. [bug] Don't crash if an argument is left off options in dig.
- 346. [func] Add support for .digrc config file, in the
- user's current directory.
+ 346. [placeholder]
345. [bug] Large-scale changes/cleanups to dig:
* Significantly improve structure handling
@@ -5598,7 +6388,6 @@
201. [cleanup] Removed the test/sdig program, it has been
replaced by bin/dig/dig.
-
--- 9.0.0b3 released ---
200. [bug] Failures in sending query responses to clients
@@ -5732,7 +6521,7 @@
and has been removed.
170. [cleanup] Remove inter server consistancy checks from zone,
- these should return as a seperate module in 9.1.
+ these should return as a separate module in 9.1.
dns_zone_checkservers(), dns_zone_checkparents(),
dns_zone_checkchildren(), dns_zone_checkglue().
Index: version
===================================================================
RCS file: /home/cvs/src/contrib/bind9/version,v
retrieving revision 1.3
retrieving revision 1.4
diff -L contrib/bind9/version -L contrib/bind9/version -u -r1.3 -r1.4
--- contrib/bind9/version
+++ contrib/bind9/version
@@ -1,10 +1,10 @@
-# $Id: version,v 1.26.2.17.2.26.4.1 2007/01/11 05:06:25 marka Exp $
+# $Id: version,v 1.29.134.18 2007/11/19 15:25:23 each Exp $
#
# This file must follow /bin/sh rules. It is imported directly via
# configure.
#
MAJORVER=9
-MINORVER=3
-PATCHVER=4
+MINORVER=4
+PATCHVER=2
RELEASETYPE=
RELEASEVER=
--- contrib/bind9/bin/named/include/named/aclconf.h
+++ /dev/null
@@ -1,72 +0,0 @@
-/*
- * Copyright (C) 2004, 2006 Internet Systems Consortium, Inc. ("ISC")
- * Copyright (C) 1999-2001 Internet Software Consortium.
- *
- * Permission to use, copy, modify, and distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- * PERFORMANCE OF THIS SOFTWARE.
- */
-
-/* $Id: aclconf.h,v 1.12.208.3 2006/03/02 00:37:20 marka Exp $ */
-
-#ifndef NS_ACLCONF_H
-#define NS_ACLCONF_H 1
-
-#include <isc/lang.h>
-
-#include <isccfg/cfg.h>
-
-#include <dns/types.h>
-
-typedef struct ns_aclconfctx {
- ISC_LIST(dns_acl_t) named_acl_cache;
-} ns_aclconfctx_t;
-
-/***
- *** Functions
- ***/
-
-ISC_LANG_BEGINDECLS
-
-void
-ns_aclconfctx_init(ns_aclconfctx_t *ctx);
-/*
- * Initialize an ACL configuration context.
- */
-
-void
-ns_aclconfctx_destroy(ns_aclconfctx_t *ctx);
-/*
- * Destroy an ACL configuration context.
- */
-
-isc_result_t
-ns_acl_fromconfig(const cfg_obj_t *caml,
- const cfg_obj_t *cctx,
- ns_aclconfctx_t *ctx,
- isc_mem_t *mctx,
- dns_acl_t **target);
-/*
- * Construct a new dns_acl_t from configuration data in 'caml' and
- * 'cctx'. Memory is allocated through 'mctx'.
- *
- * Any named ACLs referred to within 'caml' will be be converted
- * inte nested dns_acl_t objects. Multiple references to the same
- * named ACLs will be converted into shared references to a single
- * nested dns_acl_t object when the referring objects were created
- * passing the same ACL configuration context 'ctx'.
- *
- * On success, attach '*target' to the new dns_acl_t object.
- */
-
-ISC_LANG_ENDDECLS
-
-#endif /* NS_ACLCONF_H */
--- contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt
+++ /dev/null
@@ -1,754 +0,0 @@
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-Updates RFC 1034, 1035 Motorola Laboratories
-Expires January 2006 July 2005
-
-
-
- Domain Name System (DNS) Case Insensitivity Clarification
- ------ ---- ------ ----- ---- ------------- -------------
- <draft-ietf-dnsext-insensitive-06.txt>
-
- Donald E. Eastlake 3rd
-
-
-
-Status of This Document
-
- 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 BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNSEXT working group at namedroppers at 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 (2005). 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.................................8
-
- Copyright and Disclaimer...................................9
- Normative References.......................................9
- Informative References....................................10
-
- Changes Between Draft Version.............................11
- -02 to -03 Changes........................................11
- -03 to -04 Changes........................................11
- -04 to -05 Changes........................................11
- -05 to -06 Changes........................................12
-
- Author's Address..........................................13
- Expiration and File Name..................................13
-
-
-
-
-
-
-
-
-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 original DNS 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
-
-
-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 (or
- compression) 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] which is now Experimental [RFC 3363].)
-
- 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. With the
- original design of DNS, it was intended that a recursive DNS resolver
-
-
-D. Eastlake 3rd [Page 5]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- be able to handle new CLASSes that were unknown at the time of its
- implementation. This requires uniform handling of label case
- insensitivity. Should it become desireable, for example, to allocate
- a CLASS with "case sensitive ASCII labels" for example, it would be
- necessary to allocate a new label type for these labels.
-
-
-
-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 data 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 are free
- to retain the case first loaded for such a label or allow new input
- to override the old case or even maintain separate copies preserving
-
-
-D. Eastlake 3rd [Page 6]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- the input case.
-
- For example, if data with owner name "foo.bar.example" is loaded 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" in the DNS stored data or the actual input
- case could be preserved. Thus later retrieval of data stored under
- "xyz.bar.example" in this case can return all data with
- "xyz.BAR.example" or all data with "xyz.bar.example" or even, when
- more than one RR is being returned, a mixture of these two cases.
- This last case is unlikely because optimization of answer length
- through indirect labels tends to cause only copy of the name tail
- ("bar.example" or "BAR.example") to be used for all returned RRs.
- Note that none of this has any effect on the number of completeness
- of the RR set returned, only on the case of the names in the RR set
- returned.
-
- The same considerations apply when inputting multiple data records
- with owner names differing only in case. For example, if an "A"
- record is the first resourced record stored 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 in the DNS stored data. In any case, a retrieval with
- either capitalization will retrieve all RRs with either
- capitalization.
-
- 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.
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-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
- or file 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 6 of [RFC
- 4034]. 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
- 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 (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 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.
-
- [RFC 4034} - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [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 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
- Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
- the Domain Name System (DNS)", RFC 3363, August 2002.
-
- [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
- Internationalized String ("stringprep")", December 2002.
-
- [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
- "Internationalizing Domain Names in Applications (IDNA)", March 2003.
-
- [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
- for Internationalized Domain Names (IDN)", March 2003.
-
- [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
- for Internationalized Domain Names in Applications (IDNA)", March
- 2003.
-
- [UNICODE] - The Unicode Consortium, "The Unicode Standard",
- <http://www.unicode.org/unicode/standard/standard.html>.
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Changes Between Draft Version
-
- RFC Editor: The following summaries of changes between draft versions
- are to be removed before publication.
-
-
-
--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.
-
-
-
--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.
-
-
-
-
-D. Eastlake 3rd [Page 11]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
--05 to -06 Changes
-
- The following changes were made between draft version -05 and -06.
-
- 1. Add notation to the RFC Editor that the draft version change
- summaries are to be removed before RFC publication.
-
- 2. Additional text explaining why labe case insensitivity is CLASS
- independent.
-
- 3. Changes and additional text clarifying that the fact that
- inconsistent case in data loaded into DNS may result in
- unpredicatable or inconsistent case in DNS storage but has no effect
- on the completeness of RR sets retrieved.
-
- 4. Add reference to [RFC 3363] and update reference to [RFC 2535] to
- be to [RFC 4034].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 12]
-
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1 508-786-7554 (w)
-
- EMail: Donald.Eastlake at motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires January 2006.
-
- Its file name is draft-ietf-dnsext-insensitive-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 13]
-
--- contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-
-
-Network Working Group S. Weiler
-Internet-Draft SPARTA, Inc
-Updates: 4034, 4035 (if approved) J. Ihren
-Expires: November 13, 2005 Autonomica AB
- May 12, 2005
-
-
- Minimally Covering NSEC Records and DNSSEC On-line Signing
- draft-ietf-dnsext-dnssec-online-signing-00
-
-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 BCP 79.
-
- 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 November 13, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This document describes how to construct DNSSEC NSEC resource records
- that cover a smaller range of names than called for by RFC4034. By
- generating and signing these records on demand, authoritative name
- servers can effectively stop the disclosure of zone contents
- otherwise made possible by walking the chain of NSEC records in a
- signed zone.
-
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 1]
-
-Internet-Draft NSEC Epsilon May 2005
-
-
-Changes from weiler-01 to ietf-00
-
- Inserted RFC numbers for 4033, 4034, and 4035.
-
- Specified contents of bitmap field in synthesized NSEC RR's, pointing
- out that this relaxes a constraint in 4035. Added 4035 to the
- Updates header.
-
-Changes from weiler-00 to weiler-01
-
- Clarified that this updates RFC4034 by relaxing requirements on the
- next name field.
-
- Added examples covering wildcard names.
-
- In the 'better functions' section, reiterated that perfect functions
- aren't needed.
-
- Added a reference to RFC 2119.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 2]
-
-Internet-Draft NSEC Epsilon May 2005
-
-
-Table of Contents
-
- 1. Introduction and Terminology . . . . . . . . . . . . . . . . 4
- 2. Minimally Covering NSEC Records . . . . . . . . . . . . . . 4
- 3. Better Increment & Decrement Functions . . . . . . . . . . . 6
- 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
- 5. Security Considerations . . . . . . . . . . . . . . . . . . 7
- 6. Normative References . . . . . . . . . . . . . . . . . . . . 8
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
- A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8
- Intellectual Property and Copyright Statements . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 3]
-
-Internet-Draft NSEC Epsilon May 2005
-
-
-1. Introduction and Terminology
-
- With DNSSEC [1], an NSEC record lists the next instantiated name in
- its zone, proving that no names exist in the "span" between the
- NSEC's owner name and the name in the "next name" field. In this
- document, an NSEC record is said to "cover" the names between its
- owner name and next name.
-
- Through repeated queries that return NSEC records, it is possible to
- retrieve all of the names in the zone, a process commonly called
- "walking" the zone. Some zone owners have policies forbidding zone
- transfers by arbitrary clients; this side-effect of the NSEC
- architecture subverts those policies.
-
- This document presents a way to prevent zone walking by constructing
- NSEC records that cover fewer names. These records can make zone
- walking take approximately as many queries as simply asking for all
- possible names in a zone, making zone walking impractical. Some of
- these records must be created and signed on demand, which requires
- on-line private keys. Anyone contemplating use of this technique is
- strongly encouraged to review the discussion of the risks of on-line
- signing in Section 5.
-
- The technique presented here may be useful to a zone owner that wants
- to use DNSSEC, is concerned about exposure of its zone contents via
- zone walking, and is willing to bear the costs of on-line signing.
-
- 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 [4].
-
-2. Minimally Covering NSEC Records
-
- This mechanism involves changes to NSEC records for instantiated
- names, which can still be generated and signed in advance, as well as
- the on-demand generation and signing of new NSEC records whenever a
- name must be proven not to exist.
-
- In the 'next name' field of instantiated names' NSEC records, rather
- than list the next instantiated name in the zone, list any name that
- falls lexically after the NSEC's owner name and before the next
- instantiated name in the zone, according to the ordering function in
- RFC4034 [2] section 6.2. This relaxes the requirement in section
- 4.1.1 of RFC4034 that the 'next name' field contains the next owner
- name in the zone. This change is expected to be fully compatible
- with all existing DNSSEC validators. These NSEC records are returned
- whenever proving something specifically about the owner name (e.g.
- that no resource records of a given type appear at that name).
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 4]
-
-Internet-Draft NSEC Epsilon May 2005
-
-
- Whenever an NSEC record is needed to prove the non-existence of a
- name, a new NSEC record is dynamically produced and signed. The new
- NSEC record has an owner name lexically before the QNAME but
- lexically following any existing name and a 'next name' lexically
- following the QNAME but before any existing name.
-
- The generated NSEC record's type bitmap SHOULD have the RRSIG and
- NSEC bits set and SHOULD NOT have any other bits set. This relaxes
- the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
- names that did not exist before the zone wsa signed.
-
- The functions to generate the lexically following and proceeding
- names need not be perfect nor consistent, but the generated NSEC
- records must not cover any existing names. Furthermore, this
- technique works best when the generated NSEC records cover as few
- names as possible.
-
- An NSEC record denying the existence of a wildcard may be generated
- in the same way. Since the NSEC record covering a non-existent
- wildcard is likely to be used in response to many queries,
- authoritative name servers using the techniques described here may
- want to pregenerate or cache that record and its corresponding RRSIG.
-
- For example, a query for an A record at the non-instantiated name
- example.com might produce the following two NSEC records, the first
- denying the existence of the name example.com and the second denying
- the existence of a wildcard:
-
- exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
-
- ).com 3600 IN NSEC +.com ( RRSIG NSEC )
-
- Before answering a query with these records, an authoritative server
- must test for the existence of names between these endpoints. If the
- generated NSEC would cover existing names (e.g. exampldd.com or
- *bizarre.example.com), a better increment or decrement function may
- be used or the covered name closest to the QNAME could be used as the
- NSEC owner name or next name, as appropriate. If an existing name is
- used as the NSEC owner name, that name's real NSEC record MUST be
- returned. Using the same example, assuming an exampldd.com
- delegation exists, this record might be returned from the parent:
-
- exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
-
- Like every authoritative record in the zone, each generated NSEC
- record MUST have corresponding RRSIGs generated using each algorithm
- (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
- described in RFC4035 [3] section 2.2. To minimize the number of
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 5]
-
-Internet-Draft NSEC Epsilon May 2005
-
-
- signatures that must be generated, a zone may wish to limit the
- number of algorithms in its DNSKEY RRset.
-
-3. Better Increment & Decrement Functions
-
- Section 6.2 of RFC4034 defines a strict ordering of DNS names.
- Working backwards from that definition, it should be possible to
- define increment and decrement functions that generate the
- immediately following and preceding names, respectively. This
- document does not define such functions. Instead, this section
- presents functions that come reasonably close to the perfect ones.
- As described above, an authoritative server should still ensure than
- no generated NSEC covers any existing name.
-
- To increment a name, add a leading label with a single null (zero-
- value) octet.
-
- To decrement a name, decrement the last character of the leftmost
- label, then fill that label to a length of 63 octets with octets of
- value 255. To decrement a null (zero-value) octet, remove the octet
- -- if an empty label is left, remove the label. Defining this
- function numerically: fill the left-most label to its maximum length
- with zeros (numeric, not ASCII zeros) and subtract one.
-
- In response to a query for the non-existent name foo.example.com,
- these functions produce NSEC records of:
-
- fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
-
- )\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
-
- The first of these NSEC RRs proves that no exact match for
- foo.example.com exists, and the second proves that there is no
- wildcard in example.com.
-
- Both of these functions are imperfect: they don't take into account
- constraints on number of labels in a name nor total length of a name.
- As noted in the previous section, though, this technique does not
- depend on the use of perfect increment or decrement functions: it is
- sufficient to test whether any instantiated names fall into the span
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 6]
-
-Internet-Draft NSEC Epsilon May 2005
-
-
- covered by the generated NSEC and, if so, substitute those
- instantiated owner names for the NSEC owner name or next name, as
- appropriate.
-
-4. IANA Considerations
-
- Per RFC4041, IANA should think carefully about the protection of
- their immortal souls.
-
-5. Security Considerations
-
- This approach requires on-demand generation of RRSIG records. This
- creates several new vulnerabilities.
-
- First, on-demand signing requires that a zone's authoritative servers
- have access to its private keys. Storing private keys on well-known
- internet-accessible servers may make them more vulnerable to
- unintended disclosure.
-
- Second, since generation of public key signatures tends to be
- computationally demanding, the requirement for on-demand signing
- makes authoritative servers vulnerable to a denial of service attack.
-
- Lastly, if the increment and decrement functions are predictable, on-
- demand signing may enable a chosen-plaintext attack on a zone's
- private keys. Zones using this approach should attempt to use
- cryptographic algorithms that are resistant to chosen-plaintext
- attacks. It's worth noting that while DNSSEC has a "mandatory to
- implement" algorithm, that is a requirement on resolvers and
- validators -- there is no requirement that a zone be signed with any
- given algorithm.
-
- The success of using minimally covering NSEC record to prevent zone
- walking depends greatly on the quality of the increment and decrement
- functions chosen. An increment function that chooses a name
- obviously derived from the next instantiated name may be easily
- reverse engineered, destroying the value of this technique. An
- increment function that always returns a name close to the next
- instantiated name is likewise a poor choice. Good choices of
- increment and decrement functions are the ones that produce the
- immediately following and preceding names, respectively, though zone
- administrators may wish to use less perfect functions that return
- more human-friendly names than the functions described in Section 3
- above.
-
- Another obvious but misguided concern is the danger from synthesized
- NSEC records being replayed. It's possible for an attacker to replay
- an old but still validly signed NSEC record after a new name has been
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 7]
-
-Internet-Draft NSEC Epsilon May 2005
-
-
- added in the span covered by that NSEC, incorrectly proving that
- there is no record at that name. This danger exists with DNSSEC as
- defined in [-bis]. The techniques described here actually decrease
- the danger, since the span covered by any NSEC record is smaller than
- before. Choosing better increment and decrement functions will
- further reduce this danger.
-
-6. Normative References
-
- [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-
-Authors' Addresses
-
- Samuel Weiler
- SPARTA, Inc
- 7075 Samuel Morse Drive
- Columbia, Maryland 21046
- US
-
- Email: weiler at tislabs.com
-
-
- Johan Ihren
- Autonomica AB
- Bellmansgatan 30
- Stockholm SE-118 47
- Sweden
-
- Email: johani at autonomica.se
-
-Appendix A. Acknowledgments
-
- Many individuals contributed to this design. They include, in
- addition to the authors of this document, Olaf Kolkman, Ed Lewis,
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 8]
-
-Internet-Draft NSEC Epsilon May 2005
-
-
- Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
- Jakob Schlyter, Bill Manning, and Joao Damas.
-
- The key innovation of this document, namely that perfect increment
- and decrement functions are not necessary, arose during a discussion
- among the above-listed people at the RIPE49 meeting in September
- 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 9]
-
-Internet-Draft NSEC Epsilon May 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 at 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.
-
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 10]
-
--- contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt
+++ /dev/null
@@ -1,562 +0,0 @@
-
-
-
-
-DNSEXT M. Stapp
-Internet-Draft Cisco Systems, Inc.
-Expires: August 13, 2005 T. Lemon
- A. Gustafsson
- Nominum, Inc.
- February 9, 2005
-
-
- A DNS RR for Encoding DHCP Information (DHCID RR)
- <draft-ietf-dnsext-dhcid-rr-09.txt>
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of Section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 13, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- It is possible for multiple DHCP clients to attempt to update the
- same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
- the clients themselves perform the DNS updates, conflicts can arise.
- To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 1]
-
-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.
-
-Table of Contents
-
- 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 4
- 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . 4
- 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . 4
- 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . 4
- 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 6
- 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 6
- 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 6
- 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8
- 9.2 Informative References . . . . . . . . . . . . . . . . . . 8
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
- Intellectual Property and Copyright Statements . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 2]
-
-Internet-Draft The DHCID RR February 2005
-
-
-1. Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [2].
-
-2. Introduction
-
- A set of procedures to allow DHCP [7] clients and servers to
- automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
- in "Resolution of DNS Name Conflicts" [1].
-
- Conflicts can arise if multiple DHCP clients wish to use the same DNS
- name. To resolve such conflicts, "Resolution of DNS Name Conflicts"
- [1] proposes storing client identifiers in the DNS to unambiguously
- associate domain names with the DHCP clients using them. In the
- interest of clarity, it is preferable for this DHCP information to
- use a distinct RR type. This memo defines a distinct RR for this
- purpose for use by DHCP clients or servers, the "DHCID" RR.
-
- In order to avoid exposing potentially sensitive identifying
- information, the data stored is the result of a one-way MD5 [5] hash
- computation. The hash includes information from the DHCP client's
- REQUEST message as well as the domain name itself, so that the data
- stored in the DHCID RR will be dependent on both the client
- identification used in the DHCP protocol interaction and the domain
- name. This means that the DHCID RDATA will vary if a single client
- is associated over time with more than one name. This makes it
- difficult to 'track' a client as it is associated with various domain
- names.
-
- The MD5 hash algorithm has been shown to be weaker than the SHA-1
- algorithm; it could therefore be argued that SHA-1 is a better
- choice. However, SHA-1 is significantly slower than MD5. A
- successful attack of MD5's weakness does not reveal the original data
- that was used to generate the signature, but rather provides a new
- set of input data that will produce the same signature. Because we
- are using the MD5 hash to conceal the original data, the fact that an
- attacker could produce a different plaintext resulting in the same
- MD5 output is not significant concern.
-
-3. The DHCID RR
-
- The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The
- DHCID RR is only defined in the IN class. DHCID RRs cause no
- additional section processing. The DHCID RR is not a singleton type.
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 3]
-
-Internet-Draft The DHCID RR February 2005
-
-
-3.1 DHCID RDATA format
-
- The RDATA section of a DHCID RR in transmission contains RDLENGTH
- bytes of binary data. The format of this data and its interpretation
- by DHCP servers and clients are described below.
-
- DNS software should consider the RDATA section to be opaque. DHCP
- clients or servers use the DHCID RR to associate a DHCP client's
- identity with a DNS name, so that multiple DHCP clients and servers
- may deterministically perform dynamic DNS updates to the same zone.
- From the updater's perspective, the DHCID resource record RDATA
- consists of a 16-bit identifier type, in network byte order, followed
- by one or more bytes representing the actual identifier:
-
- < 16 bits > DHCP identifier used
- < n bytes > MD5 digest
-
-
-3.2 DHCID Presentation Format
-
- In DNS master files, the RDATA is represented as a single block in
- base 64 encoding identical to that used for representing binary data
- in RFC 2535 [8]. The data may be divided up into any number of white
- space separated substrings, down to single base 64 digits, which are
- concatenated to form the complete RDATA. These substrings can span
- lines using the standard parentheses.
-
-3.3 The DHCID RR Type Codes
-
- The DHCID RR Type Code specifies what data from the DHCP client's
- request was used as input into the hash function. The type codes are
- defined in a registry maintained by IANA, as specified in Section 7.
- The initial list of assigned values for the type code is:
-
- 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7].
- 0x0001 = The data portion from a DHCPv4 client's Client Identifier
- option [9].
- 0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
- client's Client Identifier option [10] or the DUID field from a
- DHCPv4 client's Client Identifier option [12]).
-
- 0x0003 - 0xfffe = Available to be assigned by IANA.
-
- 0xffff = RESERVED
-
-3.4 Computation of the RDATA
-
- The DHCID RDATA is formed by concatenating the two type bytes with
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 4]
-
-Internet-Draft The DHCID RR February 2005
-
-
- some variable-length identifying data.
-
- < type > < data >
-
- The RDATA for all type codes other than 0xffff, which is reserved for
- future expansion, is formed by concatenating the two type bytes and a
- 16-byte MD5 hash value. The input to the hash function is defined to
- be:
-
- data = MD5(< identifier > < FQDN >)
-
- The FQDN is represented in the buffer in unambiguous canonical form
- as described in RFC 2535 [8], section 8.1. The type code and the
- identifier are related as specified in Section 3.3: the type code
- describes the source of the identifier.
-
- When the updater is using the client's link-layer address as the
- identifier, the first two bytes of the DHCID RDATA MUST be zero. To
- generate the rest of the resource record, the updater computes a
- one-way hash using the MD5 algorithm across a buffer containing the
- client's network hardware type, link-layer address, and the FQDN
- data. Specifically, the first byte of the buffer contains the
- network hardware type as it appeared in the DHCP 'htype' field of the
- client's DHCPREQUEST message. All of the significant bytes of the
- chaddr field in the client's DHCPREQUEST message follow, in the same
- order in which the bytes appear in the DHCPREQUEST message. The
- number of significant bytes in the 'chaddr' field is specified in the
- 'hlen' field of the DHCPREQUEST message. The FQDN data, as specified
- above, follows.
-
- When the updater is using the DHCPv4 Client Identifier option sent by
- the client in its DHCPREQUEST message, the first two bytes of the
- DHCID RR MUST be 0x0001, in network byte order. The rest of the
- DHCID RR MUST contain the results of computing an MD5 hash across the
- payload of the option, followed by the FQDN. The payload of the
- option consists of the bytes of the option following the option code
- and length.
-
- When the updater is using the DHCPv6 DUID sent by the client in its
- REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002,
- in network byte order. The rest of the DHCID RR MUST contain the
- results of computing an MD5 hash across the payload of the option,
- followed by the FQDN. The payload of the option consists of the
- bytes of the option following the option code and length.
-
-3.5 Examples
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 5]
-
-Internet-Draft The DHCID RR February 2005
-
-
-3.5.1 Example 1
-
- A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
- Ethernet MAC address 01:02:03:04:05:06 using domain name
- "client.example.com" uses the client's link-layer address to identify
- the client. The DHCID RDATA is composed by setting the two type
- bytes to zero, and performing an MD5 hash computation across a buffer
- containing the Ethernet MAC type byte, 0x01, the six bytes of MAC
- address, and the domain name (represented as specified in
- Section 3.4).
-
- client.example.com. A 10.0.0.1
- client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU
-
-
-3.5.2 Example 2
-
- A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
- included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
- in its DHCP request. The server updates the name "chi.example.com"
- on the client's behalf, and uses the DHCP client identifier option
- data as input in forming a DHCID RR. The DHCID RDATA is formed by
- setting the two type bytes to the value 0x0001, and performing an MD5
- hash computation across a buffer containing the seven bytes from the
- client-id option and the FQDN (represented as specified in
- Section 3.4).
-
- chi.example.com. A 10.0.12.99
- chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012
-
-
-4. Use of the DHCID RR
-
- This RR MUST NOT be used for any purpose other than that detailed in
- "Resolution of DNS Name Conflicts" [1]. Although this RR contains
- data that is opaque to DNS servers, the data must be consistent
- across all entities that update and interpret this record.
- Therefore, new data formats may only be defined through actions of
- the DHC Working Group, as a result of revising [1].
-
-5. Updater Behavior
-
- The data in the DHCID RR allows updaters to determine whether more
- than one DHCP client desires to use a particular FQDN. This allows
- site administrators to establish policy about DNS updates. The DHCID
- RR does not establish any policy itself.
-
- Updaters use data from a DHCP client's request and the domain name
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 6]
-
-Internet-Draft The DHCID RR February 2005
-
-
- that the client desires to use to compute a client identity hash, and
- then compare that hash to the data in any DHCID RRs on the name that
- they wish to associate with the client's IP address. If an updater
- discovers DHCID RRs whose RDATA does not match the client identity
- that they have computed, the updater SHOULD conclude that a different
- client is currently associated with the name in question. The
- updater SHOULD then proceed according to the site's administrative
- policy. That policy might dictate that a different name be selected,
- or it might permit the updater to continue.
-
-6. Security Considerations
-
- The DHCID record as such does not introduce any new security problems
- into the DNS. In order to avoid exposing private information about
- DHCP clients to public scrutiny, a one-way hash is used to obscure
- all client information. In order to make it difficult to 'track' a
- client by examining the names associated with a particular hash
- value, the FQDN is included in the hash computation. Thus, the RDATA
- is dependent on both the DHCP client identification data and on each
- FQDN associated with the client.
-
- Administrators should be wary of permitting unsecured DNS updates to
- zones which are exposed to the global Internet. Both DHCP clients
- and servers SHOULD use some form of update authentication (e.g., TSIG
- [11]) when performing DNS updates.
-
-7. IANA Considerations
-
- IANA is requested to allocate an RR type number for the DHCID record
- type.
-
- This specification defines a new number-space for the 16-bit type
- codes associated with the DHCID RR. IANA is requested to establish a
- registry of the values for this number-space.
-
- Three initial values are assigned in Section 3.3, and the value
- 0xFFFF is reserved for future use. New DHCID RR type codes are
- tentatively assigned after the specification for the associated type
- code, published as an Internet Draft, has received expert review by a
- designated expert. The final assignment of DHCID RR type codes is
- through Standards Action, as defined in RFC 2434 [6].
-
-8. Acknowledgements
-
- Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and
- Ralph Droms for their review and suggestions.
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 7]
-
-Internet-Draft The DHCID RR February 2005
-
-
-9. References
-
-9.1 Normative References
-
- [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
- DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [3] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [4] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
- 1992.
-
- [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-9.2 Informative References
-
- [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
- [8] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
- Extensions", RFC 2132, March 1997.
-
- [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
- Carney, "Dynamic Host Configuration Protocol for IPv6
- (DHCPv6)", RFC 3315, July 2003.
-
- [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
- [12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers
- for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004.
-
-
-
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 8]
-
-Internet-Draft The DHCID RR February 2005
-
-
-Authors' Addresses
-
- Mark Stapp
- Cisco Systems, Inc.
- 1414 Massachusetts Ave.
- Boxborough, MA 01719
- USA
-
- Phone: 978.936.1535
- Email: mjs at cisco.com
-
-
- Ted Lemon
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- USA
-
- Email: mellon at nominum.com
-
-
- Andreas Gustafsson
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- USA
-
- Email: gson at nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 9]
-
-Internet-Draft The DHCID RR 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 at 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.
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 10]
-
-
--- contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt
+++ /dev/null
@@ -1,1736 +0,0 @@
-
-
-
-DNSOP O. Kolkman
-Internet-Draft RIPE NCC
-Expires: September 2, 2005 R. Gieben
- NLnet Labs
- March 2005
-
-
- DNSSEC Operational Practices
- draft-ietf-dnsop-dnssec-operational-practices-04.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 BCP 79.
-
- 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 September 2, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- 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 September 2, 2005 [Page 1]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 4
- 1.2 Time Definitions . . . . . . . . . . . . . . . . . . . . . 5
- 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5
- 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6
- 3.1 Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6
- 3.1.1 Motivations for the KSK and ZSK Separation . . . . . . 6
- 3.1.2 KSKs for high level zones . . . . . . . . . . . . . . 7
- 3.2 Randomness . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.3 Key Effectivity Period . . . . . . . . . . . . . . . . . . 8
- 3.4 Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 9
- 3.5 Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 9
- 3.6 Private Key Storage . . . . . . . . . . . . . . . . . . . 10
- 4. Signature generation, Key Rollover and Related Policies . . . 11
- 4.1 Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 11
- 4.1.1 Time Considerations . . . . . . . . . . . . . . . . . 11
- 4.2 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 13
- 4.2.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 13
- 4.2.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 17
- 4.2.3 Difference Between ZSK and KSK Rollovers . . . . . . . 18
- 4.2.4 Automated Key Rollovers . . . . . . . . . . . . . . . 19
- 4.3 Planning for Emergency Key Rollover . . . . . . . . . . . 19
- 4.3.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . 20
- 4.3.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . 20
- 4.3.3 Compromises of Keys Anchored in Resolvers . . . . . . 20
- 4.4 Parental Policies . . . . . . . . . . . . . . . . . . . . 21
- 4.4.1 Initial Key Exchanges and Parental Policies
- Considerations . . . . . . . . . . . . . . . . . . . . 21
- 4.4.2 Storing Keys or Hashes? . . . . . . . . . . . . . . . 21
- 4.4.3 Security Lameness . . . . . . . . . . . . . . . . . . 22
- 4.4.4 DS Signature Validity Period . . . . . . . . . . . . . 22
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
- 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
- 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
- 7.1 Normative References . . . . . . . . . . . . . . . . . . . 24
- 7.2 Informative References . . . . . . . . . . . . . . . . . . 24
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
- A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 25
- B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 26
- C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 26
- D. Document Details and Changes . . . . . . . . . . . . . . . . . 29
- D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 29
- D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 29
- D.3 draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 29
- D.4 draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 29
- D.5 draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 30
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 2]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- Intellectual Property and Copyright Statements . . . . . . . . 31
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 3]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
-1. Introduction
-
- During workshops and early operational deployment tests, operators
- 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. 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, which are
- discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the
- rollover, or which, 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 [4] language does not apply.
-
- This document obsoletes RFC2541 [7]
-
-1.1 The Use of the Term 'key'
-
- It is assumed that the reader is familiar with the concept of
- asymmetric keys on which DNSSEC is based (Public Key Cryptography
- [11]). Therefore, this document will use the term 'key' rather
- loosely. Where it is written that 'a key is used to sign data' it is
- assumed that the reader understands that it is the private part of
- the key-pair that is used for signing. It is also assumed that the
- reader understands that the public part of the key-pair is published
- in the DNSKEY resource record and that it is the public part that is
- used in key-exchanges.
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 4]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
-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 it may take a
- while before the RRSIG has expired from caches and has actually
- been removed from the DNS.
- o "Key effectivity period"
- The period which a key pair is expected to be 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
- periods.
- 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 (as defined in [2]
- section 5), which may cause entire (sub)domains to become invisible
- to verifying clients. The administrators of secured zones have to
- realize that their zone is, to their clients, part of a chain of
- trust.
-
- As mentioned in the introduction, the procedures herein are intended
- to ensure maintenance of zones, such as resigning or key rollovers,
- will be transparent to the verifying clients on the Internet.
-
- Administrators of secured zones will have to keep in mind that data
- published on an authoritative primary server will not be immediately
- seen by verifying clients; it may take some time for the data to be
- transfered to other secondary authoritative nameservers and clients
- may be fetching data from caching non-authoritative servers.
-
- For the verifying clients it is important that data from secured
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 5]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- zones can be used to build chains of trust regardless of whether the
- data came directly from an authoritative server, a caching nameserver
- or some middle box. Only by carefully using the available timing
- parameters can a zone administrator assure that the data necessary
- for verification can be obtained.
-
- The responsibility for maintaining the chain of trust is shared by
- administrators of secured zones in the chain of trust. This is most
- obvious in the case of a 'key compromise' when a trade off between
- maintaining a valid chain of trust and replacing the compromised keys
- 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.
-
-3. Keys Generation and Storage
-
- 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.
-
-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 Signing and Zone Signing Keys and use the so-called (Secure
- Entry Point) SEP flag to distinguish between them during operations.
- The dynamics and considerations are discussed below.
-
- To make zone resigning and key rollover 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
- SEP keys. In this document we assume a one-to-one mapping between
- KSK and SEP keys and we assume the SEP flag [1] to be set on all
- KSKs.
-
-3.1.1 Motivations for the KSK and ZSK Separation
-
- Differentiating between the KSK and ZSK functions has several
- advantages:
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 6]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- o No parent/child interaction is required when ZSKs are updated.
- 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. Also when
- verifying the KSK is only used to verify the zone's keyset.
- 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.
-
- For almost any method of key management and zone signing the KSK is
- used less frequently than the 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" on 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 planning 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
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 7]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- 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
- off line.
-
- Many resolvers will start at a root server for their access to and
- authentication of DNS data. Securely updating the trust anchors in
- 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 [3]. 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 nobody 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
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 8]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- 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.
-
-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 is
- roughly done at 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.
-
- In 2005 some discoveries were made that SHA-1 also has some
- weaknesses. Currently SHA-1 is strong enough for DNSSEC. It is
- expected that a new hashing algorithm is rolled out, before any
- attack becomes practical.
-
-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 September 2, 2005 [Page 9]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- 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.
-
- Please keep in mind that nobody can see into the future, and that
- these key lengths are only provided here as a guide.
-
- 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 for a discussion
- of how keys serving different roles (ZSK v. KSK) may need different
- key strengths.
-
-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,
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 10]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- 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
- 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 [5] 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 RR minimum TTL parameter [6] 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.
-
-4.1.1 Time Considerations
-
- Because of the expiration of signatures, one should consider the
- following:
- o We suggest the Maximum Zone TTL of your zone data to be a fraction
- of your signature validity period.
- If the TTL would be of similar order as the signature validity
- period, then all RRsets fetched during the validity period
- would be cached until the signature expiration time. Section
- 7.1 of [2] 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
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 11]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- expiration time, as this is also the time at which records
- simultaneously expire from caches.
- To avoid query load peaks we suggest the TTL on all the RRs in
- your zone to be at least a few times smaller than your
- signature validity period.
- o We suggest the signature publication period to be at least one
- maximum TTL smaller than the signature validity period.
- Resigning a zone shortly before the end of the signature
- validity period may cause simultaneous expiration of data from
- caches. This in turn may lead to peaks in the load on
- authoritative servers.
- o 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
- 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
- query.
- 2. Frequent verification causes load on recursive nameservers.
- Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from
- caching. The TTL on those should be relatively long.
- o Slave servers will need to be able to fetch newly signed zones
- well before the RRSIGs in the zone served by the slave server pass
- their signature expiration time.
- When a slave server is out of sync with its master and data in
- a zone is signed by expired signatures it may be better for the
- slave server not to give out any answer.
- Normally a slave server that is not able to contact a master
- server for an extended period will expire a zone. When that
- happens the zone will not respond on queries. The time of
- expiration is set in the SOA record and is relative to the last
- successful refresh between the master and the slave server.
- There exists no coupling between the signature expiration of
- RRSIGs in the zone and the expire parameter in the SOA.
- If the server serves a DNSSEC zone than it may well happen that
- the signatures expire well before the SOA expiration timer
- counts down to zero. It is not possible to completely prevent
- this from happening by tweaking the SOA parameters.
- However, the effects can be minimized where the SOA expiration
- time is equal or smaller than the signature validity period.
- The consequence of an authoritative server not being able to
- update a zone, whilst that zone includes expired signatures, is
- that non-secure resolvers will continue to be able to resolve
- data served by the particular slave servers while security
- aware resolvers will experience problems because of answers
- being marked as Bogus.
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 12]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- We suggest the SOA expiration timer being approximately one
- third or one fourth of the signature validity period. It will
- allow problems with transfers from the master server to be
- noticed before the actual signature time out.
- We also suggest that operators of nameservers that supply
- secondary services develop 'watch dogs' to spot upcoming
- signature expirations in zones they slave, and take appropriate
- action.
- When determining the value for the expiration parameter one has
- to take the following into account: What are the chances that
- all my secondary zones expire; How quickly can I reach an
- administrator of secondary servers to load a valid zone? All
- these arguments are not DNSSEC specific but may influence the
- choice of your signature validity intervals.
-
-4.2 Key Rollovers
-
- A DNSSEC key cannot be used forever (see Section 3.3). So key
- rollovers -- or supercessions, 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
- old zone key cached. If the old key is no longer present in the
- current zone, this validation fails, marking the data Bogus.
- Alternatively, an attempt could be made to validate data which is
- signed with a new key against an old key that lives in a local cache,
- also resulting in data being marked Bogus.
-
-4.2.1 Zone-signing Key Rollovers
-
- For zone-signing key rollovers there are two ways to make sure that
- during the rollover data still cached can be verified with the new
- key sets or newly generated signatures can be verified with the keys
- still in caches. One schema, described in Section 4.2.1.2, uses
- double signatures; the other uses key pre-publication
- (Section 4.2.1.1). The pros, cons and recommendations are described
- in Section 4.2.1.3.
-
-4.2.1.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
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 13]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- rollover".This method has advantages in the case of a key compromise.
- If the old key is compromised, the new key has already been
- distributed in the DNS. The zone administrator is then able to
- quickly switch to the new key and remove the compromised key from the
- zone. Another major advantage is that the zone size does not double,
- as is the case with the double signature ZSK rollover. A small
- "HOWTO" for this kind of rollover can be found in Appendix B.
-
- normal pre-roll roll after
-
- SOA0 SOA1 SOA2 SOA3
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
-
- DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
- DNSKEY11 DNSKEY11
- RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
-
-
- normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
- DNSKEY 10 is used to sign all the data of the zone, the zone-
- signing key.
- pre-roll: DNSKEY 11 is introduced into the key set. Note that no
- signatures are generated with this key yet, but this does not
- secure against brute force attacks on the public key. The minimum
- duration of this pre-roll phase is the time it takes for the data
- to propagate to the authoritative servers plus TTL value of the
- key set. This equates to two times the Maximum Zone TTL.
- roll: At the rollover stage (SOA serial 2) DNSKEY 11 is used to sign
- the data in the zone exclusively (i.e. all the signatures from
- DNSKEY 10 are removed from the zone). DNSKEY 10 remains published
- in the key set. This way data that was loaded into caches from
- version 1 of the zone can still be verified with key sets fetched
- from version 2 of the zone.
- The minimum time that the key set including DNSKEY 10 is to be
- published is the time that it takes for zone data from the
- previous version of the zone to expire from old caches i.e. the
- time it takes for this zone to propagate to all authoritative
- servers plus the Maximum Zone TTL value of any of the data in the
- previous version of the zone.
- after: DNSKEY 10 is removed from the zone. The key set, now only
- containing DNSKEY 1 and DNSKEY 11 is resigned with the DNSKEY 1.
-
- The above scheme can be simplified by always publishing the "future"
- key immediately after the rollover. The scheme would look as follows
- (we show two rollovers); the future key is introduced in "after" as
- DNSKEY 12 and again a newer one, numbered 13, in "2nd after":
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 14]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- normal roll after
-
- SOA0 SOA2 SOA3
- RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3)
-
- DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY11
- DNSKEY11 DNSKEY11 DNSKEY12
- RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY)
- RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
-
-
- 2nd roll 2nd after
-
- SOA4 SOA5
- RRSIG12(SOA4) RRSIG12(SOA5)
-
- DNSKEY1 DNSKEY1
- DNSKEY11 DNSKEY12
- DNSKEY12 DNSKEY13
- RRSIG1(DNSKEY) RRSIG1(DNSKEY)
- RRSIG12(DNSKEY) RRSIG12(DNSKEY)
-
-
- Note that the key introduced after the rollover is not used for
- production yet; the private key can thus be stored in a physically
- secure manner and does not need to be 'fetched' every time a zone
- needs to be signed.
-
-4.2.1.2 Double Signature Zone-signing Key Rollover
-
- This section shows how to perform a ZSK key rollover using the double
- zone data signature scheme, aptly named "double sig rollover".
-
- During the rollover stage the new version of the zone file will need
- to propagate to all authoritative servers and the data that exists in
- (distant) caches will need to expire, requiring at least the maximum
- Zone TTL.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 15]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- normal roll after
-
- SOA0 SOA1 SOA2
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
- RRSIG11(SOA1)
-
- DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY11
- DNSKEY11
- RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
- RRSIG11(DNSKEY)
-
- normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
- DNSKEY 10 is used to sign all the data of the zone, the zone-
- signing key.
- roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced
- into the key set and all the data in the zone is signed with
- DNSKEY 10 and DNSKEY 11. The rollover period will need to exist
- until all data from version 0 of the zone has expired from remote
- caches. This will take at least the maximum Zone TTL of version 0
- of the zone.
- after: DNSKEY 10 is removed from the zone. All the signatures from
- DNSKEY 10 are removed from the zone. The key set, now only
- containing DNSKEY 11, is resigned with DNSKEY 1.
-
- At every instance, RRSIGs from the previous version of the zone can
- be verified with the DNSKEY RRset from the current version and the
- other way around. The data from the current version can be verified
- with the data from the previous version of the zone. The duration of
- the rollover phase and the period between rollovers should be at
- least the "Maximum Zone TTL".
-
- Making sure that the rollover phase lasts until the signature
- expiration time of the data in version 0 of the zone is recommended.
- This way all caches are cleared of the old signatures. However, this
- date could be considerably longer than the Maximum Zone TTL, making
- the rollover a lengthy procedure.
-
- Note that in this example we assumed that the zone was not modified
- during the rollover. New data can be introduced in the zone as long
- as it is signed with both keys.
-
-4.2.1.3 Pros and Cons of the Schemes
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 16]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- Pre-publish-key set rollover: This rollover does not involve signing
- the zone data twice. Instead, before the actual rollover, 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 involves more
- parental work when used for KSK rollovers 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.
-
-4.2.2 Key-signing Key Rollovers
-
- For the rollover of a key-signing key the same considerations as for
- the rollover of a zone-signing key apply. However we can use a
- double signature scheme to guarantee that old data (only the apex key
- set) in caches can be verified with a new key set and vice versa.
-
- Since only the key set is signed with a KSK, zone size considerations
- do not apply.
-
-
- normal roll after
-
- SOA0 SOA1 SOA2
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2)
-
- DNSKEY1 DNSKEY1 DNSKEY2
- DNSKEY2
- DNSKEY10 DNSKEY10 DNSKEY10
- RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY)
- RRSIG2 (DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-
- normal: Version 0 of the zone. The parental DS points to DNSKEY1.
- Before the rollover starts the child will have to verify what the
- TTL is of the DS RR that points to DNSKEY1 - it is needed during
- the rollover and we refer to the value as TTL_DS.
- roll: During the rollover phase the zone administrator generates a
- second KSK, DNSKEY2. The key is provided to the parent and the
- child will have to wait until a new DS RR has been generated that
- points to DNSKEY2. After that DS RR has been published on all
- servers authoritative for the parent's zone, the zone
- administrator has to wait at least TTL_DS to make sure that the
- old DS RR has expired from caches.
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 17]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- after: DNSKEY1 has been removed.
-
- The scenario above puts the responsibility for maintaining a valid
- chain of trust with the child. It also is based on the premises that
- the parent only has one DS RR (per algorithm) per zone. An
- alternative mechanism has been considered. Using an established
- trust relation, the interaction can be performed in-band, and the
- removal of the keys by the child can possibly be signaled by the
- parent. In this mechanism there are periods where there are two DS
- RRs at the parent. Since at the moment of writing the protocol for
- this interaction has not been developed further discussion is out of
- scope for this document.
-
-4.2.3 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 4.2.1.1) and double signature (Section Section 4.2.1.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
- key set of the zone. The pre-publish method would work for a KSK
- rollover. The record that are to be pre-published are the parental
- DS RRs.
-
- The pre-publish method has some drawbacks. We first describe the
- rollover scheme and then indicate these drawbacks.
-
- normal pre-roll roll after
- Parent:
- SOA0 SOA1 SOA2 SOA3
- RRSIGpar(SOA0) RRSIGpar(SOA1) RRSIGpar(SOA2) RRSIGpar(SOA3)
- DS1 DS1 DS1 DS2
- DS2 DS2
- RRSIGpar(DS) RRSIGpar(DS) RRSIGpar(DS) RRSIGpar(DS)
-
-
-
- Child:
- SOA0 SOA0 SOA1 SOA1
- RRSIG10(SOA0) RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA1)
-
- DNSKEY1 DNSKEY1 DNSKEY2 DNSKEY2
-
- DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY10
- RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) RRSIG2 (DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 18]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- When the child zone wants to roll it notifies the parent during the
- pre-roll phase and submits the new key to the parent. The parent
- publishes DS1 and DS2, pointing to DNSKEY1 and DNSKEY2 respectively.
- During the rollover, which can take place as soon as the new DS set
- propagated through the DNS, the child replaces DNSKEY1 with DNSKEY2.
- Immediately after that it can notify the parent that the old DS
- record can be deleted.
-
- The drawbacks of these scheme are that during the pre-roll phase the
- parent cannot verify the match between the DS RR and DNSKEY2 using
- the DNS. Besides, we introduce a "security lame" DS record
- Section 4.4.3. Finally the child-parent interaction consists of two
- steps. The "double signature" method only needs one interaction.
-
-4.2.4 Automated Key Rollovers
-
- As keys must be renewed periodically, there is some motivation to
- automate the rollover process. Consider that:
-
- o ZSK rollovers are easy to automate as only the local zone is
- involved.
- o A KSK rollover needs interaction between the parent and child.
- 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 4.2 apply to
- an automated 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
- compromise is suspected or confirmed.
-
- When the private material of one of your keys is compromised it can
- be used for as long as a valid authentication chain exists. An
- authentication chain remains intact for:
- o as long as a signature over the compromised key in the
- authentication chain is valid,
- o as long as a parental DS RR (and signature) points to the
- compromised key,
- o as long as the key is anchored in a resolver and is used as a
- starting point for validation. (This is generally the hardest to
- update.)
-
- While an authentication chain to your compromised key exists, your
- name-space is vulnerable to abuse by anyone who has obtained
- illegitimate possession of the key.Zone operators have to make a
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 19]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- trade off if the abuse of the compromised key is worse than having
- data in caches that cannot be validated. If the zone operator
- chooses to break the authentication chain to the compromised key,
- data in caches signed with this key cannot be validated. However, if
- the zone administrator chooses to take the path of a regular roll-
- over, the malicious key holder can spoof data so that it appears to
- be valid. Note that this kind of attack is more likely to occur in a
- localized part of the network topology i.e. downstream from where the
- spoof takes place.
-
-
-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
- resigned as soon as possible. Care must be taken to not break the
- authentication chain. The local zone can only be resigned with the
- new KSK after the parent's zone has created and reloaded its zone
- with the DS created from the new KSK. Before this update takes place
- it would be best to drop the security status of a zone all together:
- the parent removes the DS of the child at the next zone update.
- After that the child can be made secure again.
-
- An additional danger of a key compromise is that the compromised key
- can be used to facilitate a legitimate DNSKEY/DS and/or nameserver
- rollover at the parent. When that happens the domain can be in
- dispute. An authenticated out of band and secure notify mechanism to
- contact a parent is needed in this case.
-
-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
- compromise. The zone must still be resigned with a new ZSK as soon
- as possible. As this is a local operation and requires no
- communication between the parent and child this can be achieved
- fairly quickly. However, one has to take into account that just as
- with a normal rollover the immediate disappearance from the old
- compromised key may lead to verification problems. The pre-
- publication scheme as discussed above minimizes such problems.
-
-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 may be pre-configured in
- most security aware resolvers.
-
- If trust-anchor keys are compromised, the resolvers using these keys
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 20]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- should be notified of this fact. Zone administrators may consider
- setting up a mailing list to communicate the fact that a SEP key is
- about to be rolled over. This communication will of course need to
- be authenticated e.g. by using digital signatures.
-
- End-users faced with the task of updating an anchored key should
- always validate the new key. New keys should be authenticated out of
- the DNS, for example, looking them up on an SSL secured announcement
- website.
-
-4.4 Parental Policies
-
-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
- should take into account that the authentication and authorization
- mechanisms used during a key exchange should be as strong as the
- authentication and authorization mechanisms used for the exchange of
- delegation information between parent and child. I.e. there is no
- implicit need in DNSSEC to make the authentication process stronger
- than it was in DNS.
-
- 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 [1] 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.
- Fetching the DNSKEY from the DNS ensures that the chain of trust
- remains intact once the parent publishes the DS RR indicating the
- child is secure.
-
- Note: the off-band verification is still needed when the key-material
- is fetched via the DNS. The parent can never be sure whether the
- DNSKEY RRs have been spoofed or not.
-
-4.4.2 Storing Keys or Hashes?
-
- When designing a registry system one should consider which of the
- DNSKEYs and/or the corresponding DSs to store. Since a child zone
- might wish to have a DS published using a message digest algorithm
- not yet understood by the registry, the registry can't count on being
- able to generate the DS record from a raw DNSKEY. Thus, we recommend
- that registry system at least support storing DS records.
-
- It may also be useful to store DNSKEYs, since having them may help
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 21]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- during troubleshooting and, so long as the child's chosen message
- digest is supported, the overhead of generating DS records from them
- is minimal. Having an out-of-band mechanism, such as a Whois
- database, to find out which keys are used to generate DS Resource
- Records for specific owners and/or zones may also help with
- troubleshooting.
-
- The storage considerations also relate the design of the customer
- interface and the method by which data is transfered between
- registrant and registry; Will the child zone owner be able to upload
- DS RRs with unknown hash algorithms or does the interface only allows
- DNSKEYs? In the registry-registrar model one can use the DNSSEC EPP
- protocol extensions [9] which allows transfer of DS RRs and
- optionally DNSKEY RRs.
-
-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
- parent should make sure that the child's key is actually configured
- in the DNS before publishing a DS RR in its zone. Failure to do so
- could cause the child's zone being marked as Bogus.
-
- Child zones should be very careful removing DNSKEY material,
- specifically SEP keys, for which a DS RR exists.
-
- Once a zone is "security lame", a fix (e.g. removing a DS RR) will
- take time to propagate through the DNS.
-
-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
- child is vulnerable in the case of a compromise of the child's
- KSK(s). A signature validity period that is too short introduces the
- possibility that a zone is marked Bogus in case of a configuration
- error in the signer. There may not be enough time to fix the
- problems before signatures expire. Something as mundane as operator
- unavailability during weekends shows the need for DS signature
- validity periods longer than 2 days. We recommend the minimum for a
- DS signature validity period of a few days.
-
- 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.
-
- We consider a signature validity period of around one week to be a
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 22]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- good compromise between the operational constraints of the parent and
- minimizing damage for the child.
-
- In addition to the signature validity period, which sets a lower
- bound 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
- the operational considerations to maintain 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.
-
-6. Acknowledgments
-
- 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 were the original
- contributors of the ideas we would like to acknowledge people who
- were actively involved in the compilation of this document. In
- random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
- Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
- Olivier Courtay, Sam Weiler, Jelte Jansen and Niall O'Reilly.
-
- Some material in this document has been shamelessly copied from
- RFC2541 [7] by Donald Eastlake.
-
- Mike StJohns designed the key exchange between parent and child
- mentioned in the last paragraph of Section 4.2.2
-
- Section 4.2.4 was supplied by G. Guette and O. Courtay.
-
- Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of
- the spelling and style issues.
-
- Kolkman and Gieben take the blame for introducing all miscakes(SIC).
-
-7. References
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 23]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
-7.1 Normative References
-
- [1] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY
- (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
- RFC 3757, May 2004.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
-7.2 Informative References
-
- [3] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1994.
-
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [5] Eastlake, D., "Secure Domain Name System Dynamic Update",
- RFC 2137, April 1997.
-
- [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
- [7] Eastlake, D., "DNS Security Operational Considerations",
- RFC 2541, March 1999.
-
- [8] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
- RFC 3658, December 2003.
-
- [9] Hollenbeck, S., "Domain Name System (DNS) Security Extensions
- Mapping for the Extensible Provisioning Protocol (EPP)",
- draft-hollenbeck-epp-secdns-07 (work in progress), March 2005.
-
- [10] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
- Sizes", The Journal of Cryptology 14 (255-293), 2001.
-
- [11] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
- Source Code in C", 1996.
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 24]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
-Authors' Addresses
-
- Olaf M. Kolkman
- RIPE NCC
- Singel 256
- Amsterdam 1016 AB
- The Netherlands
-
- Phone: +31 20 535 4444
- Email: olaf at ripe.net
- URI: http://www.ripe.net/
-
-
- Miek Gieben
- NLnet Labs
- Kruislaan 419
- Amsterdam 1098 VA
- The Netherlands
-
- Email: miek at nlnetlabs.nl
- URI: http://www.nlnetlabs.nl
-
-Appendix A. Terminology
-
- In this document there is some jargon used that is defined in other
- documents. In most cases we have not copied the text from the
- documents defining the terms but given a more elaborate explanation
- of the meaning. Note that these explanations should not be seen as
- authoritative.
-
- 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 [2]. 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 supercession in some
- environments) is the act of replacing one key pair by another at
- the end of a key effectivity period.
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 25]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- 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.
- 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.
-
-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".
- 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.
- Store the private part of the "published" key, preferably off-
- line.
- The protocol does not provide for attributes to mark a key as
- active or published. This is something you have to do on your
- own, through the use of a notebook or key management tool.
- Step 1: Determine expiration: At the beginning of the rollover make a
- note of the highest expiration time of signatures in your zone
- file created with the current key marked as "active".
- Wait until the expiration time marked in Step 1 has passed
- Step 2: Then start using the key that was marked as "published" to
- sign your data i.e. mark it as "active". Stop using the key that
- was marked as "active", mark it as "rolled".
- Step 3: It is safe to engage in a new rollover (Step 1) after at
- least one "signature validity period".
-
-Appendix C. Typographic Conventions
-
- The following typographic conventions are used in this document:
- Key notation: A key is denoted by KEYx, where x is a number, x could
- be thought of as the key id.
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 26]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- RRset notations: RRs are only denoted by the type. All other
- information - owner, class, rdata and TTL - is left out. Thus:
- "example.com 3600 IN A 192.168.1.1" is reduced to "A". RRsets are
- a list of RRs. A example of this would be: "A1,A2", specifying
- the RRset containing two "A" records. This could again be
- abbreviated to just "A".
- Signature notation: Signatures are denoted as RRSIGx(RRset), which
- means that RRset is signed with DNSKEYx.
- Zone representation: Using the above notation we have simplified the
- representation of a signed zone by leaving out all unnecessary
- details such as the names and by representing all data by "SOAx"
- SOA representation: SOA's are represented as SOAx, where x is the
- serial number.
- Using this notation the following zone:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 27]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- example.net. 600 IN SOA ns.example.net. bert.example.net. (
- 10 ; serial
- 450 ; refresh (7 minutes 30 seconds)
- 600 ; retry (10 minutes)
- 345600 ; expire (4 days)
- 300 ; minimum (5 minutes)
- )
- 600 RRSIG SOA 5 2 600 20130522213204 (
- 20130422213204 14 example.net.
- cmL62SI6iAX46xGNQAdQ... )
- 600 NS a.iana-servers.net.
- 600 NS b.iana-servers.net.
- 600 RRSIG NS 5 2 600 20130507213204 (
- 20130407213204 14 example.net.
- SO5epiJei19AjXoUpFnQ ... )
- 3600 DNSKEY 256 3 5 (
- EtRB9MP5/AvOuVO0I8XDxy0...
- ) ; key id = 14
- 3600 DNSKEY 256 3 5 (
- gsPW/Yy19GzYIY+Gnr8HABU...
- ) ; key id = 15
- 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
- 20130422213204 14 example.net.
- J4zCe8QX4tXVGjV4e1r9... )
- 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
- 20130422213204 15 example.net.
- keVDCOpsSeDReyV6O... )
- 600 RRSIG NSEC 5 2 600 20130507213204 (
- 20130407213204 14 example.net.
- obj3HEp1GjnmhRjX... )
- a.example.net. 600 IN TXT "A label"
- 600 RRSIG TXT 5 3 600 20130507213204 (
- 20130407213204 14 example.net.
- IkDMlRdYLmXH7QJnuF3v... )
- 600 NSEC b.example.com. TXT RRSIG NSEC
- 600 RRSIG NSEC 5 3 600 20130507213204 (
- 20130407213204 14 example.net.
- bZMjoZ3bHjnEz0nIsPMM... )
-
- ...
-
-
- is reduced to the following representation:
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 28]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- SOA10
- RRSIG14(SOA10)
-
- DNSKEY14
- DNSKEY15
-
- RRSIG14(KEY)
- RRSIG15(KEY)
-
- The rest of the zone data has the same signature as the SOA record,
- i.e a RRSIG created with DNSKEY 14.
-
-Appendix D. Document Details and Changes
-
- This section is to be removed by the RFC editor if and when the
- document is published.
-
- $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14
- 2005/03/21 15:51:41 dnssec Exp $
-
-D.1 draft-ietf-dnsop-dnssec-operational-practices-00
-
- Submission as working group document. This document is a modified
- and updated version of draft-kolkman-dnssec-operational-practices-00.
-
-D.2 draft-ietf-dnsop-dnssec-operational-practices-01
-
- changed the definition of "Bogus" to reflect the one in the protocol
- draft.
-
- Bad to Bogus
-
- Style and spelling corrections
-
- KSK - SEP mapping made explicit.
-
- Updates from Sam Weiler added
-
-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
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 29]
-
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- instead of Key validity period.
-
- Modified the order of the sections, based on a suggestion by Rip
- Loomis.
-
- Included parts from RFC2541 [7]. Most of its ground was already
- covered. This document obsoletes RFC2541 [7]. 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
-
-D.5 draft-ietf-dnsop-dnssec-operational-practices-04
-
- Somewhat more details added about the pre-publish KSK rollover. Also
- moved that subsection down a bit.
-
- Editorial and content nits that came in during wg last call were
- fixed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 30]
-
-Internet-Draft DNSSEC Operational Practices March 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 at 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.
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 31]
-
--- contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt
+++ /dev/null
@@ -1,580 +0,0 @@
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-UPDATES RFC 2845 Motorola Laboratories
-Expires: December 2005 June 2005
-
-
- HMAC SHA TSIG Algorithm Identifiers
- ---- --- ---- --------- -----------
- <draft-ietf-dnsext-tsig-sha-04.txt>
-
-
-Status of This Document
-
- 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 BCP 79.
-
- This draft is intended to be become a Proposed Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNSEXT working group mailing list <namedroppers at ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- Use of the TSIG DNS resource record requires specification of a
- cryptographic message authentication code. Currently identifiers
- have been specified only for the HMAC-MD5 and GSS TSIG algorithms.
- This document standardizes identifiers and implementation
- requirements for additional HMAC SHA TSIG algorithms and standardizes
- how to specify and handle the truncation of HMAC values.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2005. All Rights Reserved.
-
-
-
-
-D. Eastlake 3rd [Page 1]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright Notice...........................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
-
- 2. Algorithms and Identifiers..............................4
-
- 3. Specifying Truncation...................................5
- 3.1 Truncation Specification...............................5
-
- 4. TSIG Policy Provisions and Truncation Error.............7
-
- 5. IANA Considerations.....................................8
- 6. Security Considerations.................................8
- 6. Copyright and Disclaimer................................8
-
- 7. Normative References....................................9
- 8. Informative References..................................9
-
- Author's Address..........................................10
- Expiration and File Name..................................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-1. Introduction
-
- [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
- authenticate DNS queries and responses. This RR contains a domain
- name syntax data item which names the authentication algorithm used.
- [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for
- authentication codes using the HMAC [RFC 2104] algorithm with the MD5
- [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an
- identifier for TSIG authentication where the cryptographic operations
- are delegated to GSS [RFC 3645].
-
- In Section 2, this document specifies additional names for TSIG
- authentication algorithms based on US NIST SHA algorithms and HMAC
- 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
- length of MAC (message authentication code) data given in the TSIG
- RR. In particular, it specifies that a shorter length field value
- specifies truncation and a longer length field is an error.
-
- In Section 4, policy restrictions and implications related to
- truncation and a new error code to indicate truncation shorter than
- permitted by policy are described and specified.
-
- The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
- defined in [RFC 2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 3]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-2. Algorithms and Identifiers
-
- TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
- queries and responses. They are intended to be efficient symmetric
- authentication codes based on a shared secret. (Asymmetric signatures
- can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
- can be used for transaction signatures.) Used with a strong hash
- function, HMAC [RFC 2104] provides a way to calculate such symmetric
- authentication codes. The only specified HMAC based TSIG algorithm
- identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
-
- The use of SHA-1 [FIPS 180-2, 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 3874, SHA2draft] with 224, 256, 384,
- and 512 bits, may be preferred in some cases 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
- and truncations are acceptable subject to the restrication and
- guidelines in Section 3 and 4 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
- Mandatory hmac-sha1
- Optional hmac-sha224
- Mandatory hmac-sha256
- Optional hamc-sha384
- Optional hmac-sha512
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 4]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-3. Specifying Truncation
-
- When space is at a premium and the strength of the full length of an
- HMAC is not needed, it is reasonable to truncate the HMAC output and
- use the truncated value for authentication. HMAC SHA-1 truncated to
- 96 bits is an option available in several IETF protocols including
- IPSEC and TLS.
-
- The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
- size of the MAC field in octets. But [RFC 2845] does not specify what
- to do if this MAC size differs from the length of the output of HMAC
- for a particular hash function. Truncation is indicated by a MAC size
- less than the HMAC size as specified below.
-
-
-
-3.1 Truncation Specification
-
- The specification for TSIG handling is changed as follows:
-
- 1. If "MAC size" field is greater than HMAC output length:
- This case MUST NOT be generated and if received MUST cause the
- packet to be dropped and RCODE 1 (FORMERR) to be returned.
-
- 2. If "MAC size" field equals HMAC output length:
- Operation is as described in [RFC 2845] with the entire output
- HMAC output present.
-
- 3. "MAC size" field is less than HMAC output length but greater than
- that specified in case 4 below:
- This is sent when the signer has truncated the HMAC output to
- an allowable length, as described in RFC 2104, taking initial
- octets and discarding trailing octets. TSIG truncation can only be
- to an integral number of octets. On receipt of a packet with
- truncation thus indicated, the locally calculated MAC is similarly
- truncated and only the truncated values compared for
- authentication. The request MAC used when calculating the TSIG MAC
- for a reply is the trucated request MAC.
-
- 4. "MAC size" field is less than the larger of 10 (octets) and half
- the length of the hash function in use:
- With the exception of certain TSIG error messages described in
- RFC 2845 section 3.2 where it is permitted that the MAC size be
- zero, this case MUST NOT be generated and if received MUST cause
- the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
- size limit for this case can also, for the hash functions
- mentioned in this document, be stated as less than half the hash
- function length for hash functions other than MD5 and less than 10
- octets for MD5.
-
-
-
-D. Eastlake 3rd [Page 5]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
- SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-4. TSIG Policy Provisions and Truncation Error
-
- Use of TSIG is by mutual agreement between a resolver and server.
- Implicit in such "agreement" are policies as to acceptable keys and
- algorithms and, with the extensions in this doucment, truncations. In
- particular note the following:
-
- Such policies MAY require the rejection of TSIGs even though they
- use an algorithm for which implementation is mandatory.
-
- When a policy calls for the acceptance of a TSIG with a particular
- algorithm and a particular non-zero amount of trunction it SHOULD
- also permit the use of that algorithm with lesser truncation (a
- longer MAC) up to the full HMAC output.
-
- Regardless of a lower acceptable truncated MAC length specified by
- policy, a reply SHOULD be sent with a MAC at least as long as that in
- the corresponding request unless the request specified a MAC length
- longer than the HMAC output.
-
- Implementations permitting policies with multiple acceptable
- algorithms and/or truncations SHOULD permit this list to be ordered
- by presumed strength and SHOULD allow different truncations for the
- same algorithm to be treatred as spearate entities in this list. When
- so implemented, policies SHOULD accept a presumed stronger algorithm
- and truncation than the minimum strength required by the policy.
-
- If a TSIG is received with truncation which is permitted under
- Section 3 above but the MAC is too short for the policy in force, an
- RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-5. IANA Considerations
-
- This document, on approval for publication as a standards track RFC,
- (1) registers the new TSIG algorithm identifiers listed in Section 2
- with IANA and (2) Section 4 allocates the BADTRUNC RCODE TBA [22
- suggested].
-
-
-
-
-6. Security Considerations
-
- For all of the message authentication code algorithms listed herein,
- those producing longer values are believed to be stronger; however,
- while there have been some arguments that mild truncation can
- strengthen a MAC by reducing the information available to an
- attacker, excessive truncation clearly weakens authentication by
- reducing the number of bits an attacker has to try to brute force
- [RFC 2104].
-
- Significant progress has been made recently in cryptanalysis of hash
- function of the type used herein, all of which ultimately derive from
- the design of MD4. 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 the Security Considerations section of [RFC 2845]. See also the
- Security Considerations section of [RFC 2104] from which the limits
- on truncation in this RFC were taken.
-
-
-
-6. Copyright 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.
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-7. Normative References
-
- [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.
-
- [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication", RFC 2104, February 1997.
-
- [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
-
-
-8. Informative References.
-
- [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
- Signatures ( SIG(0)s )", RFC 2931, September 2000.
-
- [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
- 1 (SHA1)", RFC 3174, September 2001.
-
- [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
- J., and R. Hall, "Generic Security Service Algorithm for Secret Key
- Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
- 2003.
-
- [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
- September 2004,
-
- [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
- (SHA)", work in progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 9]
-
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554 (w)
-
- EMail: Donald.Eastlake at motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in December 2005.
-
- Its file name is draft-ietf-dnsext-tsig-sha-04.txt
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-
--- contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt
+++ /dev/null
@@ -1,730 +0,0 @@
-
-
-
-
-Network Working Group M. StJohns
-Internet-Draft Nominum, Inc.
-Expires: February 16, 2006 August 15, 2005
-
-
- Automated Updates of DNSSEC Trust Anchors
- draft-ietf-dnsext-trustupdate-timers-01
-
-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 BCP 79.
-
- 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 16, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-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
- management behavior (but not resolver resolution behavior), and the
-
-
-
-StJohns Expires February 16, 2006 [Page 1]
-
-Internet-Draft trustanchor-update August 2005
-
-
- 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 . . . . . . . . . . . . . . . . . . . . . . 4
- 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 February 16, 2006 [Page 2]
-
-Internet-Draft trustanchor-update August 2005
-
-
-1. Introduction
-
- As part of the reality of fielding DNSSEC (Domain Name System
- Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], 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
-
- Added the concept of timer triggered resolver queries to refresh the
-
-
-
-StJohns Expires February 16, 2006 [Page 3]
-
-Internet-Draft trustanchor-update August 2005
-
-
- resolvers view of the trust anchor key RRSet.
-
- Re-submitted expired draft as -01. Updated DNSSEC RFC References.
-
-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.
-
-2.2 Add Hold-Down
-
- Assume two trust point keys A and B. Assume that B has been
-
-
-
-StJohns Expires February 16, 2006 [Page 4]
-
-Internet-Draft trustanchor-update August 2005
-
-
- 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
- hasn't reappeared, SHOULD discard any information about the key.
-
-
-
-
-
-StJohns Expires February 16, 2006 [Page 5]
-
-Internet-Draft trustanchor-update August 2005
-
-
-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
- 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'.
-
-
-
-StJohns Expires February 16, 2006 [Page 6]
-
-Internet-Draft trustanchor-update August 2005
-
-
- 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
- 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.
-
-
-
-
-
-StJohns Expires February 16, 2006 [Page 7]
-
-Internet-Draft trustanchor-update August 2005
-
-
- 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'.
- 1. Generate a new key pair.
-
-
-
-
-
-StJohns Expires February 16, 2006 [Page 8]
-
-Internet-Draft trustanchor-update August 2005
-
-
- 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
- included in the RRSet for the remove hold-down time.
-
-
-
-StJohns Expires February 16, 2006 [Page 9]
-
-Internet-Draft trustanchor-update August 2005
-
-
-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
-
- [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.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
-
-
-StJohns Expires February 16, 2006 [Page 10]
-
-Internet-Draft trustanchor-update August 2005
-
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
-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 at nominum.com
- URI: www.nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires February 16, 2006 [Page 11]
-
-Internet-Draft trustanchor-update August 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 at 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 (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.
-
-
-
-
-
-StJohns Expires February 16, 2006 [Page 12]
-
-Internet-Draft trustanchor-update August 2005
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires February 16, 2006 [Page 13]
-
-
--- contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-04.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-Network Working Group S. Woolf
-Internet-Draft Internet Systems Consortium, Inc.
-Expires: September 14, 2005 D. Conrad
- Nominum, Inc.
- March 13, 2005
-
-
- Identifying an Authoritative Name Server
- draft-ietf-dnsop-serverid-04
-
-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 September 14, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- With the increased use of DNS anycast, load balancing, and other
- mechanisms allowing more than one DNS name server to share a single
- IP address, it is sometimes difficult to tell which of a pool of name
- servers has answered a particular query. A standardized mechanism to
- determine the identity of a name server responding to a particular
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 1]
-
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
- query would be useful, particularly as a diagnostic aid. Existing ad
- hoc mechanisms for addressing this concern are not adequate. This
- document attempts to describe the common ad hoc solution to this
- problem, including its advantages and disadvantages, and to
- characterize an improved mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 2]
-
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-1. Introduction
-
- With the increased use of DNS anycast, load balancing, and other
- mechanisms allowing more than one DNS name server to share a single
- IP address, it is sometimes difficult to tell which of a pool of name
- servers has answered a particular query. A standardized mechanism to
- determine the identity of a name server responding to a particular
- query would be useful, particularly as a diagnostic aid.
-
- Unfortunately, existing ad-hoc mechanisms for providing such
- identification have some shortcomings, not the least of which is the
- lack of prior analysis of exactly how such a mechanism should be
- designed and deployed. This document describes the existing
- convention used in one widely deployed implementation of the DNS
- protocol and discusses requirements for an improved solution to the
- problem.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 3]
-
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-2. Rationale
-
- Identifying which name server is responding to queries is often
- useful, particularly in attempting to diagnose name server
- difficulties. However, relying on the IP address of the name server
- has become more problematic due the deployment of various load
- balancing solutions, including the use of shared unicast addresses as
- documented in [RFC3258].
-
- An unfortunate side effect of these load balancing solutions, and
- some changes in management practices as the public Internet has
- evolved, is that traditional methods of determining which server is
- responding can be unreliable. Specifically, non-DNS methods such as
- ICMP ping, TCP connections, or non-DNS UDP packets (such as those
- generated by tools such as "traceroute"), etc., can end up going to a
- different server than that which receives the DNS queries.
-
- There is a well-known and frequently-used technique for determining
- an identity for a nameserver more specific than the
- possibly-non-unique "server that answered my query". The widespread
- use of the existing convention suggests a need for a documented,
- interoperable means of querying the identity of a nameserver that may
- be part of an anycast or load-balancing cluster. At the same time,
- however, it also has some drawbacks that argue against standardizing
- it as it's been practiced so far.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 4]
-
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-3. Existing Conventions
-
- Recent versions of the commonly deployed Berkeley Internet Name
- Domain implementation of the DNS protocol suite from the Internet
- Software Consortium [BIND] support a way of identifying a particular
- server via the use of a standard, if somewhat unusual, DNS query.
- Specifically, a query to a late model BIND server for a TXT resource
- record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will
- return a string that can be configured by the name server
- administrator to provide a unique identifier for the responding
- server (defaulting to the value of a gethostname() call). This
- mechanism, which is an extension of the BIND convention of using
- CHAOS class TXT RR queries to sub-domains of the "BIND." domain for
- version information, has been copied by several name server vendors.
-
- For reference, the other well-known name used by recent versions of
- BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
- query for a TXT RR for this name will return an administratively
- defined string which defaults to the version of the server
- responding. This is, however, not generally implemented by other
- vendors.
-
-3.1 Advantages
-
- There are several valuable attributes to this mechanism, which
- account for its usefulness.
- 1. The "hostname.bind" query response mechanism is within the DNS
- protocol itself. An identification mechanism that relies on the
- DNS protocol is more likely to be successful (although not
- guaranteed) in going to the same machine as a "normal" DNS query.
- 2. Since the identity information is requested and returned within
- the DNS protocol, it doesn't require allowing any other query
- mechanism to the server, such as holes in firewalls for
- otherwise-unallowed ICMP Echo requests. Thus it does not require
- any special exceptions to site security policy.
- 3. It is simple to configure. An administrator can easily turn on
- this feature and control the results of the relevant query.
- 4. It allows the administrator complete control of what information
- is given out in the response, minimizing passive leakage of
- implementation or configuration details. Such details are often
- considered sensitive by infrastructure operators.
-
-3.2 Disadvantages
-
- At the same time, there are some forbidding drawbacks to the
- VERSION.BIND mechanism that argue against standardizing it as it
- currently operates.
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 5]
-
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
- 1. It requires an additional query to correlate between the answer
- to a DNS query under normal conditions and the supposed identity
- of the server receiving the query. There are a number of
- situations in which this simply isn't reliable.
- 2. It reserves an entire class in the DNS (CHAOS) for what amounts
- to one zone. While CHAOS class is defined in [RFC1034] and
- [RFC1035], it's not clear that supporting it solely for this
- purpose is a good use of the namespace or of implementation
- effort.
- 3. It is implementation specific. BIND is one DNS implementation.
- At the time of this writing, it is probably the most prevalent
- for authoritative servers. This does not justify standardizing
- on its ad hoc solution to a problem shared across many operators
- and implementors.
-
- The first of the listed disadvantages is technically the most
- serious. It argues for an attempt to design a good answer to the
- problem that "I need to know what nameserver is answering my
- queries", not simply a convenient one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 6]
-
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-4. Characteristics of an Implementation Neutral Convention
-
- The discussion above of advantages and disadvantages to the
- HOSTNAME.BIND mechanism suggest some requirements for a better
- solution to the server identification problem. These are summarized
- here as guidelines for any effort to provide appropriate protocol
- extensions:
- 1. The mechanism adopted MUST be in-band for the DNS protocol. That
- is, it needs to allow the query for the server's identifying
- information to be part of a normal, operational query. It SHOULD
- also permit a separate, dedicated query for the server's
- identifying information.
- 2. The new mechanism SHOULD not require dedicated namespaces or
- other reserved values outside of the existing protocol mechanisms
- for these, i.e. the OPT pseudo-RR. In particular, it should not
- propagate the existing drawback of requiring support for a CLASS
- and top level domain in the authoritative server (or the querying
- tool) to be useful.
- 3. Support for the identification functionality SHOULD be easy to
- implement and easy to enable. It MUST be easy to disable and
- SHOULD lend itself to access controls on who can query for it.
- 4. It should be possible to return a unique identifier for a server
- without requiring the exposure of information that may be
- non-public and considered sensitive by the operator, such as a
- hostname or unicast IP address maintained for administrative
- purposes.
- 5. The identification mechanism SHOULD NOT be
- implementation-specific.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 7]
-
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-5. IANA Considerations
-
- This document proposes no specific IANA action. Protocol extensions,
- if any, to meet the requirements described are out of scope for this
- document. Should such extensions be specified and adopted by normal
- IETF process, the specification will include appropriate guidance to
- IANA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 8]
-
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-6. Security Considerations
-
- Providing identifying information as to which server is responding to
- a particular query from a particular location in the Internet can be
- seen as information leakage and thus a security risk. This motivates
- the suggestion above that a new mechanism for server identification
- allow the administrator to disable the functionality altogether or
- partially restrict availability of the data. It also suggests that
- the serverid data should not be readily correlated with a hostname or
- unicast IP address that may be considered private to the nameserver
- operator's management infrastructure.
-
- Propagation of protocol or service meta-data can sometimes expose the
- application to denial of service or other attack. As DNS is a
- critically important infrastructure service for the production
- Internet, extra care needs to be taken against this risk for
- designers, implementors, and operators of a new mechanism for server
- identification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 9]
-
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-7. Acknowledgements
-
- The technique for host identification documented here was initially
- implemented by Paul Vixie of the Internet Software Consortium in the
- Berkeley Internet Name Daemon package. Comments and questions on
- earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
- Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
- ICANN Root Server System Advisory Committee. The newest version
- takes a significantly different direction from previous versions,
- owing to discussion among contributors to the DNSOP working group and
- others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam
- Weiler, and Rob Austein.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 10]
-
-Internet-Draft Identifying an Authoritative Name Server March 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 at 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.
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 11]
-
-
--- contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt
+++ /dev/null
@@ -1,2072 +0,0 @@
-
-
-
-Network Working Group B. Laurie
-Internet-Draft G. Sisson
-Expires: December 3, 2005 Nominet
- R. Arends
- Telematica Instituut
- june 2005
-
-
- DNSSEC Hash Authenticated Denial of Existence
- draft-ietf-dnsext-nsec3-02
-
-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 BCP 79.
-
- 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 3, 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.
-
- A complete zone file can be used either directly as a source of
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 1]
-
-Internet-Draft nsec3 june 2005
-
-
- 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 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.
-
-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 . . . . . . . . . . . . . . . . . 7
- 2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 7
- 2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 7
- 2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7
- 2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 8
- 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 9
- 3. Creating Additional NSEC3 RRs for Empty Non Terminals . . . . 9
- 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 10
- 5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 10
- 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 11
- 6.1 Delegation Points . . . . . . . . . . . . . . . . . . . . 11
- 6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11
- 6.2 Proving Nonexistence . . . . . . . . . . . . . . . . . . . 12
- 6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 13
- 6.4.1 Avoiding Hash Collisions during generation . . . . . . 14
- 6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 14
- 6.4.3 Possible Hash Value Truncation Method . . . . . . . . 14
- 7. Performance Considerations . . . . . . . . . . . . . . . . . . 15
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
- 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
- 10.1 Normative References . . . . . . . . . . . . . . . . . . . 16
- 10.2 Informative References . . . . . . . . . . . . . . . . . . 17
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
- A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 18
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 2]
-
-Internet-Draft nsec3 june 2005
-
-
- B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 23
- B.1 answer . . . . . . . . . . . . . . . . . . . . . . . . . . 23
- B.1.1 Authenticating the Example DNSKEY RRset . . . . . . . 25
- B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 26
- B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 28
- B.3.1 No Data Error, Empty Non-Terminal . . . . . . . . . . 29
- B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 30
- B.5 Referral to Unsigned Zone using Opt-In . . . . . . . . . . 31
- B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 32
- B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 34
- B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 35
- Intellectual Property and Copyright Statements . . . . . . . . 37
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 3]
-
-Internet-Draft nsec3 june 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 problem was the requirement that the existence of all record
- types in a zone - including delegation point NS record types - must
- 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 presents
- the NSEC3 Resource Record which mitigates these issues with the NSEC
- RR.
-
- 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 December 3, 2005 [Page 4]
-
-Internet-Draft nsec3 june 2005
-
-
- over the original (unmodified) ownername, this result is referred to
- as "hashed ownername".
-
- "Canonical ordering of the zone" means the order in which hashed
- ownernames are arranged according to their numerical value, treating
- the leftmost (lowest numbered) byte as the most significant byte.
-
-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 4035 [RFC4035]. Unsigned delegation
- point NS RRsets can optionally be excluded. To provide protection
- against zone traversal, the ownernames used in the NSEC3 RR are
- cryptographic hashes of the original ownername prepended to the name
- of the zone. The NSEC3 RR indicates which hash function is used to
- construct the hash, which salt is used, and how many iterations of
- the hash function are performed over the original ownername.
-
- The ownername for the NSEC3 RR is the base32 encoding of the hashed
- 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:
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 5]
-
-Internet-Draft nsec3 june 2005
-
-
- 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 /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-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 RRset 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 behaviour is identical to NSEC behaviour.
-
-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.
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 6]
-
-Internet-Draft nsec3 june 2005
-
-
-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.
-
- The Salt field is prepended to the original ownername before hashing
- in order to defend against precalculated dictionary attacks.
-
- The salt is also prepended during iterations of the hash function.
-
- Note that although it is theoretically possible to cover the entire
- possible ownername space with different salt values, it is
- computationally infeasible to do so, and so there MUST be at least
- one salt which is the same for all NSEC3 records. This means that no
- matter what name is asked for in a query, it is guaranteed to be
- possible to find a covering NSEC3 record. Note that this does not
- preclude the use of two different salts at the same time - indeed
- this may well occur naturally, due to rolling the salt value
- periodically.
-
- The salt value SHOULD be changed from time to time - this is to
- prevent the use of a precomputed dictionary to reduce the cost of
- enumeration.
-
-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.
-
- Hashed ownernames of RRsets not authoritative for the given zone
- (such as glue records) MUST NOT be listed in the Next Hashed
- Ownername unless at least one authoritative RRset exists at the same
- ownername.
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 7]
-
-Internet-Draft nsec3 june 2005
-
-
- Note that the Next Hashed Ownername field is not encoded, unlike the
- NSEC3 RR's ownername. It is the unmodified binary hash value.
-
-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 bits for the NSEC3 RR and RRSIG RR 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 ) +
-
- 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
- [RFC2929] (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
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 8]
-
-Internet-Draft nsec3 june 2005
-
-
- 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 interpreted 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.
- The Salt Field is represented as 00 when the Salt Length field has
- value 0.
-
- The Next Hashed Ownername 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 [RFC3597] (section 5) MUST be
- used.
-
-3. Creating Additional NSEC3 RRs for Empty Non Terminals
-
- 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.
-
- Additional NSEC3 RRs are synthesized which 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
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 9]
-
-Internet-Draft nsec3 june 2005
-
-
- an NSEC3 RR type and an RRSIG RR 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. Including NSEC3 RRs in a Zone
-
- Each owner name in the zone which has authoritative data or a secured
- 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 RR type itself and its
- corresponding RRSIG RR type.
-
- 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
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 10]
-
-Internet-Draft nsec3 june 2005
-
-
- records.
- 1. For each unique original owner name in the zone, add an NSEC3
- RRset. This includes NSEC3 RRsets for unsigned delegation point
- NS RRsets, unless the policy is to have Authoritative Only NSEC3
- RRsets. The ownername of the NSEC3 RR is the hashed equivalent
- of the original owner name, prepended to the zone name.
- 2. For each RRset at the original owner, set the corresponding bit
- in the type bit map.
- 3. If the difference in number of labels between the apex and the
- original ownername is greater then 1, additional NSEC3s need to
- be added for every empty non-terminal between the apex and the
- original ownername.
- 4. Sort the set of NSEC3 RRs.
- 5. In each NSEC3 RR, insert the Next Hashed Ownername. The Next
- Hashed Ownername of the last NSEC3 in the zone contains the value
- of the hashed ownername of the first NSEC3 in the zone.
- 6. If the policy is to have authoritative only, set the
- Authoritative Only bit in those NSEC3 RRs that cover unsecured
- delegation points.
-
-6. Special Considerations
-
- The following paragraphs clarify specific behaviour explain special
- considerations for implementations.
-
-6.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 behaviour when the flag value is
- 1.
-
-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
- 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
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 11]
-
-Internet-Draft nsec3 june 2005
-
-
- the Authoritative Only Flag set to 1 can not be used to prove the
- presence or the absence of 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 to sign all
- delegations, regardless of whether the delegated zone is signed or
- not.
-
- A second attack vector exists in that an adversary is able to
- successfully fabricate an (unsigned) response claiming a nonexistent
- delegation exists.
-
- The only possible mitigation is to mandate the signing of all
- delegations.
-
-6.2 Proving Nonexistence
-
- If a wildcard resource record appears in a zone, its asterisk 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 4035
- [RFC4035] describes the impact of wildcards on authenticated denial
- of existence.
-
- In order to prove there exist no RRs for a domain, as well as no
- source of synthesis, an RR must be shown for the closest encloser,
- and non-existence must be shown for all closer labels and for the
- wildcard at the closest encloser.
-
- This can be done as follows. If the QNAME in the query is
- omega.alfa.beta.example, and the closest encloser is beta.example
- (the nearest ancestor to omega.alfa.beta.example), then the server
- should return an NSEC3 that demonstrates the nonexistence of
- alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
- *.beta.example, and an NSEC3 that demonstrates the existence of
- beta.example. This takes between one and three NSEC3 records, since
- a single record can, by chance, prove more than one of these facts.
-
- When a verifier checks this response, then the existence of
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 12]
-
-Internet-Draft nsec3 june 2005
-
-
- beta.example together with the non-existence of alfa.beta.example
- proves that the closest encloser is indeed beta.example. The non-
- existence of *.beta.example shows that there is no wildcard at the
- closest encloser, and so no source of synthesis for
- omega.alfa.beta.example. These two facts are sufficient to satisfy
- the resolver that the QNAME cannot be resolved.
-
- In practice, since the NSEC3 owner and next names are hashed, if the
- server responds with an NSEC3 for beta.example, the resolver will
- have to try successively longer names, starting with example, moving
- to beta.example, alfa.beta.example, and so on, until one of them
- hashes to a value that matches the interval (but not the ownername
- nor next owner name) of one of the returned NSEC3s (this name will be
- alfa.beta.example). Once it has done this, it knows the closest
- encloser (i.e. beta.example), and can then easily check the other two
- required proofs.
-
- Note that it is not possible for one of the shorter names tried by
- the resolver to be denied by one of the returned NSEC3s, since, by
- definition, all these names exist and so cannot appear within the
- range covered by an NSEC3. Note, however, that the first name that
- the resolver tries MUST be the apex of the zone, since names above
- the apex could be denied by one of the returned NSEC3s.
-
-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
- salt, the cost of the dictionary doubles. The NSEC3 RR can use a
- maximum of 2040 bits of salt, multiplying the cost by 2^2040.
-
- There MUST be a complete set of NSEC3s for the zone using the same
- salt value. The salt value for each NSEC3 RR MUST be equal for a
- single version of the zone.
-
- The salt SHOULD be changed every time the zone is resigned to prevent
- precomputation using a single salt.
-
-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
- chance of a single collision is about 2^(n/2) for a hash of length n
- bits (i.e. 2^80 for SHA-1). 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.
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 13]
-
-Internet-Draft nsec3 june 2005
-
-
-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 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.
-
-6.4.2 Second Preimage Requirement Analysis
-
- A cryptographic 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
- preimage X' <> X such that hash(X) = hash(X'). The work factor for
- finding a second preimage is of the order of 2^160 for SHA-1. 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.
-
-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
- 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.
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 14]
-
-Internet-Draft nsec3 june 2005
-
-
- 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. Of
- course, the size of the corresponding RRSIG RR is not reduced, so
- truncation is of limited benefit.
-
- Truncation could be signalled simply by reducing the length of the
- first label in the ownername. Note that there would have to be a
- corresponding reduction in the length of the Next Hashed Ownername
- field.
-
-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. In particular it should be
- noted that a high value for iterations gives an attacker a very good
- denial of service attack, since the attacker need not bother to
- verify the results of their queries, and hence has no performance
- penalty of his own.
-
- On the other hand, nameservers with low query rates and limited
- bandwidth are already subject to a bandwidth based denial of service
- attack, since responses are typically an order of magnitude larger
- than queries, and hence these servers may choose a high value of
- iterations in order to increase the difficulty of offline attempts to
- enumerate their namespace without significantly increasing their
- vulnerability to denial of service attacks.
-
-8. IANA Considerations
-
- IANA has to create a new registry for NSEC3 Hash Functions. The
- range for this registry is 0-127. Value 0 is the identity function.
- Value 1 is SHA-1. Values 2-126 are Reserved For Future Use. Value
- 127 is marked as Experimental.
-
-9. 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, though this would obviously be more detectable.
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 15]
-
-Internet-Draft nsec3 june 2005
-
-
- The expense of this off-line attack can be chosen by setting the
- number of 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 non-existence of the colliding domain - however, this is
- fantastically unlikely, and, in any case, DNSSEC already relies on
- SHA-1 to not collide.
-
-10. References
-
-10.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
- 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.
-
- [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning,
- "Domain Name System (DNS) IANA Considerations", BCP 42,
- RFC 2929, September 2000.
-
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
- (RR) Types", RFC 3597, September 2003.
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 16]
-
-Internet-Draft nsec3 june 2005
-
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
-10.2 Informative References
-
- [I-D.ietf-dnsext-trustupdate-threshold]
- Ihren, J., "An In-Band Rollover Mechanism and an Out-Of-
- Band Priming Method for DNSSEC Trust Anchors.",
- draft-ietf-dnsext-trustupdate-threshold-00 (work in
- progress), October 2004.
-
- [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.
-
-
-Authors' Addresses
-
- Ben Laurie
- Nominet
- 17 Perryn Road
- London W3 7LR
- England
-
- Phone: +44 (20) 8735 0686
- Email: ben at algroup.co.uk
-
-
- Geoffrey Sisson
- Nominet
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 17]
-
-Internet-Draft nsec3 june 2005
-
-
- Roy Arends
- Telematica Instituut
- Brouwerijstraat 1
- 7523 XC Enschede
- The Netherlands
-
- Phone: +31 (53) 485 0485
- Email: roy.arends at telin.nl
-
-Appendix A. Example Zone
-
- This is a zone showing its NSEC3 records. They can also be used as
- test vectors for the hash algorithm.
-
-
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600 )
- 3600 RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- 3600 NS ns1.example.
- 3600 NS ns2.example.
- 3600 RRSIG NS 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
- m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
- 1SH5r/wfjuCg+g== )
- 3600 MX 1 xx.example.
- 3600 RRSIG MX 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
- NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU
- S/o/g5C8VM6ftQ== )
- 3600 DNSKEY 257 3 5 (
- AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX
- cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1
- zsYKWJ7BvR2894hX
- ) ; Key ID = 21960
- 3600 DNSKEY 256 3 5 (
- AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
- 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
- ExXT48OGGdbfIme5
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 18]
-
-Internet-Draft nsec3 june 2005
-
-
- ) ; Key ID = 62699
- 3600 RRSIG DNSKEY 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z
- xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx
- mTkunTYzqWJrmQ== )
- 3600 RRSIG DNSKEY 5 1 3600 20050712112304 (
- 20050612112304 21960 example.
- SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk
- ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik
- 3w7ZY2UWyYIvpw== )
- 5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- 7nomf47k3vlidh4vxahhpp47l3tgv7a2
- NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5
- Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ
- sb7KfbaUo/vzAg== )
- 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
- MX NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
- ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
- MEFQmc/gEuxojA== )
- a.example. 3600 IN NS ns1.a.example.
- 3600 IN NS ns2.a.example.
- 3600 DS 58470 5 1 3079F1593EBAD6DC121E202A8B
- 766A6A4837206C )
- 3600 RRSIG DS 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
- cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
- 0kx7rGKTc3RQDA== )
- ns1.a.example. 3600 IN A 192.0.2.5
- ns2.a.example. 3600 IN A 192.0.2.6
- ai.example. 3600 IN A 192.0.2.9
- 3600 RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
- 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
- ZXW5S+1VjMZYzQ== )
- 3600 HINFO "KLH-10" "ITS"
- 3600 RRSIG HINFO 5 2 3600 20050712112304 (
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 19]
-
-Internet-Draft nsec3 june 2005
-
-
- 20050612112304 62699 example.
- AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk
- tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg
- VGNmbgPnqDVPiA== )
- 3600 AAAA 2001:db8:0:0:0:0:f00:baa9
- 3600 RRSIG AAAA 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
- ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
- l5/UqLCJJ9BDMg== )
- b.example. 3600 IN NS ns1.b.example.
- 3600 IN NS ns2.b.example.
- ns1.b.example. 3600 IN A 192.0.2.7
- ns2.b.example. 3600 IN A 192.0.2.8
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- gmnfcccja7wkax3iv26bs75myptje3qk
- MX DNSKEY NS SOA NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
- C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
- MOiKMSHozVebqw== )
- gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- jt4bbfokgbmr57qx4nqucvvn7fmo6ab6
- DS NS NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/
- ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW
- OwQBGbOegrW/Zw== )
- jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- kcll7fqfnisuhfekckeeqnmbbd4maanu
- NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
- IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
- 94Zbq3k8lgdpZA== )
- kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3 1 1 1 (
- deadbeaf
- n42hbhnjj333xdxeybycax5ufvntux5d
- MX NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 20]
-
-Internet-Draft nsec3 june 2005
-
-
- IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
- TOLtc5jPrkL4zQ== )
- n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- nimwfwcnbeoodmsc6npv3vuaagaevxxu
- A NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy
- 91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj
- xFPFGRIW3wKnrA== )
- nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- vhgwr2qgykdkf4m6iv6vkagbxozphazr
- HINFO A AAAA NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
- z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
- jL33Wm1p07TBdw== )
- ns1.example. 3600 A 192.0.2.1
- 3600 RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
- BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
- nWWLepz1PjjShQ== )
- ns2.example. 3600 A 192.0.2.2
- 3600 RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
- P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
- AkeTJu3J3auUiA== )
- vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- wbyijvpnyj33pcpi3i44ecnibnaj7eiw
- HINFO A AAAA NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W
- kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M
- 5SNSHIyfpfsi6A== )
- *.w.example. 3600 MX 1 ai.example.
- 3600 RRSIG MX 5 3 3600 20050712112304 (
- 20050612112304 62699 example.
- sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
- xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
- gQlgxEwhvQDEaQ== )
- x.w.example. 3600 MX 1 xx.example.
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 21]
-
-Internet-Draft nsec3 june 2005
-
-
- 3600 RRSIG MX 5 3 3600 20050712112304 (
- 20050612112304 62699 example.
- s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
- lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
- U9VazOa1KEIq1w== )
- x.y.w.example. 3600 MX 1 xx.example.
- 3600 RRSIG MX 5 4 3600 20050712112304 (
- 20050612112304 62699 example.
- aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7
- uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF
- 9VrQvJjwbllAfA== )
- wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
- A NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
- ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
- oorBv4xkb0flXw== )
- xx.example. 3600 A 192.0.2.10
- 3600 RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
- tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
- cxwCXWj82GVGdw== )
- 3600 HINFO "KLH-10" "TOPS-20"
- 3600 RRSIG HINFO 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q
- OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk
- KMf4DgNBDj+dIQ== )
- 3600 AAAA 2001:db8:0:0:0:0:f00:baaa
- 3600 RRSIG AAAA 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
- w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
- rzKKwb8J04/ILw== )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
- MX NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
- 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
- OcFlrPGPMm48/A== )
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 22]
-
-Internet-Draft nsec3 june 2005
-
-
-Appendix B. Example Responses
-
- The examples in this section show response messages using the signed
- zone example in Appendix A.
-
-B.1 answer
-
- A successful query to an authoritative server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 23]
-
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- x.w.example. IN MX
-
- ;; Answer
- x.w.example. 3600 IN MX 1 xx.example.
- x.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
- 20050612112304 62699 example.
- s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
- lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
- U9VazOa1KEIq1w== )
-
- ;; Authority
- example. 3600 IN NS ns1.example.
- example. 3600 IN NS ns2.example.
- example. 3600 IN RRSIG NS 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
- m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
- 1SH5r/wfjuCg+g== )
-
- ;; Additional
- xx.example. 3600 IN A 192.0.2.10
- xx.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
- tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
- cxwCXWj82GVGdw== )
- xx.example. 3600 IN AAAA 2001:db8::f00:baaa
- xx.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
- w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
- rzKKwb8J04/ILw== )
- ns1.example. 3600 IN A 192.0.2.1
- ns1.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
- BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
- nWWLepz1PjjShQ== )
- ns2.example. 3600 IN A 192.0.2.2
- ns2.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
- P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
- AkeTJu3J3auUiA== )
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 24]
-
-Internet-Draft nsec3 june 2005
-
-
- The query returned an MX RRset for "x.w.example". The corresponding
- RRSIG RR indicates that the MX RRset was signed by an "example"
- DNSKEY with algorithm 5 and key tag 62699. The resolver needs the
- corresponding DNSKEY RR in order to authenticate this answer. The
- discussion below describes how a resolver might obtain this DNSKEY
- RR.
-
- The RRSIG RR indicates the original TTL of the MX RRset was 3600,
- and, for the purpose of authentication, the current TTL is replaced
- by 3600. The RRSIG RR's labels field value of 3 indicates that the
- answer was not the result of wildcard expansion. The "x.w.example"
- MX RRset is placed in canonical form, and, assuming the current time
- falls between the signature inception and expiration dates, the
- signature is authenticated.
-
-B.1.1 Authenticating the Example DNSKEY RRset
-
- This example shows the logical authentication process that starts
- from a configured root DNSKEY RRset (or DS RRset) and moves down the
- tree to authenticate the desired "example" DNSKEY RRset. Note that
- the logical order is presented for clarity. An implementation may
- choose to construct the authentication as referrals are received or
- to construct the authentication chain only after all RRsets have been
- obtained, or in any other combination it sees fit. The example here
- demonstrates only the logical process and does not dictate any
- implementation rules.
-
- We assume the resolver starts with a configured DNSKEY RRset for the
- root zone (or a configured DS RRset for the root zone). The resolver
- checks whether this configured DNSKEY RRset is present in the root
- DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY
- RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the
- root DNSKEY RRset, and whether the signature lifetime is valid. If
- all these conditions are met, all keys in the DNSKEY RRset are
- considered authenticated. The resolver then uses one (or more) of
- the root DNSKEY RRs to authenticate the "example" DS RRset. Note
- that the resolver may have to query the root zone to obtain the root
- DNSKEY RRset or "example" DS RRset.
-
- Once the DS RRset has been authenticated using the root DNSKEY, the
- resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
- RR that matches one of the authenticated "example" DS RRs. If such a
- matching "example" DNSKEY is found, the resolver checks whether this
- DNSKEY RR has signed the "example" DNSKEY RRset and the signature
- lifetime is valid. If these conditions are met, all keys in the
- "example" DNSKEY RRset are considered authenticated.
-
- Finally, the resolver checks that some DNSKEY RR in the "example"
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 25]
-
-Internet-Draft nsec3 june 2005
-
-
- DNSKEY RRset uses algorithm 5 and has a key tag of 62699. This
- DNSKEY is used to authenticate the RRSIG included in the response.
- If multiple "example" DNSKEY RRs match this algorithm and key tag,
- then each DNSKEY RR is tried, and the answer is authenticated if any
- of the matching DNSKEY RRs validate the signature as described above.
-
-B.2 Name Error
-
- An authoritative name error. The NSEC3 RRs prove that the name does
- not exist and that no covering wildcard exists.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 26]
-
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=3
- ;;
- ;; Question
- a.c.x.w.example. IN A
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
- MX NSEC3 RRSIG )
- 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
- ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
- MEFQmc/gEuxojA== )
- nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- vhgwr2qgykdkf4m6iv6vkagbxozphazr
- HINFO A AAAA NSEC3 RRSIG )
- nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
- z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
- jL33Wm1p07TBdw== )
- ;; Additional
- ;; (empty)
-
- The query returned two NSEC3 RRs that prove that the requested data
- does not exist and no wildcard applies. The negative reply is
- authenticated by verifying both NSEC3 RRs. The NSEC3 RRs are
- authenticated in a manner identical to that of the MX RRset discussed
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 27]
-
-Internet-Draft nsec3 june 2005
-
-
- above. At least one of the owner names of the NSEC3 RRs will match
- the closest encloser. At least one of the NSEC3 RRs prove that there
- exists no longer name. At least one of the NSEC3 RRs prove that
- there exists no wildcard RRsets that should have been expanded. The
- closest encloser can be found by hasing the apex ownername (The SOA
- RR's ownername, or the ownername of the DNSKEY RRset referred by an
- RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and
- if that fails, continue by adding labels.
-
- In the above example, the name 'x.w.example' hashes to
- '7nomf47k3vlidh4vxahhpp47l3tgv7a2'. This indicates that this might
- be the closest encloser. To prove that 'c.x.w.example' and
- '*.x.w.example' do not exists, these names are hashed to respectively
- 'qsgoxsf2lanysajhtmaylde4tqwnqppl' and
- 'cvljzyf6nsckjowghch4tt3nohocpdka'. The two NSEC3 records prove that
- these hashed ownernames do not exists, since the names are within the
- given intervals.
-
-B.3 No Data Error
-
- A "no data" response. The NSEC3 RR proves that the name exists and
- that the requested RR type does not.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 28]
-
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- ns1.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
- A NSEC3 RRSIG )
- wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
- ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
- oorBv4xkb0flXw== )
- ;; Additional
- ;; (empty)
-
- The query returned an NSEC3 RR that proves that the requested name
- exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"),
- but the requested RR type does not exist (type MX is absent in the
- type code list of the NSEC RR). The negative reply is authenticated
- by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner
- identical to that of the MX RRset discussed above.
-
-B.3.1 No Data Error, Empty Non-Terminal
-
- A "no data" response because of an empty non-terminal. The NSEC3 RR
- proves that the name exists and that the requested RR type does not.
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 29]
-
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- y.w.example. IN A
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- kcll7fqfnisuhfekckeeqnmbbd4maanu
- NSEC3 RRSIG )
- jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
- IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
- 94Zbq3k8lgdpZA== )
-
- The query returned an NSEC3 RR that proves that the requested name
- exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"),
- but the requested RR type does not exist (Type A is absent in the
- type-bit-maps of the NSEC3 RR). The negative reply is authenticated
- by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner
- identical to that of the MX RRset discussed above. Note that, unlike
- generic empty non terminal proof using NSECs, this is identical to
- proving a No Data Error. This example is solely mentioned to be
- complete.
-
-B.4 Referral to Signed Zone
-
- Referral to a signed zone. The DS RR contains the data which the
- resolver will need to validate the corresponding DNSKEY RR in the
- child zone's apex.
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 30]
-
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR DO RCODE=0
- ;;
-
- ;; Question
- mc.a.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- a.example. 3600 IN NS ns1.a.example.
- a.example. 3600 IN NS ns2.a.example.
- a.example. 3600 IN DS 58470 5 1 (
- 3079F1593EBAD6DC121E202A8B766A6A4837
- 206C )
- a.example. 3600 IN RRSIG DS 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
- cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
- 0kx7rGKTc3RQDA== )
-
- ;; Additional
- ns1.a.example. 3600 IN A 192.0.2.5
- ns2.a.example. 3600 IN A 192.0.2.6
-
- The query returned a referral to the signed "a.example." zone. The
- DS RR is authenticated in a manner identical to that of the MX RRset
- discussed above. This DS RR is used to authenticate the "a.example"
- DNSKEY RRset.
-
- Once the "a.example" DS RRset has been authenticated using the
- "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
- for some "a.example" DNSKEY RR that matches the DS RR. If such a
- matching "a.example" DNSKEY is found, the resolver checks whether
- this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
- the signature lifetime is valid. If all these conditions are met,
- all keys in the "a.example" DNSKEY RRset are considered
- authenticated.
-
-B.5 Referral to Unsigned Zone using Opt-In
-
- Referral to an unsigned zone using Opt-In. The NSEC3 RR proves that
- nothing for this delegation was signed in the parent zone. There is
- no proof that the delegation exists
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 31]
-
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR DO RCODE=0
- ;;
- ;; Question
- mc.b.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- b.example. 3600 IN NS ns1.b.example.
- b.example. 3600 IN NS ns2.b.example.
- kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3 1 1 1 (
- deadbeaf
- n42hbhnjj333xdxeybycax5ufvntux5d
- MX NSEC3 RRSIG )
- kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
- IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
- TOLtc5jPrkL4zQ== )
-
- ;; Additional
- ns1.b.example. 3600 IN A 192.0.2.7
- ns2.b.example. 3600 IN A 192.0.2.8
-
- The query returned a referral to the unsigned "b.example." zone. The
- NSEC3 proves that no authentication leads from "example" to
- "b.example", since the hash of "b.example"
- ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and
- the NSEC3 opt-in bit is set. The NSEC3 RR is authenticated in a
- manner identical to that of the MX RRset discussed above.
-
-B.6 Wildcard Expansion
-
- A successful query that was answered via wildcard expansion. The
- label count in the answer's RRSIG RR indicates that a wildcard RRset
- was expanded to produce this response, and the NSEC3 RR proves that
- no closer match exists in the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 32]
-
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN MX
-
- ;; Answer
- a.z.w.example. 3600 IN MX 1 ai.example.
- a.z.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
- 20050612112304 62699 example.
- sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
- xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
- gQlgxEwhvQDEaQ== )
- ;; Authority
- example. 3600 NS ns1.example.
- example. 3600 NS ns2.example.
- example. 3600 IN RRSIG NS 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
- m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
- 1SH5r/wfjuCg+g== )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
- MX NSEC3 RRSIG )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
- 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
- OcFlrPGPMm48/A== )
- ;; Additional
- ai.example. 3600 IN A 192.0.2.9
- ai.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
- 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
- ZXW5S+1VjMZYzQ== )
- ai.example. 3600 AAAA 2001:db8::f00:baa9
- ai.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
- ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
- l5/UqLCJJ9BDMg== )
-
- The query returned an answer that was produced as a result of
- wildcard expansion. The answer section contains a wildcard RRset
- expanded as it would be in a traditional DNS response, and the
- corresponding RRSIG indicates that the expanded wildcard MX RRset was
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 33]
-
-Internet-Draft nsec3 june 2005
-
-
- signed by an "example" DNSKEY with algorithm 5 and key tag 62699.
- The RRSIG indicates that the original TTL of the MX RRset was 3600,
- and, for the purpose of authentication, the current TTL is replaced
- by 3600. The RRSIG labels field value of 2 indicates that the answer
- is the result of wildcard expansion, as the "a.z.w.example" name
- contains 4 labels. The name "a.z.w.example" is replaced by
- "*.w.example", the MX RRset is placed in canonical form, and,
- assuming that the current time falls between the signature inception
- and expiration dates, the signature is authenticated.
-
- The NSEC3 proves that no closer match (exact or closer wildcard)
- could have been used to answer this query, and the NSEC3 RR must also
- be authenticated before the answer is considered valid.
-
-B.7 Wildcard No Data Error
-
- A "no data" response for a name covered by a wildcard. The NSEC3 RRs
- prove that the matching wildcard name does not have any RRs of the
- requested type and that no closer match exists in the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 34]
-
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN AAAA
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
- MX NSEC3 RRSIG )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
- 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
- OcFlrPGPMm48/A== )
- ;; Additional
- ;; (empty)
-
- The query returned NSEC3 RRs that prove that the requested data does
- not exist and no wildcard applies. The negative reply is
- authenticated by verifying both NSEC3 RRs.
-
-B.8 DS Child Zone No Data Error
-
- A "no data" response for a QTYPE=DS query that was mistakenly sent to
- a name server for the child zone.
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 35]
-
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- example. IN DS
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- gmnfcccja7wkax3iv26bs75myptje3qk
- MX DNSKEY NS SOA NSEC3 RRSIG )
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
- C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
- MOiKMSHozVebqw== )
-
- ;; Additional
- ;; (empty)
-
- The query returned NSEC RRs that shows the requested was answered by
- a child server ("example" server). The NSEC RR indicates the
- presence of an SOA RR, showing that the answer is from the child .
- Queries for the "example" DS RRset should be sent to the parent
- servers ("root" servers).
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 36]
-
-Internet-Draft nsec3 june 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 at 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 December 3, 2005 [Page 37]
-
--- contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt
+++ /dev/null
@@ -1,956 +0,0 @@
-DNSEXT Working Group E. Lewis
-INTERNET DRAFT NeuStar
-Expiration Date: January 6, 2006 July 6, 2005
-Updates RFC 1034, RFC 2672
-
- The Role of Wildcards
- in the Domain Name System
- draft-ietf-dnsext-wcard-clarify-08.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
- BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet-Drafts
- as reference material or to cite them other than as "work in
- progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- This Internet-Draft will expire on January 6, 2006.
-
-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.
-
-Table of Contents
-
-1. Introduction
-1.1 Motivation
-1.2 The Original Definition
-1.3 Roadmap to This Document
-1.3.1 New Terms
-1.3.2 Changed Text
-1.3.3 Considerations with Special Types
-1.4 Standards Terminology
-2. Wildcard Syntax
-2.1 Identifying a Wildcard
-2.1.1 Wild Card Domain Name and Asterisk Label
-2.1.2 Asterisks and Other Characters
-2.1.3 Non-terminal Wild Card Domain Names
-2.2 Existence Rules
-2.2.1 An Example
-2.2.2 Empty Non-terminals
-2.2.3 Yet Another Definition of Existence
-2.3 When is a Wild Card Domain Name Not Special
-3. Impact of a Wild Card Domain Name On a Response
-3.1 Step 2
-3.2 Step 3
-3.3 Part 'c'
-3.3.1 Closest Encloser and the Source of Synthesis
-3.3.2 Closest Encloser and Source of Synthesis Examples
-3.3.3 Type Matching
-4. Considerations with Special Types
-4.1 SOA RRSet at a Wild Card Domain Name
-4.2 NS RRSet at a Wild Card Domain Name
-4.2.1 Discarded Notions
-4.3 CNAME RRSet at a Wild Card Domain Name
-4.4 DNAME RRSet at a Wild Card Domain Name
-4.5 SRV RRSet at a Wild Card Domain Name
-4.6 DS RRSet at a Wild Card Domain Name
-4.7 NSEC RRSet at a Wild Card Domain Name
-4.8 RRSIG at a Wild Card Domain Name
-4.9 Empty Non-terminal Wild Card Domain Name
-5. Security Considerations
-6. IANA Considerations
-7. References
-8. Editor
-9. Others Contributing to the Document
-10. Trailing Boilerplate
-
-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 is given to minimize any backwards
- compatibility issues with implementations that comply with RFC
- 1034's definition.
-
- This document is focused on the concept of wildcards as defined
- in RFC 1034. Nothing is implied regarding alternative means of
- synthesizing resource record sets, nor are alternatives discussed.
-
-1.1 Motivation
-
- Many DNS implementations diverge, in different ways, from the
- original definition of wildcards. 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 [RFC4033]. With an unclear definition of
- wildcards the design of authenticated denial became entangled.
-
- This document is intended to limit its changes, documenting only
- those based on implementation experience, and to remain as close
- to the original document as possible. To reinforce that this
- document is meant to clarify and adjust and not redefine wildcards,
- relevant sections of RFC 1034 are repeated verbatim to facilitate
- comparison of the old and new text.
-
-1.2 The Original Definition
-
- The defintion of the wildcard concept is comprised by the
- documentation of 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).
-
- This is 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 follows 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 relevant portion of the "Algorithm."
-
-# c. If at some label, a match is impossible (i.e., the
-# corresponding label does not exist), look to see if [...]
-# 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 Roadmap to This Document
-
- This document accomplishes these three items.
- o Defines new terms
- o Makes minor changes to avoid conflicting concepts
- o Describes 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 new terms are used to make discussions of wildcards clearer.
- Terminology doesn't directly have an impact on implementations.
-
-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
- RFC 1034 contained no specification on when and how to enforce the
- restriction.
-
-1.3.3 Considerations with Special Types
-
- This document describes semantics of wildcard RRSets for
- "interesting" types as well as empty non-terminal wildcards.
- Understanding these situations 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. References to section "4.3.2" are assumed to refer
- to RFC 1034's section 4.3.2, simply titled "Algorithm."
-
-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] just as non-wildcard resource records are.
- 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 so these labels 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 "*.<anydomain>", where <anydomain> is any domain name.
-# <anydomain> should not contain other * labels......................
-
- The restriction is now removed. The original documentation of it
- is incomplete and the restriction does not serve any purpose given
- years of operational experience.
-
- There are three possible reasons for putting the restriction in
- place, but none of the three has held up over time. One is
- that the restriction meant that there would never be subdomains
- of wild card domain names, but the restriciton as stated still
- permits "example.*.example." for instance. Another is that
- wild card domain names are not intended to be empty non-terminals,
- but this situation does not disrupt the algorithm in 4.3.2.
- Finally, "nested" wild card domain names are not ambiguous once
- the concept of the closest encloser had been documented.
-
- 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
-
- "Existence" is therefore an important concept in the understanding
- of wildcards. Unfortunately, the definition of what exists, in RFC
- 1034, is unlcear. So, in sections 2.2.2. and 2.2.3, another look is
- taken at the definition of existence.
-
-2.2.1 An Example
-
- To illustrate what is meant by existence consider this complete
- zone:
-
- $ORIGIN example.
- example. 3600 IN SOA <SOA RDATA>
- 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 <SRV RDATA>
- _ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
- 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 responses would be synthesized from one of the
- wildcards in the zone:
-
- 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 responses would not be synthesized from any of the
- wildcards in the zone:
-
- QNAME=host1.example., QTYPE=MX, QCLASS=IN
- because host1.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)
-
- QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
- because *.example. exists
-
- The final example highlights one common misconception about
- wildcards. A wildcard "blocks itself" in the sense that a
- wildcard does not match its own subdomains. I.e. "*.example."
- does not match all names in the "example." zone, it fails to
- match the names below "*.example." To cover names under
- "*.example.", another wild card domain name is needed -
- "*.*.example." - which covers all but it's own subdomains.
-
-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, so this apparently
- is not the intent of the original definition, justifying the
- need for an updated definition in the next section.
-
-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 one RRSet. A node may exist with no
- RRSets only if it has descendents that do, this node is an empty
- non-terminal.
-
- 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. In the delegating zone, 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 is a Wild Card Domain Name 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 matches a single, corresponding 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
-
- RFC 1034's description of how wildcards impact response
- generation is in its 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 wildcard.
-
- The algorithm in 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 suggested means of implementing the
- requirements. As such, in step 3, parts a, b, and c, do not have
- to be implemented in that order, provided that the result of the
- implemented code is compliant with the protocol's specification.
-
-3.1 Step 2
-
- Step 2 of the 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.
-
-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 [...]
-# the "*" label exists.
-
- To help describe the process of looking 'to see if [...] the "*"
- label exists' a term has been coined to describe the last domain
- (node) 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 to be 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:
- <asterisk label>.<closest encloser>.
- 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 has been made.
-
- The change is to add the following text to step 'c' prior to the
- instructions to "go to step 6":
-
- 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 <SOA RDATA>
- 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 section'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
-
- With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
- in place, the semantics of a wild card domain name owning an
- NS RRSet has come to be poorly defined. The dilemma relates to
- a conflict between the rules for synthesis in part 'c' and the
- fact that the resulting synthesis generates a record for which
- the zone is not authoritative. In a DNSSEC signed zone, the
- mechanics of signature management (generation and inclusion
- in a message) become unclear.
-
- After some lengthy discussions, there has been no clear "best
- answer" on how to document the semantics of such a situation.
- Barring such records from the DNS would require definition of
- rules for that, as well as introducing a restriction on records
- that were once legal. Allowing such records and amending the
- process of signature management would entail complicating the
- DNSSEC definition.
-
- There is one more ingredient to the discussion, that being the
- utility of a wild card domain name owned NS RRSet. Although
- there are cases of this use, it is an operational rarity.
- Expending effort to close this topic has proven to be an
- exercise in diminishing returns.
-
- In summary, there is no definition given for wild card domain
- names owning an NS RRSet. The semantics are left undefined until
- there is a clear need to have a set defined, and until there is
- a clear direction to proceed. Operationally, inclusion of wild
- card NS RRSets in a zone is discouraged, but not barred.
-
-4.2.1 Discarded Notions
-
- Prior to DNSSEC, a wild card domain name owning a NS RRSet
- appeared to be workable, and there are some instances in which
- it is found in deployments using implementations that support
- this. Continuing to allow this in the specificaion is not
- tenable with DNSSEC. The reason is that the synthesis of the
- NS RRSet is being done in a zone that has delegated away the
- responsibility for the name. This "unauthorized" synthesis is
- not a problem for the base DNS protocol, but DNSSEC, in affirming
- the authorization model for DNS exposes the problem.
-
- Outright banning of wildcards of type NS is also untenable as
- the DNS protocol does not define how to handle "illegal" data.
- Implementations may choose not to load a zone, but there is no
- protocol definition. The lack of the definition is complicated
- by having to cover dynamic update [RFC 2136], zone transfers,
- as well as loading at the master server. The case of a client
- (resolver, cacheing server) getting a wildcard of type NS in
- a reply would also have to be considered.
-
- Given the daunting challenge of a complete definition of how to
- ban such records, dealing with existing implementations that
- permit the records today is a further complication. There are
- uses of wild card domain name owning NS RRSets.
-
- One compromise proposed would have redefined wildcards of type
- NS to not be used in synthesis, this compromise fell apart
- because it would have required significant edits to the DNSSEC
- signing and validation work. (Again, DNSSEC catches
- unauthorized data.)
-
- With no clear consensus forming on the solution to this dilemma,
- and the realization that wildcards of type NS are a rarity in
- operations, the best course of action is to leave this open-ended
- until "it matters."
-
-4.3 CNAME RRSet at a Wild Card Domain Name
-
- The issue of a CNAME RRSet owned by a wild card domain name 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
-
- Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
- represents a threat to the coherency of the DNS and is to be
- avoided or outright rejected. Such a DNAME RRSet represents
- non-deterministic synthesis of rules fed to different caches.
- As caches are fed the different rules (in an unpredictable
- manner) the caches will cease to be coherent. ("As caches
- are fed" refers to the storage in a cache of records obtained
- in responses by recursive or iterative servers.)
-
- For example, assume one cache, responding to a recursive
- request, obtains the record:
- "a.b.example. DNAME foo.bar.example.net."
- and another cache obtains:
- "b.example. DNAME foo.bar.example.net."
- both generated from the record:
- "*.example. DNAME foo.bar.example.net."
- by an authoritative server.
-
- The DNAME specification is not clear on whether DNAME records
- in a cache are used to rewrite queries. In some interpretations,
- the rewrite occurs, in some, it is not. Allowing for the
- occurrence of rewriting, queries for "sub.a.b.example. A" may
- be rewritten as "sub.foo.bar.tld. A" by the former caching
- server and may be rewritten as "sub.a.foo.bar.tld. A" by the
- latter. Coherency is lost, an operational nightmare ensues.
-
- Another justification for banning or avoiding wildcard DNAME
- records is the observation that such a record could synthesize
- a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
- There is a restriction in the DNAME definition that no domain
- exist below a DNAME-owning domain, hence, the wildcard DNAME
- is not to be permitted.
-
-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 the owner 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
-
- A DS RRSet owned by a wild card domain name is meaningless and
- harmless. This statement is made in the context that an NS RRSet
- at a wild card domain name is undefined. At a non-delegation
- point, a DS RRSet has no value (no corresponding DNSKEY RRSet
- will be used in DNSSEC validation). If there is a synthesized
- DS RRSet, it alone will not be very useful as it exists in the
- context of a delegation point.
-
-4.7 NSEC RRSet at a Wild Card Domain Name
-
- Wild card domain names in DNSSEC signed zones will have an NSEC
- RRSet. Synthesis of these records will only occur when the
- query exactly matches the record. Synthesized NSEC RR's will not
- be harmful as they will never be used in negative caching or to
- generate a negative response.
-
-4.8 RRSIG at a Wild Card Domain Name
-
- RRSIG records will be present at a wild card domain name in a
- signed zone, and will be synthesized along with data sought in a
- query. The fact that the owner name is synthesized is not a
- problem as the label count in the RRSIG will instruct the
- verifying code to ignore it.
-
-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. IANA Considerations
-
- None.
-
-7. 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] Incremental Zone Transfer in DNS, M. Ohta, August 1996
-
- [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
-
- [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
- M. Andrews, March 1998
-
- [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
- August 1999.
-
- [RFC2782] A DNS RR for specifying the location of services (DNS
- SRV), A. Gulbrandsen, et.al., February 2000
-
- [RFC4033] DNS Security Introduction and Requirements, R. Arends,
- et.al., March 2005
-
- [RFC4034] Resource Records for the DNS Security Extensions,
- R. Arends, et.al., March 2005
-
- [RFC4035] Protocol Modifications for the DNS Security Extensions,
- R. Arends, et.al., March 2005
-
- [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
- August 1999
-
- Informative References
-
- [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
- P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
- April 1997
-
-8. Editor
-
- Name: Edward Lewis
- Affiliation: NeuStar
- Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US
- Phone: +1-571-434-5468
- Email: ed.lewis at neustar.biz
-
- Comments on this document can be sent to the editor or the mailing
- list for the DNSEXT WG, namedroppers at ops.ietf.org.
-
-9. Others Contributing to the Document
-
- This document represents the work of a large working group. The
- editor merely recorded the collective wisdom of the working group.
-
-10. Trailing Boilerplate
-
- 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.
-
-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 at ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-Expiration
-
- This document expires on or about January 6, 2006.
--- contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt
+++ /dev/null
@@ -1,1176 +0,0 @@
-
-
-
-DNS Operations M. Larson
-Internet-Draft P. Barber
-Expires: January 18, 2006 VeriSign
- July 17, 2005
-
-
- Observed DNS Resolution Misbehavior
- draft-ietf-dnsop-bad-dns-res-04
-
-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 BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on January 18, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This memo describes DNS iterative resolver behavior that results in a
- significant query volume sent to the root and top-level domain (TLD)
- name servers. We offer implementation advice to iterative resolver
- developers 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.
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 1]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- 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 . . . . . . . . . . . . . 7
- 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . 7
- 2.3 Inability to follow multiple levels of indirection . . . . 8
- 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . 9
- 2.4 Aggressive retransmission when fetching glue . . . . . . . 9
- 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . 10
- 2.5 Aggressive retransmission behind firewalls . . . . . . . . 10
- 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . 11
- 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 11
- 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . 12
- 2.7 Name server records with zero TTL . . . . . . . . . . . . 12
- 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13
- 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 13
- 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . 14
- 2.9 Queries for domain names resembling IPv4 addresses . . . . 14
- 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . 14
- 2.10 Misdirected recursive queries . . . . . . . . . . . . . 15
- 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . 15
- 2.11 Suboptimal name server selection algorithm . . . . . . . 15
- 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . 16
- 3. IANA considerations . . . . . . . . . . . . . . . . . . . . 17
- 4. Security considerations . . . . . . . . . . . . . . . . . . 18
- 5. Internationalization considerations . . . . . . . . . . . . 19
- 6. Informative References . . . . . . . . . . . . . . . . . . . 19
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
- Intellectual Property and Copyright Statements . . . . . . . 21
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 2]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-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 (<QNAME, QTYPE, QCLASS>) 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 indirection 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. None of the changes recommended affects the core DNS protocol
- specification; instead, this document consists of guidelines to
- implementors of iterative resolvers.
-
-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
- to answer questions about certain zones authoritatively. This entity
- is an iterative resolver combined with an authoritative name server
- and is often called a "recursive name server" or a "caching 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",
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 3]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- because the focus is usually on that component. In instances where
- the name server role of this entity requires mentioning, this memo
- uses the term "recursive name server". As an example of the
- difference, 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 record" to
- encompass both A and AAAA records when a particular situation is
- relevant to both types.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 4]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-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. (Note
- that queries with QTYPE=NS are not required by the standard
- resolution algorithm described in section 4.3.2 of RFC 1034 [2].
- These NS queries represent this implementation's addition to that
- algorithm.)
-
- 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 would be pointless: this query to the parent would come so
- quickly on the heels of the referral that it would be almost certain
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 5]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- 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
- 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 [3], 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.
-
- This section should not be understood to claim that all queries to a
- zone's parent are bad. In some cases, such queries are not only
- reasonable but required. Consider the situation when required
- information, such as the address of a name server (i.e., the address
- record corresponding to the RDATA of an NS record), has timed out of
- an iterative resolver's cache before the corresponding NS record. If
- the name of the name server is below the apex of the zone, then the
- name server's address record is only available as glue in the parent
- zone. For example, consider this NS record:
-
- example.com. IN NS ns.example.com.
-
- If a cache has this NS record but not the address record for
- "ns.example.com", it is unable to contact the "example.com" zone
- directly and must query the "com" zone to obtain the address record.
- Note, however, that such a query would not have QTYPE=NS according to
- the standard resolution algorithm.
-
-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
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 6]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- 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 [4].
-
-
-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
- 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.
-
- It should also be noted, however, that some authoritative name server
- implementations appear to be lame only for queries of certain types
- as described in RFC 4074 [5]. In this case, it makes sense to retry
- the "lame" servers for other types of queries, particularly when all
- known authoritative name servers appear to be "lame".
-
-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).
- If this caching is performed, lame servers MUST be cached against the
- specific query tuple <zone name, class, server IP address>. Zone
- name can be derived from the owner name of the NS record that was
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 7]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- 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.
-
- An exception to this recommendation occurs if all name servers for a
- zone are marked lame. In that case, the iterative resolver SHOULD
- temporarily ignore the servers' lameness status and query one or more
- servers. This behavior is a workaround for the type-specific
- lameness issue described in the previous section.
-
- Implementors should take care not to make lame server avoidance logic
- overly broad: note that a name server could be lame for a parent zone
- but not a child zone, e.g., lame for "example.com" but properly
- authoritative for "sub.example.com". Therefore a name server should
- not be automatically considered lame for subzones. In the case
- above, even if a name server is known to be lame for "example.com",
- it should be queried for QNAMEs at or below "sub.example.com" if an
- NS record indicates it should be authoritative for that zone.
-
-2.3 Inability to follow multiple levels of indirection
-
- Some iterative resolver implementations are unable to follow
- sufficient levels of indirection. 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 existing gTLDs, increasing the
- number of delegations using out-of-zone name servers.
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 8]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-2.3.1 Recommendation
-
- Clearly constructing a delegation that relies on multiple levels of
- indirection is not a good administrative practice. However, the
- practice is widespread enough to require that iterative resolvers be
- able to cope with it. Iterative resolvers SHOULD be able to handle
- arbitrary levels of indirection resulting from out-of-zone name
- servers. Iterative resolvers SHOULD implement a level-of-effort
- counter to avoid loops or otherwise performing too much work in
- resolving pathological cases.
-
- A best practice that avoids this entire issue of indirection is to
- name one or more of a zone's name servers in the zone itself. For
- example, if the zone is named "example.com", consider naming some of
- the name servers "ns{1,2,...}.example.com" (or similar).
-
-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
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 9]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- 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
- 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
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 10]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- servers, which could explain how such a situation could persist
- without being detected.
-
-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 [3], 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"
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 11]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- 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 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 apex 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.
-
- An authoritative name server SHOULD issue a warning when one of a
- zone's NS records references a name server below the zone's apex when
- a corresponding address record does not exist in the zone AND there
- are no delegated subzones where the address record could exist.
-
-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
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 12]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- 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 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.
-
-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-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 13]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- public TLD or root zones that would be the appropriate targets for a
- dynamic update.
-
- 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 names 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 IPv4 addresses
-
- The root name servers receive a significant number of A record
- queries where the QNAME looks like an IPv4 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
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 14]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- bandwidth. A possible solution 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 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. Of course, the proper and usual root zone
- change procedures would have to be followed to make such a change to
- the root zone.
-
-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
- 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.
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 15]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- 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 January 18, 2006 [Page 16]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-3. IANA considerations
-
- There are no new IANA considerations introduced by this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 17]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-4. Security considerations
-
- The iterative resolver misbehavior discussed in this document exposes
- the root and TLD name servers to increased risk of both intentional
- and unintentional denial of service attacks.
-
- 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 January 18, 2006 [Page 18]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-5. Internationalization considerations
-
- There are no new internationalization considerations introduced by
- this memo.
-
-6. Informative 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] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
- RFC 2181, July 1997.
-
- [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
- [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
- Queries for IPv6 Addresses", RFC 4074, May 2005.
-
- [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] <http://www.as112.net>
-
-
-Authors' Addresses
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- Email: mlarson at verisign.com
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 19]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- Piet Barber
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- Email: pbarber at verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 20]
-
-Internet-Draft Observed DNS Resolution Misbehavior July 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 at 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.
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 21]
-
Index: validator.c
===================================================================
RCS file: /home/cvs/src/contrib/bind9/lib/dns/validator.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -L contrib/bind9/lib/dns/validator.c -L contrib/bind9/lib/dns/validator.c -u -r1.2 -r1.3
--- contrib/bind9/lib/dns/validator.c
+++ contrib/bind9/lib/dns/validator.c
@@ -1,8 +1,8 @@
/*
- * Copyright (C) 2004-2006 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2000-2003 Internet Software Consortium.
*
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
*
@@ -15,7 +15,9 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: validator.c,v 1.91.2.5.8.27.6.1 2007/01/11 04:51:39 marka Exp $ */
+/* $Id: validator.c,v 1.119.18.35 2007/09/26 04:39:45 each Exp $ */
+
+/*! \file */
#include <config.h>
@@ -24,6 +26,7 @@
#include <isc/string.h>
#include <isc/task.h>
#include <isc/util.h>
+#include <isc/sha2.h>
#include <dns/db.h>
#include <dns/ds.h>
@@ -69,9 +72,9 @@
* validator_start -> nsecvalidate -> proveunsecure -> startfinddlvsep ->
* dlv_validator_start -> validator_start -> nsecvalidate -> proveunsecure
*
- * \li When called without a rdataset and with DNS_VALIDATOR_DLV:
- * validator_start -> startfinddlvsep -> dlv_validator_start ->
- * validator_start -> nsecvalidate -> proveunsecure
+ * Note: there isn't a case for DNS_VALIDATOR_DLV here as we want nsecvalidate()
+ * to always validate the authority section even when it does not contain
+ * signatures.
*
* validator_start: determines what type of validation to do.
* validate: attempts to perform a positive validation.
@@ -86,11 +89,11 @@
#define VALID_VALIDATOR(v) ISC_MAGIC_VALID(v, VALIDATOR_MAGIC)
#define VALATTR_SHUTDOWN 0x0001 /*%< Shutting down. */
+#define VALATTR_CANCELED 0x0002 /*%< Cancelled. */
#define VALATTR_TRIEDVERIFY 0x0004 /*%< We have found a key and
* have attempted a verify. */
#define VALATTR_INSECURITY 0x0010 /*%< Attempting proveunsecure. */
#define VALATTR_DLVTRIED 0x0020 /*%< Looked for a DLV record. */
-#define VALATTR_AUTHNONPENDING 0x0040 /*%< Tidy up pending auth. */
/*!
* NSEC proofs to be looked for.
@@ -112,6 +115,7 @@
#define DLVTRIED(val) ((val->attributes & VALATTR_DLVTRIED) != 0)
#define SHUTDOWN(v) (((v)->attributes & VALATTR_SHUTDOWN) != 0)
+#define CANCELED(v) (((v)->attributes & VALATTR_CANCELED) != 0)
static void
destroy(dns_validator_t *val);
@@ -155,18 +159,11 @@
static isc_result_t
finddlvsep(dns_validator_t *val, isc_boolean_t resume);
-static void
-auth_nonpending(dns_message_t *message);
-
static isc_result_t
startfinddlvsep(dns_validator_t *val, dns_name_t *unsecure);
/*%
* Mark the RRsets as a answer.
- *
- * If VALATTR_AUTHNONPENDING is set then this is a negative answer
- * in a insecure zone. We need to mark any pending RRsets as
- * dns_trust_authauthority answers (this is deferred from resolver.c).
*/
static inline void
markanswer(dns_validator_t *val) {
@@ -175,9 +172,6 @@
val->event->rdataset->trust = dns_trust_answer;
if (val->event->sigrdataset != NULL)
val->event->sigrdataset->trust = dns_trust_answer;
- if (val->event->message != NULL &&
- (val->attributes & VALATTR_AUTHNONPENDING) != 0)
- auth_nonpending(val->event->message);
}
static void
@@ -217,31 +211,6 @@
}
/*%
- * Mark pending answers in the authority section as dns_trust_authauthority.
- */
-static void
-auth_nonpending(dns_message_t *message) {
- isc_result_t result;
- dns_name_t *name;
- dns_rdataset_t *rdataset;
-
- for (result = dns_message_firstname(message, DNS_SECTION_AUTHORITY);
- result == ISC_R_SUCCESS;
- result = dns_message_nextname(message, DNS_SECTION_AUTHORITY))
- {
- name = NULL;
- dns_message_currentname(message, DNS_SECTION_AUTHORITY, &name);
- for (rdataset = ISC_LIST_HEAD(name->list);
- rdataset != NULL;
- rdataset = ISC_LIST_NEXT(rdataset, link))
- {
- if (rdataset->trust == dns_trust_pending)
- rdataset->trust = dns_trust_authauthority;
- }
- }
-}
-
-/*%
* Look in the NSEC record returned from a DS query to see if there is
* a NS RRset at this name. If it is found we are at a delegation point.
*/
@@ -313,7 +282,9 @@
validator_log(val, ISC_LOG_DEBUG(3), "in fetch_callback_validator");
LOCK(&val->lock);
- if (eresult == ISC_R_SUCCESS) {
+ if (CANCELED(val)) {
+ validator_done(val, ISC_R_CANCELED);
+ } else if (eresult == ISC_R_SUCCESS) {
validator_log(val, ISC_LOG_DEBUG(3),
"keyset with trust %d", rdataset->trust);
/*
@@ -377,7 +348,9 @@
validator_log(val, ISC_LOG_DEBUG(3), "in dsfetched");
LOCK(&val->lock);
- if (eresult == ISC_R_SUCCESS) {
+ if (CANCELED(val)) {
+ validator_done(val, ISC_R_CANCELED);
+ } else if (eresult == ISC_R_SUCCESS) {
validator_log(val, ISC_LOG_DEBUG(3),
"dsset with trust %d", rdataset->trust);
val->dsset = &val->frdataset;
@@ -385,10 +358,12 @@
if (result != DNS_R_WAIT)
validator_done(val, result);
} else if (eresult == DNS_R_NXRRSET ||
- eresult == DNS_R_NCACHENXRRSET)
+ eresult == DNS_R_NCACHENXRRSET ||
+ eresult == DNS_R_SERVFAIL) /* RFC 1034 parent? */
{
validator_log(val, ISC_LOG_DEBUG(3),
- "falling back to insecurity proof");
+ "falling back to insecurity proof (%s)",
+ dns_result_totext(eresult));
val->attributes |= VALATTR_INSECURITY;
result = proveunsecure(val, ISC_FALSE);
if (result != DNS_R_WAIT)
@@ -448,7 +423,9 @@
validator_log(val, ISC_LOG_DEBUG(3), "in dsfetched2: %s",
dns_result_totext(eresult));
LOCK(&val->lock);
- if (eresult == DNS_R_NXRRSET || eresult == DNS_R_NCACHENXRRSET) {
+ if (CANCELED(val)) {
+ validator_done(val, ISC_R_CANCELED);
+ } else if (eresult == DNS_R_NXRRSET || eresult == DNS_R_NCACHENXRRSET) {
/*
* There is no DS. If this is a delegation, we're done.
*/
@@ -523,7 +500,9 @@
validator_log(val, ISC_LOG_DEBUG(3), "in keyvalidated");
LOCK(&val->lock);
- if (eresult == ISC_R_SUCCESS) {
+ if (CANCELED(val)) {
+ validator_done(val, ISC_R_CANCELED);
+ } else if (eresult == ISC_R_SUCCESS) {
validator_log(val, ISC_LOG_DEBUG(3),
"keyset with trust %d", val->frdataset.trust);
/*
@@ -573,7 +552,9 @@
validator_log(val, ISC_LOG_DEBUG(3), "in dsvalidated");
LOCK(&val->lock);
- if (eresult == ISC_R_SUCCESS) {
+ if (CANCELED(val)) {
+ validator_done(val, ISC_R_CANCELED);
+ } else if (eresult == ISC_R_SUCCESS) {
validator_log(val, ISC_LOG_DEBUG(3),
"dsset with trust %d", val->frdataset.trust);
if ((val->attributes & VALATTR_INSECURITY) != 0)
@@ -613,6 +594,8 @@
unsigned int olabels, nlabels, labels;
dns_rdata_nsec_t nsec;
isc_boolean_t atparent;
+ isc_boolean_t ns;
+ isc_boolean_t soa;
REQUIRE(exists != NULL);
REQUIRE(data != NULL);
@@ -644,9 +627,9 @@
* The names are the same.
*/
atparent = dns_rdatatype_atparent(val->event->type);
- if (dns_nsec_typepresent(&rdata, dns_rdatatype_ns) &&
- !dns_nsec_typepresent(&rdata, dns_rdatatype_soa))
- {
+ ns = dns_nsec_typepresent(&rdata, dns_rdatatype_ns);
+ soa = dns_nsec_typepresent(&rdata, dns_rdatatype_soa);
+ if (ns && !soa) {
if (!atparent) {
/*
* This NSEC record is from somewhere higher in
@@ -657,7 +640,7 @@
"ignoring parent nsec");
return (ISC_R_IGNORE);
}
- } else if (atparent) {
+ } else if (atparent && ns && soa) {
/*
* This NSEC record is from the child.
* It can not be legitimately used here.
@@ -666,12 +649,20 @@
"ignoring child nsec");
return (ISC_R_IGNORE);
}
- *exists = ISC_TRUE;
- *data = dns_nsec_typepresent(&rdata, val->event->type);
- validator_log(val, ISC_LOG_DEBUG(3),
- "nsec proves name exists (owner) data=%d",
- *data);
- return (ISC_R_SUCCESS);
+ if (val->event->type == dns_rdatatype_cname ||
+ val->event->type == dns_rdatatype_nxt ||
+ val->event->type == dns_rdatatype_nsec ||
+ val->event->type == dns_rdatatype_key ||
+ !dns_nsec_typepresent(&rdata, dns_rdatatype_cname)) {
+ *exists = ISC_TRUE;
+ *data = dns_nsec_typepresent(&rdata, val->event->type);
+ validator_log(val, ISC_LOG_DEBUG(3),
+ "nsec proves name exists (owner) data=%d",
+ *data);
+ return (ISC_R_SUCCESS);
+ }
+ validator_log(val, ISC_LOG_DEBUG(3), "NSEC proves CNAME exists");
+ return (ISC_R_IGNORE);
}
if (relation == dns_namereln_subdomain &&
@@ -731,6 +722,7 @@
result = dns_name_concatenate(dns_wildcardname, &common,
wild, NULL);
if (result != ISC_R_SUCCESS) {
+ dns_rdata_freestruct(&nsec);
validator_log(val, ISC_LOG_DEBUG(3),
"failure generating wildcard name");
return (result);
@@ -771,7 +763,9 @@
validator_log(val, ISC_LOG_DEBUG(3), "in authvalidated");
LOCK(&val->lock);
- if (result != ISC_R_SUCCESS) {
+ if (CANCELED(val)) {
+ validator_done(val, ISC_R_CANCELED);
+ } else if (result != ISC_R_SUCCESS) {
validator_log(val, ISC_LOG_DEBUG(3),
"authvalidated: got %s",
isc_result_totext(result));
@@ -784,6 +778,7 @@
}
} else {
dns_name_t **proofs = val->event->proofs;
+ dns_name_t *wild = dns_fixedname_name(&val->wild);
if (rdataset->trust == dns_trust_secure)
val->seensig = ISC_TRUE;
@@ -795,10 +790,9 @@
(val->attributes & VALATTR_FOUNDNODATA) == 0 &&
(val->attributes & VALATTR_FOUNDNOQNAME) == 0 &&
nsecnoexistnodata(val, val->event->name, devent->name,
- rdataset, &exists, &data,
- dns_fixedname_name(&val->wild))
+ rdataset, &exists, &data, wild)
== ISC_R_SUCCESS)
- {
+ {
if (exists && !data) {
val->attributes |= VALATTR_FOUNDNODATA;
if (NEEDNODATA(val))
@@ -1285,15 +1279,27 @@
{
isc_result_t result;
dns_fixedname_t fixed;
+ isc_boolean_t ignore = ISC_FALSE;
val->attributes |= VALATTR_TRIEDVERIFY;
dns_fixedname_init(&fixed);
+ again:
result = dns_dnssec_verify2(val->event->name, val->event->rdataset,
- key, ISC_FALSE, val->view->mctx, rdata,
+ key, ignore, val->view->mctx, rdata,
dns_fixedname_name(&fixed));
- validator_log(val, ISC_LOG_DEBUG(3),
- "verify rdataset (keyid=%u): %s",
- keyid, isc_result_totext(result));
+ if (result == DNS_R_SIGEXPIRED && val->view->acceptexpired) {
+ ignore = ISC_TRUE;
+ goto again;
+ }
+ if (ignore && (result == ISC_R_SUCCESS || result == DNS_R_FROMWILDCARD))
+ validator_log(val, ISC_LOG_INFO,
+ "accepted expired %sRRSIG (keyid=%u)",
+ (result == DNS_R_FROMWILDCARD) ?
+ "wildcard " : "", keyid);
+ else
+ validator_log(val, ISC_LOG_DEBUG(3),
+ "verify rdataset (keyid=%u): %s",
+ keyid, isc_result_totext(result));
if (result == DNS_R_FROMWILDCARD) {
if (!dns_name_equal(val->event->name,
dns_fixedname_name(&fixed)))
@@ -1485,6 +1491,7 @@
isc_boolean_t supported_algorithm;
isc_result_t result;
unsigned char dsbuf[DNS_DS_BUFFERSIZE];
+ isc_uint8_t digest_type;
validator_log(val, ISC_LOG_DEBUG(3), "dlv_validatezonekey");
@@ -1495,6 +1502,32 @@
*/
supported_algorithm = ISC_FALSE;
+ /*
+ * If DNS_DSDIGEST_SHA256 is present we are required to prefer
+ * it over DNS_DSDIGEST_SHA1. This in practice means that we
+ * need to ignore DNS_DSDIGEST_SHA1 if a DNS_DSDIGEST_SHA256
+ * is present.
+ */
+ digest_type = DNS_DSDIGEST_SHA1;
+ for (result = dns_rdataset_first(&val->dlv);
+ result == ISC_R_SUCCESS;
+ result = dns_rdataset_next(&val->dlv)) {
+ dns_rdata_reset(&dlvrdata);
+ dns_rdataset_current(&val->dlv, &dlvrdata);
+ dns_rdata_tostruct(&dlvrdata, &dlv, NULL);
+
+ if (!dns_resolver_algorithm_supported(val->view->resolver,
+ val->event->name,
+ dlv.algorithm))
+ continue;
+
+ if (dlv.digest_type == DNS_DSDIGEST_SHA256 &&
+ dlv.length == ISC_SHA256_DIGESTLENGTH) {
+ digest_type = DNS_DSDIGEST_SHA256;
+ break;
+ }
+ }
+
for (result = dns_rdataset_first(&val->dlv);
result == ISC_R_SUCCESS;
result = dns_rdataset_next(&val->dlv))
@@ -1503,8 +1536,14 @@
dns_rdataset_current(&val->dlv, &dlvrdata);
(void)dns_rdata_tostruct(&dlvrdata, &dlv, NULL);
- if (dlv.digest_type != DNS_DSDIGEST_SHA1 ||
- !dns_resolver_algorithm_supported(val->view->resolver,
+ if (!dns_resolver_digest_supported(val->view->resolver,
+ dlv.digest_type))
+ continue;
+
+ if (dlv.digest_type != digest_type)
+ continue;
+
+ if (!dns_resolver_algorithm_supported(val->view->resolver,
val->event->name,
dlv.algorithm))
continue;
@@ -1627,6 +1666,7 @@
dst_key_t *dstkey;
isc_boolean_t supported_algorithm;
isc_boolean_t atsep = ISC_FALSE;
+ isc_uint8_t digest_type;
/*
* Caller must be holding the validator lock.
@@ -1796,6 +1836,32 @@
supported_algorithm = ISC_FALSE;
+ /*
+ * If DNS_DSDIGEST_SHA256 is present we are required to prefer
+ * it over DNS_DSDIGEST_SHA1. This in practice means that we
+ * need to ignore DNS_DSDIGEST_SHA1 if a DNS_DSDIGEST_SHA256
+ * is present.
+ */
+ digest_type = DNS_DSDIGEST_SHA1;
+ for (result = dns_rdataset_first(val->dsset);
+ result == ISC_R_SUCCESS;
+ result = dns_rdataset_next(val->dsset)) {
+ dns_rdata_reset(&dsrdata);
+ dns_rdataset_current(val->dsset, &dsrdata);
+ dns_rdata_tostruct(&dsrdata, &ds, NULL);
+
+ if (!dns_resolver_algorithm_supported(val->view->resolver,
+ val->event->name,
+ ds.algorithm))
+ continue;
+
+ if (ds.digest_type == DNS_DSDIGEST_SHA256 &&
+ ds.length == ISC_SHA256_DIGESTLENGTH) {
+ digest_type = DNS_DSDIGEST_SHA256;
+ break;
+ }
+ }
+
for (result = dns_rdataset_first(val->dsset);
result == ISC_R_SUCCESS;
result = dns_rdataset_next(val->dsset))
@@ -1804,8 +1870,13 @@
dns_rdataset_current(val->dsset, &dsrdata);
(void)dns_rdata_tostruct(&dsrdata, &ds, NULL);
- if (ds.digest_type != DNS_DSDIGEST_SHA1)
+ if (!dns_resolver_digest_supported(val->view->resolver,
+ ds.digest_type))
+ continue;
+
+ if (ds.digest_type != digest_type)
continue;
+
if (!dns_resolver_algorithm_supported(val->view->resolver,
val->event->name,
ds.algorithm))
@@ -2044,12 +2115,6 @@
if (rdataset->type == dns_rdatatype_rrsig)
continue;
- if (rdataset->type == dns_rdatatype_soa) {
- val->soaset = rdataset;
- val->soaname = name;
- } else if (rdataset->type == dns_rdatatype_nsec)
- val->nsecset = rdataset;
-
for (sigrdataset = ISC_LIST_HEAD(name->list);
sigrdataset != NULL;
sigrdataset = ISC_LIST_NEXT(sigrdataset,
@@ -2059,8 +2124,6 @@
sigrdataset->covers == rdataset->type)
break;
}
- if (sigrdataset == NULL)
- continue;
/*
* If a signed zone is missing the zone key, bad
* things could happen. A query for data in the zone
@@ -2149,7 +2212,6 @@
validator_log(val, ISC_LOG_DEBUG(3),
"nonexistence proof(s) not found");
- val->attributes |= VALATTR_AUTHNONPENDING;
val->attributes |= VALATTR_INSECURITY;
return (proveunsecure(val, ISC_FALSE));
}
@@ -2166,7 +2228,8 @@
dns_rdataset_current(rdataset, &dsrdata);
(void)dns_rdata_tostruct(&dsrdata, &ds, NULL);
- if (ds.digest_type == DNS_DSDIGEST_SHA1 &&
+ 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);
@@ -2329,6 +2392,10 @@
dns_fixedname_init(&val->dlvsep);
dlvsep = dns_fixedname_name(&val->dlvsep);
dns_name_copy(val->event->name, dlvsep, NULL);
+ /*
+ * If this is a response to a DS query, we need to look in
+ * the parent zone for the trust anchor.
+ */
if (val->event->type == dns_rdatatype_ds) {
labels = dns_name_countlabels(dlvsep);
if (labels == 0)
@@ -2431,9 +2498,16 @@
if (val->havedlvsep)
dns_name_copy(dns_fixedname_name(&val->dlvsep), secroot, NULL);
else {
+ dns_name_copy(val->event->name, secroot, NULL);
+ /*
+ * If this is a response to a DS query, we need to look in
+ * the parent zone for the trust anchor.
+ */
+ if (val->event->type == dns_rdatatype_ds &&
+ dns_name_countlabels(secroot) > 1U)
+ dns_name_split(secroot, 1, NULL, secroot);
result = dns_keytable_finddeepestmatch(val->keytable,
- val->event->name,
- secroot);
+ secroot, secroot);
if (result == ISC_R_NOTFOUND) {
validator_log(val, ISC_LOG_DEBUG(3),
@@ -2506,11 +2580,21 @@
namebuf);
result = view_find(val, tname, dns_rdatatype_ds);
+
if (result == DNS_R_NXRRSET || result == DNS_R_NCACHENXRRSET) {
/*
* There is no DS. If this is a delegation,
* we maybe done.
*/
+ if (val->frdataset.trust == dns_trust_pending) {
+ result = create_fetch(val, tname,
+ dns_rdatatype_ds,
+ dsfetched2,
+ "proveunsecure");
+ if (result != ISC_R_SUCCESS)
+ goto out;
+ return (DNS_R_WAIT);
+ }
if (val->frdataset.trust < dns_trust_secure) {
/*
* This shouldn't happen, since the negative
@@ -2675,7 +2759,8 @@
LOCK(&val->lock);
- if ((val->options & DNS_VALIDATOR_DLV) != 0) {
+ if ((val->options & DNS_VALIDATOR_DLV) != 0 &&
+ val->event->rdataset != NULL) {
validator_log(val, ISC_LOG_DEBUG(3), "looking for DLV");
result = startfinddlvsep(val, dns_rootname);
} else if (val->event->rdataset != NULL &&
@@ -2759,7 +2844,6 @@
dns_validatorevent_t *event;
REQUIRE(name != NULL);
- REQUIRE(type != 0);
REQUIRE(rdataset != NULL ||
(rdataset == NULL && sigrdataset == NULL && message != NULL));
REQUIRE(validatorp != NULL && *validatorp == NULL);
@@ -2812,9 +2896,6 @@
val->keyset = NULL;
val->dsset = NULL;
dns_rdataset_init(&val->dlv);
- val->soaset = NULL;
- val->nsecset = NULL;
- val->soaname = NULL;
val->seensig = ISC_FALSE;
val->havedlvsep = ISC_FALSE;
val->depth = 0;
@@ -2825,7 +2906,8 @@
ISC_LINK_INIT(val, link);
val->magic = VALIDATOR_MAGIC;
- isc_task_send(task, ISC_EVENT_PTR(&event));
+ if ((options & DNS_VALIDATOR_DEFER) == 0)
+ isc_task_send(task, ISC_EVENT_PTR(&event));
*validatorp = val;
@@ -2843,6 +2925,21 @@
}
void
+dns_validator_send(dns_validator_t *validator) {
+ isc_event_t *event;
+ REQUIRE(VALID_VALIDATOR(validator));
+
+ LOCK(&validator->lock);
+
+ INSIST((validator->options & DNS_VALIDATOR_DEFER) != 0);
+ event = (isc_event_t *)validator->event;
+ validator->options &= ~DNS_VALIDATOR_DEFER;
+ UNLOCK(&validator->lock);
+
+ isc_task_send(validator->task, ISC_EVENT_PTR(&event));
+}
+
+void
dns_validator_cancel(dns_validator_t *validator) {
REQUIRE(VALID_VALIDATOR(validator));
@@ -2856,6 +2953,13 @@
if (validator->subvalidator != NULL)
dns_validator_cancel(validator->subvalidator);
+ if ((validator->options & DNS_VALIDATOR_DEFER) != 0) {
+ isc_task_t *task = validator->event->ev_sender;
+ validator->options &= ~DNS_VALIDATOR_DEFER;
+ isc_event_free((isc_event_t **)&validator->event);
+ isc_task_detach(&task);
+ }
+ validator->attributes |= VALATTR_CANCELED;
}
UNLOCK(&validator->lock);
}
Index: resolver.c
===================================================================
RCS file: /home/cvs/src/contrib/bind9/lib/dns/resolver.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -L contrib/bind9/lib/dns/resolver.c -L contrib/bind9/lib/dns/resolver.c -u -r1.4 -r1.5
--- contrib/bind9/lib/dns/resolver.c
+++ contrib/bind9/lib/dns/resolver.c
@@ -1,8 +1,8 @@
/*
- * Copyright (C) 2004-2006 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
*
@@ -15,7 +15,9 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: resolver.c,v 1.218.2.18.4.64.4.2 2007/01/11 05:05:10 marka Exp $ */
+/* $Id: resolver.c,v 1.284.18.66 2007/11/01 13:53:27 shane Exp $ */
+
+/*! \file */
#include <config.h>
@@ -99,12 +101,12 @@
#define QTRACE(m)
#endif
-/*
+/*%
* Maximum EDNS0 input packet size.
*/
#define RECV_BUFFER_SIZE 4096 /* XXXRTH Constant. */
-/*
+/*%
* This defines the maximum number of timeouts we will permit before we
* disable EDNS0 on the query.
*/
@@ -146,13 +148,13 @@
#define RESQUERY_SENDING(q) ((q)->sends > 0)
typedef enum {
- fetchstate_init = 0, /* Start event has not run yet. */
+ fetchstate_init = 0, /*%< Start event has not run yet. */
fetchstate_active,
- fetchstate_done /* FETCHDONE events posted. */
+ fetchstate_done /*%< FETCHDONE events posted. */
} fetchstate;
struct fetchctx {
- /* Not locked. */
+ /*% Not locked. */
unsigned int magic;
dns_resolver_t * res;
dns_name_t name;
@@ -160,15 +162,16 @@
unsigned int options;
unsigned int bucketnum;
char * info;
- /* Locked by appropriate bucket lock. */
+ /*% Locked by appropriate bucket lock. */
fetchstate state;
isc_boolean_t want_shutdown;
isc_boolean_t cloned;
+ isc_boolean_t spilled;
unsigned int references;
isc_event_t control_event;
ISC_LINK(struct fetchctx) link;
ISC_LIST(dns_fetchevent_t) events;
- /* Locked by task event serialization. */
+ /*% Locked by task event serialization. */
dns_name_t domain;
dns_rdataset_t nameservers;
unsigned int attributes;
@@ -187,16 +190,19 @@
isc_sockaddrlist_t forwarders;
dns_fwdpolicy_t fwdpolicy;
isc_sockaddrlist_t bad;
+ isc_sockaddrlist_t edns;
+ isc_sockaddrlist_t edns512;
+ dns_validator_t *validator;
ISC_LIST(dns_validator_t) validators;
dns_db_t * cache;
dns_adb_t * adb;
- /*
+ /*%
* The number of events we're waiting for.
*/
unsigned int pending;
- /*
+ /*%
* The number of times we've "restarted" the current
* nameserver set. This acts as a failsafe to prevent
* us from pounding constantly on a particular set of
@@ -206,18 +212,23 @@
*/
unsigned int restarts;
- /*
+ /*%
* The number of timeouts that have occurred since we
* last successfully received a response packet. This
* is used for EDNS0 black hole detection.
*/
unsigned int timeouts;
- /*
+ /*%
* Look aside state for DS lookups.
*/
dns_name_t nsname;
dns_fetch_t * nsfetch;
dns_rdataset_t nsrrset;
+
+ /*%
+ * Number of queries that reference this context.
+ */
+ unsigned int nqueries;
};
#define FCTX_MAGIC ISC_MAGIC('F', '!', '!', '!')
@@ -240,7 +251,7 @@
#define ADDRWAIT(f) (((f)->attributes & FCTX_ATTR_ADDRWAIT) != \
0)
#define SHUTTINGDOWN(f) (((f)->attributes & FCTX_ATTR_SHUTTINGDOWN) \
- != 0)
+ != 0)
#define WANTCACHE(f) (((f)->attributes & FCTX_ATTR_WANTCACHE) != 0)
#define WANTNCACHE(f) (((f)->attributes & FCTX_ATTR_WANTNCACHE) != 0)
#define NEEDEDNS0(f) (((f)->attributes & FCTX_ATTR_NEEDEDNS0) != 0)
@@ -265,6 +276,7 @@
isc_mutex_t lock;
ISC_LIST(fetchctx_t) fctxs;
isc_boolean_t exiting;
+ isc_mem_t * mctx;
} fctxbucket_t;
typedef struct alternate {
@@ -309,12 +321,17 @@
isc_rwlock_t mbslock;
#endif
dns_rbt_t * mustbesecure;
+ unsigned int spillatmax;
+ unsigned int spillatmin;
+ isc_timer_t * spillattimer;
+ isc_boolean_t zero_no_soa_ttl;
/* Locked by lock. */
unsigned int references;
isc_boolean_t exiting;
isc_eventlist_t whenshutdown;
unsigned int activebuckets;
isc_boolean_t priming;
+ unsigned int spillat;
/* Locked by primelock. */
dns_fetch_t * primefetch;
/* Locked by nlock. */
@@ -324,7 +341,7 @@
#define RES_MAGIC ISC_MAGIC('R', 'e', 's', '!')
#define VALID_RESOLVER(res) ISC_MAGIC_VALID(res, RES_MAGIC)
-/*
+/*%
* Private addrinfo flags. These must not conflict with DNS_FETCHOPT_NOEDNS0,
* which we also use as an addrinfo flag.
*/
@@ -337,6 +354,8 @@
#define NXDOMAIN(r) (((r)->attributes & DNS_RDATASETATTR_NXDOMAIN) != 0)
+#define dns_db_transfernode(a,b,c) do { (*c) = (*b); (*b) = NULL; } while (0)
+
static void destroy(dns_resolver_t *res);
static void empty_bucket(dns_resolver_t *res);
static isc_result_t resquery_send(resquery_t *query);
@@ -351,6 +370,7 @@
dns_rdataset_t *ardataset,
isc_result_t *eresultp);
static void validated(isc_task_t *task, isc_event_t *event);
+static void maybe_destroy(fetchctx_t *fctx);
static isc_result_t
valcreate(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, dns_name_t *name,
@@ -362,21 +382,30 @@
dns_valarg_t *valarg;
isc_result_t result;
- valarg = isc_mem_get(fctx->res->mctx, sizeof(*valarg));
+ valarg = isc_mem_get(fctx->res->buckets[fctx->bucketnum].mctx,
+ sizeof(*valarg));
if (valarg == NULL)
return (ISC_R_NOMEMORY);
valarg->fctx = fctx;
valarg->addrinfo = addrinfo;
+ if (!ISC_LIST_EMPTY(fctx->validators))
+ INSIST((valoptions & DNS_VALIDATOR_DEFER) != 0);
+
result = dns_validator_create(fctx->res->view, name, type, rdataset,
sigrdataset, fctx->rmessage,
valoptions, task, validated, valarg,
&validator);
- if (result == ISC_R_SUCCESS)
+ if (result == ISC_R_SUCCESS) {
+ if ((valoptions & DNS_VALIDATOR_DEFER) == 0) {
+ INSIST(fctx->validator == NULL);
+ fctx->validator = validator;
+ }
ISC_LIST_APPEND(fctx->validators, validator, link);
- else
- isc_mem_put(fctx->res->mctx, valarg, sizeof(*valarg));
+ } else
+ isc_mem_put(fctx->res->buckets[fctx->bucketnum].mctx,
+ valarg, sizeof(*valarg));
return (result);
}
@@ -515,6 +544,9 @@
INSIST(query->tcpsocket == NULL);
+ query->fctx->nqueries--;
+ if (SHUTTINGDOWN(query->fctx))
+ maybe_destroy(query->fctx); /* Locks bucket. */
query->magic = 0;
isc_mem_put(query->mctx, query, sizeof(*query));
*queryp = NULL;
@@ -559,8 +591,7 @@
* slow. We don't know. Increase the RTT.
*/
INSIST(no_response);
- rtt = query->addrinfo->srtt +
- (200000 * fctx->restarts);
+ rtt = query->addrinfo->srtt + 200000;
if (rtt > 10000000)
rtt = 10000000;
/*
@@ -743,6 +774,9 @@
fctx_sendevents(fetchctx_t *fctx, isc_result_t result) {
dns_fetchevent_t *event, *next_event;
isc_task_t *task;
+ unsigned int count = 0;
+ isc_interval_t i;
+ isc_boolean_t logit = ISC_FALSE;
/*
* Caller must be holding the appropriate bucket lock.
@@ -766,8 +800,42 @@
fctx->type == dns_rdatatype_any ||
fctx->type == dns_rdatatype_rrsig ||
fctx->type == dns_rdatatype_sig);
+
+ /*
+ * Negative results must be indicated in event->result.
+ */
+ if (dns_rdataset_isassociated(event->rdataset) &&
+ event->rdataset->type == dns_rdatatype_none) {
+ INSIST(event->result == DNS_R_NCACHENXDOMAIN ||
+ event->result == DNS_R_NCACHENXRRSET);
+ }
isc_task_sendanddetach(&task, ISC_EVENT_PTR(&event));
+ count++;
+ }
+
+ if ((fctx->attributes & FCTX_ATTR_HAVEANSWER) != 0 &&
+ fctx->spilled &&
+ (count < fctx->res->spillatmax || fctx->res->spillatmax == 0)) {
+ LOCK(&fctx->res->lock);
+ if (count == fctx->res->spillat && !fctx->res->exiting) {
+ fctx->res->spillat += 5;
+ if (fctx->res->spillat > fctx->res->spillatmax &&
+ fctx->res->spillatmax != 0)
+ fctx->res->spillat = fctx->res->spillatmax;
+ logit = ISC_TRUE;
+ isc_interval_set(&i, 20 * 60, 0);
+ result = isc_timer_reset(fctx->res->spillattimer,
+ isc_timertype_ticker, NULL,
+ &i, ISC_TRUE);
+ RUNTIME_CHECK(result == ISC_R_SUCCESS);
+ }
+ UNLOCK(&fctx->res->lock);
+ if (logit)
+ isc_log_write(dns_lctx, DNS_LOGCATEGORY_RESOLVER,
+ DNS_LOGMODULE_RESOLVER, ISC_LOG_NOTICE,
+ "clients-per-query increased to %u",
+ count + 1);
}
}
@@ -872,7 +940,8 @@
}
static inline isc_result_t
-fctx_addopt(dns_message_t *message, dns_resolver_t *res) {
+fctx_addopt(dns_message_t *message, unsigned int version, isc_uint16_t udpsize)
+{
dns_rdataset_t *rdataset;
dns_rdatalist_t *rdatalist;
dns_rdata_t *rdata;
@@ -898,12 +967,13 @@
/*
* Set Maximum UDP buffer size.
*/
- rdatalist->rdclass = res->udpsize;
+ rdatalist->rdclass = udpsize;
/*
- * Set EXTENDED-RCODE, VERSION, and Z to 0, and the DO bit to 1.
+ * Set EXTENDED-RCODE and Z to 0, DO to 1.
*/
- rdatalist->ttl = DNS_MESSAGEEXTFLAG_DO;
+ rdatalist->ttl = (version << 16);
+ rdatalist->ttl |= DNS_MESSAGEEXTFLAG_DO;
/*
* No EDNS options.
@@ -924,34 +994,37 @@
static inline void
fctx_setretryinterval(fetchctx_t *fctx, unsigned int rtt) {
unsigned int seconds;
+ unsigned int us;
/*
- * We retry every 2 seconds the first two times through the address
+ * We retry every .5 seconds the first two times through the address
* list, and then we do exponential back-off.
*/
if (fctx->restarts < 3)
- seconds = 2;
+ us = 500000;
else
- seconds = (2 << (fctx->restarts - 1));
+ us = (500000 << (fctx->restarts - 2));
/*
- * Double the round-trip time and convert to seconds.
+ * Double the round-trip time.
*/
- rtt /= 500000;
+ rtt *= 2;
/*
* Always wait for at least the doubled round-trip time.
*/
- if (seconds < rtt)
- seconds = rtt;
+ if (us < rtt)
+ us = rtt;
/*
- * But don't ever wait for more than 30 seconds.
+ * But don't ever wait for more than 10 seconds.
*/
- if (seconds > 30)
- seconds = 30;
+ if (us > 10000000)
+ us = 10000000;
- isc_interval_set(&fctx->interval, seconds, 0);
+ seconds = us / 1000000;
+ us -= seconds * 1000000;
+ isc_interval_set(&fctx->interval, seconds, us * 1000);
}
static isc_result_t
@@ -962,6 +1035,8 @@
isc_task_t *task;
isc_result_t result;
resquery_t *query;
+ isc_sockaddr_t addr;
+ isc_boolean_t have_addr = ISC_FALSE;
FCTXTRACE("query");
@@ -973,14 +1048,17 @@
if (result != ISC_R_SUCCESS)
return (result);
+ INSIST(ISC_LIST_EMPTY(fctx->validators));
+
dns_message_reset(fctx->rmessage, DNS_MESSAGE_INTENTPARSE);
- query = isc_mem_get(res->mctx, sizeof(*query));
+ query = isc_mem_get(res->buckets[fctx->bucketnum].mctx,
+ sizeof(*query));
if (query == NULL) {
result = ISC_R_NOMEMORY;
goto stop_idle_timer;
}
- query->mctx = res->mctx;
+ query->mctx = res->buckets[fctx->bucketnum].mctx;
query->options = options;
query->attributes = 0;
query->sends = 0;
@@ -1000,28 +1078,42 @@
query->dispatchmgr = res->dispatchmgr;
query->dispatch = NULL;
query->tcpsocket = NULL;
+ if (res->view->peers != NULL) {
+ dns_peer_t *peer = NULL;
+ isc_netaddr_t dstip;
+ isc_netaddr_fromsockaddr(&dstip, &addrinfo->sockaddr);
+ result = dns_peerlist_peerbyaddr(res->view->peers,
+ &dstip, &peer);
+ if (result == ISC_R_SUCCESS) {
+ result = dns_peer_getquerysource(peer, &addr);
+ if (result == ISC_R_SUCCESS)
+ have_addr = ISC_TRUE;
+ }
+ }
+
if ((query->options & DNS_FETCHOPT_TCP) != 0) {
- isc_sockaddr_t addr;
int pf;
pf = isc_sockaddr_pf(&addrinfo->sockaddr);
-
- switch (pf) {
- case PF_INET:
- result = dns_dispatch_getlocaladdress(res->dispatchv4,
- &addr);
- break;
- case PF_INET6:
- result = dns_dispatch_getlocaladdress(res->dispatchv6,
- &addr);
- break;
- default:
- result = ISC_R_NOTIMPLEMENTED;
- break;
+ if (!have_addr) {
+ switch (pf) {
+ case PF_INET:
+ result =
+ dns_dispatch_getlocaladdress(res->dispatchv4,
+ &addr);
+ break;
+ case PF_INET6:
+ result =
+ dns_dispatch_getlocaladdress(res->dispatchv6,
+ &addr);
+ break;
+ default:
+ result = ISC_R_NOTIMPLEMENTED;
+ break;
+ }
+ if (result != ISC_R_SUCCESS)
+ goto cleanup_query;
}
- if (result != ISC_R_SUCCESS)
- goto cleanup_query;
-
isc_sockaddr_setport(&addr, 0);
result = isc_socket_create(res->socketmgr, pf,
@@ -1040,16 +1132,46 @@
* A dispatch will be created once the connect succeeds.
*/
} else {
- switch (isc_sockaddr_pf(&addrinfo->sockaddr)) {
- case PF_INET:
- dns_dispatch_attach(res->dispatchv4, &query->dispatch);
- break;
- case PF_INET6:
- dns_dispatch_attach(res->dispatchv6, &query->dispatch);
- break;
- default:
- result = ISC_R_NOTIMPLEMENTED;
- goto cleanup_query;
+ if (have_addr) {
+ unsigned int attrs, attrmask;
+ attrs = DNS_DISPATCHATTR_UDP;
+ switch (isc_sockaddr_pf(&addr)) {
+ case AF_INET:
+ attrs |= DNS_DISPATCHATTR_IPV4;
+ break;
+ case AF_INET6:
+ attrs |= DNS_DISPATCHATTR_IPV6;
+ break;
+ default:
+ result = ISC_R_NOTIMPLEMENTED;
+ goto cleanup_query;
+ }
+ attrmask = DNS_DISPATCHATTR_UDP;
+ attrmask |= DNS_DISPATCHATTR_TCP;
+ attrmask |= DNS_DISPATCHATTR_IPV4;
+ attrmask |= DNS_DISPATCHATTR_IPV6;
+ result = dns_dispatch_getudp(res->dispatchmgr,
+ res->socketmgr,
+ res->taskmgr, &addr,
+ 4096, 1000, 32768, 16411,
+ 16433, attrs, attrmask,
+ &query->dispatch);
+ if (result != ISC_R_SUCCESS)
+ goto cleanup_query;
+ } else {
+ switch (isc_sockaddr_pf(&addrinfo->sockaddr)) {
+ case PF_INET:
+ dns_dispatch_attach(res->dispatchv4,
+ &query->dispatch);
+ break;
+ case PF_INET6:
+ dns_dispatch_attach(res->dispatchv6,
+ &query->dispatch);
+ break;
+ default:
+ result = ISC_R_NOTIMPLEMENTED;
+ goto cleanup_query;
+ }
}
/*
* We should always have a valid dispatcher here. If we
@@ -1088,6 +1210,7 @@
}
ISC_LIST_APPEND(fctx->queries, query, link);
+ query->fctx->nqueries++;
return (ISC_R_SUCCESS);
@@ -1100,7 +1223,8 @@
cleanup_query:
query->magic = 0;
- isc_mem_put(res->mctx, query, sizeof(*query));
+ isc_mem_put(res->buckets[fctx->bucketnum].mctx,
+ query, sizeof(*query));
stop_idle_timer:
RUNTIME_CHECK(fctx_stopidletimer(fctx) == ISC_R_SUCCESS);
@@ -1108,6 +1232,66 @@
return (result);
}
+static isc_boolean_t
+triededns(fetchctx_t *fctx, isc_sockaddr_t *address) {
+ isc_sockaddr_t *sa;
+
+ for (sa = ISC_LIST_HEAD(fctx->edns);
+ sa != NULL;
+ sa = ISC_LIST_NEXT(sa, link)) {
+ if (isc_sockaddr_equal(sa, address))
+ return (ISC_TRUE);
+ }
+
+ return (ISC_FALSE);
+}
+
+static void
+add_triededns(fetchctx_t *fctx, isc_sockaddr_t *address) {
+ isc_sockaddr_t *sa;
+
+ if (triededns(fctx, address))
+ return;
+
+ sa = isc_mem_get(fctx->res->buckets[fctx->bucketnum].mctx,
+ sizeof(*sa));
+ if (sa == NULL)
+ return;
+
+ *sa = *address;
+ ISC_LIST_INITANDAPPEND(fctx->edns, sa, link);
+}
+
+static isc_boolean_t
+triededns512(fetchctx_t *fctx, isc_sockaddr_t *address) {
+ isc_sockaddr_t *sa;
+
+ for (sa = ISC_LIST_HEAD(fctx->edns512);
+ sa != NULL;
+ sa = ISC_LIST_NEXT(sa, link)) {
+ if (isc_sockaddr_equal(sa, address))
+ return (ISC_TRUE);
+ }
+
+ return (ISC_FALSE);
+}
+
+static void
+add_triededns512(fetchctx_t *fctx, isc_sockaddr_t *address) {
+ isc_sockaddr_t *sa;
+
+ if (triededns512(fctx, address))
+ return;
+
+ sa = isc_mem_get(fctx->res->buckets[fctx->bucketnum].mctx,
+ sizeof(*sa));
+ if (sa == NULL)
+ return;
+
+ *sa = *address;
+ ISC_LIST_INITANDAPPEND(fctx->edns512, sa, link);
+}
+
static isc_result_t
resquery_send(resquery_t *query) {
fetchctx_t *fctx;
@@ -1196,7 +1380,9 @@
* Set CD if the client says don't validate or the question is
* under a secure entry point.
*/
- if ((query->options & DNS_FETCHOPT_NOVALIDATE) == 0) {
+ if ((query->options & DNS_FETCHOPT_NOVALIDATE) != 0) {
+ fctx->qmessage->flags |= DNS_MESSAGEFLAG_CD;
+ } else if (res->view->enablevalidation) {
result = dns_keytable_issecuredomain(res->view->secroots,
&fctx->name,
&secure_domain);
@@ -1206,8 +1392,7 @@
secure_domain = ISC_TRUE;
if (secure_domain)
fctx->qmessage->flags |= DNS_MESSAGEFLAG_CD;
- } else
- fctx->qmessage->flags |= DNS_MESSAGEFLAG_CD;
+ }
/*
* We don't have to set opcode because it defaults to query.
@@ -1256,15 +1441,35 @@
* Use EDNS0, unless the caller doesn't want it, or we know that
* the remote server doesn't like it.
*/
- if (fctx->timeouts >= MAX_EDNS0_TIMEOUTS &&
+
+ if ((triededns512(fctx, &query->addrinfo->sockaddr) ||
+ fctx->timeouts >= (MAX_EDNS0_TIMEOUTS * 2)) &&
(query->options & DNS_FETCHOPT_NOEDNS0) == 0) {
query->options |= DNS_FETCHOPT_NOEDNS0;
FCTXTRACE("too many timeouts, disabling EDNS0");
+ } else if ((triededns(fctx, &query->addrinfo->sockaddr) ||
+ fctx->timeouts >= MAX_EDNS0_TIMEOUTS) &&
+ (query->options & DNS_FETCHOPT_NOEDNS0) == 0) {
+ query->options |= DNS_FETCHOPT_EDNS512;
+ FCTXTRACE("too many timeouts, setting EDNS size to 512");
}
if ((query->options & DNS_FETCHOPT_NOEDNS0) == 0) {
if ((query->addrinfo->flags & DNS_FETCHOPT_NOEDNS0) == 0) {
- result = fctx_addopt(fctx->qmessage, res);
+ unsigned int version = 0; /* Default version. */
+ unsigned int flags;
+ isc_uint16_t udpsize = res->udpsize;
+
+ flags = query->addrinfo->flags;
+ if ((flags & DNS_FETCHOPT_EDNSVERSIONSET) != 0) {
+ version = flags & DNS_FETCHOPT_EDNSVERSIONMASK;
+ version >>= DNS_FETCHOPT_EDNSVERSIONSHIFT;
+ }
+ if ((query->options & DNS_FETCHOPT_EDNS512) != 0)
+ udpsize = 512;
+ else if (peer != NULL)
+ (void)dns_peer_getudpsize(peer, &udpsize);
+ result = fctx_addopt(fctx->qmessage, version, udpsize);
if (result != ISC_R_SUCCESS) {
/*
* We couldn't add the OPT, but we'll press on.
@@ -1291,6 +1496,12 @@
goto cleanup_message;
}
+ if ((query->options & DNS_FETCHOPT_NOEDNS0) == 0)
+ add_triededns(fctx, &query->addrinfo->sockaddr);
+
+ if ((query->options & DNS_FETCHOPT_EDNS512) != 0)
+ add_triededns512(fctx, &query->addrinfo->sockaddr);
+
/*
* Clear CD if EDNS is not in use.
*/
@@ -1540,7 +1751,7 @@
want_done = ISC_TRUE;
}
} else if (SHUTTINGDOWN(fctx) && fctx->pending == 0 &&
- ISC_LIST_EMPTY(fctx->validators)) {
+ fctx->nqueries == 0 && ISC_LIST_EMPTY(fctx->validators)) {
bucketnum = fctx->bucketnum;
LOCK(&res->buckets[bucketnum].lock);
/*
@@ -1646,7 +1857,7 @@
}
static void
-add_bad(fetchctx_t *fctx, isc_sockaddr_t *address, isc_result_t reason) {
+add_bad(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, isc_result_t reason) {
char namebuf[DNS_NAME_FORMATSIZE];
char addrbuf[ISC_SOCKADDR_FORMATSIZE];
char classbuf[64];
@@ -1655,6 +1866,7 @@
isc_buffer_t b;
isc_sockaddr_t *sa;
const char *sep1, *sep2;
+ isc_sockaddr_t *address = &addrinfo->sockaddr;
if (bad_server(fctx, address)) {
/*
@@ -1665,7 +1877,8 @@
FCTXTRACE("add_bad");
- sa = isc_mem_get(fctx->res->mctx, sizeof(*sa));
+ sa = isc_mem_get(fctx->res->buckets[fctx->bucketnum].mctx,
+ sizeof(*sa));
if (sa == NULL)
return;
*sa = *address;
@@ -1674,6 +1887,11 @@
if (reason == DNS_R_LAME) /* already logged */
return;
+ if (reason == DNS_R_UNEXPECTEDRCODE &&
+ fctx->rmessage->opcode == dns_rcode_servfail &&
+ ISFORWARDER(addrinfo))
+ return;
+
if (reason == DNS_R_UNEXPECTEDRCODE) {
isc_buffer_init(&b, code, sizeof(code) - 1);
dns_rcode_totext(fctx->rmessage->rcode, &b);
@@ -1780,7 +1998,7 @@
static void
findname(fetchctx_t *fctx, dns_name_t *name, in_port_t port,
unsigned int options, unsigned int flags, isc_stdtime_t now,
- isc_boolean_t *pruned, isc_boolean_t *need_alternate)
+ isc_boolean_t *need_alternate)
{
dns_adbaddrinfo_t *ai;
dns_adbfind_t *find;
@@ -1809,7 +2027,8 @@
result = dns_adb_createfind(fctx->adb,
res->buckets[fctx->bucketnum].task,
fctx_finddone, fctx, name,
- &fctx->domain, options, now, NULL,
+ &fctx->name, fctx->type,
+ options, now, NULL,
res->view->dstport, &find);
if (result != ISC_R_SUCCESS) {
if (result == DNS_R_ALIAS) {
@@ -1872,18 +2091,6 @@
(res->dispatchv6 == NULL &&
find->result_v4 == DNS_R_NXRRSET)))
*need_alternate = ISC_TRUE;
- /*
- * And ADB isn't going to send us any events
- * either. This find loses.
- */
- if ((find->options & DNS_ADBFIND_LAMEPRUNED) != 0) {
- /*
- * The ADB pruned lame servers for
- * this name. Remember that in case
- * we get desperate later on.
- */
- *pruned = ISC_TRUE;
- }
dns_adb_destroyfind(&find);
}
}
@@ -1898,7 +2105,7 @@
unsigned int stdoptions;
isc_sockaddr_t *sa;
dns_adbaddrinfo_t *ai;
- isc_boolean_t pruned, all_bad;
+ isc_boolean_t all_bad;
dns_rdata_ns_t ns;
isc_boolean_t need_alternate = ISC_FALSE;
@@ -1914,7 +2121,6 @@
}
res = fctx->res;
- pruned = ISC_FALSE;
stdoptions = 0; /* Keep compiler happy. */
/*
@@ -2006,7 +2212,6 @@
stdoptions |= DNS_ADBFIND_INET6;
isc_stdtime_get(&now);
- restart:
INSIST(ISC_LIST_EMPTY(fctx->finds));
INSIST(ISC_LIST_EMPTY(fctx->altfinds));
@@ -2023,7 +2228,7 @@
continue;
findname(fctx, &ns.name, 0, stdoptions, 0, now,
- &pruned, &need_alternate);
+ &need_alternate);
dns_rdata_reset(&rdata);
dns_rdata_freestruct(&ns);
}
@@ -2043,7 +2248,7 @@
if (!a->isaddress) {
findname(fctx, &a->_u._n.name, a->_u._n.port,
stdoptions, FCTX_ADDRINFO_FORWARDER,
- now, &pruned, NULL);
+ now, NULL);
continue;
}
if (isc_sockaddr_pf(&a->_u.addr) != family)
@@ -2086,18 +2291,6 @@
* yet. Tell the caller to wait for an answer.
*/
result = DNS_R_WAIT;
- } else if (pruned) {
- /*
- * Some addresses were removed by lame pruning.
- * Turn pruning off and try again.
- */
- FCTXTRACE("restarting with returnlame");
- INSIST((stdoptions & DNS_ADBFIND_RETURNLAME) == 0);
- stdoptions |= DNS_ADBFIND_RETURNLAME;
- pruned = ISC_FALSE;
- fctx_cleanupaltfinds(fctx);
- fctx_cleanupfinds(fctx);
- goto restart;
} else {
/*
* We've lost completely. We don't know any
@@ -2394,8 +2587,8 @@
REQUIRE(ISC_LIST_EMPTY(fctx->finds));
REQUIRE(ISC_LIST_EMPTY(fctx->altfinds));
REQUIRE(fctx->pending == 0);
- REQUIRE(ISC_LIST_EMPTY(fctx->validators));
REQUIRE(fctx->references == 0);
+ REQUIRE(ISC_LIST_EMPTY(fctx->validators));
FCTXTRACE("destroy");
@@ -2412,21 +2605,37 @@
sa = next_sa) {
next_sa = ISC_LIST_NEXT(sa, link);
ISC_LIST_UNLINK(fctx->bad, sa, link);
- isc_mem_put(res->mctx, sa, sizeof(*sa));
+ isc_mem_put(res->buckets[bucketnum].mctx, sa, sizeof(*sa));
+ }
+
+ for (sa = ISC_LIST_HEAD(fctx->edns);
+ sa != NULL;
+ sa = next_sa) {
+ next_sa = ISC_LIST_NEXT(sa, link);
+ ISC_LIST_UNLINK(fctx->edns, sa, link);
+ isc_mem_put(res->buckets[bucketnum].mctx, sa, sizeof(*sa));
+ }
+
+ for (sa = ISC_LIST_HEAD(fctx->edns512);
+ sa != NULL;
+ sa = next_sa) {
+ next_sa = ISC_LIST_NEXT(sa, link);
+ ISC_LIST_UNLINK(fctx->edns512, sa, link);
+ isc_mem_put(res->buckets[bucketnum].mctx, sa, sizeof(*sa));
}
isc_timer_detach(&fctx->timer);
dns_message_destroy(&fctx->rmessage);
dns_message_destroy(&fctx->qmessage);
if (dns_name_countlabels(&fctx->domain) > 0)
- dns_name_free(&fctx->domain, res->mctx);
+ dns_name_free(&fctx->domain, res->buckets[bucketnum].mctx);
if (dns_rdataset_isassociated(&fctx->nameservers))
dns_rdataset_disassociate(&fctx->nameservers);
- dns_name_free(&fctx->name, res->mctx);
+ dns_name_free(&fctx->name, res->buckets[bucketnum].mctx);
dns_db_detach(&fctx->cache);
dns_adb_detach(&fctx->adb);
- isc_mem_free(res->mctx, fctx->info);
- isc_mem_put(res->mctx, fctx, sizeof(*fctx));
+ isc_mem_free(res->buckets[bucketnum].mctx, fctx->info);
+ isc_mem_put(res->buckets[bucketnum].mctx, fctx, sizeof(*fctx));
LOCK(&res->nlock);
res->nfctx--;
@@ -2569,7 +2778,7 @@
}
if (fctx->references == 0 && fctx->pending == 0 &&
- ISC_LIST_EMPTY(fctx->validators))
+ fctx->nqueries == 0 && ISC_LIST_EMPTY(fctx->validators))
bucket_empty = fctx_destroy(fctx);
UNLOCK(&res->buckets[bucketnum].lock);
@@ -2610,6 +2819,7 @@
* pending ADB finds and no pending validations.
*/
INSIST(fctx->pending == 0);
+ INSIST(fctx->nqueries == 0);
INSIST(ISC_LIST_EMPTY(fctx->validators));
if (fctx->references == 0) {
/*
@@ -2654,8 +2864,9 @@
*/
static inline isc_result_t
-fctx_join(fetchctx_t *fctx, isc_task_t *task, isc_taskaction_t action,
- void *arg, dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset,
+fctx_join(fetchctx_t *fctx, isc_task_t *task, isc_sockaddr_t *client,
+ dns_messageid_t id, isc_taskaction_t action, void *arg,
+ dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset,
dns_fetch_t *fetch)
{
isc_task_t *clone;
@@ -2671,8 +2882,7 @@
clone = NULL;
isc_task_attach(task, &clone);
event = (dns_fetchevent_t *)
- isc_event_allocate(fctx->res->mctx, clone,
- DNS_EVENT_FETCHDONE,
+ isc_event_allocate(fctx->res->mctx, clone, DNS_EVENT_FETCHDONE,
action, arg, sizeof(*event));
if (event == NULL) {
isc_task_detach(&clone);
@@ -2685,6 +2895,8 @@
event->rdataset = rdataset;
event->sigrdataset = sigrdataset;
event->fetch = fetch;
+ event->client = client;
+ event->id = id;
dns_fixedname_init(&event->foundname);
/*
@@ -2723,21 +2935,21 @@
*/
REQUIRE(fctxp != NULL && *fctxp == NULL);
- fctx = isc_mem_get(res->mctx, sizeof(*fctx));
+ fctx = isc_mem_get(res->buckets[bucketnum].mctx, sizeof(*fctx));
if (fctx == NULL)
return (ISC_R_NOMEMORY);
dns_name_format(name, buf, sizeof(buf));
dns_rdatatype_format(type, typebuf, sizeof(typebuf));
strcat(buf, "/"); /* checked */
strcat(buf, typebuf); /* checked */
- fctx->info = isc_mem_strdup(res->mctx, buf);
+ fctx->info = isc_mem_strdup(res->buckets[bucketnum].mctx, buf);
if (fctx->info == NULL) {
result = ISC_R_NOMEMORY;
goto cleanup_fetch;
}
FCTXTRACE("create");
dns_name_init(&fctx->name, NULL);
- result = dns_name_dup(name, res->mctx, &fctx->name);
+ result = dns_name_dup(name, res->buckets[bucketnum].mctx, &fctx->name);
if (result != ISC_R_SUCCESS)
goto cleanup_info;
dns_name_init(&fctx->domain, NULL);
@@ -2764,13 +2976,18 @@
ISC_LIST_INIT(fctx->forwarders);
fctx->fwdpolicy = dns_fwdpolicy_none;
ISC_LIST_INIT(fctx->bad);
+ ISC_LIST_INIT(fctx->edns);
+ ISC_LIST_INIT(fctx->edns512);
ISC_LIST_INIT(fctx->validators);
+ fctx->validator = NULL;
fctx->find = NULL;
fctx->altfind = NULL;
fctx->pending = 0;
fctx->restarts = 0;
fctx->timeouts = 0;
fctx->attributes = 0;
+ fctx->spilled = ISC_FALSE;
+ fctx->nqueries = 0;
dns_name_init(&fctx->nsname, NULL);
fctx->nsfetch = NULL;
@@ -2812,7 +3029,9 @@
NULL);
if (result != ISC_R_SUCCESS)
goto cleanup_name;
- result = dns_name_dup(domain, res->mctx, &fctx->domain);
+ result = dns_name_dup(domain,
+ res->buckets[bucketnum].mctx,
+ &fctx->domain);
if (result != ISC_R_SUCCESS) {
dns_rdataset_disassociate(&fctx->nameservers);
goto cleanup_name;
@@ -2821,12 +3040,16 @@
/*
* We're in forward-only mode. Set the query domain.
*/
- result = dns_name_dup(domain, res->mctx, &fctx->domain);
+ result = dns_name_dup(domain,
+ res->buckets[bucketnum].mctx,
+ &fctx->domain);
if (result != ISC_R_SUCCESS)
goto cleanup_name;
}
} else {
- result = dns_name_dup(domain, res->mctx, &fctx->domain);
+ result = dns_name_dup(domain,
+ res->buckets[bucketnum].mctx,
+ &fctx->domain);
if (result != ISC_R_SUCCESS)
goto cleanup_name;
dns_rdataset_clone(nameservers, &fctx->nameservers);
@@ -2835,14 +3058,16 @@
INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain));
fctx->qmessage = NULL;
- result = dns_message_create(res->mctx, DNS_MESSAGE_INTENTRENDER,
+ result = dns_message_create(res->buckets[bucketnum].mctx,
+ DNS_MESSAGE_INTENTRENDER,
&fctx->qmessage);
if (result != ISC_R_SUCCESS)
goto cleanup_domain;
fctx->rmessage = NULL;
- result = dns_message_create(res->mctx, DNS_MESSAGE_INTENTPARSE,
+ result = dns_message_create(res->buckets[bucketnum].mctx,
+ DNS_MESSAGE_INTENTPARSE,
&fctx->rmessage);
if (result != ISC_R_SUCCESS)
@@ -2915,18 +3140,18 @@
cleanup_domain:
if (dns_name_countlabels(&fctx->domain) > 0)
- dns_name_free(&fctx->domain, res->mctx);
+ dns_name_free(&fctx->domain, res->buckets[bucketnum].mctx);
if (dns_rdataset_isassociated(&fctx->nameservers))
dns_rdataset_disassociate(&fctx->nameservers);
cleanup_name:
- dns_name_free(&fctx->name, res->mctx);
+ dns_name_free(&fctx->name, res->buckets[bucketnum].mctx);
cleanup_info:
- isc_mem_free(res->mctx, fctx->info);
+ isc_mem_free(res->buckets[bucketnum].mctx, fctx->info);
cleanup_fetch:
- isc_mem_put(res->mctx, fctx, sizeof(*fctx));
+ isc_mem_put(res->buckets[bucketnum].mctx, fctx, sizeof(*fctx));
return (result);
}
@@ -2964,7 +3189,7 @@
if (rdataset->type != dns_rdatatype_ns)
continue;
namereln = dns_name_fullcompare(name, &fctx->domain,
- &order, &labels);
+ &order, &labels);
if (namereln == dns_namereln_equal &&
(message->flags & DNS_MESSAGEFLAG_AA) != 0)
return (ISC_FALSE);
@@ -3093,15 +3318,30 @@
unsigned int bucketnum;
isc_boolean_t bucket_empty = ISC_FALSE;
dns_resolver_t *res = fctx->res;
+ dns_validator_t *validator, *next_validator;
REQUIRE(SHUTTINGDOWN(fctx));
- if (fctx->pending != 0 || !ISC_LIST_EMPTY(fctx->validators))
+ if (fctx->pending != 0 || fctx->nqueries != 0)
return;
+ for (validator = ISC_LIST_HEAD(fctx->validators);
+ validator != NULL; validator = next_validator) {
+ next_validator = ISC_LIST_NEXT(validator, link);
+ dns_validator_cancel(validator);
+ /*
+ * If this is a active validator wait for the cancel
+ * to complete before calling dns_validator_destroy().
+ */
+ if (validator == fctx->validator)
+ continue;
+ ISC_LIST_UNLINK(fctx->validators, validator, link);
+ dns_validator_destroy(&validator);
+ }
+
bucketnum = fctx->bucketnum;
LOCK(&res->buckets[bucketnum].lock);
- if (fctx->references == 0)
+ if (fctx->references == 0 && ISC_LIST_EMPTY(fctx->validators))
bucket_empty = fctx_destroy(fctx);
UNLOCK(&res->buckets[bucketnum].lock);
@@ -3148,13 +3388,15 @@
FCTXTRACE("received validation completion event");
ISC_LIST_UNLINK(fctx->validators, vevent->validator, link);
+ fctx->validator = NULL;
/*
* Destroy the validator early so that we can
* destroy the fctx if necessary.
*/
dns_validator_destroy(&vevent->validator);
- isc_mem_put(fctx->res->mctx, valarg, sizeof(*valarg));
+ isc_mem_put(fctx->res->buckets[fctx->bucketnum].mctx,
+ valarg, sizeof(*valarg));
negative = ISC_TF(vevent->rdataset == NULL);
@@ -3229,10 +3471,14 @@
if (result == ISC_R_SUCCESS)
dns_db_detachnode(fctx->cache, &node);
result = vevent->result;
- add_bad(fctx, &addrinfo->sockaddr, result);
+ add_bad(fctx, addrinfo, result);
isc_event_free(&event);
UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
- if (sentresponse)
+ INSIST(fctx->validator == NULL);
+ fctx->validator = ISC_LIST_HEAD(fctx->validators);
+ if (fctx->validator != NULL) {
+ dns_validator_send(fctx->validator);
+ } else if (sentresponse)
fctx_done(fctx, result); /* Locks bucket. */
else
fctx_try(fctx); /* Locks bucket. */
@@ -3262,7 +3508,8 @@
*/
ttl = fctx->res->view->maxncachettl;
if (fctx->type == dns_rdatatype_soa &&
- covers == dns_rdatatype_any)
+ covers == dns_rdatatype_any &&
+ fctx->res->zero_no_soa_ttl)
ttl = 0;
result = ncache_adderesult(fctx->rmessage, fctx->cache, node,
@@ -3299,7 +3546,12 @@
if (result != ISC_R_SUCCESS &&
result != DNS_R_UNCHANGED)
goto noanswer_response;
- if (vevent->sigrdataset != NULL) {
+ if (ardataset != NULL && ardataset->type == 0) {
+ if (NXDOMAIN(ardataset))
+ eresult = DNS_R_NCACHENXDOMAIN;
+ else
+ eresult = DNS_R_NCACHENXRRSET;
+ } else if (vevent->sigrdataset != NULL) {
result = dns_db_addrdataset(fctx->cache, node, NULL, now,
vevent->sigrdataset, 0,
asigrdataset);
@@ -3313,6 +3565,7 @@
* If we only deferred the destroy because we wanted to cache
* the data, destroy now.
*/
+ dns_db_detachnode(fctx->cache, &node);
UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
if (SHUTTINGDOWN(fctx))
maybe_destroy(fctx); /* Locks bucket. */
@@ -3329,7 +3582,9 @@
* more rdatasets that still need to
* be validated.
*/
+ dns_db_detachnode(fctx->cache, &node);
UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
+ dns_validator_send(ISC_LIST_HEAD(fctx->validators));
goto cleanup_event;
}
@@ -3393,8 +3648,7 @@
dns_fixedname_name(&hevent->foundname), NULL)
== ISC_R_SUCCESS);
dns_db_attach(fctx->cache, &hevent->db);
- hevent->node = node;
- node = NULL;
+ dns_db_transfernode(fctx->cache, &node, &hevent->node);
clone_results(fctx);
}
@@ -3407,12 +3661,14 @@
fctx_done(fctx, result); /* Locks bucket. */
cleanup_event:
+ INSIST(node == NULL);
isc_event_free(&event);
}
static inline isc_result_t
cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo,
- isc_stdtime_t now) {
+ isc_stdtime_t now)
+{
dns_rdataset_t *rdataset, *sigrdataset;
dns_rdataset_t *addedrdataset, *ardataset, *asigrdataset;
dns_rdataset_t *valrdataset = NULL, *valsigrdataset = NULL;
@@ -3442,14 +3698,16 @@
/*
* Is DNSSEC validation required for this name?
*/
- result = dns_keytable_issecuredomain(res->view->secroots, name,
- &secure_domain);
- if (result != ISC_R_SUCCESS)
- return (result);
+ if (res->view->enablevalidation) {
+ result = dns_keytable_issecuredomain(res->view->secroots, name,
+ &secure_domain);
+ if (result != ISC_R_SUCCESS)
+ return (result);
- if (!secure_domain && res->view->dlv != NULL) {
- valoptions = DNS_VALIDATOR_DLV;
- secure_domain = ISC_TRUE;
+ if (!secure_domain && res->view->dlv != NULL) {
+ valoptions = DNS_VALIDATOR_DLV;
+ secure_domain = ISC_TRUE;
+ }
}
if ((fctx->options & DNS_FETCHOPT_NOVALIDATE) != 0)
@@ -3524,8 +3782,10 @@
fail ? "failure" : "warning",
namebuf, typebuf, classbuf);
if (fail) {
- if (ANSWER(rdataset))
+ if (ANSWER(rdataset)) {
+ dns_db_detachnode(fctx->cache, &node);
return (DNS_R_BADNAME);
+ }
continue;
}
}
@@ -3590,8 +3850,29 @@
result = dns_db_addrdataset(fctx->cache, node, NULL,
now, rdataset, 0,
addedrdataset);
- if (result == DNS_R_UNCHANGED)
+ if (result == DNS_R_UNCHANGED) {
result = ISC_R_SUCCESS;
+ if (!need_validation &&
+ ardataset != NULL &&
+ ardataset->type == 0) {
+ /*
+ * The answer in the cache is better
+ * than the answer we found, and is
+ * a negative cache entry, so we
+ * must set eresult appropriately.
+ */
+ if (NXDOMAIN(ardataset))
+ eresult = DNS_R_NCACHENXDOMAIN;
+ else
+ eresult = DNS_R_NCACHENXRRSET;
+ /*
+ * We have a negative response from
+ * the cache so don't attempt to
+ * add the RRSIG rrset.
+ */
+ continue;
+ }
+ }
if (result != ISC_R_SUCCESS)
break;
if (sigrdataset != NULL) {
@@ -3640,6 +3921,13 @@
rdataset,
sigrdataset,
valoptions, task);
+ /*
+ * Defer any further validations.
+ * This prevents multiple validators
+ * from manipulating fctx->rmessage
+ * simultaniously.
+ */
+ valoptions |= DNS_VALIDATOR_DEFER;
}
} else if (CHAINING(rdataset)) {
if (rdataset->type == dns_rdatatype_cname)
@@ -3701,12 +3989,10 @@
* a negative cache entry, so we
* must set eresult appropriately.
*/
- if (NXDOMAIN(ardataset))
- eresult =
- DNS_R_NCACHENXDOMAIN;
- else
- eresult =
- DNS_R_NCACHENXRRSET;
+ if (NXDOMAIN(ardataset))
+ eresult = DNS_R_NCACHENXDOMAIN;
+ else
+ eresult = DNS_R_NCACHENXRRSET;
}
result = ISC_R_SUCCESS;
} else if (result != ISC_R_SUCCESS)
@@ -3717,15 +4003,22 @@
if (valrdataset != NULL)
result = valcreate(fctx, addrinfo, name, fctx->type,
valrdataset, valsigrdataset, valoptions,
- task);
+ task);
if (result == ISC_R_SUCCESS && have_answer) {
fctx->attributes |= FCTX_ATTR_HAVEANSWER;
if (event != NULL) {
+ /*
+ * Negative results must be indicated in event->result.
+ */
+ if (dns_rdataset_isassociated(event->rdataset) &&
+ event->rdataset->type == dns_rdatatype_none) {
+ INSIST(eresult == DNS_R_NCACHENXDOMAIN ||
+ eresult == DNS_R_NCACHENXRRSET);
+ }
event->result = eresult;
dns_db_attach(fctx->cache, adbp);
- *anodep = node;
- node = NULL;
+ dns_db_transfernode(fctx->cache, &node, anodep);
clone_results(fctx);
}
}
@@ -3863,14 +4156,16 @@
/*
* Is DNSSEC validation required for this name?
*/
- result = dns_keytable_issecuredomain(res->view->secroots, name,
- &secure_domain);
- if (result != ISC_R_SUCCESS)
- return (result);
+ if (fctx->res->view->enablevalidation) {
+ result = dns_keytable_issecuredomain(res->view->secroots, name,
+ &secure_domain);
+ if (result != ISC_R_SUCCESS)
+ return (result);
- if (!secure_domain && res->view->dlv != NULL) {
- valoptions = DNS_VALIDATOR_DLV;
- secure_domain = ISC_TRUE;
+ if (!secure_domain && res->view->dlv != NULL) {
+ valoptions = DNS_VALIDATOR_DLV;
+ secure_domain = ISC_TRUE;
+ }
}
if ((fctx->options & DNS_FETCHOPT_NOVALIDATE) != 0)
@@ -3963,8 +4258,7 @@
if (event != NULL) {
event->result = eresult;
dns_db_attach(fctx->cache, adbp);
- *anodep = node;
- node = NULL;
+ dns_db_transfernode(fctx->cache, &node, anodep);
clone_results(fctx);
}
}
@@ -4175,7 +4469,7 @@
dns_message_t *message;
dns_name_t *name, *qname, *ns_name, *soa_name, *ds_name;
dns_rdataset_t *rdataset, *ns_rdataset;
- isc_boolean_t done, aa, negative_response;
+ isc_boolean_t aa, negative_response;
dns_rdatatype_t type;
dns_section_t section =
bind8_ns_resp ? DNS_SECTION_ANSWER : DNS_SECTION_AUTHORITY;
@@ -4234,13 +4528,12 @@
/*
* Process the authority section.
*/
- done = ISC_FALSE;
ns_name = NULL;
ns_rdataset = NULL;
soa_name = NULL;
ds_name = NULL;
result = dns_message_firstname(message, section);
- while (!done && result == ISC_R_SUCCESS) {
+ while (result == ISC_R_SUCCESS) {
name = NULL;
dns_message_currentname(message, section, &name);
if (dns_name_issubdomain(name, &fctx->domain)) {
@@ -4302,15 +4595,29 @@
dns_trust_additional;
}
}
- /*
- * 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, handled above) or
- * rcode is NXDOMAIN (handled above) in which case
- * the NS RRset is allowed (Type 4).
- */
- if (soa_name != NULL)
- negative_response = ISC_TRUE;
+ }
+ result = dns_message_nextname(message, section);
+ if (result == ISC_R_NOMORE)
+ break;
+ else if (result != ISC_R_SUCCESS)
+ return (result);
+ }
+
+ /*
+ * 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, handled above) or
+ * rcode is NXDOMAIN (handled above) in which case
+ * the NS RRset is allowed (Type 4).
+ */
+ if (soa_name != NULL)
+ negative_response = ISC_TRUE;
+
+ result = dns_message_firstname(message, section);
+ while (result == ISC_R_SUCCESS) {
+ name = NULL;
+ dns_message_currentname(message, section, &name);
+ if (dns_name_issubdomain(name, &fctx->domain)) {
for (rdataset = ISC_LIST_HEAD(name->list);
rdataset != NULL;
rdataset = ISC_LIST_NEXT(rdataset, link)) {
@@ -4465,11 +4772,14 @@
* if so we should bail out.
*/
INSIST(dns_name_countlabels(&fctx->domain) > 0);
- dns_name_free(&fctx->domain, fctx->res->mctx);
+ dns_name_free(&fctx->domain,
+ fctx->res->buckets[fctx->bucketnum].mctx);
if (dns_rdataset_isassociated(&fctx->nameservers))
dns_rdataset_disassociate(&fctx->nameservers);
dns_name_init(&fctx->domain, NULL);
- result = dns_name_dup(ns_name, fctx->res->mctx, &fctx->domain);
+ result = dns_name_dup(ns_name,
+ fctx->res->buckets[fctx->bucketnum].mctx,
+ &fctx->domain);
if (result != ISC_R_SUCCESS)
return (result);
fctx->attributes |= FCTX_ATTR_WANTCACHE;
@@ -4924,9 +5234,11 @@
if (dns_rdataset_isassociated(&fctx->nameservers))
dns_rdataset_disassociate(&fctx->nameservers);
dns_rdataset_clone(fevent->rdataset, &fctx->nameservers);
- dns_name_free(&fctx->domain, fctx->res->mctx);
+ dns_name_free(&fctx->domain,
+ fctx->res->buckets[bucketnum].mctx);
dns_name_init(&fctx->domain, NULL);
- result = dns_name_dup(&fctx->nsname, fctx->res->mctx,
+ result = dns_name_dup(&fctx->nsname,
+ fctx->res->buckets[bucketnum].mctx,
&fctx->domain);
if (result != ISC_R_SUCCESS) {
fctx_done(fctx, DNS_R_SERVFAIL);
@@ -5350,6 +5662,28 @@
* for this fetch.
*/
result = DNS_R_YXDOMAIN;
+ } else if (message->rcode == dns_rcode_badvers) {
+ dns_rdataset_t *opt;
+ unsigned int flags, mask;
+ unsigned int version;
+
+ resend = ISC_TRUE;
+ opt = dns_message_getopt(message);
+ version = (opt->ttl >> 16) & 0xff;
+ flags = (version << DNS_FETCHOPT_EDNSVERSIONSHIFT) |
+ DNS_FETCHOPT_EDNSVERSIONSET;
+ mask = DNS_FETCHOPT_EDNSVERSIONMASK |
+ DNS_FETCHOPT_EDNSVERSIONSET;
+ switch (version) {
+ case 0:
+ dns_adb_changeflags(fctx->adb, query->addrinfo,
+ flags, mask);
+ break;
+ default:
+ broken_server = DNS_R_BADVERS;
+ keep_trying = ISC_TRUE;
+ break;
+ }
} else {
/*
* XXXRTH log.
@@ -5379,7 +5713,7 @@
is_lame(fctx)) {
log_lame(fctx, query->addrinfo);
result = dns_adb_marklame(fctx->adb, query->addrinfo,
- &fctx->domain,
+ &fctx->name, fctx->type,
now + fctx->res->lame_ttl);
if (result != ISC_R_SUCCESS)
isc_log_write(dns_lctx, DNS_LOGCATEGORY_RESOLVER,
@@ -5563,7 +5897,7 @@
* Add this server to the list of bad servers for
* this fctx.
*/
- add_bad(fctx, &addrinfo->sockaddr, broken_server);
+ add_bad(fctx, addrinfo, broken_server);
}
if (get_nameservers) {
@@ -5601,9 +5935,11 @@
fctx_done(fctx, DNS_R_SERVFAIL);
return;
}
- dns_name_free(&fctx->domain, fctx->res->mctx);
+ dns_name_free(&fctx->domain,
+ fctx->res->buckets[fctx->bucketnum].mctx);
dns_name_init(&fctx->domain, NULL);
- result = dns_name_dup(fname, fctx->res->mctx,
+ result = dns_name_dup(fname,
+ fctx->res->buckets[fctx->bucketnum].mctx,
&fctx->domain);
if (result != ISC_R_SUCCESS) {
fctx_done(fctx, DNS_R_SERVFAIL);
@@ -5643,7 +5979,7 @@
fctx_done(fctx, result);
} else if (result == DNS_R_CHASEDSSERVERS) {
unsigned int n;
- add_bad(fctx, &addrinfo->sockaddr, result);
+ add_bad(fctx, addrinfo, result);
fctx_cancelqueries(fctx, ISC_TRUE);
fctx_cleanupfinds(fctx);
fctx_cleanupforwaddrs(fctx);
@@ -5701,6 +6037,7 @@
isc_task_shutdown(res->buckets[i].task);
isc_task_detach(&res->buckets[i].task);
DESTROYLOCK(&res->buckets[i].lock);
+ isc_mem_detach(&res->buckets[i].mctx);
}
isc_mem_put(res->mctx, res->buckets,
res->nbuckets * sizeof(fctxbucket_t));
@@ -5722,6 +6059,7 @@
#if USE_MBSLOCK
isc_rwlock_destroy(&res->mbslock);
#endif
+ isc_timer_detach(&res->spillattimer);
res->magic = 0;
isc_mem_put(res->mctx, res, sizeof(*res));
}
@@ -5760,11 +6098,44 @@
UNLOCK(&res->lock);
}
+static void
+spillattimer_countdown(isc_task_t *task, isc_event_t *event) {
+ dns_resolver_t *res = event->ev_arg;
+ isc_result_t result;
+ unsigned int count;
+ isc_boolean_t logit = ISC_FALSE;
+
+ REQUIRE(VALID_RESOLVER(res));
+
+ UNUSED(task);
+
+ LOCK(&res->lock);
+ INSIST(!res->exiting);
+ if (res->spillat > res->spillatmin) {
+ res->spillat--;
+ logit = ISC_TRUE;
+ }
+ if (res->spillat <= res->spillatmin) {
+ result = isc_timer_reset(res->spillattimer,
+ isc_timertype_inactive, NULL,
+ NULL, ISC_TRUE);
+ RUNTIME_CHECK(result == ISC_R_SUCCESS);
+ }
+ count = res->spillat;
+ UNLOCK(&res->lock);
+ if (logit)
+ isc_log_write(dns_lctx, DNS_LOGCATEGORY_RESOLVER,
+ DNS_LOGMODULE_RESOLVER, ISC_LOG_NOTICE,
+ "clients-per-query decreased to %u", count);
+
+ isc_event_free(&event);
+}
+
isc_result_t
dns_resolver_create(dns_view_t *view,
isc_taskmgr_t *taskmgr, unsigned int ntasks,
isc_socketmgr_t *socketmgr,
- isc_timermgr_t *timermgr,
+ isc_timermgr_t *timermgr,
unsigned int options,
dns_dispatchmgr_t *dispatchmgr,
dns_dispatch_t *dispatchv4,
@@ -5774,6 +6145,7 @@
dns_resolver_t *res;
isc_result_t result = ISC_R_SUCCESS;
unsigned int i, buckets_created = 0;
+ isc_task_t *task = NULL;
char name[16];
/*
@@ -5803,6 +6175,10 @@
res->udpsize = RECV_BUFFER_SIZE;
res->algorithms = NULL;
res->mustbesecure = NULL;
+ res->spillatmin = res->spillat = 10;
+ res->spillatmax = 100;
+ res->spillattimer = NULL;
+ res->zero_no_soa_ttl = ISC_FALSE;
res->nbuckets = ntasks;
res->activebuckets = ntasks;
@@ -5822,6 +6198,13 @@
DESTROYLOCK(&res->buckets[i].lock);
goto cleanup_buckets;
}
+ res->buckets[i].mctx = NULL;
+ result = isc_mem_create(0, 0, &res->buckets[i].mctx);
+ if (result != ISC_R_SUCCESS) {
+ isc_task_detach(&res->buckets[i].task);
+ DESTROYLOCK(&res->buckets[i].lock);
+ goto cleanup_buckets;
+ }
snprintf(name, sizeof(name), "res%u", i);
isc_task_setname(res->buckets[i].task, name, res);
ISC_LIST_INIT(res->buckets[i].fctxs);
@@ -5856,10 +6239,22 @@
if (result != ISC_R_SUCCESS)
goto cleanup_nlock;
+ task = NULL;
+ result = isc_task_create(taskmgr, 0, &task);
+ if (result != ISC_R_SUCCESS)
+ goto cleanup_primelock;
+
+ result = isc_timer_create(timermgr, isc_timertype_inactive, NULL, NULL,
+ task, spillattimer_countdown, res,
+ &res->spillattimer);
+ isc_task_detach(&task);
+ if (result != ISC_R_SUCCESS)
+ goto cleanup_primelock;
+
#if USE_ALGLOCK
result = isc_rwlock_init(&res->alglock, 0, 0);
if (result != ISC_R_SUCCESS)
- goto cleanup_primelock;
+ goto cleanup_spillattimer;
#endif
#if USE_MBSLOCK
result = isc_rwlock_init(&res->mbslock, 0, 0);
@@ -5880,9 +6275,12 @@
#endif
#endif
#if USE_ALGLOCK || USE_MBSLOCK
+ cleanup_spillattimer:
+ isc_timer_detach(&res->spillattimer);
+#endif
+
cleanup_primelock:
DESTROYLOCK(&res->primelock);
-#endif
cleanup_nlock:
DESTROYLOCK(&res->nlock);
@@ -5898,6 +6296,7 @@
cleanup_buckets:
for (i = 0; i < buckets_created; i++) {
+ isc_mem_detach(&res->buckets[i].mctx);
DESTROYLOCK(&res->buckets[i].lock);
isc_task_shutdown(res->buckets[i].task);
isc_task_detach(&res->buckets[i].task);
@@ -5916,6 +6315,7 @@
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;
@@ -5934,6 +6334,13 @@
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);
@@ -6075,6 +6482,7 @@
unsigned int i;
fetchctx_t *fctx;
isc_socket_t *sock;
+ isc_result_t result;
REQUIRE(VALID_RESOLVER(res));
@@ -6111,6 +6519,10 @@
}
if (res->activebuckets == 0)
send_shutdown_events(res);
+ result = isc_timer_reset(res->spillattimer,
+ isc_timertype_inactive, NULL,
+ NULL, ISC_TRUE);
+ RUNTIME_CHECK(result == ISC_R_SUCCESS);
}
UNLOCK(&res->lock);
@@ -6181,12 +6593,32 @@
dns_rdataset_t *sigrdataset,
dns_fetch_t **fetchp)
{
+ return (dns_resolver_createfetch2(res, name, type, domain,
+ nameservers, forwarders, NULL, 0,
+ options, task, action, arg,
+ rdataset, sigrdataset, fetchp));
+}
+
+isc_result_t
+dns_resolver_createfetch2(dns_resolver_t *res, dns_name_t *name,
+ dns_rdatatype_t type,
+ dns_name_t *domain, dns_rdataset_t *nameservers,
+ dns_forwarders_t *forwarders,
+ isc_sockaddr_t *client, dns_messageid_t id,
+ unsigned int options, isc_task_t *task,
+ isc_taskaction_t action, void *arg,
+ dns_rdataset_t *rdataset,
+ dns_rdataset_t *sigrdataset,
+ dns_fetch_t **fetchp)
+{
dns_fetch_t *fetch;
fetchctx_t *fctx = NULL;
- isc_result_t result;
+ isc_result_t result = ISC_R_SUCCESS;
unsigned int bucketnum;
isc_boolean_t new_fctx = ISC_FALSE;
isc_event_t *event;
+ unsigned int count = 0;
+ unsigned int spillat;
UNUSED(forwarders);
@@ -6213,8 +6645,11 @@
if (fetch == NULL)
return (ISC_R_NOMEMORY);
- bucketnum = dns_name_hash(name, ISC_FALSE) % res->nbuckets;
+ bucketnum = dns_name_fullhash(name, ISC_FALSE) % res->nbuckets;
+ LOCK(&res->lock);
+ spillat = res->spillat;
+ UNLOCK(&res->lock);
LOCK(&res->buckets[bucketnum].lock);
if (res->buckets[bucketnum].exiting) {
@@ -6230,6 +6665,31 @@
break;
}
}
+
+ /*
+ * Is this a duplicate?
+ */
+ if (fctx != NULL && client != NULL) {
+ dns_fetchevent_t *fevent;
+ for (fevent = ISC_LIST_HEAD(fctx->events);
+ fevent != NULL;
+ fevent = ISC_LIST_NEXT(fevent, ev_link)) {
+ if (fevent->client != NULL && fevent->id == id &&
+ isc_sockaddr_equal(fevent->client, client)) {
+ result = DNS_R_DUPLICATE;
+ goto unlock;
+ }
+ count++;
+ }
+ }
+ if (count >= res->spillatmin && res->spillatmin != 0) {
+ if (count >= spillat)
+ fctx->spilled = ISC_TRUE;
+ if (fctx->spilled) {
+ result = DNS_R_DROP;
+ goto unlock;
+ }
+ }
/*
* If we didn't have a fetch, would attach to a done fetch, this
@@ -6249,7 +6709,7 @@
new_fctx = ISC_TRUE;
}
- result = fctx_join(fctx, task, action, arg,
+ result = fctx_join(fctx, task, client, id, action, arg,
rdataset, sigrdataset, fetch);
if (new_fctx) {
if (result == ISC_R_SUCCESS) {
@@ -6371,7 +6831,8 @@
/*
* No one cares about the result of this fetch anymore.
*/
- if (fctx->pending == 0 && ISC_LIST_EMPTY(fctx->validators) &&
+ if (fctx->pending == 0 && fctx->nqueries == 0 &&
+ ISC_LIST_EMPTY(fctx->validators) &&
SHUTTINGDOWN(fctx)) {
/*
* This fctx is already shutdown; we were just
@@ -6604,6 +7065,13 @@
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) {
@@ -6623,7 +7091,7 @@
isc_result_t
dns_resolver_setmustbesecure(dns_resolver_t *resolver, dns_name_t *name,
- isc_boolean_t value)
+ isc_boolean_t value)
{
isc_result_t result;
@@ -6669,3 +7137,45 @@
#endif
return (value);
}
+
+void
+dns_resolver_getclientsperquery(dns_resolver_t *resolver, isc_uint32_t *cur,
+ isc_uint32_t *min, isc_uint32_t *max)
+{
+ REQUIRE(VALID_RESOLVER(resolver));
+
+ LOCK(&resolver->lock);
+ if (cur != NULL)
+ *cur = resolver->spillat;
+ if (min != NULL)
+ *min = resolver->spillatmin;
+ if (max != NULL)
+ *max = resolver->spillatmax;
+ UNLOCK(&resolver->lock);
+}
+
+void
+dns_resolver_setclientsperquery(dns_resolver_t *resolver, isc_uint32_t min,
+ isc_uint32_t max)
+{
+ REQUIRE(VALID_RESOLVER(resolver));
+
+ LOCK(&resolver->lock);
+ resolver->spillatmin = resolver->spillat = min;
+ resolver->spillatmax = max;
+ UNLOCK(&resolver->lock);
+}
+
+isc_boolean_t
+dns_resolver_getzeronosoattl(dns_resolver_t *resolver) {
+ REQUIRE(VALID_RESOLVER(resolver));
+
+ return (resolver->zero_no_soa_ttl);
+}
+
+void
+dns_resolver_setzeronosoattl(dns_resolver_t *resolver, isc_boolean_t state) {
+ REQUIRE(VALID_RESOLVER(resolver));
+
+ resolver->zero_no_soa_ttl = state;
+}
Index: dispatch.c
===================================================================
RCS file: /home/cvs/src/contrib/bind9/lib/dns/dispatch.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -L contrib/bind9/lib/dns/dispatch.c -L contrib/bind9/lib/dns/dispatch.c -u -r1.2 -r1.3
--- contrib/bind9/lib/dns/dispatch.c
+++ contrib/bind9/lib/dns/dispatch.c
@@ -1,8 +1,8 @@
/*
- * Copyright (C) 2004, 2006 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
*
@@ -15,7 +15,9 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: dispatch.c,v 1.101.2.6.2.13 2006/07/19 00:44:04 marka Exp $ */
+/* $Id: dispatch.c,v 1.116.18.19 2007/08/28 07:20:04 tbox Exp $ */
+
+/*! \file */
#include <config.h>
@@ -55,11 +57,11 @@
typedef struct dns_qid {
unsigned int magic;
- unsigned int qid_nbuckets; /* hash table size */
- unsigned int qid_increment; /* id increment on collision */
+ unsigned int qid_nbuckets; /*%< hash table size */
+ unsigned int qid_increment; /*%< id increment on collision */
isc_mutex_t lock;
- dns_nsid_t nsid;
- dns_displist_t *qid_table; /* the table itself */
+ dns_nsid_t nsid;
+ dns_displist_t *qid_table; /*%< the table itself */
} dns_qid_t;
struct dns_dispatchmgr {
@@ -77,18 +79,18 @@
/* locked by buffer lock */
dns_qid_t *qid;
isc_mutex_t buffer_lock;
- unsigned int buffers; /* allocated buffers */
- unsigned int buffersize; /* size of each buffer */
- unsigned int maxbuffers; /* max buffers */
+ unsigned int buffers; /*%< allocated buffers */
+ unsigned int buffersize; /*%< size of each buffer */
+ unsigned int maxbuffers; /*%< max buffers */
/* Locked internally. */
isc_mutex_t pool_lock;
- isc_mempool_t *epool; /* memory pool for events */
- isc_mempool_t *rpool; /* memory pool for replies */
- isc_mempool_t *dpool; /* dispatch allocations */
- isc_mempool_t *bpool; /* memory pool for buffers */
+ isc_mempool_t *epool; /*%< memory pool for events */
+ isc_mempool_t *rpool; /*%< memory pool for replies */
+ isc_mempool_t *dpool; /*%< dispatch allocations */
+ isc_mempool_t *bpool; /*%< memory pool for buffers */
- isc_entropy_t *entropy; /* entropy source */
+ isc_entropy_t *entropy; /*%< entropy source */
};
#define MGR_SHUTTINGDOWN 0x00000001U
@@ -114,32 +116,32 @@
struct dns_dispatch {
/* Unlocked. */
- unsigned int magic; /* magic */
- dns_dispatchmgr_t *mgr; /* dispatch manager */
- isc_task_t *task; /* internal task */
- isc_socket_t *socket; /* isc socket attached to */
- isc_sockaddr_t local; /* local address */
- unsigned int maxrequests; /* max requests */
+ unsigned int magic; /*%< magic */
+ dns_dispatchmgr_t *mgr; /*%< dispatch manager */
+ isc_task_t *task; /*%< internal task */
+ isc_socket_t *socket; /*%< isc socket attached to */
+ isc_sockaddr_t local; /*%< local address */
+ unsigned int maxrequests; /*%< max requests */
isc_event_t *ctlevent;
- /* Locked by mgr->lock. */
+ /*% Locked by mgr->lock. */
ISC_LINK(dns_dispatch_t) link;
/* Locked by "lock". */
- isc_mutex_t lock; /* locks all below */
+ isc_mutex_t lock; /*%< locks all below */
isc_sockettype_t socktype;
unsigned int attributes;
- unsigned int refcount; /* number of users */
- dns_dispatchevent_t *failsafe_ev; /* failsafe cancel event */
+ unsigned int refcount; /*%< number of users */
+ dns_dispatchevent_t *failsafe_ev; /*%< failsafe cancel event */
unsigned int shutting_down : 1,
shutdown_out : 1,
connected : 1,
tcpmsg_valid : 1,
- recv_pending : 1; /* is a recv() pending? */
+ recv_pending : 1; /*%< is a recv() pending? */
isc_result_t shutdown_why;
- unsigned int requests; /* how many requests we have */
- unsigned int tcpbuffers; /* allocated buffers */
- dns_tcpmsg_t tcpmsg; /* for tcp streams */
+ unsigned int requests; /*%< how many requests we have */
+ unsigned int tcpbuffers; /*%< allocated buffers */
+ dns_tcpmsg_t tcpmsg; /*%< for tcp streams */
dns_qid_t *qid;
};
@@ -968,6 +970,9 @@
INSIST(disp->recv_pending == 0);
disp->recv_pending = 1;
break;
+ default:
+ INSIST(0);
+ break;
}
}
@@ -1237,6 +1242,7 @@
if (isc_mempool_create(mgr->mctx, buffersize,
&mgr->bpool) != ISC_R_SUCCESS) {
+ UNLOCK(&mgr->buffer_lock);
return (ISC_R_NOMEMORY);
}
@@ -1394,6 +1400,7 @@
{
dns_qid_t *qid;
unsigned int i;
+ isc_result_t result;
REQUIRE(VALID_DISPATCHMGR(mgr));
REQUIRE(buckets < 2097169); /* next prime > 65536 * 32 */
@@ -1411,20 +1418,21 @@
return (ISC_R_NOMEMORY);
}
- if (nsid_init(mgr->mctx, &qid->nsid, usepool) != ISC_R_SUCCESS) {
+ result = nsid_init(mgr->mctx, &qid->nsid, usepool);
+ if (result != ISC_R_SUCCESS) {
isc_mem_put(mgr->mctx, qid->qid_table,
buckets * sizeof(dns_displist_t));
isc_mem_put(mgr->mctx, qid, sizeof(*qid));
return (ISC_R_NOMEMORY);
}
- if (isc_mutex_init(&qid->lock) != ISC_R_SUCCESS) {
- UNEXPECTED_ERROR(__FILE__, __LINE__, "isc_mutex_init failed");
+ result = isc_mutex_init(&qid->lock);
+ if (result != ISC_R_SUCCESS) {
nsid_destroy(mgr->mctx, &qid->nsid);
isc_mem_put(mgr->mctx, qid->qid_table,
buckets * sizeof(dns_displist_t));
isc_mem_put(mgr->mctx, qid, sizeof(*qid));
- return (ISC_R_UNEXPECTED);
+ return (result);
}
for (i = 0; i < buckets; i++)
@@ -1463,7 +1471,7 @@
dns_dispatch_t **dispp)
{
dns_dispatch_t *disp;
- isc_result_t res;
+ isc_result_t result;
REQUIRE(VALID_DISPATCHMGR(mgr));
REQUIRE(dispp != NULL && *dispp == NULL);
@@ -1494,15 +1502,13 @@
disp->tcpbuffers = 0;
disp->qid = NULL;
- if (isc_mutex_init(&disp->lock) != ISC_R_SUCCESS) {
- res = ISC_R_UNEXPECTED;
- UNEXPECTED_ERROR(__FILE__, __LINE__, "isc_mutex_init failed");
+ result = isc_mutex_init(&disp->lock);
+ if (result != ISC_R_SUCCESS)
goto deallocate;
- }
disp->failsafe_ev = allocate_event(disp);
if (disp->failsafe_ev == NULL) {
- res = ISC_R_NOMEMORY;
+ result = ISC_R_NOMEMORY;
goto kill_lock;
}
@@ -1519,7 +1525,7 @@
deallocate:
isc_mempool_put(mgr->dpool, disp);
- return (res);
+ return (result);
}
@@ -1609,8 +1615,10 @@
DNS_EVENT_DISPATCHCONTROL,
destroy_disp, disp,
sizeof(isc_event_t));
- if (disp->ctlevent == NULL)
+ if (disp->ctlevent == NULL) {
+ result = ISC_R_NOMEMORY;
goto kill_task;
+ }
isc_task_setname(disp->task, "tcpdispatch", disp);
@@ -1791,8 +1799,10 @@
DNS_EVENT_DISPATCHCONTROL,
destroy_disp, disp,
sizeof(isc_event_t));
- if (disp->ctlevent == NULL)
+ if (disp->ctlevent == NULL) {
+ result = ISC_R_NOMEMORY;
goto kill_task;
+ }
isc_task_setname(disp->task, "udpdispatch", disp);
Index: validator.h
===================================================================
RCS file: /home/cvs/src/contrib/bind9/lib/dns/include/dns/validator.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -L contrib/bind9/lib/dns/include/dns/validator.h -L contrib/bind9/lib/dns/include/dns/validator.h -u -r1.2 -r1.3
--- contrib/bind9/lib/dns/include/dns/validator.h
+++ contrib/bind9/lib/dns/include/dns/validator.h
@@ -1,8 +1,8 @@
/*
- * Copyright (C) 2004-2006 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2000-2003 Internet Software Consortium.
*
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
*
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: validator.h,v 1.18.12.11.6.1 2007/01/11 04:51:39 marka Exp $ */
+/* $Id: validator.h,v 1.27.18.10 2007/09/26 04:39:45 each Exp $ */
#ifndef DNS_VALIDATOR_H
#define DNS_VALIDATOR_H 1
@@ -81,11 +81,24 @@
ISC_EVENT_COMMON(struct dns_validatorevent);
dns_validator_t * validator;
isc_result_t result;
+ /*
+ * Name and type of the response to be validated.
+ */
dns_name_t * name;
dns_rdatatype_t type;
+ /*
+ * Rdata and RRSIG (if any) for positive responses.
+ */
dns_rdataset_t * rdataset;
dns_rdataset_t * sigrdataset;
+ /*
+ * The full response. Required for negative responses.
+ * Also required for positive wildcard responses.
+ */
dns_message_t * message;
+ /*
+ * Proofs to be cached.
+ */
dns_name_t * proofs[3];
} dns_validatorevent_t;
Index: dispatch.h
===================================================================
RCS file: /home/cvs/src/contrib/bind9/lib/dns/include/dns/dispatch.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -L contrib/bind9/lib/dns/include/dns/dispatch.h -L contrib/bind9/lib/dns/include/dns/dispatch.h -u -r1.2 -r1.3
--- contrib/bind9/lib/dns/include/dns/dispatch.h
+++ contrib/bind9/lib/dns/include/dns/dispatch.h
@@ -1,8 +1,8 @@
/*
- * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
*
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: dispatch.h,v 1.45.2.2.4.2 2004/03/06 08:13:55 marka Exp $ */
+/* $Id: dispatch.h,v 1.48.18.5 2007/08/28 07:20:05 tbox Exp $ */
#ifndef DNS_DISPATCH_H
#define DNS_DISPATCH_H 1
@@ -24,14 +24,14 @@
***** Module Info
*****/
-/*
+/*! \file
+ * \brief
* DNS Dispatch Management
- *
* Shared UDP and single-use TCP dispatches for queries and responses.
*
* MP:
*
- * All locking is performed internally to each dispatch.
+ *\li All locking is performed internally to each dispatch.
* Restrictions apply to dns_dispatch_removeresponse().
*
* Reliability:
@@ -40,12 +40,12 @@
*
* Security:
*
- * Depends on the isc_socket_t and dns_message_t for prevention of
+ *\li Depends on the isc_socket_t and dns_message_t for prevention of
* buffer overruns.
*
* Standards:
*
- * None.
+ *\li None.
*/
/***
@@ -61,7 +61,7 @@
ISC_LANG_BEGINDECLS
-/*
+/*%
* This event is sent to a task when a response comes in.
* No part of this structure should ever be modified by the caller,
* other than parts of the buffer. The holy parts of the buffer are
@@ -79,16 +79,17 @@
*/
struct dns_dispatchevent {
- ISC_EVENT_COMMON(dns_dispatchevent_t); /* standard event common */
- isc_result_t result; /* result code */
- isc_int32_t id; /* message id */
- isc_sockaddr_t addr; /* address recv'd from */
- struct in6_pktinfo pktinfo; /* reply info for v6 */
- isc_buffer_t buffer; /* data buffer */
- isc_uint32_t attributes; /* mirrored from socket.h */
+ ISC_EVENT_COMMON(dns_dispatchevent_t); /*%< standard event common */
+ isc_result_t result; /*%< result code */
+ isc_int32_t id; /*%< message id */
+ isc_sockaddr_t addr; /*%< address recv'd from */
+ struct in6_pktinfo pktinfo; /*%< reply info for v6 */
+ isc_buffer_t buffer; /*%< data buffer */
+ isc_uint32_t attributes; /*%< mirrored from socket.h */
};
-/*
+/*@{*/
+/*%
* Attributes for added dispatchers.
*
* Values with the mask 0xffff0000 are application defined.
@@ -121,83 +122,84 @@
#define DNS_DISPATCHATTR_NOLISTEN 0x00000020U
#define DNS_DISPATCHATTR_MAKEQUERY 0x00000040U
#define DNS_DISPATCHATTR_CONNECTED 0x00000080U
+/*@}*/
isc_result_t
dns_dispatchmgr_create(isc_mem_t *mctx, isc_entropy_t *entropy,
dns_dispatchmgr_t **mgrp);
-/*
+/*%<
* Creates a new dispatchmgr object.
*
* Requires:
- * "mctx" be a valid memory context.
+ *\li "mctx" be a valid memory context.
*
- * mgrp != NULL && *mgrp == NULL
+ *\li mgrp != NULL && *mgrp == NULL
*
- * "entropy" may be NULL, in which case an insecure random generator
+ *\li "entropy" may be NULL, in which case an insecure random generator
* will be used. If it is non-NULL, it must be a valid entropy
* source.
*
* Returns:
- * ISC_R_SUCCESS -- all ok
+ *\li ISC_R_SUCCESS -- all ok
*
- * anything else -- failure
+ *\li anything else -- failure
*/
void
dns_dispatchmgr_destroy(dns_dispatchmgr_t **mgrp);
-/*
+/*%<
* Destroys the dispatchmgr when it becomes empty. This could be
* immediately.
*
* Requires:
- * mgrp != NULL && *mgrp is a valid dispatchmgr.
+ *\li mgrp != NULL && *mgrp is a valid dispatchmgr.
*/
void
dns_dispatchmgr_setblackhole(dns_dispatchmgr_t *mgr, dns_acl_t *blackhole);
-/*
+/*%<
* Sets the dispatcher's "blackhole list," a list of addresses that will
* be ignored by all dispatchers created by the dispatchmgr.
*
* Requires:
- * mgrp is a valid dispatchmgr
- * blackhole is a valid acl
+ * \li mgrp is a valid dispatchmgr
+ * \li blackhole is a valid acl
*/
dns_acl_t *
dns_dispatchmgr_getblackhole(dns_dispatchmgr_t *mgr);
-/*
+/*%<
* Gets a pointer to the dispatcher's current blackhole list,
* without incrementing its reference count.
*
* Requires:
- * mgr is a valid dispatchmgr
+ *\li mgr is a valid dispatchmgr
* Returns:
- * A pointer to the current blackhole list, or NULL.
+ *\li A pointer to the current blackhole list, or NULL.
*/
void
dns_dispatchmgr_setblackportlist(dns_dispatchmgr_t *mgr,
dns_portlist_t *portlist);
-/*
+/*%<
* Sets a list of UDP ports that won't be used when creating a udp
* dispatch with a wildcard port.
*
* Requires:
- * mgr is a valid dispatchmgr
- * portlist to be NULL or a valid port list.
+ *\li mgr is a valid dispatchmgr
+ *\li portlist to be NULL or a valid port list.
*/
dns_portlist_t *
dns_dispatchmgr_getblackportlist(dns_dispatchmgr_t *mgr);
-/*
+/*%<
* Return the current port list.
*
* Requires:
- * mgr is a valid dispatchmgr
+ *\li mgr is a valid dispatchmgr
*/
@@ -210,29 +212,29 @@
unsigned int buckets, unsigned int increment,
unsigned int attributes, unsigned int mask,
dns_dispatch_t **dispp);
-/*
+/*%<
* Attach to existing dns_dispatch_t if one is found with dns_dispatchmgr_find,
* otherwise create a new UDP dispatch.
*
* Requires:
- * All pointer parameters be valid for their respective types.
+ *\li All pointer parameters be valid for their respective types.
*
- * dispp != NULL && *disp == NULL
+ *\li dispp != NULL && *disp == NULL
*
- * 512 <= buffersize <= 64k
+ *\li 512 <= buffersize <= 64k
*
- * maxbuffers > 0
+ *\li maxbuffers > 0
*
- * buckets < 2097169
+ *\li buckets < 2097169
*
- * increment > buckets
+ *\li increment > buckets
*
- * (attributes & DNS_DISPATCHATTR_TCP) == 0
+ *\li (attributes & DNS_DISPATCHATTR_TCP) == 0
*
* Returns:
- * ISC_R_SUCCESS -- success.
+ *\li ISC_R_SUCCESS -- success.
*
- * Anything else -- failure.
+ *\li Anything else -- failure.
*/
isc_result_t
@@ -241,7 +243,7 @@
unsigned int maxbuffers, unsigned int maxrequests,
unsigned int buckets, unsigned int increment,
unsigned int attributes, dns_dispatch_t **dispp);
-/*
+/*%<
* Create a new dns_dispatch and attach it to the provided isc_socket_t.
*
* For all dispatches, "buffersize" is the maximum packet size we will
@@ -258,65 +260,65 @@
*
* Requires:
*
- * mgr is a valid dispatch manager.
+ *\li mgr is a valid dispatch manager.
*
- * sock is a valid.
+ *\li sock is a valid.
*
- * task is a valid task that can be used internally to this dispatcher.
+ *\li task is a valid task that can be used internally to this dispatcher.
*
- * 512 <= buffersize <= 64k
+ * \li 512 <= buffersize <= 64k
*
- * maxbuffers > 0.
+ *\li maxbuffers > 0.
*
- * maxrequests <= maxbuffers.
+ *\li maxrequests <= maxbuffers.
*
- * buckets < 2097169 (the next prime after 65536 * 32)
+ *\li buckets < 2097169 (the next prime after 65536 * 32)
*
- * increment > buckets (and prime).
+ *\li increment > buckets (and prime).
*
- * attributes includes DNS_DISPATCHATTR_TCP and does not include
- * DNS_DISPATCHATTR_UDP.
+ *\li attributes includes #DNS_DISPATCHATTR_TCP and does not include
+ * #DNS_DISPATCHATTR_UDP.
*
* Returns:
- * ISC_R_SUCCESS -- success.
+ *\li ISC_R_SUCCESS -- success.
*
- * Anything else -- failure.
+ *\li Anything else -- failure.
*/
void
dns_dispatch_attach(dns_dispatch_t *disp, dns_dispatch_t **dispp);
-/*
+/*%<
* Attach to a dispatch handle.
*
* Requires:
- * disp is valid.
+ *\li disp is valid.
*
- * dispp != NULL && *dispp == NULL
+ *\li dispp != NULL && *dispp == NULL
*/
void
dns_dispatch_detach(dns_dispatch_t **dispp);
-/*
+/*%<
* Detaches from the dispatch.
*
* Requires:
- * dispp != NULL and *dispp be a valid dispatch.
+ *\li dispp != NULL and *dispp be a valid dispatch.
*/
void
dns_dispatch_starttcp(dns_dispatch_t *disp);
-/*
+/*%<
* Start processing of a TCP dispatch once the socket connects.
*
* Requires:
- * 'disp' is valid.
+ *\li 'disp' is valid.
*/
isc_result_t
dns_dispatch_addresponse(dns_dispatch_t *disp, isc_sockaddr_t *dest,
isc_task_t *task, isc_taskaction_t action, void *arg,
isc_uint16_t *idp, dns_dispentry_t **resp);
-/*
+/*%<
* Add a response entry for this dispatch.
*
* "*idp" is filled in with the assigned message ID, and *resp is filled in
@@ -327,24 +329,24 @@
* or through dns_dispatch_removeresponse() for another to be delivered.
*
* Requires:
- * "idp" be non-NULL.
+ *\li "idp" be non-NULL.
*
- * "task" "action" and "arg" be set as appropriate.
+ *\li "task" "action" and "arg" be set as appropriate.
*
- * "dest" be non-NULL and valid.
+ *\li "dest" be non-NULL and valid.
*
- * "resp" be non-NULL and *resp be NULL
+ *\li "resp" be non-NULL and *resp be NULL
*
* Ensures:
*
- * <id, dest> is a unique tuple. That means incoming messages
+ *\li <id, dest> is a unique tuple. That means incoming messages
* are identifiable.
*
* Returns:
*
- * ISC_R_SUCCESS -- all is well.
- * ISC_R_NOMEMORY -- memory could not be allocated.
- * ISC_R_NOMORE -- no more message ids can be allocated
+ *\li ISC_R_SUCCESS -- all is well.
+ *\li ISC_R_NOMEMORY -- memory could not be allocated.
+ *\li ISC_R_NOMORE -- no more message ids can be allocated
* for this destination.
*/
@@ -352,88 +354,90 @@
void
dns_dispatch_removeresponse(dns_dispentry_t **resp,
dns_dispatchevent_t **sockevent);
-/*
+/*%<
* Stops the flow of responses for the provided id and destination.
* If "sockevent" is non-NULL, the dispatch event and associated buffer is
* also returned to the system.
*
* Requires:
- * "resp" != NULL and "*resp" contain a value previously allocated
+ *\li "resp" != NULL and "*resp" contain a value previously allocated
* by dns_dispatch_addresponse();
*
- * May only be called from within the task given as the 'task'
+ *\li May only be called from within the task given as the 'task'
* argument to dns_dispatch_addresponse() when allocating '*resp'.
*/
isc_socket_t *
dns_dispatch_getsocket(dns_dispatch_t *disp);
-/*
+/*%<
* Return the socket associated with this dispatcher.
*
* Requires:
- * disp is valid.
+ *\li disp is valid.
*
* Returns:
- * The socket the dispatcher is using.
+ *\li The socket the dispatcher is using.
*/
isc_result_t
dns_dispatch_getlocaladdress(dns_dispatch_t *disp, isc_sockaddr_t *addrp);
-/*
+/*%<
* Return the local address for this dispatch.
* This currently only works for dispatches using UDP sockets.
*
* Requires:
- * disp is valid.
- * addrp to be non null.
+ *\li disp is valid.
+ *\li addrp to be non null.
*
* Returns:
- * ISC_R_SUCCESS
- * ISC_R_NOTIMPLEMENTED
+ *\li ISC_R_SUCCESS
+ *\li ISC_R_NOTIMPLEMENTED
*/
void
dns_dispatch_cancel(dns_dispatch_t *disp);
-/*
+/*%<
* cancel outstanding clients
*
* Requires:
- * disp is valid.
+ *\li disp is valid.
*/
void
dns_dispatch_changeattributes(dns_dispatch_t *disp,
unsigned int attributes, unsigned int mask);
-/*
+/*%<
* Set the bits described by "mask" to the corresponding values in
* "attributes".
*
* That is:
*
+ * \code
* new = (old & ~mask) | (attributes & mask)
+ * \endcode
*
- * This function has a side effect when DNS_DISPATCHATTR_NOLISTEN changes.
+ * This function has a side effect when #DNS_DISPATCHATTR_NOLISTEN changes.
* When the flag becomes off, the dispatch will start receiving on the
* corresponding socket. When the flag becomes on, receive events on the
* corresponding socket will be canceled.
*
* Requires:
- * disp is valid.
+ *\li disp is valid.
*
- * attributes are reasonable for the dispatch. That is, setting the UDP
+ *\li attributes are reasonable for the dispatch. That is, setting the UDP
* attribute on a TCP socket isn't reasonable.
*/
void
dns_dispatch_importrecv(dns_dispatch_t *disp, isc_event_t *event);
-/*
+/*%<
* Inform the dispatcher of a socket receive. This is used for sockets
* shared between dispatchers and clients. If the dispatcher fails to copy
* or send the event, nothing happens.
*
* Requires:
- * disp is valid, and the attribute DNS_DISPATCHATTR_NOLISTEN is set.
+ *\li disp is valid, and the attribute DNS_DISPATCHATTR_NOLISTEN is set.
* event != NULL
*/
More information about the Midnightbsd-cvs
mailing list