Stuart Cheshire said:
"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."
[BA] Right. Margaret's message was technically wrong on a large number
of points, mischaracterizing mDNS, LLMNR and even DNS.
Stuart continues:
"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:"
[BA] Completely agree. Sending unsecured queries for FQDNs via a
link-scope multicast protocol is potentially dangerous. This should only
be done in situations where the security concerns can be addressed. This is
why
the LLMNR specification describes usage restrictions (Section 2) as well as
authentication mechanisms (Section 5.3).
(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.
[BA] The LLMNR specification contains similar language, except using a MAY
instead of a SHOULD:
" While these conditions are necessary for sending an LLMNR query, they
are not sufficient. While an LLMNR sender MAY send a query for any
name, it also MAY impose additional conditions on sending LLMNR
queries. For example, a sender configured with a DNS server MAY send
LLMNR queries only for unqualified names and for fully qualified
domain names within configured zones."
The reason that this is only a MAY is because if security mechanisms
are in place (DNSSEC, TSIG, IPsec) then queries for FQDNs may be sent
securely.
[Stuart]
(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.
[BA] Agreed. Section 5.3 of the LLMNR specification describes the use
of DNSSEC as well as other security mechanisms such as TSIG and IPsec.
Use of LLMNR with TSIG has been demonstrated in running code.
[Stuart]
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.
[BA] Actually, LLMNR and mDNS don't differ in this respect. LLMNR also
enables use of special sub-trees. As an example, Windows implementations
today treat single-label names specially; queries for these names are
never sent to the DNS, only over NetBIOS.
However, LLMNR, while describing the use of special sub-trees, does not
prescribe the special sub-tree that implementations should use. Some
implementations might designate the single-label space as special;
others might use ".local".
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf