Subject: DNSEXT Document Review: LLMNR-45

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Thu, 12 Jan 2006 11:08:44 -0500

Dear Colleagues

In http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01251.html
our AD, Margaret Wasserman summarized the IETF Last Call
and provided the reasons why LLMNR should not be forwarded to the
IESG. She asked the DNSEXT working group to resolve the issues and
suggested a new IETF last call when the issues where addressed.
Note that after posting of the above mail there was significant
discussion on the IETF list.

Below are the issues brought up by Margaret:

(1) Concerns that publication of this protocol will be confusing
or actively harmful given the existing wide deployment of Apple's
mDNS protocol.

(2) Security concerns have been raised about the fact that
applications on hosts that implement LLMNR will not be able to
tell if a response has come from the DNS or from a local lookup.

(3) Separate, but perhaps underlying both of the previous issues,
there seems be a fundamental disagreement about what technical
approach we should take to link-local name lookup. LLMNR takes the
approach that local lookups should use the same names as global
lookups and that upper layers should not care whether a name was
resolved in the global DNS or locally, essentially making the
local lookup mechanism an extension of the DNS. mDNS takes the
approach that local lookups should be distinguishable from global
lookups and accomplishes this through the use of a special local
domain (.local).

Bernard argued in 
http://www1.ietf.org/mail-archive/web/ietf/current/msg37767.html
that points 1 and 2 are resolver and API issues respectively.

Since the start of the IETF last call (LLMNR-42), 
Bernard has updated the document  3 times,
The current version is available at
    http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-45.txt
the diff´s are available at:
    http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-mdns/draft-ietf-dnsext-mdns-43-from-42.diff.html
    http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-mdns/draft-ietf-dnsext-mdns-44-from-43.diff.html
    http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-mdns/draft-ietf-dnsext-mdns-45-from-44.diff.html

These edits have been vetted through several ISSUES on the
mailing-list. The issue tracker for LLMNR is at
   http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

We are asking the working group to thoroughly review version 45.

We would like to specifically ask the working group:

    a) that it agrees that all protocol issues have been properly
       addressed;
    b) that it supports the thought that issue 1 and 2 are indeed out
       of scope;
    c) and that Issue 3 is indeed clarified in version 0.45 of the
       document.

If there is consensus on the fact that the answer to the 3
questions above is yes then we will forward the document to the
IESG once more. If there is no consensus on one of the 3 questions
(based on technical arguments) then more work needs to be done or,
alternatively, we drop the work and ask Margaret to support
publication as an informational RFC (please provide arguments).

If we do not get sufficient feedback on this i.e. fewer than 5
people indicate they have thoroughly reviewed the document  then we
will inform our AD that the DNSEXT working group failed in
delivering a review of chartered work and request removal of the
work item.
In that case we plan to suggest to the AD, that as this document has
seen detailed technical review this working group will not
object if this document being published as informational (unless
the working group instructs us not to do so).

We plan review the discussion on this item during the second week
of February, please send your comments no later than on February 5'th.

	The DNSEXT chairs
	Olaf & Ólafur

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Jan 2006 12:50:47 -0800 (PST)

Andrew Sullivan said:

>What I am slightly puzzled about is that, given the
>suggestions about how to handle single-label names and the suggestion
>that users reserve a FQDN if they want to use it with LLMNR, I'm not
>sure what is so different about this proposal from Apple's mDNS; and
>mDNS, as far as I can tell, has the additional benefit that a mistake
>in configuration doesn't automatically leak to the global DNS.

mDNS and LLMNR do not in fact differ in that respect; issue #3 was in fact 
in error, as Stuart pointed out on the IETF list. 

Either mDNS or LLMNR can be used to resolve any name, but both protocols 
restrict queries by default.  By default, LLMNR only sends queries 
for the single-label namespace established by RFC 1001;  mDNS uses the 
".local" name space.  Either protocol can conceivably be mis-configured. 

Neither mDNS nor LLMNR take the position that applications should 
not care how names are resolved;  APIs enable applications to control 
that behavior.  

Andrew Sullivan also said:

>That is the way she introduced it in her email; but I noticed that
>her subsequent discussion of the question boiled down to two, in my
>view distinct questions:
>
>1.a.	That users will be confused, and potentially use .local.
>1.b.	That large numbers of lookups for undelegated labels may end
>up going to the global DNS.
>
>
>It seems to me that these are different issues, and that it makes no
>difference whether it is the label ".local" or something else for
>which the query asks, unless the query is for something that is
>already properly configured in the global DNS.  Perhaps I am
>overlooking some way in which 1.b. depends strongly on 1.a.?  Because
>it sort of looks to me like 1.b. might be true under this draft even
>if users understand perfectly well that they shouldn't use .local.

1.b is not directly related to 1.a as far as I can see, although both seem 
to be related to resolver behavior.  Whether a given implementation 
supports mDNS or LLMNR or both, it is possible (and probably desirable) 
for the resolver to avoid sending lookups for ".local" to the global DNS.  
Similarly, implementations supporting both DNS and RFC 1001 have traditionally 
not sent lookups for single-label names to the global DNS (e.g. typing 
"http://msw/ in the browser will not result in a DNS query for "msw" on 
the wire). 

Paul Vixie asked:

>Bernie, can you offer us some guideance as to your interest or your 
>employer's interest in seeing LLMNR standardized?  why aren't you able 
>to use Apple's existing similar technology to achieve your aims here?

My own interest in "mDNS" only arose after I was told by the DNSEXT WG 
chairs that the WG had not accepted the exist  mDNS proposal as 
a WG work item.  At the time, the alternative seemed to be either to have 
no IETF-standard link local name resolution protocol, or to work with the 
DNSEXT WG to develop a standard.  I did not imagine at the time that 
working with the IETF could result in the worst of all possible outcomes. 

Although Apple's mDNS and DNSEXT WG's LLMNR protocol appear similar in 
packet format, their objectives are actually quite different.  As Stuart 
has noted, the goal of Apple Bonjour was to provide much the same 
functionality that had been provided in AppleTalk.  As a result, Service 
Discovery is a core requirement for mDNS.  LLMNR does not provide the 
service discovery functionality required by Apple Bonjour. Apple mDNS does 
not provide a name resolution service for single-label names.