Big Sur reproducible DNS resolution issues

Hello,

Since the upgrade to Big Sur, I noticed network issues, regardless which network device is used Wi-Fi, LAN, it does not matter.

After some testing the issue is now reproducible as follows:
  • Mount a samba share and copy a file to it, in my case it was PDF file with size of approx. 1.6 MB

  • The copy process does not finish and any samba share is no longer accessible

  • Furthermore DNS resolution no longer works: e.g. executing dig apple.com no longer works, opening any website in any browser just times out, etc.

  • Strangely enough ping apple.com works (...?)

  • If the browser has cached a domain name, the website opens just fine

What I tried so far to investigate the issue:
  • I scrolled over the logs in the Console.app .. found nothing

  • Killed the macOS services mDNSResponderHelper, mDNSResponder .. nope

  • Flushed the DNS cache: sudo dscacheutil -flushcache .. nothing

  • Search the WWW for related issues and found these: Big Sur Network Connectivity Issue, Big Sur DNS Issue .. these two might be related, but who knows..

  • So far, only a reboot fixes this...

Can anyone else reproduce this issue ?
Any further ideas ?

Best Regards
SH
Post not yet marked as solved Up vote post of shoelzle Down vote post of shoelzle
34k views
  • I'll add my me to to the list. Since Big Sur - but not the original release, not sure which one in particular. Several different DNS related issues:

    Cisco AnyConnect client 4.9.04043. DNS is routed through the tunnel. Works great. System sleeps because I walk away, tunnel disconnects. Tunnel reconnects upon wake, DNS resolution is broken. HUP the mDNSResponder and everything is back to normal. This never happens if the laptop doesn't sleep.Safari will randomly have issues with DNS and return NXDOMAIN, even though DNS resolution via dig and ping are working fine. But it doesn't do it with pages that are already cached. Other browsers will work fine when Safari is broken. Need to close Safari and re-open to resolve this issue.
Add a Comment

Replies

Hello everybody.

I'm also having a similar problem, I use OpenVPN Connect, I'm using Big Sur version 12.3.1, (Macbook Air M1) and it just doesn't work. I always have the log below.

EVENT: WAIT ⏎[May 6, 2022, 08:42:48] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock ⏎[May 6, 2022, 08:42:48] Transport Error: socket_protect error (UDP) ⏎[May 6, 2022, 08:42:48] Client terminated, restarting in 2000 ms...

I'm pretty sure the problem is in the Big Sur version, because the same .ovpn file works on my iPhone or Windows desktop.

Hi guys.

On MacBook with M1 processor there is a workaround: I use AnyConnect client designed for iPad from AppStore.

Feels a little bit clunky, but there is no more problems with connection,

I am experiencing the same issue on my macbook m1 on Monterey with FortiClient VPN. Any fixes?

  • I am also experiencing the same issue on my macbook m1 on Monterey with FortiClient VPN. Any fixes?

Add a Comment

I observed the similar issue with Monterey and latest Cisco VPN. Simplest solution was to restart the machine, but I was running a critical process on my machine for multiple hours and didn’t wanted to loose that time, so I did a hack to make it work, it’s little disruptive but did the job for me. I tried to get the list of network interface :

scutil --nwi

there was a demon virtual network interface created by cisco vpn and I cleared that one using scutil utility sudo scutil remove State:/Network/Service/com.cisco.anyconnect/IPv4

this restored the internet connectivity and DNS resolution.

I had to re-install Anyconnect to enable vpn but I was able to restore Internet connectivity without restart.

I am not sure how generic this solution is but I thought it’s worth sharing. Cheers!

Hi All, I'm having the same issue on Ventura 13.4 (22F66), is there any update on this?

  • Hi All, I'm having the same issue on Ventura 13.2.1 (22D68).

Add a Comment

I've attempted to package vikmalik's insightful workaround as follows:

With VPN down run:

echo list | sudo scutil | grep DNS

with VPN up run the same:

echo list | sudo scutil | grep DNS

You will notice one extra state. In my case it was:

State:/Network/Service/BA3F9510-ED70-4AF9-B776-89EFDB500789/DNS

Now with the VPN up you can remove the state with:

echo 'remove State:/Network/Service/BA3F9510-ED70-4AF9-B776-89EFDB500789/DNS' | sudo scutil

Afterwards applications, such as ping or chrome, will be able to resolve hostnames again while VPN is active. You'll have to remove that state every time the VPN is established. Fortunately, the state string doesn't change and you can alias the command.