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)?
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.
Are you crazy? Please refrain from posting AI generated content in conversations about security. Seems like a new account too.
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.