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

[Paul Wouters]

On Fri, 27 May 2022, Petr Menšík wrote:

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

So that shows to my point of letting them ask "what do we need to do to
be considered for a system default resolver", and one point would be
"do not disabled DNSSEC". If they keep thinking DNSSEC is not core to
the DNS protocol, they have no business being the default resolver.

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

EDNS is an RFC from 1999. In 2019, there was a global DNS "flag day" to
remove all workarounds dealing with badly or not implemented EDNS0:

https://kb.isc.org/docs/dns-flag-day-will-it-affect-you

It seems like systemd-resolved would be the single DNS resolver that
still feels it needs to hack around broken EDNS0 support?

> If I have a laptop and connect
> to such network, I would like to receive working resolution.

See the work in the ADD group. Basically, you will move anyway towards
not giving coffeeshops and hotels your DNS traffic, as that is a privacy
issue, and your system will start using a Trusted Remote Resolver (TRR).
Mozilla is already doing this for some of its users, eg in the US. That
reduces your use case to doing proper captive portal in cases of broken
DNS. And that is another battle in the opensource software stack, as
everyone and no one takes responsibility for captive portals. systemd?
NetworkManager? Gnome? Firefox? Everyone mucks a little and not enough.

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

The proper engineered solution is an "upstream" container that is only
used for captive portaling and will not need DNSSEC and shouldn't need
EDNS0, that uses a contained cookieless browser (so the hotspot doesn't
get your facebook cookies) and once internet connectivity has been
enabled, you tell NM the network is up, and NM tells all the apps, and
those use their own ADD/TRR discovered DNS servers that will work with
EDNS0 and DNSSEC. Those without TRR could use DoH or DoT to well known
DNS providers (1.1.1.1, 8.8.8.8 or 9.9.9.9)

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

That should not be needed if you engineer the above suggested solution.

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

As long as we have a few dozen open systemd-resolved bugs, I am
concluding no systemd people are working on this part of systemd.

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

I'm sure unbound wouldn't mind a varlink API that can accept a wrapped
version of "unbound-control forward" commands. I think they should stay
away from the aging dbus.

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

Yes. Each network can advertise the "local domains" they deem they are
authoritve for so you can reconfigure it. Note that the systemd-resolved
solution of "multiple networks" is "throw all queries to all networks",
which in a meeting with systemd people 10 years ago, I told them is an
unacceptable privacy issue. It was disgarded as not a use case they
considered.

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

The mixing of search domains and DHCP domains has also been problematic,
and another case where people only look at their one use case. Red Hat
wanted to have their local domains "just work" when people connect to
their wifi, and so they cause modification of the search path, which is
a security issue. When I am at starbucks, I dont want my unqualified
queries for "mail" to go to "mail.starbucks.com". In general, my search
domains are my own, and should not be modified by the network at all.
That is, search domain for unqualified queries should not be taken from
the network ever. If you want to set it for your users, provision them
with some config/package that adds "redhat.com" to the search domains.

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

See above if you want to really properly engineer yourself out of this
problem. But if you are connecting to a network that does not answer
DNS queries with the DO bit set in 2022, then that network gear has not
been updated for so long, it should be considered under malicious
control, and you should REALLY not let it force you to use unprotected
DNS.

These arguments are all from individual users having one individual use
case. They are not engineering for the real world.

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

I had hoped varlink would have gained more steam now to replace dbus.
The libreswan team is planning to add support for it.

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

If you change resolv.conf to a real server instead of 127.0.0.53, and
leave "resolv" in nsswitch.conf, then glibc will still intercept
gethostbyname() calls and use systemd-resolved to resolve those. While
getaddr_info() complies to POSIX still and MUST use the nameserver in
/etc/resolv.conf, so glibc honours that. You get a frankenresolver based
on what lowlevel DNS calls apps or libraries are using.

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

Maybe others know more about this and can point you somewhere.

> 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 am amused at the sentence containing "dbus" and "without extra pain".
I tried using the various example codes and none of it worked when I
was playing with it.

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

Thanks for filing that. It is indeed yet another bug where the RFC is
not followed, and things break :(

> Anyway, if I configure root forwarders to some local server and it can

another nice feature of unbound is support for local root, RFC 8806.
Which also prevents a lot of junk queries from leaking on the internet
and increases privacy for the users on typos not leaking to root servers
via ISP.

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

That is something that can again be easilly provisioned using an
enterprise package (or home user config) that adds such domains to an
unbound include file in /etc/unbound.d/ which is why I created that
directory in the fedora unbound package to allow files to be dropped in
there without needing to change the core /etc/unbound/unbound.conf.

> Well, something can be changed via Merge Requests to systemd. But they
> have own ideas how it is correct.

Based on my commets and RFC quoting in their github issue tracker, I
wouldn't invest my time in fixing code to only see it rejected as not
their use case. Sorry :(

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

That mirrors my situation there, except that I had the weight of a DNS
RFC author as well, and still that did not help :(

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

As long as systemd-resolved remains split of in its own package we can
rpm -e, I can live with that. For most users, the browser's DNS is what
really matters, and there firefox is going full TRR anyway, so whatever
the OS will do in the future will not really matter anymore.

Paul