Mac VPN connections don't resolve DNS properly

Ok so it turns out that it's a bug in macOS 10.11 all the way to 10.13

DNS resolution with "ping internalhostname" will work just fine but "host internalhostname" or "nslookup internalhostname" will fail.

This is because macOS appends the search domain from the split tunnel VPN to the first DNS resolver (the LAN/wifi one) and its DNS servers have no idea how to look up those internal VPN hostnames.

I have no idea however how come "ping internalhostname" resolution works or how come internal webpage browsing works.. Apple is still investigating but it looks like a bug on macOS so far.

Hi,

Did you eve figure this question out ?

I'm noticing the same thing on High Sierra. VPN Split tunnel assigns domain search to resolver 1 when it should infact be resolver 3 !

I've been pulling my hair and am about to open a bugreport with Apple.

The .local domain Bonjour/mDNS network traffic intentionally does not pass through IP routers.

Use the target IP address, or set up and use unicast DNS.

Having similar problem. Mac Mini Server at each end, .home is 10.7.x and .private is 10.8.2. When another Mountain Lion Mac in the .private net connects to the .home VPN suddenly it can not reach either of two IMAP mail servers in .private.

This is a relatively recent development in the past few months. If I kill mDNSResponder on the problem client Mac then things work as expected for about 30 minutes.

Conventional DNS via nslookup gives the expected answers.

scutil --dns is very similar to the original post in this thread but the first resolver #1 on mine does not list a domain, only search domains. Resolver #2 lists the remote home domain.

The problem appears to be the remote DNS is being asked to resolve private local names and when that fails Mail.app searches no more. No matter the IMAP servers are named .private.

On a lark I looked at System Preferences -> Sharing and saw host name was "clumsy" and instructed to use clumsy.local to connect from others. Wouldn't let me edit the .local but the Edit... button would let me define a "global dynamic hostname" of clumsy.private.

Mail.app now seems to be able to find the .private IMAP servers. And the remote .home servers.

Have asked elsewhere but I'd be interested in a Mac equivalent of nslookup that would do things the Mac way for diagnostics.

Maybe I'm missing something but I think you're misunderstanding how the resolver works.

From what I can tell the Search Domain [0]: alison.local should not be being added to Resolver 1. This domain should be handled by Resolver 2 the correct one for the domain.

That's not how it works. DNS doesn't care about the hostname you're looking up to determine which resolver to use.

DNS queries the first resolver in the list and takes whatever answer that returns. If the server fails (doesn't reply, isn't available, etc.) then the second resolver in the list is used.

In this case your primary resolver (75.75.75.75) is being asked for an IP address in the alison.local domain. Since that public server has no idea about your .local domain it returns an unknown host reply, and that is what your system sees. It does not then proceed to the secondary, or, ultimately, tertiary server, to get a second or third opinion.

Your solution hinges on using the private domain server 192.168.242.1 as the first server in the list.

I don't see where one has control over the order of search domains returned by "scutil --dns".

In my case I have:

scutil --dns

DNS configuration

resolver #1

search domain[0] : home

search domain[1] : private

nameserver[0] : 192.168.123.100

nameserver[1] : 69.1.30.42

nameserver[2] : 69.1.30.43

if_index : 5 (en1)

reach : Reachable,Directly Reachable Address

resolver #2

domain : home

nameserver[0] : 10.0.0.7

if_index : 7 (ppp0)

reach : Reachable,Transient Connection

order : 100000

resolver #3

domain : local

options : mdns

timeout : 5

order : 300000

As seen from the machine at 192.168.123.22 (clumsy.private).

imap1.private is also the DNS server at 192.168.123.100.

imap2.home is 10.0.0.7 on the far end of VPN.

Until I changed hostname in System Preferences -> Sharing from clumsy (which was promoted to clumsy.local) to clumsy.private I could nslookup imap2.private but Mail.app could not reach it by name, only number when the VPN was up. Yet Mail.app could talk to imap2.home. Drop the VPN, restart Mail.app, and all was fine.

I think something else is going on. When I vpn from my .private network to my .home network (where each have Mac Mini Servers running DNS) name resolution of the .private network's hosts fail in Mac apps but work fine from Unix command line tools such as nslookup.

You need to “Set Service Order” in Network preferences such that your VPN has highest priority. Then the resolver coming from the VPN will be preferred for your search domain “alison.local”.