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

Fri May 27 10:49:30 UTC 2022

Let me state first I am fan of DNSSEC and unbound. But some existing
networks do not allow them to work.

On 5/27/22 04:41, Paul Wouters wrote:
> 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 obivously dislike DNSSEC and consider it breaking too many stuff.
Often their first advice is try turning DNSSEC off. Worked? Okay, close
the issue.
>
> 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.

Even when I disagree with them in quite many things, they have working
resolver even in weird network situations. For example routerboard wifi
routers do not support EDNS0 or DNSSEC. If I have a laptop and connect
to such network, I would like to receive working resolution. That is not
as straight forward with unbound. With its default configuration it
would result in servfail and not working connectivity. I would recommend
anyone to request such network provider to fix the DNS cache/forwarder,
but such networks are not very uncommon. If unbound should be
preinstalled also on Laptops moving from network to network, this has to
be solved somehow.

I would recommend ability to set DNSSEC validation per connection in NM.
But anyway, this should be solved automatically if unbound would be
installed on every desktop.

>>> 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.
Well, Red Hat pays many of systemd developers. It is not in the same
situation as dnsmasq for example. It has its developer base not small.
But I admit they do not follow DNS best practices very often. It should
be noted that there are also other name resolution methods on Linux
workstation. It is not just DNS, but also mDNS, LLMNR or various nss
plugins. I don't know whether there is any work group working with those
methods as well.
>
>>> 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.
It may not be hard, but there is no existing implementation for that I
would know about. For example OpenVPN announced they would like
dbus-only configuration of those forwarders.
>
>>> 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.

I have not read all ADD drafts. But do they solve how to direct name
queries to multiple resolvers when I am connected to multiple networks?
There are attempts to solve those problems right now somehow, even
before final standard is made. Example might be hack with ~ prefix to
search domains in DHCP. Then they are just added to local domains set
for a connection, but not into /etc/resolv.conf search clause.

>>> 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.
I am for ability to validate DNSSEC from every machine possible. However
some resolvers offered to network users do not allow it. Not only
resolved with DNSSEC=no is breaking it. If that is not important for a
network operator, okay. The user should have easy way to receive
notification this network does offer servers with working validation.
But it should work even in that case.
>
> 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)
Interesting. Not sure about that. The only user of varlink that I know
is resolved. I guess any generic enough API would work. But dbus
integration on workstation would still make sense.
>
>>> - 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.
Not sure what do you mean. Can you explain?
>
>>> - 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 to move LLMNR and mDNS resolution to nss plugins only. But
there is no simple to use asynchronous API, which can request names
including nss plugins from application. If we insist on DNS, we end in
the same mess resolved now has. We have getdns library, which is nice.
But DNS specific. I think we miss a simple library or service, which can
provide getaddrinfo() library calls in non-blocking way and easily
integrated into desktop application.

Resolved has dbus resolve1 API [3], which seems too specific for
resolved. I don't like the API itself, but provides a way to
asynchronously resolve address without extra pain.

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

I understand servers rarely need LLMNR. It breaks too many things in
current systemd-resolved implementation. Filled [1] recently, but I
doubt they would change it enough.

Anyway, if I configure root forwarders to some local server and it can
respond to 'machine.example.' query with unsigned content, it is quite
lame if my unbound turns that response to NXDOMAIN, because example. is
proven non-existent at root. That server obviously knows it. If that
domain is immediately above root, there is no danger just accepting this
with NTA exception IMO. Many existing networks misuse some kind of
private TLD. If we want unbound with DNSSEC enabled to be a default, it
should not break on every such network, where it worked for years
before. Of course they should be told to get and use own domain. There
is not a small collection, which might be accepted by default [2].

Of course if it is in iterative mode without forwarding, there is no
reason to accept such responses. If root servers are signed, they know
what belongs there.

>
> 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.
Well, something can be changed via Merge Requests to systemd. But they
have own ideas how it is correct.
> 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

My efforts can change something. But fact is systemd team has more
developers and I am alone again in our Infrastructure Services team on
DNS related products for RHEL. In fact systemd maintainer asked me for a
requirements summary on modern system. Any idea for a good mailing list
for that question? Or working group? Except what we already discussed, I
think easy registration of local hostnames would be useful. As a
replacement for libvirt-nss plugin, which provides names only via
getaddrinfo calls. Unless I have something equivalent or better than
systemd-resolved, I am afraid the resolution implementation in next
major RHEL release would become resolved.

So if that should ever change, I think also implementations have to be
done. Not just discussion. Unbound is great, but would need a more plug
& play feel if offered also to non-techical people. :)

Cheers,
Petr

1. https://github.com/systemd/systemd/issues/23494
2. https://observatory.research.icann.org/graph-m4.html
3.
https://www.freedesktop.org/software/systemd/man/org.freedesktop.resolve1.html#

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB