Subject: when to use LLMNR

From: Joshua Graessley <[email-masked]>
Date: Fri, 1 Nov 2002 15:08:10 -0800

I've read through the latest LLMNR draft and a few things are unclear 
to me.

In section 3, Usage Model, an implicit search order for unqualified 
names is given. This search order suggests appending the "current 
domain" and then querying for the unqualified name:

> [1]  Request the name with the current domain appended.
> [2]  Request just the name.

It goes on to say:

> The same host MAY use LLMNR queries for the resolution of unqualified 
> host names, and conventional DNS queries for resolution of other DNS 
> names.".

How does one discern the difference between an unqualified name and a 
top level domain name? If someone wants to query for "com", should that 
be sent using conventional DNS or LLMNR? Are we changing the semantics 
of the APIs to require all top level domains to be specified as a fully 
qualified name (i.e. "com." instead of "com")?

What is a "current domain". It is possible for a host to have multiple 
interfaces with separate configurations. Is the "current domain" a list 
of domains to be searched when an unqualified name is specified? This 
list can come from DHCP or be manually entered. If DHCPv4 and DHCPv6 
are in use, there could be conflicts? This is a little off topic, but 
the point is that a user may not have a lot of control over the domain 
names appended to unqualified names. At the very least, there are a lot 
of sources of a "current domain" or current domains.

It seems like the needs of multi-homed hosts are not fully covered by 
this draft. In section 3.1, "LLMNR configuration", the draft states:

> LLMNR usage can be configured manually or automatically.  On 
> interfaces where no manual or automatic DNS configuration has been 
> performed for a given protocol (IPv4 or IPv6), LLMNR SHOULD be enabled 
> for that protocol.

What does it mean to only enable LLMNR on an interface where no manual 
or automatic DNS configuration has been performed? DNS settings are not 
per-interface. When an API such as getaddrinfo is used, the client does 
not specify an interface. If a multi-homed host is connected to a 
configured network and an unconfigured network, it seems the desired 
behavior is nearly impossible to attain.

In section 6.2, Usage Restrictions:

> As noted in Section 3.1, LLMNR is intended for usage in scenarios where
> a DNS server is not configured.  If an interface has been configured 
> for
> a given protocol via any automatic configuration mechanism which is 
> able
> to supply DNS configuration information, then LLMNR SHOULD NOT be used
> on that interface for that protocol unless it has been explicitly
> enabled, whether via that mechanism or any other. This ensures that
> upgraded hosts do not change their default behavior, without requiring
> the source of the configuration information to be simultaneously
> updated.  This implies that on the interface, the host will neither
> listen on the LINKLOCAL multicast address, nor will it send queries to
> that address.

If a multi-homed host is connected to a configured network and an 
unconfigured network, it may want to perform LLMNR to find hosts on the 
unconfigured network. This conflicts with the security concerns that 
suggest LLMNR should not be used. It is unclear if LLMNR could be used 
in this case, but only for unqualified names. If LLMNR is supposed to 
be used only for unqualified names, how does one resolve conflicts 
between an unqualified name resolved via LLMNR and the fully qualified 
name created by appending the "current domain". This limits, in very 
difficult to guess ways, the names that could be used with LLMNR on the 
unconfigured link.

Example: My laptop has a wireless interface and an ethernet jack. I may 
have my ethernet jack connected to a network with a global IPv4 address 
and a DNS server both of which I received from a DHCP server. The DHCP 
server also told me that my current domain is "graessley.net". My 
wireless interface may be used only to connect to an 802.11 printer 
nearby. My printer may have a LLMNR name of "printer". Since I have a 
configured DNS server and a current domain, my resolver library will 
probably query "printer.graessley.net" before trying "printer". This 
makes it impossible to find my printer by name. It is unclear what 
names I could use for the printer. Any host that connects wirelessly to 
my printer may search any number of other domains if the host is also 
connected to another network.

What am I overlooking?

-josh

--
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: Derek Atkins <[email-masked]>
Date: 01 Nov 2002 18:17:20 -0500

> How does one discern the difference between an unqualified name and a

Qualified names end with a ".", i.e. "com." or "org." or "." (for the root).
Unqualified names do NOT end with a .

Note, however, this this is irrelevant.  LLMNR is just another
naming service, different from DNS as much as NIS/YP is diferent
from DNS, which is just as different as /etc/hosts.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 3 Nov 2002 19:59:10 +0100 (CET)

> from DNS, which is just as different as /etc/hosts.

Actually, IMHO *more* different than NIS/YP and /etc/hosts.

For different naming services there is typically an administrator
who is trying to prevent inconsistencies between the answers
from the the different naming services. In some cases one naming
service might contain a subset of another, but I don't know of
a case where one naming service explicitly contains inconsistent
information for the same name as another naming service.

With LLMNR the operational use might cause inconsistent
information by design, where www.<localdomain> can be 
effectively advertised by anybody using LLMNR and be different 
than the "managed" name service information for that name.

  Erik