DNScrypt support

The problem you're addressing (if any)
DNS resolving via DNScrypt.

Describe the solution you'd like
Run DNScrypt-proxy in firewall-vm and forward DNS-requests to that service.

Where is the value to a user, and who might that user be?
DNScrypt is a fast and reliable solution to encrypt and authenticate DNS traffic. Actually I would expect every operating system to protect DNS traffic. Protection of DNS traffic concerns all users of operating systems which utilise the internet. There are DoT and DoH also, but so far DNScrypt worked best for me.

Describe alternatives you've considered
I have not considered an alternative so far. I have tried DoT and DoH in different setups but their performance hasn't been convincing.

Additional context
This is just a quick hack. I'm interested in your perspective, especially if you have security concerns.

Relevant documentation you've consulted
https://www.qubes-os.org/doc/contributing/

Related, non-duplicate issues
#2341
#2344
https://github.com/DNSCrypt/dnscrypt-proxy
https://blog.tufarolo.eu/how-to-configure-pihole-in-qubesos-proxyvm/

To enable DNScrypt for Qubes-OS it takes two steps:

Step 1:

# start FEDORA-TEMPLATE-VM and run a terminal
sudo su
dnf install dnscrypt-proxy
# do not (!) enable the dnscrypt-proxy.service
# shutdown FEDORA-TEMPLATE-VM
# restart all VMs which use the FEDORA-TEMPLATE

Step 2:

# open a terminal in SYS-FIREWALL
sudo su
cd /rw/config
vi rc.local
# insert the lines below at the end of rc.local
# save and close file
# shutdown and restart SYS-FIREWALL

# start dnscrypt-proxy
systemctl start dnscrypt-proxy.service
# tweak iptables
iptables -t nat -F PR-QBS
iptables -t nat -I PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to-destination 127.0.0.1
iptables -I INPUT -i vif+ -p udp --dport 53 -d 127.0.0.1 -j ACCEPT
# enable traffic coming from the virtual interfaces to be forwarded to the loopback interface
find /proc/sys/net/ipv4/conf -name "vif*" -exec bash -c 'echo 1 | sudo tee {}/route_localnet'
find /proc/sys/net/ipv6/conf -name "vif*" -exec bash -c 'echo 1 | sudo tee {}/route_localnet'

Further considerations:

1. There is no need to use unbound or dnsmasq since dnscrypt-proxy already caches DNS-requests.
2. To run an extra VM for dnscrypt-proxy seemed a bit overkill to me.
3. It is reasonable to trust dnscrypt-proxy since it is part of the fedora distribution which we put our trust in.
4. Whonix Tor traffic is not affected, all traffic including DNS is still tunneled through the Tor network as far as I can tell. However, I am going to investigate by which means Tor is protecting DNS traffic.

[andrewdavidwong]

Hm, this looks like a feature request for DNScrypt to be an option in Qubes rather than an actual package contribution.

Agreed. If you consider to implement DNScrypt support for the next qubes-os release I would greatly appreciate that. Until then I am helping myself with the above hack.

Btw, for those who like to use DNScrypt-proxy, the size of the DNS-cache can be adjusted in the Fedora-TEMPLATE-VM under

/etc/dnscrypt-proxy/dnscrypt-proxy.toml

I'm still interested in the qubes-os security team's perspective on my hack. Does the iptables-tweaking raise any eyebrows? Or enableing traffic to Firewall-VM's localhost?

[3hhh]

iptables -t nat -I PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to-destination 127.0.0.1
iptables -I INPUT -i vif+ -p udp --dport 53 -d 127.0.0.1 -j ACCEPT

That probably disables the Qubes firewall for DNS.

That's why dedicated VMs and firewall VMs in front of them should be generally preferred, cf. [1], section "network service qubes".

[1] https://www.qubes-os.org/doc/firewall/

[3hhh]

Also, rc.local is a bad place for firewall rules as it's only executed after the network is up (i.e. there may be leaks).

Anyway the likely best infrastructure for DNS would be

sys-net  ------------- sys-fw ---- some VM
      |
        --- sys-dns (AppVM, connected to sys-net)

With DNS for VPN:

sys-net  ------------- sys-fw ---- sys-vpn ----- sys-fw-vpn ---- some VM
                                     |
                                     |  --- sys-dns (AppVM, connected to sys-vpn)

This way you can't break anything in the firewall VMs.

Dnscrypt-proxy could be run seperatly in each App-VM if desired. However, in that case I wouldn't consider encrypted DNS-traffic a feature of Qubes-OS but of the App-VM.

iptables -t nat -I PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to-destination 127.0.0.1
iptables -I INPUT -i vif+ -p udp --dport 53 -d 127.0.0.1 -j ACCEPT

That probably disables the Qubes firewall for DNS.

Are you sure? To me it looks like DNS-traffic is completely redirected to localhost. You could consider that "blocked".

[3hhh]

Dnscrypt-proxy could be run seperatly in each App-VM if desired. However, in that case I wouldn't consider encrypted DNS-traffic a feature of Qubes-OS but of the App-VM.

That sys-dns AppVM provides the DNS service to all upstream (e.g some VM) VMs. That's what my post was about.

iptables -t nat -I PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to-destination 127.0.0.1
iptables -I INPUT -i vif+ -p udp --dport 53 -d 127.0.0.1 -j ACCEPT

That probably disables the Qubes firewall for DNS.

Are you sure? To me it looks like DNS-traffic is completely redirected to localhost. You could consider that "blocked".

Pretty sure.
You DNAT all incoming port 53 traffic to the local DNS service. This way the filter FORWARD chain which holds the Qubes OS firewall is bypassed (traffic to localhost goes to INPUT).
Just try it out: On one of your VMs using the dnscrypt service attempt to disallow DNS via qvm-firewall. Then use e.g. dig or nslookup and you'll likely notice that it still works.

That's why the above "Qubes way" of segregating duties (1 VM for the DNs service, 1 for the firewall, 1 for network) tends to be superior. Apart from the security benefits.

retracted

@andrewdavidwong

First of all thanks to you and the qubes team for all the great work. Qubes-OS is awesome. With this post I want to keep up my feature request.

Only addition to the above mentioned scripts, one could stop systemd-resolved.service by adding something like that to /rw/config/rc.local:

systemctl stop systemd-resolved
echo 'nameserver 127.0.0.1' > /etc/resolv.conf

@evadogstar

Will this proxy work if DNScrypt-proxy will be at the VPN vw which are limited to access the network only if the service run from specific user?

No, in this setup it won't. You could however use the dnscrypt-proxy service in your Proxy-/VPN-VM and route it's traffic through the VPN. I could offer to help with updating the VPN page if desired.

@3hhh

Thanks for your feedback.

iptables -t nat -I PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to-destination 127.0.0.1

This rule is equivalent to the one the Qubes-Team posted for the VPN-/Proxy-VM.

iptables -I INPUT -i vif+ -p udp --dport 53 -d 127.0.0.1 -j ACCEPT

I would consider this rule to be very specific as it allows incoming UDP traffic on 127.0.0.1:53 from vif-interfaces. But I'm not very good at iptables, so giving me input in form of concrete alternative drafts is very welcomed.

That's why the above "Qubes way" of segregating duties (1 VM for the DNs service, 1 for the firewall, 1 for network) tends to be superior. Apart from the security benefits.

I see your point. The above proposed solution is replacing systemd-resolved by dnscrypt-proxy, so it introduces an attack surface as dnscrypt-proxy communicates with the "outside world" but it also reduces the attack surface by shutting down systemd-resolved. The new service is more complex, relying on more lines of code, therefore there might be more known or unknown vulnerabilities. This should be taken into account when establishing a thread model. As you probably know DNS itself can be used to exfiltrate data (see iodine).

PS: major edit... it can't be done without iptables... otherwise dns-traffic is just passed along to 10.139.1.1 or 10.139.1.2...
PPS: I hope this isn't considered necrobumping. If desired I could start a new thread.