Integration of DNSSEC - Githubissues

rugk commented 8 years ago

A DNSSEC verification by default would be a nice thing to have.

Also some DNSCrypt servers (see https://github.com/QubesOS/qubes-issues/issues/2341) offer DNSSEC. Of course, however, if you trust the DNSCrypt server enough, you do not have to verify DNSSEC, but yeah I know... Qubes OS trust's nobody. :smile:

andrewdavidwong commented 8 years ago

Which Qubes component(s) are you proposing that DNSSEC be implemented in?

rugk commented 8 years ago

The local DNS resolver if there is already one...

Basically the aim is that all applications use a local DNS server (You know, never trust something outside of the device) and that this DNS resolver uses DNSSEC to verify the DNS responses.

As said this is best combined with https://github.com/QubesOS/qubes-issues/issues/2341.

adrelanos commented 7 years ago

https://wiki.debian.org/DNSSEC

On Debian DNSSEC can be made to work by installing dnssec-trigger. But I don't know what it actually does. If it uses the user's ISP DNS server and just enables DNSSEC or uses some alternative DNS server.

rugk commented 7 years ago

I think the dns server should/is not be changed automatically.

adrelanos commented 2 years ago

Linking all the DNS security related ticket together:

TommyTran732 commented 1 year ago

Both Fedora and Debian are using systemd-resolved now. Maybe it would be nice to just set DNSSEC=allow-downgrade in /etc/systemd/resolved.conf by default in the TemplateVMs?

It would also be nice to have a Qubes service to automatically change this to DNSSEC=true if the user confirms that their DNS servers support DNSSEC and wants it to always be on.

adrelanos commented 1 year ago

/etc/systemd/resolved.conf

If anything, use drop-in files in /usr/lib. Something similar to /usr/lib/systemd/resolved.conf.d/30-config-name.conf.

Both Fedora and Debian are using systemd-resolved now. Maybe it would be nice to just set DNSSEC=allow-downgrade in /etc/systemd/resolved.conf by default in the TemplateVMs?

Quote systemd-resolved man page DNSSEC=:

DNSSEC= ... Defaults to "allow-downgrade".

So that's already the default, no need then? Or does Fedora / Debian set this to false?

It would also be nice to have a Qubes service to automatically change this to DNSSEC=true if the user confirms that their DNS servers support DNSSEC and wants it to always be on.

I think most users won't know that. Could lead to broken connectivity. So Qubes would have to test this. You could also check if there's a feature request for systemd-resolved to autodetect this.

Another alternative would be to have an option for Qubes to automatically set up encrypted and/or authenticated (DNSSEC) by choosing Qubes built-in servers.

Edit: That was discussed here: https://github.com/QubesOS/qubes-issues/issues/2341#issuecomment-250786742

3hhh commented 1 year ago

Qubes OS redirects DNS requests via DNAT to the next VM downstream. systemd-resolved will be bypassed even if you explicitly enable it. In the last VM (usually sys-net), NetworkManager takes over and usually forwards DNS requests to what your DHCP server advises as DNS server.

There are ways to configure Qubes OS to use systemd-resolved with DNSSEC, but it doesn't make much sense if you have an explicit trusted DNS resolver with DNSSEC (e.g. sys-dns or your router) in your network. Multiple DNSSEC-enabled resolvers will just slow down your DNS requests. Also, it increases the attack surface and it remains unclear where to put such a resolver (dedicated VM, sys-net, sys-fw, sys-whonix, sys-vpn, ... ?).

So a bad default IMHO. More like something that might have to be documented properly.

Btw personally I use unbound as DNSSEC resolver inside a sys-dns VM for my VPN network and systemd-resolved as DNS cache without DNSSEC in all firewall VMs to get proper DNS blocking #5225.

TommyTran732 commented 1 year ago

It is true that the closest VM that handles networking will take over also handles DNS. If DNSSEC is enabled by default in the template, then wouldn't the user still effectively having DNSSEC?

Also I don't know how it doesn't make sense to enable this by default. Take for example, we have a user who uses a sys-vpn qubes.

DNS resolution done with with DHCP provided DNS by sys-net for AppVMs not going through sys-vpn is validated.
DNS resolution done with with DHCP provided DNS by sys-vpn for AppVMs going through sys-vpn is validated.

systemd-resolved does not actually run in the non-network VMs, so I don't understand how it could slow down DNS requests.

TommyTran732 commented 1 year ago

Both Fedora and Debian are using systemd-resolved now. Maybe it would be nice to just set DNSSEC=allow-downgrade in /etc/systemd/resolved.conf by default in the TemplateVMs?

I am not sure. The config file has DNSSEC=false commented out.

3hhh commented 1 year ago

There may be multiple VMs that handle networking in the same network path, e.g. a sys-snort proxy VM, an update cacher, a wireshark man-in-the-middle proxy VM, ...

Also, as I had previously mentioned, it doesn't make too much sense to do DNSSEC if a downstream VM or your router already does it. I accidentally ran with that setup for a while and had 50-100ms latencies per uncached DNS request. systemd-resolved even ran into some weird key issues multiple times resulting in no DNS at all (unbound worked just fine btw). Not much fun.

And then there's still the increased security posture caused by a few thousand lines of code running a non-trivial protocol.

So it's not a cup of tea for everyone = doesn't make sense as default.

I agree that using custom DNS servers or implementing one's own sys-dns should be more accessible though.

QubesOS / qubes-issues

Integration of DNSSEC #2344