(3) Separate, but perhaps underlying both of the previous issues,
there seems be a fundamental disagreement about what technical
approach we should take to link-local name lookup. LLMNR takes the
approach that local lookups should use the same names as global
lookups and that upper layers should not care whether a name was
resolved in the global DNS or locally, essentially making the local
lookup mechanism an extension of the DNS. mDNS takes the approach
that local lookups should be distinguishable from global lookups and
accomplishes this through the use of a special local domain (.local).
This claim is one of the bits of misinformation that seems to be spread
about mDNS for some reason. It's repeated so often that people who
haven't read the draft assume it's true.
Even on Mac OS 9, five years ago, if you looked up "www.ietf.org" and had
no unicast DNS servers configured, it would look it up via mDNS instead.
The difference is that we were profoundly nervous about the implications
of doing this without adequate security, which is why
draft-cheshire-dnsext-multicastdns.txt allows multicast lookups for
non-local names, but says:
(14. Enabling and Disabling Multicast DNS)
The option to fail-over to Multicast DNS for names not ending
in ".local." SHOULD be a user-configured option, and SHOULD
be disabled by default because of the possible security issues
related to unintended local resolution of apparently global names.
(24. Security Considerations)
When DNS queries for *global* DNS names are sent to the mDNS
multicast address (during network outages which disrupt communication
with the greater Internet) it is *especially* important to use
DNSSEC, because the user may have the impression that he or she is
communicating with some authentic host, when in fact he or she is
really communicating with some local host that is merely masquerading
as that name.
The difference between mDNS and LLMNR is not in their lookup of global
names, but that mDNS *also* designates a special sub-tree of the
namespace where users explicitly have different security expectations. We
have an expectation of what www.ietf.org means. Our expectation of what
webserver.local means is different -- we know it's just a local,
temporary, transient name. We might do on-line banking at
www.bankofamerica.com, but never at moneybank.local.
Stuart Cheshire <cheshire(_at_)apple(_dot_)com>
* Wizard Without Portfolio, Apple Computer, Inc.
* www.stuartcheshire.org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf