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

  • Question

  • 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)

    I have also tried inserting additional DNS servers so that in the output of systemd-resolv --status, the DNS Servers looks like this:

    DNS Servers: 192.168.150.81

                          1.1.1.1

    But this doesn't change the behavior of the VM at all.

    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?

    Thursday, May 21, 2020 2:15 PM

All replies

  • Additional information:

    I've tried creating a new "external" virtual switch, and connecting the Ubuntu guest VM to the external switch, and that works, kind of. When connected to the external virtual switch, Ubuntu gets an IP via DHCP (the same network as the physical Ethernet adapter in the laptop), and also receives nameserver configuration via DHCP. It is able to communicate with those name servers and resolve addresses with no issues.  However, it appears the connection is bridged with the laptop's external Ethernet interface, which means it is not able to take advantage of any VPN connections.  This, unfortunately, is not good enough, because I need the Ubuntu guest VM to be able to connect to hosts which are only available via the VPN. However, it is telling that DNS resolution works without issues when connected to the external virtual switch, indicating that there is not a configuration problem with the guest VM, but that there is something wrong with the "default switch".

    I have also tried creating a new "internal" virtual switch, and connecting the guest Ubuntu VM to that, but it didn't work either. By default, the new "internal" virtual switch is configured for DHCP (which doesn't seem to work for some reason), but even when I configure it for a static IP (similar to how the "default switch" is configured), it doesn't seem to provide a DHCP server to the guest VM, so the guest doesn't get an IP, and that doesn't work either.

    I have also tried using a "legacy" virtual Ethernet adapter for the Ubuntu VM, rather than the default adapter, but that made no difference.

    At this point, all signs seem to point to the "default switch" not working properly, but I can't tell if that's a bug or some sort of configuration issue.

    Thursday, May 21, 2020 4:23 PM
  • Windows 10 Creators Update (Windows 10 version 1703)
    Screen shot of the quick create UI

    Open Hyper-V Manager from the start menu.

    In Hyper-V Manager, Find Quick Create in the right hand Actions menu.

    Customize your virtual desktop server.

    (optional) Give the virtual machine a name.
    Select the installation media for the virtual machine. You can install from a .iso or .vhdx file. If you are installing Windows in the virtual machine, you can enable Windows Secure Boot. Otherwise leave it unselected.
    Set up network. If you have an existing virtual switch, you can select in the network dropdown. If you have no existing switch, you will see a button to set up an automatic network, which will automatically configure a virtual network.
    Click Connect to start your virtual machine. Don't worry about editing the settings, you can go back and change them any time.

    You may be prompted to ‘Press any key to boot from CD or DVD’. Go ahead and do so. As far as it knows, you're installing from a CD.

    Congratulations, you have a new virtual machine. Now you're ready to install the operating system.

    Note: Unless you're running a volume-licensed version of Windows, you need a separate license for Windows running inside a virtual machine. The virtual machine's operating system is independent of the host operating system.
    • Edited by Max-44 Thursday, May 21, 2020 4:59 PM
    Thursday, May 21, 2020 4:54 PM