Subject: LLMNR Issue 3

From: Rob Austein <[email-masked]>
Date: Sat, 05 Apr 2003 14:13:40 -0500

Please forgive me if I'm confused on the LLMNR issue resolution
protocol, I didn't see an obvious thread on which to follow up on the
proposed resolution to issue #3.

I have some reservations about the solution proposed for LLMNR issue
#3, and while I won't stand in the way, I thought I should explain my
reservations, since I think they expose a split between two
fundamentally different usage models.

The scenario we discussed at the IETF 56 DNSEXT meeting (two laptops
on an ad hoc network, each laptop knows its own FQDN) is the result of
how I think about naming machines.  My laptop's name is the same no
matter where my laptop goes, and to me the whole FQDN is the laptop's
name, not just the leftmost label, because the FQDN is unambiguous.
Because of this, the proposed resolution to issue #3 seems bizzare to
me: here I have a machine that has a perfectly good unambiguous name,
but the protocol won't let me use it, and instead forces me to cons up
a potentially ambiguous name.

I realize that there are operating systems and networks that operate
on the model that only the leftmost label is the host's business, and
everything else is imposed by the local environment, but I don't
operate that way (and yes, my laptop's DHCP client is configured to
override most of the DNS-related information that might come from the
local environment).

So it seems to me that this proposed resolution is somewhat biased in
favor of a particular model for ad-hoc networks at the expense of
other (perhaps better) models, and increases the likelyhood of name
colisions by forcing users who can supply unambiguous names to use
potentially ambiguous names instead.

--
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: Ted Lemon <[email-masked]>
Date: Sat, 5 Apr 2003 14:52:14 -0600

> a potentially ambiguous name.

You're right.   It is bizarre.   It's there for a good reason, which is 
that Joe Average doesn't think his laptop is called 
"joeaverage.myispsdomain.com".   He thinks it's called "joeaverage".   
So if you want Joe Average to be able to exchange data with Jane 
Average (assuming that Jane Average also doesn't think of her laptop as 
having an FQDN) when they meet in a coffee shop to talk about their 
homework, and Joe and Jane average do not use the same ISP, the only 
name that either one of them has a chance of coming up with is 
"joeaverage" or "janeaverage."

I think this falls apart if you think about it a bit, though - chances 
are that Joe and Jane don't even think of their computers as 
"joeaverage" and "janeaverage" - they think of them as "my computer".   
So the only chance Joe and Jane really have of exchanging data is if 
they see a menu with a name that looks right, like "Joe's Computer".   
They're just not going to be able to come up with a name for each 
other's computer otherwise.   So you might as well use an fqdn.

This brings us to the next problem, which is that neither Joe nor Jane 
are likely to have a reasonable basis for assigning an FQDN to their 
computer right now.   For a computer to have an FQDN, it has to have a 
name registered in the DNS.   Any other definition of "having an FQDN" 
is meaningless (correct me if I am wrong).   Neither Joe nor Jane have 
any idea that their computers ought to have FQDNs, and neither Joe nor 
Jane would have any idea how to get their computers' name registered in 
the DNS even if they realized that it would be useful to do so.   So 
for Joe and Jane, it's necessary that LLMNR allow their computers to 
have names without requiring them to go through the process of 
registering FQDNs for their computers.

This gets even more complicated because Joe and Jane's laptops, being 
portable, may very well switch FQDNs as they move from site to site.   
It's quite likely that both laptops do DHCP from time to time, either 
when they're connecting at home or at work.   It's also likely that 
their respective DHCP servers sometimes assign FQDNs to their laptops, 
unbeknownst to them.   It is extremely unlikely that Joe or Jane will 
be aware of this, and so if their laptops use those names--and only 
those names--in LLMNR, Joe and Jane won't be able to identify their 
laptops.

So I would say that it's fine for your computer to claim it's 
sra-vroom.hactrn.net using LLMNR, as long as Joe and Jane's computers, 
which haven't been explicitly configured with FQDNs, but may have been 
dynamically configured with FQDNs, don't do so.   And if we have to 
pick one or the other behavior as the default, the behavior should 
favor Joe and Jane, because unlike you, they are not prepared to defend 
themselves from misconfiguration.

I should point out that neither Joe nor Jane need be dunces in this 
scenario - they just aren't networking geeks, and don't want to be 
forced to be.   Also, I am making no assertions about whether or not 
Joe and Jane are a couple; this scenario works with all configurations 
of Joe and Jane, and also with Joe and Dave, and with Jane and Rebecca, 
and so on.   :')

---

From: Bill Manning <[email-masked]>
Date: Sun, 6 Apr 2003 09:18:11 -0700 (PDT)

% > The scenario we discussed at the IETF 56 DNSEXT meeting (two laptops
% > on an ad hoc network, each laptop knows its own FQDN) is the result of
% > how I think about naming machines.  My laptop's name is the same no
% > matter where my laptop goes, and to me the whole FQDN is the laptop's
% > name, not just the leftmost label, because the FQDN is unambiguous.
% > Because of this, the proposed resolution to issue #3 seems bizzare to
% > me: here I have a machine that has a perfectly good unambiguous name,
% > but the protocol won't let me use it, and instead forces me to cons up
% > a potentially ambiguous name.

	amen.  thats why the TBDS project chose to key off the FQDN for
	its version of mDNS.

% "joeaverage" and "janeaverage" - they think of them as "my computer".   
% So the only chance Joe and Jane really have of exchanging data is if 
% they see a menu with a name that looks right, like "Joe's Computer".   
% They're just not going to be able to come up with a name for each 
% other's computer otherwise.   So you might as well use an fqdn.

	yup.

% 
% This brings us to the next problem, which is that neither Joe nor Jane 
% are likely to have a reasonable basis for assigning an FQDN to their 
% computer right now.   For a computer to have an FQDN, it has to have a 
% name registered in the DNS.   Any other definition of "having an FQDN" 
% is meaningless (correct me if I am wrong).   Neither Joe nor Jane have 
% any idea that their computers ought to have FQDNs, and neither Joe nor 
% Jane would have any idea how to get their computers' name registered in 
% the DNS even if they realized that it would be useful to do so.   So 
% for Joe and Jane, it's necessary that LLMNR allow their computers to 
% have names without requiring them to go through the process of 
% registering FQDNs for their computers.
% 
% This gets even more complicated because Joe and Jane's laptops, being 
% portable, may very well switch FQDNs as they move from site to site.   
% It's quite likely that both laptops do DHCP from time to time, either 
% when they're connecting at home or at work.   It's also likely that 
% their respective DHCP servers sometimes assign FQDNs to their laptops, 
% unbeknownst to them.   It is extremely unlikely that Joe or Jane will 
% be aware of this, and so if their laptops use those names--and only 
% those names--in LLMNR, Joe and Jane won't be able to identify their 
% laptops.

	perhaps. but there  is the disticntion of where your computer is
	vs who named it.  Joe and Jane likely have Internet access.
	They buy that access from someone.  perhaps [email-masked]
	and [email-masked]  it would seem to not bee too much of a reach to
	presume that bbss and aol will tag the connecting machines of their
	customerss with a name - perhaps joe-pc.aol.com and jane-pda.bbss.net
	and assign credentials to them.... volia, FQDNs.

	Now when joe and jane meet at the StarBucks in Memphis, they get
	new IP addresses but their FQDNs stay the same as their creds... case closed.

% 
% So I would say that it's fine for your computer to claim it's 
% sra-vroom.hactrn.net using LLMNR, as long as Joe and Jane's computers, 
% which haven't been explicitly configured with FQDNs, but may have been 
% dynamically configured with FQDNs, don't do so.   And if we have to 
% pick one or the other behavior as the default, the behavior should 
% favor Joe and Jane, because unlike you, they are not prepared to defend 
% themselves from misconfiguration.
% 
% I should point out that neither Joe nor Jane need be dunces in this 
% scenario - they just aren't networking geeks, and don't want to be 
% forced to be.   Also, I am making no assertions about whether or not 
% Joe and Jane are a couple; this scenario works with all configurations 
% of Joe and Jane, and also with Joe and Dave, and with Jane and Rebecca, 
% and so on.   :')
% 
% 
% --
% 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/>
% 

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Paul Vixie <[email-masked]>
Date: Sun, 06 Apr 2003 17:45:28 +0000

i've just got to beg to differ.

if joe and jane meet in a coffee shop and, via some combination of an
apple-style "chooser" and bluetooth or 802.11 or irda or null-ether cable
see each other at all, then it's probably adequate for them to see rfc1918
ipv4 addresses or link-local ipv6 addresses (or both).  names are a nicety
but one which the palm-beamers seem to do perfectly well without, most of
the time (since most palm owners don't ever name their pda's.)

the more interesting question is: what if it's 802.11 and a large network,
such as an internet cafe.  in that case, one would immediately say that
ip addresses weren't useful since there would be so many of them.  (when
there's only one, it's safe most of the time to assume you know who it is;
when there's a lot more than one, you just don't know who's who.)  but if
we take this one step further, unqualified names don't help.  on a large
network like an 802.11 internet cafe, there's going to be more than one
jane and probably more than one joe.

the cases where the connectivity is limited to small numbers of other-ends
are such that ip addresses (or names like "other end of null-ether cable")
are good enough.

the cases where the connectivity is not so limited are such that only fully
qualified and "universal" names are good enough.

and in either case, higher level security like certificates ought to be used,
since neither ip addresses nor universal fully qualified domain names are
appropriate for either authentication or authorization.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 6 Apr 2003 12:41:34 -0500

> 	and assign credentials to them.... volia, FQDNs.

Um, Joe and Jane don't know from FQDNs.   And they may use their 
laptops in more places than just home and Starbucks.   So it's entirely 
possible that their laptops have more than one FQDN that could be 
thought of as "the laptop's FQDN."   And then they will see 
inconsistent behavior when they visit Starbucks.   Sometimes 
joe-pc.aol.com will be Joe's laptop's FQDN, and sometimes it'll be 
joe-pc.megacorp-example.com.   Joe and Jane aren't going to be able to 
predict that.

Joe and Jane will learn about FQDNs only when it's to their advantage 
to do so.   I'm not saying that can't happen.   But right now it's not 
particularly to their advantage, so chances are they don't know about 
them.   Joe and Jane think of FQDNs as things that start with www, smtp 
or pop, that only servers have.

I'm all in favor of changing this - in fact, I'm working to change it - 
but I don't think that the design of a protocol should be predicated on 
the success of my efforts.

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 7 Apr 2003 18:09:29 -0700

We have a tension between two requirements:

1) Enable rob.example.net to discover randy.other-example.org on the
same link;

2) Avoid making it too easy for a hacker to spoof
"www.something-important.com" by convincing the host to send an LLMNR
query and then feeding the right answer.

The last-last draft (16) proposes the following:

[1] If a DNS query does not receive a response, prior to falling
    back to LLMNR, the query SHOULD be retransmitted at least
    once.

[2] A sender SHOULD send LLMNR queries only for names that are
    either unqualified or exist within the default domain.

[3] A responder with both link-local and routable addresses
    MUST respond to LLMNR queries for A/AAAA RRs only with
    routable address(es).  This encourages use of routable
    address(es) for establishment of new connections.

[4] A sender SHOULD only send LLMNR queries for PTR RRs
    that represent addresses reachable through the link
    over which LLMNR is used.

Recommendation [2] will effectively prevent the rob/randy scenario. The
root of the issue is that there is not necessarily a "default domain"
for a given link -- e.g. a corporate laptop visiting a home network
keeps its corporate name. The recommendation [2] is thus difficult to
implement. 

-- Christian Huitema

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 8 Apr 2003 09:26:43 +0200 (CEST)

> query and then feeding the right answer.

This tension is caused by the desire to have the same API do DNS and LLMNR
lookups with some form of automatic fallback.
What you propose might be the best compromise in that case.

But there is an option to allow an explicit user interface knob
to say "always use LLMNR, always use DNS, first DNS than LLMNR"
and have different rules in the 3 cases.
In the first case, when the user has explicitly told the system to use LLMNR
for everything, then LLMNR should be able to lookup any names I think.

  Erik

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 9 Apr 2003 11:10:39 -0700

> for everything, then LLMNR should be able to lookup any names I think.

A knob is often a bad thing. It's an acknowledgment that there is no 
good solution so the user should research the options and come to their 
own conclusion about what will work best. I would not want to always 
use LLMNR first or even simultaneously with DNS. I don't want to make 
it easier for someone to spoof my mail server, or the AIM server, or 
any of the other number of services that are totally insecure that I 
make use of on a daily basis.

The solution to this problem lies in LLMNR issue 22 (Bring back 
"local.arpa"). That issue has been rejected. Unless that issue is going 
to be reopened, it seems the obvious answer is that DNS should be used 
before LLMNR to avoid the security problems. This makes LLMNR useful 
only in the case where a device does not have a configured DNS server 
or for names that do not exist in the DNS namespace. This is a pity 
since multi-homed devices are so common these days. This severely 
(perhaps fatally) limits the usefulness of LLMNR. This limitation and 
the question of what name to use will likely limit LLMNR to hobbyists 
and experts.

Since LLMNR issue 22 has been rejected, read no further.

The problem you're trying to address is the reason that Apple is using 
a special domain to denote names that should always be resolved using a 
specific non DNS method. Dynamic DNS update is nice, but few people use 
it. This usually means that a laptop can have many names throughout the 
period of a day. When I'm at work, my laptop is graejo5.apple.com.. 
When I'm at home, my laptop is 
adsl-64-171-18-123.dsl.sntc01.pacbell.net.. If I had dynamic DNS setup, 
I could potentially have something like joshs-tibook.graessley.com. 
always point to whatever IP address is currently assigned to my laptop. 
I don't have that setup and neither does the average person.

If I meet someone else at an airport or at someone's house where I'm 
assigned a NAT address, I would like an easy way to connect to their 
machine by name. In both of these cases, I have a configured DNS 
server. I have no idea what name the other machine has. If my friend 
has dynamic DNS enabled, he might have a useful name that could be up 
to date. If we're both behind the same NAT, we should have no trouble 
communicating, but my friend should not use the NAT address when 
updating the DNS record for their name. Yes, NAT is evil, but we can't 
just bury our heads in the sand and ignore the problem.

By carving off a domain such as "local.arpa." and making LLMNR the 
authority of that domain, you solve two problems. You can make it very 
clear when LLMNR should be used (LLMNR issue 3), if the fully qualified 
name ends in "local.arpa.", use LLMNR. You also give people a domain 
they can use a name in. Not everyone owns a domain they can assign 
names from. Most ISPs certainly don't assign your computer a name, they 
assign a name to the IP address that you are assigned. Your IP address 
often changes, so that name often changes.

The use of the "local.arpa." domain also solves some serious 
multihoming problems. With multihoming, there is a possibility that one 
interface will be attached to a configured network and one interface 
will be attached to an ad-hoc network. In such a scenario, the device 
connected to both networks will be unable to use LLMNR to resolve names 
on the ad-hoc network. The queries would be sent to DNS first. By 
specifying a domain such as local.arpa. to indicate queries should be 
sent using LLMNR, we can handle the multi-homed case. The multi-homed 
devices sends queries ending in local.arpa. to LLMNR and all other 
queries to DNS. We don't have the potential security problem of sending 
queries for www.ietf.org to LLMNR but we get the benefit of being able 
to resolve, using LLMNR, the names of the devices on the ad-hoc network.

-josh

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 10 Apr 2003 10:40:08 -0700 (PDT)

Joshua Graessley writes:

"I would not want to always
use LLMNR first or even simultaneously with DNS. I don't want to make
it easier for someone to spoof my mail server, or the AIM server, or
any of the other number of services that are totally insecure that I
make use of on a daily basis."

This is certainly a concern. While both unicast and multicast name
resolution is vulnerable to spoofing without DNS security, the thinking is
that LLMNR is even easier because you don't even have to write any
software to do it, just misconfigure your machine. Also, DNS security
seems difficult to deploy with protocols such as LLMNR. So the argument is
that even though both usages are vulnerable today, LLMNR is likely to
remain vulnerable, no matter how DNS security were to advance.

"The solution to this problem lies in LLMNR issue 22 (Bring back
"local.arpa")."

I guess I'm missing how "local.arpa" addresses the spoofing issue. Is this
because instead of spoofing ietf.org, the attacker now has to spoof
ietf.org.local.arpa? Or is the "security" provided by this due to only
using linklocal name resolution to resolve unqualified names
(foo.local.arpa)? In that case, why wouldn't the same scope restriction
in LLMNR provide equivalent security?

"You can make it very clear when LLMNR should be used (LLMNR issue 3),
if the fully qualified name ends in "local.arpa.", use LLMNR."

Actually, this just adds another "knob to configure" -- the search list.

"You also give people a domain they can use a name in."

Since this is a flat name space, that doesn't address the issue of name
conflicts. There will be as many "bob.local.arpa" hosts as "bob" hosts.

"When I'm at work, my laptop is graejo5.apple.com.
When I'm at home, my laptop is
adsl-64-171-18-123.dsl.sntc01.pacbell.net."

Depends on whether your host allows DHCP to assign the name or not. If
not, your laptop might remain graejo5.apple.com while a PTR RR query for
your IP address might return adsl-64-171-18-123.dsl.sntc01.pacbell.net
from the DNS server, and graejo5.apple.com if handled via LLMNR.

In any case, I'm not sure how "local.arpa" helps this situation. Does
someone at the airport connect to your machine as
"graejo5.apple.com.local.arpa"? "graejo5.local.arpa"? Or some other name?

"If I meet someone else at an airport or at someone's house where I'm
assigned a NAT address, I would like an easy way to connect to their
machine by name. In both of these cases, I have a configured DNS
server. I have no idea what name the other machine has."

This doesn't sound like a problem that requires a name resolution solution
to me. It has been pointed out by Erik Guttman that if what is actually
needed to solve this is to discover the hosts and corresponding services
on the local link, as well as their attributes, which could include a
"friendly name". That way you don't have to know what the name is -- which
is a problem whether you're using "local.arpa" or not.

"there is a possibility that one
interface will be attached to a configured network and one interface
will be attached to an ad-hoc network. In such a scenario, the device
connected to both networks will be unable to use LLMNR to resolve names
on the ad-hoc network."

I don't think this is true. It might attempt to do a DNS query first, but
presumably this will fail and an LLMNR query will go out, potentially on
both interfaces.

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 10 Apr 2003 13:10:27 -0700

> in LLMNR provide equivalent security?

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.

> Actually, this just adds another "knob to configure" -- the search 

It 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.

> conflicts. There will be as many "bob.local.arpa" hosts as "bob" hosts.

Detecting and handling conflicts is not an impossible task. Creating an 
appropriate user experience to properly handle and notify someone of a 
conflict can be tricky.

> "graejo5.apple.com.local.arpa"? "graejo5.local.arpa"? Or some other 

I don't own the domain apple.com. I can't just pick any name in that 
domain. That domain is handled by an administrator at Apple. I don't 
own the dsl.sntc01.pacbell.net domain either. Come to think of it, I 
don't really own any domain. What name should I pick? How do I go about 
picking one? How do I make sure that it won't conflict with a name 
somewhere in the DNS namespace? 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.

> is a problem whether you're using "local.arpa" or not.

Service discovery is ideal but there are many tools that exist today 
that could make use of LLMNR. For example, my ssh client doesn't know 
about any service discovery mechanisms. The ability to use a name 
instead of addresses with an ssh client is very desirable. The same is 
true of a web browser. Few web browsers support any service discovery 
mechanisms. The ability to use a name instead of an address when typing 
in a URL for my buddies machine is very useful. Such a name would 
continue to work even if the network topology changes, as long as my 
buddy and I are still on the same local network and our names don't 
conflict with other names on that network.

-josh

---

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

---

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