Slow DNS resolution time in Debian VMs

[andrewdavidwong]

Qubes OS version (e.g., R3.2):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

debian-8
debian-9

---

Antoine via qubes-users wrote:

I have recently installed Qubes OS and I am experiencing some slow time
resolution in my debian VM. I have checked the /etc/resolv.conf file and
it contains the following lines:

> nameserver 10.137.2.1
> nameserver 10.137.2.254

Playing with dig I can realise that the first IP is working well while
all DNS queries sent to the second one finish in timeout:

> $ dig +short qubes-os.org @10.137.2.1
> 104.25.152.101
> 104.25.151.101
> $ dig +short qubes-os.org @10.137.2.254
> ;; connection timed out; no servers could be reached

In sys-firewall, everything seems OK:

> $ iptables -S -t nat
> [...]
> -A PR-QBS -d 10.137.2.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 10.137.1.1
> -A PR-QBS -d 10.137.2.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 10.137.1.1
> -A PR-QBS -d 10.137.2.254/32 -p udp -m udp --dport 53 -j DNAT --to-destination 10.137.1.254
> -A PR-QBS -d 10.137.2.254/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 10.137.1.254

But I have the feeling something is missing in sys-net:

> $ iptables -S -t nat
> [...]
> -A PR-QBS -d 10.137.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.1.1
> -A PR-QBS -d 10.137.1.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 192.168.1.1
> [...]

where 192.168.1.1 is the expected DNS server on my LAN.

Do you have an idea why this DNAT rule is missing? (I am not sure to
understand why 2 different nameserver are filled in resolv.conf).

[marmarek]

As for missing DNAT rule in sys-net - if DHCP provided only one address, only one rule is added. This is intended behavior. In Linux, /etc/resolv.conf is used sequentially - always first address is tried first and only when it fails the next one is tried. Lack of second DNAT is not a problem, because there is nothing to DNAT to anyway. This all is probably unrelated to slow DNS response.

What applications are slow in DNS resolution? Is it slow with dig?

[marmarek]

As for missing DNAT rule in sys-net - if DHCP provided only one address, only one rule is added. This is intended behavior. In Linux, /etc/resolv.conf is used sequentially - always first address is tried first and only when it fails the next one is tried. Lack of second DNAT is not a problem, because there is nothing to DNAT to anyway. This all is probably unrelated to slow DNS response.

What applications are slow in DNS resolution? Is it slow with dig?

[marmarek]

Oh, I see @unman already posted similar response in the original thread.

[marmarek]

Oh, I see @unman already posted similar response in the original thread.

[unman]

@marmarek
The issue here is that a qube has by default two resolvers configured, but this user only had 1 DNS server on their local network. After the name server on the reporter's network failed (by design), resolution was attempted using the second server configured in the qube - this also failed, of course, but as a timeout. The timeout meant there appeared to be a delay in DNS response.
It's reasonable to configure qubes with two addresses - that provides versatility when changing networks. The only change we could make would be to add a second DNAT rule, with NAT to the same DNS server if only one was configured. That would remove the timeout. Worth it?

[unman]

@marmarek
The issue here is that a qube has by default two resolvers configured, but this user only had 1 DNS server on their local network. After the name server on the reporter's network failed (by design), resolution was attempted using the second server configured in the qube - this also failed, of course, but as a timeout. The timeout meant there appeared to be a delay in DNS response.
It's reasonable to configure qubes with two addresses - that provides versatility when changing networks. The only change we could make would be to add a second DNAT rule, with NAT to the same DNS server if only one was configured. That would remove the timeout. Worth it?

[marmarek]

The only change we could make would be to add a second DNAT rule, with NAT to the same DNS server if only one was configured. That would remove the timeout. Worth it?

👍

[marmarek]

The only change we could make would be to add a second DNAT rule, with NAT to the same DNS server if only one was configured. That would remove the timeout. Worth it?

👍

[unman]

@andrewdavidwong Please close this. The apparent slow resolution arose because OP's network had only one DNS server, configured to reject certain DNS requests, and the netVM therefore fell back to using the second configured DNS server, which did not exist. This was what caused the apparent slow resolution. The (now merged) PR removes the scope for this happening.

[unman]

@andrewdavidwong Please close this. The apparent slow resolution arose because OP's network had only one DNS server, configured to reject certain DNS requests, and the netVM therefore fell back to using the second configured DNS server, which did not exist. This was what caused the apparent slow resolution. The (now merged) PR removes the scope for this happening.