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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf