blacksmith07

Q: Trouble to access ".local" domain

In my company we use a lot of .local domain for internal services.

 

With maverick i have access to this domains, but with yosemite i didn't have access.

 

I already try to look at mDNSResponder by did'nt find why this didn't work with all the "*.local" domain

MacBook Pro (Retina, 13-inch, Late 2013), OS X Yosemite (10.10)

Posted on Oct 20, 2014 1:33 AM

Close

Q: Trouble to access ".local" domain

  • All replies
  • Helpful answers

first Previous Page 3 of 3
  • by frank.bear,

    frank.bear frank.bear Nov 10, 2014 8:59 AM in response to ulzeraj
    Level 1 (0 points)
    Nov 10, 2014 8:59 AM in response to ulzeraj

    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


  • by apnetmedic,

    apnetmedic apnetmedic Nov 13, 2014 8:02 AM in response to blacksmith07
    Level 1 (0 points)
    Nov 13, 2014 8:02 AM in response to blacksmith07

    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.

  • by ryn_m,

    ryn_m ryn_m Nov 18, 2014 1:58 PM in response to blacksmith07
    Level 1 (0 points)
    Nov 18, 2014 1:58 PM in response to blacksmith07

    For those of you who can reproduce this problem, has the 10.10.1 update resolved the issue?

     

    Thanks!

  • by Jonas MN,

    Jonas MN Jonas MN Nov 19, 2014 12:03 AM in response to ryn_m
    Level 1 (0 points)
    Nov 19, 2014 12:03 AM in response to ryn_m

    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

  • by Kenneth Barnt,

    Kenneth Barnt Kenneth Barnt Nov 19, 2014 4:18 AM in response to ryn_m
    Level 1 (5 points)
    Nov 19, 2014 4:18 AM in response to ryn_m

    No, it did not. In fact, it seems like it reverted the manual change to the setting that did resolve it.

  • by m11k3,

    m11k3 m11k3 Nov 19, 2014 3:58 PM in response to Kenneth Barnt
    Level 1 (0 points)
    Nov 19, 2014 3:58 PM in response to Kenneth Barnt

    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.

  • by CalvinS0,

    CalvinS0 CalvinS0 Dec 10, 2014 12:21 AM in response to blacksmith07
    Level 1 (0 points)
    Dec 10, 2014 12:21 AM in response to blacksmith07

    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....

  • by EONE,

    EONE EONE Dec 22, 2014 3:13 PM in response to blacksmith07
    Level 1 (0 points)
    Dec 22, 2014 3:13 PM in response to blacksmith07

    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

  • by zeki893,

    zeki893 zeki893 Dec 24, 2014 10:24 PM in response to Kenneth Barnt
    Level 1 (0 points)
    Dec 24, 2014 10:24 PM in response to Kenneth Barnt

    works for me thanks

  • by BJH75,

    BJH75 BJH75 Jan 26, 2015 8:29 AM in response to ulzeraj
    Level 1 (5 points)
    Jan 26, 2015 8:29 AM in response to ulzeraj

    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.

  • by Luckbox72,

    Luckbox72 Luckbox72 Mar 12, 2015 5:33 PM in response to ulzeraj
    Level 1 (0 points)
    Mar 12, 2015 5:33 PM in response to ulzeraj

    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.

  • by jgib27,

    jgib27 jgib27 Apr 28, 2015 2:13 PM in response to geek1.de
    Level 1 (0 points)
    Apr 28, 2015 2:13 PM in response to geek1.de

    Thank you, that worked well as a temporary workaround.

  • by jaraco,

    jaraco jaraco May 15, 2016 1:45 PM in response to jgib27
    Level 1 (4 points)
    May 15, 2016 1:45 PM in response to jgib27

    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.

first Previous Page 3 of 3