9.2.4rc6

23 files changed, 1733 insertions, 1966 deletions

diff --git a/CHANGES b/CHANGES
index 6f1520fe..21431631 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,4 +1,30 @@
 
+	--- 9.2.4rc6 released ---
+
+1685.	[bug]		Change #1679 loop tests weren't quite right.
+
+1682.	[port]		Update configure test for (long long) printf format.
+			[RT #5066]
+
+1681.	[bug]		Only set SO_REUSEADDR when a port is specified in
+			isc_socket_bind(). [RT #11742]
+
+1679.	[bug]		When there was a single nameserver with multiple
+			addresses for a zone not all addresses were tried.
+			[RT #11706]
+
+1672.	[cleanup]	Tests which only function in a threaded build
+			now return R:THREADONLY (rather than R:UNTESTED)
+			in a non-threaded build.
+
+1671.	[contrib]	queryperf: add NAPTR to the list of known types.
+
+1669.	[bug]		Restore "update forwarding denied" log messages
+			accidentally suppressed by change #1633. [RT# 11657]
+
+1660.	[bug]		win32: connection_reset_fix() was being called
+			unconditionally.  [RT #11595]
+
 	--- 9.2.4rc5 released ---
 
 1655.	[bug]		Logging multiple versions w/o a size was broken.
diff --git a/bin/named/update.c b/bin/named/update.c
index 3f00d43d..22829183 100644
--- a/bin/named/update.c
+++ b/bin/named/update.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: update.c,v 1.88.2.10 2004/06/04 03:45:15 marka Exp $ */
+/* $Id: update.c,v 1.88.2.11 2004/06/20 23:44:35 marka Exp $ */
 
 #include <config.h>
 
@@ -1979,6 +1979,9 @@ ns_update_start(ns_client_t *client, isc_result_t sigresult) {
 	case dns_zone_slave:
 		if (dns_zone_getforwardacl(zone) == NULL) {
 			result = DNS_R_NOTIMP;
+			ns_client_log(client, DNS_LOGCATEGORY_SECURITY,
+				      NS_LOGMODULE_CLIENT, ISC_LOG_ERROR,
+				      "update forwarding denied");
 			goto failure;
 		}
 		CHECK(ns_client_checkacl(client, "update forwarding",
diff --git a/bin/tests/tasks/t_tasks.c b/bin/tests/tasks/t_tasks.c
index 44c90047..61c735ae 100644
--- a/bin/tests/tasks/t_tasks.c
+++ b/bin/tests/tasks/t_tasks.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: t_tasks.c,v 1.29.2.1 2004/03/09 06:10:30 marka Exp $ */
+/* $Id: t_tasks.c,v 1.29.2.2 2004/06/21 07:08:35 marka Exp $ */
 
 #include <config.h>
 
@@ -41,7 +41,7 @@ isc_boolean_t threaded = ISC_FALSE;
 static void
 require_threads(void) {
 	t_info("This test requires threads\n");
-	t_result(T_UNTESTED);
+	t_result(T_THREADONLY);
 	return;
 }
 
diff --git a/bin/tests/timers/t_timers.c b/bin/tests/timers/t_timers.c
index 9c43716c..4ab7f976 100644
--- a/bin/tests/timers/t_timers.c
+++ b/bin/tests/timers/t_timers.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: t_timers.c,v 1.22.2.1 2004/03/09 06:10:31 marka Exp $ */
+/* $Id: t_timers.c,v 1.22.2.2 2004/06/21 07:08:36 marka Exp $ */
 
 #include <config.h>
 
@@ -55,7 +55,7 @@ static	int		Tx_nanoseconds;
 static void
 require_threads(void) {
 	t_info("This test requires threads\n");
-	t_result(T_UNTESTED);
+	t_result(T_THREADONLY);
 	return;
 }
 
diff --git a/configure b/configure
index 5182df30..383449ba 100755
--- a/configure
+++ b/configure
@@ -1,5 +1,5 @@
 #! /bin/sh
-# From configure.in Revision: 1.294.2.31 .
+# From configure.in Revision: 1.294.2.32 .
 # Guess values for system-dependent variables and create Makefiles.
 # Generated by GNU Autoconf 2.59.
 #
@@ -24625,12 +24625,15 @@ fi
 
 
 
-#
 # Determine the printf format characters to use when printing
-# values of type isc_int64_t.  We make the assumption that platforms
-# where a "long long" is the same size as a "long" (e.g., Alpha/OSF1)
-# want "%ld" and everyone else can use "%lld".  Win32 uses "%I64d",
-# but that's defined elsewhere since we don't use configure on Win32.
+# values of type isc_int64_t. This will normally be "ll", but where
+# the compiler treats "long long" as a alias for "long" and printf
+# doesn't know about "long long" use "l".  Hopefully the sprintf
+# will produce a inconsistant result in the later case.  If the compiler
+# fails due to seeing "%lld" we fall back to "l".
+#
+# Win32 uses "%I64d", but that's defined elsewhere since we don't use
+# configure on Win32.
 #
 echo "$as_me:$LINENO: checking printf format modifier for 64-bit integers" >&5
 echo $ECHO_N "checking printf format modifier for 64-bit integers... $ECHO_C" >&6
@@ -24645,7 +24648,17 @@ _ACEOF
 cat confdefs.h >>conftest.$ac_ext
 cat >>conftest.$ac_ext <<_ACEOF
 /* end confdefs.h.  */
-main() { exit(!(sizeof(long long int) == sizeof(long int))); }
+
+#include <stdio.h>
+main() {
+	long long int j = 0;
+	char buf[100];
+	buf[0] = 0;
+	sprintf(buf, "%lld", j);
+	exit((sizeof(long long int) != sizeof(long int))? 0 :
+	     (strcmp(buf, "0") != 0));
+}
+
 _ACEOF
 rm -f conftest$ac_exeext
 if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
@@ -24658,18 +24671,18 @@ if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
   ac_status=$?
   echo "$as_me:$LINENO: \$? = $ac_status" >&5
   (exit $ac_status); }; }; then
-  echo "$as_me:$LINENO: result: l" >&5
-echo "${ECHO_T}l" >&6
-	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'
+  echo "$as_me:$LINENO: result: ll" >&5
+echo "${ECHO_T}ll" >&6
+	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'
 else
   echo "$as_me: program exited with status $ac_status" >&5
 echo "$as_me: failed program was:" >&5
 sed 's/^/| /' conftest.$ac_ext >&5
 
 ( exit $ac_status )
-echo "$as_me:$LINENO: result: ll" >&5
-echo "${ECHO_T}ll" >&6
-	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'
+echo "$as_me:$LINENO: result: l" >&5
+echo "${ECHO_T}l" >&6
+	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'
 fi
 rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftest.$ac_ext
 fi
diff --git a/configure.in b/configure.in
index 87dbc128..6bf24fd0 100644
--- a/configure.in
+++ b/configure.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-AC_REVISION($Revision: 1.294.2.31 $)
+AC_REVISION($Revision: 1.294.2.32 $)
 
 AC_INIT(lib/dns/name.c)
 AC_PREREQ(2.13)
@@ -1508,19 +1508,32 @@ AC_CHECK_FUNC(strerror, AC_DEFINE(HAVE_STRERROR))
 AC_SUBST(ISC_EXTRA_OBJS)
 AC_SUBST(ISC_EXTRA_SRCS)
 
-#
 # Determine the printf format characters to use when printing
-# values of type isc_int64_t.  We make the assumption that platforms
-# where a "long long" is the same size as a "long" (e.g., Alpha/OSF1)
-# want "%ld" and everyone else can use "%lld".  Win32 uses "%I64d",
-# but that's defined elsewhere since we don't use configure on Win32.
+# values of type isc_int64_t. This will normally be "ll", but where
+# the compiler treats "long long" as a alias for "long" and printf
+# doesn't know about "long long" use "l".  Hopefully the sprintf
+# will produce a inconsistant result in the later case.  If the compiler
+# fails due to seeing "%lld" we fall back to "l".
+#
+# Win32 uses "%I64d", but that's defined elsewhere since we don't use
+# configure on Win32.
 #
 AC_MSG_CHECKING(printf format modifier for 64-bit integers)
-AC_TRY_RUN([main() { exit(!(sizeof(long long int) == sizeof(long int))); }],
-	[AC_MSG_RESULT(l)
-	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'],
+AC_TRY_RUN([
+#include <stdio.h>
+main() {
+	long long int j = 0;
+	char buf[100];
+	buf[0] = 0;
+	sprintf(buf, "%lld", j);
+	exit((sizeof(long long int) != sizeof(long int))? 0 :
+	     (strcmp(buf, "0") != 0));
+} 
+],
 	[AC_MSG_RESULT(ll)
 	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'],
+	[AC_MSG_RESULT(l)
+	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'],
 	[AC_MSG_RESULT(assuming target platform uses ll)
 	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'])
 AC_SUBST(ISC_PLATFORM_QUADFORMAT)
diff --git a/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.2.4-patch b/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.2.4-patch
index fe7860ec..8a40759e 100644
--- a/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.2.4-patch
+++ b/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.2.4-patch
@@ -17,8 +17,8 @@ and install.
 
 
 Index: README.idnkit
---- /dev/null	Thu Apr 29 11:15:03 2004
-+++ README.idnkit	Thu Apr 29 11:05:40 2004
+--- /dev/null	Thu Jul  1 13:17:02 2004
++++ README.idnkit	Thu Jul  1 13:19:01 2004
 @@ -0,0 +1,113 @@
 +
 +			BIND-9 IDN patch
@@ -136,10 +136,10 @@ Index: README.idnkit
 Index: configure
 ===================================================================
 RCS file: /proj/cvs/prod/bind9/configure,v
-retrieving revision 1.284.2.28
-diff -U2 -r1.284.2.28 configure
---- configure	10 Mar 2004 03:25:48 -0000	1.284.2.28
-+++ configure	29 Apr 2004 01:16:48 -0000
+retrieving revision 1.284.2.29
+diff -U2 -r1.284.2.29 configure
+--- configure	1 Jul 2004 00:18:29 -0000	1.284.2.29
++++ configure	1 Jul 2004 03:21:53 -0000
 @@ -466,5 +466,5 @@
  #endif"
  
@@ -332,7 +332,7 @@ diff -U2 -r1.284.2.28 configure
 +#line 21486 "configure"
  #include "confdefs.h"
  
-@@ -25777,4 +25781,354 @@
+@@ -25790,4 +25794,354 @@
  
  #
 +# IDN support
@@ -687,7 +687,7 @@ diff -U2 -r1.284.2.28 configure
 +#
  # Substitutions
  #
-@@ -26639,4 +26993,5 @@
+@@ -26652,4 +27006,5 @@
  s,@XMLDCL@,$XMLDCL,;t t
  s,@DOCBOOK2MANSPEC@,$DOCBOOK2MANSPEC,;t t
 +s,@IDNLIBS@,$IDNLIBS,;t t
@@ -696,11 +696,11 @@ diff -U2 -r1.284.2.28 configure
 Index: configure.in
 ===================================================================
 RCS file: /proj/cvs/prod/bind9/configure.in,v
-retrieving revision 1.294.2.31
-diff -U2 -r1.294.2.31 configure.in
---- configure.in	10 Mar 2004 03:24:06 -0000	1.294.2.31
-+++ configure.in	29 Apr 2004 01:16:52 -0000
-@@ -1756,4 +1756,80 @@
+retrieving revision 1.294.2.32
+diff -U2 -r1.294.2.32 configure.in
+--- configure.in	1 Jul 2004 00:16:42 -0000	1.294.2.32
++++ configure.in	1 Jul 2004 03:21:58 -0000
+@@ -1769,4 +1769,80 @@
  
  #
 +# IDN support
@@ -787,7 +787,7 @@ RCS file: /proj/cvs/prod/bind9/config.h.in,v
 retrieving revision 1.47.2.8
 diff -U2 -r1.47.2.8 config.h.in
 --- config.h.in	15 Mar 2004 05:00:23 -0000	1.47.2.8
-+++ config.h.in	29 Apr 2004 01:16:52 -0000
++++ config.h.in	1 Jul 2004 03:21:59 -0000
 @@ -17,5 +17,5 @@
   */
  
@@ -809,21 +809,21 @@ diff -U2 -r1.47.2.8 config.h.in
 +
  /* Define to 1 if you have the <stdint.h> header file. */
  #undef HAVE_STDINT_H
-@@ -222,4 +228,7 @@
+@@ -221,4 +227,7 @@
+ /* Define to 1 if you can safely include both <sys/time.h> and <time.h>. */
  #undef TIME_WITH_SYS_TIME
- 
++
 +/* define if idnkit support is to be included. */
 +#undef WITH_IDN
-+
+ 
  /* Define to 1 if your processor stores words with the most significant byte
-    first (like Motorola and SPARC, unlike Intel and VAX). */
 Index: bin/dig/Makefile.in
 ===================================================================
 RCS file: /proj/cvs/prod/bind9/bin/dig/Makefile.in,v
 retrieving revision 1.25.2.2
 diff -U2 -r1.25.2.2 Makefile.in
 --- bin/dig/Makefile.in	9 Mar 2004 06:09:10 -0000	1.25.2.2
-+++ bin/dig/Makefile.in	29 Apr 2004 01:16:52 -0000
++++ bin/dig/Makefile.in	1 Jul 2004 03:21:59 -0000
 @@ -37,5 +37,5 @@
  DEPLIBS =	${DNSDEPLIBS} ${ISCDEPLIBS}
  
@@ -837,7 +837,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/dig.1,v
 retrieving revision 1.14.2.5
 diff -U2 -r1.14.2.5 dig.1
 --- bin/dig/dig.1	15 Mar 2004 04:44:38 -0000	1.14.2.5
-+++ bin/dig/dig.1	29 Apr 2004 01:16:53 -0000
++++ bin/dig/dig.1	1 Jul 2004 03:22:01 -0000
 @@ -355,4 +355,15 @@
  will not print the initial query when it looks up the NS records for
  isc.org.
@@ -860,7 +860,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/dig.docbook,v
 retrieving revision 1.4.2.8
 diff -U2 -r1.4.2.8 dig.docbook
 --- bin/dig/dig.docbook	9 Mar 2004 06:09:12 -0000	1.4.2.8
-+++ bin/dig/dig.docbook	29 Apr 2004 01:16:55 -0000
++++ bin/dig/dig.docbook	1 Jul 2004 03:22:03 -0000
 @@ -530,4 +530,19 @@
  
  <refsect1>
@@ -887,7 +887,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/dighost.c,v
 retrieving revision 1.221.2.22
 diff -U2 -r1.221.2.22 dighost.c
 --- bin/dig/dighost.c	15 Apr 2004 06:53:18 -0000	1.221.2.22
-+++ bin/dig/dighost.c	29 Apr 2004 01:17:00 -0000
++++ bin/dig/dighost.c	1 Jul 2004 03:22:16 -0000
 @@ -33,4 +33,15 @@
  #include <limits.h>
  
@@ -1126,7 +1126,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/host.1,v
 retrieving revision 1.11.2.2
 diff -U2 -r1.11.2.2 host.1
 --- bin/dig/host.1	15 Mar 2004 04:44:38 -0000	1.11.2.2
-+++ bin/dig/host.1	29 Apr 2004 01:17:01 -0000
++++ bin/dig/host.1	1 Jul 2004 03:22:16 -0000
 @@ -122,4 +122,15 @@
  will be set to the number of seconds given by the hardware's maximum
  value for an integer quantity.
@@ -1149,7 +1149,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/host.docbook,v
 retrieving revision 1.2.2.3
 diff -U2 -r1.2.2.3 host.docbook
 --- bin/dig/host.docbook	9 Mar 2004 06:09:13 -0000	1.2.2.3
-+++ bin/dig/host.docbook	29 Apr 2004 01:17:01 -0000
++++ bin/dig/host.docbook	1 Jul 2004 03:22:21 -0000
 @@ -182,4 +182,19 @@
  
  <refsect1>
@@ -1176,7 +1176,7 @@ RCS file: /proj/cvs/prod/bind9/lib/dns/name.c,v
 retrieving revision 1.127.2.9
 diff -U2 -r1.127.2.9 name.c
 --- lib/dns/name.c	9 Mar 2004 06:11:03 -0000	1.127.2.9
-+++ lib/dns/name.c	29 Apr 2004 01:17:07 -0000
++++ lib/dns/name.c	1 Jul 2004 03:22:35 -0000
 @@ -196,4 +196,11 @@
  dns_name_t *dns_wildcardname = &wild;
  
@@ -1221,7 +1221,7 @@ RCS file: /proj/cvs/prod/bind9/lib/dns/include/dns/name.h,v
 retrieving revision 1.95.2.5
 diff -U2 -r1.95.2.5 name.h
 --- lib/dns/include/dns/name.h	9 Mar 2004 06:11:19 -0000	1.95.2.5
-+++ lib/dns/include/dns/name.h	29 Apr 2004 01:17:09 -0000
++++ lib/dns/include/dns/name.h	1 Jul 2004 03:22:37 -0000
 @@ -220,4 +220,15 @@
  #define DNS_NAME_MAXWIRE 255
  
@@ -1238,9 +1238,10 @@ diff -U2 -r1.95.2.5 name.h
 +
  /***
   *** Initialization
-@@ -1262,4 +1273,12 @@
+@@ -1261,4 +1272,12 @@
+  *
   */
- 
++
 +#ifdef WITH_IDN
 +void
 +dns_name_settotextfilter(dns_name_totextfilter_t proc);
@@ -1248,6 +1249,5 @@ diff -U2 -r1.95.2.5 name.h
 + * Call 'proc' at the end of dns_name_totext.
 + */
 +#endif /* WITH_IDN */
-+
+ 
  #define DNS_NAME_FORMATSIZE (DNS_NAME_MAXTEXT + 1)
- /*
diff --git a/contrib/queryperf/queryperf.c b/contrib/queryperf/queryperf.c
index d7b11140..98cdd1b1 100644
--- a/contrib/queryperf/queryperf.c
+++ b/contrib/queryperf/queryperf.c
@@ -18,7 +18,7 @@
 /***
  ***	DNS Query Performance Testing Tool  (queryperf.c)
  ***
- ***	Version $Id: queryperf.c,v 1.1.1.2.2.5 2003/05/12 07:07:13 marka Exp $
+ ***	Version $Id: queryperf.c,v 1.1.1.2.2.6 2004/06/21 00:45:24 marka Exp $
  ***
  ***	Stephen Jacob <sj@nominum.com>
  ***/
@@ -75,13 +75,13 @@ enum directives_enum	{ V_SERVER, V_PORT, V_MAXQUERIES, V_MAXWAIT };
 #define QTYPE_STRINGS { \
 	"A", "NS", "MD", "MF", "CNAME", "SOA", "MB", "MG", \
 	"MR", "NULL", "WKS", "PTR", "HINFO", "MINFO", "MX", "TXT", \
-	"AAAA", "SRV", "A6", "AXFR", "MAILB", "MAILA", "*", "ANY" \
+	"AAAA", "SRV", "NAPTR", "A6", "AXFR", "MAILB", "MAILA", "*", "ANY" \
 }
 
 #define QTYPE_CODES { \
 	1, 2, 3, 4, 5, 6, 7, 8, \
 	9, 10, 11, 12, 13, 14, 15, 16, \
-	28, 33, 38, 252, 253, 254, 255, 255 \
+	28, 33, 35, 38, 252, 253, 254, 255, 255 \
 }
 
 #define RCODE_STRINGS { \
@@ -180,7 +180,7 @@ void
 show_startup_info(void) {
 	printf("\n"
 "DNS Query Performance Testing Tool\n"
-"Version: $Id: queryperf.c,v 1.1.1.2.2.5 2003/05/12 07:07:13 marka Exp $\n"
+"Version: $Id: queryperf.c,v 1.1.1.2.2.6 2004/06/21 00:45:24 marka Exp $\n"
 "\n");
 }
 
diff --git a/doc/draft/draft-ietf-dnsext-mdns-30.txt b/doc/draft/draft-ietf-dnsext-mdns-30.txt
deleted file mode 100644
index 15375739..00000000
--- a/doc/draft/draft-ietf-dnsext-mdns-30.txt
+++ /dev/null
@@ -1,1868 +0,0 @@
-DNSEXT Working Group                                        Levon Esibov

-INTERNET-DRAFT                                             Bernard Aboba

-Category: Standards Track                                    Dave Thaler

-<draft-ietf-dnsext-mdns-30.txt>                                Microsoft

-17 March 2004

-

-

-

-              Linklocal Multicast Name Resolution (LLMNR)

-

-

-This document is an Internet-Draft and is in full conformance with all

-provisions of Section 10 of RFC 2026.

-

-

-Internet-Drafts are working documents of the Internet Engineering Task

-Force (IETF), its areas, and its working groups.  Note that other groups

-may also distribute working documents as Internet-Drafts.

-

-

-Internet-Drafts are draft documents valid for a maximum of six months

-and may be updated, replaced, or obsoleted by other documents at any

-time.  It is inappropriate to use Internet-Drafts as reference material

-or to cite them other than as "work in progress."

-

-

-The list of current Internet-Drafts can be accessed at

-http://www.ietf.org/ietf/1id-abstracts.txt

-

-

-The list of Internet-Draft Shadow Directories can be accessed at

-http://www.ietf.org/shadow.html.

-

-

-Copyright Notice

-

-

-Copyright (C) The Internet Society (2004).  All Rights Reserved.

-

-

-Abstract

-

-

-Today, with the rise of home networking, there are an increasing number

-of ad-hoc networks operating without a Domain Name System (DNS) server.

-In order to allow name resolution in such environments, Link-Local

-Multicast Name Resolution (LLMNR) is proposed.  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.

-

-

-The goal of LLMNR is to enable name resolution in scenarios in which

-conventional DNS name resolution is not possible.  Since LLMNR only

-operates on the local link, it cannot be considered a substitute for

-DNS.

-

-

-

-

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                    [Page 1]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-Table of Contents

-

-

-1.     Introduction ..........................................    3

-   1.1       Requirements ....................................    3

-   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 .................................   10

-   2.5       Off-link detection ..............................   11

-   2.6       Responder responsibilities ......................   12

-   2.7       Retransmission and jitter .......................   12

-   2.8       DNS TTL .........................................   13

-   2.9       Use of the authority and additional sections ....   13

-3.     Usage model ...........................................   14

-   3.1       LLMNR configuration .............................   15

-4.     Conflict resolution ...................................   16

-   4.1       Considerations for multiple interfaces ..........   18

-   4.2       API issues ......................................   19

-5.     Security considerations ...............................   19

-   5.1       Scope restriction ...............................   20

-   5.2       Usage restriction ...............................   21

-   5.3       Cache and port separation .......................   21

-   5.4       Authentication ..................................   22

-6.     IANA considerations ...................................   22

-7.     References ............................................   22

-   7.1       Normative References ............................   22

-   7.2       Informative References ..........................   23

-Acknowledgments ..............................................   24

-Authors' Addresses ...........................................   25

-Intellectual Property Statement ..............................   25

-Full Copyright Statement .....................................   26

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                    [Page 2]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-1.  Introduction

-

-

-This document discusses Link Local Multicast Name Resolution (LLMNR),

-which utilizes the DNS packet format and supports all current and future

-DNS formats, types and classes.  LLMNR operates on a separate port from

-the Domain Name System (DNS), with a distinct resolver cache.

-

-

-The goal of LLMNR is to enable name resolution in scenarios in which

-conventional DNS name resolution is not possible.  These include

-scenarios in which hosts are not configured with the address of a DNS

-server, where configured DNS servers do not reply to a query, or where

-they respond with errors, as described in Section 2.  Since LLMNR only

-operates on the local link, it cannot be considered a substitute for

-DNS.

-

-

-Link-scope multicast addresses are used to prevent propagation of LLMNR

-traffic across routers, potentially flooding the network.  LLMNR queries

-can also be sent to a unicast address, as described in Section 2.4.

-

-

-Propagation of LLMNR packets on the local link is considered sufficient

-to enable name resolution in small networks.  The assumption is that if

-a network has a gateway, then the network is able to provide DNS server

-configuration.   Configuration issues are discussed in Section 3.1.

-

-

-In the future, it may be desirable to consider use of multicast name

-resolution with multicast scopes beyond the link-scope.  This could

-occur if LLMNR deployment is successful, the need for multicast name

-resolution beyond the link-scope, or multicast routing becomes

-ubiquitous.  For example, expanded support for multicast name resolution

-might be required for mobile ad-hoc networking scenarios, or where no

-DNS server is available that is authoritative for the names of local

-hosts, and can support dynamic DNS, such as in wireless hotspots.

-

-

-Once we have experience in LLMNR deployment in terms of administrative

-issues, usability and impact on the network, it will be possible to

-reevaluate which multicast scopes are appropriate for use with multicast

-name resolution.

-

-

-Service discovery in general, as well as discovery of DNS servers using

-LLMNR in particular, is outside of the scope of this document, as is

-name resolution over non-multicast capable media.

-

-

-1.1.  Requirements

-

-

-In this document, several words are used to signify the requirements of

-the specification.  These words are often capitalized.  The key words

-"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD

-NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                    [Page 3]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-interpreted as described in [RFC2119].

-

-

-1.2.  Terminology

-

-

-This document assumes familiarity with DNS terminology defined in

-[RFC1035].  Other terminology used in this document includes:

-

-

-Positively Resolved

-     Responses with RCODE set to zero are referred to in this document

-     as "positively resolved".

-

-

-Routable Address

-     An address other than a Link-Local address.  This includes globally

-     routable addresses, as well as private addresses.

-

-

-Reachable

-     An address is considered reachable over a link if either an ARP or

-     neighbor discovery cache entry exists for the address on the link.

-

-

-Responder

-     A host that listens to LLMNR queries, and responds to those for

-     which it is authoritative.

-

-

-Sender

-     A host that sends an LLMNR query.

-

-

-2.  Name resolution using LLMNR

-

-

-LLMNR is a peer-to-peer name resolution protocol that is not intended as

-a replacement for DNS.  LLMNR queries are sent to and received on port

-TBD.  IPv4 administratively scoped multicast usage is specified in

-"Administratively Scoped IP Multicast" [RFC2365].  The IPv4 link-scope

-multicast address a given responder listens to, and to which a sender

-sends queries, is TBD.  The IPv6 link-scope multicast address a given

-responder listens to, and to which a sender sends all queries, is TBD.

-

-

-Typically a host is configured as both an LLMNR sender and a responder.

-A host MAY be configured as a sender, but not a responder.  However, a

-host configured as a responder MUST act as a sender to verify the

-uniqueness of names as described in Section 4.  This document does not

-specify how names are chosen or configured.  This may occur via any

-mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315].

-

-

-LLMNR usage MAY be configured manually or automatically on a per

-interface basis.  By default, LLMNR responders SHOULD be enabled on all

-interfaces, at all times.  Enabling LLMNR for use in situations where a

-DNS server has been configured will result in a change in default

-behavior without a simultaneous update to configuration information.

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                    [Page 4]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-Where this is considered undesirable, LLMNR SHOULD NOT be enabled by

-default, so that hosts will neither listen on the link-scope multicast

-address, nor will they send queries to that address.

-

-

-An LLMNR sender may send a request for any name.  However, by default,

-LLMNR requests SHOULD be sent only when one of the following conditions

-are met:

-

-

-[1]  No manual or automatic DNS configuration has been performed.  If an

-     interface has been configured with DNS server address(es), then

-     LLMNR SHOULD NOT be used as the primary name resolution mechanism

-     on that interface, although it MAY be used as a name resolution

-     mechanism of last resort.

-

-

-[2]  DNS servers do not respond.

-

-

-[3]  DNS servers respond to a DNS query with RCODE=3 (Authoritative Name

-     Error) or RCODE=0, and an empty answer section.

-

-

-A typical sequence of events for LLMNR usage is as follows:

-

-

-[a]  DNS servers are not configured or do not respond to a DNS query, or

-     respond with RCODE=3, or RCODE=0 and an empty answer section.

-

-

-[b]  An LLMNR sender sends an LLMNR query to the link-scope multicast

-     address(es) defined in Section 2, unless a unicast query is

-     indicated.  A sender SHOULD send LLMNR queries for PTR RRs via

-     unicast, as specified in Section 2.4.

-

-

-[c]  A responder responds to this query only if it is authoritative for

-     the domain name in the query.  A responder responds to a multicast

-     query by sending a unicast UDP response to the sender.  Unicast

-     queries are responded to as indicated in Section 2.4.

-

-

-[d]  Upon reception of the response, the sender processes it.

-

-

-Further details of sender and responder behavior are provided in the

-sections that follow.

-

-

-2.1.  LLMNR packet format

-

-

-LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for

-both queries and responses.  LLMNR implementations SHOULD send UDP

-queries and responses only as large as are known to be permissible

-without causing fragmentation.  When in doubt a maximum packet size of

-512 octets SHOULD be used.  LLMNR implementations MUST accept UDP

-queries and responses as large as permitted by the link MTU.

-

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                    [Page 5]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-2.1.1.  LLMNR header format

-

-

-LLMNR queries and responses utilize the DNS header format defined in

-[RFC1035] with exceptions noted below:

-

-

-                                1  1  1  1  1  1

-  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5

-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

-|                      ID                       |

-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

-|QR|   Opcode  | Z|TC| Z| Z| Z| Z| Z|   RCODE   |

-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

-|                    QDCOUNT                    |

-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

-|                    ANCOUNT                    |

-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

-|                    NSCOUNT                    |

-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

-|                    ARCOUNT                    |

-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

-

-

-where:

-

-

-ID   A 16 bit identifier assigned by the program that generates any kind

-     of query.  This identifier is copied from the query to the response

-     and can be used by the sender to match responses to outstanding

-     queries. The ID field in a query SHOULD be set to a pseudo-random

-     value.

-

-

-QR   A one bit field that specifies whether this message is an LLMNR

-     query (0), or an LLMNR response (1).

-

-

-OPCODE

-     A four bit field that specifies the kind of query in this message.

-     This value is set by the originator of a query and copied into the

-     response.  This specification defines the behavior of standard

-     queries and responses (opcode value of zero).  Future

-     specifications may define the use of other opcodes with LLMNR.

-     LLMNR senders and responders MUST support standard queries (opcode

-     value of zero).  LLMNR queries with unsupported OPCODE values MUST

-     be silently discarded by responders.

-

-

-TC   TrunCation - specifies that this message was truncated due to

-     length greater than that permitted on the transmission channel.

-     The TC bit MUST NOT be set in an LLMNR query and if set is ignored

-     by an LLMNR responder.  If the TC bit is set an LLMNR response,

-     then the sender MAY use the response if it contains all necessary

-     information, or the sender MAY discard the response and resend the

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                    [Page 6]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-     LLMNR query over TCP using the unicast address of the responder as

-     the destination address.  See  [RFC2181] and Section 2.4 of this

-     specification for further discussion of the TC bit.

-

-

-Z    Reserved for future use.  Implementations of this specification

-     MUST set these bits to zero in both queries and responses.  If

-     these bits are set in a LLMNR query or response, implementations of

-     this specification MUST ignore them.  Since reserved bits could

-     conceivably be used for different purposes than in DNS,

-     implementors are advised not to enable processing of these bits in

-     an LLMNR implementation starting from a DNS code base.

-

-

-RCODE

-     Response code -- this 4 bit field is set as part of LLMNR

-     responses.  In an LLMNR query, the RCODE MUST be zero, and is

-     ignored by the responder.  The response to a multicast LLMNR query

-     MUST have RCODE set to zero.  A sender MUST silently discard an

-     LLMNR response with a non-zero RCODE sent in response to a

-     multicast query.

-

-

-     If an LLMNR responder is authoritative for the name in a multicast

-     query, but an error is encountered, the responder SHOULD send an

-     LLMNR response with an RCODE of zero, no RRs in the answer section,

-     and the TC bit set.  This will cause the query to be resent using

-     TCP, and allow the inclusion of a non-zero RCODE in the response to

-     the TCP query.  Responding with the TC bit set is preferrable to

-     not sending a response, since it enables errors to be diagnosed.

-

-

-     Since LLMNR responders only respond to LLMNR queries for names for

-     which they are authoritative, LLMNR responders MUST NOT respond

-     with an RCODE of 3; instead, they should not respond at all.

-

-

-     LLMNR implementations MUST support EDNS0 [RFC2671] and extended

-     RCODE values.

-

-

-QDCOUNT

-     An unsigned 16 bit integer specifying the number of entries in the

-     question section. A sender MUST place only one question into the

-     question section of an LLMNR query.  LLMNR responders MUST silently

-     discard LLMNR queries with QDCOUNT not equal to one.  LLMNR senders

-     MUST silently discard LLMNR responses with QDCOUNT not equal to

-     one.

-

-

-ANCOUNT

-     An unsigned 16 bit integer specifying the number of resource

-     records in the answer section.  LLMNR responders MUST silently

-     discard LLMNR queries with ANCOUNT not equal to zero.

-

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                    [Page 7]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-NSCOUNT

-     An unsigned 16 bit integer specifying the number of name server

-     resource records in the authority records section.  Authority

-     record section processing is described in Section 2.9.

-

-

-ARCOUNT

-     An unsigned 16 bit integer specifying the number of resource

-     records in the additional records section.  Additional record

-     section processing is described in Section 2.9.

-

-

-2.2.  Sender behavior

-

-

-A sender may send an LLMNR query for any legal resource record  type

-(e.g.  A, AAAA, SRV, etc.) to the link-scope multicast address.

-

-

-As described in Section 2.4, a sender may also send a unicast query.

-Sections 2 and 3 describe the circumstances in which LLMNR queries may

-be sent.

-

-

-The sender MUST anticipate receiving no replies to some LLMNR queries,

-in the event that no responders are available within the link-scope or

-in the event no positive non-null responses exist for the transmitted

-query.  If no positive response is received, a resolver treats it as a

-response that no records of the specified type and class exist for the

-specified name (it is treated the same as a response with RCODE=0 and an

-empty answer section).

-

-

-Since the responder may order the RRs in the response so as to indicate

-preference, the sender SHOULD preserve ordering in the response to the

-querying application.

-

-

-2.3.  Responder behavior

-

-

-An LLMNR response MUST be sent to the sender via unicast.

-

-

-Upon configuring an IP address responders typically will synthesize

-corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR

-queries for these RRs.  An SOA RR is synthesized only when a responder

-has another RR as well;  the SOA RR MUST NOT be the only RR that a

-responder has.  However, in general whether RRs are manually or

-automatically created is an implementation decision.

-

-

-For example, a host configured to have computer name "host1" and to be a

-member of the "example.com" domain, and with IPv4 address 10.1.1.1 and

-IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the

-following records:

-

-

-host1. IN A 10.1.1.1

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                    [Page 8]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6

-

-

-host1.example.com. IN A 10.1.1.1

-IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6

-

-

-1.1.1.10.in-addr.arpa. IN PTR host1.

-IN PTR host1.example.com.

-

-

-6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

-IN PTR host1.

-IN PTR host1.example.com

-

-

-An LLMNR responder might be further manually configured with the name of

-a local mail server with an MX RR included in the "host1." and

-"host1.example.com." records.

-

-

-In responding to queries:

-

-

-[a]  Responders MUST listen on UDP port TBD on the link-scope multicast

-     address(es) defined in Section 2, and on UDP and TCP port TBD on

-     the unicast address(es) that could be set as the source address(es)

-     when the responder responds to the LLMNR query.

-

-

-[b]  Responders MUST direct responses to the port from which the query

-     was sent.  When queries are received via TCP this is an inherent

-     part of the transport protocol.  For queries received by UDP the

-     responder MUST take note of the source port and use that as the

-     destination port in the response.  Responses SHOULD always be sent

-     from the port to which they were directed.

-

-

-[c]  Responders MUST respond to LLMNR queries for names and addresses

-     they are authoritative for.  This applies to both forward and

-     reverse lookups.

-

-

-[d]  Responders MUST NOT respond to LLMNR queries for names they are not

-     authoritative for.

-

-

-[e]  Responders MUST NOT respond using cached data.

-

-

-[f]  If a DNS server is running on a host that supports LLMNR, the DNS

-     server MUST respond to LLMNR queries only for the RRSets relating

-     to the host on which the server is running, but MUST NOT respond

-     for other records for which the server is authoritative.  DNS

-     servers also MUST NOT send LLMNR queries in order to resolve DNS

-     queries.

-

-

-[g]  If a responder is authoritative for a name, it MAY respond with

-     RCODE=0 and an empty answer section, if the type of query does not

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                    [Page 9]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-     match a RR that the responder has.

-

-

-As an example, a host configured to respond to LLMNR queries for the

-name "foo.example.com."  is authoritative for the name

-"foo.example.com.".  On receiving an LLMNR query for an A RR with the

-name "foo.example.com." the host authoritatively responds with A RR(s)

-that contain IP address(es) in the RDATA of the resource record.  If the

-responder has a AAAA RR, but no A RR, and an A RR query is received, the

-responder would respond with RCODE=0 and an empty answer section.

-

-

-In conventional DNS terminology a DNS server authoritative for a zone is

-authoritative for all the domain names under the zone apex except for

-the branches delegated into separate zones.  Contrary to conventional

-DNS terminology, an LLMNR responder is authoritative only for the zone

-apex.

-

-

-For example the host "foo.example.com." is not authoritative for the

-name "child.foo.example.com." unless the host is configured with

-multiple names, including "foo.example.com."  and

-"child.foo.example.com.".  As a result, "foo.example.com." cannot reply

-to an LLMNR query for "child.foo.example.com." with RCODE=3

-(authoritative name error).  The purpose of limiting the name authority

-scope of a responder is to prevent complications that could be caused by

-coexistence of two or more hosts with the names representing child and

-parent (or grandparent) nodes in the DNS tree, for example,

-"foo.example.com." and "child.foo.example.com.".

-

-

-In this example (unless this limitation is introduced) an LLMNR query

-for an A resource record for the name "child.foo.example.com." would

-result in two authoritative responses: RCODE=3 (authoritative name

-error) received from "foo.example.com.", and a requested A record - from

-"child.foo.example.com.".  To prevent this ambiguity, LLMNR enabled

-hosts could perform a dynamic update of the parent (or grandparent) zone

-with a delegation to a child zone.  In this example a host

-"child.foo.example.com." would send a dynamic update for the NS and glue

-A record to "foo.example.com.", but this approach 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.

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 10]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-A responder receiving a unicast query MUST send the response with a

-source address set to the destination address field of the IP header of

-the query causing the response.

-

-

-Unicast LLMNR queries MUST be sent using TCP.  Senders MUST support

-sending TCP queries, and responders MUST support listening for TCP

-queries.

-

-

-Responses to TCP unicast LLMNR queries MUST be sent using TCP,  using

-the same connection as the query.  If the sender of a TCP query receives

-a response to that query not using TCP, the response MUST be silently

-discarded.

-

-

-Unicast UDP queries MUST be silently discarded.

-

-

-If TCP connection setup cannot be completed in order to send a unicast

-TCP query, this is treated as a response that no records of the

-specified type and class exist for the specified name (it is treated the

-same as a response with RCODE=0 and an empty answer section).

-

-

-2.5.  "Off link" detection

-

-

-For IPv4, an "on link" address is defined as a link-local address

-[IPv4Link] or an address whose prefix belongs to a subnet on the local

-link.  For IPv6 [RFC2460] an "on link" address is either a link-local

-address, defined in [RFC2373], or an address whose prefix belongs to a

-subnet on the local link.

-

-

-A sender MUST select a source address for LLMNR queries that is "on

-link".  The destination address of an LLMNR query MUST be a link-scope

-multicast address or an "on link" unicast address.

-

-

-A responder MUST select a source address for responses that is "on

-link". The destination address of an LLMNR response MUST be an "on link"

-unicast address.

-

-

-On receiving an LLMNR query, the responder MUST check whether it was

-sent to a LLMNR multicast addresses defined in Section 2.  If it was

-sent to another multicast address, then the query MUST be silently

-discarded.

-

-

-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

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 11]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-SYN-ACK from the responder.

-

-

-For UDP queries and responses the Hop Limit field in the IPv6 header,

-and the TTL field in the IPV4 header MAY be set to any value.  However,

-it is RECOMMENDED that the value 255 be used for compatibility with

-Apple Rendezvous.

-

-

-Implementation note:

-

-

-   In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL

-   socket options are used to set the TTL of outgoing unicast and

-   multicast packets. The IP_RECVTTL socket option is available on some

-   platforms to retrieve the IPv4 TTL of received packets with

-   recvmsg().  [RFC2292] specifies similar options for setting and

-   retrieving the IPv6 Hop Limit.

-

-

-2.6.  Responder responsibilities

-

-

-It is the responsibility of the responder to ensure that RRs returned in

-LLMNR responses MUST only include values that are valid on the local

-interface, such as IPv4 or IPv6 addresses valid on the local link or

-names defended using the mechanism described in Section 4.  In

-particular:

-

-

-[a]  If a link-scope IPv6 address is returned in a AAAA RR, that address

-     MUST be valid on the local link over which LLMNR is used.

-

-

-[b]  If an IPv4 address is returned, it MUST be reachable through the

-     link over which LLMNR is used.

-

-

-[c]  If a name is returned (for example in a CNAME, MX or SRV RR), the

-     name MUST be resolvable on the local link over which LLMNR is used.

-

-

-Routable addresses MUST be included first in the response, if available.

-This encourages use of routable address(es) for establishment of new

-connections.

-

-

-2.7.  Retransmission and jitter

-

-

-An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine

-when to retransmit an LLMNR query and how long to collect responses to

-an LLMNR query.

-

-

-If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,

-then a sender MAY repeat the transmission of the query in order to

-assure that it was received by a host capable of responding to it.

-Retransmission of UDP queries SHOULD NOT be attempted more than 3 times.

-Where LLMNR queries are sent using TCP, retransmission is handled by the

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 12]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-transport layer.

-

-

-Because an LLMNR sender cannot know in advance if a query sent using

-multicast will receive no response, one response, or more than one

-response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect

-all possible responses, rather than considering the multicast query

-answered after the first response is received. A unicast query sender

-considers the query answered after the first response is received, so

-that it only waits for LLMNR_TIMEOUT if no response has been received.

-

-

-An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT

-for each transmission. It is suggested that the computation of

-LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries

-sent on the same interface.

-

-

-For example, the algorithms described in RFC 2988 [RFC2988] (including

-exponential backoff) compute an RTO, which is used as the value of

-LLMNR_TIMEOUT.  Smaller values MAY be used for the initial RTO

-(discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO

-(discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum

-RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).

-

-

-Recommended values are an initial RTO of 1 second, a minimum RTO of

-200ms, and a maximum RTO of 5 seconds.  In order to avoid

-synchronization, the transmission of each LLMNR query and response

-SHOULD delayed by a time randomly selected from the interval 0 to 100

-ms.  This delay MAY be avoided by responders responding with RRs which

-they have previously determined to be UNIQUE (see Section 4 for

-details).

-

-

-2.8.  DNS TTL

-

-

-The responder should use a pre-configured TTL value in the records

-returned an LLMNR response.  A default value of 30 seconds is

-RECOMMENDED.  In highly dynamic environments (such as mobile ad-hoc

-networks), the TTL value may need to be reduced.

-

-

-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

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 13]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-responses.

-

-

-Responders SHOULD insert an SOA record into the authority section of a

-negative response, to facilitate negative caching as specified in

-[RFC2308].  The owner name of this SOA record MUST be equal to the query

-name.

-

-

-Responders SHOULD NOT perform DNS additional section processing, except

-as required for EDNS0 and DNSSEC.

-

-

-Senders MUST NOT cache RRs from the authority or additional section of a

-response as answers, though they may be used for other purposes such as

-negative caching.

-

-

-3.  Usage model

-

-

-Since LLMNR is a secondary name resolution mechanism, its usage is in

-part determined by the behavior of DNS implementations.  This document

-does not specify any changes to DNS resolver behavior, such as

-searchlist processing or retransmission/failover policy.  However,

-robust DNS resolver implementations are more likely to avoid unnecessary

-LLMNR queries.

-

-

-As noted in [DNSPerf], even when DNS servers are configured, a

-significant fraction of DNS queries do not receive a response, or result

-in negative responses due to missing inverse mappings or NS records that

-point to nonexistent or inappropriate hosts.  This has the potential to

-result in a large number of unnecessary LLMNR queries.

-

-

-[RFC1536] describes common DNS implementation errors and fixes.  If the

-proposed fixes are implemented, unnecessary LLMNR queries will be

-reduced substantially, and so implementation of [RFC1536] is

-recommended.

-

-

-For example, [RFC1536] Section 1 describes issues with retransmission

-and recommends implementation of a retransmission policy based on round

-trip estimates, with exponential backoff.  [RFC1536] Section 4 describes

-issues with failover, and recommends that resolvers try another server

-when they don't receive a response to a query.  These policies are

-likely to avoid unnecessary LLMNR queries.

-

-

-[RFC1536] Section 3 describes zero answer bugs, which if addressed will

-also reduce unnecessary LLMNR queries.

-

-

-[RFC1536] Section 6 describes name error bugs and recommended searchlist

-processing that will reduce unnecessary RCODE=3 (authoritative name)

-errors, thereby also reducing unnecessary LLMNR queries.

-

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 14]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-3.1.  LLMNR configuration

-

-

-Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is

-possible for a dual stack host to be configured with the address of a

-DNS server over IPv4, while remaining unconfigured with a DNS server

-suitable for use over IPv6.

-

-

-In these situations, a dual stack host will send AAAA queries to the

-configured DNS server over IPv4.  However, an IPv6-only host

-unconfigured with a DNS server suitable for use over IPv6 will be unable

-to resolve names using DNS.  Automatic IPv6 DNS configuration mechanisms

-(such as [RFC3315] and [DNSDisc]) are not yet widely deployed, and not

-all DNS servers support IPv6. Therefore lack of IPv6 DNS configuration

-may be a common problem in the short term, and LLMNR may prove useful in

-enabling linklocal name resolution over IPv6.

-

-

-Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],

-IPv6-only hosts may not be configured with a DNS server.  Where there is

-no DNS server authoritative for the name of a host or the authoritative

-DNS server does not support dynamic client update over IPv6 or

-DHCPv6-based dynamic update, then an IPv6-only host will not be able to

-do DNS dynamic update, and other hosts will not be able to resolve its

-name.

-

-

-For example, if the configured DNS server responds to AAAA RR queries

-sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then

-it will not be possible to resolve the names of IPv6-only hosts.  In

-this situation, LLMNR over IPv6 can be used for local name resolution.

-

-

-Similarly, if a DHCPv4 server is available providing DNS server

-configuration, and DNS server(s) exist which are authoritative for the A

-RRs of local hosts and support either dynamic client update over IPv4 or

-DHCPv4-based dynamic update, then the names of local 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

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 15]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-service.  In these circumstances, it is possible for hosts within an

-administrative domain to be inconsistent in their DNS configuration.

-

-

-For example, where DHCP is used for configuring DNS servers, one or more

-DHCP servers can fail.  As a result, hosts configured prior to the

-outage will be configured with a DNS server, while hosts configured

-after the outage will not.  Alternatively, it is possible for the DNS

-configuration mechanism to continue functioning while configured DNS

-servers fail.

-

-

-Unless unconfigured hosts periodically retry configuration, an outage in

-the DNS configuration mechanism will result in hosts continuing to use

-LLMNR even once the outage is repaired.  Since LLMNR only enables

-linklocal name resolution, this represents an unnecessary degradation in

-capabilities.  As a result, it is recommended that hosts without a

-configured DNS server periodically attempt to obtain DNS configuration.

-For example, where DHCP is used for DNS configuration, [RFC2131]

-recommends a maximum retry interval of 64 seconds.  In the absence of

-other guidance, a default retry interval of one (1) minute is

-RECOMMENDED.

-

-

-4.  Conflict resolution

-

-

-The sender MUST anticipate receiving multiple replies to the same LLMNR

-query, in the event that several LLMNR enabled computers receive the

-query and respond with valid answers.  When this occurs, the responses

-may first be concatenated, and then treated in the same manner that

-multiple RRs received from the same DNS server would; the sender

-perceives no inherent conflict in the receipt of multiple responses.

-

-

-There are some scenarios when multiple responders MAY respond to the

-same query.  There are other scenarios when only one responder MAY

-respond to a query.  Resource records for which the latter queries are

-submitted are referred as UNIQUE throughout this document.  The

-uniqueness of a resource record depends on a nature of the name in the

-query and type of the query.  For example it is expected that:

-

-

-   - multiple hosts may respond to a query for an SRV type record

-   - multiple hosts may respond to a query for an A or AAAA type

-     record for a cluster name (assigned to multiple hosts in

-     the cluster)

-   - only a single host may respond to a query for an A or AAAA

-     type record for a name.

-

-

-Every responder that responds to an LLMNR query AND includes a UNIQUE

-record in the response:

-

-

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 16]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-[1]  MUST verify that there is no other host within the scope of the

-     LLMNR query propagation that can return a resource record for the

-     same name, type and class.

-

-

-[2]  MUST NOT include a UNIQUE resource record in the response without

-     having verified its uniqueness.

-

-

-Where a host is configured to issue LLMNR queries on more than one

-interface, each interface should have its own independent LLMNR cache.

-For each UNIQUE resource record in a given interface's configuration,

-the host MUST verify resource record uniqueness on that interface.  To

-accomplish this, the host MUST send an LLMNR query for each UNIQUE

-resource record.

-

-

-By default, a host SHOULD be configured to behave as though all RRs are

-UNIQUE.  Uniqueness verification is carried out when the host:

-

-

-  - starts up or is rebooted

-  - wakes from sleep (if the network interface was inactive during sleep)

-  - is configured to respond to the LLMNR queries on an interface

-    enabled for transmission and reception of IP traffic

-  - is configured to respond to the LLMNR queries using additional

-    UNIQUE resource records

-  - detects that an interface is connected and is usable

-    (e.g. an IEEE 802 hardware link-state change indicating

-    that a cable was attached or completion of authentication

-    (and if needed, association) with a wireless base station

-    or adhoc network

-

-

-When a host that has a UNIQUE record receives an LLMNR query for that

-record, the host MUST respond.  After the client receives a response, it

-MUST check whether the response arrived on an interface different from

-the one on which the query was sent.  If the response arrives on a

-different interface, the client can use the UNIQUE resource record in

-response to LLMNR queries.  If not, then it MUST NOT use the UNIQUE

-resource record in response to LLMNR queries.

-

-

-The name conflict detection mechanism doesn't prevent name conflicts

-when previously partitioned segments are connected by a bridge. In order

-to minimize the chance of conflicts in such a situation, it is

-recommended that steps be taken to ensure name uniqueness. For example,

-the name could be chosen randomly from a large pool of potential names,

-or the name could be assigned via a process designed to guarantee

-uniqueness.

-

-

-When name conflicts are detected, they SHOULD be logged.  To detect

-duplicate use of a name, an administrator can use a name resolution

-utility which employs LLMNR and lists both responses and responders.

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 17]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-This would allow an administrator to diagnose behavior and potentially

-to intervene and reconfigure LLMNR responders who should not be

-configured to respond to the same name.

-

-

-4.1.  Considerations for Multiple Interfaces

-

-

-A multi-homed host may elect to configure LLMNR on only one of its

-active interfaces.  In many situations this will be adequate.  However,

-should a host need to configure LLMNR on more than one of its active

-interfaces, there are some additional precautions it MUST take.

-Implementers who are not planning to support LLMNR on multiple

-interfaces simultaneously may skip this section.

-

-

-A multi-homed host checks the uniqueness of UNIQUE records as described

-in Section 4.  The situation is illustrated in figure 1.

-

-

-     ----------  ----------

-      |      |    |      |

-     [A]    [myhost]   [myhost]

-

-

-   Figure 1.  Link-scope name conflict

-

-

-In this situation, the multi-homed myhost will probe for, and defend,

-its host name on both interfaces.  A conflict will be detected on one

-interface, but not the other.  The multi-homed myhost will not be able

-to respond with a host RR for "myhost" on the interface on the right

-(see Figure 1).  The multi-homed host may, however, be configured to use

-the "myhost" name on the interface on the left.

-

-

-Since names are only unique per-link, hosts on different links could be

-using the same name.  If an LLMNR client sends requests over 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,

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 18]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-and that shown in Figure 3 where no conflict exists.

-

-

-             [A]

-            |   |

-        -----   -----

-            |   |

-           [myhost]

-

-

-   Figure 3.  Multiple paths to same host

-

-

-This illustrates that the proposed name conflict resolution mechanism

-does not support detection or resolution of conflicts between hosts on

-different links.  This problem can also occur with unicast DNS when a

-multi-homed host is connected to two different networks with separated

-name spaces.  It is not the intent of this document to address the issue

-of uniqueness of names within DNS.

-

-

-4.2.  API issues

-

-

-[RFC2553] provides an API which can partially solve the name ambiguity

-problem for applications written to use this API, since the sockaddr_in6

-structure exposes the scope within which each scoped address exists, and

-this structure can be used for both IPv4 (using v4-mapped IPv6

-addresses) and IPv6 addresses.

-

-

-Following the example in Figure 2, an application on 'myhost' issues the

-request getaddrinfo("A", ...) with ai_family=AF_INET6 and

-ai_flags=AI_ALL|AI_V4MAPPED.  LLMNR requests will be sent from both

-interfaces and the resolver library will return a list containing

-multiple addrinfo structures, each with an associated sockaddr_in6

-structure.  This list will thus contain the IPv4 and IPv6 addresses of

-both hosts responding to the name 'A'.  Link-local addresses will have a

-sin6_scope_id value that disambiguates which interface is used to reach

-the address.  Of course, to the application, Figures 2 and 3 are still

-indistinguishable, but this API allows the application to communicate

-successfully with any address in the list.

-

-

-5.  Security Considerations

-

-

-LLMNR is by nature a peer-to-peer name resolution protocol. It is

-therefore inherently more vulnerable than DNS, since existing DNS

-security mechanisms are difficult to apply to LLMNR. While tools exist

-to alllow an attacker to spoof a response to a DNS query, spoofing a

-response to an LLMNR query is easier since the query is sent to a link-

-scope multicast address, where every host on the logical link will be

-made aware of it.

-

-

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 19]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-In order to address the security vulnerabilities, the following

-mechanisms are contemplated:

-

-

-[1]  Scope restrictions.

-

-

-[2]  Usage restrictions.

-

-

-[3]  Cache and port separation.

-

-

-[4]  Authentication.

-

-

-These techniques are described in the following sections.

-

-

-5.1.  Scope restriction

-

-

-With LLMNR it is possible that hosts will allocate conflicting names for

-a period of time, or that attackers will attempt to deny service to

-other hosts by allocating the same name. Such attacks also allow hosts

-to receive packets destined for other hosts.

-

-

-Since LLMNR is typically deployed in situations where no trust model can

-be assumed, it is likely that LLMNR queries and responses will be

-unauthenticated.  In the absence of authentication, LLMNR reduces the

-exposure to such threats by utilizing UDP queries sent to a link-scope

-multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6)

-fields to one (1) on TCP queries and responses.

-

-

-Using a TTL of one (1) to set up a TCP connection in order to send a

-unicast LLMNR query reduces the likelihood of both denial of service

-attacks and spoofed responses.  Checking that an LLMNR query is sent to

-a link-scope multicast address should prevent spoofing of multicast

-queries by off-link attackers.

-

-

-While this limits the ability of off-link attackers to spoof LLMNR

-queries and responses, it does not eliminate it. For example, it is

-possible for an attacker to spoof a response to a frequent query (such

-as an A or AAAA query for a popular Internet host), and by using a TTL

-or Hop Limit field larger than one (1), for the forged response to reach

-the LLMNR sender.

-

-

-When LLMNR queries are sent to a link-scope multicast address, it is

-possible that some routers may not properly implement link-scope

-multicast, or that link-scope multicast addresses may leak into the

-multicast routing system.

-

-

-Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one

-in an LLMNR UDP response may enable denial of service attacks across the

-Internet.  However, since LLMNR responders only respond to queries for

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 20]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-which they are authoritative, and LLMNR does not provide wildcard query

-support, it is believed that this threat is minimal.

-

-

-There also are scenarios such as public "hotspots" where attackers can

-be present on the same link.  These threats are most serious in wireless

-networks such as 802.11, since attackers on a wired network will require

-physical access to the home network, while wireless attackers may reside

-outside the home.  Link-layer security can be of assistance against

-these threats if it is available.

-

-

-5.2.  Usage restriction

-

-

-As noted in Sections 2 and 3, LLMNR is intended for usage in a limited

-set of scenarios.

-

-

-If an LLMNR query is sent whenever a DNS server does not respond in a

-timely way, then an attacker can poison the LLMNR cache by responding to

-the query with incorrect information.  To some extent, these

-vulnerabilities exist today, since DNS response spoofing tools are

-available that can allow an attacker to respond to a query more quickly

-than a distant DNS server.

-

-

-Since LLMNR queries are sent and responded to on the local-link, an

-attacker will need to respond more quickly to provide its own response

-prior to arrival of the response from a legitimate responder. If an

-LLMNR query is sent for an off-link host, spoofing a response in a

-timely way is not difficult, since a legitimate response will never be

-received.

-

-

-The vulnerability is more serious if LLMNR is given higher priority than

-DNS among the enabled name resolution mechanisms. In such a

-configuration, a denial of service attack on the DNS server would not be

-necessary in order to poison the LLMNR cache, since LLMNR queries would

-be sent even when the DNS server is available. In addition, the LLMNR

-cache, once poisoned, would take precedence over the DNS cache,

-eliminating the benefits of cache separation. As a result, LLMNR is only

-used as a name resolution mechanism of last resort.

-

-

-5.3.  Cache and port separation

-

-

-In order to prevent responses to LLMNR queries from polluting the DNS

-cache, LLMNR implementations MUST use a distinct, isolated cache for

-LLMNR on each interface. The use of separate caches is most effective

-when LLMNR is used as a name resolution mechanism of last resort, since

-this minimizes the opportunities for poisoning the LLMNR cache, and

-decreases reliance on it.

-

-

-LLMNR operates on a separate port from DNS, reducing the likelihood that

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 21]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-a DNS server will unintentionally respond to an LLMNR query.

-

-

-5.4.  Authentication

-

-

-LLMNR implementations may not support DNSSEC or TSIG, and as a result,

-responses to LLMNR queries may be unauthenticated.  If authentication is

-desired, and a pre-arranged security configuration is possible, then

-IPsec ESP with a null-transform MAY be used to authenticate LLMNR

-responses.  In a small network without a certificate authority, this can

-be most easily accomplished through configuration of a group pre-shared

-key for trusted hosts.

-

-

-6.  IANA Considerations

-

-

-This specification creates one new name space:  the reserved bits in the

-LLMNR header.  These are allocated by IETF Consensus, in accordance with

-BCP 26 [RFC2434].

-

-

-LLMNR requires allocation of a port TBD for both TCP and UDP.

-Assignment of the same port for both transports is requested.

-

-

-LLMNR requires allocation of a link-scope multicast IPv4 address TBD.

-LLMNR also requires allocation of a link-scope multicast IPv6 address

-TBD.

-

-

-7.  References

-

-

-7.1.  Normative References

-

-

-[RFC1035] Mockapetris, P., "Domain Names - Implementation and

-          Specification", RFC 1035, November 1987.

-

-

-[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,

-          April 1992.

-

-

-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

-          Requirement Levels", BCP 14, RFC 2119, March 1997.

-

-

-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS

-          Specification", RFC 2181, July 1997.

-

-

-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",

-          RFC 2308, March 1998.

-

-

-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC

-          2365, July 1998.

-

-

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 22]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing

-          Architecture", RFC 2373, July 1998.

-

-

-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA

-          Considerations Section in RFCs", BCP 26, RFC 2434, October

-          1998.

-

-

-[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6

-          (IPv6) Specification", RFC 2460, December 1998.

-

-

-[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC

-          2535, March 1999.

-

-

-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,

-          August 1999.

-

-

-[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission

-          Timer", RFC 2988, November 2000.

-

-

-7.2.  Informative References

-

-

-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested

-          Fixes", RFC 1536, October 1993.

-

-

-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,

-          March 1997.

-

-

-[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic

-          Updates in the Domain Name System (DNS UPDATE)", RFC 2136,

-          April 1997.

-

-

-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",

-          RFC 2292, February 1998.

-

-

-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic

-          Socket Interface Extensions for IPv6", RFC 2553, March 1999.

-

-

-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC

-          2937, September 2000.

-

-

-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for

-          IPv6 (DHCPv6)", RFC 3315, July 2003.

-

-

-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of

-          Caching", IEEE/ACM Transactions on Networking, Volume 10,

-          Number 5, pp. 589, October 2002.

-

-

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 23]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local

-          unicast addresses to communicate with recursive DNS servers",

-          Internet draft (work in progress), draft-ietf-ipv6-dns-

-          discovery-07.txt, October 2002.

-

-

-[IPV4Link]

-          Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration

-          of IPv4 Link-Local Addresses", Internet draft (work in

-          progress), draft-ietf-zeroconf-ipv4-linklocal-14.txt, April

-          2004.

-

-

-[POSIX]   IEEE Std. 1003.1-2001 Standard for Information Technology --

-          Portable Operating System Interface (POSIX). Open Group

-          Technical Standard: Base Specifications, Issue 6, December

-          2001.  ISO/IEC 9945:2002.  http://www.opengroup.org/austin

-

-

-[LLMNREnable]

-          Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work

-          in progress), draft-guttman-mdns-enable-02.txt, April 2002.

-

-

-[NodeInfo]

-          Crawford, M., "IPv6 Node Information Queries", Internet draft

-          (work in progress), draft-ietf-ipn-gwg-icmp-name-

-          lookups-09.txt, May 2002.

-

-

-Acknowledgments

-

-

-This work builds upon original work done on multicast DNS by Bill

-Manning and Bill Woodcock. Bill Manning's work was funded under DARPA

-grant #F30602-99-1-0523. The authors gratefully acknowledge their

-contribution to the current specification.  Constructive input has also

-been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert

-Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron

-Hattig, Thomas Narten, Christian Huitema, Erik Nordmark, Sander Van-

-Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku

-Savela.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 24]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-Authors' Addresses

-

-

-Levon Esibov

-Microsoft Corporation

-One Microsoft Way

-Redmond, WA 98052

-

-

-EMail: levone@microsoft.com

-

-

-Bernard Aboba

-Microsoft Corporation

-One Microsoft Way

-Redmond, WA 98052

-

-

-Phone: +1 425 706 6605

-EMail: bernarda@microsoft.com

-

-

-Dave Thaler

-Microsoft Corporation

-One Microsoft Way

-Redmond, WA 98052

-

-

-Phone: +1 425 703 8835

-EMail: dthaler@microsoft.com

-

-

-Intellectual Property Statement

-

-

-The IETF takes no position regarding the validity or scope of any

-intellectual property or other rights that might be claimed to  pertain

-to the implementation or use of the technology described in this

-document or the extent to which any license under such rights might or

-might not be available; neither does it represent that it has made any

-effort to identify any such rights.  Information on the IETF's

-procedures with respect to rights in standards-track and standards-

-related documentation can be found in BCP-11.  Copies of claims of

-rights made available for publication and any assurances of licenses to

-be made available, or the result of an attempt made to obtain a general

-license or permission for the use of such proprietary rights by

-implementors or users of this specification can be obtained from the

-IETF Secretariat.

-

-

-The IETF invites any interested party to bring to its attention any

-copyrights, patents or patent applications, or other proprietary rights

-which may cover technology that may be required to practice this

-standard.  Please address the information to the IETF Executive

-Director.

-

-

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 25]

-

-

-

-

-

-

-INTERNET-DRAFT                    LLMNR                    17 March 2004

-

-

-

-Full Copyright Statement

-

-

-Copyright (C) The Internet Society (2004).  All Rights Reserved.

-This document and translations of it may be copied and furnished to

-others, and derivative works that comment on or otherwise explain it or

-assist in its implementation may be prepared, copied, published and

-distributed, in whole or in part, without restriction of any kind,

-provided that the above copyright notice and this paragraph are included

-on all such copies and derivative works.  However, this document itself

-may not be modified in any way, such as by removing the copyright notice

-or references to the Internet Society or other Internet organizations,

-except as needed for the purpose of developing Internet standards in

-which case the procedures for copyrights defined in the Internet

-Standards process must be followed, or as required to translate it into

-languages other than English.  The limited permissions granted above are

-perpetual and will not be revoked by the Internet Society or its

-successors or assigns.  This document and the information contained

-herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE

-INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR

-IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE

-INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

-WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Open Issues

-

-

-Open issues with this specification are tracked on the following web

-site:

-

-

-http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

-

-

-Expiration Date

-

-

-This memo is filed as <draft-ietf-dnsext-mdns-30.txt>,  and  expires

-October 4, 2004.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Esibov, Aboba & Thaler       Standards Track                   [Page 26]
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsext-mdns-32.txt b/doc/draft/draft-ietf-dnsext-mdns-32.txt
new file mode 100644
index 00000000..50c54bcb
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-mdns-32.txt
@@ -0,0 +1,1559 @@
+
+
+
+
+
+
+DNSEXT Working Group                                        Levon Esibov
+INTERNET-DRAFT                                             Bernard Aboba
+Category: Standards Track                                    Dave Thaler
+<draft-ietf-dnsext-mdns-32.txt>                                Microsoft
+25 June 2004
+
+
+              Linklocal Multicast Name Resolution (LLMNR)
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3667.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups. Note that other
+   groups may also distribute working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time. It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on November 22, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   Today, with the rise of home networking, there are an increasing
+   number of ad-hoc networks operating without a Domain Name System
+   (DNS) server.  The goal of Link-Local Multicast Name Resolution
+   (LLMNR) is to enable name resolution in scenarios in which
+   conventional DNS name resolution is not possible.  LLMNR supports all
+   current and future DNS formats, types and classes, while operating on
+   a separate port from DNS, and with a distinct resolver cache.  Since
+   LLMNR only operates on the local link, it cannot be considered a
+   substitute for DNS.
+
+
+
+
+
+Esibov, Aboba & Thaler       Standards Track                    [Page 1]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+Table of Contents
+
+1.     Introduction ..........................................    3
+   1.1       Requirements ....................................    4
+   1.2       Terminology .....................................    4
+2.     Name resolution using LLMNR ...........................    4
+   2.1       LLMNR packet format .............................    6
+   2.2       Sender behavior .................................    8
+   2.3       Responder behavior ..............................    8
+   2.4       Unicast queries .................................   11
+   2.5       Off-link detection ..............................   11
+   2.6       Responder responsibilities ......................   12
+   2.7       Retransmission and jitter .......................   13
+   2.8       DNS TTL .........................................   13
+   2.9       Use of the authority and additional sections ....   14
+3.     Usage model ...........................................   14
+   3.1       LLMNR configuration .............................   15
+4.     Conflict resolution ...................................   16
+   4.1       Considerations for multiple interfaces ..........   18
+   4.2       API issues ......................................   19
+5.     Security considerations ...............................   20
+   5.1       Scope restriction ...............................   20
+   5.2       Usage restriction ...............................   21
+   5.3       Cache and port separation .......................   22
+   5.4       Authentication ..................................   22
+6.     IANA considerations ...................................   22
+7.     References ............................................   22
+   7.1       Normative References ............................   22
+   7.2       Informative References ..........................   23
+Acknowledgments ..............................................   24
+Authors' Addresses ...........................................   25
+Intellectual Property Statement ..............................   25
+Full Copyright Statement .....................................   26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler       Standards Track                    [Page 2]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+1.  Introduction
+
+   This document discusses Link Local Multicast Name Resolution (LLMNR),
+   which utilizes the DNS packet format and supports all current and
+   future DNS formats, types and classes.  LLMNR operates on a separate
+   port from the Domain Name System (DNS), with a distinct resolver
+   cache.
+
+   The goal of LLMNR is to enable name resolution in scenarios in which
+   conventional DNS name resolution is not possible.  These include
+   scenarios in which hosts are not configured with the address of a DNS
+   server, where configured DNS servers do not reply to a query, or
+   where they respond with errors, as described in Section 2.  Since
+   LLMNR only operates on the local link, it cannot be considered a
+   substitute for DNS.
+
+   Link-scope multicast addresses are used to prevent propagation of
+   LLMNR traffic across routers, potentially flooding the network.
+   LLMNR queries can also be sent to a unicast address, as described in
+   Section 2.4.
+
+   Propagation of LLMNR packets on the local link is considered
+   sufficient to enable name resolution in small networks.  The
+   assumption is that if a network has a gateway, then the network is
+   able to provide DNS server configuration.   Configuration issues are
+   discussed in Section 3.1.
+
+   In the future, it may be desirable to consider use of multicast name
+   resolution with multicast scopes beyond the link-scope.  This could
+   occur if LLMNR deployment is successful, the need arises for
+   multicast name resolution beyond the link-scope, or multicast routing
+   becomes ubiquitous.  For example, expanded support for multicast name
+   resolution might be required for mobile ad-hoc networking scenarios,
+   or where no DNS server is available that is authoritative for the
+   names of local hosts, and can support dynamic DNS, such as in
+   wireless hotspots.
+
+   Once we have experience in LLMNR deployment in terms of
+   administrative issues, usability and impact on the network, it will
+   be possible to reevaluate which multicast scopes are appropriate for
+   use with multicast name resolution.
+
+   Service discovery in general, as well as discovery of DNS servers
+   using LLMNR in particular, is outside of the scope of this document,
+   as is name resolution over non-multicast capable media.
+
+
+
+
+
+
+Esibov, Aboba & Thaler       Standards Track                    [Page 3]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+1.1.  Requirements
+
+   In this document, several words are used to signify the requirements
+   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
+   and "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+1.2.  Terminology
+
+   This document assumes familiarity with DNS terminology defined in
+   [RFC1035].  Other terminology used in this document includes:
+
+Positively Resolved
+     Responses with RCODE set to zero are referred to in this document
+     as "positively resolved".
+
+Routable Address
+     An address other than a Link-Local address.  This includes globally
+     routable addresses, as well as private addresses.
+
+Reachable
+     An address is considered reachable over a link if either an ARP or
+     neighbor discovery cache entry exists for the address on the link.
+
+Responder
+     A host that listens to LLMNR queries, and responds to those for
+     which it is authoritative.
+
+Sender
+     A host that sends an LLMNR query.
+
+2.  Name resolution using LLMNR
+
+   LLMNR is a peer-to-peer name resolution protocol that is not intended
+   as a replacement for DNS.  LLMNR queries are sent to and received on
+   port 5355.  IPv4 administratively scoped multicast usage is specified
+   in "Administratively Scoped IP Multicast" [RFC2365].  The IPv4 link-
+   scope multicast address a given responder listens to, and to which a
+   sender sends queries, is 224.0.0.252.  The IPv6 link-scope multicast
+   address a given responder listens to, and to which a sender sends all
+   queries, is FF02:0:0:0:0:0:1:3.
+
+   Typically a host is configured as both an LLMNR sender and a
+   responder.  A host MAY be configured as a sender, but not a
+   responder.  However, a host configured as a responder MUST act as a
+   sender to verify the uniqueness of names as described in Section 4.
+   This document does not specify how names are chosen or configured.
+
+
+
+Esibov, Aboba & Thaler       Standards Track                    [Page 4]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+   This may occur via any mechanism, including DHCPv4 [RFC2131] or
+   DHCPv6 [RFC3315].
+
+   LLMNR usage MAY be configured manually or automatically on a per
+   interface basis.  By default, LLMNR responders SHOULD be enabled on
+   all interfaces, at all times.  Enabling LLMNR for use in situations
+   where a DNS server has been configured will result in a change in
+   default behavior without a simultaneous update to configuration
+   information. Where this is considered undesirable, LLMNR SHOULD NOT
+   be enabled by default, so that hosts will neither listen on the link-
+   scope multicast address, nor will they send queries to that address.
+
+   An LLMNR sender may send a request for any name.  However, by
+   default, LLMNR requests SHOULD be sent only when one of the following
+   conditions are met:
+
+   [1] No manual or automatic DNS configuration has been
+       performed.  If an interface has been configured with DNS
+       server address(es),  then LLMNR SHOULD NOT be used as the
+       primary name resolution mechanism on that interface, although
+       it MAY be used as a name resolution mechanism of last resort.
+
+   [2] DNS servers do not respond.
+
+   [3] DNS servers respond to a DNS query with RCODE=3
+       (Authoritative Name Error) or RCODE=0, and an empty
+       answer section.
+
+   A typical sequence of events for LLMNR usage is as follows:
+
+   [a]  DNS servers are not configured or do not respond to a
+        DNS query, or respond with RCODE=3, or RCODE=0 and an
+        empty answer section.
+
+   [b]  An LLMNR sender sends an LLMNR query to the link-scope
+        multicast address(es) defined in Section 2, unless a
+        unicast query is indicated.  A sender SHOULD send LLMNR
+        queries for PTR RRs via unicast, as specified in Section 2.4.
+
+   [c]  A responder responds to this query only if it is authoritative
+        for the domain name in the query.  A responder responds to a
+        multicast query by sending a unicast UDP response to the sender.
+        Unicast queries are responded to as indicated in Section 2.4.
+
+   [d]  Upon reception of the response, the sender processes it.
+
+   Further details of sender and responder behavior are provided in the
+   sections that follow.
+
+
+
+Esibov, Aboba & Thaler       Standards Track                    [Page 5]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+2.1.  LLMNR packet format
+
+   LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4
+   for both queries and responses.  LLMNR implementations SHOULD send
+   UDP queries and responses only as large as are known to be
+   permissible without causing fragmentation.  When in doubt a maximum
+   packet size of 512 octets SHOULD be used.  LLMNR implementations MUST
+   accept UDP queries and responses as large as permitted by the link
+   MTU.
+
+2.1.1.  LLMNR header format
+
+   LLMNR queries and responses utilize the DNS header format defined in
+   [RFC1035] with exceptions noted below:
+
+                                   1  1  1  1  1  1
+     0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                      ID                       |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |QR|   Opcode  | Z|TC| Z| Z| Z| Z| Z|   RCODE   |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                    QDCOUNT                    |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                    ANCOUNT                    |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                    NSCOUNT                    |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                    ARCOUNT                    |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   where:
+
+ID   A 16 bit identifier assigned by the program that generates any kind
+     of query.  This identifier is copied from the query to the response
+     and can be used by the sender to match responses to outstanding
+     queries. The ID field in a query SHOULD be set to a pseudo-random
+     value.
+
+QR   A one bit field that specifies whether this message is an LLMNR
+     query (0), or an LLMNR response (1).
+
+OPCODE
+     A four bit field that specifies the kind of query in this message.
+     This value is set by the originator of a query and copied into the
+     response.  This specification defines the behavior of standard
+     queries and responses (opcode value of zero).  Future
+     specifications may define the use of other opcodes with LLMNR.
+
+
+
+Esibov, Aboba & Thaler       Standards Track                    [Page 6]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+     LLMNR senders and responders MUST support standard queries (opcode
+     value of zero).  LLMNR queries with unsupported OPCODE values MUST
+     be silently discarded by responders.
+
+TC   TrunCation - specifies that this message was truncated due to
+     length greater than that permitted on the transmission channel.
+     The TC bit MUST NOT be set in an LLMNR query and if set is ignored
+     by an LLMNR responder.  If the TC bit is set an LLMNR response,
+     then the sender MAY use the response if it contains all necessary
+     information, or the sender MAY discard the response and resend the
+     LLMNR query over TCP using the unicast address of the responder as
+     the destination address.  See  [RFC2181] and Section 2.4 of this
+     specification for further discussion of the TC bit.
+
+Z    Reserved for future use.  Implementations of this specification
+     MUST set these bits to zero in both queries and responses.  If
+     these bits are set in a LLMNR query or response, implementations of
+     this specification MUST ignore them.  Since reserved bits could
+     conceivably be used for different purposes than in DNS,
+     implementors are advised not to enable processing of these bits in
+     an LLMNR implementation starting from a DNS code base.
+
+RCODE
+     Response code -- this 4 bit field is set as part of LLMNR
+     responses.  In an LLMNR query, the RCODE MUST be zero, and is
+     ignored by the responder.  The response to a multicast LLMNR query
+     MUST have RCODE set to zero.  A sender MUST silently discard an
+     LLMNR response with a non-zero RCODE sent in response to a
+     multicast query.
+
+     If an LLMNR responder is authoritative for the name in a multicast
+     query, but an error is encountered, the responder SHOULD send an
+     LLMNR response with an RCODE of zero, no RRs in the answer section,
+     and the TC bit set.  This will cause the query to be resent using
+     TCP, and allow the inclusion of a non-zero RCODE in the response to
+     the TCP query.  Responding with the TC bit set is preferrable to
+     not sending a response, since it enables errors to be diagnosed.
+
+     Since LLMNR responders only respond to LLMNR queries for names for
+     which they are authoritative, LLMNR responders MUST NOT respond
+     with an RCODE of 3; instead, they should not respond at all.
+
+     LLMNR implementations MUST support EDNS0 [RFC2671] and extended
+     RCODE values.
+
+QDCOUNT
+     An unsigned 16 bit integer specifying the number of entries in the
+     question section. A sender MUST place only one question into the
+
+
+
+Esibov, Aboba & Thaler       Standards Track                    [Page 7]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+     question section of an LLMNR query.  LLMNR responders MUST silently
+     discard LLMNR queries with QDCOUNT not equal to one.  LLMNR senders
+     MUST silently discard LLMNR responses with QDCOUNT not equal to
+     one.
+
+ANCOUNT
+     An unsigned 16 bit integer specifying the number of resource
+     records in the answer section.  LLMNR responders MUST silently
+     discard LLMNR queries with ANCOUNT not equal to zero.
+
+NSCOUNT
+     An unsigned 16 bit integer specifying the number of name server
+     resource records in the authority records section.  Authority
+     record section processing is described in Section 2.9.
+
+ARCOUNT
+     An unsigned 16 bit integer specifying the number of resource
+     records in the additional records section.  Additional record
+     section processing is described in Section 2.9.
+
+2.2.  Sender behavior
+
+   A sender may send an LLMNR query for any legal resource record  type
+   (e.g.  A, AAAA, SRV, etc.) to the link-scope multicast address.
+
+   As described in Section 2.4, a sender may also send a unicast query.
+   Sections 2 and 3 describe the circumstances in which LLMNR queries
+   may be sent.
+
+   The sender MUST anticipate receiving no replies to some LLMNR
+   queries, in the event that no responders are available within the
+   link-scope or in the event no positive non-null responses exist for
+   the transmitted query.  If no positive response is received, a
+   resolver treats it as a response that no records of the specified
+   type and class exist for the specified name (it is treated the same
+   as a response with RCODE=0 and an empty answer section).
+
+   Since the responder may order the RRs in the response so as to
+   indicate preference, the sender SHOULD preserve ordering in the
+   response to the querying application.
+
+2.3.  Responder behavior
+
+   An LLMNR response MUST be sent to the sender via unicast.
+
+   Upon configuring an IP address responders typically will synthesize
+   corresponding A, AAAA and PTR RRs so as to be able to respond to
+   LLMNR queries for these RRs.  An SOA RR is synthesized only when a
+
+
+
+Esibov, Aboba & Thaler       Standards Track                    [Page 8]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+   responder has another RR as well;  the SOA RR MUST NOT be the only RR
+   that a responder has.  However, in general whether RRs are manually
+   or automatically created is an implementation decision.
+
+   For example, a host configured to have computer name "host1" and to
+   be a member of the "example.com" domain, and with IPv4 address
+   10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
+   authoritative for the following records:
+
+   host1. IN A 10.1.1.1
+   IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
+
+   host1.example.com. IN A 10.1.1.1
+   IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
+
+   1.1.1.10.in-addr.arpa. IN PTR host1.
+   IN PTR host1.example.com.
+
+   6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
+   IN PTR host1.
+   IN PTR host1.example.com
+
+   An LLMNR responder might be further manually configured with the name
+   of a local mail server with an MX RR included in the "host1." and
+   "host1.example.com." records.
+
+   In responding to queries:
+
+[a]  Responders MUST listen on UDP port 5355 on the link-scope multicast
+     address(es) defined in Section 2, and on UDP and TCP port 5355 on
+     the unicast address(es) that could be set as the source address(es)
+     when the responder responds to the LLMNR query.
+
+[b]  Responders MUST direct responses to the port from which the query
+     was sent.  When queries are received via TCP this is an inherent
+     part of the transport protocol.  For queries received by UDP the
+     responder MUST take note of the source port and use that as the
+     destination port in the response.  Responses SHOULD always be sent
+     from the port to which they were directed.
+
+[c]  Responders MUST respond to LLMNR queries for names and addresses
+     they are authoritative for.  This applies to both forward and
+     reverse lookups.
+
+[d]  Responders MUST NOT respond to LLMNR queries for names they are not
+     authoritative for.
+
+
+
+
+
+Esibov, Aboba & Thaler       Standards Track                    [Page 9]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+[e]  Responders MUST NOT respond using cached data.
+
+[f]  If a DNS server is running on a host that supports LLMNR, the DNS
+     server MUST respond to LLMNR queries only for the RRSets relating
+     to the host on which the server is running, but MUST NOT respond
+     for other records for which the server is authoritative.  DNS
+     servers also MUST NOT send LLMNR queries in order to resolve DNS
+     queries.
+
+[g]  If a responder is authoritative for a name, it MAY respond with
+     RCODE=0 and an empty answer section, if the type of query does not
+     match a RR that the responder has.
+
+   As an example, a host configured to respond to LLMNR queries for the
+   name "foo.example.com."  is authoritative for the name
+   "foo.example.com.".  On receiving an LLMNR query for an A RR with the
+   name "foo.example.com." the host authoritatively responds with A
+   RR(s) that contain IP address(es) in the RDATA of the resource
+   record.  If the responder has a AAAA RR, but no A RR, and an A RR
+   query is received, the responder would respond with RCODE=0 and an
+   empty answer section.
+
+   In conventional DNS terminology a DNS server authoritative for a zone
+   is authoritative for all the domain names under the zone apex except
+   for the branches delegated into separate zones.  Contrary to
+   conventional DNS terminology, an LLMNR responder is authoritative
+   only for the zone apex.
+
+   For example the host "foo.example.com." is not authoritative for the
+   name "child.foo.example.com." unless the host is configured with
+   multiple names, including "foo.example.com."  and
+   "child.foo.example.com.".  As a result, "foo.example.com." cannot
+   reply to an LLMNR query for "child.foo.example.com." with RCODE=3
+   (authoritative name error).  The purpose of limiting the name
+   authority scope of a responder is to prevent complications that could
+   be caused by coexistence of two or more hosts with the names
+   representing child and parent (or grandparent) nodes in the DNS tree,
+   for example, "foo.example.com." and "child.foo.example.com.".
+
+   In this example (unless this limitation is introduced) an LLMNR query
+   for an A resource record for the name "child.foo.example.com." would
+   result in two authoritative responses: RCODE=3 (authoritative name
+   error) received from "foo.example.com.", and a requested A record -
+   from "child.foo.example.com.".  To prevent this ambiguity, LLMNR
+   enabled hosts could perform a dynamic update of the parent (or
+   grandparent) zone with a delegation to a child zone.  In this example
+   a host "child.foo.example.com." would send a dynamic update for the
+   NS and glue A record to "foo.example.com.", but this approach
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 10]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+   significantly complicates implementation of LLMNR and would not be
+   acceptable for lightweight hosts.
+
+2.4.  Unicast queries and responses
+
+   Unicast queries SHOULD be sent when:
+
+   [a] A sender repeats a query after it received a response
+       with the TC bit set to the previous LLMNR multicast query, or
+
+   [b] The sender queries for a PTR RR of a fully formed IP address
+       within the "in-addr.arpa" or "ip6.arpa" zones.
+
+   Unicast LLMNR queries MUST be done using TCP and the responses MUST
+   be sent using the same TCP connection as the query.  Senders MUST
+   support sending TCP queries, and responders MUST support listening
+   for TCP queries. If the sender of a TCP query receives a response to
+   that query not using TCP, the response MUST be silently discarded.
+
+   Unicast UDP queries MUST be silently discarded.
+
+   If TCP connection setup cannot be completed in order to send a
+   unicast TCP query, this is treated as a response that no records of
+   the specified type and class exist for the specified name (it is
+   treated the same as a response with RCODE=0 and an empty answer
+   section).
+
+2.5.  "Off link" detection
+
+   For IPv4, an "on link" address is defined as a link-local address
+   [IPv4Link] or an address whose prefix belongs to a subnet on the
+   local link.  For IPv6 [RFC2460] an "on link" address is either a
+   link-local address, defined in [RFC2373], or an address whose prefix
+   belongs to a subnet on the local link.
+
+   A sender MUST select a source address for LLMNR queries that is "on
+   link".  The destination address of an LLMNR query MUST be a link-
+   scope multicast address or an "on link" unicast address.
+
+   A responder MUST select a source address for responses that is "on
+   link". The destination address of an LLMNR response MUST be an "on
+   link" unicast address.
+
+   On receiving an LLMNR query, the responder MUST check whether it was
+   sent to a LLMNR multicast addresses defined in Section 2.  If it was
+   sent to another multicast address, then the query MUST be silently
+   discarded.
+
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 11]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+   Section 2.4 discusses use of TCP for LLMNR queries and responses.  In
+   composing an LLMNR query using TCP, the sender MUST set the Hop Limit
+   field in the IPv6 header and the TTL field in the IPv4 header of the
+   response to one (1).  The responder SHOULD set the TTL or Hop Limit
+   settings on the TCP listen socket to one (1) so that SYN-ACK packets
+   will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
+   prevents an incoming connection from off-link since the sender will
+   not receive a SYN-ACK from the responder.
+
+   For UDP queries and responses the Hop Limit field in the IPv6 header,
+   and the TTL field in the IPV4 header MAY be set to any value.
+   However, it is RECOMMENDED that the value 255 be used for
+   compatibility with Apple Rendezvous.
+
+   Implementation note:
+
+      In the sockets API for IPv4 [POSIX], the IP_TTL and
+      IP_MULTICAST_TTL socket options are used to set the TTL of
+      outgoing unicast and multicast packets. The IP_RECVTTL socket
+      option is available on some platforms to retrieve the IPv4 TTL of
+      received packets with recvmsg().  [RFC2292] specifies similar
+      options for setting and retrieving the IPv6 Hop Limit.
+
+2.6.  Responder responsibilities
+
+   It is the responsibility of the responder to ensure that RRs returned
+   in LLMNR responses MUST only include values that are valid on the
+   local interface, such as IPv4 or IPv6 addresses valid on the local
+   link or names defended using the mechanism described in Section 4.
+   In particular:
+
+   [a] If a link-scope IPv6 address is returned in a AAAA RR,
+       that address MUST be valid on the local link over which
+       LLMNR is used.
+
+   [b] If an IPv4 address is returned, it MUST be reachable
+       through the link over which LLMNR is used.
+
+   [c] If a name is returned (for example in a CNAME, MX
+       or SRV RR), the name MUST be resolvable on the local
+       link over which LLMNR is used.
+
+   Routable addresses MUST be included first in the response, if
+   available.  This encourages use of routable address(es) for
+   establishment of new connections.
+
+
+
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 12]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+2.7.  Retransmission and jitter
+
+   An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
+   when to retransmit an LLMNR query and how long to collect responses
+   to an LLMNR query.
+
+   If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
+   then a sender MAY repeat the transmission of the query in order to
+   assure that it was received by a host capable of responding to it.
+   Retransmission of UDP queries SHOULD NOT be attempted more than 3
+   times. Where LLMNR queries are sent using TCP, retransmission is
+   handled by the transport layer.
+
+   Because an LLMNR sender cannot know in advance if a query sent using
+   multicast will receive no response, one response, or more than one
+   response, the sender SHOULD wait for LLMNR_TIMEOUT in order to
+   collect all possible responses, rather than considering the multicast
+   query answered after the first response is received. A unicast query
+   sender considers the query answered after the first response is
+   received, so that it only waits for LLMNR_TIMEOUT if no response has
+   been received.
+
+   An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
+   for each transmission. It is suggested that the computation of
+   LLMNR_TIMEOUT be based on the response times for earlier LLMNR
+   queries sent on the same interface.
+
+   For example, the algorithms described in RFC 2988 [RFC2988]
+   (including exponential backoff) compute an RTO, which is used as the
+   value of LLMNR_TIMEOUT.  Smaller values MAY be used for the initial
+   RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum
+   RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the
+   maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).
+
+   Recommended values are an initial RTO of 1 second, a minimum RTO of
+   200ms, and a maximum RTO of 5 seconds.  In order to avoid
+   synchronization, the transmission of each LLMNR query and response
+   SHOULD delayed by a time randomly selected from the interval 0 to 100
+   ms.  This delay MAY be avoided by responders responding with RRs
+   which they have previously determined to be UNIQUE (see Section 4 for
+   details).
+
+2.8.  DNS TTL
+
+   The responder should use a pre-configured TTL value in the records
+   returned an LLMNR response.  A default value of 30 seconds is
+   RECOMMENDED.  In highly dynamic environments (such as mobile ad-hoc
+   networks), the TTL value may need to be reduced.
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 13]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+   Due to the TTL minimalization necessary when caching an RRset, all
+   TTLs in an RRset MUST be set to the same value.
+
+2.9.  Use of the authority and additional sections
+
+   Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
+   concept of delegation.  In LLMNR, the NS resource record type may be
+   stored and queried for like any other type, but it has no special
+   delegation semantics as it does in the DNS.  Responders MAY have NS
+   records associated with the names for which they are authoritative,
+   but they SHOULD NOT include these NS records in the authority
+   sections of responses.
+
+   Responders SHOULD insert an SOA record into the authority section of
+   a negative response, to facilitate negative caching as specified in
+   [RFC2308].  The owner name of this SOA record MUST be equal to the
+   query name.
+
+   Responders SHOULD NOT perform DNS additional section processing,
+   except as required for EDNS0 and DNSSEC.
+
+   Senders MUST NOT cache RRs from the authority or additional section
+   of a response as answers, though they may be used for other purposes
+   such as negative caching.
+
+3.  Usage model
+
+   Since LLMNR is a secondary name resolution mechanism, its usage is in
+   part determined by the behavior of DNS implementations.  This
+   document does not specify any changes to DNS resolver behavior, such
+   as searchlist processing or retransmission/failover policy.  However,
+   robust DNS resolver implementations are more likely to avoid
+   unnecessary LLMNR queries.
+
+   As noted in [DNSPerf], even when DNS servers are configured, a
+   significant fraction of DNS queries do not receive a response, or
+   result in negative responses due to missing inverse mappings or NS
+   records that point to nonexistent or inappropriate hosts.  This has
+   the potential to result in a large number of unnecessary LLMNR
+   queries.
+
+   [RFC1536] describes common DNS implementation errors and fixes.  If
+   the proposed fixes are implemented, unnecessary LLMNR queries will be
+   reduced substantially, and so implementation of [RFC1536] is
+   recommended.
+
+   For example, [RFC1536] Section 1 describes issues with retransmission
+   and recommends implementation of a retransmission policy based on
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 14]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+   round trip estimates, with exponential backoff.  [RFC1536] Section 4
+   describes issues with failover, and recommends that resolvers try
+   another server when they don't receive a response to a query.  These
+   policies are likely to avoid unnecessary LLMNR queries.
+
+   [RFC1536] Section 3 describes zero answer bugs, which if addressed
+   will also reduce unnecessary LLMNR queries.
+
+   [RFC1536] Section 6 describes name error bugs and recommended
+   searchlist processing that will reduce unnecessary RCODE=3
+   (authoritative name) errors, thereby also reducing unnecessary LLMNR
+   queries.
+
+3.1.  LLMNR configuration
+
+   Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
+   possible for a dual stack host to be configured with the address of a
+   DNS server over IPv4, while remaining unconfigured with a DNS server
+   suitable for use over IPv6.
+
+   In these situations, a dual stack host will send AAAA queries to the
+   configured DNS server over IPv4.  However, an IPv6-only host
+   unconfigured with a DNS server suitable for use over IPv6 will be
+   unable to resolve names using DNS.  Automatic IPv6 DNS configuration
+   mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
+   deployed, and not all DNS servers support IPv6. Therefore lack of
+   IPv6 DNS configuration may be a common problem in the short term, and
+   LLMNR may prove useful in enabling linklocal name resolution over
+   IPv6.
+
+   Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
+   IPv6-only hosts may not be configured with a DNS server.  Where there
+   is no DNS server authoritative for the name of a host or the
+   authoritative DNS server does not support dynamic client update over
+   IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
+   be able to do DNS dynamic update, and other hosts will not be able to
+   resolve its name.
+
+   For example, if the configured DNS server responds to AAAA RR queries
+   sent over IPv4 or IPv6 with an authoritative name error (RCODE=3),
+   then it will not be possible to resolve the names of IPv6-only hosts.
+   In this situation, LLMNR over IPv6 can be used for local name
+   resolution.
+
+   Similarly, if a DHCPv4 server is available providing DNS server
+   configuration, and DNS server(s) exist which are authoritative for
+   the A RRs of local hosts and support either dynamic client update
+   over IPv4 or DHCPv4-based dynamic update, then the names of local
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 15]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+   IPv4 hosts can be resolved over IPv4 without LLMNR.  However,  if no
+   DNS server is authoritative for the names of local hosts, or the
+   authoritative DNS server(s) do not support dynamic update, then LLMNR
+   enables linklocal name resolution over IPv4.
+
+   Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
+   configure LLMNR on an interface.  The LLMNR Enable Option, described
+   in [LLMNREnable], can be used to explicitly enable or disable use of
+   LLMNR on an interface.  The LLMNR Enable Option does not determine
+   whether or in which order DNS itself is used for name resolution.
+   The order in which various name resolution mechanisms should be used
+   can be specified using the Name Service Search Option (NSSO) for DHCP
+   [RFC2937], using the LLMNR Enable Option code carried in the NSSO
+   data.
+
+   It is possible that DNS configuration mechanisms will go in and out
+   of service.  In these circumstances, it is possible for hosts within
+   an administrative domain to be inconsistent in their DNS
+   configuration.
+
+   For example, where DHCP is used for configuring DNS servers, one or
+   more DHCP servers can fail.  As a result, hosts configured prior to
+   the outage will be configured with a DNS server, while hosts
+   configured after the outage will not.  Alternatively, it is possible
+   for the DNS configuration mechanism to continue functioning while
+   configured DNS servers fail.
+
+   Unless unconfigured hosts periodically retry configuration, an outage
+   in the DNS configuration mechanism will result in hosts continuing to
+   use LLMNR even once the outage is repaired.  Since LLMNR only enables
+   linklocal name resolution, this represents an unnecessary degradation
+   in capabilities.  As a result, it is recommended that hosts without a
+   configured DNS server periodically attempt to obtain DNS
+   configuration.  For example, where DHCP is used for DNS
+   configuration, [RFC2131] recommends a maximum retry interval of 64
+   seconds.  In the absence of other guidance, a default retry interval
+   of one (1) minute is RECOMMENDED.
+
+4.  Conflict resolution
+
+   The sender MUST anticipate receiving multiple replies to the same
+   LLMNR query, in the event that several LLMNR enabled computers
+   receive the query and respond with valid answers.  When this occurs,
+   the responses may first be concatenated, and then treated in the same
+   manner that multiple RRs received from the same DNS server would; the
+   sender perceives no inherent conflict in the receipt of multiple
+   responses.
+
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 16]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+   There are some scenarios when multiple responders MAY respond to the
+   same query.  There are other scenarios when only one responder MAY
+   respond to a query.  Resource records for which the latter queries
+   are submitted are referred as UNIQUE throughout this document.  The
+   uniqueness of a resource record depends on a nature of the name in
+   the query and type of the query.  For example it is expected that:
+
+      - multiple hosts may respond to a query for an SRV type record
+      - multiple hosts may respond to a query for an A or AAAA type
+        record for a cluster name (assigned to multiple hosts in
+        the cluster)
+      - only a single host may respond to a query for an A or AAAA
+        type record for a name.
+
+   Every responder that responds to an LLMNR query AND includes a UNIQUE
+   record in the response:
+
+   [1]  MUST verify that there is no other host within the
+        scope of the LLMNR query propagation that can return
+        a resource record for the same name, type and class.
+
+   [2]  MUST NOT include a UNIQUE resource record in the
+        response without having verified its uniqueness.
+
+   Where a host is configured to issue LLMNR queries on more than one
+   interface, each interface should have its own independent LLMNR
+   cache.  For each UNIQUE resource record in a given interface's
+   configuration, the host MUST verify resource record uniqueness on
+   that interface.  To accomplish this, the host MUST send an LLMNR
+   query for each UNIQUE resource record.
+
+   By default, a host SHOULD be configured to behave as though all RRs
+   are UNIQUE.  Uniqueness verification is carried out when the host:
+
+     - starts up or is rebooted
+     - wakes from sleep (if the network interface was inactive during sleep)
+     - is configured to respond to the LLMNR queries on an interface
+       enabled for transmission and reception of IP traffic
+     - is configured to respond to the LLMNR queries using additional
+       UNIQUE resource records
+     - detects that an interface is connected and is usable
+       (e.g. an IEEE 802 hardware link-state change indicating
+       that a cable was attached or completion of authentication
+       (and if needed, association) with a wireless base station
+       or adhoc network
+
+   When a host that has a UNIQUE record receives an LLMNR query for that
+   record, the host MUST respond.  After the client receives a response,
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 17]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+   it MUST check whether the response arrived on an interface different
+   from the one on which the query was sent.  If the response arrives on
+   a different interface, the client can use the UNIQUE resource record
+   in response to LLMNR queries.  If not, then it MUST NOT use the
+   UNIQUE resource record in response to LLMNR queries.
+
+   The name conflict detection mechanism doesn't prevent name conflicts
+   when previously partitioned segments are connected by a bridge. In
+   order to minimize the chance of conflicts in such a situation, it is
+   recommended that steps be taken to ensure name uniqueness. For
+   example, the name could be chosen randomly from a large pool of
+   potential names, or the name could be assigned via a process designed
+   to guarantee uniqueness.
+
+   When name conflicts are detected, they SHOULD be logged.  To detect
+   duplicate use of a name, an administrator can use a name resolution
+   utility which employs LLMNR and lists both responses and responders.
+   This would allow an administrator to diagnose behavior and
+   potentially to intervene and reconfigure LLMNR responders who should
+   not be configured to respond to the same name.
+
+4.1.  Considerations for Multiple Interfaces
+
+   A multi-homed host may elect to configure LLMNR on only one of its
+   active interfaces.  In many situations this will be adequate.
+   However, should a host need to configure LLMNR on more than one of
+   its active interfaces, there are some additional precautions it MUST
+   take.  Implementers who are not planning to support LLMNR on multiple
+   interfaces simultaneously may skip this section.
+
+   A multi-homed host checks the uniqueness of UNIQUE records as
+   described in Section 4.  The situation is illustrated in figure 1.
+
+        ----------  ----------
+         |      |    |      |
+        [A]    [myhost]   [myhost]
+
+      Figure 1.  Link-scope name conflict
+
+   In this situation, the multi-homed myhost will probe for, and defend,
+   its host name on both interfaces.  A conflict will be detected on one
+   interface, but not the other.  The multi-homed myhost will not be
+   able to respond with a host RR for "myhost" on the interface on the
+   right (see Figure 1).  The multi-homed host may, however, be
+   configured to use the "myhost" name on the interface on the left.
+
+   Since names are only unique per-link, hosts on different links could
+   be using the same name.  If an LLMNR client sends requests over
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 18]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+   multiple interfaces, and receives replies from more than one, the
+   result returned to the client is defined by the implementation.  The
+   situation is illustrated in figure 2.
+
+        ----------  ----------
+         |      |    |     |
+        [A]    [myhost]   [A]
+
+
+      Figure 2.  Off-segment name conflict
+
+   If host myhost is configured to use LLMNR on both interfaces, it will
+   send LLMNR queries on both interfaces.  When host myhost sends a
+   query for the host RR for name "A" it will receive a response from
+   hosts on both interfaces.
+
+   Host myhost cannot distinguish between the situation shown in Figure
+   2, and that shown in Figure 3 where no conflict exists.
+
+                [A]
+               |   |
+           -----   -----
+               |   |
+              [myhost]
+
+      Figure 3.  Multiple paths to same host
+
+   This illustrates that the proposed name conflict resolution mechanism
+   does not support detection or resolution of conflicts between hosts
+   on different links.  This problem can also occur with unicast DNS
+   when a multi-homed host is connected to two different networks with
+   separated name spaces.  It is not the intent of this document to
+   address the issue of uniqueness of names within DNS.
+
+4.2.  API issues
+
+   [RFC2553] provides an API which can partially solve the name
+   ambiguity problem for applications written to use this API, since the
+   sockaddr_in6 structure exposes the scope within which each scoped
+   address exists, and this structure can be used for both IPv4 (using
+   v4-mapped IPv6 addresses) and IPv6 addresses.
+
+   Following the example in Figure 2, an application on 'myhost' issues
+   the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
+   ai_flags=AI_ALL|AI_V4MAPPED.  LLMNR requests will be sent from both
+   interfaces and the resolver library will return a list containing
+   multiple addrinfo structures, each with an associated sockaddr_in6
+   structure.  This list will thus contain the IPv4 and IPv6 addresses
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 19]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+   of both hosts responding to the name 'A'.  Link-local addresses will
+   have a sin6_scope_id value that disambiguates which interface is used
+   to reach the address.  Of course, to the application, Figures 2 and 3
+   are still indistinguishable, but this API allows the application to
+   communicate successfully with any address in the list.
+
+5.  Security Considerations
+
+   LLMNR is by nature a peer-to-peer name resolution protocol. It is
+   therefore inherently more vulnerable than DNS, since existing DNS
+   security mechanisms are difficult to apply to LLMNR. While tools
+   exist to alllow an attacker to spoof a response to a DNS query,
+   spoofing a response to an LLMNR query is easier since the query is
+   sent to a link-scope multicast address, where every host on the
+   logical link will be made aware of it.
+
+   In order to address the security vulnerabilities, the following
+   mechanisms are contemplated:
+
+      [1]  Scope restrictions.
+      [2]  Usage restrictions.
+      [3]  Cache and port separation.
+      [4]  Authentication.
+
+   These techniques are described in the following sections.
+
+5.1.  Scope restriction
+
+   With LLMNR it is possible that hosts will allocate conflicting names
+   for a period of time, or that attackers will attempt to deny service
+   to other hosts by allocating the same name. Such attacks also allow
+   hosts to receive packets destined for other hosts.
+
+   Since LLMNR is typically deployed in situations where no trust model
+   can be assumed, it is likely that LLMNR queries and responses will be
+   unauthenticated.  In the absence of authentication, LLMNR reduces the
+   exposure to such threats by utilizing UDP queries sent to a link-
+   scope multicast address, as well as setting the TTL (IPv4) or Hop
+   Limit (IPv6) fields to one (1) on TCP queries and responses.
+
+   Using a TTL of one (1) to set up a TCP connection in order to send a
+   unicast LLMNR query reduces the likelihood of both denial of service
+   attacks and spoofed responses.  Checking that an LLMNR query is sent
+   to a link-scope multicast address should prevent spoofing of
+   multicast queries by off-link attackers.
+
+   While this limits the ability of off-link attackers to spoof LLMNR
+   queries and responses, it does not eliminate it. For example, it is
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 20]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+   possible for an attacker to spoof a response to a frequent query
+   (such as an A or AAAA query for a popular Internet host), and by
+   using a TTL or Hop Limit field larger than one (1), for the forged
+   response to reach the LLMNR sender.
+
+   When LLMNR queries are sent to a link-scope multicast address, it is
+   possible that some routers may not properly implement link-scope
+   multicast, or that link-scope multicast addresses may leak into the
+   multicast routing system.
+
+   Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than
+   one in an LLMNR UDP response may enable denial of service attacks
+   across the Internet.  However, since LLMNR responders only respond to
+   queries for which they are authoritative, and LLMNR does not provide
+   wildcard query support, it is believed that this threat is minimal.
+
+   There also are scenarios such as public "hotspots" where attackers
+   can be present on the same link.  These threats are most serious in
+   wireless networks such as 802.11, since attackers on a wired network
+   will require physical access to the home network, while wireless
+   attackers may reside outside the home.  Link-layer security can be of
+   assistance against these threats if it is available.
+
+5.2.  Usage restriction
+
+   As noted in Sections 2 and 3, LLMNR is intended for usage in a
+   limited set of scenarios.
+
+   If an LLMNR query is sent whenever a DNS server does not respond in a
+   timely way, then an attacker can poison the LLMNR cache by responding
+   to the query with incorrect information.  To some extent, these
+   vulnerabilities exist today, since DNS response spoofing tools are
+   available that can allow an attacker to respond to a query more
+   quickly than a distant DNS server.
+
+   Since LLMNR queries are sent and responded to on the local-link, an
+   attacker will need to respond more quickly to provide its own
+   response prior to arrival of the response from a legitimate
+   responder. If an LLMNR query is sent for an off-link host, spoofing a
+   response in a timely way is not difficult, since a legitimate
+   response will never be received.
+
+   The vulnerability is more serious if LLMNR is given higher priority
+   than DNS among the enabled name resolution mechanisms. In such a
+   configuration, a denial of service attack on the DNS server would not
+   be necessary in order to poison the LLMNR cache, since LLMNR queries
+   would be sent even when the DNS server is available. In addition, the
+   LLMNR cache, once poisoned, would take precedence over the DNS cache,
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 21]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+   eliminating the benefits of cache separation. As a result, LLMNR is
+   only used as a name resolution mechanism of last resort.
+
+5.3.  Cache and port separation
+
+   In order to prevent responses to LLMNR queries from polluting the DNS
+   cache, LLMNR implementations MUST use a distinct, isolated cache for
+   LLMNR on each interface. The use of separate caches is most effective
+   when LLMNR is used as a name resolution mechanism of last resort,
+   since this minimizes the opportunities for poisoning the LLMNR cache,
+   and decreases reliance on it.
+
+   LLMNR operates on a separate port from DNS, reducing the likelihood
+   that a DNS server will unintentionally respond to an LLMNR query.
+
+5.4.  Authentication
+
+   LLMNR implementations may not support DNSSEC or TSIG, and as a
+   result, responses to LLMNR queries may be unauthenticated.  If
+   authentication is desired, and a pre-arranged security configuration
+   is possible, then IPsec ESP with a null-transform MAY be used to
+   authenticate LLMNR responses.  In a small network without a
+   certificate authority, this can be most easily accomplished through
+   configuration of a group pre-shared key for trusted hosts.
+
+6.  IANA Considerations
+
+   This specification creates one new name space:  the reserved bits in
+   the LLMNR header.  These are allocated by IETF Consensus, in
+   accordance with BCP 26 [RFC2434].
+
+   LLMNR requires allocation of port 5355 for both TCP and UDP.
+
+   LLMNR requires allocation of link-scope multicast IPv4 address
+   224.0.0.252, as well as link-scope multicast IPv6 address
+   FF02:0:0:0:0:0:1:3.
+
+7.  References
+
+7.1.  Normative References
+
+[RFC1035] Mockapetris, P., "Domain Names - Implementation and
+          Specification", RFC 1035, November 1987.
+
+[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+          April 1992.
+
+
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 22]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+          Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+          Specification", RFC 2181, July 1997.
+
+[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+          RFC 2308, March 1998.
+
+[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
+          2365, July 1998.
+
+[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+          Architecture", RFC 2373, July 1998.
+
+[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+          Considerations Section in RFCs", BCP 26, RFC 2434, October
+          1998.
+
+[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+          (IPv6) Specification", RFC 2460, December 1998.
+
+[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+          2535, March 1999.
+
+[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
+          August 1999.
+
+[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
+          Timer", RFC 2988, November 2000.
+
+7.2.  Informative References
+
+[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
+          Fixes", RFC 1536, October 1993.
+
+[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+          March 1997.
+
+[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+          Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+          April 1997.
+
+[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
+          RFC 2292, February 1998.
+
+[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
+          Socket Interface Extensions for IPv6", RFC 2553, March 1999.
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 23]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
+          2937, September 2000.
+
+[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
+          IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
+          Caching", IEEE/ACM Transactions on Networking, Volume 10,
+          Number 5, pp. 589, October 2002.
+
+[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
+          unicast addresses to communicate with recursive DNS servers",
+          Internet draft (work in progress), draft-ietf-ipv6-dns-
+          discovery-07.txt, October 2002.
+
+[IPV4Link]
+          Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
+          of IPv4 Link-Local Addresses", Internet draft (work in
+          progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, May
+          2004.
+
+[POSIX]   IEEE Std. 1003.1-2001 Standard for Information Technology --
+          Portable Operating System Interface (POSIX). Open Group
+          Technical Standard: Base Specifications, Issue 6, December
+          2001.  ISO/IEC 9945:2002.  http://www.opengroup.org/austin
+
+[LLMNREnable]
+          Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
+          in progress), draft-guttman-mdns-enable-02.txt, April 2002.
+
+[NodeInfo]
+          Crawford, M., "IPv6 Node Information Queries", Internet draft
+          (work in progress), draft-ietf-ipn-gwg-icmp-name-
+          lookups-09.txt, May 2002.
+
+Acknowledgments
+
+   This work builds upon original work done on multicast DNS by Bill
+   Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
+   grant #F30602-99-1-0523. The authors gratefully acknowledge their
+   contribution to the current specification.  Constructive input has
+   also been received from Mark Andrews, Stuart Cheshire, Randy Bush,
+   Robert Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik
+   Guttman, Myron Hattig, Thomas Narten, Christian Huitema, Erik
+   Nordmark, Sander Van-Valkenburg, Tomohide Nagashima, Brian Zill,
+   Keith Moore and Markku Savela.
+
+
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 24]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+Authors' Addresses
+
+   Levon Esibov
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   EMail: levone@microsoft.com
+
+   Bernard Aboba
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: +1 425 706 6605
+   EMail: bernarda@microsoft.com
+
+   Dave Thaler
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: +1 425 703 8835
+   EMail: dthaler@microsoft.com
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards- related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 25]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                     25 June 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.  The limited permissions granted above are perpetual and
+   will not be revoked by the Internet Society or its successors or
+   assigns.  This document and the information contained herein is
+   provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Open Issues
+
+   Open issues with this specification are tracked on the following web
+   site:
+
+   http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
+
+Expiration Date
+
+   This memo is filed as <draft-ietf-dnsext-mdns-32.txt>,  and  expires
+   December 22, 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler       Standards Track                   [Page 26]
+
diff --git a/lib/bind/api b/lib/bind/api
index 815c8f55..0d0496c8 100644
--- a/lib/bind/api
+++ b/lib/bind/api
@@ -1,3 +1,3 @@
 LIBINTERFACE = 3
-LIBREVISION = 4
+LIBREVISION = 5
 LIBAGE = 0
diff --git a/lib/bind/include/arpa/nameser_compat.h b/lib/bind/include/arpa/nameser_compat.h
index dc64bd17..9eabb16c 100644
--- a/lib/bind/include/arpa/nameser_compat.h
+++ b/lib/bind/include/arpa/nameser_compat.h
@@ -32,7 +32,7 @@
 
 /*
  *      from nameser.h	8.1 (Berkeley) 6/2/93
- *	$Id: nameser_compat.h,v 1.1.2.4 2004/03/09 09:17:25 marka Exp $
+ *	$Id: nameser_compat.h,v 1.1.2.5 2004/07/01 04:42:04 marka Exp $
  */
 
 #ifndef _ARPA_NAMESER_COMPAT_
@@ -65,7 +65,7 @@
     defined(__hppa) || defined(__hp9000) || \
     defined(__hp9000s300) || defined(__hp9000s700) || \
     defined(__hp3000s900) || defined(__hpux) || defined(MPE) || \
-    defined (BIT_ZERO_ON_LEFT) || defined(m68k) || \
+    defined (BIT_ZERO_ON_LEFT) || defined(m68k) || defined(__sparc) ||  \
     (defined(__Lynx__) && \
      (defined(__68k__) || defined(__sparc__) || defined(__powerpc__)))
 #define BYTE_ORDER	BIG_ENDIAN
diff --git a/lib/bind/include/resolv.h b/lib/bind/include/resolv.h
index bc32d7d5..b8339c4c 100644
--- a/lib/bind/include/resolv.h
+++ b/lib/bind/include/resolv.h
@@ -50,7 +50,7 @@
 
 /*
  *	@(#)resolv.h	8.1 (Berkeley) 6/2/93
- *	$Id: resolv.h,v 1.7.2.12 2004/03/09 09:17:24 marka Exp $
+ *	$Id: resolv.h,v 1.7.2.13 2004/06/25 00:39:31 marka Exp $
  */
 
 #ifndef _RESOLV_H_
@@ -254,6 +254,7 @@ union res_sockaddr_union {
 #define	RES_BLAST	0x00020000	/* blast all recursive servers */
 #define RES_NOTLDQUERY	0x00100000	/* don't unqualified name as a tld */
 #define RES_USE_DNSSEC	0x00200000	/* use DNSSEC using OK bit in OPT */
+/* #define RES_DEBUG2	0x00400000 */	/* nslookup internal */
 /* KAME extensions: use higher bit to avoid conflict with ISC use */
 #define RES_USE_DNAME	0x10000000	/* use DNAME */
 #define RES_USE_EDNS0	0x40000000	/* use EDNS0 if configured */
diff --git a/lib/bind/irs/getnameinfo.c b/lib/bind/irs/getnameinfo.c
index dd8c14b4..5947c038 100644
--- a/lib/bind/irs/getnameinfo.c
+++ b/lib/bind/irs/getnameinfo.c
@@ -154,7 +154,7 @@ getnameinfo(sa, salen, host, hostlen, serv, servlen, flags)
 
 	switch (sa->sa_family) {
 	case AF_INET:
-		if (ntohl(*(const u_long *)addr) >> IN_CLASSA_NSHIFT == 0)
+		if (ntohl(*(const u_int32_t *)addr) >> IN_CLASSA_NSHIFT == 0)
 			flags |= NI_NUMERICHOST;			
 		break;
 	case AF_INET6:
diff --git a/lib/dns/api b/lib/dns/api
index f94ca400..c88c1d07 100644
--- a/lib/dns/api
+++ b/lib/dns/api
@@ -1,3 +1,3 @@
 LIBINTERFACE = 12
-LIBREVISION = 3
+LIBREVISION = 4
 LIBAGE = 1
diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c
index 27588c27..2c519eb8 100644
--- a/lib/dns/resolver.c
+++ b/lib/dns/resolver.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resolver.c,v 1.218.2.31 2004/04/15 02:16:27 marka Exp $ */
+/* $Id: resolver.c,v 1.218.2.34 2004/07/03 00:56:55 marka Exp $ */
 
 #include <config.h>
 
@@ -1775,7 +1775,7 @@ possibly_mark(fetchctx_t *fctx, dns_adbaddrinfo_t *addr)
 
 static inline dns_adbaddrinfo_t *
 fctx_nextaddress(fetchctx_t *fctx) {
-	dns_adbfind_t *find;
+	dns_adbfind_t *find, *start;
 	dns_adbaddrinfo_t *addrinfo;
 
 	/*
@@ -1812,21 +1812,24 @@ fctx_nextaddress(fetchctx_t *fctx) {
 	 * Find the first unmarked addrinfo.
 	 */
 	addrinfo = NULL;
-	while (find != fctx->find) {
-		for (addrinfo = ISC_LIST_HEAD(find->list);
-		     addrinfo != NULL;
-		     addrinfo = ISC_LIST_NEXT(addrinfo, publink)) {
-			possibly_mark(fctx, addrinfo);
-			if (UNMARKED(addrinfo)) {
-				addrinfo->flags |= FCTX_ADDRINFO_MARK;
-				break;
+	if (find != NULL) {
+		start = find;
+		do {
+			for (addrinfo = ISC_LIST_HEAD(find->list);
+			     addrinfo != NULL;
+			     addrinfo = ISC_LIST_NEXT(addrinfo, publink)) {
+				possibly_mark(fctx, addrinfo);
+				if (UNMARKED(addrinfo)) {
+					addrinfo->flags |= FCTX_ADDRINFO_MARK;
+					break;
+				}
 			}
-		}
-		if (addrinfo != NULL)
-			break;
-		find = ISC_LIST_NEXT(find, publink);
-		if (find != fctx->find && find == NULL)
-			find = ISC_LIST_HEAD(fctx->finds);
+			if (addrinfo != NULL)
+				break;
+			find = ISC_LIST_NEXT(find, publink);
+			if (find == NULL)
+				find = ISC_LIST_HEAD(fctx->finds);
+		} while (find != start);
 	}
 
 	fctx->find = find;
diff --git a/lib/isc/api b/lib/isc/api
index a8e3a55c..3a0cbf2f 100644
--- a/lib/isc/api
+++ b/lib/isc/api
@@ -1,3 +1,3 @@
 LIBINTERFACE = 8
-LIBREVISION = 4
+LIBREVISION = 5
 LIBAGE = 1
diff --git a/lib/isc/unix/Makefile.in b/lib/isc/unix/Makefile.in
index 86576a49..cd4fe2ca 100644
--- a/lib/isc/unix/Makefile.in
+++ b/lib/isc/unix/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.35.2.2 2004/03/09 06:12:08 marka Exp $
+# $Id: Makefile.in,v 1.35.2.3 2004/06/22 02:55:36 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -46,3 +46,6 @@ SUBDIRS =	include
 TARGETS =	${OBJS}
 
 @BIND9_MAKE_RULES@
+
+interfaceiter.@O@: interfaceiter.c ifiter_ioctl.c ifiter_sysctl.c
+
diff --git a/lib/isc/unix/socket.c b/lib/isc/unix/socket.c
index 52a802d8..373817ca 100644
--- a/lib/isc/unix/socket.c
+++ b/lib/isc/unix/socket.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: socket.c,v 1.207.2.27 2004/04/19 02:56:46 marka Exp $ */
+/* $Id: socket.c,v 1.207.2.29 2004/07/01 04:51:44 marka Exp $ */
 
 #include <config.h>
 
@@ -2855,7 +2855,11 @@ isc_socket_bind(isc_socket_t *sock, isc_sockaddr_t *sockaddr) {
 		UNLOCK(&sock->lock);
 		return (ISC_R_FAMILYMISMATCH);
 	}
-	if (setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on,
+	/*
+	 * Only set SO_REUSEADDR when we want a specific port.
+	 */
+	if (isc_sockaddr_getport(sockaddr) != (in_port_t)0 &&
+	    setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on,
 		       sizeof(on)) < 0) {
 		UNEXPECTED_ERROR(__FILE__, __LINE__,
 				 "setsockopt(%d) %s", sock->fd,
diff --git a/lib/isc/win32/socket.c b/lib/isc/win32/socket.c
index 773f6274..1887b44c 100644
--- a/lib/isc/win32/socket.c
+++ b/lib/isc/win32/socket.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: socket.c,v 1.5.2.21 2004/05/17 03:02:23 marka Exp $ */
+/* $Id: socket.c,v 1.5.2.23 2004/06/30 23:28:40 marka Exp $ */
 
 /* This code has been rewritten to take advantage of Windows Sockets
  * I/O Completion Ports and Events. I/O Completion Ports is ONLY
@@ -1846,11 +1846,13 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type,
 	switch (type) {
 	case isc_sockettype_udp:
 		sock->fd = socket(pf, SOCK_DGRAM, IPPROTO_UDP);
-		result = connection_reset_fix(sock->fd);
-		if (result != ISC_R_SUCCESS) {
-			closesocket(sock->fd);
-			free_socket(&sock);
-			return (result);
+		if (sock->fd != INVALID_SOCKET) {
+			result = connection_reset_fix(sock->fd);
+			if (result != ISC_R_SUCCESS) {
+				closesocket(sock->fd);
+				free_socket(&sock);
+				return (result);
+			}
 		}
 		break;
 	case isc_sockettype_tcp:
@@ -3223,7 +3225,11 @@ isc_socket_bind(isc_socket_t *sock, isc_sockaddr_t *sockaddr) {
 		UNLOCK(&sock->lock);
 		return (ISC_R_FAMILYMISMATCH);
 	}
-	if (setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on,
+	/*
+	 * Only set SO_REUSEADDR when we want a specific port.
+	 */
+	if (isc_sockaddr_getport(sockaddr) != (in_port_t)0 &&
+	    setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on,
 		       sizeof(on)) < 0) {
 		UNEXPECTED_ERROR(__FILE__, __LINE__,
 				 "setsockopt(%d) %s", sock->fd,
diff --git a/lib/tests/include/tests/t_api.h b/lib/tests/include/tests/t_api.h
index 18814159..4ac77739 100644
--- a/lib/tests/include/tests/t_api.h
+++ b/lib/tests/include/tests/t_api.h
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: t_api.h,v 1.14.2.1 2004/03/09 06:12:45 marka Exp $ */
+/* $Id: t_api.h,v 1.14.2.2 2004/06/21 07:08:36 marka Exp $ */
 
 #ifndef TESTS_T_API_H
 #define TESTS_T_API_H 1
@@ -37,6 +37,7 @@
 #define	T_UNRESOLVED	0x3
 #define	T_UNSUPPORTED	0x4
 #define	T_UNTESTED	0x5
+#define	T_THREADONLY	0x6
 
 /*
  *
diff --git a/lib/tests/t_api.c b/lib/tests/t_api.c
index d23993a8..c56b66a9 100644
--- a/lib/tests/t_api.c
+++ b/lib/tests/t_api.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: t_api.c,v 1.48.2.3 2004/03/09 06:12:44 marka Exp $ */
+/* $Id: t_api.c,v 1.48.2.4 2004/06/21 07:08:36 marka Exp $ */
 
 #include <config.h>
 
@@ -390,6 +390,9 @@ t_result(int result) {
 		case T_UNTESTED:
 			p = "UNTESTED";
 			break;
+		case T_THREADONLY:
+			p = "THREADONLY";
+			break;
 		default:
 			p = "UNKNOWN";
 			break;
diff --git a/version b/version
index 09e560b4..5d2b8c38 100644
--- a/version
+++ b/version
@@ -1,4 +1,4 @@
-# $Id: version,v 1.26.2.27 2004/06/11 03:37:27 marka Exp $
+# $Id: version,v 1.26.2.28 2004/07/01 02:10:19 marka Exp $
 #
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
@@ -7,4 +7,4 @@ MAJORVER=9
 MINORVER=2
 PATCHVER=4
 RELEASETYPE=rc
-RELEASEVER=5
+RELEASEVER=6