I was troubleshooting some DNS issues while using mullvad VPN, and I noticed that my netvms have a set called dns-addr in their nftables. I couldn’t figure out what this is for, what is setting it, and when?
The contents seem to vary. With the mullvad netvms (configured using the method in Mullvad VPN App 4.3 (and 4.2) setup guide ) it sometimes contains the currently configured mullvad DNS server, sometimes a different mullvad DNS server, and sometimes it’s empty.
In my sys-firewall it’s the standard DNS IPs for QubesOS (elements = { 10.139.1.1, 10.139.1.2 })
The set is populated from /etc/resolv.conf, pulling in any content that
starts nameserver. I assume you are seeing the result of some race
condition in populating that field.
It is, I think, set in usr/lib/python3/dist-packages/qubesagent/firewall.py
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Creating a brand new AppVM, starting it and connecting it to a netvm doesn’t seem to generate this set? Although DNS resolution seems to be working fine.
This pref seems to have the same value for all my qubes, including those where there is a dns-addr set, and where this set contains the mullvad DNS IPs. Also, this pref can’t be set manually.
I guess the main question is what this is for and does it matter when it’s missing, or not matching the intended DNS IP (i.e when using mullvad)?
Adding a bit on the “does it matter” part from post #4.
dns-addr is basically the nftables set that Qubes DNAT rules use so AppVM DNS queries get redirected to whatever nameserver entries were present when the firewall/DNAT helper last ran. That is why it tracks /etc/resolv.conf (and why Mullvad can make it bounce around as the VPN DNS changes).
If the set is empty or stale, DNS can still work through other paths (for example the VPN app doing its own DNS, or resolvers that are not going through those DNAT rules). The mismatch usually matters when you expect qubes-setup-dnat-to-ns style redirection to force every port-53 query onto a specific resolver. With Mullvad lockdown/DNS settings doing their own thing, an empty or “wrong” dns-addr is often just a symptom of timing rather than the root of the leak/block.
Practical check: from an AppVM behind the Mullvad netvm, resolve something while watching whether traffic leaves on UDP/TCP 53 toward the Mullvad DNS you intend, and whether dig/nslookup still works with the VPN down (killswitch test). If those look right, I would not chase the set by itself.
Apologies. I misread and thought you were asking about dnat-dns. The reference @unman provided is the correct one. systemctl cat qubes-firewall shows that script is called when the the service is started.
I mentioned the qvm-prefs as you can see the same (read-only) value there too. It is empty for non-networked qubes. The pref does not match the content of /etc/resolv.conf which makes me wonder what value it actually has.