[Networkmanager] Dynamically changing DNS configurations depending on the connection

[Petr Menšík]

Yes, this is common situation I am hitting often too. WiFi has simple 
different profiles by changing SSID, so having working name resolution 
even for internal VPN networks is simple. I prefer dnsmasq, but 
systemd-resolved should work as well.

I think the proper solution would be decent support for Provisioning 
Domain [1], which would allow differentiate networks based on DHCP 
parameters with some trusted way to validate it. I think some 
internal-only TLS site or at least router SSH public key might be 
candidates for secure enough network recognition. PvD can specify extra 
well-known https, which can guarantee trusted site identifier.

I think for VPN there should be only one profile. It should list all 
domains, which should be directed at DNS servers provided by the VPN. It 
might be needed to extend ipv4.dns-search manually with more domains.

For all other names just default network-provided DNS servers should be 
used. If you want to use custom DNS servers just on some of connections, 
it becomes more tricky.

I would just guess the reset phase might be caused by systemd-resolved 
enforcing information from the daemon. Maybe it needs to be configured 
in later connection state, which is not present when running in 
dispatcher. I would try playing with values of connectivity, as show by 
nmcli general.

Have you tried delaying the change, for example by systemd unit? Some 
examples are at [2]. I just guess something in NM systemd-resolved 
plugin might be responsible for the reset, but not sure. Delaying 
parameters might make it behave like manual configuration.

Regards,
Petr

1. https://www.rfc-editor.org/rfc/rfc7556.html#section-2
2. 
https://stackoverflow.com/questions/43001223/how-to-ensure-that-there-is-a-delay-before-a-service-is-started-in-systemd

On 10. 08. 23 15:22, Andre Costa wrote:
> Hi,
>
> There is a lot of context here 
> <https://discussion.fedoraproject.org/t/need-to-set-different-dns-configurations-for-home-and-work/86830>, 
> but to summarize the current status:
>
>  1. There are two specific scenarios that I am trying to manage
>     through dispatcher scripts:
>      1. Wired connection needs to set up different DNS configurations
>         depending if I am working remotely from home or at the office
>      2. When I am working remotely and I connect through the VPN to
>         work.com <http://work.com>, I need to set up split DNS to
>         route queries to <site>.work.com <http://work.com> to work.com
>         <http://work.com> DNS servers, and all other queries to
>         NextDNS servers
>  2. I am configuring everything I can through NetworkManager's profiles
>      1. I have one profile for wired connection that is used both at
>         home and at the office
>      2. I have two profiles to connect to my work VPN
>      3. I have two profiles for Wi-Fi (one for home and the other for
>         work)
>
> I think I managed to solve 1.1 through a dispatcher script, but I 
> haven't tested it onsite yet.
>
> As for 1.2, I wrote another dispatcher script that is being executed, 
> but for some unknown reason, the changes I am making through 
> resolvectl are being reversed:
>
> Aug 09 12:19:23 fedoracosta systemd-resolved[950]: enp3s0: Bus client 
> set DNS server list to: ...
> Aug 09 12:19:23 fedoracosta systemd-resolved[950]: enp3s0: Bus client 
> set search domain list to: ~.
> Aug 09 12:19:23 fedoracosta systemd-resolved[950]: enp3s0: Bus client 
> set default route setting: yes
> Aug 09 12:19:23 fedoracosta systemd[1]: iscsi.service: Unit cannot be 
> reloaded because it is inactive.
> Aug 09 12:19:25 fedoracosta systemd-resolved[950]: enp3s0: Bus client 
> reset search domain list.
> Aug 09 12:19:25 fedoracosta systemd-resolved[950]: enp3s0: Bus client 
> set default route setting: no
> Aug 09 12:19:25 fedoracosta systemd-resolved[950]: enp3s0: Bus client 
> reset DNS server list.
>
> On the output above, the first three lines are the result of the 
> execution of the dispatcher script, and the last three lines revert 
> them. If I try to apply the same changes through the command line 
> after the VPN is up, it works as intended.
>
> I think I am stuck here, if anyone could lend a helping hand, I would 
> greatly appreciate it.
>
> Best regards,
> Andre

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/networkmanager/attachments/20230828/3f025247/attachment.htm>