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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf