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