Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
On Mon, Sep 05, 2005 at 01:45:03AM -0700, Christian Huitema wrote: > 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 _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 CanadaToronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 +1 416 646 3304 x4110 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
At 10:12 06/09/2005, Iljitsch van Beijnum wrote: On 6-sep-2005, at 1:48, JFC (Jefsey) Morfin wrote: > 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? 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. 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 !" 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
On Sep 6, 2005, at 10:51 AM, Eliot Lear wrote: Iljitsch van Beijnum wrote: 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. 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 smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
Iljitsch van Beijnum wrote: > 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
On 6-sep-2005, at 1:48, JFC (Jefsey) Morfin wrote: > 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? 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
At 22:09 05/09/2005, Iljitsch van Beijnum wrote: > 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
On Mon, 2005-09-05 at 15:02 +0300, Markku Savela 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. 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 signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
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... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
At 11:29 05/09/2005, Pekka Savola wrote: On Mon, 5 Sep 2005, Christian Huitema wrote: LLMNR does not create additional DNS queries. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
JFC (Jefsey) Morfin wrote: At 10:45 05/09/2005, Christian Huitema wrote: > 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. 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 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. 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! 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 -- 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 PROTECTED] http://iason.site.voila.fr http://www.kokoom.com/iason ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
At 10:45 05/09/2005, Christian Huitema wrote: > 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. 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 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
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 Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
> 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
From: "Russ Allbery" <[EMAIL PROTECTED]> Margaret Wasserman <[EMAIL PROTECTED]> writes: On the other hand, the DNSEXT WG has worked for several years to produce the LLMNR specification, and I don't see anything fundamentally wrong with the mechanism that we have produced (people should respond to the IETF LC if they see blocking technical issues). The authors of that specification gave change control to the IETF community, and they have gone through 40+ document iterations, working towards a document that would achieve DNSEXT consensus. That process was not followed for mDNS (because it was not the chosen solution), and we currently only have one document (LLMNR) that has reached IETF WG consensus and has been submitted for standards publication. As near as I can tell, the authors of the mDNS specification also gave change control to the IETF community, so I wouldn't raise that as a distinction. The only distinction appears to be working group consensus; the protocols otherwise look to be in the same place legally and process-wise. One other minor point here, that should probably migrate to Newtrk pretty quickly if anyone wants to chat about it... I'm getting an uneasy feeling here about a comparison between a working group internet-draft and a non-working group internet-draft, as if that was interesting. If our process had anything to say about what it means for a draft to be adopted by a working group, in terms of the quality standard it's being held to, or the reviews that have been conducted, or anything similar, this would be a very reasonable distinction, but our process says very little about any of this stuff - so saying "my draft is a working group draft" (or, even worse, "a working group draft on the standards track") isn't helpful at all. Often our processes are fuzzy for a reason, so I'm not saying we should "require three out-of-working-group independent reviews before an internet-draft can be adopted by a working group", or anything like that. I'm just saying that we shouldn't say things that sound like we DO have specific criteria that some internet-drafts meet and become working group drafts. Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
> What I find amusing is so many people asking the IESG to overrule a > WG's judgment, given how many people have complained about the IESG's > power to do exactly that. I haven't checked for overlap between the > two groups... This is much less of a contradiction than you imagine. To exercise power effectively it is often necessary to exercise it sparingly. If I was a cynical person I might suggest that the purpose of the IETF constitution was precisely to prevent anyone ever exercising power effectively. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
