DNS answers back with dns as A records as well.

[ZeroInputCtrl]

• Your Windows build number: Microsoft Windows [Version 10.0.19541.1000]

• What you're doing and what's happening: nslookup docker-01.ky1.home

• What's wrong / what should be happening instead:
  I have a local bind dns for facilitating a local to my network domain name ky1.home.
  When running the command on WSL2 ubuntu and debian i get:

Server:         172.18.128.1
Address:        172.18.128.1#53

Non-authoritative answer:
Name:   docker-01.ky1.home
Address: 10.222.11.110
Name:   ns1.ky1.home
Address: 10.222.11.81
Name:   ns2.ky1.home
Address: 10.222.11.82

dig response for the same address

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> docker-01.ky1.home
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36872
;; flags: qr rd ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;docker-01.ky1.home.            IN      A

;; ANSWER SECTION:
docker-01.ky1.home.     0       IN      A       10.222.11.110
ns1.ky1.home.           0       IN      A       10.222.11.81
ns2.ky1.home.           0       IN      A       10.222.11.82

;; Query time: 1 msec
;; SERVER: 172.18.128.1#53(172.18.128.1)
;; WHEN: Wed Jan 22 09:05:19 EST 2020
;; MSG SIZE  rcvd: 126

As you can see the nameservers are being answered back by the wsl nameserver.
When i run the same command in the standard windows CMD it comes back clean.

Server:  ns1.ky1.home
Address:  10.222.11.81

Name:    docker-01.ky1.home
Address:  10.222.11.110


C:\Users\thowe>

On another server on my network running debian i get

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   docker-01.ky1.home
Address: 10.222.11.110

root@odroid-01:/mnt/gv1#

Normally this wouldn't be much of an issue except when i try to access a server for something and that server is down i end up getting pointed to my nameserver instead of failing which is fairly annoying.

[chutzimir]

Indeed, I stumbled upon the same problem when trying to connect to a machine which was not available so my SSH decided to use the next IP in the answer.

As a workaround, I am pointing my WSL guests to the appropriate resolvers and bypassing the WSL host.

The issue is very easy to reproduce with any public hostname. From inside WSL I did the same query against 172.31.16.1 (the WSL bridge), and against 10.136.80.82 which is the DNS resolver which the Windows host is using.

For what it's worth, this is WSL2.

C:\>ver

Microsoft Windows [Version 10.0.19041.21]

dig against WSL host:

$ dig @172.31.16.1 github.com

; <<>> DiG 9.11.14-3ubuntu1-Ubuntu <<>> @172.31.16.1 github.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5304
;; flags: qr rd ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;github.com.                    IN      A

;; ANSWER SECTION:
github.com.             0       IN      A       52.69.186.44
ns3.p16.dynect.net.     0       IN      A       208.78.71.16
ns-1283.awsdns-32.org.  0       IN      A       205.251.197.3
ns-1283.awsdns-32.org.  0       IN      AAAA    2600:9000:5305:300::1
ns-421.awsdns-52.com.   0       IN      A       205.251.193.165
ns-421.awsdns-52.com.   0       IN      AAAA    2600:9000:5301:a500::1
ns-1707.awsdns-21.co.uk. 0      IN      A       205.251.198.171
ns-1707.awsdns-21.co.uk. 0      IN      AAAA    2600:9000:5306:ab00::1
ns2.p16.dynect.net.     0       IN      A       204.13.250.16
ns1.p16.dynect.net.     0       IN      A       208.78.70.16
ns-520.awsdns-01.net.   0       IN      A       205.251.194.8
ns-520.awsdns-01.net.   0       IN      AAAA    2600:9000:5302:800::1
ns4.p16.dynect.net.     0       IN      A       204.13.251.16

;; Query time: 1 msec
;; SERVER: 172.31.16.1#53(172.31.16.1)
;; WHEN: Tue Feb 04 20:33:17 JST 2020
;; MSG SIZE  rcvd: 450

Compare the above with the output from our internal DNS resolver, which gives the NS record A addresses in the additional section.

$ dig github.com  @10.136.80.82

; <<>> DiG 9.11.14-3ubuntu1-Ubuntu <<>> github.com @10.136.80.82
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10555
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;github.com.                    IN      A

;; ANSWER SECTION:
github.com.             32      IN      A       52.69.186.44

;; AUTHORITY SECTION:
github.com.             807     IN      NS      ns2.p16.dynect.net.
github.com.             807     IN      NS      ns3.p16.dynect.net.
github.com.             807     IN      NS      ns1.p16.dynect.net.
github.com.             807     IN      NS      ns-1283.awsdns-32.org.
github.com.             807     IN      NS      ns-520.awsdns-01.net.
github.com.             807     IN      NS      ns-421.awsdns-52.com.
github.com.             807     IN      NS      ns4.p16.dynect.net.
github.com.             807     IN      NS      ns-1707.awsdns-21.co.uk.

;; ADDITIONAL SECTION:
ns-421.awsdns-52.com.   3114    IN      A       205.251.193.165
ns-421.awsdns-52.com.   3114    IN      AAAA    2600:9000:5301:a500::1
ns2.p16.dynect.net.     3416    IN      A       204.13.250.16
ns4.p16.dynect.net.     3416    IN      A       204.13.251.16
ns3.p16.dynect.net.     3416    IN      A       208.78.71.16
ns-1707.awsdns-21.co.uk. 3207   IN      A       205.251.198.171
ns-1707.awsdns-21.co.uk. 3207   IN      AAAA    2600:9000:5306:ab00::1
ns1.p16.dynect.net.     3416    IN      A       208.78.70.16
ns-1283.awsdns-32.org.  3110    IN      A       205.251.197.3
ns-1283.awsdns-32.org.  3110    IN      AAAA    2600:9000:5305:300::1
ns-520.awsdns-01.net.   3207    IN      A       205.251.194.8
ns-520.awsdns-01.net.   3207    IN      AAAA    2600:9000:5302:800::1

;; Query time: 1 msec
;; SERVER: 10.136.80.82#53(10.136.80.82)
;; WHEN: Tue Feb 04 20:37:17 JST 2020
;; MSG SIZE  rcvd: 515

[tszalay]

I'm seeing this issue as well, for nameservers on our companies' intranet when working remotely on VPN (which will be the case for the foreseeable future). I'm redacting slightly for intranet privacy reasons, but functionally it's the same:

szalay@TwentyFourKarat:~$ dig gerrit.<company domain> ; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> gerrit.<company domain> ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44945 ;; flags: qr rd ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;gerrit.<company domain>. IN A ;; ANSWER SECTION: gerrit.<company domain>. 0 IN CNAME alias.<company domain>. alias.<company domain>. 0 IN A 10.232.15.1 # Tamas: this is the correct answer <company DNS server name>. 0 IN A <company DNS server IP> ;; Query time: 15 msec ;; SERVER: 172.30.80.1#53(172.30.80.1) ;; WHEN: Thu Mar 26 18:13:24 EDT 2020 ;; MSG SIZE rcvd: 214

where 172.30.80.1 is the WSL DNS server.
This makes any of our intranet websites inaccessible, unfortunately.

As a side note, the DNS search suffixes configured by our VPN on Windows also are ignored by WSL DNS server; I'm sure there's an issue for that elsewhere.

[maketsi]

This issue still exists on 10.0.19041.508, and is most likely the reason for all DNS related problems other issue tickets mention about. Often, other people just complain that ping/apt/something else doesn't connect, which they can't, because those NS servers don't have the services running that you try to reach.
The only current workaround is to statically use any other DNS server address besides the Hyper-v one, but that is an annoyance when your VPN/ISP/network provider blocks all external non-authorized DNS servers, and doesn't help for resolving any internal hosts either. Current best fix is to manually replicate the host's DNS resolver IPs to resolv.conf, bypassing hyper-v mangling.

[timriker]

This looks like #5806

[microsoft-github-policy-service]

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!