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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5-sep-2005, at 14:21, Jeroen Massar wrote:

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

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

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.

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.

Then again, hosts on the local network can already easily respond to
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.

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.

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.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]