On Mon, Sep 28, 2020 at 11:19 AM PGNet Dev <pgnet.dev@xxxxxxxxx> 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?
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
