DNS resolution works inconsistently in VPN connection

Question

I have an OpenVPN server setup in data center and use tunnelblick as a client. Once connected it add routes to my DC LAN 10.0.0.0/24 network and uses 10.0.0.1 as primary DNS, 8.8.8.8 as secondary DNS.

10.0.0.1 host my subdomain DNS entries in dc.example.com

The issue is when the VPN tunnel established, DNS resolution does not work consistently.

As I checked, both /etc/resolve.conf and "System Preference - Network - DNS Servers" shows the same result, which has "10.0.0.1" and "8.8.8.8" as expected.

However, in the terminal, I got mixed result between "dig" and "ping". For dig I can get sth like

➜  ~ dig ftp.dc.example.com

; <<>> DiG 9.8.3-P1 <<>> ftp.dc.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22990
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ftp.dc.example.com.        IN  A

;; ANSWER SECTION:
ftp.dc.example.com. 3600    IN  A   10.0.1.13

;; Query time: 84 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Thu Nov 24 15:39:21 2016
;; MSG SIZE  rcvd: 55

But for ping I got

➜  ~ ping ftp.dc.example.com
ping: cannot resolve ftp.dc.example.com: Unknown host

And in other application like browser I got the same result as "ping", basically unresolvable.

As you can see there's no network issue or issue with DNS server, otherwise "dig" wouldn't work.

But, if I query "www.google.com" then both "ping" and "dig" will work.

So it seems when the VPN connection established, the resolve.conf is updated accordingly, but some applications might be still querying old DNS server.

I tried to reopen terminal application, or use different terminal like iTerm, same result. But if I wait for a while, say 10-15 minutes, then ping and browser will work.

Answer 1

When OS X is configured with multiple DNS servers (e.g. 10.0.0.1 and 8.8.8.8), they system resolver does not treat them as primary vs. secondary or anything like that, it just uses all of them. So when you try to reach ftp.dc.example.com, it might try to look that name up with the 10.0.0.1 server (and succeed), or it might try with the 8.8.8.8 server (and fail). Which one it uses for any given lookup is more or less random.

The only solution I know of is to not include DNS servers on the list, unless you want it to use them. In this case, that means use 10.0.0.1 only, not 8.8.8.8.

BTW, dig, host, and nslookup do not go through the system resolver, and hence will not behave the same way -- they all use the first listed DNS server unless you specifically tell them to query a different server.

Answer 2

This seems like you are being affected by OS X's DNS caching. It may be a matter of manually flushing the cache in the client side 'up' script for your VPN connection. This article may be helpful to you http://osxdaily.com/2014/11/20/flush-dns-cache-mac-os-x/

Answer 3

A bit late, but Google consistently pointed me to this issues when looking for DNS problems in combination with a VPN. The issue for me with VPN setup was that OSX doesn't use /etc/resolv.conf, but uses information accessible through scutil.

You can view your current DNS config through scutil --dns. In my case it listed some internal DNS servers from the VPN network which we're used for resolving:

DNS configuration

resolver #1
  nameserver[0] : 80.84.224.26
  nameserver[1] : 80.84.224.249
  flags    : Request A records
  reach    : 0x00000002 (Reachable)

...

Which works for the lookups on the VPN, but didn't allow me to access anything else. Since I'm not interested in accessing these by name, I replaced the DNS entries listed here with public ones using sc-util:

scutil
> open
> d.init
> get State:/Network/Service/FctVpnService/DNS
> d.add ServerAddresses * 8.8.8.8 9.9.9.9
> set State:/Network/Service/FctVpnService/DNS
> exit

Now when I use scutil --dns again, it should show the server addresses just configured:

resolver #1
  nameserver[0] : 8.8.8.8
  nameserver[1] : 9.9.9.9
  flags    : Request A records
  reach    : 0x00000002 (Reachable)

Note FctVpnService might not be the correct key for you may have to search for the correct key for your environment. You can find the keys by calling the list command after starting scutil.