Subject: Proposed Resolution to LLMNR Issue #1

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Mar 2003 09:36:47 -0800 (PST)

Issue 1: Multihomed hosts
Submitter: Joshua Graessley
Submitter email address: [email-masked]
Date first submitted: November 1, 2002
Reference: <[email-masked]>
Document: LLMNR-12
Comment type: T
Priority: S
Section: 6.2
Rationale/Explanation of issue:

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

[BA] I agree that the situation you present is problematic.
Below is a proposed resolution.

Change section 3.1 to the following:

"3.1. Unqualified names

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

If a name is not qualified and does not end in a trailing dot, for the
purposes of LLMNR, the implicit search order is as follows:

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

This is the behavior suggested by [RFC1536]. LLMNR uses this technique
to resolve unqualified host names."

--
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/>