Would be unbound good candidate to replace systemd-resolved on desktop?

[Paul Wouters]

On May 26, 2022, at 16:51, Petr Menšík via Unbound-users <unbound-users at lists.nlnetlabs.nl> wrote:
> 
> 
>> 
>> 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.

My experience with systemd and systemd-resolved people and bug handling lead me to say that systemd-resolved is unsuitable as the default resolver. All my use cases were deemed “out of scope” and there are crashes and RFC violations galore that are either closed as notabug or ignored. 

They should ask “what needs to change so that systemd-resolved could become the system resolver”, and then take that input seriously. That was not the case when I was there trying to have that conversation.

>> 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.

It works for bsd as default resolver. It has a dedicated team and budget. It’s developers attend IETF and RIPE meetings and are closely involved with operational issues and protocol development. None of this is true for systemd-resolved.

>> But is missing:
>> 
>> - integration with NM manager configuring split-DNS domains properly.

We did it for libreswan, it’s trivial to add it to NM. It will have taken longer to write this email on my virtual phone keyboard. All the unbound-control commands were added for this, some specifically for this use case with libreswan at my request. 

>> Similar to dns=dnsmasq configuration in NetworkManager.conf.
>> - ability to pass example.corp. names validation, if they exist on
>> forwarders provided by local network.

Instead of all this bad hacking, those developers should get involved with the IETF ADD working group and look at the drafts produced there for exactly how future protocols are supposed to fix this. Unbound or glue code will likely be written for this by dedicated dns developers.

>> Or any private TLD, such as .home
>> or .lan. Could be solved by disabling dnssec validation by default, just
>> like systemd-resolved.

Again, this is exactly why resolved is unsuitable. The thought that dnssec is optional is archaic. It shows disrespect to the users and results it more complicated setups where applications will ignore the system dns because it’s simply untrustworthy.

DNS will contain SVCB, HTTPS records to advertise dns transports and AliasMode replacing CNAMEs. It will contain SNI public keys for encrypted SNI. None of these records can be used securely when dnssec is disabled. 

Systemd should stop hacking and look at what’s happening at the IETF. Everything is still in drafts and they can still influence based on their experience and use cases. They should stop forcing their own ideas and dropping real world use cases as they have done in the past. Fritzbox can be dealt with separately instead of making fake TLDs work a higher priority than actual proper DNS deployment. 

>> - missing d-bus API to allow VPNs forwarders configuration and split-DNS
>> zones definition

That’s another way of saying NM integration. And isn’t dbus legacy and the new tool is varlink?  (Lack of dbus integration in general is because the low level libdbus is wrong for this and all other higher level libs pulled in a graphical desktop dependencies)

>> - no mDNS or LLMNR support

LLMNR is dead isn’t it? And Avahi ran the .local stuff just fine? 

>> - no custom NSS plugin (I think this is unimportant)

This is actually a bug. Systemd-resolved changes its answer based on whether gethostbyname() or getaddr_info() is used. One of the reasons I remove this from nsswitch.conf in all my systems.

>> - no d-bus API offering asynchronous resolution to application (not sure
>> how much this is used)

Resolving over dbus doesn’t seem like a very good idea. A varlink API shouldn’t be that hard. Not sure of the gain versus a connected TCP connection to the local host DNS server. Smells more like “not invented here” syndrome.

>> 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?

Very very few people need mdns or LLMNR, especially on servers or containers. I like my enterprise DNS not optimizing for printer discovery or a developers need to reach a fake .box TLD to login to their router.

If I sound harsh, it’s because all of this is has happened before and all of this will happen again. Nothing fundamentally has changed with systemd-resolved in the last 7+ years.

I doubt this email or any of your efforts at Red Hat regarding DNS will change anything either but I applaud you for trying and reaching out to us. I hope I am wrong and you manage to ensure RHEL10 will have a solid system-wide DNS setup.

Thanks for trying Petr! I really do appreciate that.

Paul