On Mon, Sep 28, 2020 at 11:19 AM PGNet Dev <pgnet.dev(a)gmail.com> wrote:
On 9/28/20 11:03 AM, Lennart Poettering wrote:
> I have the strong suspicion that the same people who are
> able to deploy working DNSSEC client side and are educated enough in
> DNSSEC to know what that even means are also capable of replacing that
> one symlink in /etc.
i'll start with: i'm generally a huge use-systemd-*-whenever-possible
bigot. aka, NOT an anti-systemd'er.
but, this^ comment, though likely _true_, causes concern for those of us
out here, in the peanut gallery.
<peanut-gallery hat>on</peanut-gallery hat>
as Paul Wouters has repeatedly pointed out ... others' use cases are not
mine.
and statements such as "It's easy to do using resolvectl" make me ...
antsy.
forcing use of, or switching by (coming) default, to solutions that cause
significant breakage to working systems, is bad news. whether or not that
breakage can be 'easily' worked around.
easy != zero effort / zero cost.
my typical 'small-office install' includes local split-horizon bind9
implementation, as well as instances of both NSD4/Unbound, multiple VPN
links, and varied routing for IPv4 & IPv6 dns queries, as well as general &
specific traffic. internal services/capabilities include mail, DNSSEC and
instances of secure DNS (DoT/DoH), geoIP, etc etc.
'large-office' installs are correspondingly _more_ 'convoluted'.
that said, it all works. well.
(my) users see/use a static /etc/resolv.conf, with, generally, a single
nameserver entry.
recent experiments (on F32, admittedly -- *not* yet F33) with
NetworkManager &/or systemd-resolved here were nightmarish; a seemingly
endless array of 'gotchas' ...
after trying, and failing, to chase down & completely resolve all the
problems, the functional solution i landed on was
(1) disable NetworkManager everywhere (yes, causes some current pain with
laptops)
I would have expected NetworkManager to handle this kind of setup just
fine. What went wrong?