[Networkmanager] Dynamically changing DNS configurations depending on the connection
Andre Costa
andre.ocosta at gmail.com
Tue Aug 29 18:32:32 UTC 2023
Hi Petr, thanks for reaching out.
I managed to find a working solution -- probably not the best one, but
AFAICS it works pretty well.
I tried to summarize it here
<https://discussion.fedoraproject.org/t/need-to-set-different-dns-configurations-for-home-and-work/86830/17>,
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.
The key point I believe was this change:
DNSOverTLS=opportunisticDomains=~.
So, at the end of the day, it was much simpler than I anticipated. Again,
any suggestions and corrections are welcome.
Best regards,
Andre
On Tue, Aug 29, 2023 at 9:00 AM <
networkmanager-request at lists.freedesktop.org> wrote:
> Send Networkmanager mailing list submissions to
> networkmanager at lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/networkmanager
> or, via email, send a message with subject or body 'help' to
> networkmanager-request at lists.freedesktop.org
>
> You can reach the person managing the list at
> networkmanager-owner at lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Networkmanager digest..."
>
>
> Today's Topics:
>
> 1. Re: manual method and may-fail default (Beniamino Galvani)
> 2. Re: Dynamically changing DNS configurations depending on the
> connection (Petr Men??k)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> [snip]
> ------------------------------
>
> Message: 2
> Date: Mon, 28 Aug 2023 17:22:07 +0200
> From: Petr Men??k <pemensik at redhat.com>
> To: networkmanager at lists.freedesktop.org
> Subject: Re: [Networkmanager] Dynamically changing DNS configurations
> depending on the connection
> Message-ID: <2a09d37c-0634-246a-483b-4e7c3f1a85da at redhat.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> 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-0001.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> Networkmanager mailing list
> Networkmanager at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/networkmanager
>
>
> ------------------------------
>
> End of Networkmanager Digest, Vol 10, Issue 8
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/networkmanager/attachments/20230829/e16f804c/attachment.htm>
More information about the Networkmanager
mailing list