Subject: Re: LLMNR Issue 3

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 Apr 2003 10:38:09 -0700 (PDT)

On Thu, 10 April 2003, Joshua Graessley said:

"Unless I'm mistaken, domains in the search list are appended to
unqualified names only if an attempt to resolve the unqualified name
fails. A resolver attempting to resolve "ietf.org" would try to resolve
"ietf.org." first. Since "ietf.org." doesn't end in "local.arpa." LLMNR
would not be used if there is a DNS server configured. Even if someone
were respoding to "ietf.org.local.arpa." using LLMNR, it is unlikely
they would receive any queries for that name."

The problem is that in practice attempts to resolve names fail
a significant portion of the time, even when the DNS server is up
and the RR exists. So once the attempt to resolve "ietf.org" fails,
an attempt will be made to resolve "ietf.org.local.arpa".

[The searchlist] "is an optional knob. The default behavior could work
well enough that you don't have to add local.arpa to the search list
unless you really wanted to. You could resolve LLMNR names by appending
local.arpa yourself. You can resolve any name without editing or even
having a search list. Search lists are just a convenience for people who
type a lot of names in a few domains often."

Unless "local.arpa" were in the searchlist, if conventional
DNS were to fail, as it does in practice, then it would not be
possible to resolve a non "local.arpa" FQDN on the local link. So either
the searchlist entry is present and things "just work" or it is not
present and they break. In any case, the same behavior is exhibited
depending on whether LLMNR is used as a fallback name resolution mechanism
or not.

"If the name does exist in the DNS
namespace, someone with access to a DNS server may be unable to use
LLMNR to find me. If there is a specific domain for LLMNR names, the
domain can be used to specify that the name should be resolved using
LLMNR. People who don't have authority over any domain will still have
a way to use LLMNR. Names in that domain will have certain properties.
They won't be globally unique, they will be unique only on the local
link. This would give me the freedom to pick any LLMNR name. The
protocol can detect a conflict and notify me, at which time I can pick
a new unique name or maybe my LLMNR responder could automatically
generate a unique name."

Wouldn't use of unqualified names with fallback provide the same benefit?
"Bob" isn't registered in the DNS, so a host can choose that name, and
it can be resolved via LLMNR. I'm not sure why the name has to
be uniquely tied to a particular name resolution mechanism.

--
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: Joshua Graessley <[email-masked]>
Date: Thu, 17 Apr 2003 10:29:03 -0700

> an attempt will be made to resolve "ietf.org.local.arpa".

I think we've gone in a circle. One of the problems with LLMNR is that 
it is unclear when LLMNR should be used to resolve a name. Should DNS 
or LLMNR come first? We don't want to make it really easy to spoof 
ietf.org, so must only use LLMNR when either there is no DNS server or 
the query fails. I believe we can make this work better by having a 
domain for which LLMNR is authoritative. Any queries in this domain a 
resolved using LLMNR only. You point out that if someone adds that 
domain to their search list, then a query for ietf.org.local.arpa. will 
occur of the query for ietf.org. fails. Is this any different from the 
case where the query for ietf.org fails in DNS and we fall back to 
using LLMNR?

> depending on whether LLMNR is used as a fallback name resolution 

I would not expect a FQDN to work if DNS was flaky. In the example 
we've been using, I would never expect that if my DNS server is not 
working, I could use LLMNR to get the address of ietf.org. It is 
unlikely I will ever be on the same local link as any of the IETF 
servers.

> be uniquely tied to a particular name resolution mechanism.

tv is. I can't give my television the name tv? Based on the 
implementations I've seen, most resolvers would try a query for bob. 
Bob would be sent off to the DNS code. The DNS code would append 
domains in the search list if bob failed to resolve. Before bob would 
ever be tried with LLMNR, DNS would be used for bob and bob followed by 
all of the names in the search domains list.

If the resolver libraries were changed, there would still be problems. 
If someone knew that I commonly use a server named zaphod.apple.com, 
but I was lazy and typed zaphod, relying on the search domains to do 
the right thing, they could easily spoof zaphod. If the use of LLMNR is 
triggered by the domain, the search list can actually be used to 
specify an order in which LLMNR is used for unqualified names. By 
default, the LLMNR domain shouldn't be in the list so LLMNR would not 
be used unless someone typed a name ending in the LLMNR domain.

-josh