VPN / DNS Issues With macOS Ventura

To put it very simply: This is a very normal feature, and it worked in 12.x but does not correctly in 13.x.

And as it (at leas in my case) only happens after the device went to sleep, it would seem common sense that it's not working as designed.

So IMHO it's quite irrelevant whether we're using this to connect to our VPN at home but still want a public DNS for whatever reasons, or if we're stumbling upon this issue in an enterprise environment.

Apple should be grateful that we're bringing this to the public and thus helping to improve their products, but if they prefer to not talk about any potential issues, well...

I find it quite funny that every time someone finds a bug or something like that in an Apple product, someone with thousands of points jumps in to defend Apple. And I wonder if this comment will even make it to the forum, as my last try at a reply was censored for reasons unknown.

Hi all, I had the same problem. We have internal dns servers in the company. And even when I connected, the company dns records didn't work...

However, I have come to one thing. I added "DNS Suffix" to the VPN connection settings on Mac OS and everything started working right away.

Hopefully this information will help someone else.

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.

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 love how Apple broke it but the entire world has to fix it.

And while providing no public redundant DNS servers can fix internal located Ventura computers - it cannot fix the VPN connected Ventura computers. The end user's Ventura Mac will always have public DNS servers available to them through their internet connection. And Ventura likes to use those public DNS servers before the VPN connected DNS servers.

I have the solution - but you won't like it.

Background

I have an Apple macOS laptop alongside Microsoft Windows laptop.

Both macOS and Windows connect to the tunnel and work.

Windows will attempt using the VPN's DNS first, then if that fails, falls back to the next resovler (which is usually just internet).

macOS recognizes the VPN's DNS resolver - it just won't use it.

I've seen countless posts from so many forums of people second guessing themselves and their skills, when really it's the Apple macOS that is the problem. They simple don't offer the solutions that Microsoft do - they are simply non-existent. Sure - they give you the option of putting in your own DNS server to use - they just won't use it. This must be by design, because it's hard to imagine the bug is this serious and so pervasive. This is why people go crazy wondering 'why isn't it working?'

YOU are not going crazy, because the behavior you expect and want, is perfectly available and working on a Microsoft Windows laptop. THAT is the solution! I'm running both side-by-side - macOS is THE problem.

ps.

I repaired and programmed Apple computers from 1988 to the early '90's and it's very surprising to me how little the computers have changed over the years compared to Microsoft. Honestly, I just use them for their light-weight and battery life, I'm seriously considering installing windows on my mac. Hmmm...

I found this to be the case also. I configure the vpn to hand out our internal DNS as primary, then 1.1.1.1 as secondary. If I remove the secondary then DNS lookups work correctly. Even on my home wifi where I have an internal DNS server for my home network, if I put a secondary of 1.1.1.1 then the dns lookup will ignore my primary DNS and use 1.1.1.1 for lookup.

Using host and dig returns the correct IP address when the secondary DNS is present. But comments I found indicate that host and dig do not resolve the same as Mac applications, so ping and others only resolve correctly if the secondary is removed. This appears to be a bug with Ventura DNS resolution, or it is by design and I have not found the setting that would allow for the primary to be used when a secondary (or more) is present. Still searching for the answer... but a work around is to present only the internal DNS servers to your VPN clients.

Hi,

I have been having this problem also but I just solved it. I actually only joined to post the solution

Indeed the /etc/resolv.conf is over-written props to the user who pointed that out on page 3). For me it was overwritten with an internal 10.x address so obviously DNS was failing.

What is causing the overwrite is after upgrading apple turns on by default limit ip tracking.

01) Go to settings

02) Go to networks

03) Click details next to the network name In my case my wireless

04) Turn off limit ip tracking

05) Try your vpn again

That one thing fixed the automatic overwriting of the conf file.

I work in cloud security arch and while I am a big believer in secure defaults it is obnoxious to roll something like that out breaking people's vpns without some kind of warning.

Good luck to everyone!

NickTK wrote:

The same problem, macOS 13.5, no one checked by chance, maybe they fixed it in Sonoma?

If they have, no one here would be able to comment on it. Discussing beta software is prohibited by the Apple Support Communities Use Agreement - Apple Community

I have this problem too. In my case I am using an own internal DNS-Server which also provides certain domain names only for internal use. Until last week everything worked, today suddenly all DNS-Entries which do not exist externally do not work anymore until I remove the second DNS entry, in my case also 1.1.1.1.

But it is quiet strange, using 1.1.1.1 as second entry:

• nslookup makes the right resolution.
• ping is working.
• curl is not working.
• RDP is not woking using domain name.

Florian

I am still having the same issue on Sonoma.

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.

I am experiencing the same issue on all our company MacBook's and even some of our iPad's that have updated to Ventura and iPad OS 16. From our internal DHCP we issue 2 DNS servers (1. Internal DNS, 2. 8.8.8.8). Any time someone would try to contact an internal URL/Intranet site it would not use our internal DNS server to resolve the name. As soon as I remove the 8.8.8.8 from the DNS settings and leave just our internal DNS, it immediately fixes itself. I have found that if I replace the 8.8.8.8 with 1.1.1.1 or 208.67.222.222 (OpenDNS) it immediately fixes the issue, and I can resolve internal DNS as expected again. Seems like there is a bug with have 2 DNS servers and 8.8.8.8 as the secondary. Though I have been reading about 1.1.1.1 not working for people also. Apple really needs to fix this issue! I have had numerous users with useless computers for the last couple days while we try to fix this issue. Hopefully this helps someone get some machines back to functioning somewhat normally.

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?