search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.38k stars 819 forks source link

Erroneous DNS request from WSL2 takes >10s in specific conditions #6585

Closed lassi-niemisto closed 4 months ago

lassi-niemisto commented 3 years ago

Environment

Windows build number: 10.0.19042.804
Your Distribution version: Ubuntu 20.04
Whether the issue is on WSL 2 and/or WSL 1: WSL2

Steps to reproduce

Inside WSL2 Ubuntu: time dig +time=20 somenonexistentdomain.com should return pretty fast, but when I connect my OpenVPN, it starts to take ~12 seconds which causes all sorts of trouble, knowing the WSL DNS is somehow queuing the requests in single thread as mentioned in https://github.com/microsoft/WSL/issues/4285

Problem seems to be between windows services "Dnscache" and "SharedAccess" doing their part in DNS relaying.

Different setups and results:

I have 2 Wiresharks monitoring both the "vEthernet (WSL)" and the "SophosTap"/"OpenTap" adapter to see how it goes. The dns traffic visible in the "WSL" adapter is logical and immediate in all cases (request goes immediately out to one of the Taps and when reply is seen in WSL adapter, dig terminates immediately.

Thus it is mostly interesting to see what happens in the Tap adapters and compare the two VPN setups. For better understanding of the participants, I have used LiveTcpUdpWatch tool to translate UDP traffic to PIDs. The process in "SophosTap"/"OpenTap" goes:

Some additional things found/tried:

Expected behavior

Inside WSL2 Ubuntu: Erroneous request such as time dig +time=20 somenonexistentdomain.com should return pretty fast

Actual behavior

When I connect my OpenVPN, above starts to take ~12 seconds which causes all sorts of trouble

image

Targets with this issue

Ultimate target would be to get WSL automatically use the host side DNS settings provided by any VPN setup and without needing any special configuration or hacks (e.g. runtime resolv.conf updaters) on the Ubuntu side.

Since the DNS resolving mechanism is a black box, I would appreciate any documentation or hints regarding how it is supposed to work or how to debug this further.

image

lassiniemisto commented 3 years ago

As said, I am available for further debugging if I get any guidance or information how the different services should interact.

lassiniemisto commented 3 years ago

Still reproduces with windows build 10.0.19042.868

ProximaB commented 1 year ago

I have also encountered this issue. If you require any specific information or insights regarding this problem, please let me know what kind of details you would like me to provide. @therealkenc Hi, I apologize for being direct, but this problem is quite common in WSL and it couses a lot of troubles in my current workflow as I decided to move to WSL which now I started regretting. It leads to various issues that have been reported over the years, such as slow Git operations and internet connectivity problems. One solution is to edit the resolv.conf file, but ultimately, it all boils down to the problem documented by lassi-niemisto. In my current work I use selfhosted instance of gitlab(selfsigned certificate), forticlient vpn, wsl2, ubuntu.

lassi-niemisto commented 1 year ago

I am currently using OpenVPN open source edition instead of Sophos / OpenVPN Connect, it works without trouble.

microsoft-github-policy-service[bot] commented 4 months ago

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!