Subject: RE: LLMNR Issue 3

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

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