Trouble to access ".local" domain

We found a solution that worked for us!

After running

sudo discoveryutil mdnsactivedirectory yes

in the terminal we're able to resolve .local FQDNs again. This gets it to use regular (unicast) DNS for .local domains rather than just using multicast DNS (mDNS, aka Bonjour) to look-up .local addresses.

I followed the instructions on this post when I encountered the issue. The workaround was great and I installed it as a LaunchDaemon to correct the problem for the future. Today, I was having DNS issues and revisited this issue, but discovered based on this KB article (Reset the DNS cache in OS X - Apple Support) that apparently mDNSResponder was revived and discoveryutil deprecated in OS X 10.10.4, so this workaround should no longer be necessary. On my current system, which is 10.11.4, there's no discoveryutil in /usr/sbin/discoveryutil.

We are having .local issues at the institution I work for as well. What we're seeing is that most applications (e.g. browsers, Finder for connecting to shares) will not connect to a server using an FQDN ending in example.local, but they will connect to the server just fine if only the hostname is specified and example.local is in the search domain.

Mail.app seems to be an exception to this, in that it will still connect, but it takes an inordinate amount of time for that initial connection to come up.

It seems that Yosemite's implementation of Bonjour sticks much more strictly to RFC 6762, and so it assumes anything that uses .local explicitly should be resolved using mDNS, rather than traditional unicast-DNS. In previous releases, these queries were done in parallel, but now I'm not even sure the unicast query happens at all.

Hello.

I've experienced the same problem.

Solution that helped me - http://blog.malyshev.com/?p=1513

Briefly. Apple use .local domain for Bonjour service.

At pre-Yosemite versions, OS make attempt to resolve host via DNS, then via Bonjour. In Yosemite and iOS 8 that is reversed (strange solution).

To solve this problem, go to Network > Advanced... > DNS. In "Search Domains" enter name of your local domain (example.local).

I'm sure this will help.

Tags: domain.local, Yosemite, idiots.

Hello,

Your solution does work only if using short names :

* "host.mydomain.local" won't resolv

* "host" will resolv

I face the same problem in my company. Everything is under .local (lots of subdomains)

I didn't find any workaround for the moment (even adding --no-multicast argument to the discoveryd service command line doesn't work).

I had the same problem, the .local domains was not resolved, when I connected to PPTP VPN. When I set the search domain in the VPN/Advanced/DNS/Search domains AND the Wi-fi/Advanced/DNS/Search domains to ourdomain.local, the problem was solved.

This didn't help me.

Instead I tried to connect to server (Command + K) in Finder. I wrote the DNS-iP instead of the .local address. I found the iP in System Preferences/Network/Advanced/DNS on the left column instead of the search-domains on the right hand side, where the .local domain was.

Then I was asked for my password (which on Maverick was in the keychain i guess).

This worked for me.

I know very very little about this stuff, but maybe it will help you.

(maybe it has something to do with the password protection)

Add one more that works in a company that uses .local for all its internal hosts. No internal hosts are in the xxx.com domain, so that's not an option.

I, too, had no trouble with Mavericks.

There have been reports of trouble resolving the .local domain since 2002 - do a search with your favorite engine. Apple has known they have issues for over 10 years.

IMHO: .local DNS searches should definitely NOT be passed to external DNS servers, but in my case, the DNS server is at 192.168.xxx.xxx, an internal host. In that case, the search CAN be passed on to an internal DNS host. Non-public domain ips are 'well-known' and Apple can definitely let .local requests be passed to DNS servers hosted on a private network.

The issue is bad enough for me, I'm considering reverting to Mavericks. I don't need much of what Yosemite offers, anyway.

I'd ask for my money back, but...... Of course, you get what you pay for, too.

This worked for me, but my .local domain became inaccessible after a reboot. Any other ideas? The weird thing is that I did an in-place upgrade from Mavericks 4 days ago, including numerous reboots, but this problem only surfaced within the last 18 hours of this post.

I had the same issue, normally "connect to server" (cmd-K) gave a window with frequently used servers such as SMB://companyname.local/dfs/company templates. This stopped working after installation of Yosemite. The trick is to use the actual name of the fileserver, in my case SMB://fls01/company templates

This solved the problem

By running "sudo discoveryutil mdnsactivedirectory yes" I get the following error:

Basic RemoteControl Tue Nov 4 15:56:29 2014: XPCRemoteSender.cpp:54: com.apple.discoveryd: server failed

Warning: this command didn't reassure me by sending an OK

Hi all, my 2 cents

Same problem, I try some solutions read here but it dont work

I solved in this way

In /etc/hosts I write a record for all my devices like this:

192.168.3.123 frodo.local frodo

192.168.3.124 gandalf.local gandalf

and so on.

Previsious record write like this

192.168.3.123 frodo frodo.local

dont work. on yosemite but it work on maverick, ml and leopard.

I hope help you.

Sorry for my neanderthal english 😟

bye Frank

As the initial excitement is over I made new tests and I noticed that the name resolution is still not working as it should. 😠
To have a name resolution must insert two records for each device.
example:
Local network "local" with a PC that acts as a garbage dump
192.168.3.200 mordor
192.168.3.200 mordor.local
(of course the name Mordor is not chosen at random for a PC garbage)
After entering the two records in the /etc/hosts file check with the command
dns-sd q mordor
dns-sd q mordor.local
that the resolution occurs.
I'm sorry for my english primitive, my native language is the language of Beorn (read The Hobbit for more details) 😉

I'm having this problem with Linux for a quite while since Avahi-Daemon is on the default resolver list of any distribution. Its Microsoft's and your administrator fault for breaking the rules.

I should note that Apple isn't doing nothing wrong. The .local suffix is reserved for multicast DNS resolution but a whole lot of Windows administrators wrongly adopt "company.local" as their DNS suffix. This has to do with the fact that the Microsoft learning documentation always use a .local domain.

The domain .local is a TLD RESERVED (http://tools.ietf.org/html/rfc6762) for hostnames that can be resolved via multicast DNS. If someone is using it on their Windows AD infrastructure they are doing it wrong.