VPN / DNS Issues With macOS Ventura

As before, with 1.1.1.1 as secondary no love. host lookup works, but ping and others do not resolve. Today I find if I create the file /etc/resolver/mydomain.net and put my primary in the file as "nameserver 192.168.11.10" all works well.

Note that all other secondaries I have tried have worked. Just 1.1.1.1 has the problem. And is fixed with the above solution found on superuser on StackExchange in answer to the question "How to make .local resolve not via mDNS on Mac OS Mohave?"

scutil --dns shows resolver #1 correctly as my nameservers in order from my network settings. mDNS for domain local is second. With the above file present, then resolver #8 is added pointing to the nameserver listed in the file.

This seems like a bug because only 1.1.1.1 has the issue?

I've moved to using 1.1.1.2 for now. But why does 1.1.1.1 act differently, only to be fixed with the above solution?

I didn't manage to raise this with Apple as I was able to fix the issue, I had to remove the public DNS server from those advertised by the VPN server, once that was removed and I only had our 2 private DNS resolvers listed the problems seem to have gone away

We are having a similar issue.

It seems like macOS Ventura (13.3) isn't respecting DNS order. It was choosing our Open DNS server.

This was placed last in the DNS list however it seems that macOS Ventura is choosing that over the others listed.

We identified there was an issue with our Open DNS server but it being listed last why was Ventura using it 1st?

We removed that entry for now until we solve the problem with Open DNS.

Here are my latest updates...

VP of IT: The issue still is not Apple. It is that we need an internal address to resolve in OpenDNS

VP of IT: Moreover why is OpenDNS even in there when it is not receiving any queries

Manager of ITOps: It is considered bad security practice to put internal entries in public DNS

VP of IT: Correct

VP of IT: OpenDNS should only be when we are external…. Yes?

Manager of ITOps: Therefore we cannot have OpenDNS resolve internal addresses.

Manager of ITOps: The problem IS Apple and not honoring the DNS server order from the DHCP settings.

Manager of ITOps: The OpenDNS servers were added they solely to account for loss of access to internal DNS servers.

Manager of ITOps: It was primarily necessary in offices where there was no on-site domain controller for when the WAN would become unavailable.

Me: As far as Apple “knows” there is no issue with macOS. They wanted to blame our MDM and will not troubleshoot further until we test after removing our MDM. I spoke to Tech1 who is going to remove our MDM and reinstall macOS to rest further. Once that has been completed I will report back to Apple Support.

VP of IT: Stop spinning our wheels with Apple. It does not matter.

Manager of ITOps: Correct, if we are willing to accept that in a network failure, there will be NO DNS resolution in offices w/o an onsite server. Then we should plan on never putting OpenDNS back in the list.

VP of IT: As long as you are fully redundant for internal resolvers then you are okay.

Manager of ITOps: that is the issue, in some offices, we are not fully redundant.

VP of IT: Well then that is more the issue.

VP of IT: DNS should have at least one resolver locally and a backup within our data center

VP of IT: Or we need to rethink the OKTA login process and it calling oktalogin.xxxxx.com

TLDR: We are going to stop using OpenDNS and have redundancy in each office and "ignore" The problem is Apple and that they are not honoring the DNS server order from the DHCP settings.

One more person experiencing this problem, chiming in.

I have a dedicated dhcp/dns server running dnsmasq. It was all fine when it offered only itself as the dns server. When I added a secondary dns public server to the list of dns servers offered to its dhcp clients, all of sudden MacOS 13.3.1 failed to resolve address when using command line utilities like "ping" and "ssh" would not work with local domain names. Diagnostic utilities like "nslookup", "dig", and "scutil -r" would work. Chrome and Safari also work. My older macs, with no unsupported OS's, all worked fine. My windows computers worked fine. My Chromebooks worked fine. The only problem is with my MacOS 13.3.6 system.

I resovled it by adding a /etc/resolver/lan, where "lan" is the my local network doman name", and declared the local name server in that resolver file. But hardcoding the dns like that defeats the purpose of using dhcp to distribute the name server address.

Having MacOS M2 with 13.3.1, I have (I had) the same issue with all VPN connections (regardless the system used, at least with SonicWall, Fortinet, WatchGuard, Ivanti).

I found a quite dirty but worky solution: after the connection being established, and the /etc/resolv.conf being updated, I explicitly set the DNS back to something public.

For example:

networksetup -setdnsservers "Wi-Fi" 8.8.8.8

That did the thing for all aforementioned VPN clients.

If your internal network is using a .local domain, make sure, when attempting to reach resources on it, you use the full domain name.

For example, when trying to access a share called "share" on a server named "server" on the domain "company", the SMB share would be smb://server.company.local/share not smb//server.company/share

When the problem begins, open up a terminal and see if this command shows your DNS entries::

scutil --dns

Basically MacOS is a bit weird about name servers. It is not simple "here are some resolvers" and my bet is that there is an API or a deprecated resource in use that means the DNS is not being updated appropriately or the VPN providers are not feeding the appropriate information.

You may see a number of entries there, but the important ones are the resolvers and the domains associated. If it is pointing at itself, something isn't right and I recommend contacting apple support. DNS issues have been reported in various placed throughout the Ventura beta and evidently continue.

I'm especially seeing this, after my Mac has gone to sleep, after wakeup it refuses to find hosts behind the VPN.

Switching Wi-Fi completely off and on again usually does the trick, sometimes a reboot is needed.

I had 8.8.8.8 set as a tertiary DNS, have now removed this to see if it changes anything.

So, not only 1.1.1.1 has the issue, but 8.8.8.8 as well.

And: i definitely never had this on Monterey, it started with Ventura.

Just testing with 13.1. Partially fixed?

Does not work with 1.1.1.1 or 1.0.0.1.

Works with 8.8.8.8 (Google), Quad9, OpenDNS, Comodo.

So is it Cloudflare or Apple with the problem now? Was there really anything changed by Apple?

In my case, after connecting to vpn through tunnelbrick, ssh won't resolve host an internal host.

My workaround is to switch my current wifi to another one (I had two wifi networks at home), that would seem to "trigger" something internally in osx, while leaving my vpn connected, then my ssh would resolve host again! Note that turning wifi off and on doesn't work, but switching one would "fix" it. Strange.

Our VPN provider has suggested the issue might be related to our MDM software (in our case Jamf) and I have removed it from my laptop to try to see if I can reproduce the issue still (no issues yet, but it's early days)

I have struggled for the last 8 months with this DNS issue on Ventura 13.1-13.6.2. Local DNS IPs is required for internal servers, but adding any secondary fail-over external DNS IPs would cause failures after reboot or wake. I tried every combination of every posted idea and solution I could find. Nothing stuck for more than a few days. Out of options and on a whim, I tried adding a zero before the final digit of the last octet. This has been working successfully for over 2 months. Hopefully this simple trick works for you.

fail ---> success!

1.1.1.1 ---> 1.1.1.01

9.9.9.9 ---> 9.9.9.09

8.8.8.8 ---> 8.8.8.08

8.8.4.4 ---> 8.8.4.04

DNS is one of the most critical pieces needed to use a computer today. Come on Apple, DNS needs to be bullet-proof and prioritized before add-on features.

Has anyone actually got any support from Apple? Seems like the issue is still present with Sonoma. It seems like when connected to the IKEv2 VPN, the local DNS queries are going through 127.0.0.1 and don't actually route properly. If I do nslookup and specific the server manually, it queries fine.

Same issue here, MacOS 13.2.1, Fortinet VPN Client 7.2, the resolv.conf file just minutes after VPN connection is overwritten by previous version, cutting of DNS access. It is affecting all people in my company. If goes for months, Apple is reluctant to provide any fix.