Zelbinion

Windows 10 Pro (1903 – build 18362.836) + Hyper-V + Ubuntu 20.04 (quick create) = DNS does not resolve inside VM

Hi, I just created an Ubuntu 20.04 VM (using Quick Create) in hyper-v on a Windows 10 Pro machine (version 1903, build 18362.836)

and while I can ping/telnet to other hosts (both on my local lan and also on the internet) DNS resolution does not work.

I am using the "default switch" for the VM with the default settings. The host machine has no issues with DNS resolution.

I also have an ubuntu console via WSL, and it has no issues with DNS resolution.

For example in the Ubuntu VM:

>nslookup microsoft.com

I get:

;; connection timed out; no servers could be reached

When I try name resolution with an external DNS server (e.g. cloudflare)

>nslookup microsoft.com 1.1.1.1

I get:

;; connection timed out; no servers could be reached

Or when I try this:

>dig @1.1.1.1 microsoft.com

I get:

; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 microsoft.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

(both of these commands work find in my Ubuntu WSL console, and nslookup works find in the windows CMD terminal)

From within the Ubuntu VM:

I can ping the cloudflare DNS server using the ip address (e.g. ping 1.1.1.1) so networking and ICMP is working.

I can telnet to 1.1.1.1 on port 53, so TCP is working (other IPs work as well)

…and this works:

>nc -z -v -u 1.1.1.1 53

Connection to 1.1.1.1 53 port [udp/domain] succeeded!

So I can reach an external DNS server via UDP on port 53, and that works too, so doesn’t seem like it can be a problem with networking, firewalls, VPNs, whatever… (I’ve tried several other public DNS servers, including google (8.8.8.8) with the same results.

…and yet no attempt to resolve a hostname (or even a reverse lookup) works.

Interestingly, if I force a TCP connection for dig with the +tcp flag, I can get hostnames to resolve, but only with external servers. In other words:

This works: >dig @1.1.1.1 microsoft.com +tcp

This does not: >dig microsoft.com +tcp

/etc/resolv.conf is:

nameserver 127.0.0.53

options edns0

search mshome.net

and the output of systemd-resolve -status is:

Global
       LLMNR setting: no
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.192.in-addr.arpa
                      18.192.in-addr.arpa
                      19.192.in-addr.arpa
                      20.192.in-addr.arpa
                      21.192.in-addr.arpa
                      22.192.in-addr.arpa
                      23.192.in-addr.arpa
                      24.192.in-addr.arpa
                      25.192.in-addr.arpa
                      25.192.in-addr.arpa
                      27.192.in-addr.arpa
                      28.192.in-addr.arpa
                      29.192.in-addr.arpa
                      30.192.in-addr.arpa
                      31.192.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 2 (eth0)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 192.168.150.81
         DNS Servers: 192.168.150.81
          DNS Domain: ~.
                      mshome.net

(note: 192.168.150.81 is the IP address of the "vEthernet (Default Switch)" Ethernet adapter)

Everything (hyper-V, the default switch, Ubuntu, etc.) is using default settings. I’m at a loss. I could understand if simply doing a name lookup via nslookup using the default name servers didn’t work, as that is probably a resolver configuration problem.
However, specifying an external, reachable DNS sever, and it STILL fails to resolve (at least with the default UDP), and ONLY with the VM — everything else, including WSL, works fine… I don’t get it.

Anyone have any ideas?

Read full post . . . .

Go Que Newsroom Categories

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 46 bytes) in /home/content/36/8658336/html/goquecom/wp-includes/wp-db.php on line 1995