MacOS: Split DNS Not Working as Intended with VPN Profile

Split DNS failures on macOS often stem from stale resolver caches or misconfigured routing tables rather than VPN profile errors. You can diagnose the active configuration by running scutil --dns in Terminal to inspect domain-specific rules and search paths. To resolve persistent issues, flush the system cache using dscacheutil and restart the mDNSResponder service, which forces the operating system to re-evaluate your network interfaces and apply the correct split-horizon routing.

Understanding Split DNS Behavior on macOS

Split DNS, also known as split-horizon DNS, allows a single device to use different name servers for different domains. When connected to a corporate VPN, your Mac should route internal queries (like intranet.company.com) through the VPN tunnel while sending public queries (like google.com) through your local Wi-Fi or Ethernet connection. This setup is critical for security and performance, ensuring that internal resources are not exposed to the public internet and that latency is minimized for external traffic. However, macOS does not always handle these transitions seamlessly. When you disconnect from a VPN, the system may retain residual DNS routes. Conversely, when connecting, it might fail to prioritize the VPN’s DNS server over the local router’s default server. This results in either inability to reach internal sites or unintended exposure of internal names to external resolvers. The root cause is typically how the kernel manages the routing table associated with network service identifiers, rather than a fundamental flaw in the VPN client itself.

Diagnosing the Issue with scutil

Before applying fixes, you must verify the current state of your DNS configuration. The primary tool for this is the scutil utility, which provides detailed insights into the system configuration database. Open Terminal and execute the following command:

scutil --dns

This output is verbose but contains crucial information. Look for the "domain" section. Here, you will see entries like .local or specific company suffixes. Next to each domain, check the "nameserver" column. If your VPN is supposed to handle .corp domains, there should be an entry mapping that domain to the IP address provided by your VPN gateway. If this mapping is missing, or if the nameserver points to your local ISP’s DNS instead of the VPN server, split DNS is not configured correctly in the runtime environment. You should also check the "options" section. Ensure that search lists do not contain conflicting entries that might cause the resolver to attempt resolution via the wrong interface first. If the VPN profile is pushing these settings but they are not appearing here, the issue lies in the persistence of the configuration across reboots or network changes.

Clearing Stale Caches and Restarting Services

Even with correct configurations, macOS relies on several caching daemons that can hold onto outdated information. The most common culprit is the directory service cache managed by dscacheutil. To clear this cache, run the following command in Terminal:

sudo dscacheutil -flushcache

This command forces the system to discard cached DNS records. However, this alone is often insufficient because the multicast DNS responder (mDNSResponder) maintains its own independent cache and state machine. mDNSResponder handles both mDNS (for local zero-configuration networking) and standard DNS resolution logic. If it has cached a negative response or an incorrect route for a domain, it will continue to serve that data until its internal timer expires or it is manually restarted. To restart mDNSResponder, you need to kill the process, allowing the system launch daemon to automatically respawn it with a clean state. Use the following commands:

sudo killall mDNSResponder
sudo killall mDNSResponderHelper
sudo killall DiscoveryService

After executing these commands, wait a few seconds for the services to restart. Then, reconnect to your VPN. The system will now query the DNS servers fresh, and the scutil --dns output should reflect the correct routing for your split DNS domains.

Verifying the Fix

Once the services have restarted and the VPN is reconnected, verify the fix by checking the DNS configuration again. Run scutil --dns and confirm that the relevant domains are mapped to the VPN’s nameservers. You can also test resolution by using nslookup or dig for an internal hostname. It should return the internal IP address. If it returns a public IP or times out, the split DNS rule is still not being applied correctly, and you may need to review the VPN profile’s push settings or contact your network administrator. For users experiencing similar lookup delays on newer macOS versions, such as Sequoia, refer to our guide on resolving split DNS lookup issues specifically tailored for recent updates. Additionally, if you are managing multiple network interfaces, ensure that no other services are interfering with your primary network configuration.

Frequently Asked Questions

Why does my internal website load slowly after connecting to the VPN?

Slow loading often indicates that the DNS query is initially sent to the local resolver before falling back to the VPN server. This happens because the local cache or routing table prioritizes the non-VPN path. Flushing the cache with dscacheutil and restarting mDNSResponder usually resolves this latency by forcing a fresh lookup against the correct, low-latency VPN nameserver.

Can I manually edit the DNS configuration files to fix split DNS?

While you can modify files in /etc/resolv.conf or /etc/hosts, these changes are often overwritten by network management profiles or DHCP leases. Using scutil to view the active configuration is safer, and relying on the VPN client to push the correct settings is the standard approach. Manual edits should only be used as a temporary diagnostic step, not a permanent solution.

What if scutil --dns shows no domains at all?

If the domain list is empty, your system may not have any active DNS search domains configured, or the network service is in a disconnected state. Ensure that your VPN connection is fully established and that the VPN profile includes "Use Default Gateway" and "Send All Traffic" options if required. Sometimes, toggling Airplane mode or disabling/enabling Wi-Fi can reset the network stack enough to populate these fields.

Does restarting mDNSResponder affect Bluetooth or AirDrop?

Restarting mDNSResponder briefly interrupts mDNS-based services like AirDrop and Bluetooth file sharing, as these rely on multicast DNS for device discovery. However, these services typically reconnect within seconds. Your regular internet browsing and VPN connectivity are unaffected by this restart, as they use unicast DNS resolution handled by the same daemon.

How do I prevent split DNS issues after a reboot?

Prevention involves ensuring that your VPN client is set to "Connect On Demand" or automatically reconnects upon login. Additionally, avoid manually configuring static DNS settings on your network adapter unless necessary. Let the DHCP and VPN profiles manage the DNS assignments. If issues persist, consider creating a script that runs dscacheutil -flushcache and restarts mDNSResponder upon VPN connection events.