upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-04-02 15:56:52 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

This commit was manufactured by cvs2git to create branch 'v9_3'.

Browse source
This commit is contained in:
cvs2git 2006-09-28 05:46:20 +00:00
commit f7545a00e6
10 changed files with 6265 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
contrib/dbus/Makefile.9.3.2b1 Normal file
View file

@ -0,0 +1,20 @@
# contrib/dbus/Makefile
#
# This Makefile will install D-BUS support into the ISC BIND 9.3.2b1+ source,
# necessary to support dynamic forwarding table management with D-BUS, for
# Red Hat NetworkManager support.
#
# After running "make" in this directory, simply run make in the top level
# BIND source directory, and D-BUS support will be enabled.
#
all:
echo 'Enabling D-BUS support...'
@ cp -fp dbus_mgr.c dbus_service.c ../../bin/named;
@ cp -fp dbus_mgr.h dbus_service.h ../../bin/named/include/named;
@ cp -fp README.DBUS ../../doc/misc
@ cd ../..; patch -s -p1 -b --suffix=.dbus < contrib/dbus/bind-9.3.2b1-dbus.patch
install:
install -o root -g root -m 640 named-dbus-system.conf /etc/dbus-1/system.d/named.conf
install -o root -g root -m 640 named-dbus.service /usr/share/dbus-1/services/named.service

20
contrib/dbus/Makefile.9.3.3rc2 Normal file
View file

@ -0,0 +1,20 @@
# contrib/dbus/Makefile
#
# This Makefile will install D-BUS support into the ISC BIND 9.3.2b1+ source,
# necessary to support dynamic forwarding table management with D-BUS, for
# Red Hat NetworkManager support.
#
# After running "make" in this directory, simply run make in the top level
# BIND source directory, and D-BUS support will be enabled.
#
all:
echo 'Enabling D-BUS support...'
@ cp -fp dbus_mgr.c dbus_service.c ../../bin/named;
@ cp -fp dbus_mgr.h dbus_service.h ../../bin/named/include/named;
@ cp -fp README.DBUS ../../doc/misc
@ cd ../..; patch -s -p1 -b --suffix=.dbus < contrib/dbus/bind-9.3.3rc2-dbus.patch
install:
install -o root -g root -m 640 named-dbus-system.conf /etc/dbus-1/system.d/named.conf
install -o root -g root -m 640 named-dbus.service /usr/share/dbus-1/services/named.service

778
contrib/dbus/bind-9.3.3rc2-dbus.patch Normal file
View file

@ -0,0 +1,778 @@
--- bind-9.3.3rc2/lib/dns/forward.c.dbus 2005-03-17 04:58:30.000000000 +0100
+++ bind-9.3.3rc2/lib/dns/forward.c 2006-09-18 10:08:37.000000000 +0200
@@ -200,3 +200,89 @@
}
isc_mem_put(fwdtable->mctx, forwarders, sizeof(dns_forwarders_t));
}
+
+/***
+ *** new D-BUS Dynamic Forwarding Zones functions:
+ ***/
+isc_result_t
+dns_fwdtable_delete(dns_fwdtable_t *fwdtable, dns_name_t *name )
+{
+ isc_result_t result;
+
+ REQUIRE(VALID_FWDTABLE(fwdtable));
+
+ RWLOCK(&fwdtable->rwlock, isc_rwlocktype_write);
+
+ result = dns_rbt_deletename(fwdtable->table, name, ISC_FALSE);
+
+ RWUNLOCK(&fwdtable->rwlock, isc_rwlocktype_write);
+
+ return (result);
+}
+
+isc_result_t
+dns_fwdtable_find_closest(dns_fwdtable_t *fwdtable,
+ dns_name_t *name,
+ dns_name_t *foundname,
+ dns_forwarders_t **forwardersp)
+{
+ isc_result_t result;
+
+ REQUIRE(VALID_FWDTABLE(fwdtable));
+
+ RWLOCK(&fwdtable->rwlock, isc_rwlocktype_read);
+
+ result = dns_rbt_findname(fwdtable->table, name, 0, foundname,
+ (void **)forwardersp);
+
+ if(result == DNS_R_PARTIALMATCH)
+ result = ISC_R_SUCCESS;
+
+ RWUNLOCK(&fwdtable->rwlock, isc_rwlocktype_read);
+
+ return (result);
+}
+
+isc_result_t
+dns_fwdtable_find_exact(dns_fwdtable_t *fwdtable, dns_name_t *name,
+ dns_forwarders_t **forwardersp)
+{
+ isc_result_t result;
+
+ REQUIRE(VALID_FWDTABLE(fwdtable));
+
+ REQUIRE(forwardersp != 0L);
+
+ RWLOCK(&fwdtable->rwlock, isc_rwlocktype_read);
+
+ result = dns_rbt_findname(fwdtable->table, name, 0, NULL,
+ (void **)forwardersp);
+
+ if( result != ISC_R_SUCCESS )
+ *forwardersp = 0L;
+
+ RWUNLOCK(&fwdtable->rwlock, isc_rwlocktype_read);
+
+ return (result);
+}
+
+static
+void dns_fwdtable_traverse
+(
+ dns_name_t *name,
+ void *node_data,
+ void *cbp,
+ void *cb_arg
+)
+{
+ dns_fwdtable_callback_t cb = (dns_fwdtable_callback_t) cbp;
+
+ (*cb)( name, node_data, cb_arg);
+}
+
+void dns_fwdtable_foreach(dns_fwdtable_t *fwdtable, dns_fwdtable_callback_t cb, void *cb_arg )
+{
+ REQUIRE(VALID_FWDTABLE(fwdtable));
+
+ dns_rbt_traverse( fwdtable->table, dns_fwdtable_traverse, cb, cb_arg );
+}
--- bind-9.3.3rc2/lib/dns/include/dns/forward.h.dbus 2005-03-17 04:58:31.000000000 +0100
+++ bind-9.3.3rc2/lib/dns/include/dns/forward.h 2006-09-18 10:08:37.000000000 +0200
@@ -98,6 +98,37 @@
* all memory associated with the forwarding table is freed.
*/
+
+/* These are ONLY used by dbus_mgr :
+ */
+
+isc_result_t
+dns_fwdtable_delete( dns_fwdtable_t *fwdtable, dns_name_t *name );
+/*
+ * Removes an entry from the forwarding table.
+ */
+
+isc_result_t
+dns_fwdtable_find_exact(dns_fwdtable_t *fwdtable, dns_name_t *name,
+ dns_forwarders_t **forwardersp);
+/*
+ * Finds an exact match for "name" in the forwarding table.
+ */
+
+isc_result_t
+dns_fwdtable_find_closest(dns_fwdtable_t *fwdtable, dns_name_t *name, dns_name_t *foundname,
+ dns_forwarders_t **forwardersp);
+/*
+ * Finds the closest match for "*name" in the forwarding table, returning
+ * the actual name matching in *name if different to *name passed in.
+ */
+
+typedef void (*dns_fwdtable_callback_t)( dns_name_t *, dns_forwarders_t *, void *);
+void dns_fwdtable_foreach(dns_fwdtable_t *fwdtable, dns_fwdtable_callback_t cb, void * );
+/* Invoke cb for each member of fwdtable
+ */
+
+
ISC_LANG_ENDDECLS
#endif /* DNS_FORWARD_H */
--- bind-9.3.3rc2/lib/dns/include/dns/rbt.h.dbus 2004-10-11 07:55:51.000000000 +0200
+++ bind-9.3.3rc2/lib/dns/include/dns/rbt.h 2006-09-18 10:08:37.000000000 +0200
@@ -833,6 +833,17 @@
* <something_else> Any error result from dns_name_concatenate.
*/
+
+typedef void (*dns_rbt_traverse_callback_t)( dns_name_t *name,
+ void *node_data,
+ void *cb_arg1,
+ void *cb_arg2);
+
+void dns_rbt_traverse( dns_rbt_t *rbt, dns_rbt_traverse_callback_t cb, void *cb_arg1, void *cb_arg2 );
+/* tree traversal function (only used by D-BUS dynamic forwarding dbus_mgr at
+ * the moment)
+ */
+
ISC_LANG_ENDDECLS
#endif /* DNS_RBT_H */
--- bind-9.3.3rc2/lib/dns/rbt.c.dbus 2005-06-18 03:03:24.000000000 +0200
+++ bind-9.3.3rc2/lib/dns/rbt.c 2006-09-18 10:08:37.000000000 +0200
@@ -2172,6 +2172,47 @@
dns_rbt_printtree(rbt->root, NULL, 0);
}
+static void
+dns_rbt_traverse_tree(dns_rbtnode_t *root, dns_rbt_traverse_callback_t cb, void *cb_arg1, void *cb_arg2 ) {
+/*
+ * This is used ONLY to traverse the forward table by dbus_mgr at the moment.
+ * Since the forward table is not likely to be large, this can be recursive.
+ */
+ dns_name_t name;
+ dns_offsets_t offsets;
+ char buf[DNS_NAME_MAXWIRE];
+ isc_buffer_t buffer;
+
+ if (root != NULL) {
+
+ if (DOWN(root))
+ dns_rbt_traverse_tree(DOWN(root), cb, cb_arg1, cb_arg2);
+
+ if( LEFT(root) != NULL )
+ dns_rbt_traverse_tree(LEFT(root), cb, cb_arg1, cb_arg2);
+
+ if( RIGHT(root) != NULL )
+ dns_rbt_traverse_tree(RIGHT(root), cb, cb_arg1, cb_arg2);
+
+ if( DATA(root) == 0L )
+ return;
+
+ dns_name_init(&name, offsets);
+ isc_buffer_init(&buffer, buf, DNS_NAME_MAXWIRE);
+ dns_name_setbuffer( &name, &buffer);
+ dns_rbt_fullnamefromnode(root, &name);
+
+ (*cb)(&name, DATA(root), cb_arg1, cb_arg2);
+ }
+}
+
+void dns_rbt_traverse( dns_rbt_t *rbt, dns_rbt_traverse_callback_t cb, void *cb_arg1, void *cb_arg2 )
+{
+ REQUIRE(VALID_RBT(rbt));
+
+ dns_rbt_traverse_tree( rbt->root, cb, cb_arg1, cb_arg2 );
+}
+
/*
* Chain Functions
*/
--- bind-9.3.3rc2/lib/isc/include/isc/socket.h.dbus 2004-03-08 10:04:53.000000000 +0100
+++ bind-9.3.3rc2/lib/isc/include/isc/socket.h 2006-09-18 10:08:37.000000000 +0200
@@ -136,6 +136,10 @@
#define ISC_SOCKEVENT_NEWCONN (ISC_EVENTCLASS_SOCKET + 3)
#define ISC_SOCKEVENT_CONNECT (ISC_EVENTCLASS_SOCKET + 4)
+#define ISC_SOCKEVENT_READ_READY (ISC_EVENTCLASS_SOCKET + 5)
+#define ISC_SOCKEVENT_WRITE_READY (ISC_EVENTCLASS_SOCKET + 6)
+#define ISC_SOCKEVENT_SELECTED (ISC_EVENTCLASS_SOCKET + 7)
+
/*
* Internal events.
*/
@@ -144,7 +148,8 @@
typedef enum {
isc_sockettype_udp = 1,
- isc_sockettype_tcp = 2
+ isc_sockettype_tcp = 2,
+ isc_sockettype_fd = 8
} isc_sockettype_t;
/*
@@ -699,6 +704,30 @@
* 'sock' is a valid socket.
*/
+isc_socketevent_t*
+isc_socket_fd_handle_reads( isc_socket_t *sock, isc_socketevent_t *dev );
+/* register the "dev" event to be sent when the isc_sockettype_fd sock
+ * was select()-ed for read. If there is already an event registered, it
+ * is returned, otherwise 0 is returned. If dev is 0, removes any existing
+ * registered event.
+ */
+
+isc_socketevent_t*
+isc_socket_fd_handle_writes( isc_socket_t *sock, isc_socketevent_t *dev );
+/* register the "dev" event to be sent when the isc_sockettype_fd sock
+ * was select()-ed for write. If there is already an event registered, it
+ * is returned, otherwise 0 is returned. If dev is 0, removes any existing
+ * registered event.
+ */
+
+isc_socketevent_t*
+isc_socket_fd_handle_selected( isc_socket_t *sock, isc_socketevent_t *dev );
+/* register the "dev" event to be sent when ALL isc_sockettype_fd sockets
+ * have been select()-ed . If there is already an event registered, it
+ * is returned, otherwise 0 is returned. If dev is 0, removes any existing
+ * registered event.
+ */
+
ISC_LANG_ENDDECLS
#endif /* ISC_SOCKET_H */
--- bind-9.3.3rc2/lib/isc/unix/socket.c.dbus 2006-05-19 04:53:36.000000000 +0200
+++ bind-9.3.3rc2/lib/isc/unix/socket.c 2006-09-18 10:08:37.000000000 +0200
@@ -148,6 +148,11 @@
ISC_LIST(isc_socketevent_t) recv_list;
ISC_LIST(isc_socket_newconnev_t) accept_list;
isc_socket_connev_t *connect_ev;
+
+ /* these are used only by isc_sockettype_fd sockets:*/
+ isc_socketevent_t *read_ready_event;
+ isc_socketevent_t *write_ready_event;
+ isc_socketevent_t *selected_event;
/*
* Internal events. Posted when a descriptor is readable or
@@ -304,7 +309,7 @@
static void
wakeup_socket(isc_socketmgr_t *manager, int fd, int msg) {
- isc_socket_t *sock;
+ isc_socket_t *sock=0L;
/*
* This is a wakeup on a socket. If the socket is not in the
@@ -1289,6 +1294,9 @@
sock->connected = 0;
sock->connecting = 0;
sock->bound = 0;
+ sock->read_ready_event = 0L;
+ sock->write_ready_event = 0L;
+ sock->selected_event = 0L;
/*
* initialize the lock
@@ -1401,13 +1409,16 @@
case isc_sockettype_tcp:
sock->fd = socket(pf, SOCK_STREAM, IPPROTO_TCP);
break;
+
+ case isc_sockettype_fd:
+ sock->fd = pf;
}
#ifdef F_DUPFD
/*
* Leave a space for stdio to work in.
*/
- if (sock->fd >= 0 && sock->fd < 20) {
+ if ( (type != isc_sockettype_fd) && (sock->fd >= 0) && (sock->fd < 20) ) {
int new, tmp;
new = fcntl(sock->fd, F_DUPFD, 20);
tmp = errno;
@@ -1461,7 +1472,7 @@
}
}
- if (make_nonblock(sock->fd) != ISC_R_SUCCESS) {
+ if ((type != isc_sockettype_fd) && (make_nonblock(sock->fd) != ISC_R_SUCCESS)) {
(void)close(sock->fd);
free_socket(&sock);
return (ISC_R_UNEXPECTED);
@@ -1729,6 +1740,38 @@
isc_task_send(ev->ev_sender, (isc_event_t **)&iev);
}
+static
+isc_event_t *dispatch_read_ready(isc_socketmgr_t *manager, isc_socket_t *sock)
+{
+ isc_event_t *dev = (isc_event_t*)sock->read_ready_event, *ev;
+
+ ev = isc_mem_get(manager->mctx, dev->ev_size);
+ memcpy(ev,dev,dev->ev_size);
+ ISC_LINK_INIT(ev,ev_link);
+ isc_task_send(dev->ev_sender, &ev );
+ return (isc_event_t *)sock->selected_event;
+}
+
+static
+isc_event_t *dispatch_write_ready(isc_socketmgr_t *manager,isc_socket_t *sock)
+{
+ isc_event_t *dev = (isc_event_t*)sock->write_ready_event, *ev;
+ ev = isc_mem_get(manager->mctx, dev->ev_size);
+ memcpy(ev,dev,dev->ev_size);
+ ISC_LINK_INIT(ev,ev_link);
+ isc_task_send(dev->ev_sender, &ev );
+ return (isc_event_t *)sock->selected_event;
+}
+
+static
+void dispatch_selected(isc_socketmgr_t *manager, isc_event_t *dev)
+{ isc_event_t *ev;
+ ev = isc_mem_get(manager->mctx, dev->ev_size);
+ memcpy(ev,dev,dev->ev_size);
+ ISC_LINK_INIT(ev,ev_link);
+ isc_task_send(dev->ev_sender, &ev );
+}
+
/*
* Dequeue an item off the given socket's read queue, set the result code
* in the done event to the one provided, and send it to the task it was
@@ -2136,6 +2179,7 @@
int i;
isc_socket_t *sock;
isc_boolean_t unlock_sock;
+ isc_event_t *sock_selected = 0L;
REQUIRE(maxfd <= (int)FD_SETSIZE);
@@ -2169,11 +2213,15 @@
unlock_sock = ISC_TRUE;
LOCK(&sock->lock);
if (!SOCK_DEAD(sock)) {
+ if( sock->type != isc_sockettype_fd )
+ {
if (sock->listener)
dispatch_accept(sock);
else
dispatch_recv(sock);
- }
+ }else
+ sock_selected = dispatch_read_ready(manager,sock);
+ }
FD_CLR(i, &manager->read_fds);
}
check_write:
@@ -2187,16 +2235,24 @@
LOCK(&sock->lock);
}
if (!SOCK_DEAD(sock)) {
+ if( sock->type != isc_sockettype_fd )
+ {
if (sock->connecting)
dispatch_connect(sock);
else
dispatch_send(sock);
+ }else
+ sock_selected = dispatch_write_ready(manager,sock);
}
FD_CLR(i, &manager->write_fds);
}
if (unlock_sock)
UNLOCK(&sock->lock);
}
+ if( sock_selected != 0L )
+ {
+ dispatch_selected(manager, sock_selected);
+ }
}
#ifdef ISC_PLATFORM_USETHREADS
@@ -2215,7 +2271,7 @@
int cc;
fd_set readfds;
fd_set writefds;
- int msg, fd;
+ int msg, fd = -1;
int maxfd;
char strbuf[ISC_STRERRORSIZE];
@@ -3546,3 +3602,55 @@
return (ISC_R_SUCCESS);
}
#endif /* ISC_PLATFORM_USETHREADS */
+
+isc_socketevent_t*
+isc_socket_fd_handle_reads( isc_socket_t *sock, isc_socketevent_t *dev )
+{
+ REQUIRE(VALID_SOCKET(sock));
+ if(dev != 0L)
+ {
+ sock->references=1;
+ sock->read_ready_event = dev;
+ select_poke(sock->manager, sock->fd, SELECT_POKE_READ);
+ }else
+ {
+ dev = sock->read_ready_event ;
+ sock->read_ready_event = 0L ;
+ }
+ return dev;
+}
+
+isc_socketevent_t*
+isc_socket_fd_handle_writes( isc_socket_t *sock, isc_socketevent_t *dev )
+{
+ REQUIRE(VALID_SOCKET(sock));
+ if(dev != 0L)
+ {
+ sock->references=1;
+ sock->write_ready_event = dev;
+ select_poke(sock->manager, sock->fd, SELECT_POKE_WRITE);
+ }else
+ {
+ dev = sock->write_ready_event;
+ sock->write_ready_event = 0L;
+ }
+ return dev;
+}
+
+isc_socketevent_t*
+isc_socket_fd_handle_selected( isc_socket_t *sock, isc_socketevent_t *dev )
+{
+ REQUIRE(VALID_SOCKET(sock));
+ if(dev != 0L)
+ {
+ sock->references=1;
+ sock->selected_event = dev;
+ }else
+ {
+ dev = sock->selected_event;
+ sock->selected_event = 0L;
+ sock->references=0;
+ destroy(&sock);
+ }
+ return dev;
+}
--- bind-9.3.3rc2/bin/named/named.8.dbus 2006-06-29 15:02:30.000000000 +0200
+++ bind-9.3.3rc2/bin/named/named.8 2006-09-18 10:08:37.000000000 +0200
@@ -33,7 +33,7 @@
named \- Internet domain name server
.SH "SYNOPSIS"
.HP 6
-\fBnamed\fR [\fB\-4\fR] [\fB\-6\fR] [\fB\-c\ \fR\fB\fIconfig\-file\fR\fR] [\fB\-d\ \fR\fB\fIdebug\-level\fR\fR] [\fB\-f\fR] [\fB\-g\fR] [\fB\-n\ \fR\fB\fI#cpus\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-s\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR] [\fB\-v\fR] [\fB\-x\ \fR\fB\fIcache\-file\fR\fR]
+\fBnamed\fR [\fB\-4\fR] [\fB\-6\fR] [\fB\-c\ \fR\fB\fIconfig\-file\fR\fR] [\fB\-d\ \fR\fB\fIdebug\-level\fR\fR] [\fB\-f\fR] [\fB\-g\fR] [\fB\-n\ \fR\fB\fI#cpus\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-s\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR] [\fB\-v\fR] [\fB\-x\ \fR\fB\fIcache\-file\fR\fR] [\fB\-D\fR]
.SH "DESCRIPTION"
.PP
\fBnamed\fR
@@ -146,6 +146,13 @@
.B "Warning:"
This option must not be used. It is only of interest to BIND 9 developers and may be removed or changed in a future release.
.RE
+.sp
+.TP
+\fB\-D\fR
+Enable dynamic management of the forwarding table with D-BUS
+messages. This option is required for Red Hat NetworkManager
+support. See doc/README.DBUS .
+.sp
.SH "SIGNALS"
.PP
In routine operation, signals should not be used to control the nameserver;
@@ -165,6 +172,73 @@
\fBnamed\fR
configuration file is too complex to describe in detail here. A complete description is provided in the
BIND 9 Administrator Reference Manual.
+.PP
+.SH "NOTES"
+.PP
+.TP
+\fBRed Hat SELinux BIND Security Profile:\fR
+.PP
+By default, Red Hat ships BIND with the most secure SELinux policy
+that will not prevent normal BIND operation and will prevent exploitation
+of all known BIND security vulnerabilities . See the selinux(8) man page
+for information about SElinux.
+.PP
+It is not necessary to run named in a chroot environment if the Red Hat
+SELinux policy for named is enabled. When enabled, this policy is far
+more secure than a chroot environment.
+.PP
+With this extra security comes some restrictions:
+.br
+By default, the SELinux policy does not allow named to write any master
+zone database files. Only the root user may create files in the $ROOTDIR/var/named
+zone database file directory (the options { "directory" } option), where
+$ROOTDIR is set in /etc/sysconfig/named.
+.br
+The "named" group must be granted read privelege to
+these files in order for named to be enabled to read them.
+.br
+Any file created in the zone database file directory is automatically assigned
+the SELinux file context named_zone_t .
+.br
+By default, SELinux prevents any role from modifying named_zone_t files; this
+means that files in the zone database directory cannot be modified by dynamic
+DNS (DDNS) updates or zone transfers.
+.br
+The Red Hat BIND distribution and SELinux policy creates two directories where
+named is allowed to create and modify files: $ROOTDIR/var/named/slaves and
+$ROOTDIR/var/named/data. By placing files you want named to modify, such as
+slave or DDNS updateable zone files and database / statistics dump files in
+these directories, named will work normally and no further operator action is
+required. Files in these directories are automatically assigned the 'named_cache_t'
+file context, which SELinux allows named to write.
+.br
+You can enable the named_t domain to write and create named_zone_t files by use
+of the SELinux tunable boolean variable "named_write_master_zones", using the
+setsebool(8) command or the system-config-security GUI . If you do this, you
+must also set the ENABLE_ZONE_WRITE variable in /etc/sysconfig/named to
+1 / yes to set the ownership of files in the $ROOTDIR/var/named directory
+to named:named in order for named to be allowed to write them.
+.PP
+\fBRed Hat BIND named_sdb SDB support:\fR
+.PP
+Red Hat ships the bind-sdb RPM that provides the /usr/sbin/named_sdb program,
+which is named compiled with the Simplified Database Backend modules that ISC
+provides in the "contrib/sdb" directory.
+.br
+The SDB modules for LDAP, PostGreSQL and DirDB are compiled into named_sdb.
+.br
+To run named_sdb, set the ENABLE_SDB variable in /etc/sysconfig/named to 1 or "yes",
+and then the "service named start" named initscript will run named_sdb instead
+of named .
+.br
+See the documentation for the various SDB modules in /usr/share/doc/bind-sdb-*/ .
+.PP
+\fBRed Hat system-config-bind:\fR
+.PP
+Red Hat provides the system-config-bind GUI to configure named.conf and zone
+database files. Run the "system-config-bind" command and access the manual
+by selecting the Help menu.
+.PP
.SH "FILES"
.TP 3n
\fI/etc/named.conf\fR
--- bind-9.3.3rc2/bin/named/include/named/globals.h.dbus 2006-03-02 01:37:20.000000000 +0100
+++ bind-9.3.3rc2/bin/named/include/named/globals.h 2006-09-18 10:08:37.000000000 +0200
@@ -112,6 +112,8 @@
EXTERN int ns_g_listen INIT(3);
+EXTERN int ns_g_dbus INIT(0);
+
#undef EXTERN
#undef INIT
--- bind-9.3.3rc2/bin/named/include/named/log.h.dbus 2004-03-08 05:04:21.000000000 +0100
+++ bind-9.3.3rc2/bin/named/include/named/log.h 2006-09-18 10:08:37.000000000 +0200
@@ -34,6 +34,7 @@
#define NS_LOGCATEGORY_QUERIES (&ns_g_categories[4])
#define NS_LOGCATEGORY_UNMATCHED (&ns_g_categories[5])
#define NS_LOGCATEGORY_UPDATE_SECURITY (&ns_g_categories[6])
+#define NS_LOGCATEGORY_DBUS (&ns_g_categories[7])
/*
* Backwards compatibility.
@@ -51,6 +52,7 @@
#define NS_LOGMODULE_NOTIFY (&ns_g_modules[8])
#define NS_LOGMODULE_CONTROL (&ns_g_modules[9])
#define NS_LOGMODULE_LWRESD (&ns_g_modules[10])
+#define NS_LOGMODULE_DBUS (&ns_g_modules[11])
isc_result_t
ns_log_init(isc_boolean_t safe);
--- bind-9.3.3rc2/bin/named/include/named/server.h.dbus 2006-03-02 01:37:20.000000000 +0100
+++ bind-9.3.3rc2/bin/named/include/named/server.h 2006-09-18 10:08:37.000000000 +0200
@@ -91,7 +91,8 @@
ns_controls_t * controls; /* Control channels */
unsigned int dispatchgen;
ns_dispatchlist_t dispatches;
-
+
+ ns_dbus_mgr_t * dbus_mgr;
};
#define NS_SERVER_MAGIC ISC_MAGIC('S','V','E','R')
--- bind-9.3.3rc2/bin/named/include/named/types.h.dbus 2004-03-06 11:21:26.000000000 +0100
+++ bind-9.3.3rc2/bin/named/include/named/types.h 2006-09-18 10:08:37.000000000 +0200
@@ -38,4 +38,6 @@
typedef struct ns_dispatch ns_dispatch_t;
typedef ISC_LIST(ns_dispatch_t) ns_dispatchlist_t;
+typedef struct ns_dbus_mgr ns_dbus_mgr_t ;
+
#endif /* NAMED_TYPES_H */
--- bind-9.3.3rc2/bin/named/log.c.dbus 2005-05-25 01:58:17.000000000 +0200
+++ bind-9.3.3rc2/bin/named/log.c 2006-09-18 10:08:37.000000000 +0200
@@ -41,6 +41,7 @@
{ "queries", 0 },
{ "unmatched", 0 },
{ "update-security", 0 },
+ { "dbus", 0 },
{ NULL, 0 }
};
@@ -60,6 +61,7 @@
{ "notify", 0 },
{ "control", 0 },
{ "lwresd", 0 },
+ { "dbus", 0 },
{ NULL, 0 }
};
--- bind-9.3.3rc2/bin/named/main.c.dbus 2006-01-06 01:01:42.000000000 +0100
+++ bind-9.3.3rc2/bin/named/main.c 2006-09-18 10:08:37.000000000 +0200
@@ -239,7 +239,8 @@
"usage: named [-4|-6] [-c conffile] [-d debuglevel] "
"[-f|-g] [-n number_of_cpus]\n"
" [-p port] [-s] [-t chrootdir] [-u username]\n"
- " [-m {usage|trace|record}]\n");
+ " [-m {usage|trace|record}]\n"
+ " [-D ]\n");
}
static void
@@ -345,7 +346,7 @@
isc_commandline_errprint = ISC_FALSE;
while ((ch = isc_commandline_parse(argc, argv,
- "46c:C:d:fgi:lm:n:N:p:P:st:u:vx:")) != -1) {
+ "46c:C:d:fgi:lm:n:N:p:P:st:u:vx:D")) != -1) {
switch (ch) {
case '4':
if (disable4)
@@ -434,6 +435,9 @@
case 'v':
printf("BIND %s\n", ns_g_version);
exit(0);
+ case 'D':
+ ns_g_dbus = 1;
+ break;
case '?':
usage();
ns_main_earlyfatal("unknown option '-%c'",
--- bind-9.3.3rc2/bin/named/server.c.dbus 2006-05-24 06:30:24.000000000 +0200
+++ bind-9.3.3rc2/bin/named/server.c 2006-09-18 10:08:37.000000000 +0200
@@ -86,6 +86,8 @@
#include <stdlib.h>
#endif
+#include <named/dbus_mgr.h>
+
/*
* Check an operation for failure. Assumes that the function
* using it has a 'result' variable and a 'cleanup' label.
@@ -1495,12 +1497,12 @@
if (result != ISC_R_SUCCESS) {
char namebuf[DNS_NAME_FORMATSIZE];
dns_name_format(origin, namebuf, sizeof(namebuf));
- cfg_obj_log(forwarders, ns_g_lctx, ISC_LOG_WARNING,
- "could not set up forwarding for domain '%s': %s",
+ cfg_obj_log(forwarders, ns_g_lctx, ISC_LOG_NOTICE,
+ "setting up forwarding failed for domain '%s': %s",
namebuf, isc_result_totext(result));
goto cleanup;
}
-
+
result = ISC_R_SUCCESS;
cleanup:
@@ -2875,6 +2877,20 @@
CHECKFATAL(load_zones(server, ISC_FALSE), "loading zones");
+ server->dbus_mgr = 0L;
+ if( ns_g_dbus )
+ if( dbus_mgr_create
+ ( ns_g_mctx, ns_g_taskmgr, ns_g_socketmgr, ns_g_timermgr,
+ &server->dbus_mgr
+ ) != ISC_R_SUCCESS
+ )
+ {
+ isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+ NS_LOGMODULE_SERVER, ISC_LOG_WARNING,
+ "dbus_mgr initialization failed. D-BUS service is disabled."
+ );
+ }
+
ns_os_started();
isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_SERVER,
ISC_LOG_NOTICE, "running");
@@ -2937,6 +2953,9 @@
dns_db_detach(&server->in_roothints);
+ if( server->dbus_mgr != 0L )
+ dbus_mgr_shutdown(server->dbus_mgr);
+
isc_task_endexclusive(server->task);
isc_task_detach(&server->task);
--- bind-9.3.3rc2/bin/named/Makefile.in.dbus 2004-09-06 23:47:25.000000000 +0200
+++ bind-9.3.3rc2/bin/named/Makefile.in 2006-09-18 10:10:58.000000000 +0200
@@ -35,7 +35,8 @@
${LWRES_INCLUDES} ${DNS_INCLUDES} ${BIND9_INCLUDES} \
${ISCCFG_INCLUDES} ${ISCCC_INCLUDES} ${ISC_INCLUDES} \
${DBDRIVER_INCLUDES}
-
+DBUS_INCLUDES = \
+ -I/usr/lib/dbus-1.0/include -I/usr/include/dbus-1.0
CDEFINES =
CWARNINGS =
@@ -52,6 +53,7 @@
ISCDEPLIBS = ../../lib/isc/libisc.@A@
LWRESDEPLIBS = ../../lib/lwres/liblwres.@A@
BIND9DEPLIBS = ../../lib/bind9/libbind9.@A@
+DBUSLIBS= -ldbus-1
DEPLIBS = ${LWRESDEPLIBS} ${DNSDEPLIBS} ${BIND9DEPLIBS} \
${ISCCFGDEPLIBS} ${ISCCCDEPLIBS} ${ISCDEPLIBS}
@@ -71,6 +73,7 @@
zoneconf.@O@ \
lwaddr.@O@ lwresd.@O@ lwdclient.@O@ lwderror.@O@ lwdgabn.@O@ \
lwdgnba.@O@ lwdgrbn.@O@ lwdnoop.@O@ lwsearch.@O@ \
+ dbus_service.@O@ dbus_mgr.@O@ \
$(DBDRIVER_OBJS)
UOBJS = unix/os.@O@
@@ -83,6 +86,7 @@
zoneconf.c \
lwaddr.c lwresd.c lwdclient.c lwderror.c lwdgabn.c \
lwdgnba.c lwdgrbn.c lwdnoop.c lwsearch.c \
+ dbus_service.c dbus_mgr.c \
$(DBDRIVER_SRCS)
MANPAGES = named.8 lwresd.8 named.conf.5
@@ -105,9 +109,14 @@
-DNS_LOCALSTATEDIR=\"${localstatedir}\" \
-c ${srcdir}/config.c
+dbus_service.o: dbus_service.c
+ ${LIBTOOL_MODE_COMPILE} ${CC} ${ALL_CFLAGS} \
+ ${DBUS_INCLUDES} \
+ -c ${srcdir}/dbus_service.c
+
named@EXEEXT@: ${OBJS} ${UOBJS} ${DEPLIBS}
${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \
- ${OBJS} ${UOBJS} ${LIBS}
+ ${OBJS} ${UOBJS} ${LIBS} ${DBUSLIBS}
lwresd@EXEEXT@: named@EXEEXT@
rm -f lwresd@EXEEXT@

840
doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt Normal file
View file

@ -0,0 +1,840 @@
DNSEXT D. Blacka
Internet-Draft VeriSign, Inc.
Intended status: Standards Track April 7, 2006
Expires: October 9, 2006
DNSSEC Experiments
draft-ietf-dnsext-dnssec-experiments-03
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 October 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Blacka Expires October 9, 2006 [Page 1]
Internet-Draft DNSSEC Experiments April 2006
Abstract
This document describes a methodology for deploying alternate, non-
backwards-compatible, DNSSEC methodologies in an experimental fashion
without disrupting the deployment of standard DNSSEC.
Table of Contents
1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 8
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Blacka Expires October 9, 2006 [Page 2]
Internet-Draft DNSSEC Experiments April 2006
1. Definitions and Terminology
Throughout this document, familiarity with the DNS system (RFC 1035
[5]) and the DNS security extensions ([2], [3], and [4] is assumed.
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].
Blacka Expires October 9, 2006 [Page 3]
Internet-Draft DNSSEC Experiments April 2006
2. Overview
Historically, experimentation with DNSSEC alternatives has been a
problematic endeavor. There has typically been a desire to both
introduce non-backwards-compatible changes to DNSSEC and to try these
changes on real zones in the public DNS. This creates a problem when
the change to DNSSEC would make all or part of the zone using those
changes appear bogus (bad) or otherwise broken to existing security-
aware resolvers.
This document describes a standard methodology for setting up DNSSEC
experiments. This methodology addresses the issue of co-existence
with standard DNSSEC and DNS by using unknown algorithm identifiers
to hide the experimental DNSSEC protocol modifications from standard
security-aware resolvers.
Blacka Expires October 9, 2006 [Page 4]
Internet-Draft DNSSEC Experiments April 2006
3. Experiments
When discussing DNSSEC experiments, it is necessary to classify these
experiments into two broad categories:
Backwards-Compatible: describes experimental changes that, while not
strictly adhering to the DNSSEC standard, are nonetheless
interoperable with clients and servers that do implement the
DNSSEC standard.
Non-Backwards-Compatible: describes experiments that would cause a
standard security-aware resolver to (incorrectly) determine that
all or part of a zone is bogus, or to otherwise not interoperate
with standard DNSSEC clients and servers.
Not included in these terms are experiments with the core DNS
protocol itself.
The methodology described in this document is not necessary for
backwards-compatible experiments, although it certainly may be used
if desired.
Blacka Expires October 9, 2006 [Page 5]
Internet-Draft DNSSEC Experiments April 2006
4. Method
The core of the methodology is the use of strictly unknown algorithm
identifiers when signing the experimental zone, and more importantly,
having only unknown algorithm identifiers in the DS records for the
delegation to the zone at the parent.
This technique works because of the way DNSSEC-compliant validators
are expected to work in the presence of a DS set with only unknown
algorithm identifiers. From [4], Section 5.2:
If the validator does not support any of the algorithms listed in
an authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.
And further:
If the resolver does not support any of the algorithms listed in
an authenticated DS RRset, then the resolver will not be able to
verify the authentication path to the child zone. In this case,
the resolver SHOULD treat the child zone as if it were unsigned.
While this behavior isn't strictly mandatory (as marked by MUST), it
is likely that a validator would implement this behavior, or, more to
the point, it would handle this situation in a safe way (see below
(Section 6).)
Because we are talking about experiments, it is RECOMMENDED that
private algorithm numbers be used (see [3], appendix A.1.1. Note
that secure handling of private algorithms requires special handing
by the validator logic. See [6] for further details.) Normally,
instead of actually inventing new signing algorithms, the recommended
path is to create alternate algorithm identifiers that are aliases
for the existing, known algorithms. While, strictly speaking, it is
only necessary to create an alternate identifier for the mandatory
algorithms, it is suggested that all optional defined algorithms be
aliased as well.
It is RECOMMENDED that for a particular DNSSEC experiment, a
particular domain name base is chosen for all new algorithms, then
the algorithm number (or name) is prepended to it. For example, for
experiment A, the base name of "dnssec-experiment-a.example.com" is
chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
defined to be "3.dnssec-experiment-a.example.com" and
"5.dnssec-experiment-a.example.com". However, any unique identifier
Blacka Expires October 9, 2006 [Page 6]
Internet-Draft DNSSEC Experiments April 2006
will suffice.
Using this method, resolvers (or, more specifically, DNSSEC
validators) essentially indicate their ability to understand the
DNSSEC experiment's semantics by understanding what the new algorithm
identifiers signify.
This method creates two classes of security-aware servers and
resolvers: servers and resolvers that are aware of the experiment
(and thus recognize the experiment's algorithm identifiers and
experimental semantics), and servers and resolvers that are unaware
of the experiment.
This method also precludes any zone from being both in an experiment
and in a classic DNSSEC island of security. That is, a zone is
either in an experiment and only experimentally validatable, or it is
not.
Blacka Expires October 9, 2006 [Page 7]
Internet-Draft DNSSEC Experiments April 2006
5. Defining an Experiment
The DNSSEC experiment MUST define the particular set of (previously
unknown) algorithm identifiers that identify the experiment, and
define what each unknown algorithm identifier means. Typically,
unless the experiment is actually experimenting with a new DNSSEC
algorithm, this will be a mapping of private algorithm identifiers to
existing, known algorithms.
Normally the experiment will choose a DNS name as the algorithm
identifier base. This DNS name SHOULD be under the control of the
authors of the experiment. Then the experiment will define a mapping
between known mandatory and optional algorithms into this private
algorithm identifier space. Alternately, the experiment MAY use the
OID private algorithm space instead (using algorithm number 254), or
MAY choose non-private algorithm numbers, although this would require
an IANA allocation.
For example, an experiment might specify in its description the DNS
name "dnssec-experiment-a.example.com" as the base name, and declare
that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC
algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an
alias of DNSSEC algorithm 5 (RSASHA1).
Resolvers MUST only recognize the experiment's semantics when present
in a zone signed by one or more of these algorithm identifiers. This
is necessary to isolate the semantics of one experiment from any
others that the resolver might understand.
In general, resolvers involved in the experiment are expected to
understand both standard DNSSEC and the defined experimental DNSSEC
protocol, although this isn't required.
Blacka Expires October 9, 2006 [Page 8]
Internet-Draft DNSSEC Experiments April 2006
6. Considerations
There are a number of considerations with using this methodology.
1. Under some circumstances, it may be that the experiment will not
be sufficiently masked by this technique and may cause resolution
problem for resolvers not aware of the experiment. For instance,
the resolver may look at a non-validatable response and conclude
that the response is bogus, either due to local policy or
implementation details. This is not expected to be a common
case, however.
2. It will not be possible for security-aware resolvers unaware of
the experiment to build a chain of trust through an experimental
zone.
Blacka Expires October 9, 2006 [Page 9]
Internet-Draft DNSSEC Experiments April 2006
7. Use in Non-Experiments
This general methodology MAY be used for non-backwards compatible
DNSSEC protocol changes that start out as or become standards. In
this case:
o The protocol change SHOULD use public IANA allocated algorithm
identifiers instead of private algorithm identifiers. This will
help identify the protocol change as a standard, rather than an
experiment.
o Resolvers MAY recognize the protocol change in zones not signed
(or not solely signed) using the new algorithm identifiers.
Blacka Expires October 9, 2006 [Page 10]
Internet-Draft DNSSEC Experiments April 2006
8. Security Considerations
Zones using this methodology will be considered insecure by all
resolvers except those aware of the experiment. It is not generally
possible to create a secure delegation from an experimental zone that
will be followed by resolvers unaware of the experiment.
Blacka Expires October 9, 2006 [Page 11]
Internet-Draft DNSSEC Experiments April 2006
9. IANA Considerations
This document has no IANA actions.
Blacka Expires October 9, 2006 [Page 12]
Internet-Draft DNSSEC Experiments April 2006
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[4] 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
[5] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[6] Austein, R. and S. Weiler, "Clarifications and Implementation
Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02
(work in progress), January 2006.
Blacka Expires October 9, 2006 [Page 13]
Internet-Draft DNSSEC Experiments April 2006
Author's Address
David Blacka
VeriSign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
Phone: +1 703 948 3200
Email: davidb@verisign.com
URI: http://www.verisignlabs.com
Blacka Expires October 9, 2006 [Page 14]
Internet-Draft DNSSEC Experiments April 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Blacka Expires October 9, 2006 [Page 15]

504
doc/draft/draft-ietf-dnsext-ds-sha256-05.txt Normal file
View file

@ -0,0 +1,504 @@
Network Working Group W. Hardaker
Internet-Draft Sparta
Expires: August 25, 2006 February 21, 2006
Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
draft-ietf-dnsext-ds-sha256-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 August 25, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies how to use the SHA-256 digest type in DNS
Delegation Signer (DS) Resource Records (RRs). DS records, when
stored in a parent zone, point to key signing DNSKEY key(s) in a
child zone.
Hardaker Expires August 25, 2006 [Page 1]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Implementing the SHA-256 algorithm for DS record support . . . 3
2.1. DS record field values . . . . . . . . . . . . . . . . . . 3
2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3
2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Hardaker Expires August 25, 2006 [Page 2]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
1. Introduction
The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
zones to distribute a cryptographic digest of a child's Key Signing
Key (KSK) DNSKEY RR. The DS RRset is signed by at least one of the
parent zone's private zone data signing keys for each algorithm in
use by the parent. Each signature is published in an RRSIG resource
record, owned by the same domain as the DS RRset and with a type
covered of DS.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Implementing the SHA-256 algorithm for DS record support
This document specifies that the digest type code [XXX: To be
assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
[SHA256CODE] for use within DS records. The results of the digest
algorithm MUST NOT be truncated and the entire 32 byte digest result
is to be published in the DS record.
2.1. DS record field values
Using the SHA-256 digest algorithm within a DS record will make use
of the following DS-record fields:
Digest type: [XXX: To be assigned by IANA; likely 2]
Digest: A SHA-256 bit digest value calculated by using the following
formula ("|" denotes concatenation). The resulting value is not
truncated and the entire 32 byte result is to used in the
resulting DS record and related calculations.
digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
where DNSKEY RDATA is defined by [RFC4034] as:
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
The Key Tag field and Algorithm fields remain unchanged by this
document and are specified in the [RFC4034] specification.
2.2. DS Record with SHA-256 Wire Format
The resulting on-the-wire format for the resulting DS record will be
[XXX: IANA assignment should replace the 2 below]:
Hardaker Expires August 25, 2006 [Page 3]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Algorithm | DigestType=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Digest (length for SHA-256 is 32 bytes) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
2.3. Example DS Record Using SHA-256
The following is an example DNSKEY and matching DS record. This
DNSKEY record comes from the example DNSKEY/DS records found in
section 5.4 of [RFC4034].
The DNSKEY record:
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
fwJr1AYtsmx3TGkJaNXVbfi/
2pHm822aJ5iI9BMzNXxeYCmZ
DRD99WYwYqUSdjMmmAphXdvx
egXd/M5+X7OrzKBaMbCVdFLU
Uh6DhweJBjEVv5f2wwjM9Xzc
nOf+EPbtG9DMBmADjFDc2w/r
ljwvFw==
) ; key id = 60485
The resulting DS record covering the above DNSKEY record using a SHA-
256 digest: [RFC Editor: please replace XXX with the assigned digest
type (likely 2):]
dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
CEB1E3E0614B93C4F9E99B83
83F6A1E4469DA50A )
3. Implementation Requirements
Implementations MUST support the use of the SHA-256 algorithm in DS
RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1
digests if DS RRs with SHA-256 digests are present in the DS RRset.
4. Deployment Considerations
If a validator does not support the SHA-256 digest type and no other
DS RR exists in a zone's DS RRset with a supported digest type, then
Hardaker Expires August 25, 2006 [Page 4]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
the validator has no supported authentication path leading from the
parent to the child. The resolver should treat this case as it would
the case of an authenticated NSEC RRset proving that no DS RRset
exists, as described in [RFC4035], section 5.2.
Because zone administrators can not control the deployment speed of
support for SHA-256 in validators that may be referencing any of
their zones, zone operators should consider deploying both SHA-1 and
SHA-256 based DS records. This should be done for every DNSKEY for
which DS records are being generated. Whether to make use of both
digest types and for how long is a policy decision that extends
beyond the scope of this document.
5. IANA Considerations
Only one IANA action is required by this document:
The Digest Type to be used for supporting SHA-256 within DS records
needs to be assigned by IANA. This document requests that the Digest
Type value of 2 be assigned to the SHA-256 digest algorithm.
At the time of this writing, the current digest types assigned for
use in DS records are as follows:
VALUE Digest Type Status
0 Reserved -
1 SHA-1 MANDATORY
2 SHA-256 MANDATORY
3-255 Unassigned -
6. Security Considerations
6.1. Potential Digest Type Downgrade Attacks
A downgrade attack from a stronger digest type to a weaker one is
possible if all of the following are true:
o A zone includes multiple DS records for a given child's DNSKEY,
each of which use a different digest type.
o A validator accepts a weaker digest even if a stronger one is
present but invalid.
For example, if the following conditions are all true:
Hardaker Expires August 25, 2006 [Page 5]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
o Both SHA-1 and SHA-256 based digests are published in DS records
within a parent zone for a given child zone's DNSKEY.
o The DS record with the SHA-1 digest matches the digest computed
using the child zone's DNSKEY.
o The DS record with the SHA-256 digest fails to match the digest
computed using the child zone's DNSKEY.
Then if the validator accepts the above situation as secure then this
can be used as a downgrade attack since the stronger SHA-256 digest
is ignored.
6.2. SHA-1 vs SHA-256 Considerations for DS Records
Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
implementations allow for it. SHA-256 is widely believed to be more
resilient to attack than SHA-1, and confidence in SHA-1's strength is
being eroded by recently-announced attacks. Regardless of whether or
not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
time of this writing) that SHA-256 is the better choice for use in DS
records.
At the time of this publication, the SHA-256 digest algorithm is
considered sufficiently strong for the immediate future. It is also
considered sufficient for use in DNSSEC DS RRs for the immediate
future. However, future published attacks may weaken the usability
of this algorithm within the DS RRs. It is beyond the scope of this
document to speculate extensively on the cryptographic strength of
the SHA-256 digest algorithm.
Likewise, it is also beyond the scope of this document to specify
whether or for how long SHA-1 based DS records should be
simultaneously published alongside SHA-256 based DS records.
7. Acknowledgments
This document is a minor extension to the existing DNSSEC documents
and those authors are gratefully appreciated for the hard work that
went into the base documents.
The following people contributed to portions of this document in some
fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
Weiler.
Hardaker Expires August 25, 2006 [Page 6]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[SHA256] National Institute of Standards and Technology, "Secure
Hash Algorithm. NIST FIPS 180-2", August 2002.
8.2. Informative References
[SHA256CODE]
Eastlake, D., "US Secure Hash Algorithms (SHA)",
June 2005.
Hardaker Expires August 25, 2006 [Page 7]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
Author's Address
Wes Hardaker
Sparta
P.O. Box 382
Davis, CA 95617
US
Email: hardaker@tislabs.com
Hardaker Expires August 25, 2006 [Page 8]
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Hardaker Expires August 25, 2006 [Page 9]

1801
doc/draft/draft-ietf-dnsext-mdns-46.txt Normal file
View file

File diff suppressed because it is too large Load diff

464
doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt Normal file
View file

@ -0,0 +1,464 @@
INTERNET-DRAFT DSA Information in the DNS
OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
Motorola Laboratories
Expires: September 2006 March 2006
DSA Keying and Signature Information in the DNS
--- ------ --- --------- ----------- -- --- ---
<draft-ietf-dnsext-rfc2536bis-dsa-07.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 DNS extensions working group mailing list
<namedroppers@ops.ietf.org>.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The standard method of encoding US Government Digital Signature
Algorithm keying and signature information for use in the Domain Name
System is specified.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DSA Information in the DNS
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. DSA Keying Information..................................3
3. DSA Signature Information...............................4
4. Performance Considerations..............................4
5. Security Considerations.................................5
6. IANA Considerations.....................................5
Copyright, Disclaimer, and Additional IPR Provisions.......5
Normative References.......................................7
Informative References.....................................7
Author's Address...........................................8
Expiration and File Name...................................8
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DSA Information in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information [RFC 1034, 1035]. The DNS has been extended to
include digital signatures and cryptographic keys as described in
[RFC 4033, 4034, 4035] and additional work is underway which would
require the storage of keying and signature information in the DNS.
This document describes how to encode US Government Digital Signature
Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
2. DSA Keying Information
When DSA public keys are stored in the DNS, the structure of the
relevant part of the RDATA part of the RR being used is the fields
listed below in the order given.
The period of key validity is not included in this data but is
indicated separately, for example by an RR such as RRSIG which signs
and authenticates the RR containing the keying information.
Field Size
----- ----
T 1 octet
Q 20 octets
P 64 + T*8 octets
G 64 + T*8 octets
Y 64 + T*8 octets
As described in [FIPS 186-2] and [Schneier], T is a key size
parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
is greater than 8 is reserved and the remainder of the data may have
a different format in that case.) Q is a prime number selected at
key generation time such that 2**159 < Q < 2**160. Thus Q is always
20 octets long and, as with all other fields, is stored in "big-
endian" network order. P, G, and Y are calculated as directed by the
[FIPS 186-2] key generation algorithm [Schneier]. P is in the range
2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
and Y are quantities modulo P and so can be up to the same length as
P and are allocated fixed size fields with the same number of octets
as P.
During the key generation process, a random number X must be
generated such that 1 <= X <= Q-1. X is the private key and is used
in the final step of public key generation where Y is computed as
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DSA Information in the DNS
Y = G**X mod P
3. DSA Signature Information
The portion of the RDATA area used for US Digital Signature Algorithm
signature information is shown below with fields in the order they
are listed and the contents of each multi-octet field in "big-endian"
network order.
Field Size
----- ----
T 1 octet
R 20 octets
S 20 octets
First, the data signed must be determined. Then the following steps
are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
specified in the public key [Schneier]:
hash = SHA-1 ( data )
Generate a random K such that 0 < K < Q.
R = ( G**K mod P ) mod Q
S = ( K**(-1) * (hash + X*R) ) mod Q
For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
3174].
Since Q is 160 bits long, R and S can not be larger than 20 octets,
which is the space allocated.
T is copied from the public key. It is not logically necessary in
the SIG but is present so that values of T > 8 can more conveniently
be used as an escape for extended versions of DSA or other algorithms
as later standardized.
4. Performance Considerations
General signature generation speeds are roughly the same for RSA [RFC
3110] and DSA. With sufficient pre-computation, signature generation
with DSA is faster than RSA. Key generation is also faster for DSA.
However, signature verification is an order of magnitude slower than
RSA when the RSA public exponent is chosen to be small, as is
recommended for some applications.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DSA Information in the DNS
Current DNS implementations are optimized for small transfers,
typically less than 512 bytes including DNS overhead. Larger
transfers will perform correctly and extensions have been
standardized [RFC 2671] to make larger transfers more efficient, it
is still advisable at this time to make reasonable efforts to
minimize the size of RR sets containing keying and/or signature
inforamtion consistent with adequate security.
5. Security Considerations
Keys retrieved from the DNS should not be trusted unless (1) they
have been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms,
evaluating the necessary strength of the key is essential and
dependent on local policy.
The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
current DSA standard may limit the security of DSA. For particular
applications, implementors are encouraged to consider the range of
available algorithms and key sizes.
DSA assumes the ability to frequently generate high quality random
numbers. See [random] for guidance. DSA is designed so that if
biased rather than random numbers are used, high bandwidth covert
channels are possible. See [Schneier] and more recent research. The
leakage of an entire DSA private key in only two DSA signatures has
been demonstrated. DSA provides security only if trusted
implementations, including trusted random number generation, are
used.
6. IANA Considerations
Allocation of meaning to values of the T parameter that are not
defined herein (i.e., > 8 ) requires an IETF standards actions. It
is intended that values unallocated herein be used to cover future
extensions of the DSS standard.
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (C) The Internet Society (2006). 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.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DSA Information in the DNS
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.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DSA Information in the DNS
Normative References
[FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
Signature Standard, 27 January 2000.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
Informative References
[RFC 1034] - "Domain names - concepts and facilities", P.
Mockapetris, 11/01/1987.
[RFC 1035] - "Domain names - implementation and specification", P.
Mockapetris, 11/01/1987.
[RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
1999.
[RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
(DNS)", D. Eastlake 3rd. May 2001.
[RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
Jones, September 2001.
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
2005.
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[Schneier] - "Applied Cryptography Second Edition: protocols,
algorithms, and source code in C" (second edition), Bruce Schneier,
1996, John Wiley and Sons, ISBN 0-471-11709-9.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DSA Information in the DNS
Author's Address
Donald E. Eastlake 3rd
Motorola Labortories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1-508-786-7554(w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in September 2006.
Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt.
D. Eastlake 3rd [Page 8]

580
doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt Normal file
View file

@ -0,0 +1,580 @@
INTERNET-DRAFT Diffie-Hellman Information in the DNS
OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
Motorola Laboratories
Expires: September 2006 March 2006
Storage of Diffie-Hellman Keying Information in the DNS
------- -- -------------- ------ ----------- -- --- ---
<draft-ietf-dnsext-rfc2539bis-dhk-07.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.
Distribution of this document is unlimited. Comments should be sent
to the DNS extensions working group mailing list
<namedroppers@ops.ietf.org>.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The standard method for encoding Diffie-Hellman keys in the Domain
Name System is specified.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
Acknowledgements
Part of the format for Diffie-Hellman keys and the description
thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
and Hemma Prafullchandra. In addition, the following persons
provided useful comments that were incorporated into the predecessor
of this document: Ran Atkinson, Thomas Narten.
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Acknowledgements...........................................2
Table of Contents..........................................2
1. Introduction............................................3
1.1 About This Document....................................3
1.2 About Diffie-Hellman...................................3
2. Encoding Diffie-Hellman Keying Information..............4
3. Performance Considerations..............................5
4. IANA Considerations.....................................5
5. Security Considerations.................................5
Copyright, Disclaimer, and Additional IPR Provisions.......5
Normative References.......................................7
Informative Refences.......................................7
Author's Address...........................................8
Expiration and File Name...................................8
Appendix A: Well known prime/generator pairs...............9
A.1. Well-Known Group 1: A 768 bit prime..................9
A.2. Well-Known Group 2: A 1024 bit prime.................9
A.3. Well-Known Group 3: A 1536 bit prime................10
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
similar information [RFC 1034, 1035]. The DNS has been extended to
include digital signatures and cryptographic keys as described in
[RFC 4033, 4034, 4035] and additonal work is underway which would use
the storage of keying information in the DNS.
1.1 About This Document
This document describes how to store Diffie-Hellman keys in the DNS.
Familiarity with the Diffie-Hellman key exchange algorithm is assumed
[Schneier, RFC 2631].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
1.2 About Diffie-Hellman
Diffie-Hellman requires two parties to interact to derive keying
information which can then be used for authentication. Thus Diffie-
Hellman is inherently a key agreement algorithm. As a result, no
format is defined for Diffie-Hellman "signature information". For
example, assume that two parties have local secrets "i" and "j".
Assume they each respectively calculate X and Y as follows:
X = g**i ( mod p )
Y = g**j ( mod p )
They exchange these quantities and then each calculates a Z as
follows:
Zi = Y**i ( mod p )
Zj = X**j ( mod p )
Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
secret between the two parties that an adversary who does not know i
or j will not be able to learn from the exchanged messages (unless
the adversary can derive i or j by performing a discrete logarithm
mod p which is hard for strong p and g).
The private key for each party is their secret i (or j). The public
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
key is the pair p and g, which is the same for both parties, and
their individual X (or Y).
For further information about Diffie-Hellman and precautions to take
in deciding on a p and g, see [RFC 2631].
2. Encoding Diffie-Hellman Keying Information
When Diffie-Hellman keys appear within the RDATA portion of a RR,
they are encoded as shown below.
The period of key validity is not included in this data but is
indicated separately, for example by an RR such as RRSIG which signs
and authenticates the RR containing the keying information.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEY flags | protocol | algorithm=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prime length (or flag) | prime (p) (or special) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ prime (p) (variable length) | generator length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| generator (g) (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| public value length | public value (variable length)/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ public value (g^i mod p) (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prime length is the length of the Diffie-Hellman prime (p) in bytes
if it is 16 or greater. Prime contains the binary representation of
the Diffie-Hellman prime with most significant byte first (i.e., in
network order). If "prime length" field is 1 or 2, then the "prime"
field is actually an unsigned index into a table of 65,536
prime/generator pairs and the generator length SHOULD be zero. See
Appedix A for defined table entries and Section 4 for information on
allocating additional table entries. The meaning of a zero or 3
through 15 value for "prime length" is reserved.
Generator length is the length of the generator (g) in bytes.
Generator is the binary representation of generator with most
significant byte first. PublicValueLen is the Length of the Public
Value (g**i (mod p)) in bytes. PublicValue is the binary
representation of the DH public value with most significant byte
first.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
3. Performance Considerations
Current DNS implementations are optimized for small transfers,
typically less than 512 bytes including DNS overhead. Larger
transfers will perform correctly and extensions have been
standardized [RFC 2671] to make larger transfers more efficient. But
it is still advisable at this time to make reasonable efforts to
minimize the size of RR sets containing keying information consistent
with adequate security.
4. IANA Considerations
Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
an IETF consensus as defined in [RFC 2434].
Well known prime/generator pairs number 0x0000 through 0x07FF can
only be assigned by an IETF standards action. [RFC 2539], the
Proposed Standard predecessor of this document, assigned 0x0001
through 0x0002. This document additionally assigns 0x0003. Pairs
number 0s0800 through 0xBFFF can be assigned based on RFC
documentation. Pairs number 0xC000 through 0xFFFF are available for
private use and are not centrally coordinated. Use of such private
pairs outside of a closed environment may result in conflicts and/or
security failures.
5. Security Considerations
Keying information retrieved from the DNS should not be trusted
unless (1) it has been securely obtained from a secure resolver or
independently verified by the user and (2) this secure resolver and
secure obtainment or independent verification conform to security
policies acceptable to the user. As with all cryptographic
algorithms, evaluating the necessary strength of the key is important
and dependent on security policy.
In addition, the usual Diffie-Hellman key strength considerations
apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p
SHOULD be "large", etc. See [RFC 2631, Schneier].
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (C) The Internet Society (2006). 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.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
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.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
Normative References
[RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section
in RFCs", T. Narten, H. Alvestrand, October 1998.
[RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
1999.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
Informative Refences
[RFC 1034] - "Domain names - concepts and facilities", P.
Mockapetris, November 1987.
[RFC 1035] - "Domain names - implementation and specification", P.
Mockapetris, November 1987.
[RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
[RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
1999.
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
2005.
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
and Sons.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
Author's Address
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1-508-786-7554
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in September 2006.
Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt.
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
Appendix A: Well known prime/generator pairs
These numbers are copied from the IPSEC effort where the derivation
of these values is more fully explained and additional information is
available. Richard Schroeppel performed all the mathematical and
computational work for this appendix.
A.1. Well-Known Group 1: A 768 bit prime
The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
decimal value is
155251809230070893513091813125848175563133404943451431320235
119490296623994910210725866945387659164244291000768028886422
915080371891804634263272761303128298374438082089019628850917
0691316593175367469551763119843371637221007210577919
Prime modulus: Length (32 bit words): 24, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
A.2. Well-Known Group 2: A 1024 bit prime
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its decimal value is
179769313486231590770839156793787453197860296048756011706444
423684197180216158519368947833795864925541502180565485980503
646440548199239100050792877003355816639229553136239076508735
759914822574862575007425302077447712589550957937778424442426
617334727629299387668709205606050270810842907692932019128194
467627007
Prime modulus: Length (32 bit words): 32, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
A.3. Well-Known Group 3: A 1536 bit prime
The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
Its decimal value is
241031242692103258855207602219756607485695054850245994265411
694195810883168261222889009385826134161467322714147790401219
650364895705058263194273070680500922306273474534107340669624
601458936165977404102716924945320037872943417032584377865919
814376319377685986952408894019557734611984354530154704374720
774996976375008430892633929555996888245787241299381012913029
459299994792636526405928464720973038494721168143446471443848
8520940127459844288859336526896320919633919
Prime modulus Length (32 bit words): 48, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
D. Eastlake 3rd [Page 10]

640
doc/draft/draft-ietf-dnsop-respsize-06.txt Normal file
View file

@ -0,0 +1,640 @@
DNSOP Working Group Paul Vixie, ISC
INTERNET-DRAFT Akira Kato, WIDE
<draft-ietf-dnsop-respsize-06.txt> August 2006
DNS Referral Response Size Issues
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.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
With a mandated default minimum maximum message size of 512 octets,
the DNS protocol presents some special problems for zones wishing to
expose a moderate or high number of authority servers (NS RRs). This
document explains the operational issues caused by, or related to
this response size limit, and suggests ways to optimize the use of
this limited space. Guidance is offered to DNS server implementors
and to DNS zone operators.
Expires January 2007 [Page 1]
INTERNET-DRAFT August 2006 RESPSIZE
1 - Introduction and Overview
1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
octets. Even though this limitation was due to the required minimum IP
reassembly limit for IPv4, it became a hard DNS protocol limit and is
not implicitly relaxed by changes in transport, for example to IPv6.
1.2. The EDNS0 protocol extension (see [RFC2671 2.3, 4.5]) permits
larger responses by mutual agreement of the requester and responder.
The 512 octet message size limit will remain in practical effect until
there is widespread deployment of EDNS0 in DNS resolvers on the
Internet.
1.3. Since DNS responses include a copy of the request, the space
available for response data is somewhat less than the full 512 octets.
Negative responses are quite small, but for positive and delegation
responses, every octet must be carefully and sparingly allocated. This
document specifically addresses delegation response sizes.
2 - Delegation Details
2.1. RELEVANT PROTOCOL ELEMENTS
2.1.1. A delegation response will include the following elements:
Header Section: fixed length (12 octets)
Question Section: original query (name, class, type)
Answer Section: empty, or a CNAME/DNAME chain
Authority Section: NS RRset (nameserver names)
Additional Section: A and AAAA RRsets (nameserver addresses)
2.1.2. If the total response size exceeds 512 octets, and if the data
that does not fit was "required", then the TC bit will be set
(indicating truncation). This will usually cause the requester to retry
using TCP, depending on what information was desired and what
information was omitted. For example, truncation in the authority
section is of no interest to a stub resolver who only plans to consume
the answer section. If a retry using TCP is needed, the total cost of
the transaction is much higher. See [RFC1123 6.1.3.2] for details on
the requirement that UDP be attempted before falling back to TCP.
2.1.3. RRsets are never sent partially unless TC bit set to indicate
truncation. When TC bit is set, the final apparent RRset in the final
non-empty section must be considered "possibly damaged" (see [RFC1035
6.2], [RFC2181 9]).
Expires January 2007 [Page 2]
INTERNET-DRAFT August 2006 RESPSIZE
2.1.4. With or without truncation, the glue present in the additional
data section should be considered "possibly incomplete", and requesters
should be prepared to re-query for any damaged or missing RRsets. Note
that truncation of the additional data section might not be signalled
via the TC bit since additional data is often optional (see discussion
in [RFC4472 B]).
2.1.5. DNS label compression allows a domain name to be instantiated
only once per DNS message, and then referenced with a two-octet
"pointer" from other locations in that same DNS message (see [RFC1035
4.1.4]). If all nameserver names in a message share a common parent
(for example, all ending in ".ROOT-SERVERS.NET"), then more space will
be available for incompressable data (such as nameserver addresses).
2.1.6. The query name can be as long as 255 octets of network data. In
this worst case scenario, the question section will be 259 octets in
size, which would leave only 240 octets for the authority and additional
sections (after deducting 12 octets for the fixed length header.)
2.2. ADVICE TO ZONE OWNERS
2.2.1. Average and maximum question section sizes can be predicted by
the zone owner, since they will know what names actually exist, and can
measure which ones are queried for most often. Note that if the zone
contains any wildcards, it is possible for maximum length queries to
require positive responses, but that it is reasonable to expect
truncation and TCP retry in that case. For cost and performance
reasons, the majority of requests should be satisfied without truncation
or TCP retry.
2.2.2. Some queries to non-existing names can be large, but this is not
a problem because negative responses need not contain any answer,
authority or additional records. See [RFC2308 2.1] for more information
about the format of negative responses.
2.2.3. The minimum useful number of name servers is two, for redundancy
(see [RFC1034 4.1]). A zone's name servers should be reachable by all
IP transport protocols (e.g., IPv4 and IPv6) in common use.
2.2.4. The best case is no truncation at all. This is because many
requesters will retry using TCP immediately, or will automatically re-
query for RRsets that are possibly truncated, without considering
whether the omitted data was actually necessary.
Expires January 2007 [Page 3]
INTERNET-DRAFT August 2006 RESPSIZE
2.3. ADVICE TO SERVER IMPLEMENTORS
2.3.1. In case of multi-homed name servers, it is advantageous to
include an address record from each of several name servers before
including several address records for any one name server. If address
records for more than one transport (for example, A and AAAA) are
available, then it is advantageous to include records of both types
early on, before the message is full.
2.3.2. Each added NS RR for a zone will add 12 fixed octets (name, type,
class, ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME).
Each A RR will require 16 octets, and each AAAA RR will require 28
octets.
2.3.3. While DNS distinguishes between necessary and optional resource
records, this distinction is according to protocol elements necessary to
signify facts, and takes no official notice of protocol content
necessary to ensure correct operation. For example, a nameserver name
that is in or below the zone cut being described by a delegation is
"necessary content," since there is no way to reach that zone unless the
parent zone's delegation includes "glue records" describing that name
server's addresses.
2.3.4. It is also necessary to distinguish between "explicit truncation"
where a message could not contain enough records to convey its intended
meaning, and so the TC bit has been set, and "silent truncation", where
the message was not large enough to contain some records which were "not
required", and so the TC bit was not set.
2.3.5. A delegation response should prioritize glue records as follows.
first
All glue RRsets for one name server whose name is in or below the
zone being delegated, or which has multiple address RRsets (currently
A and AAAA), or preferably both;
second
Alternate between adding all glue RRsets for any name servers whose
names are in or below the zone being delegated, and all glue RRsets
for any name servers who have multiple address RRsets (currently A
and AAAA);
thence
All other glue RRsets, in any order.
Expires January 2007 [Page 4]
INTERNET-DRAFT August 2006 RESPSIZE
Whenever there are multiple candidates for a position in this priority
scheme, one should be chosen on a round-robin or fully random basis.
The goal of this priority scheme is to offer "necessary" glue first,
avoiding silent truncation for this glue if possible.
2.3.6. If any "necessary content" is silently truncated, then it is
advisable that the TC bit be set in order to force a TCP retry, rather
than have the zone be unreachable. Note that a parent server's proper
response to a query for in-child glue or below-child glue is a referral
rather than an answer, and that this referral MUST be able to contain
the in-child or below-child glue, and that in outlying cases, only EDNS
or TCP will be large enough to contain that data.
3 - Analysis
3.1. An instrumented protocol trace of a best case delegation response
follows. Note that 13 servers are named, and 13 addresses are given.
This query was artificially designed to exactly reach the 512 octet
limit.
;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
;; QUERY SECTION:
;; [23456789.123456789.123456789.\
123456789.123456789.123456789.com A IN] ;; @80
;; AUTHORITY SECTION:
com. 86400 NS E.GTLD-SERVERS.NET. ;; @112
com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
Expires January 2007 [Page 5]
INTERNET-DRAFT August 2006 RESPSIZE
;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
;; MSG SIZE sent: 80 rcvd: 512
3.2. For longer query names, the number of address records supplied will
be lower. Furthermore, it is only by using a common parent name (which
is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
fit, due to the use of DNS compression pointers in the last 12
occurances of the parent domain name. The following output from a
response simulator demonstrates these properties.
% perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
a.dns.br requires 10 bytes
b.dns.br requires 4 bytes
c.dns.br requires 4 bytes
d.dns.br requires 4 bytes
# of NS: 4
For maximum size query (255 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 3 (yellow)
preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
For average size query (64 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 4 (green)
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
Expires January 2007 [Page 6]
INTERNET-DRAFT August 2006 RESPSIZE
% perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
ns-ext.isc.org requires 16 bytes
ns.psg.com requires 12 bytes
ns.ripe.net requires 13 bytes
ns.eu.int requires 11 bytes
# of NS: 4
For maximum size query (255 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 3 (yellow)
preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
For average size query (64 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 4 (green)
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
(Note: The response simulator program is shown in Section 5.)
Here we use the term "green" if all address records could fit, or
"yellow" if two or more could fit, or "orange" if only one could fit, or
"red" if no address record could fit. It's clear that without a common
parent for nameserver names, much space would be lost. For these
examples we use an average/common name size of 15 octets, befitting our
assumption of GTLD-SERVERS.NET as our common parent name.
We're assuming a medium query name size of 64 since that is the typical
size seen in trace data at the time of this writing. If
Internationalized Domain Name (IDN) or any other technology which
results in larger query names be deployed significantly in advance of
EDNS, then new measurements and new estimates will have to be made.
4 - Conclusions
4.1. The current practice of giving all nameserver names a common parent
(such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
responses and allows for more nameservers to be enumerated than would
otherwise be possible, since the common parent domain name only appears
once in a DNS message and is referred to via "compression pointers"
thereafter.
4.2. If all nameserver names for a zone share a common parent, then it
is operationally advisable to make all servers for the zone thus served
also be authoritative for the zone of that common parent. For example,
the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively
for the ROOT-SERVERS.NET. This is to ensure that the zone's servers
always have the zone's nameservers' glue available when delegating, and
Expires January 2007 [Page 7]
INTERNET-DRAFT August 2006 RESPSIZE
will be able to respond with answers rather than referrals if a
requester who wants that glue comes back asking for it. In this case
the name server will likely be a "stealth server" -- authoritative but
unadvertised in the glue zone's NS RRset. See [RFC1996 2] for more
information about stealth servers.
4.3. Thirteen (13) is the effective maximum number of nameserver names
usable traditional (non-extended) DNS, assuming a common parent domain
name, and given that implicit referral response truncation is
undesirable in the average case.
4.4. Multi-homing of name servers within a protocol family is
inadvisable since the necessary glue RRsets (A or AAAA) are atomically
indivisible, and will be larger than a single resource record. Larger
RRsets are more likely to lead to or encounter truncation.
4.5. Multi-homing of name servers across protocol families is less
likely to lead to or encounter truncation, partly because multiprotocol
clients are more likely to speak EDNS which can use a larger response
size limit, and partly because the resource records (A and AAAA) are in
different RRsets and are therefore divisible from each other.
4.6. Name server names which are at or below the zone they serve are
more sensitive to referral response truncation, and glue records for
them should be considered "less optional" than other glue records, in
the assembly of referral responses.
4.7. If a zone is served by thirteen (13) name servers having a common
parent name (such as ?.ROOT-SERVERS.NET) and each such name server has a
single address record in some protocol family (e.g., an A RR), then all
thirteen name servers or any subset thereof could multi-home in a second
protocol family by adding a second address record (e.g., an AAAA RR)
without reducing the reachability of the zone thus served.
5 - Source Code
#!/usr/bin/perl
#
# SYNOPSIS
# repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
# if all queries are assumed to have a same zone suffix,
# such as "jp" in JP TLD servers, specify it in -z option
#
use strict;
use Getopt::Std;
Expires January 2007 [Page 8]
INTERNET-DRAFT August 2006 RESPSIZE
my ($sz_msg) = (512);
my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
my (%namedb, $name, $nssect, %opts, $optz);
my $n_ns = 0;
getopt('z', %opts);
if (defined($opts{'z'})) {
server_name_len($opts{'z'}); # just register it
}
foreach $name (@ARGV) {
my $len;
$n_ns++;
$len = server_name_len($name);
print "$name requires $len bytes\n";
$nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl
+ $sz_rdlen + $len;
}
print "# of NS: $n_ns\n";
arsect(255, $nssect, $n_ns, "maximum");
arsect(64, $nssect, $n_ns, "average");
sub server_name_len {
my ($name) = @_;
my (@labels, $len, $n, $suffix);
$name =~ tr/A-Z/a-z/;
@labels = split(/\./, $name);
$len = length(join('.', @labels)) + 2;
for ($n = 0; $#labels >= 0; $n++, shift @labels) {
$suffix = join('.', @labels);
return length($name) - length($suffix) + $sz_ptr
if (defined($namedb{$suffix}));
$namedb{$suffix} = 1;
}
return $len;
}
sub arsect {
my ($sz_query, $nssect, $n_ns, $cond) = @_;
my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
$ansect = $sz_query + 1 + $sz_type + $sz_class;
$space = $sz_msg - $sz_header - $ansect - $nssect;
$n_a = atmost(int($space / $sz_rr_a), $n_ns);
Expires January 2007 [Page 9]
INTERNET-DRAFT August 2006 RESPSIZE
$n_a_aaaa = atmost(int($space
/ ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
$n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns)
/ $sz_rr_aaaa), $n_ns);
printf "For %s size query (%d byte):\n", $cond, $sz_query;
printf " only A is considered: ";
printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
printf " A and AAAA are considered: ";
printf "# of A+AAAA is %d (%s)\n",
$n_a_aaaa, &judge($n_a_aaaa, $n_ns);
printf " preferred-glue A is assumed: ";
printf "# of A is %d, # of AAAA is %d (%s)\n",
$n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
}
sub judge {
my ($n, $n_ns) = @_;
return "green" if ($n >= $n_ns);
return "yellow" if ($n >= 2);
return "orange" if ($n == 1);
return "red";
}
sub atmost {
my ($a, $b) = @_;
return 0 if ($a < 0);
return $b if ($a > $b);
return $a;
}
6 - Security Considerations
The recommendations contained in this document have no known security
implications.
7 - IANA Considerations
This document does not call for changes or additions to any IANA
registry.
8 - Acknowledgement
The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews
for their valuable comments and suggestions.
Expires January 2007 [Page 10]
INTERNET-DRAFT August 2006 RESPSIZE
This work was supported by the US National Science Foundation (research
grant SCI-0427144) and DNS-OARC.
9 - References
[RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities",
RFC1034, November 1987.
[RFC1035] Mockapetris, P.V., "Domain names - Implementation and
Specification", RFC1035, November 1987.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", RFC1123, October 1989.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC1996, August 1996.
[RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification",
RFC2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC2308, March 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671,
August 1999.
[RFC4472] Durand, A., Ihren, J., Savola, P., "Operational Consideration
and Issues with IPV6 DNS", April 2006.
10 - Authors' Addresses
Paul Vixie
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
+1 650 423 1301
vixie@isc.org
Akira Kato
University of Tokyo, Information Technology Center
2-11-16 Yayoi Bunkyo
Tokyo 113-8658, JAPAN
+81 3 5841 2750
kato@wide.ad.jp
Expires January 2007 [Page 11]
INTERNET-DRAFT August 2006 RESPSIZE
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors retain
all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this
standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Expires January 2007 [Page 12]

618
doc/draft/draft-ietf-dnsop-serverid-06.txt Normal file
View file

@ -0,0 +1,618 @@
Network Working Group S. Woolf
Internet-Draft Internet Systems Consortium, Inc.
Expires: September 6, 2006 D. Conrad
Nominum, Inc.
March 5, 2006
Requirements for a Mechanism Identifying a Name Server Instance
draft-ietf-dnsop-serverid-06
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 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
With the increased use of DNS anycast, load balancing, and other
mechanisms allowing more than one DNS name server to share a single
IP address, it is sometimes difficult to tell which of a pool of name
servers has answered a particular query. A standardized mechanism to
determine the identity of a name server responding to a particular
query would be useful, particularly as a diagnostic aid for
administrators. Existing ad hoc mechanisms for addressing this need
Woolf & Conrad Expires September 6, 2006 [Page 1]
Internet-Draft Serverid March 2006
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
some widely deployed implementations of the DNS protocol, including
advantages and disadvantages, and discusses some attributes of an
improved mechanism.
Woolf & Conrad Expires September 6, 2006 [Page 2]
Internet-Draft Serverid March 2006
1. Introduction and Rationale
Identifying which name server is responding to queries is often
useful, particularly in attempting to diagnose name server
difficulties. This is most obviously useful for authoritative
nameservers in the attempt to diagnose the source or prevalence of
inaccurate data, but can also conceivably be useful for caching
resolvers in similar and other situations. Furthermore, the ability
to identify which server is responding to a query has become more
useful as DNS has become more critical to more Internet users, and as
network and server deployment topologies have become more complex.
The traditional means for determining which of several possible
servers is answering a query has traditionally been based on the use
of the server's IP address as a unique identifier. However, the
modern Internet has seen the deployment of various load balancing,
fault-tolerance, or attack-resistance schemes such as shared use of
unicast IP addresses as documented in [RFC3258]. An unfortunate side
effect of these schemes has been to make the use of IP addresses as
identifiers somewhat problematic. Specifically, a dedicated DNS
query may not go to the same server as answered a previous query,
even though sent to the same IP address. Non-DNS methods such as
ICMP ping, TCP connections, or non-DNS UDP packets (such as those
generated by tools like "traceroute"), etc., may well be even less
certain to reach the same server as the one 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 the query I sent to IP address XXX".
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 6, 2006 [Page 3]
Internet-Draft Serverid March 2006
2. Existing Conventions
For some time, the commonly deployed Berkeley Internet Name Domain
implementation of the DNS protocol suite from the Internet Systems
Consortium [BIND] has supported a way of identifying a particular
server via the use of a standards-compliant, if somewhat unusual, DNS
query. Specifically, a query to a recent 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. (The value defaults to the result 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.
A refinement to the BIND-based mechanism, which dropped the
implementation-specific string, replaces ".BIND" with ".SERVER".
Thus the query string to learn the unique name of a server may be
queried as "ID.SERVER".
(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 CHAOS 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.)
2.1. Advantages
There are several valuable attributes to this mechanism, which
account for its usefulness.
1. The "HOSTNAME.BIND" or "ID.SERVER" 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 system 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 is likely to
reach the same server over a path subject to the same routing,
resource, and security policy as the query, without any special
exceptions to site security policy.
Woolf & Conrad Expires September 6, 2006 [Page 4]
Internet-Draft Serverid March 2006
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.
5. Hypothetically, since it's an ordinary DNS record and the
relevant DNSSEC RRs are class independent, the id.server response
RR could be signed, which has the advantages described in
[RFC4033].
2.2. Disadvantages
At the same time, there are some serious drawbacks to the CHAOS/TXT
query mechanism that argue against standardizing it as it currently
operates.
1. It requires an additional query to correlate between the answer
to a DNS query under normal conditions and the supposed identity
of the server receiving the query. There are a number of
situations in which this simply isn't reliable.
2. It reserves an entire class in the DNS (CHAOS) for what amounts
to one zone. While CHAOS class is defined in [RFC1034] and
[RFC1035], it's not clear that supporting it solely for this
purpose is a good use of the namespace or of implementation
effort.
3. The initial and still common form, using .BIND, 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. Meanwhile, the proposed refinement changes the
string but preserves the ad hoc CHAOS/TXT mechanism.
4. There is no convention or shared understanding of what
information an answer to such a query for a server identity could
or should include, including a possible encoding or
authentication mechanism.
The first of the listed disadvantages may be 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 6, 2006 [Page 5]
Internet-Draft Serverid March 2006
2.3. 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. But it should preserve the ability of
the CHAOS/TXT query-based mechanism to work through firewalls and
in other situations where only DNS can be relied upon to reach
the server of interest.
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. It should be possible to authenticate the received data by some
mechanism analogous to those provided by DNSSEC. In this
context, the need could be met by including encryption options in
the specification of a new mechanism.
6. The identification mechanism should not be implementation-
specific.
Woolf & Conrad Expires September 6, 2006 [Page 6]
Internet-Draft Serverid March 2006
3. 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. A proposed extension, specified and adopted by normal IETF
process, is described in [NSID], including relevant IANA action.
Woolf & Conrad Expires September 6, 2006 [Page 7]
Internet-Draft Serverid March 2006
4. 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.
Both authentication and confidentiality of serverid data are
potentially of interest to administrators-- that is, operators may
wish to make serverid data available and reliable to themselves and
their chosen associates only. This would imply both an ability to
authenticate it to themselves and keep it private from arbitrary
other parties. This led to Characteristics 4 and 5 of an improved
solution.
Woolf & Conrad Expires September 6, 2006 [Page 8]
Internet-Draft Serverid March 2006
5. 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.
6. References
[1] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 0013, November 1987.
[2] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, STD 0013, November 1987.
[3] Hardie, T., "Distributing Authoritative Name Servers via Shared
Unicast Addresses", RFC 3258, April 2002.
[4] ISC, "BIND 9 Configuration Reference".
[5] Austein, S., "DNS Name Server Identifier Option (NSID)",
Internet Drafts http://www.ietf.org/internet-drafts/
draft-ietf-dnsext-nsid-01.txt, January 2006.
[6] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
Woolf & Conrad Expires September 6, 2006 [Page 9]
Internet-Draft Serverid March 2006
Authors' Addresses
Suzanne Woolf
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
US
Phone: +1 650 423-1333
Email: woolf@isc.org
URI: http://www.isc.org/
David Conrad
Nominum, Inc.
2385 Bay Road
Redwood City, CA 94063
US
Phone: +1 1 650 381 6003
Email: david.conrad@nominum.com
URI: http://www.nominum.com/
Woolf & Conrad Expires September 6, 2006 [Page 10]
Internet-Draft Serverid March 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). 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 6, 2006 [Page 11]