diff --git a/contrib/dbus/Makefile.9.3.2b1 b/contrib/dbus/Makefile.9.3.2b1 new file mode 100644 index 0000000000..6285034426 --- /dev/null +++ b/contrib/dbus/Makefile.9.3.2b1 @@ -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 diff --git a/contrib/dbus/Makefile.9.3.3rc2 b/contrib/dbus/Makefile.9.3.3rc2 new file mode 100644 index 0000000000..91a0ffe08d --- /dev/null +++ b/contrib/dbus/Makefile.9.3.3rc2 @@ -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 diff --git a/contrib/dbus/bind-9.3.3rc2-dbus.patch b/contrib/dbus/bind-9.3.3rc2-dbus.patch new file mode 100644 index 0000000000..9048db71e0 --- /dev/null +++ b/contrib/dbus/bind-9.3.3rc2-dbus.patch @@ -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 @@ + * 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 + #endif + ++#include ++ + /* + * 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@ diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt new file mode 100644 index 0000000000..c8db70916f --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt @@ -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] + diff --git a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt new file mode 100644 index 0000000000..2460cb619b --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt @@ -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] + diff --git a/doc/draft/draft-ietf-dnsext-mdns-46.txt b/doc/draft/draft-ietf-dnsext-mdns-46.txt new file mode 100644 index 0000000000..63d0b23af6 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-mdns-46.txt @@ -0,0 +1,1801 @@ + + + + + + +DNSEXT Working Group Bernard Aboba +INTERNET-DRAFT Dave Thaler +Category: Standards Track Levon Esibov + Microsoft Corporation +16 April 2006 + + Linklocal Multicast Name Resolution (LLMNR) + +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 15, 2006. + +Copyright Notice + + Copyright (C) The Internet Society 2006. + +Abstract + + The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable + name resolution in scenarios in which conventional DNS name + resolution is not possible. LLMNR supports all current and future + DNS formats, types and classes, while operating on a separate port + from DNS, and with a distinct resolver cache. Since LLMNR only + operates on the local link, it cannot be considered a substitute for + DNS. + + + + + +Aboba, Thaler & Esibov Standards Track [Page 1] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +Table of Contents + +1. Introduction .......................................... 3 + 1.1 Requirements .................................... 4 + 1.2 Terminology ..................................... 4 +2. Name Resolution Using LLMNR ........................... 4 + 2.1 LLMNR Packet Format ............................. 5 + 2.2 Sender Behavior ................................. 8 + 2.3 Responder Behavior .............................. 8 + 2.4 Unicast Queries and Responses ................... 11 + 2.5 Off-link Detection .............................. 11 + 2.6 Responder Responsibilities ...................... 12 + 2.7 Retransmission and Jitter ....................... 13 + 2.8 DNS TTL ......................................... 14 + 2.9 Use of the Authority and Additional Sections .... 14 +3. Usage model ........................................... 15 + 3.1 LLMNR Configuration ............................. 16 +4. Conflict Resolution ................................... 18 + 4.1 Uniqueness Verification ......................... 18 + 4.2 Conflict Detection and Defense .................. 19 + 4.3 Considerations for Multiple Interfaces .......... 20 + 4.4 API issues ...................................... 22 +5. Security Considerations ............................... 22 + 5.1 Denial of Service ............................... 22 + 5.2 Spoofing ...............,........................ 23 + 5.3 Authentication .................................. 24 + 5.4 Cache and Port Separation ....................... 24 +6. IANA considerations ................................... 25 +7. Constants ............................................. 25 +8. References ............................................ 26 + 8.1 Normative References ............................ 26 + 8.2 Informative References .......................... 26 +Acknowledgments .............................................. 28 +Authors' Addresses ........................................... 28 +Intellectual Property Statement .............................. 29 +Disclaimer of Validity ....................................... 29 +Copyright Statement .......................................... 29 + + + + + + + + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 2] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +1. Introduction + + This document discusses Link Local Multicast Name Resolution (LLMNR), + which is based on the DNS packet format and supports all current and + future DNS formats, types and classes. LLMNR operates on a separate + port from the Domain Name System (DNS), with a distinct resolver + cache. + + Since LLMNR only operates on the local link, it cannot be considered + a substitute for DNS. Link-scope multicast addresses are used to + prevent propagation of LLMNR traffic across routers, potentially + flooding the network. LLMNR queries can also be sent to a unicast + address, as described in Section 2.4. + + Propagation of LLMNR packets on the local link is considered + sufficient to enable name resolution in small networks. In such + networks, if a network has a gateway, then typically the network is + able to provide DNS server configuration. Configuration issues are + discussed in Section 3.1. + + In the future, it may be desirable to consider use of multicast name + resolution with multicast scopes beyond the link-scope. This could + occur if LLMNR deployment is successful, the need arises for + multicast name resolution beyond the link-scope, or multicast routing + becomes ubiquitous. For example, expanded support for multicast name + resolution might be required for mobile ad-hoc networks. + + Once we have experience in LLMNR deployment in terms of + administrative issues, usability and impact on the network, it will + be possible to reevaluate which multicast scopes are appropriate for + use with multicast name resolution. IPv4 administratively scoped + multicast usage is specified in "Administratively Scoped IP + Multicast" [RFC2365]. + + Service discovery in general, as well as discovery of DNS servers + using LLMNR in particular, is outside of the scope of this document, + as is name resolution over non-multicast capable media. + +1.1. Requirements + + In this document, several words are used to signify the requirements + of the specification. The key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 3] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +1.2. Terminology + + This document assumes familiarity with DNS terminology defined in + [RFC1035]. Other terminology used in this document includes: + +Routable Address + An address other than a Link-Local address. This includes globally + routable addresses, as well as private addresses. + +Reachable + An LLMNR responder considers one of its addresses reachable over a + link if it will respond to an ARP or Neighbor Discovery query for + that address received on that link. + +Responder + A host that listens to LLMNR queries, and responds to those for + which it is authoritative. + +Sender + A host that sends an LLMNR query. + +UNIQUE + There are some scenarios when multiple responders may respond to + the same query. There are other scenarios when only one responder + may respond to a query. Names for which only a single responder is + anticipated are referred to as UNIQUE. Name uniqueness is + configured on the responder, and therefore uniqueness verification + is the responder's responsibility. + +2. Name Resolution Using LLMNR + + LLMNR queries are sent to and received on port 5355. The IPv4 link- + scope multicast address a given responder listens to, and to which a + sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast + address a given responder listens to, and to which a sender sends all + queries, is FF02:0:0:0:0:0:1:3. + + Typically a host is configured as both an LLMNR sender and a + responder. A host MAY be configured as a sender, but not a + responder. However, a host configured as a responder MUST act as a + sender, if only to verify the uniqueness of names as described in + Section 4. This document does not specify how names are chosen or + configured. This may occur via any mechanism, including DHCPv4 + [RFC2131] or DHCPv6 [RFC3315]. + + A typical sequence of events for LLMNR usage is as follows: + + [a] An LLMNR sender sends an LLMNR query to the link-scope + + + +Aboba, Thaler & Esibov Standards Track [Page 4] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + multicast address(es), unless a unicast query is indicated, + as specified in Section 2.4. + + [b] A responder responds to this query only if it is authoritative + for the name in the query. A responder responds to a + multicast query by sending a unicast UDP response to the sender. + Unicast queries are responded to as indicated in Section 2.4. + + [c] Upon reception of the response, the sender processes it. + + The sections that follow provide further details on sender and + responder behavior. + +2.1. LLMNR Packet Format + + LLMNR is based on the DNS packet format defined in [RFC1035] Section + 4 for both queries and responses. LLMNR implementations SHOULD send + UDP queries and responses only as large as are known to be + permissible without causing fragmentation. When in doubt a maximum + packet size of 512 octets SHOULD be used. LLMNR implementations MUST + accept UDP queries and responses as large as the smaller of the link + MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22 + octets for the header, VLAN tag and CRC). + +2.1.1. LLMNR Header Format + + LLMNR queries and responses utilize the DNS header format defined in + [RFC1035] with exceptions noted below: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + + + + +Aboba, Thaler & Esibov Standards Track [Page 5] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +ID A 16 bit identifier assigned by the program that generates any kind + of query. This identifier is copied from the query to the response + and can be used by the sender to match responses to outstanding + queries. The ID field in a query SHOULD be set to a pseudo-random + value. For advice on generation of pseudo-random values, please + consult [RFC1750]. + +QR Query/Response. A one bit field, which if set indicates that the + message is an LLMNR response; if clear then the message is an LLMNR + query. + +OPCODE + A four bit field that specifies the kind of query in this message. + This value is set by the originator of a query and copied into the + response. This specification defines the behavior of standard + queries and responses (opcode value of zero). Future + specifications may define the use of other opcodes with LLMNR. + LLMNR senders and responders MUST support standard queries (opcode + value of zero). LLMNR queries with unsupported OPCODE values MUST + be silently discarded by responders. + +C Conflict. When set within a request, the 'C'onflict bit indicates + that a sender has received multiple LLMNR responses to this query. + In an LLMNR response, if the name is considered UNIQUE, then the + 'C' bit is clear, otherwise it is set. LLMNR senders do not + retransmit queries with the 'C' bit set. Responders MUST NOT + respond to LLMNR queries with the 'C' bit set, but may start the + uniqueness verification process, as described in Section 4.2. + +TC TrunCation - specifies that this message was truncated due to + length greater than that permitted on the transmission channel. + The TC bit MUST NOT be set in an LLMNR query and if set is ignored + by an LLMNR responder. If the TC bit is set in an LLMNR response, + then the sender SHOULD resend the LLMNR query over TCP using the + unicast address of the responder as the destination address. If + the sender receives a response to the TCP query, then it SHOULD + discard the UDP response with the TC bit set. See [RFC2181] and + Section 2.4 of this specification for further discussion of the TC + bit. + +T Tentative. The 'T'entative bit is set in a response if the + responder is authoritative for the name, but has not yet verified + the uniqueness of the name. A responder MUST ignore the 'T' bit in + a query, if set. A response with the 'T' bit set is silently + discarded by the sender, except if it is a uniqueness query, in + which case a conflict has been detected and a responder MUST + resolve the conflict as described in Section 4.1. + + + + +Aboba, Thaler & Esibov Standards Track [Page 6] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +Z Reserved for future use. Implementations of this specification + MUST set these bits to zero in both queries and responses. If + these bits are set in a LLMNR query or response, implementations of + this specification MUST ignore them. Since reserved bits could + conceivably be used for different purposes than in DNS, + implementors are advised not to enable processing of these bits in + an LLMNR implementation starting from a DNS code base. + +RCODE + Response code -- this 4 bit field is set as part of LLMNR + responses. In an LLMNR query, the sender MUST set RCODE to zero; + the responder ignores the RCODE and assumes it to be zero. The + response to a multicast LLMNR query MUST have RCODE set to zero. A + sender MUST silently discard an LLMNR response with a non-zero + RCODE sent in response to a multicast query. + + If an LLMNR responder is authoritative for the name in a multicast + query, but an error is encountered, the responder SHOULD send an + LLMNR response with an RCODE of zero, no RRs in the answer section, + and the TC bit set. This will cause the query to be resent using + TCP, and allow the inclusion of a non-zero RCODE in the response to + the TCP query. Responding with the TC bit set is preferable to not + sending a response, since it enables errors to be diagnosed. This + may be required, for example, when an LLMNR query includes a TSIG + RR in the additional section, and the responder encounters a + problem that requires returning a non-zero RCODE. TSIG error + conditions defined in [RFC2845] include a TSIG RR in an + unacceptable position (RCODE=1) or a TSIG RR which does not + validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)). + + Since LLMNR responders only respond to LLMNR queries for names for + which they are authoritative, LLMNR responders MUST NOT respond + with an RCODE of 3; instead, they should not respond at all. + + LLMNR implementations MUST support EDNS0 [RFC2671] and extended + RCODE values. + +QDCOUNT + An unsigned 16 bit integer specifying the number of entries in the + question section. A sender MUST place only one question into the + question section of an LLMNR query. LLMNR responders MUST silently + discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders + MUST silently discard LLMNR responses with QDCOUNT not equal to + one. + +ANCOUNT + An unsigned 16 bit integer specifying the number of resource + records in the answer section. LLMNR responders MUST silently + + + +Aboba, Thaler & Esibov Standards Track [Page 7] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + discard LLMNR queries with ANCOUNT not equal to zero. + +NSCOUNT + An unsigned 16 bit integer specifying the number of name server + resource records in the authority records section. Authority + record section processing is described in Section 2.9. LLMNR + responders MUST silently discard LLMNR queries with NSCOUNT not + equal to zero. + +ARCOUNT + An unsigned 16 bit integer specifying the number of resource + records in the additional records section. Additional record + section processing is described in Section 2.9. + +2.2. Sender Behavior + + A sender MAY send an LLMNR query for any legal resource record type + (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address. + As described in Section 2.4, a sender MAY also send a unicast query. + + The sender MUST anticipate receiving no replies to some LLMNR + queries, in the event that no responders are available within the + link-scope. If no response is received, a resolver treats it as a + response that the name does not exist (RCODE=3 is returned). A + sender can handle duplicate responses by discarding responses with a + source IP address and ID field that duplicate a response already + received. + + When multiple valid LLMNR responses are received with the 'C' bit + set, they SHOULD be concatenated and treated in the same manner that + multiple RRs received from the same DNS server would be. However, + responses with the 'C' bit set SHOULD NOT be concatenated with + responses with the 'C' bit clear; instead, only the responses with + the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are + received along with error response(s), then the error responses are + silently discarded. + + Since the responder may order the RRs in the response so as to + indicate preference, the sender SHOULD preserve ordering in the + response to the querying application. + +2.3. Responder Behavior + + An LLMNR response MUST be sent to the sender via unicast. + + Upon configuring an IP address, responders typically will synthesize + corresponding A, AAAA and PTR RRs so as to be able to respond to + LLMNR queries for these RRs. An SOA RR is synthesized only when a + + + +Aboba, Thaler & Esibov Standards Track [Page 8] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + responder has another RR in addition to the SOA RR; the SOA RR MUST + NOT be the only RR that a responder has. However, in general whether + RRs are manually or automatically created is an implementation + decision. + + For example, a host configured to have computer name "host1" and to + be a member of the "example.com" domain, and with IPv4 address + 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be + authoritative for the following records: + + host1. IN A 192.0.2.1 + IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + host1.example.com. IN A 192.0.2.1 + IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + 1.2.0.192.in-addr.arpa. IN PTR host1. + IN PTR host1.example.com. + + 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2. + ip6.arpa IN PTR host1. (line split for formatting reasons) + IN PTR host1.example.com. + + An LLMNR responder might be further manually configured with the name + of a local mail server with an MX RR included in the "host1." and + "host1.example.com." records. + + In responding to queries: + +[a] Responders MUST listen on UDP port 5355 on the link-scope multicast + address(es) defined in Section 2, and on TCP port 5355 on the + unicast address(es) that could be set as the source address(es) + when the responder responds to the LLMNR query. + +[b] Responders MUST direct responses to the port from which the query + was sent. When queries are received via TCP this is an inherent + part of the transport protocol. For queries received by UDP the + responder MUST take note of the source port and use that as the + destination port in the response. Responses MUST always be sent + from the port to which they were directed. + +[c] Responders MUST respond to LLMNR queries for names and addresses + they are authoritative for. This applies to both forward and + reverse lookups, with the exception of queries with the 'C' bit + set, which do not elicit a response. + +[d] Responders MUST NOT respond to LLMNR queries for names they are not + authoritative for. + + + +Aboba, Thaler & Esibov Standards Track [Page 9] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +[e] Responders MUST NOT respond using data from the LLMNR or DNS + resolver cache. + +[f] If a DNS server is running on a host that supports LLMNR, the DNS + server MUST respond to LLMNR queries only for the RRSets relating + to the host on which the server is running, but MUST NOT respond + for other records for which the server is authoritative. DNS + servers also MUST NOT send LLMNR queries in order to resolve DNS + queries. + +[g] If a responder is authoritative for a name, it MUST respond with + RCODE=0 and an empty answer section, if the type of query does not + match a RR that the responder has. + + As an example, a host configured to respond to LLMNR queries for the + name "foo.example.com." is authoritative for the name + "foo.example.com.". On receiving an LLMNR query for an A RR with the + name "foo.example.com." the host authoritatively responds with A + RR(s) that contain IP address(es) in the RDATA of the resource + record. If the responder has a AAAA RR, but no A RR, and an A RR + query is received, the responder would respond with RCODE=0 and an + empty answer section. + + In conventional DNS terminology a DNS server authoritative for a zone + is authoritative for all the domain names under the zone apex except + for the branches delegated into separate zones. Contrary to + conventional DNS terminology, an LLMNR responder is authoritative + only for the zone apex. + + For example the host "foo.example.com." is not authoritative for the + name "child.foo.example.com." unless the host is configured with + multiple names, including "foo.example.com." and + "child.foo.example.com.". As a result, "foo.example.com." cannot + reply to an LLMNR query for "child.foo.example.com." with RCODE=3 + (authoritative name error). The purpose of limiting the name + authority scope of a responder is to prevent complications that could + be caused by coexistence of two or more hosts with the names + representing child and parent (or grandparent) nodes in the DNS tree, + for example, "foo.example.com." and "child.foo.example.com.". + + Without the restriction on authority an LLMNR query for an A resource + record for the name "child.foo.example.com." would result in two + authoritative responses: RCODE=3 (authoritative name error) received + from "foo.example.com.", and a requested A record - from + "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled + hosts could perform a dynamic update of the parent (or grandparent) + zone with a delegation to a child zone; for example a host + "child.foo.example.com." could send a dynamic update for the NS and + + + +Aboba, Thaler & Esibov Standards Track [Page 10] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + glue A record to "foo.example.com.". However, this approach + significantly complicates implementation of LLMNR and would not be + acceptable for lightweight hosts. + +2.4. Unicast Queries and Responses + + Unicast queries SHOULD be sent when: + + [a] A sender repeats a query after it received a response + with the TC bit set to the previous LLMNR multicast query, or + + [b] The sender queries for a PTR RR of a fully formed IP address + within the "in-addr.arpa" or "ip6.arpa" zones. + + Unicast LLMNR queries MUST be done using TCP and the responses MUST + be sent using the same TCP connection as the query. Senders MUST + support sending TCP queries, and responders MUST support listening + for TCP queries. If the sender of a TCP query receives a response to + that query not using TCP, the response MUST be silently discarded. + + Unicast UDP queries MUST be silently discarded. + + A unicast PTR RR query for an off-link address will not elicit a + response, but instead an ICMP TTL or Hop Limit exceeded message will + be received. An implementation receiving an ICMP message in response + to a TCP connection setup attempt can return immediately, treating + this as a response that no such name exists (RCODE=3 is returned). + An implementation that cannot process ICMP messages MAY send + multicast UDP queries for PTR RRs. Since TCP implementations will + not retransmit prior to RTOmin, a considerable period will elapse + before TCP retransmits multiple times, resulting in a long timeout + for TCP PTR RR queries sent to an off-link destination. + +2.5. "Off link" Detection + + A sender MUST select a source address for LLMNR queries that is + assigned on the interface on which the query is sent. The + destination address of an LLMNR query MUST be a link-scope multicast + address or a unicast address. + + A responder MUST select a source address for responses that is + assigned on the interface on which the query was received. The + destination address of an LLMNR response MUST be a unicast address. + + On receiving an LLMNR query, the responder MUST check whether it was + sent to a LLMNR multicast addresses defined in Section 2. If it was + sent to another multicast address, then the query MUST be silently + discarded. + + + +Aboba, Thaler & Esibov Standards Track [Page 11] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + Section 2.4 discusses use of TCP for LLMNR queries and responses. In + composing an LLMNR query using TCP, the sender MUST set the Hop Limit + field in the IPv6 header and the TTL field in the IPv4 header of the + response to one (1). The responder SHOULD set the TTL or Hop Limit + settings on the TCP listen socket to one (1) so that SYN-ACK packets + will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This + prevents an incoming connection from off-link since the sender will + not receive a SYN-ACK from the responder. + + For UDP queries and responses, the Hop Limit field in the IPv6 header + and the TTL field in the IPV4 header MAY be set to any value. + However, it is RECOMMENDED that the value 255 be used for + compatibility with early implementations of [RFC3927]. + + Implementation note: + + In the sockets API for IPv4 [POSIX], the IP_TTL and + IP_MULTICAST_TTL socket options are used to set the TTL of + outgoing unicast and multicast packets. The IP_RECVTTL socket + option is available on some platforms to retrieve the IPv4 TTL of + received packets with recvmsg(). [RFC2292] specifies similar + options for setting and retrieving the IPv6 Hop Limit. + +2.6. Responder Responsibilities + + It is the responsibility of the responder to ensure that RRs returned + in LLMNR responses MUST only include values that are valid on the + local interface, such as IPv4 or IPv6 addresses valid on the local + link or names defended using the mechanism described in Section 4. + IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local + addresses are defined in [RFC2373]. In particular: + + [a] If a link-scope IPv6 address is returned in a AAAA RR, + that address MUST be valid on the local link over which + LLMNR is used. + + [b] If an IPv4 address is returned, it MUST be reachable + through the link over which LLMNR is used. + + [c] If a name is returned (for example in a CNAME, MX + or SRV RR), the name MUST be resolvable on the local + link over which LLMNR is used. + + Where multiple addresses represent valid responses to a query, the + order in which the addresses are returned is as follows: + + [d] If the source address of the query is a link-scope address, + then the responder SHOULD include a link-scope address first + + + +Aboba, Thaler & Esibov Standards Track [Page 12] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + in the response, if available. + + [e] If the source address of the query is a routable address, + then the responder MUST include a routable address first + in the response, if available. + +2.7. Retransmission and Jitter + + An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine + when to retransmit an LLMNR query. An LLMNR sender SHOULD either + estimate the LLMNR_TIMEOUT for each interface, or set a reasonably + high initial timeout. Suggested constants are described in Section + 7. + + If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, + then a sender SHOULD repeat the transmission of the query in order to + assure that it was received by a host capable of responding to it. + An LLMNR query SHOULD NOT be sent more than three times. + + Where LLMNR queries are sent using TCP, retransmission is handled by + the transport layer. Queries with the 'C' bit set MUST be sent using + multicast UDP and MUST NOT be retransmitted. + + An LLMNR sender cannot know in advance if a query sent using + multicast will receive no response, one response, or more than one + response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response + has been received, or if it is necessary to collect all potential + responses, such as if a uniqueness verification query is being made. + Otherwise an LLMNR sender SHOULD consider a multicast query answered + after the first response is received, if that response has the 'C' + bit clear. + + However, if the first response has the 'C' bit set, then the sender + SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect + all possible responses. When multiple valid answers are received, + they may first be concatenated, and then treated in the same manner + that multiple RRs received from the same DNS server would. A unicast + query sender considers the query answered after the first response is + received. + + Since it is possible for a response with the 'C' bit clear to be + followed by a response with the 'C' bit set, an LLMNR sender SHOULD + be prepared to process additional responses for the purposes of + conflict detection, even after it has considered a query answered. + + In order to avoid synchronization, the transmission of each LLMNR + query and response SHOULD delayed by a time randomly selected from + the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by + + + +Aboba, Thaler & Esibov Standards Track [Page 13] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + responders responding with names which they have previously + determined to be UNIQUE (see Section 4 for details). + +2.8. DNS TTL + + The responder should insert a pre-configured TTL value in the records + returned in an LLMNR response. A default value of 30 seconds is + RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc + networks), the TTL value may need to be reduced. + + Due to the TTL minimalization necessary when caching an RRset, all + TTLs in an RRset MUST be set to the same value. + +2.9. Use of the Authority and Additional Sections + + Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a + concept of delegation. In LLMNR, the NS resource record type may be + stored and queried for like any other type, but it has no special + delegation semantics as it does in the DNS. Responders MAY have NS + records associated with the names for which they are authoritative, + but they SHOULD NOT include these NS records in the authority + sections of responses. + + Responders SHOULD insert an SOA record into the authority section of + a negative response, to facilitate negative caching as specified in + [RFC2308]. The TTL of this record is set from the minimum of the + MINIMUM field of the SOA record and the TTL of the SOA itself, and + indicates how long a resolver may cache the negative answer. The + owner name of the SOA record (MNAME) MUST be set to the query name. + The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored + by senders. Negative responses without SOA records SHOULD NOT be + cached. + + In LLMNR, the additional section is primarily intended for use by + EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, + senders MAY only include pseudo RR-types in the additional section of + a query; unless the 'C' bit is set, responders MUST ignore the + additional section of queries containing other RR types. + + In queries where the 'C' bit is set, the sender SHOULD include the + conflicting RRs in the additional section. Since conflict + notifications are advisory, responders SHOULD log information from + the additional section, but otherwise MUST ignore the additional + section. + + Senders MUST NOT cache RRs from the authority or additional section + of a response as answers, though they may be used for other purposes + such as negative caching. + + + +Aboba, Thaler & Esibov Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +3. Usage Model + + LLMNR is a peer-to-peer name resolution protocol that is not intended + as a replacement for DNS; rather, it enables name resolution in + scenarios in which conventional DNS name resolution is not possible. + This includes situations in which hosts are not configured with the + address of a DNS server; where the DNS server is unavailable or + unreachable; where there is no DNS server authoritative for the name + of a host, or where the authoritative DNS server does not have the + desired RRs. + + By default, an LLMNR sender SHOULD send LLMNR queries only for + single-label names. In order to reduce unnecessary DNS queries, stub + resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS + queries for single-label names. An LLMNR sender SHOULD NOT be + enabled to send a query for any name, except where security + mechanisms (described in Section 5.3) can be utilized. + + Regardless of whether security mechanisms can be utilized, LLMNR + queries SHOULD NOT be sent unless one of the following conditions are + met: + + [1] No manual or automatic DNS configuration has been performed. + If DNS server address(es) have been configured, a + host SHOULD attempt to reach DNS servers over all protocols + on which DNS server address(es) are configured, prior to sending + LLMNR queries. For dual stack hosts configured with DNS server + address(es) for one protocol but not another, this implies that + DNS queries SHOULD be sent over the protocol configured with + a DNS server, prior to sending LLMNR queries. + + [2] All attempts to resolve the name via DNS on all interfaces + have failed after exhausting the searchlist. This can occur + because DNS servers did not respond, or because they + responded to DNS queries with RCODE=3 (Authoritative Name + Error) or RCODE=0, and an empty answer section. Where a + single resolver call generates DNS queries for A and AAAA RRs, + an implementation MAY choose not to send LLMNR queries if any + of the DNS queries is successful. An LLMNR query SHOULD only + be sent for the originally requested name; a searchlist + is not used to form additional LLMNR queries. + + Since LLMNR is a secondary name resolution mechanism, its usage is in + part determined by the behavior of DNS implementations. In general, + robust DNS resolver implementations are more likely to avoid + unnecessary LLMNR queries. + + As noted in [DNSPerf], even when DNS servers are configured, a + + + +Aboba, Thaler & Esibov Standards Track [Page 15] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + significant fraction of DNS queries do not receive a response, or + result in negative responses due to missing inverse mappings or NS + records that point to nonexistent or inappropriate hosts. This has + the potential to result in a large number of unnecessary LLMNR + queries. + + [RFC1536] describes common DNS implementation errors and fixes. If + the proposed fixes are implemented, unnecessary LLMNR queries will be + reduced substantially, and so implementation of [RFC1536] is + recommended. + + For example, [RFC1536] Section 1 describes issues with retransmission + and recommends implementation of a retransmission policy based on + round trip estimates, with exponential back-off. [RFC1536] Section 4 + describes issues with failover, and recommends that resolvers try + another server when they don't receive a response to a query. These + policies are likely to avoid unnecessary LLMNR queries. + + [RFC1536] Section 3 describes zero answer bugs, which if addressed + will also reduce unnecessary LLMNR queries. + + [RFC1536] Section 6 describes name error bugs and recommended + searchlist processing that will reduce unnecessary RCODE=3 + (authoritative name) errors, thereby also reducing unnecessary LLMNR + queries. + + If error responses are received from both DNS and LLMNR, then the + lowest RCODE value should be returned. For example, if either DNS or + LLMNR receives a response with RCODE=0, then this should returned to + the caller. + +3.1. LLMNR Configuration + + LLMNR usage MAY be configured manually or automatically on a per + interface basis. By default, LLMNR responders SHOULD be enabled on + all interfaces, at all times. Enabling LLMNR for use in situations + where a DNS server has been configured will result in a change in + default behavior without a simultaneous update to configuration + information. Where this is considered undesirable, LLMNR SHOULD NOT + be enabled by default, so that hosts will neither listen on the link- + scope multicast address, nor will they send queries to that address. + + Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is + possible for a dual stack host to be configured with the address of a + DNS server over IPv4, while remaining unconfigured with a DNS server + suitable for use over IPv6. + + In these situations, a dual stack host will send AAAA queries to the + + + +Aboba, Thaler & Esibov Standards Track [Page 16] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + configured DNS server over IPv4. However, an IPv6-only host + unconfigured with a DNS server suitable for use over IPv6 will be + unable to resolve names using DNS. Automatic IPv6 DNS configuration + mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely + deployed, and not all DNS servers support IPv6. Therefore lack of + IPv6 DNS configuration may be a common problem in the short term, and + LLMNR may prove useful in enabling link-local name resolution over + IPv6. + + Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], + IPv6-only hosts may not be configured with a DNS server. Where there + is no DNS server authoritative for the name of a host or the + authoritative DNS server does not support dynamic client update over + IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not + be able to do DNS dynamic update, and other hosts will not be able to + resolve its name. + + For example, if the configured DNS server responds to a AAAA RR query + sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or + RCODE=0 and an empty answer section, then a AAAA RR query sent using + LLMNR over IPv6 may be successful in resolving the name of an + IPv6-only host on the local link. + + Similarly, if a DHCPv4 server is available providing DNS server + configuration, and DNS server(s) exist which are authoritative for + the A RRs of local hosts and support either dynamic client update + over IPv4 or DHCPv4-based dynamic update, then the names of local + IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no + DNS server is authoritative for the names of local hosts, or the + authoritative DNS server(s) do not support dynamic update, then LLMNR + enables linklocal name resolution over IPv4. + + Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to + configure LLMNR on an interface. The LLMNR Enable Option, described + in [LLMNREnable], can be used to explicitly enable or disable use of + LLMNR on an interface. The LLMNR Enable Option does not determine + whether or in which order DNS itself is used for name resolution. + The order in which various name resolution mechanisms should be used + can be specified using the Name Service Search Option (NSSO) for DHCP + [RFC2937], using the LLMNR Enable Option code carried in the NSSO + data. + + It is possible that DNS configuration mechanisms will go in and out + of service. In these circumstances, it is possible for hosts within + an administrative domain to be inconsistent in their DNS + configuration. + + For example, where DHCP is used for configuring DNS servers, one or + + + +Aboba, Thaler & Esibov Standards Track [Page 17] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + more DHCP servers can fail. As a result, hosts configured prior to + the outage will be configured with a DNS server, while hosts + configured after the outage will not. Alternatively, it is possible + for the DNS configuration mechanism to continue functioning while + configured DNS servers fail. + + An outage in the DNS configuration mechanism may result in hosts + continuing to use LLMNR even once the outage is repaired. Since + LLMNR only enables linklocal name resolution, this represents a + degradation in capabilities. As a result, hosts without a configured + DNS server may wish to periodically attempt to obtain DNS + configuration if permitted by the configuration mechanism in use. In + the absence of other guidance, a default retry interval of one (1) + minute is RECOMMENDED. + +4. Conflict Resolution + + By default, a responder SHOULD be configured to behave as though its + name is UNIQUE on each interface on which LLMNR is enabled. However, + it is also possible to configure multiple responders to be + authoritative for the same name. For example, multiple responders + MAY respond to a query for an A or AAAA type record for a cluster + name (assigned to multiple hosts in the cluster). + + To detect duplicate use of a name, an administrator can use a name + resolution utility which employs LLMNR and lists both responses and + responders. This would allow an administrator to diagnose behavior + and potentially to intervene and reconfigure LLMNR responders who + should not be configured to respond to the same name. + +4.1. Uniqueness Verification + + Prior to sending an LLMNR response with the 'T' bit clear, a + responder configured with a UNIQUE name MUST verify that there is no + other host within the scope of LLMNR query propagation that is + authoritative for the same name on that interface. + + Once a responder has verified that its name is UNIQUE, if it receives + an LLMNR query for that name, with the 'C' bit clear, it MUST + respond, with the 'T' bit clear. Prior to verifying that its name is + UNIQUE, a responder MUST set the 'T' bit in responses. + + Uniqueness verification is carried out when the host: + + - starts up or is rebooted + - wakes from sleep (if the network interface was inactive + during sleep) + - is configured to respond to LLMNR queries on an interface + + + +Aboba, Thaler & Esibov Standards Track [Page 18] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + enabled for transmission and reception of IP traffic + - is configured to respond to LLMNR queries using additional + UNIQUE resource records + - verifies the acquisition of a new IP address and configuration + on an interface + + To verify uniqueness, a responder MUST send an LLMNR query with the + 'C' bit clear, over all protocols on which it responds to LLMNR + queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify + uniqueness of a name by sending a query for the name with type='ANY'. + + If no response is received, the sender retransmits the query, as + specified in Section 2.7. If a response is received, the sender MUST + check if the source address matches the address of any of its + interfaces; if so, then the response is not considered a conflict, + since it originates from the sender. To avoid triggering conflict + detection, a responder that detects that it is connected to the same + link on multiple interfaces SHOULD set the 'C' bit in responses. + + If a response is received with the 'T' bit clear, the responder MUST + NOT use the name in response to LLMNR queries received over any + protocol (IPv4 or IPv6). If a response is received with the 'T' bit + set, the responder MUST check if the source IP address in the + response, interpreted as an unsigned integer, is less than the source + IP address in the query. If so, the responder MUST NOT use the name + in response to LLMNR queries received over any protocol (IPv4 or + IPv6). For the purpose of uniqueness verification, the contents of + the answer section in a response is irrelevant. + + Periodically carrying out uniqueness verification in an attempt to + detect name conflicts is not necessary, wastes network bandwidth, and + may actually be detrimental. For example, if network links are + joined only briefly, and are separated again before any new + communication is initiated, temporary conflicts are benign and no + forced reconfiguration is required. LLMNR responders SHOULD NOT + periodically attempt uniqueness verification. + +4.2. Conflict Detection and Defense + + Hosts on disjoint network links may configure the same name for use + with LLMNR. If these separate network links are later joined or + bridged together, then there may be multiple hosts which are now on + the same link, trying to use the same name. + + In order to enable ongoing detection of name conflicts, when an LLMNR + sender receives multiple LLMNR responses to a query, it MUST check if + the 'C' bit is clear in any of the responses. If so, the sender + SHOULD send another query for the same name, type and class, this + + + +Aboba, Thaler & Esibov Standards Track [Page 19] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + time with the 'C' bit set, with the potentially conflicting resource + records included in the additional section. + + Queries with the 'C' bit set are considered advisory and responders + MUST verify the existence of a conflict before acting on it. A + responder receiving a query with the 'C' bit set MUST NOT respond. + + If the query is for a UNIQUE name, then the responder MUST send its + own query for the same name, type and class, with the 'C' bit clear. + If a response is received, the sender MUST check if the source + address matches the address of any of its interfaces; if so, then the + response is not considered a conflict, since it originates from the + sender. To avoid triggering conflict detection, a responder that + detects that it is connected to the same link on multiple interfaces + SHOULD set the 'C' bit in responses. + + An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD + log them. Upon detecting a conflict, an LLMNR responder MUST + immediately stop using the conflicting name in response to LLMNR + queries received over any supported protocol, if the source IP + address in the response, interpreted as an unsigned integer, is less + than the source IP address in the uniqueness verification query. + + After stopping the use of a name, the responder MAY elect to + configure a new name. However, since name reconfiguration may be + disruptive, this is not required, and a responder may have been + configured to respond to multiple names so that alternative names may + already be available. A host that has stopped the use of a name may + attempt uniqueness verification again after the expiration of the TTL + of the conflicting response. + +4.3. Considerations for Multiple Interfaces + + A multi-homed host may elect to configure LLMNR on only one of its + active interfaces. In many situations this will be adequate. + However, should a host need to configure LLMNR on more than one of + its active interfaces, there are some additional precautions it MUST + take. Implementers who are not planning to support LLMNR on multiple + interfaces simultaneously may skip this section. + + Where a host is configured to issue LLMNR queries on more than one + interface, each interface maintains its own independent LLMNR + resolver cache, containing the responses to LLMNR queries. + + A multi-homed host checks the uniqueness of UNIQUE records as + described in Section 4. The situation is illustrated in figure 1. + + + + + +Aboba, Thaler & Esibov Standards Track [Page 20] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + ---------- ---------- + | | | | + [A] [myhost] [myhost] + + Figure 1. Link-scope name conflict + + In this situation, the multi-homed myhost will probe for, and defend, + its host name on both interfaces. A conflict will be detected on one + interface, but not the other. The multi-homed myhost will not be + able to respond with a host RR for "myhost" on the interface on the + right (see Figure 1). The multi-homed host may, however, be + configured to use the "myhost" name on the interface on the left. + + Since names are only unique per-link, hosts on different links could + be using the same name. If an LLMNR client sends requests over + multiple interfaces, and receives replies from more than one, the + result returned to the client is defined by the implementation. The + situation is illustrated in figure 2. + + ---------- ---------- + | | | | + [A] [myhost] [A] + + + Figure 2. Off-segment name conflict + + If host myhost is configured to use LLMNR on both interfaces, it will + send LLMNR queries on both interfaces. When host myhost sends a + query for the host RR for name "A" it will receive a response from + hosts on both interfaces. + + Host myhost cannot distinguish between the situation shown in Figure + 2, and that shown in Figure 3 where no conflict exists. + + [A] + | | + ----- ----- + | | + [myhost] + + Figure 3. Multiple paths to same host + + This illustrates that the proposed name conflict resolution mechanism + does not support detection or resolution of conflicts between hosts + on different links. This problem can also occur with DNS when a + multi-homed host is connected to two different networks with + separated name spaces. It is not the intent of this document to + address the issue of uniqueness of names within DNS. + + + +Aboba, Thaler & Esibov Standards Track [Page 21] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +4.4. API Issues + + [RFC2553] provides an API which can partially solve the name + ambiguity problem for applications written to use this API, since the + sockaddr_in6 structure exposes the scope within which each scoped + address exists, and this structure can be used for both IPv4 (using + v4-mapped IPv6 addresses) and IPv6 addresses. + + Following the example in Figure 2, an application on 'myhost' issues + the request getaddrinfo("A", ...) with ai_family=AF_INET6 and + ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both + interfaces and the resolver library will return a list containing + multiple addrinfo structures, each with an associated sockaddr_in6 + structure. This list will thus contain the IPv4 and IPv6 addresses + of both hosts responding to the name 'A'. Link-local addresses will + have a sin6_scope_id value that disambiguates which interface is used + to reach the address. Of course, to the application, Figures 2 and 3 + are still indistinguishable, but this API allows the application to + communicate successfully with any address in the list. + +5. Security Considerations + + LLMNR is a peer-to-peer name resolution protocol designed for use on + the local link. While LLMNR limits the vulnerability of responders + to off-link senders, it is possible for an off-link responder to + reach a sender. + + In scenarios such as public "hotspots" attackers can be present on + the same link. These threats are most serious in wireless networks + such as 802.11, since attackers on a wired network will require + physical access to the network, while wireless attackers may mount + attacks from a distance. Link-layer security such as [IEEE-802.11i] + can be of assistance against these threats if it is available. + + This section details security measures available to mitigate threats + from on and off-link attackers. + +5.1. Denial of Service + + Attackers may take advantage of LLMNR conflict detection by + allocating the same name, denying service to other LLMNR responders + and possibly allowing an attacker to receive packets destined for + other hosts. By logging conflicts, LLMNR responders can provide + forensic evidence of these attacks. + + An attacker may spoof LLMNR queries from a victim's address in order + to mount a denial of service attack. Responders setting the IPv6 Hop + Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP + + + +Aboba, Thaler & Esibov Standards Track [Page 22] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + response may be able to reach the victim across the Internet. + + While LLMNR responders only respond to queries for which they are + authoritative and LLMNR does not provide wildcard query support, an + LLMNR response may be larger than the query, and an attacker can + generate multiple responses to a query for a name used by multiple + responders. A sender may protect itself against unsolicited + responses by silently discarding them as rapidly as possible. + +5.2. Spoofing + + LLMNR is designed to prevent reception of queries sent by an off-link + attacker. LLMNR requires that responders receiving UDP queries check + that they are sent to a link-scope multicast address. However, it is + possible that some routers may not properly implement link-scope + multicast, or that link-scope multicast addresses may leak into the + multicast routing system. To prevent successful setup of TCP + connections by an off-link sender, responders receiving a TCP SYN + reply with a TCP SYN-ACK with TTL set to one (1). + + While it is difficult for an off-link attacker to send an LLMNR query + to a responder, it is possible for an off-link attacker to spoof a + response to a query (such as an A or AAAA query for a popular + Internet host), and by using a TTL or Hop Limit field larger than one + (1), for the forged response to reach the LLMNR sender. Since the + forged response will only be accepted if it contains a matching ID + field, choosing a pseudo-random ID field within queries provides some + protection against off-link responders. + + Since LLMNR queries can be sent when DNS server(s) do not respond, an + attacker can execute a denial of service attack on the DNS server(s) + and then poison the LLMNR cache by responding to an LLMNR query with + incorrect information. As noted in "Threat Analysis of the Domain + Name System (DNS)" [RFC3833] these threats also exist with DNS, since + DNS response spoofing tools are available that can allow an attacker + to respond to a query more quickly than a distant DNS server. + However, while switched networks or link layer security may make it + difficult for an on-link attacker to snoop unicast DNS queries, + multicast LLMNR queries are propagated to all hosts on the link, + making it possible for an on-link attacker to spoof LLMNR responses + without having to guess the value of the ID field in the query. + + Since LLMNR queries are sent and responded to on the local-link, an + attacker will need to respond more quickly to provide its own + response prior to arrival of the response from a legitimate + responder. If an LLMNR query is sent for an off-link host, spoofing + a response in a timely way is not difficult, since a legitimate + response will never be received. + + + +Aboba, Thaler & Esibov Standards Track [Page 23] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + This vulnerability can be reduced by limiting use of LLMNR to + resolution of single-label names as described in Section 3, or by + implementation of authentication (see Section 5.3). + +5.3. Authentication + + LLMNR is a peer-to-peer name resolution protocol, and as a result, + it is often deployed in situations where no trust model can be + assumed. Where a pre-arranged security configuration is possible, + the following security mechanisms may be used: + +[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0) + [RFC2931] security mechanisms. "DNS Name Service based on Secure + Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes + the use of TSIG to secure LLMNR, based on group keys. While group + keys can be used to demonstrate membership in a group, they do not + protect against forgery by an attacker that is a member of the + group. + +[b] IPsec ESP with a null-transform MAY be used to authenticate unicast + LLMNR queries and responses or LLMNR responses to multicast + queries. In a small network without a certificate authority, this + can be most easily accomplished through configuration of a group + pre-shared key for trusted hosts. As with TSIG, this does not + protect against forgery by an attacker with access to the group + pre-shared key. + +[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to + support DNSSEC, LLMNR implementations MAY be configured with trust + anchors, or they MAY make use of keys obtained from DNS queries. + Since LLMNR does not support "delegated trust" (CD or AD bits), + LLMNR implementations cannot make use of DNSSEC unless they are + DNSSEC-aware and support validation. Unlike approaches [a] or [b], + DNSSEC permits a responder to demonstrate ownership of a name, not + just membership within a trusted group. As a result, it enables + protection against forgery. + +5.4. Cache and Port Separation + + In order to prevent responses to LLMNR queries from polluting the DNS + cache, LLMNR implementations MUST use a distinct, isolated cache for + LLMNR on each interface. The use of separate caches is most + effective when LLMNR is used as a name resolution mechanism of last + resort, since this minimizes the opportunities for poisoning the + LLMNR cache, and decreases reliance on it. + + LLMNR operates on a separate port from DNS, reducing the likelihood + that a DNS server will unintentionally respond to an LLMNR query. + + + +Aboba, Thaler & Esibov Standards Track [Page 24] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + If LLMNR is given higher priority than DNS among the enabled name + resolution mechanisms, a denial of service attack on the DNS server + would not be necessary in order to poison the LLMNR cache, since + LLMNR queries would be sent even when the DNS server is available. + In addition, the LLMNR cache, once poisoned, would take precedence + over the DNS cache, eliminating the benefits of cache separation. As + a result, LLMNR SHOULD NOT be used as a primary name resolution + mechanism. + +6. IANA Considerations + + LLMNR requires allocation of port 5355 for both TCP and UDP. + + LLMNR requires allocation of link-scope multicast IPv4 address + 224.0.0.252, as well as link-scope multicast IPv6 address + FF02:0:0:0:0:0:1:3. + + This specification creates two new name spaces: the LLMNR namespace + and the reserved bits in the LLMNR header. The reserved bits in the + LLMNR header are allocated by IETF Consensus, in accordance with BCP + 26 [RFC2434]. + + In order to to avoid creating any new administrative procedures, + administration of the LLMNR namespace will piggyback on the + administration of the DNS namespace. + + The rights to use a fully qualified domain name (FQDN) within LLMNR + are obtained coincident with acquiring the rights to use that name + within DNS. Those wishing to use a FQDN within LLMNR should first + acquire the rights to use the corresponding FQDN within DNS. Using a + FQDN within LLMNR without ownership of the corresponding name in DNS + creates the possibility of conflict and therefore is discouraged. + + LLMNR responders may self-allocate a name within the single-label + name space, first defined in [RFC1001]. Since single-label names are + not unique, no registration process is required. + +7. Constants + + The following timing constants are used in this protocol; they are + not intended to be user configurable. + + JITTER_INTERVAL 100 ms + LLMNR_TIMEOUT 1 second (if set statically on all interfaces) + 100 ms (IEEE 802 media, including IEEE 802.11) + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 25] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +8. References + +8.1. Normative References + +[RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS + Service on a TCP/UDP Transport: Concepts and Methods", RFC + 1001, March 1987. + +[RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November 1987. + +[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + +[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC 2308, March 1998. + +[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + +[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October + 1998. + +[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + +[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + +[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + +8.2. Informative References + +[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of + Caching", IEEE/ACM Transactions on Networking, Volume 10, + Number 5, pp. 589, October 2002. + +[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local + unicast addresses to communicate with recursive DNS servers", + Internet draft (work in progress), draft-ietf-ipv6-dns- + discovery-07.txt, October 2002. + + + + +Aboba, Thaler & Esibov Standards Track [Page 26] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +[IEEE-802.11i] + Institute of Electrical and Electronics Engineers, "Supplement + to Standard for Telecommunications and Information Exchange + Between Systems - LAN/MAN Specific Requirements - Part 11: + Wireless LAN Medium Access Control (MAC) and Physical Layer + (PHY) Specifications: Specification for Enhanced Security", + IEEE 802.11i, July 2004. + +[LLMNREnable] + Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work + in progress), draft-guttman-mdns-enable-02.txt, April 2002. + +[LLMNRSec] + Jeong, J., Park, J. and H. Kim, "DNS Name Service based on + Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT + 2004, Phoenix Park, Korea, February 9-11, 2004. + +[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- + Portable Operating System Interface (POSIX). Open Group + Technical Standard: Base Specifications, Issue 6, December + 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin + +[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested + Fixes", RFC 1536, October 1993. + +[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + +[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + +[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", + RFC 2292, February 1998. + +[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC + 2365, July 1998. + +[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic + Socket Interface Extensions for IPv6", RFC 2553, March 1999. + +[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC + 2937, September 2000. + +[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + +[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + + + +Aboba, Thaler & Esibov Standards Track [Page 27] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration + of Link-Local IPv4 Addresses", RFC 3927, October 2004. + +[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "DNS Security Introduction and Requirement", RFC 4033, March + 2005. + +Acknowledgments + + This work builds upon original work done on multicast DNS by Bill + Manning and Bill Woodcock. Bill Manning's work was funded under + DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge + their contribution to the current specification. Constructive input + has also been received from Mark Andrews, Rob Austein, Randy Bush, + Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur + Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, + Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, + Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike + St. Johns, Sander Van-Valkenburg, and Brian Zill. + +Authors' Addresses + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 706 6605 + EMail: bernarda@microsoft.com + + Dave Thaler + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 703 8835 + EMail: dthaler@microsoft.com + + Levon Esibov + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + EMail: levone@microsoft.com + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 28] + + + + + +INTERNET-DRAFT LLMNR 16 April 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. + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 29] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +Open Issues + + Open issues with this specification are tracked on the following web + site: + + http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 30] + + + diff --git a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt new file mode 100644 index 0000000000..e169da8681 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt @@ -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 + --- ------ --- --------- ----------- -- --- --- + + 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 + . + + 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] + diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt new file mode 100644 index 0000000000..f6e8588e8c --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt @@ -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 + ------- -- -------------- ------ ----------- -- --- --- + + + + +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 + . + + 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] + diff --git a/doc/draft/draft-ietf-dnsop-respsize-06.txt b/doc/draft/draft-ietf-dnsop-respsize-06.txt new file mode 100644 index 0000000000..b041925afb --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-respsize-06.txt @@ -0,0 +1,640 @@ + + + + + + + DNSOP Working Group Paul Vixie, ISC + INTERNET-DRAFT Akira Kato, WIDE + 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] + + diff --git a/doc/draft/draft-ietf-dnsop-serverid-06.txt b/doc/draft/draft-ietf-dnsop-serverid-06.txt new file mode 100644 index 0000000000..c6ec7e42a5 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-serverid-06.txt @@ -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] + +