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: peter@xxxxxxxxxxxxxxxx
http://iason.site.voila.fr
http://www.kokoom.com/iason
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf