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): 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.