Well, nothing is stopping anyone from using unbound as a DNS cache today. It seems that the only issue is making it “default”, which requires hacking on the systemd-resolved subsystem. I’m a big systemd supporter, but systemd should remain a service management layer, not try to re-implement some sort of per-service generic API for every possible service. What is next? A systemd-twitter subsystem to manage my twitter access in a generic way? And then rewrite all applications to use d-bus to send API calls to the systemd-twitter subsystem, which then translates those calls to to Twitter’s API? There is such a thing as too much abstraction.
I also find NetworkManager totally unsuitable for servers, and I generally delete it. Its use case is really for laptops, which I don’t care about. And I don’t care about split DNS either. It isn’t a feature that I’d ever use, or recommend anyone else use. If you have to do split DNS, the capability already exists. No need to write a new abstraction to it. Tom > On May 26, 2022, at 1:51 PM, Petr Menšík via Unbound-users > <[email protected]> wrote: > > Does no answer mean nobody would like unbound as a default DNS cache? > Does systemd-resolved fulfill your needs? > > On 5/16/22 12:25, Petr Menšík wrote: >> Hi, >> >> I had a discussion with some our people involved in systemd development. >> They would like some decision about RHEL 10 DNS subsystem. Of course >> they would like to have systemd-resolved similar to Fedora or Ubuntu. >> >> I on the other hand would like to have something following properly RFC >> and standards. I think unbound is the closest match. It has good runtime >> reconfiguration support. It knows even how to do DNS over TLS and can >> switch to it runtime. >> >> But is missing: >> >> - integration with NM manager configuring split-DNS domains properly. >> Similar to dns=dnsmasq configuration in NetworkManager.conf. >> - ability to pass example.corp. names validation, if they exist on >> forwarders provided by local network. Or any private TLD, such as .home >> or .lan. Could be solved by disabling dnssec validation by default, just >> like systemd-resolved. >> - missing d-bus API to allow VPNs forwarders configuration and split-DNS >> zones definition >> - no mDNS or LLMNR support >> - no custom NSS plugin (I think this is unimportant) >> - no d-bus API offering asynchronous resolution to application (not sure >> how much this is used) >> >> I would like something not blocking DNSSEC records by default. Do you >> think it is worth working on missing items? Would you recommend to >> install unbound on all desktop installations by default? Why yes? Why >> not? Do you see any blocker I haven't mentioned? >> >> Any feedback would be welcomed! >> >> Cheers, >> Petr >> > -- > Petr Menšík > Software Engineer > Red Hat, http://www.redhat.com/ > email: [email protected] > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB >
