-
All replies
-
Helpful answers
-
Nov 10, 2014 8:59 AM in response to ulzerajby frank.bear,Hi Ulzuraj many thanks for the information! You are right, I tried to insert the records
like this: 192.168.3.123 frodo.shire frodo
and there is no need to insert two identical records, one for the machine name and one full.
Now with frodo.shire the resolution is both frodo and frodo.shire.
Thank you for your contribution.Use "local" as the domain name of the local network is not a good idea
-
Nov 13, 2014 8:02 AM in response to blacksmith07by apnetmedic,I have this problem as well, and the "sudo discoveryutil mdnsactivedirectory yes" command does not fix it.
I have an added layer in that I'm using a VPN (Cisco AnyConnect), so the VPN software probably makes its own changes to how the resolver is working.
I can temporarily fix this using:
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
Within a few minutes, I'm back to broken name resolution. Maybe if I just leave discoveryd off? I suppose then I have to live without AirPlay and other goodies.
I upgraded to Yosemite from Mountain Lion, due to Mavericks having a display driver problem which caused GoToMeeting to crash. Yosemite fixes that, but now I can barely access my intranet! Ugh.
I know, the real fix is to get my IT department to use something other than "companyname.local" for its intranet.. but that ship turns slowly.
-
Nov 18, 2014 1:58 PM in response to blacksmith07by ryn_m,For those of you who can reproduce this problem, has the 10.10.1 update resolved the issue?
Thanks!
-
Nov 19, 2014 12:03 AM in response to ryn_mby Jonas MN,Hi,
I updated my MacBook Pro from 2007, to Yosemite 10.1 and did some tests.
- the WiFi is not dropped anymore after the computer goes to sleep - SOLVED
- the computer name is not changed anymore and the computer name <name> is the same as <name>.local. Non numbers or anything. The name stays the same during the day, after reboots and for different users. Rock solid. - SOLVED
The conclusion is that the 10.1 update solved the problems above and I would recommend an update.
Jonas
Sweden
-
Nov 19, 2014 4:18 AM in response to ryn_mby Kenneth Barnt,No, it did not. In fact, it seems like it reverted the manual change to the setting that did resolve it.
-
Nov 19, 2014 3:58 PM in response to Kenneth Barntby m11k3,I Updated to Yosemite 10.10.1 to test this and the update has removed the .local address workaround I had added in the search domains.
Still seems that adding the address to the search domains is the only workaround, otherwise changing the address to something other than .local.
Apple need to fix this! Hopefully the next patch will resolve this.
-
Dec 10, 2014 12:21 AM in response to blacksmith07by CalvinS0,And it would be very friendly from Apple to give some reply on these posts since this fact really ***** for every business user...
I can not and will not upgrade due to this reason....
-
Dec 22, 2014 3:13 PM in response to blacksmith07by EONE,Do you have Sophos AV installed?
Add
127.0.0.1
.local
and ip-range e.g. 192.168.1.0/24
to the allowed websites or turn off web protection
Good luck
-
-
Jan 26, 2015 8:29 AM in response to ulzerajby BJH75,AD has been using .local domains since 2000. Is it necessarily "best practice?" Probably not, but until very recently it wasn't a problem, or in direct opposition to any RFC. Just because an Apple employee decides to write an RFC that is less than 2 years old without taking into consideration 10+ years of enterprise networking does not make it APPLE = RIGHT and the AD infrastructure = WRONG.
There are plenty of domains in the enterprise world using .local tlds. MDNS is not an enterprise feature, it is for small networks and home users who don't understand how to setup DNS properly. If Apple wants to use it - great, but their insistence that it should be forced onto an enterprise network that works 100% appropriately with a .local TLD is misguided. It is another example of Apple's horrific support and understanding of enterprise needs.
If you were building a new domain, I wouldn't recommend .local - mostly due to issues like this and the more technically sound argument being put out by CABrowser regarding the insecurity of SSL certs for .local environments (this I can buy into). But the reality is I have a .local running in my home lab because I have plenty of software customer with .local (and no, I didn't set up their environments). Windows servers get upgraded from 2000 > 2003 > 2008 > 2012 but the original domain names often stay and it can be a herculean effort to rename them in many cases.
Apple's insistence on what they believe is the "right way" is simply wrong. Enterprise friendly vendors need to live in the past as much as they have a foot in the future.
-
Mar 12, 2015 5:33 PM in response to ulzerajby Luckbox72,I have been trying to set up a number of macs so that can access pc on a windows network when then have a sslvpn setup. I have had no issue on older versions on the osx but Yosemite I have been unsuccessful. I can map drives or remote desktop with ip no problem, but not by name.
I can run sudo discoveryutil mdnsactivedirectory yes and I am able to use pc name, but after reboot I have to run this again, so not the best option.
I have tired creating the com.fix.local.plist and saving it in /Library/LaunchDaemons but on reboot it doe not work.
Is there a step I missed?
as to the .local issue, yes if I was to setup the netowrk today I would not use the .local but since this was setup in 2000 and the network has grown since then to change to not use the .local would be way to much work to just fix an issue with apple os.
-
Apr 28, 2015 2:13 PM in response to geek1.deby jgib27,Thank you, that worked well as a temporary workaround.
-
May 15, 2016 1:45 PM in response to jgib27by jaraco,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.