Split DNS broken with macOS 10.14.6 update

[abonstu]

I updated to macOS 10.14.6 yesterday and Split DNS resolution no longer seems to work.

i.e. domains configured to resolve their address via VPN DNS are not being resolved correctly.

Tested with latest stable (1.7.16) and latest beta (1.7.17b4).

[James]

Hi abonstu,

I'm afraid we can't find any problems with Split DNS under macOS 10.14.6 in our testing. What are you seeing when attempting to resolve an address associated with the VPN connection (i.e. is the resolution failing for you, or being resolved using your normal network's DNS server, etc.)? Do you have any third-party network/firewall/DNS-proxy software installed that could be filtering lookups?

A common misstep we often see is testing DNS resolutions using "nslookup" or "dig", which do not work correctly on macOS. Please see the following comment from Apple on this:
https://www.sparklabs.com/support/kb/article/configuring-dns-and-wins-settings/#notes-for-linux-unix-users

If you're using one of the above tools, please try the instructions to test a lookup here instead:
https://www.sparklabs.com/support/kb/article/configuring-dns-and-wins-settings/#looking-up-or-testing-a-domain-name

If you're still stuck, please post a copy of your OpenVPN log and the output from running the "scutil --dns" command in the Terminal (please feel free to censor out any sensitive details before posting) and we'll take a look and see if anything stands out:
https://www.sparklabs.com/support/kb/article/viewing-the-openvpn-log/
https://www.sparklabs.com/support/kb/article/configuring-dns-and-wins-settings/#checking-which-dns-servers-are-being-used

Cheers,
James

[abonstu]

When i set my connection DNS Mode to 'Split DNS' and Domains to 'mongodb.net' here is the result:

Code: Select all

$ dscacheutil -q host -a name xxx-xxx-xx-shard-00-00-ipkmx.mongodb.net
name: ec2-13-210-31-139.ap-southeast-2.compute.amazonaws.com
alias: xxx-xxx-xx-shard-00-00-ipkmx.mongodb.net
ip_address: 13.x.x.x

When i set my connection DNS Mode to 'Full DNS' here is the result:

Code: Select all

$ dscacheutil -q host -a name xxx-xxx-xx-shard-00-00-ipkmx.mongodb.net
name: ec2-13-210-31-139.ap-southeast-2.compute.amazonaws.com
alias: xxx-xxx-xx-shard-00-00-ipkmx.mongodb.net
ip_address: 192.168.x.x

To me that looks like the Split DNS is simply not resolving the domain via the VPN.

Note that this exact configuration was working prior to the 10.14.6 macOS update (i.e. the above domain was resolving to the private address 192.168.x.x via Split DNS).

Can you please double confirm this is working correctly? It seems pretty black and white from here.

[James]

Can you please double confirm this is working correctly? It seems pretty black and white from here.

I can confirm that Split DNS is working correctly under 10.14.6 with version 1.7.16 of Viscosity.

If you'd like us to help debug the issue with your setup please post the details listed in my previous post and we can take a look for you.

Cheers,
James

[abonstu]

Hi James,

Appreciate your help mate.

Some details:
- 192.168.8.x is my local LAN
- 192.168.248.x is the remote network that mongodb.net should resolve to
- 10.0.0.2 is the remote DNS server
- 192.168.248.x and 10.x.x.x are configured to route over the VPN

Here's the output from scutil --dns

Code: Select all

$ scutil --dns
DNS configuration

resolver #1
  search domain[0] : mongodb.net
  nameserver[0] : 192.168.8.1
  if_index : 10 (en0)
  flags    : Request A records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)

resolver #2
  domain   : local
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300000

resolver #3
  domain   : mongodb.net
  nameserver[0] : 10.0.0.2
  flags    : Supplemental, Request A records
  reach    : 0x00000002 (Reachable)
  order    : 102000

resolver #4
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300200

resolver #5
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300400

resolver #6
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300600

resolver #7
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300800

resolver #8
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 301000

DNS configuration (for scoped queries)

resolver #1
  nameserver[0] : 192.168.8.1
  if_index : 10 (en0)
  flags    : Scoped, Request A records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)

resolver #2
  search domain[0] : mongodb.net
  nameserver[0] : 10.0.0.2
  if_index : 24 (utun10)
  flags    : Scoped, Request A records
  reach    : 0x00000002 (Reachable)

And heres the OpenVPN log

Code: Select all

2019-08-16 02:07:39: Viscosity Mac 1.7.16 (1491)
2019-08-16 02:07:39: Viscosity OpenVPN Engine Started
2019-08-16 02:07:39: Running on macOS 10.14.6
2019-08-16 02:07:39: ---------
2019-08-16 02:07:39: State changed to Connecting
2019-08-16 02:07:39: Checking reachability status of connection...
2019-08-16 02:07:39: Connection is reachable. Starting connection attempt.
2019-08-16 02:07:39: OpenVPN 2.4.7 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on May 29 2019
2019-08-16 02:07:39: library versions: OpenSSL 1.0.2s  28 May 2019, LZO 2.10
2019-08-16 02:07:40: Resolving address: vpn.eagle.io
2019-08-16 02:07:41: Valid endpoint found: 54.206.39.42:1194:udp
2019-08-16 02:07:41: WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
2019-08-16 02:07:41: TCP/UDP: Preserving recently used remote address: [AF_INET]54.206.39.42:1194
2019-08-16 02:07:41: UDP link local: (not bound)
2019-08-16 02:07:41: UDP link remote: [AF_INET]54.206.39.42:1194
2019-08-16 02:07:41: State changed to Authenticating
2019-08-16 02:07:41: [server] Peer Connection Initiated with [AF_INET]54.206.39.42:1194
2019-08-16 02:07:43: Opened utun device utun10
2019-08-16 02:07:43: /sbin/ifconfig utun10 delete
2019-08-16 02:07:43: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2019-08-16 02:07:43: /sbin/ifconfig utun10 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up
2019-08-16 02:07:43: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2019-08-16 02:07:43: Initialization Sequence Completed
2019-08-16 02:07:43: DNS mode set to Split
2019-08-16 02:07:43: State changed to Connected

[James]

Thanks for posting those details.

As far as I can tell your Split DNS setup is configured correctly.

However based on your dscacheutil output I believe the "xxx-xxx-xx-shard-00-00-ipkmx.mongodb.net" domain might actually be a CNAME record (rather than an A record) to an ap-southeast-2.compute.amazonaws.com subdomain. If so, macOS is likely doing the initial lookup using your VPN DNS server, getting the CNAME record back reporting it's an alias for a different domain, and then re-doing the DNS lookup for that domain. Of course, as the next domain is different in this case, it'll use a different DNS server.

If this is the case, you should be able to get the behaviour you want by changing the DNS record to an A record for the server (the approach I'd recommend), or by adding "ap-southeast-2.compute.amazonaws.com" as a search domain to your VPN connection as well.

Cheers,
James

[abonstu]

Yep that was it!

I added amazonaws.com to the list of domains and its resolving to the 192.168.248.x address now.

Either they changed the DNS records or macOS 10.14.6 changes the way it resolves CNAMEs.

Cheers for your help mate