Subject: Re: DNSEXT WGLC Summary: LLMNR

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Oct 2003 21:02:09 -0700 (PDT)

> that computer simply is not going to be able to identify itself using
> LLMNR.

I'm not sure how you conclude this.  LLMNR doesn't care whether the
name is an FQDN or not.  If you type "ping tedlemon" then the host will
send an LLMNR query for "tedlemon".  If you type "ping
tedlemon.nominum.com" then if the configured DNS server doesn't answer the
query or responds with "no such name" then an LLMNR query will be sent for
"tedlemon.nominum.com"

> implementation does something extra-protocular to generate an FQDN.

Nope. LLMNR can send a query for any name.

> Perhaps the right thing is to specify the protocol by which this name
> is derived separately, but if so, we should say that that's the answer,

All LLMNR needs to work is for a responder to have a name, any name. If it
hears a query for that name, it will respond.

--
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: Mika Liljeberg <[email-masked]>
Date: Thu, 23 Oct 2003 13:37:09 +0300

I have to say that, to some extent, I share Joshua's concern with regard
to naming devices in an ad-hoc fashion. While it is true that LLMNR can
be used to query any name, the implicit assumption seems to be that the
naming must be consistent with DNS. 

In ad-hoc scenarios users need to be able to nickname their devices with
something that is easy to type and remember (and fits on a single line
on a cell phone display, for instance). Users like simple names such as
"phone", "headset", "pc", or "vcr". It's not acceptable to have
something like "mdzadpa". Who can remember that? In case of conflict, I
might want to use a longer name like "phone.mika". So instead of having
a single nickname my device might have multiple nicknames.

How could I resolve the inevitable conflict using LLMNR? In real life
users deal with naming conflicts all the time and think nothing of it.
People sometimes have the same first names, so we qualify what we mean
by adding a surname or narrow the context in some other manner. Suppose
Ted's phone also has names like "phone" and "phone.ted". My query for
"phone" returns IP addresses for both my phone and Ted's phone. Since I
got responses from more than one device a conflict has occurred. My
application might try to resolve this by doing a reverse query for both
IP addresses and receive the names "phone.mika" and "phone.ted" (or it
might use some other protocol to get a better description of each
device), which in turn would be presented to me in a selection dialog. I
would then be able to qualify which one I meant by selecting one of the
presented choises.

There are various ways to implement the above but it seems clear to me
that we can't do something like this in a manner that will satisfy the
users if the naming is required to be consistent with DNS. Being able to
pick any name you want is important. That being the case, I can see a
need for a reserved TLD name for ad-hoc use, guaranteed never to appear
in the global DNS. That doesn't mean LLMNR should not respond to queries
for its DNS names as well. It just means that the names picked by the
users themselves would be placed in a separate name space.

	MikaL

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 23 Oct 2003 08:58:25 -0500

on 10/23/2003 5:37 AM Mika Liljeberg wrote:

> users if the naming is required to be consistent with DNS.

Well, since there are various ways to do it, there's no real restriction
or requirement. An RR with an owner name of the device and textual data
would provide friendly long names indexed to short (DNS) names. Having the
systems include these RRs in the ~authority section of the question
message would provide the advertisement and collision detection
mechanisms. Due to the absence of an authoritative delegation hierarchy
(this includes the absence of a .local, but also includes the absence of
naming authority at the leaf-node), the short names must be kept separate
from "real" DNS names anyway.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 23 Oct 2003 07:03:26 -0700 (PDT)

> users if the naming is required to be consistent with DNS.

There's no requirement that an LLMNR responder register its name in DNS;
however, if it does, then it will also respond to LLMNR queries for
the name it registers.  An LLMNR responder can choose to respond to the
name "joe" or "joe.example.com".

In terms of *attributes* of the host, such as a "friendly description", an
icon, a sound, etc. these are all orthogonal issues to name resolution.
Service discovery protocols (including uPnP, SLPv2, etc.) are typically
extensible and can provide this kind of richness.  There is no need
to overload DNS to handle this.  If the desire is merely to discover
services and present them on the desktop in a pleasing way, I'd argue
that name resolution is not required.  Send a service discovery query,
collate the results (which can include a naming attribute, by the way)
and display them.  If anything, the problem is that we have too many
protocols that can handle this.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Oct 2003 13:17:22 -0400

I've been reviewing draft-ietf-dnsext-mdns-24.txt, and I found that I don't
think I would know how to implement LLMNR based on this document.  In
particular, the description of some terms like hostname, current domain, as
well as the behavior of senders and responders regarding unqualified names,
needs to be clarified.

One problem I have is the ambiguity between current host implementations of
these concepts and the way the terms are used in the document.  I think it
would be useful to give concrete, implementation-independent definitions of
the following terms in the terminology section:

hostname - in section 2.2, the third paragraph begins with the sentence: 'As
an example, a computer "host.example.com." ...'  I don't know what this
means in an implementation; is this a configured character string or a
one-component name with the current domain appended or ???  I suggest that
something like "hostname" be defined and used throughout the document for
clarity.

current domain - in section 3.1, the first item in the implicit search order
is "...the name with the current domain appended".  What, exactly, is the
"current domain"?  Is it the domain search list?  I don't think that term is
defined in RFC 1536, which is given as a reference to the list.

authoritative - this term seems to be used in a different way than in DNS,
and is defined by example rather than by a sentence or phrase

owned by - in the fifth paragraph of section 2.2, what are "RRSets owned by
the host"?

(other DNS terms) - it might be good to say something in section 1.2 to the
effect of "Other terminology from DNS is defined in RFC 1034 or RFC 1035
(whichever is appropriate).  In fact, it might be good to explicitly state
that the reader should be familiar with the concepts from DNS in RFC 1034
and RFC 1035.

Regarding unqualified names, I'm trying to relate the protocol described in
draft-ietf-dnsext-mdns-24.txt to the scenario I imagine I would use at home,
where I have a couple of computers using private addressing behind NAT,
which are configured with a list of DNS recursive name servers through DHCP.
  Each computer is configured with an unqualified name, say "den" and
"laptop" and does not have a domain search list.  I'd like to be able to be
able to enter, for example, http://den/some-random-page.html

So, the target of this URL is configured with the unqualified name "den".
The sender presumably first sends a request to the each of the DNS servers
in the configured list of servers, and gets no response or a negative
response.  According to section 3.1, the sender skips step 1 (no current
domain or domain search list configured) and sends a request for the name
with the root domain appended: "den."  If the target is configured with the
unqualified name "den", does it also respond to requests for the name
"den."?  Or, does the hostname always have to be a FQDN, so that if the user
enters "den" as the "computer name", the hostname is then "den."?

By the way, I found the description (section 3, first para) of when to use
LLMNR to be confusing.  Could that description be rewritten as a list of
conditions or steps to take?

- Ralph

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 23 Oct 2003 10:44:52 -0700

> query or responds with "no such name" then an LLMNR query will be sent 

This is only true if the computer performing the lookup doesn't have a 
list of search domains or there is no tedlemon.<search domain(s) here>. 
Example: User has DSL and NAT. Their ISP has told them to use the 
search domain example.net and use "mail" as the mail server name. This 
is a really stupid way to set things up, but it is fairly common. There 
exists a tedlemon.example.net. Ted Lemon visits, and hooks up his 
laptop. He's using the name "tedlemon". He tells Joe to connect to his 
web server (http://tedlemon/). Joe types it in, hits return. Joe gets a 
connection error because tedlemon.example.net resolved and isn't 
running a web server. Joe can not use a name to access Ted Lemon's 
computer.

> Nope. LLMNR can send a query for any name.

LLMNR _can_ send a query for any name. It is not likely to send a query 
for most names unless DNS is available. When a DNS server is available, 
a user will be unable to determine which names can be used with LLMNR 
and which names can not. What works in one situation may not work in 
another.

> hears a query for that name, it will respond.

There's no point in listening for a name if no one will ever us LLMNR 
to ask for it.

-josh