Subject: RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard

From: "Christian Huitema" <[email-masked]>
Date: Mon, 5 Sep 2005 01:45:03 -0700

> My greatest concern is that the document as it stands is likely to
> cause a large number of bogus DNS queries.  If the protocol is widely
> adopted, it seems probable that many clients will have LLMNR enabled
> on an interface in a situation where a DNS server has been configured
> (as described in section 2).  In that case, every LLMNR query will
> entail (possibly more than) one DNS query, because of the provision,
> "All attempts to resolve the name via DNS on all interfaces have
> failed after exhausting the searchlist."  Such DNS queries will become
> commonplace if the protocol is widely adopted and widely used.  This
> feature of the design appears to increase the burden on the entire
> Internet infrastructure in order to support unshared infrastructure.

Uh, no. 

LLMNR does not create additional DNS queries. Applications do not issue
LLMNR requests, they issue name resolution requests. When a name
resolution request is issued, the current behavior is to submit the
request to the DNS, possibly applying a "search list". LLMNR does not
change that. LLMNR adds an additional transaction at the end of the
search list, falling back to local multicast resolution if the
infrastructure could not resolve the query authoritatively.

The part about multiple interfaces is also the current behavior in
multi-homed hosts. In theory, DNS requests sent to different servers
over different interfaces should all be equivalent. In practice, they
are not. Some names can be resolved through some interfaces, and not
through others. To be sure, systems end up sending the requests on
multiple interfaces.

-- Christian Huitema

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Pekka Savola <[email-masked]>
Date: Mon, 5 Sep 2005 12:29:04 +0300 (EEST)

On Mon, 5 Sep 2005, Christian Huitema wrote:
> LLMNR does not create additional DNS queries.

In itself, it does not.  But the operational practises it promotes 
very probably cause a significant increase to the number of bogus 
FQDN's people use, and thus have an impact on the queries to the root.

As it is, in the general case, folks either don't use hostnames like 
"anotherbox.somebogusdomain." in applications or they actually have a 
DNS server which is authoritative for that zone.  That is, users often 
do configure bogus things like that for host names, but because the 
lookups don't work unless they actually have the DNS server, such use 
is limited.  With LLMNR, such use but without the DNS server would 
become commonplace.

On the other hand, if you have DNS server, it might be ~OK -- there 
aren't additional queries to the root server under normal 
circumstances.  (If a host moves off-link the queries typically end up 
in the root though.)

However, as folks have pointed out, having a lookup mechanism which 
can also use real FQDN's has benefits compared to just restricting to 
.local.  The more difficult problem is being able to separate "really 
owned FQDN" from "invented, bogus FQDN"... while not making the 
problem worse by creating even more DNS traffic.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 05 Sep 2005 11:38:28 +0200

> > Internet infrastructure in order to support unshared infrastructure.

Christian,
I am not sure I understand you correctly. What Andrew fears, if I am 
correct, is an increase of the number of resolution requests. I feel 
you answer on the number of DNS querries per resolution request?

I would be interested in better understanding the details of the 
Windows mechanism: where to best find it described? It could be used 
for similar needs (registry distribution) I work on. I understand 
that what you name the "search list" is Hosts.txt? and that the idea 
is to either add a smarter database or a broadcast t querry to 
complete the local Host.txt service? However I fail to see what this 
really brings that a local dynamic name server would not provide with 
more security and services?

thank you
jfc

---

From: Peter Dambier <[email-masked]>
Date: Mon, 05 Sep 2005 13:19:39 +0200

JFC (Jefsey) Morfin wrote:
> correct, is an increase of the number of resolution requests. I feel you 
> answer on the number of DNS querries per resolution request?
> 
> I would be interested in better understanding the details of the Windows 
> mechanism: where to best find it described? It could be used for similar 
> needs (registry distribution) I work on. I understand that what you name 
> the "search list" is Hosts.txt? and that the idea is to either add a 
> smarter database or a broadcast t querry to complete the local Host.txt 
> service? However I fail to see what this really brings that a local 
> dynamic name server would not provide with more security and services?
> 
> thank you
> jfc
> 
> 
> 
> 

Can I translate this:
    A gun does not kill anybody. It is the mafia employee how does ...

An application using LLMNR does create additional DNS queries.

Well, no it doesnot. It asks the resolver to do it.

Asking the resolver for "gurgleblaster.bar.com" is dangerous. There
might be a record "*.bar.com 24.24.24.24". So you get the answer
24.24.24.24 and your host gurgleblaster.bar.com on ip 169.254.11.12
will never be looked up via LLMNR. So using other domains than
".local" does not make sense.

Asking the resolver for "gurgleblaster.local" will ask my resolver
to ask my ISPs resolver to ask all 13 root-servers about
"gurgleblaster.local" because none of them will find it, probably
more than once.

Oh, yes LLMNR will never ask anything from the root-server. Only
the applications using it will.

That is disgusting!

-- 
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [email-masked]
http://iason.site.voila.fr
http://www.kokoom.com/iason

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 05 Sep 2005 13:36:17 +0200

At 11:29 05/09/2005, Pekka Savola wrote:
>can also use real FQDN's has benefits compared to just restricting 
>to .local.  The more difficult problem is being able to separate 
>"really owned FQDN" from "invented, bogus FQDN"... while not making 
>the problem worse by creating even more DNS traffic.

This mechanism would work on a list of TLDs to compare with. May be 
the proper place to introduce a full TLD service where a istld(tld) 
function would return a null string if it did not exist and the 
proper tld to use otherwise. This would enforce a strict TLD aliasing 
able to support an internationalised version of the existing TLDs for 
full ML.ML names.

That function could be extended to isdn(dn.tld) where the dn could be 
nullified if it did use only characters from the TLD associated 
charset. This would address the homograph problem, since TLD Managers 
can decide of their TLD charsets, but cannot impose them beyond their 
own registration level.

jfc

---

From: Markku Savela <[email-masked]>
Date: Mon, 5 Sep 2005 15:02:14 +0300

LLMNR does create extra queries to root servers. Lets say I have named
my local devices in LLMNR as

 "fridge"
 "tv"
 "vcr"
 "myserver"

Now, every time, when some application wants to contact those devices,
it does a normal getbyname using one of the names.

Because there is only one network in my home, the internet gateway is
on the same link and has also global DNS enabled. By LLMNR definion,
the "getbyname" first tries to resolve those names from the global
DNS. Thus for "vcr", we get query to root servers for "vcr", etc.

Now, imagine every household or mobile phone doing the same...

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 05 Sep 2005 14:21:30 +0200

> my local devices in LLMNR as

Which would be easily "solved" for both mDNS (when not restricting
to .local) by first asking the local network using mDNS/LLMNR and then
asking DNS. Which takes away the worry of flooding (root) dns servers.
(Misconfigured machines are a bigger problem there)

This has a *huge* security issue of course when some one starts replying
to all those queries with false data (www.paypal.com anyone?, or
responding for www.ietf.org and putting all kind of naughty words in the
drafts ;)

Then again, hosts on the local network can already easily respond to
normal DNS queries too by flooding the switch with MAC addresses,
putting it into broadcast mode and then simply responding to queries. Of
course one will then get some dupes back from the original one which
will make things a bit confusing, but most resolvers don't care about
those and simply ignore them anyway (afaik). I guess we want DNSSec
here, but that was the whole point -> zeroconf...

That said, it would be really good if both mDNS/LLMNR had a 'off'
switch. When a real DNS server responds then we have a working DNS
server, with mDNS/LLMNR being targetted at zero-conf networks,
apparently, as we have DNS, these networks are configured, they have a
working DNS server, thus mDNS/LLMNR is not required. Folks can then use
DDNS and other methods for registering names.

Another thing one could do then is have a real DNS server respond
directly to these mDNS/LLMNR queries, which avoids one to even configure
a DNS server.

Greets,
 Jeroen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 5 Sep 2005 22:09:10 +0200

> asking DNS.

Oh yes, that would be fun. Consider the case of a WLAN an an IETF  
meeting where many hundreds of people are on the same wireless  
network. Any and all multicast must be transmitted by all access  
points at a very conservative speed to be reasonably sure everyone  
hears them. Typical multicast speed is 1 Mbps, so even if everyone  
does a few name lookups per minute this is enough to use up a  
significant part of the available wireless bandwidth.

> This has a *huge* security issue of course

That too.

This discussion (as a whole, not your particular contribution) makes  
it very clear that the issues aren't understood very well at this time.

For instance, the assumption right now is that if a client wants to  
know something, it multicasts the query and the party in the know  
answers, the same as ARP has been doing for decades (well, at least  
LLMNR doesn't suggest the use of broadcasts... thank the deity of  
your choice for small favors).

However, that is far from the only possible model. A different one,  
that should scale a lot better, is one where hosts register their  
information when they join the link.

> normal DNS queries too by flooding the switch with MAC addresses,

Ethernet switching is a dirty hack that can't die fast enough. But  
unfortunately nobody cares enough to build new and better link  
technologies. That aside, with additional hacks you can make all this  
as bullitproof as you feel like making it, so there is no need to  
assume the link layer is always unsafe, although it often is, of course.

> DDNS and other methods for registering names.

Way too simple. If I'm a simple home user and all my machines point  
to my ISP's DNS servers, I do have DNS for global names, but there is  
no chance I'll get to register all my appliances in the global DNS.  
So for those people that aren't capable of running their own DNS,  
there is certainly a use case for both local and global names side by  
side.

Coming back to the inital list of names: the .local. trick got some  
bad press here, undeservedly so, IMO. If you name your mDNS capable  
stuff "fridge", "tv" etc. then you'll see that the .local. part is  
added automatically, nicely avoiding most namespace confusion. (In  
some cases you need to add .local. manually, especially when using  
lower-level tools.)

My conclusion: we don't know what problem we want to solve, the  
solution space hasn't been explored fully, and the security issues  
have been largely ignored.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 06 Sep 2005 01:48:39 +0200

>  So for those people that aren't capable of running their own DNS,

I agree with everything you say. But with this one. I think the 
problem is there is no free Linux/Windows nameserver with a smart 
enough control panel for everyone being able to run their own DNS. 
May be a project to dig into rather than to endanger the DNS?
jfc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 6 Sep 2005 10:12:37 +0200

> May be a project to dig into rather than to endanger the DNS?

It would be an interesting experiment to make an easy-to-use DNS  
implementation for local use that runs on a residential gateway. But  
to be part of the global DNS requires delegation pointers from  
elsewhere, and most residential/SOHO users don't have addresses that  
are stable enough to make this usable. This may change with IPv6,  
though.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 06 Sep 2005 10:51:18 +0200

Iljitsch van Beijnum wrote:
> implementation for local use that runs on a residential gateway. But  to
> be part of the global DNS requires delegation pointers from  elsewhere,
> and most residential/SOHO users don't have addresses that  are stable
> enough to make this usable. This may change with IPv6,  though.

Quite frankly the mechanisms between registry, domain owner, and service
provider suck rocks.  Think about what has to happen on just the
following three cases:

 - new customer, new domain
 Customer has to register domain, provide that name to the ISP, and
 have the ISP either list all hosts or delegate back to the customer
 name servers for reverse lookup.

 - new customer, old domain
 Customer has to change name servers by contacting registry and
 repeat reverse lookup steps

 - same customer, same domain, ISP renumbers
 ISP has to delegate addresses down to customer (a'la prefix
 delegation) and customer must then contact registry.

I've simplified the renumbering steps as many will note, but still
this shouldn't be hopeless.  I just don't see any interest in actually
fixing the problem.

Eliot

---

From: Marc Manthey <[email-masked]>
Date: Tue, 6 Sep 2005 11:51:15 +0200

>> enough to make this usable. This may change with IPv6,  though.

sure ,  i heard that there is  a mobile implementation arround

adrian did a great job

http://www.ag-projects.com/docs/Present/ETSI-20041130.pdf

regards

-- 
  "When it's not necessary to do something,
    it's becomes necessary NOT to do it."

Les Enfants Terribles
www.let.de

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 06 Sep 2005 12:41:46 +0200

>are stable enough to make this usable. This may change with IPv6,

I am afraid not. The real digital divide is between those who can be 
called and those who cannot by lack of money for an IP address (the 
cost of an IPv6 address is also the software change, education, 
missing user tools). This results from an old and costly model (RIRs) 
rather than using a network model (like telephone). This was needed 
in a deployment period, this is a blocking factor for a mature global 
network continuity.

It is a real shame that the entire world has E.164 numbers, with 
billions of people paying them every month, using every days, 
possibly keeping them all their life long, using them for the 
telephone, as customer ID, when they want to be differentiate from 
homonyms in databases, etc. and they cannot use on the  ... modern 
... Internet. By the ITU or by the RIRs, what is the problem to have 
an IPv6 plan made of a leading byte+telephone number?  What is the 
problem of entering a telephone number in a browser and to access the 
corresponding byte+telnr IPv6 address?

In the meanwhile is there an impossibility to think of small 
softwares acting as a local name server and as an external resolver. 
Is there a major problem in having the IP addresses managed 
dynamically (mobile systems would need them anyway)? Is there a big 
problem to get a hook before or after Hosts.txt so anyone can 
organise the responses he wants, for his applications?

I think the real problem is to gather a DNS reference book. So the 
specs, the functions, the tricks of the protocol, the samples of 
existing code are documented authoritatively, a test bed is organised 
and new people with fresh ideas can come, learn and realistically 
develop new projects without being shout at "RFC XXXX!" or start an 
IETF war. mDNS and LLMNR are just that: working ideas. In 22 years 
should we not have had a lot more?

They represent a danger for the DNS? May be, only if the DNS is not 
fool proof or at least resilient enough or embedded in a more global 
system the user has an immediate interest to protect because it would 
affect much more, like in the DRS (distributed registry system I 
alluded to and which seems an interesting area of research). IMHO it 
is in that directions the IETF should work.

Anyway do not worry too much about a DNS network overload, without a 
DRS the langtags support may do better and faster.
jfc

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Sep 2005 10:50:19 -0400

> infrastructure could not resolve the query authoritatively.

The _protocol_ does not change that.  The _adoption_ of the protocol
changes the world in such a way that the effect appears.  Today, very
few people accidentally resolve things to TLDs like .myhome or .local
or .whydoicare or whatever.  But if LLMNR is widely adopted, then end
users will have reasons to attempt to make such resolutions as a
matter of course (maybe accidentally -- the names might be configured
for them by programs, so that they don't even know they're doing
this).  If those end users' boxes are also hooked up to the DNS
infrastructure -- an assumtion that hardly requires stretching one's
imagination -- then every such attempted resolution will send at
least one query to the DNS infrastructure.

Just because a protocol doesn't require a technical change in
behaviour does not mean that its adoption will not change the
techno-social environment.  For a somewhat recent example, consider
the phishing attacks that IDNA opened up.  They're really not much
different from other, previously-known phishing attacks, but because
the phish-space was so much bigger, what was once a managable
annoyance became a problem that needed to be addressed by those
developing IDNA-aware applications.  

At least in the IDNA case, the social problems could be worked around
with techno-social solutions.  Not so in the case of LLMNR: if we
start to have this problem, everyone will have to live with it,
because the protocol is designed that way.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110