![]() 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. # Now you can see the stale entries are gone, and the VPN client and general DNS resolution is restored to working order Prompt> set State:/Network/Service/OpenVPNConnect/DNS Prompt> d.remove SupplementalMatchDomainsNoSearch Prompt> d.remove SupplementalMatchDomains Prompt> get State:/Network/Service/OpenVPNConnect/DNS SubKey = State:/Network/Service/OpenVPNConnect/DNS I know that it is OpenVPN leaving this behind, so I choose that network service (you may have to choose something else) ![]() # Here, we remove the stale entries directly in the scutil shell. # You can see here that the stale entries have not been removed by the above conventional means. $ sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder # Lets try to remove them via conventional OS tools / processes that have always worked in the past: $ scutil -dns | egrep -i '(domain|nameserver)' 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):Ĭode 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. the above commands aren't removing these stale entries ). 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. 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. 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. I've been experiencing this issue on Big Sur 11.3.1 - using OpenVPN and a variety of other commercial VPN clients. Search the these two might be related, but who knows. nopeįlushed the DNS cache: sudo dscacheutil -flushcache. Killed the macOS services mDNSResponderHelper, mDNSResponder. I scrolled over the logs in the Console.app. What I tried so far to investigate the issue: If the browser has cached a domain name, the website opens just fine executing dig no longer works, opening any website in any browser just times out, etc. The copy process does not finish and any samba share is no longer accessibleįurthermore DNS resolution no longer works: e.g. Mount a samba share and copy a file to it, in my case it was PDF file with size of approx. Since the upgrade to Big Sur, I noticed network issues, regardless which network device is used Wi-Fi, LAN, it does not matter.Īfter some testing the issue is now reproducible as follows:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |