-
All replies
-
Helpful answers
-
Oct 20, 2014 2:25 AM in response to blacksmith07by Jonas MN,Hi,
Have you tried using the full public domain name instead? I had to in my LAN server.local did not work but the public domain name did.
Jonas
Sweden
-
Oct 20, 2014 2:28 AM in response to Jonas MNby blacksmith07,Hi,
I don't have public domain corresponding to the servers using "*.local".
It seems like an issue with bonjour service or mDNSResponder, but i don't know how to disable this service on Yosemite
-
Oct 20, 2014 4:09 AM in response to blacksmith07by Kenneth Barnt,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.
-
Oct 20, 2014 6:08 AM in response to Kenneth Barntby uwcxjly,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.
-
Oct 20, 2014 6:57 AM in response to uwcxjlyby RomRider,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).
-
Oct 20, 2014 7:03 AM in response to RomRiderby aarontheanimator,I have tried using just the .local name, <server>.local but no luck. It still doesn't bring any of them up. Any solutions yet?
-
Oct 20, 2014 7:35 AM in response to aarontheanimatorby blacksmith07,the only workaround i've found is to add my domains into /etc/hosts, but that not a solution to my issue
-
-
Oct 21, 2014 10:21 AM in response to blacksmith07by esojaro,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.
-
Oct 23, 2014 4:51 AM in response to uwcxjlyby JensJJ,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)
-
Oct 23, 2014 7:59 AM in response to blacksmith07by jregan,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.
-
Oct 23, 2014 8:02 AM in response to jreganby jregan,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.
-
Oct 23, 2014 8:40 AM in response to blacksmith07by Kenneth Barnt,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.
-
Oct 23, 2014 8:51 AM in response to Kenneth Barntby jregan,Works for me!
Where did you find the solution?