How to overwrite Qubes Virtual DNS 10.139.1.1, 10.139.1.2

[whoami]

@unman

Can you explain why you think this simple solution does not provide an answer to
your simple question?

Since I still do not know what needs to be entered to get lokinet’s DNS working after reboot (after one week).

I would very thankful if you just simply drop me the simple one-liner solution for my simple question even if this proofs that I still need to learn a lot about DNS, Qubes DNS workflow and how to manipulate it. That is fine for me, I still want to learn more about QOS

I tested the official troubleshooting recommendations (for normal Linux distros) with your recommendation:

@unman

make the change using /rw/config/rc.local

echo ‘nameserver 127.3.2.1’ > /etc/resolvconf/resolv.conf.d/head

I also did some tests with
echo ‘nameserver 127.3.2.1’ > /etc/resolv.conf
echo ‘nameserver 127.3.2.1’ > /etc/resolvconf/resolv.conf.d/original

As already stated here:

@whoami

and did the update afterwards but it returns:

etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf

And after every reboot it switches back to the Qubes default DNS.

and here:

@whoami

during the installation routine I see this (I guess this could be a useful info):

Created symlink /etc/systemd/system/sysinit.target.wants/resolvconf.service
→ /lib/systemd/system/resolvconf.service.

Created symlink /etc/systemd/system/systemd-resolved.service.wants/resolvconf-pull-resolved.path
→ /lib/systemd/system/resolvconf-pull-resolved.path.

Created symlink /etc/systemd/system/systemd-resolved.service.wants/resolvconf-pull-resolved.service
→ /lib/systemd/system/resolvconf-pull-resolved.service.

I guess this symlink is the issue here but I have no clue where to start here. I never used / worked with symlink before but what I understood it is simply a link which points to a directory.

I tried your second recommendation: using bind-dirs
As descripted in the docs I made a 50_user.conf and added

/etc/systemd/system

with that I hoped to keep the symlink persistent (which was made during the installation routine). I also did this test with a lokinet-gw and a lokinet-ws setup instead of the previous standalone Qube tests. Both still without success.

Accidentally, I saw @qubist nice Guide on:

[guide] how-to setup a sys-dns qube

The firewall documentation says: “Qubes does not support running any networking services (e.g. VPN, local DNS server, IPS, …) directly in a qube that is used to run the Qubes firewall service (usually sys-firewall) for good reasons. In particular, if you want to ensure proper functioning of the Qubes firewall, you should not tinker with iptables or nftables rules in such qubes.” which sounds confusing because: sys-firewall is not a service, it is a VM the “good reasons” have not been expl…

He also used your recommended /rw/config/rc.local approach:

echo 'nameserver 127.0.0.1' > /etc/resolv.conf

But he used it in a much more complex content and I guess in my case the issue is strongly linked to the way lokinet implemented its DNS.

@qubist maybe you have an additional hint / solution for me. As described here the issue can be reproduced very quickly (in 5 mins).