<div dir="ltr"><div dir="ltr"><div>Hi Petr, thanks for reaching out.</div><div><br></div><div>I managed to find a working solution -- probably not the best one, but AFAICS it works pretty well.<br></div><div><br></div><div>I tried to summarize it <a href="https://discussion.fedoraproject.org/t/need-to-set-different-dns-configurations-for-home-and-work/86830/17" target="_blank">here</a>,
but basically I removed all the modifications and restarted from
scratch, one step at a time. I removed all dispatcher scripts, and
simplified the configuration files.<br></div><div><br></div><div>The key point I believe was this change:<br></div><div><pre dir="ltr"><code><span>DNSOverTLS</span>=opportunistic
<span>Domains</span>=~.</code></pre></div><div>So, at the end of the day, it was much simpler than I anticipated. Again, any suggestions and corrections are welcome.</div><div><br></div><div>Best regards,</div><div>Andre</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 29, 2023 at 9:00 AM <<a href="mailto:networkmanager-request@lists.freedesktop.org">networkmanager-request@lists.freedesktop.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Send Networkmanager mailing list submissions to<br>
<a href="mailto:networkmanager@lists.freedesktop.org" target="_blank">networkmanager@lists.freedesktop.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.freedesktop.org/mailman/listinfo/networkmanager" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/networkmanager</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:networkmanager-request@lists.freedesktop.org" target="_blank">networkmanager-request@lists.freedesktop.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:networkmanager-owner@lists.freedesktop.org" target="_blank">networkmanager-owner@lists.freedesktop.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Networkmanager digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: manual method and may-fail default (Beniamino Galvani)<br>
2. Re: Dynamically changing DNS configurations depending on the<br>
connection (Petr Men??k)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br></div>[snip]<br><div>
------------------------------<br>
<br>
Message: 2<br>
Date: Mon, 28 Aug 2023 17:22:07 +0200<br>
From: Petr Men??k <<a href="mailto:pemensik@redhat.com" target="_blank">pemensik@redhat.com</a>><br>
To: <a href="mailto:networkmanager@lists.freedesktop.org" target="_blank">networkmanager@lists.freedesktop.org</a><br>
Subject: Re: [Networkmanager] Dynamically changing DNS configurations<br>
depending on the connection<br>
Message-ID: <<a href="mailto:2a09d37c-0634-246a-483b-4e7c3f1a85da@redhat.com" target="_blank">2a09d37c-0634-246a-483b-4e7c3f1a85da@redhat.com</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
Yes, this is common situation I am hitting often too. WiFi has simple <br>
different profiles by changing SSID, so having working name resolution <br>
even for internal VPN networks is simple. I prefer dnsmasq, but <br>
systemd-resolved should work as well.<br>
<br>
I think the proper solution would be decent support for Provisioning <br>
Domain [1], which would allow differentiate networks based on DHCP <br>
parameters with some trusted way to validate it. I think some <br>
internal-only TLS site or at least router SSH public key might be <br>
candidates for secure enough network recognition. PvD can specify extra <br>
well-known https, which can guarantee trusted site identifier.<br>
<br>
I think for VPN there should be only one profile. It should list all <br>
domains, which should be directed at DNS servers provided by the VPN. It <br>
might be needed to extend ipv4.dns-search manually with more domains.<br>
<br>
For all other names just default network-provided DNS servers should be <br>
used. If you want to use custom DNS servers just on some of connections, <br>
it becomes more tricky.<br>
<br>
I would just guess the reset phase might be caused by systemd-resolved <br>
enforcing information from the daemon. Maybe it needs to be configured <br>
in later connection state, which is not present when running in <br>
dispatcher. I would try playing with values of connectivity, as show by <br>
nmcli general.<br>
<br>
Have you tried delaying the change, for example by systemd unit? Some <br>
examples are at [2]. I just guess something in NM systemd-resolved <br>
plugin might be responsible for the reset, but not sure. Delaying <br>
parameters might make it behave like manual configuration.<br>
<br>
Regards,<br>
Petr<br>
<br>
1. <a href="https://www.rfc-editor.org/rfc/rfc7556.html#section-2" rel="noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc7556.html#section-2</a><br>
2. <br>
<a href="https://stackoverflow.com/questions/43001223/how-to-ensure-that-there-is-a-delay-before-a-service-is-started-in-systemd" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/43001223/how-to-ensure-that-there-is-a-delay-before-a-service-is-started-in-systemd</a><br>
<br>
On 10. 08. 23 15:22, Andre Costa wrote:<br>
> Hi,<br>
><br>
> There is a lot of context here <br>
> <<a href="https://discussion.fedoraproject.org/t/need-to-set-different-dns-configurations-for-home-and-work/86830" rel="noreferrer" target="_blank">https://discussion.fedoraproject.org/t/need-to-set-different-dns-configurations-for-home-and-work/86830</a>>, <br>
> but to summarize the current status:<br>
><br>
> 1. There are two specific scenarios that I am trying to manage<br>
> through dispatcher scripts:<br>
> 1. Wired connection needs to set up different DNS configurations<br>
> depending if I am working remotely from home or at the office<br>
> 2. When I am working remotely and I connect through the VPN to<br>
> <a href="http://work.com" rel="noreferrer" target="_blank">work.com</a> <<a href="http://work.com" rel="noreferrer" target="_blank">http://work.com</a>>, I need to set up split DNS to<br>
> route queries to <site>.<a href="http://work.com" rel="noreferrer" target="_blank">work.com</a> <<a href="http://work.com" rel="noreferrer" target="_blank">http://work.com</a>> to <a href="http://work.com" rel="noreferrer" target="_blank">work.com</a><br>
> <<a href="http://work.com" rel="noreferrer" target="_blank">http://work.com</a>> DNS servers, and all other queries to<br>
> NextDNS servers<br>
> 2. I am configuring everything I can through NetworkManager's profiles<br>
> 1. I have one profile for wired connection that is used both at<br>
> home and at the office<br>
> 2. I have two profiles to connect to my work VPN<br>
> 3. I have two profiles for Wi-Fi (one for home and the other for<br>
> work)<br>
><br>
> I think I managed to solve 1.1 through a dispatcher script, but I <br>
> haven't tested it onsite yet.<br>
><br>
> As for 1.2, I wrote another dispatcher script that is being executed, <br>
> but for some unknown reason, the changes I am making through <br>
> resolvectl are being reversed:<br>
><br>
> Aug 09 12:19:23 fedoracosta systemd-resolved[950]: enp3s0: Bus client <br>
> set DNS server list to: ...<br>
> Aug 09 12:19:23 fedoracosta systemd-resolved[950]: enp3s0: Bus client <br>
> set search domain list to: ~.<br>
> Aug 09 12:19:23 fedoracosta systemd-resolved[950]: enp3s0: Bus client <br>
> set default route setting: yes<br>
> Aug 09 12:19:23 fedoracosta systemd[1]: iscsi.service: Unit cannot be <br>
> reloaded because it is inactive.<br>
> Aug 09 12:19:25 fedoracosta systemd-resolved[950]: enp3s0: Bus client <br>
> reset search domain list.<br>
> Aug 09 12:19:25 fedoracosta systemd-resolved[950]: enp3s0: Bus client <br>
> set default route setting: no<br>
> Aug 09 12:19:25 fedoracosta systemd-resolved[950]: enp3s0: Bus client <br>
> reset DNS server list.<br>
><br>
> On the output above, the first three lines are the result of the <br>
> execution of the dispatcher script, and the last three lines revert <br>
> them. If I try to apply the same changes through the command line <br>
> after the VPN is up, it works as intended.<br>
><br>
> I think I am stuck here, if anyone could lend a helping hand, I would <br>
> greatly appreciate it.<br>
><br>
> Best regards,<br>
> Andre<br>
<br>
-- <br>
Petr Men??k<br>
Software Engineer, RHEL<br>
Red Hat,<a href="http://www.redhat.com/" rel="noreferrer" target="_blank">http://www.redhat.com/</a><br>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.freedesktop.org/archives/networkmanager/attachments/20230828/3f025247/attachment-0001.htm" rel="noreferrer" target="_blank">https://lists.freedesktop.org/archives/networkmanager/attachments/20230828/3f025247/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
Networkmanager mailing list<br>
<a href="mailto:Networkmanager@lists.freedesktop.org" target="_blank">Networkmanager@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/networkmanager" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/networkmanager</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Networkmanager Digest, Vol 10, Issue 8<br>
*********************************************<br>
</div></blockquote></div></div>