DNS Issues - unable to resolve .local URL's over VPN

[stemkat]

Hi All,
I have an infuriating DNS issue with Yosemite. Does anyone know what is happening or what might have been changed by Apple. Any temporary fix till Apple/Cisco get their act together?

Thanks All!

Below is the write up I sent to Apple via the Feedback Assistant (sent 9th Aug)

There are major issues introduced in Yosemite in relation to resolving .local addresses to my companies DNS name server when connecting remotely via VPN. VPN client is Cisco AnyConnect Secure Mobility Client.

I have to access autodiscover.MyCompany.local, mail.MyCompany.local and wiki.MyCompany.local constantly through Mail, Outlook and Safari however these URL’s cannot be resolved and when pinged Network Utility states ‘Unknown Host’.

Attempts to fix this issue involve Flushing DNS cache (sudo discoveryutil mdnsflushcache
), force quitting non responding processes (e.g. geod), constantly trying to ping the addresses, internet browsing, reestablishing VPN, quitting application etc. There is no sure fire fix. At some point the the DNS nameserver is then accessible by the OS and I am then able to ping one/all of the above URL’s. Interestingly, it can start to resolve one URL such as Mail., but will fail to resolve another, such as wiki. There is no logical patten. There are DNS and perhaps port forwarding issues here and need urgent attention.

I have addressed Mail by placing the IP address of my Exchange… the server is accessible it’s just DNS seems to be broken. I cannot do this for wiki.MyCompany.local as the IP address forwards back to the URL and it then cannot be resolved.

Whilst this issue is not persistent, it is consistent and happens at least every time I re-establish the VPN. It also re-appears randomly whilst on the VPN and can take 20mins to resolve each time. I have no idea what allows these URL’s to sometimes resolve to my companies Nameserver and other times cannot. This issue happens with both IPv4 Tunnel Modes including Split Tunnelling.

Through cat /etc/resolv.conf | grep nameserver, I can see the VPN assigns the correct Nameserver as the primary as soon as the VPN is established. The IP addresses of Nameserver and respective servers can be pinged.

This issue needs urgent attention, as it will cause major issues for Corporate users. FYI - the VPN and DNS were running very well with the last version of Mavericks. This issue has been introduced in Yosemite. Some OS X network behaviours have been changed in this new OS.

 

[agelwarg]

Apple Response??

Did Apple ever respond? Did you find a resolution? I'm experiencing the same issue(s)

 

[filosnet]

Same problem here... and apparently I am having it with Safari only

 

[scubastevegk]

Same thing happening to me. I did a tcpdump while I was attempting to resolve a name, and confirmed my suspicion that the system was treating the lookup as a multicast DNS request, rather than a unicast request and directing it to my corporate DNS server.

According to this article that looks like it was created in the Snow Leopard days, DNS requests with two labels ahead of .local should be directed to a DNS server, while request with one label should be interpreted as multicast:
http://support.apple.com/kb/HT3473?viewlocale=en_US&locale=en_US

Everything works properly when I am directly connected to my corporate LAN. DNS requests are sent unicast to my servers, and everything resolves properly. It's only over VPN that I have problems. If anyone has any solutions, I'd be happy to try things out - I control our corporate DNS servers, so I have a lot of latitude here.

 

[scottreder]

I'm having the same issue resolving a hostname in my company's lab over a Cisco AnyConnect VPN connection (latest version - 3.1.05187). In this case, it's a VMware Horizon connection server with xxxx.yyyy.local naming convention that won't resolve.

This worked in Mavericks and also works in a Win7 virtual machine running under Fusion on OS X 10.10 Yosemite (installed the VPN and Horizon clients directly in the VM), but no go with 10.10 natively.

Anyone try an alias to see if that works as an interim fix? I will try this out later today.

What a nasty issue - as stemkat said, "This issue needs urgent attention, as it will cause major issues for Corporate users." That obviously didn't catch anyone's attention prior to GA...

 

[scubastevegk]

I just got it resolved in my environment this morning. I configured our VPN to push our .local domain as a DNS suffix when it hands down the IP address to the remote client. Doing so forced OS X to send the DNS request to the server instead of interpreting it as multicast. Hopefully this helps others here!

 

[scottreder]

Thanks for the update, scubastevegk.

My fix was to put our lab's *.local domain first in the "Search Domains" list under System Preferences -> Network -> Advanced -> DNS. I made these edits under a new Location so I can switch back & forth easily.

Looks like the default behavior for *.local name resolution in 10.10 is Bonjour multicast. Bad move there by Apple. At least make it easy to switch to normal name resolution.