DNS

[Antoine]

Hi,

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

Many thanks for your help,

Antoine

[Unman]

> --

No idea - report it as a bug

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Filed a bug report:

https://github.com/QubesOS/qubes-issues/issues/2674

Antoine, you didn't mention which version of Qubes or Debian you're
using, so I assumed Qubes 3.2 and the Debian 8 TemplateVM.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYvLzEAAoJENtN07w5UDAw+rsP/iOfRnkcfKfPONVv5ZjJwIIs
7CONV6Spmp69MK9SrnytzNRu1FXyimXY7/PyDYDkidwF8V/YTIjoxxKVdkCv9nMS
O8psTge4AdJXInQCiFtH8iMb6Qb7RnJ7YJYT+rrIGfKW+ThQolW8/yFnvFExlHor
15zMIifI5jqi+khD+iNY1X81Hv2vjiDxmzD0l6VjODb6Bdu1rQnBF/i73axFDyIZ
eXGjotqW3t7eAm4OBKjZcKWcKnrDrfItqH67CDwEDco837ECYQsjX/DvB7OQcTMY
GkAlNKkXmSMq9GTAyhdMNW4qNUF00vqJeohowlU2WTM0ihDS4rN71TfHnBFi1WRJ
MC3/QCBP4NxJpehz1iYTj4i+TDL1X6JWwcIvsyEPJ7yc3shAPF8WUY/GTwUCozly
VWF2j3gC46od27iO6RkXCKdpYNZjoN1bwRRgTAh/hnosNHuu4fy8Qj0v6Rj1ktVe
JBmdFBI5x2TBuBJatq+wF2SWdEMgu/ThhXelv2sn204P7mqqNa/DgktakGPVNE7X
+kxGsgIeMJUZ3npaNNI5As/WZ+EhNm6rC3KloBqNz5V2Aoq4DRbeOqbLSmCx/4mA
577++Ll4ixOzrh0Zpw1f7uOheVhLVI+VlCUxaoHujh+8a/MSxm0UI1v5kKkGqT0f
LdVJt02d1Rn96HADm/VF
=hp+e
-----END PGP SIGNATURE-----

[Antoine]

On Sun, Mar 05, 2017 at 05:35:03PM -0800, Andrew David Wong wrote:
> Filed a bug report:
>
> https://github.com/QubesOS/qubes-issues/issues/2674
>
> Antoine, you didn't mention which version of Qubes or Debian you're
> using, so I assumed Qubes 3.2 and the Debian 8 TemplateVM.

In fact, I am using a Debian 9 TemplateVM.

Antoine

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thanks. I've updated the bug report.

However, please note that Debian 8 has gone more extensive testing
than Debian 9 as a TemplateVM. You may wish to try Debian 8 to see
whether this resolves your problem.

https://www.qubes-os.org/doc/supported-versions/#templatevms

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYvf9hAAoJENtN07w5UDAwd4wP/iPxL+W+Skap6XzBRmNdPR2i
PuBbS6iLd46YiUaRR06jGG2Iha6g/jNkDPLeWBcWWFXxJnFiE3iJSTrElTZgPLEC
TZpdOhDftejZ8/7cLmXnLI8aec24cubB6bZBZUymUs9BgqQQgJiLJfwHg0TCOsRJ
skysZttUBYh0WZDlyHRecRNl7D6SikfD12OKGuxEy7I3kOZfuC37cai/mF5KHfRf
ypPkj7pkvr7FYdUd65SP8KNc8U5IsoBeyDXfjJ4UYbo2/+B9lUPicULB2oBuBNPQ
cYukQbHJTC03thHWr3OCkD3jfQlXDaJO9JsVMfrzaYuVONRPQhHIB0tKKhvI9kO/
05h7dMLdN5rjiX3bl9nHZMuJ3CrXMYjT9P1qL85EP2/Wamb4a/16XjX2bLftj6iK
peKG0zgGwnOaFjoBLFyhTcL6YMSyWzcxAkwLWhr0o8lEayztBFk/lQjP46DeLcFB
ZGS24S85K5s026i73bDQ+YAxhY/dgCPVt/APDyfXZ3HW0jQRN0WvFPdk6B0FGgWR
BBZaZDE+rXlpwJTyoZbflymjHk8I5JvC25cMXeZz2YBodmS8SCV0LKj0DwO5xSLc
9uhwZ6sLLDdopFXD7faFEZwzbn3WyAqGUF/6zvcec6LMW87IW1a3/XJENjaM2YQG
Ac+kZnIOp8zhShaHCwcK
=oAkz
-----END PGP SIGNATURE-----

[Antoine]

On Mon, Mar 06, 2017 at 04:31:31PM -0800, Andrew David Wong wrote:
> >> Filed a bug report:
> >>
> >> https://github.com/QubesOS/qubes-issues/issues/2674
> >>
> >> Antoine, you didn't mention which version of Qubes or Debian
> >> you're using, so I assumed Qubes 3.2 and the Debian 8
> >> TemplateVM.
> >
> > In fact, I am using a Debian 9 TemplateVM.
> >
> > Antoine
> >
>
> Thanks. I've updated the bug report.
>
> However, please note that Debian 8 has gone more extensive testing
> than Debian 9 as a TemplateVM. You may wish to try Debian 8 to see
> whether this resolves your problem.

I have the same problem with Fedora 23, Debian 8 and Debian 9:

= Fedora 23 =
[user@work ~]$ grep PRETTY /etc/os-release
PRETTY_NAME="Fedora 23 (Workstation Edition)"
[user@work ~]$ cat /etc/resolv.conf
nameserver 10.137.2.1
nameserver 10.137.2.254
[user@work ~]$ dig +short gov.uk @10.137.2.1
23.235.33.144
23.235.37.144
[user@work ~]$ dig +short gov.uk @10.137.2.254

;; connection timed out; no servers could be reached

= Debian 8 =
user@cloud:~$ grep PRETTY /etc/os-release
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
user@cloud:~$ cat /etc/resolv.conf
nameserver 10.137.2.1
nameserver 10.137.2.254
user@cloud:~$ dig +short gov.uk @10.137.2.1
23.235.33.144
23.235.37.144
user@cloud:~$ dig +short gov.uk @10.137.2.254

;; connection timed out; no servers could be reached

= Debian 9 =
user@Email:~$ grep PRETTY /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
user@Email:~$ cat /etc/resolv.conf
nameserver 10.137.2.1
nameserver 10.137.2.254
user@Email:~$ dig +short gov.uk @10.137.2.1
23.235.33.144
23.235.37.144
user@Email:~$ dig +short gov.uk @10.137.2.254

;; connection timed out; no servers could be reached

Do you have an advise how to remove 10.137.2.254 from the list of
default name servers?

Many thanks,

Antoine

[Unman]

Probaly more relevant would be for you to discover why the first
nameserver isnt reachable or isnt responding.
With multiple entries they are queried in the order given, so if the
first is working correctly the second entry wont be hit.

Thats the real problem.
.

[Antoine]

On Tue, Mar 07, 2017 at 09:08:07PM +0000, Unman wrote:
> On Tue, Mar 07, 2017 at 09:56:23PM +0100, 'Antoine' via qubes-users wrote:
> > On Mon, Mar 06, 2017 at 04:31:31PM -0800, Andrew David Wong wrote:
> > > >> Filed a bug report:
> > > >>
> > > >> https://github.com/QubesOS/qubes-issues/issues/2674

I have understood why I have this problem.

On my LAN, the DNS recursive server (unbound) has a blacklist: it
refuses to answer queries for tracking/ad domains. The problem is that
when a program receives a "REFUSED" packet from its DNS query, it tries
to solve the same host on the second DNS server in resolv.conf.

I can see the pattern clearly using tcpdump: Query -> fast answer
REFUSED -> Query on the second DNS server -> no answer.

On the DNS resolver:
# grep facebook unbound-blacklist.conf
local-zone: "facebook.com" refuse

on any Qubes VM:
$ host facebook.com 10.137.2.1
Using domain server:
Name: 10.137.2.1
Address: 10.137.2.1#53
Aliases:

Host facebook.com not found: 5(REFUSED)
$ host facebook.com 10.137.2.254
[... 10s ...]

;; connection timed out; no servers could be reached

$ host facebook.com
Host facebook.com not found: 5(REFUSED)
$ ping facebook.com
[... 10s ...]
ping: facebook.com: Temporary failure in name resolution

I do not understand why this second DNS server is populated in all Qubes
VM. Is there a simple way to configure only 1 DNS server?

Antoine

[Unman]

If you had two servers on your network, or your DHCP server gave out two
addresses both would be used, I think.
If you want to lose one, you could overwrite it from rc.local or use
bind-dirs on resolv.conf: both methods are covered in the docs.
Look at www.qubes-os.org/doc/config-files

[Antoine]

On Thu, Mar 09, 2017 at 12:30:21AM +0000, Unman wrote:
> > > > > >> https://github.com/QubesOS/qubes-issues/issues/2674
> > > > I have the same problem with Fedora 23, Debian 8 and Debian 9:
> > > >
> > > > = Fedora 23 =
> > > > [user@work ~]$ grep PRETTY /etc/os-release
> > > > PRETTY_NAME="Fedora 23 (Workstation Edition)"
> > > > [user@work ~]$ cat /etc/resolv.conf
> > > > nameserver 10.137.2.1
> > > > nameserver 10.137.2.254
> > > > [user@work ~]$ dig +short gov.uk @10.137.2.1
> > > > 23.235.33.144
> > > > 23.235.37.144
> > > > [user@work ~]$ dig +short gov.uk @10.137.2.254
> > > > ;; connection timed out; no servers could be reached

The issue is that my DHCP server is only giving 1 DNS server. I do not
understand why Qubes thinks I have 2.

Antoine

[Unman]

No the issue is that the 1 DNS server you use doesn't resolve some
addresses. I assume this is how you like it so I'm not clear really on
what the problem is.

I have suggested to you how you can easily remove the second listing if
that bothers you. (You've cut that from my reply).
Alternatively you could customise sys-net to provide
DNS services from some other servers, or add a second redirect rule to
the one server you have. I don't see why that would be an advantage -
surely your applications would time out in exactly the same way that
they do at present?
And if you added a second server that *doesn't* filter requests, why have
one that *does* as your primary server?

[Antoine Sirinelli]

On Thu, Mar 09, 2017 at 12:30:21AM +0000, Unman wrote:

> If you had two servers on your network, or your DHCP server gave out two
> addresses both would be used, I think.
> If you want to lose one, you could overwrite it from rc.local or use
> bind-dirs on resolv.conf: both methods are covered in the docs.
> Look at www.qubes-os.org/doc/config-files
>

On Sat, Mar 11, 2017 at 11:02:29PM +0000, Unman wrote:
> No the issue is that the 1 DNS server you use doesn't resolve some
> addresses. I assume this is how you like it so I'm not clear really on
> what the problem is.
>
> I have suggested to you how you can easily remove the second listing if
> that bothers you. (You've cut that from my reply).
> Alternatively you could customise sys-net to provide
> DNS services from some other servers, or add a second redirect rule to
> the one server you have. I don't see why that would be an advantage -
> surely your applications would time out in exactly the same way that
> they do at present?
> And if you added a second server that *doesn't* filter requests, why have
> one that *does* as your primary server?

Thank you for spending time to answer me but I still do not understand
why Qubes configures 2 DNS servers in /etc/resolv.conf in the VMs.

To summarise, I have one DNS server on my network. My DHCP server passes
only this DNS server adresses (Option 6). I may have missed something on
Qubes behaviour but why does Qubes decides to use 2 DNS server?

I understand your workaround to remove the second DNS server in VMs but
I would like to understand why it appears.

On a side note, on this network, I have plenty of different devices
connected with OS and I never had any issue with a second DNS server
appearing in the auto-configuration.

Thank you again for your help,

Antoine