We had a problem where DNS failed when trying to do anything network-related from inside a Docker container on Windows, and while using GlobalProtect VPN from Palo Alto Networks.
The problem was easily reproduced by calling wget domain at our company.
If we called wget with an IP address, it could resolve, but failed on the name. For example:
~/dev # wget 188.8.131.52
Connecting to 184.108.40.206 (220.127.116.11:80)
Connecting to 18.104.22.168 (22.214.171.124:443)
wget: bad address ‘domain at our company’
The same call worked correctly on a Mac running Docker with GlobalProtect VPN.
It turns out there is a Windows-specific split-tunneling setting on the GlobalProtect VPN Portal, documented at https://www.paloaltonetworks.com/documentation/80/pan-os/web-interface-help/globalprotect/network-globalprotect-portals/globalprotect-portals-agent-configuration-tab/globalprotect-portals-agent-app-tab#id67b93aa3-5241-482b-ac69-7f3952c24454.
"Resolve All FQDNs Using DNS Servers Assigned by the Tunnel (Windows Only)
Configure the DNS resolution preferences when the GlobalProtect tunnel is connected on Windows endpoints:
• Select Yes (default) to enable the GlobalProtect agent to allow Windows endpoints to resolve all DNS queries with the DNS servers you configure on the gateway instead of allowing the endpoint to send some DNS queries to the DNS servers set on the physical adapter.
• Select No to allow Windows endpoints to send DNS queries to the DNS server set on the physical adapter if the initial query to the DNS server configured on the gateway is not resolved. This option retains the native Windows behavior to query all DNS servers on all adapters recursively but can result in long wait times to resolve some DNS queries."
We had this option configured to Yes. Setting it to No fixed the problem.
Hope this helps the next person and saves them hours of debugging!