Host and containers slow DNS but VM works fine

[nwb99]

Strange problem.
I moved my Proxmox host to a "new" system (my old PC, i5-3570k, Sabertooth Z77 and Intel Gigabit CT desktop NIC).
I also recently changed my LAN subnet from 192.168.0.0 to 192.168.10.0, to avoid VPN conflicts with another network I can connect to.

For some reason now, my Proxmox host and its containers have slow DNS response or none at all.
For example, I can ping -4 google.com from either the host or from a container, and it takes many seconds before it'll even begin to ping. The same applies for pinging with IPv6.
Pinging from another PC on the network or from the Debian VM begins returning results instantly.

Today, a major security bug was fixed in the kernel, and Debian released a patch. So, I wanted to update my stuff and check for anything else anyway. I go to update my container(s) and get the following:

However, updating a Debian VM works fine. The VM uses the same 1.1.1.1 IPv4 DNS as the others and it is also delegated an IPv6 address and DNS from my provider (stupid NDP relay with OpenWRT because T-Mobile doesn't support prefix delegation. I'm rural.).

Now, I can ping security.debian.org from my PC running Windows or from the Debian VM just fine. And it does so instantly. However, I can't get the host or containers to do it always. It seems to be hit or miss.

resolv.conf from Proxmox host:

search local
nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 2606:4700:4700::1111

resolv.conf from Debian container:

# --- BEGIN PVE ---
search Mars.local
nameserver 1.1.1.1
# --- END PVE ---

ip a output from Proxmox host:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether 68:05:ca:42:cb:d5 brd ff:ff:ff:ff:ff:ff
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 68:05:ca:42:cb:d5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.10/24 brd 192.168.10.255 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 2607:fb90:REDACTED/64 scope global dynamic mngtmpaddr
       valid_lft 86159sec preferred_lft 86159sec
    inet6 fe80::6a05:caff:fe42:cbd5/64 scope link
       valid_lft forever preferred_lft forever
4: veth100i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether fe:59:f3:ac:f4:d0 brd ff:ff:ff:ff:ff:ff link-netnsid 0
5: tap101i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
    link/ether 32:c1:21:e4:5d:0f brd ff:ff:ff:ff:ff:ff
6: veth102i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether fe:f1:c2:e9:f0:3b brd ff:ff:ff:ff:ff:ff link-netnsid 1

ip a output from a container:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ae:10:90:d4:2e:90 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.10.15/24 brd 192.168.10.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2607:fb90:REDACTED/64 scope global dynamic mngtmpaddr
       valid_lft 86100sec preferred_lft 86100sec
    inet6 fe80::ac10:90ff:fed4:2e90/64 scope link
       valid_lft forever preferred_lft forever

/etc/network/interfaces from Proxmox host:

auto lo
iface lo inet loopback

iface enp3s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.10.10/24
        gateway 192.168.10.1
        bridge-ports enp3s0
        bridge-stp off
        bridge-fd 0

/etc/network/interfaces from a Debian container:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.10.15/24
        gateway 192.168.10.1

iface eth0 inet6 auto

/etc/network/interfaces from Debian VM:

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens18
iface ens18 inet static
        address 192.168.10.13
        gateway 192.168.10.1
        netmask 255.255.255.0
        dns-nameserver 1.1.1.1

I do not believe any firewalls are enabled in Proxmox, since all of this used to work fine a few days ago before I made any changes.

Note: pings and iperf tests between PCs on the same network (192.168.10.0/24 and the IPv6's given out by T-Mobile /64) works flawlessly.

thanks

 

[Lorenz.S]

Hi,

as far as I know, IPv6 is always preferred if it is possible. The only difference between the resolve.conf's is the IPv6 address. Try it with only IPv4 DNS servers on the PVE host, perhaps this helps.

 

[nwb99]

Hi,

as far as I know, IPv6 is always preferred if it is possible. The only difference between the resolve.conf's is the IPv6 address. Try it with only IPv4 DNS servers on the PVE host, perhaps this helps.

thanks for your response!

I actually tried disabling IPv6 entirely on the host (including removing the IPv6 DNS you mentioned), and therefore containers, by passing ipv6.disable=1 to the kernel in /etc/default/grub. I verified IPv6 was disabled when a ping6 failed to resolve. Still, it seems the apt update was slow. Pings sometimes start instantly, sometimes not. No dropped packets or anything. I suspect it's T-Mobile's garbage IPv6 DNS servers. I've set the IPv6 DNS servers and the host DNS servers. While ping seems to be still slow to start randomly, apt is still slow, reporting in bytes/s but working nonetheless. Something odd is going on. Debian VM continues to work fine though.

 

[wolframio]

Hello, i had the same problem, but host works fine and VM or CT are have slow or dead DNS, cant solve anyway, is not my dns server, firewall or anything like that, because ESXI 6.7 works perfect on the machine and the same network.

 

[bobmc]

personally I would recommend to use a local dns server for your internal network,

 

[wolframio]

personally I would recommend to use a local dns server for your internal network,

how you do that? i try using a dns server that is running on my lan, but you mean running inside the VM?

 

[bobmc]

I would install something like pi-hole as a container on your host and then use that as a dns server for all the devices on your local network.

 

[wolframio]

I would install something like pi-hole as a container on your host and then use that as a dns server for all the devices on your local network.

alredy try that, no luck, what ip should i put on the VM/CT dns¿? 127.0.0.1 or the host IP?

 

[diego555]

I had exactly the same problem,
really frustrating.
(I tried with 2 Ubuntu containers).

workaround:
- set an internal DNS
- set in the etc/hosts the domains and ips that you actually need