<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Regards,<br>
Petr<br>
</p>
<p>1. <a class="moz-txt-link-freetext" href="https://www.rfc-editor.org/rfc/rfc7556.html#section-2">https://www.rfc-editor.org/rfc/rfc7556.html#section-2</a><br>
2.
<a class="moz-txt-link-freetext" href="https://stackoverflow.com/questions/43001223/how-to-ensure-that-there-is-a-delay-before-a-service-is-started-in-systemd">https://stackoverflow.com/questions/43001223/how-to-ensure-that-there-is-a-delay-before-a-service-is-started-in-systemd</a><br>
</p>
<div class="moz-cite-prefix">On 10. 08. 23 15:22, Andre Costa wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMBDoMM0mVJnD6-MfTNPVj1xvGcNhHGT=Fiyr4ZWSMrauqcwSQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi,</div>
<div><br>
</div>
<div>There is a lot of context <a
href="https://discussion.fedoraproject.org/t/need-to-set-different-dns-configurations-for-home-and-work/86830"
moz-do-not-send="true">here</a>, but to summarize the
current status:</div>
<div>
<ol>
<li>There are two specific scenarios that I am trying to
manage through dispatcher scripts:</li>
<ol>
<li>Wired connection needs to set up different DNS
configurations depending if I am working remotely from
home or at the office</li>
<li>When I am working remotely and I connect through the
VPN to <a href="http://work.com" moz-do-not-send="true">work.com</a>,
I need to set up split DNS to route queries to
<site>.<a href="http://work.com"
moz-do-not-send="true">work.com</a> to <a
href="http://work.com" moz-do-not-send="true">work.com</a>
DNS servers, and all other queries to NextDNS servers<br>
</li>
</ol>
<li>I am configuring everything I can through
NetworkManager's profiles</li>
<ol>
<li>I have one profile for wired connection that is used
both at home and at the office</li>
<li>I have two profiles to connect to my work VPN</li>
<li>I have two profiles for Wi-Fi (one for home and the
other for work)</li>
</ol>
</ol>
<div>I think I managed to solve 1.1 through a dispatcher
script, but I haven't tested it onsite yet.</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div><span style="font-family:monospace">Aug 09 12:19:23
fedoracosta systemd-resolved[950]: enp3s0: Bus client set
DNS server list to: ...<br>
Aug 09 12:19:23 fedoracosta systemd-resolved[950]: enp3s0:
Bus client set search domain list to: ~.<br>
Aug 09 12:19:23 fedoracosta systemd-resolved[950]: enp3s0:
Bus client set default route setting: yes<br>
Aug 09 12:19:23 fedoracosta systemd[1]: iscsi.service:
Unit cannot be reloaded because it is inactive.<br>
Aug 09 12:19:25 fedoracosta systemd-resolved[950]: enp3s0:
Bus client reset search domain list.<br>
Aug 09 12:19:25 fedoracosta systemd-resolved[950]: enp3s0:
Bus client set default route setting: no<br>
Aug 09 12:19:25 fedoracosta systemd-resolved[950]: enp3s0:
Bus client reset DNS server list.</span></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I think I am stuck here, if anyone could lend a helping
hand, I would greatly appreciate it.</div>
<div><br>
</div>
<div>Best regards,</div>
<div>Andre<br>
</div>
</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Petr Menšík
Software Engineer, RHEL
Red Hat, <a class="moz-txt-link-freetext" href="http://www.redhat.com/">http://www.redhat.com/</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</body>
</html>