Hi Didier,

On Sat, 2025-03-22 at 10:04 +0100, Didier Kryn wrote:
> Le 18/03/2025 à 21:12, Marjorie Roome via Dng a écrit :
> > Hi,
> >
> > On Tue, 2025-03-18 at 16:44 -0300, altoid via Dng wrote:
> > > Hello:
> > >
> > > Users of [connman] and [network-manager] (and possibly maybe
> > > other
> > > such applications) who want to run their boxes with their own DNS
> > > settings know exactly what I am referring to in the subject
> > > title.
> > >
> > > I was one of them till I decided to go the [ifupdown] route and
> > > rid
> > > myself of both the headache and a layer of abstraction.
> > >
> > > Then, while searching on how to fix something else, I came across
> > > [/sbin/dhclient-script] and within it, this bit which instantly
> > > called my attention:
> > >
> > > [code]
> > > --- snip ---
> > > # update /etc/resolv.conf based on received values    # <----
> > > wthf?
> > >    make_resolv_conf() {
> > >        local new_resolv_conf
> > > --- snip ---
> > > [/code]
> > >
> > > Not in any way script savvy but it seemed I had found the
> > > hijacker,
> > > so to speak.
> > >
> > > Those who know more could confirm my suspicions.
> > >
> > > According to [jed], the whole snippet is from line 39 to line 125
> > > and
> > > it would seem (?) to be the routine that constantly overwrites
> > > [/etc/resolv.conf] just because some idiot thought it was a good
> > > idea
> > > to do so.
> > >
> > > The web is full of posts complaining about this issue from quite
> > > a
> > > few years back, all of which have been ignored.
> > >
> > > But I digress ...
> > >
> > > I was wondering if this could be put to death without much ado or
> > > causing extra work for the Devuan maintainers.
> > >
> > > Maybe a small / specific Devuan meta-package with a script to
> > > edit
> > > [/sbin/dhclient-script] and bring some peace to independent DNS
> > > users.
> > >
> > > Just a thought.
> > > Opinions/solutions welcome.
> > >
> > I use network manager but also use dnscrypt-proxy running on my own
> > PC
> > to supply my DNS lookups.
> >  
> > So my resolv.conf just contains the line
> > nameserver 127.0.0.1
> >
> > dnscrypt-proxy listens on 127.0.0.1:53
> >
> > And I have moved /etc/resolv.conf elsewhere and replaced it by a
> > symbolic link to where it actually is (/etc/dnscrypt-
> > proxy/resolv.conf).
> >
> > You can also simply make it immutable (chattr +i /etc/resolv.conf).
> >
>      Don't want to dig too much into this issue which goes a little
> over my head, but, if you're roaming (eg with a laptop), better not
> make resolv.conf immutable. An other issue with constantly rewriting
> it is frequent disk writes. This can be mitigated by the installation
> of package resolvconf, which changes /etc/resolv.conf to a symbolic
> link pointing to a file in /run (mounted as tmpfs).
>
>      In case one needs to programatically monitor the changes of
> resolv.conf, the inotify API exists just for this kind of case.
> Normally your program is purely reactive and organized around a call
> to select() and the inotify filedescriptor can just be added to te
> list.
>
Yes my Resolv.conf is fixed because it simply points to dnscrypt-proxy
(127.0.0:1:53) which is a DNS proxy running on my own machine and that
then uses a choice of DNS resolvers which are dynamic.

It finds DNS servers from a list that you can control. 
You can have a fixed list and a fallback, such as 9.9.9.9 but it
normally looks for nearby DNS servers, that in my cases are limited to
ones that are non-logging, are dnssec, use doh or dnscrypt (so lookup
is encrypted in transit) and then load balances between the quickest
few based on latency, so not all queries are sent to one resolver
anyway.

On my fixed PC I only refresh these latencies and hence preferred
resolvers every 4 hours but you might want to do something different on
a laptop that moves around.

Dnscrypt-proxy also caches queries.

And I can and do also choose from a selection of blocklists that block
the usual subjects. I can override these with an allowlist in the event
there is a website I need that would otherwise not work.

--
Marjorie