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.