Apple, whose OS X Yosemite (10.10) will not even resolve DNS when internet is down ("private networks don't exist"), simply chose the wrong name for something that is basically only used by machines.
Their ".local" is not meant for manual use. They could just as easily have called it ".mdns" or something -- OS X will by default not show it anyway I'm sure. So they have claimed something they were not entitled to and their broken model of network computing is now the foundation of how to do things? * The local DNS server timeout issue is not really an issue; if you didn't want that you shouldn't have chosen .local for mdns. * .local leakage is no different from .home leakage and in this case can be prevented * redirecting local services would require upstream malicious .local to be configured in DNS servers but is directly at odds with the situation in which a _local_ .local DNS server is configured, so can also be solved by only allowing .local to get out if there IS a local .local DNS server * The only real argument that remains is name resolution; automatic changing of host names in cast of conflicts. RFC 6762 notes that "Implementers MAY choose to look up such names concurrently via other mechanisms (e.g., Unicast DNS) and coalesce the results in some fashion. Implementers choosing to do this should be aware of the potential for user confusion when a given name can produce different results depending on external network conditions (such as, but not limited to, which name lookup mechanism responds faster)." Lennart likes to scream about people not listening to the designers; but what does he do? The typical use case of a merged system is when DHCP provides DNS through supplied hostnames, there is no resolution in that sense, at least no standard one. The DHCP set would remain unchanged (and unresolved) while the mDNS set, oblivious to anything happening in unicast DNS, would produce different names where some of them would change, adding new ones to the total set. Those new names would only be resolvable through mDNS. Unless you were talking about a huge network (why would you use multicast in such a system?) the actual prevalence of such conflicts and confusion must be considered low. I think it can be argued that discovery is a much more important aspect of mDNS than resolution because most hardware devices pick MAC-based names and most operating systems also pick randomized names by default. Anything else reeks of configuration, and if you configure, you are not in zeroconf. So there aren't really any reasons that are deal-breaking, and those that exist are caused by mDNS' insistence to use for its automated system a human-meaningful name such as .local, which is a design flaw. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/80900 Title: Avahi daemon prevents resolution of FQDNs ending in ".local" due to false negatives in the detection of ".local" networks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/80900/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs