I've been experiencing this issue on Big Sur 11.3.1 - using OpenVPN and a variety of other commercial VPN clients. The issue that I see, which isn't being reported here is that effectively macOS is holding onto resolver information and not allowing to be cleared out via certain mechanisms that would normally work.
When you disconnect your VPN client, and issue a
scutil --dns | egrep -i '(domain|nameserver)', entries that were pushed by the VPN client are left behind, which is definitely new and broken behavior. Trying to clear these entries with
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder , you'll find that
scutil --dns | egrep -i '(domain|nameserver)' yields the same resolver entries that your VPN client inserted (e.g. the above commands aren't removing these stale entries ).
Thusly, how I've been able to fix it without a reboot is to effectively use the
scutil shell to directly modify and save the state of the DNS-related dictionaries that are populated/deleted by the VPN software (note: I've added
prompt> to denote where commands need to be manually entered (and since I can't figure out how to escape the prompt so the formatting doesn't go awry):
Code Block | # In this case, the OpenVPN client is disconnected and all of these entries referring to 172.16.1.53 and 172.16.1.54 shouldn't be in the resolver dictionaries. |
|
| $ scutil --dns | egrep -i '(domain|nameserver)' |
| nameserver[0] : 1.1.1.1 |
| nameserver[1] : 1.0.0.1 |
| domain : sanitized.com |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.dev |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : local |
| domain : 254.169.in-addr.arpa |
| domain : 8.e.f.ip6.arpa |
| domain : 9.e.f.ip6.arpa |
| domain : a.e.f.ip6.arpa |
| domain : b.e.f.ip6.arpa |
| nameserver[0] : 1.1.1.1 |
| nameserver[1] : 1.0.0.1 |
|
|
| # Lets try to remove them via conventional OS tools / processes that have always worked in the past: |
| $ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder |
| Password: |
|
| # You can see here that the stale entries have not been removed by the above conventional means. |
| $ scutil --dns | egrep -i '(domain|nameserver)' |
| nameserver[0] : 1.1.1.1 |
| nameserver[1] : 1.0.0.1 |
| domain : sanitized.com |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.dev |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : sanitized.local |
| nameserver[0] : 172.16.1.53 |
| nameserver[1] : 172.16.1.54 |
| domain : local |
| domain : 254.169.in-addr.arpa |
| domain : 8.e.f.ip6.arpa |
| domain : 9.e.f.ip6.arpa |
| domain : a.e.f.ip6.arpa |
| domain : b.e.f.ip6.arpa |
| nameserver[0] : 1.1.1.1 |
| nameserver[1] : 1.0.0.1 |
|
|
| # Here, we remove the stale entries directly in the scutil shell. I know that it is OpenVPN leaving this behind, so I choose that network service (you may have to choose something else) |
|
| $ sudo scutil |
| Password: |
| |
| prompt> list ".*DNS" |
| subKey [0] = State:/Network/Global/DNS |
| subKey [1] = State:/Network/MulticastDNS |
| subKey [2] = State:/Network/PrivateDNS |
| subKey [3] = State:/Network/Service/CEEA9BD1-D467-461C-844D-A4C7E4640418/DNS |
| subKey [4] = State:/Network/Service/OpenVPNConnect/DNS |
|
| prompt> get State:/Network/Service/OpenVPNConnect/DNS |
| prompt> d.show |
| <dictionary> { |
| ServerAddresses : <array> { |
| 0 : 172.16.1.53 |
| 1 : 172.16.1.54 |
| } |
| SupplementalMatchDomains : <array> { |
| 0 : sanitized.dev |
| 1 : sanitized.local |
| 2 : sanitized.local |
| 3 : sanitized.local |
| 4 : sanitized.local |
| 5 : sanitized.local |
| 6 : sanitized.local |
| 7 : sanitized.local |
| 8 : sanitized.com |
| } |
| SupplementalMatchDomainsNoSearch : 1 |
| } |
|
| prompt> d.remove ServerAddresses |
| prompt> d.show |
| <dictionary> { |
| SupplementalMatchDomains : <array> { |
| 0 : sanitized.dev |
| 1 : sanitized.local |
| 2 : sanitized.local |
| 3 : sanitized.local |
| 4 : sanitized.local |
| 5 : sanitized.local |
| 6 : sanitized.local |
| 7 : sanitized.local |
| 8 : sanitized.com |
| } |
| SupplementalMatchDomainsNoSearch : 1 |
| } |
|
| prompt> d.remove SupplementalMatchDomains |
| prompt> d.show |
| <dictionary> { |
| SupplementalMatchDomainsNoSearch : 1 |
| } |
|
| prompt> d.remove SupplementalMatchDomainsNoSearch |
| prompt> d.show |
| <dictionary> { |
| } |
|
| prompt> set State:/Network/Service/OpenVPNConnect/DNS |
| prompt> quit |
|
| # Now you can see the stale entries are gone, and the VPN client and general DNS resolution is restored to working order |
| $ scutil --dns | egrep -i '(domain|nameserver)' |
| nameserver[0] : 1.1.1.1 |
| nameserver[1] : 1.0.0.1 |
| domain : local |
| domain : 254.169.in-addr.arpa |
| domain : 8.e.f.ip6.arpa |
| domain : 9.e.f.ip6.arpa |
| domain : a.e.f.ip6.arpa |
| domain : b.e.f.ip6.arpa |
| nameserver[0] : 1.1.1.1 |
| nameserver[1] : 1.0.0.1 |
You can see from the last
scutil --dns | egrep -i '(domain|nameserver)' that I have restored things to what I would normally have when I boot the system (e.g. DHCP providing DNS information over Wi-Fi).
From this point, I can fire up any client VPN software and the interaction with the OS seems to work appropriately (until it breaks again, which is probably when there's a client disconnect / sleep, something like that).
Consequently, you can script this behavior, though it would be nice to know why this is happening. A reboot will fix it, but that's way too cumbersome -- especially if you're someone who has to use an array of VPN client software throughout your day.
I hope this helps.
-
—
mdiorio
-
—
augustnagro
Add a CommentI'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.See my answer here: https://developer.apple.com/forums/thread/667347?answerId=682255022#682255022