Split DNS problems

[leorg99]

Windows Version

Microsoft Windows [Version 10.0.22631.3155]

WSL Version

2.1.4.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

5.15.146.1-2

Distro Version

Debian GNU/Linux 12 (bookworm)

Other Software

No response

Repro Steps

.wslconfig

[wsl2]
firewall=false
networkingMode=mirrored
memory=16GB 
processors=4
swap=4GB
nestedVirtualization=false
guiApplications=false

[experimental]
sparseVhd=true

/etc/wsl.conf:

[boot]
systemd=true

Expected Behavior

When connected to VPN (Cisco AnyConnect), I expect the VPN nameservers to be listed first followed by LAN nameserver in /etc/resolv.conf

Actual Behavior

The actual generated /etc/resolv.conf is:

nameserver 192.168.1.1
nameserver vpn nameserver1
nameserver vpn nameserver2
search host1 host2 host3 etc

When the VPN has an internal domain that also exists publicly, name resolution fails because it tries the LAN/public nameserver first. When I rearrange the nameserver order so that the VPN nameservers are first, everything gets resolved properly.

The Windows host already appears to do this when the VPN adapter (Ethernet3) is connected:

InterfaceAlias               Interface ConnectionSpecificSuffix ConnectionSpecificSuffix RegisterThisConn UseSuffixWhen
                             Index                              SearchList               ectionsAddress   Registering
--------------               --------- ------------------------ ------------------------ ---------------- -------------
Ethernet 3                          22 core.dc                  {}                       True             False
Local Area Connection* 1             7                          {}                       True             False
Local Area Connection* 2            17                          {}                       True             False
Wi-Fi                                5                          {}                       True             False
Loopback Pseudo-Interface 1          1                          {}                       True             False
vEthernet (Default Switch)          27                          {}                       False            False

Diagnostic Logs

No response

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

• Only first nameserver is used from /etc/resolv.conf when I use VPN (#2884), similarity score: 0.83
• /etc/resolv.conf is wrong when using VPN (#1986), similarity score: 0.75

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[leorg99]

I think rearranging the name servers breaks other things. I am not sure what is the correct solution. Most of the internal VPN domains resolve properly except for ones ending in .internal. They resolve on the Windows host with the VPN adapter, but not wsl2 with Debian.

[leorg99]

In the end, I made it work using dnsmasq.

With networkingMode=mirrored and VPN connected (via Windows Cisco AnyConnect), my resolv.conf looked like:

nameserver 192.168.1.1
nameserver vpn nameserver1
nameserver vpn nameserver2
search host1 host2 host3 etc

This worked for the most part except for .internal, which seemed to use go through 192.168.1.1 and not the corp vpn DNS servers. I also had an issue with docker run --rm -it alpine:edge apk update failing to resolve dl-cdn.alpinelinux.org, which went away when I disconnected from VPN.

With networkingMode=mirrored and dnsTunneling=true and trying different combinations of useWindowsDnsCache and bestEffortDnsParsing, I had all kinds of weird DNS issues. This was even less usable than with just networkingMode=mirrored .

In the end, I installed dnsmasq.
My /etc/dnsmasq.conf looks like:

# anything without dots in it doesn't get forwarded to DNS
domain-needed
no-resolv
bogus-priv

# only bind to the localhost IP
listen-address=127.0.0.53

# specifically do not provide any other service than DNS
no-dhcp-interface=lo

# only bind to the interface(s) listed above
# default is to bind to all interfaces even though you specified only one above
bind-interfaces

# enable DNS Cache and adjust cache-size
cache-size=1000

log-queries

server=8.8.8.8                   # resolve default
server=/foo/10.125.40.51 # resolve foo with corp dns1
server=/foo/10.125.40.52 # resolve foo with corp dns2
server=/bar/10.125.40.51
server=/bar/10.125.40.52

I updated /etc/wsl.conf:

[boot]
systemd=true
[network]
generateResolvConf = false

and changed /etc/resolv.conf to:

nameserver 127.0.0.53

I forgot if I had to enable the dnsmasq service but it would be

sudo systemctl enable dnsmasq

If it was already running, you have to restart it to load the changed config file:

sudo systemctl restart dnsmasq

I tried to bind dnsmasq to interface=lo and even though I could clearly see dnsmasq was the only process listening to 127.0.0.1:53 and ::1:53, something was blocking or filtering connections to this address. Binding to 127.0.0.53 was the only way to make it work. Could be related to #11312.

Everything now seems to resolve as expected.

[chanpreetdhanjal]

Please follow the networking diagnostic script. https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#collect-wsl-logs-for-networking-issues

It should create a folder like [WslNetworkingLogs-date_ver.zip]

[CatalinFetoiu]

hi @LeorGreenberger. thanks for reporting the issue

when collecting the logs Chanpreet asked for, please have dnsTunneling set to true and the dnsmasq tool disabled/uninstalled, so that we can troubleshoot why dnsTunneling did not work for your scenario. thanks

[CatalinFetoiu]

we had a different report of split DNS issues with DNS tunneling - #10680, which was root caused and we are working to fix.

the root cause could be similar here

[CatalinFetoiu]

we have made a fix for DNS tunneling split DNS problems (fixing #10680). Can you please take KB5036980 published in https://support.microsoft.com/en-us/topic/windows-11-version-22h2-update-history-ec4229c3-9c5f-4e75-9d6d-9025ab70fcce, install it and see if the issue still reproduces?

Please make sure to have DNS tunneling enabled when testing.

If you still encounter issues after installing the KB, please attach networking logs. thanks