Provide resolvconf(8)-compatible interface for systemd-resolved

[zx2c4]

The standard way for various programs to manage DNS in an ad-hoc non-centralized way -- such as when separate programs are not centrally managed, like VPNs -- is resolvconf(8). The best implementation of resolvconf is openresolv, which provides numerous useful options such as -x for exclusive, -m for metric, Here's a man page for it. A resolvconf is available in all distributions, except the RPM ones, and it's in the BSDs too. It appears to be the "de facto" standard for ad-hoc programs contributing to the pool of nameserver knowledge that eventually results in a resolv.conf.

systemd-resolved has a dbus API, but no command line interface for accessing it (AFAIK). In the same way that systemd reimplemented shutdown, halt, and so forth, to retain the same well-known interface, but under the hood talk dbus to systemd's pid 1, I'd like to propose that systemd-resolved provides a "resolvconf" -- something with the same options as openresolv, but that translates these to systemd-resolved dbus commands.

This would lead to easy adoption of systemd-resolved, as well as conformity across distributions, whether they're using a Debian resolvconf, an openresolv resolvconf, or a systemd-resolved resolvconf. In Redhat-world, now that NetworkManager has a systemd-resolved plugin, it would also be a simple way for interacting with that too.

Is this idea interesting to the systemd-resolved developers?

[dkg]

I like this idea, though i'm not sure that systemd would need to implement the full complement of the resolvconf interface. At any rate, a simple command-line interface that knows how to speak to systemd-resolved to perform the most common basic operations (adding a resolver, removing a resolver) would be useful.

[zx2c4]

On Oct 28, 2017 4:35 PM, "dkg" ***@***.***> wrote: I like this idea, though i'm not sure that systemd would need to implement the full complement of the resolvconf interface. At any rate, a simple command-line interface that knows how to speak to systemd-resolved to perform the most common basic operations (adding a resolver, removing a resolver) would be useful..

It's attitudes like this one that contribute to fragmentation and abstraction bloat. resolvconf(8) is a de facto standard interface, which systemd can embrace just like many others it already has, such as halt, shutdown, fstab, etc. In any case I'm mostly interested in hearing from systemd devs the technical concerns (or lack thereof) with this approach. Namely, is the input format it takes (resolv.conf files, essentially) sufficient an API?

[yuwata]

C.f. #7014.

[yuwata]

Especially #7014 (comment).

[poettering]

hmm, I think this would be OK to have actually, maybe as a multi-call overloading of the existing systemd-resolve tool.

[poettering]

so what's precisely the minimal options we'd have to support? I figure only "resolvconf -a IFACE." matters really, the rest can be NOPs, including "resolvconf -d", as we notice on our own when interfaces go away...

[zx2c4]

-m and -x are the biggies.

http://nxmnpg.lemoda.net/8/resolvconf

[poettering]

"-m" doesn't really translate. Note sure I fully grok "-x", but it doesn't really translate either...

[poettering]

as first step i prepped #7576 now. It doesn't add a compatible interface, but we can add that later building on this new code. Since the semantics don't map 1:1 i'd rather have a native interface first, exposing the right semantics, before we add compat kludges to provide debian/ubunti semantics too

[zx2c4]

The -x means that the given name server becomes the exclusive one for the machine. This is important if people don't want DNS requests "leaking" through a different nameserver when bringing up VPN devices.

[tixxdz]

@poettering FWIW I also think that we should support this.

[poettering]

I figure "-x" could be translated to "add '.' to the list of routing domains for the interface". In resolved doing that means that DNS traffic for domains that aren't listed as search/routing domains otherwise is directed to that interface. It wouldn't have quite the same semantics, as a more specific domain-routing rule would still win, but in the big picture the difference shouldn't be too bad...

The "-m" metric stuff doesn't translate at all though: resolved doesn't priorize DNS configuration over each other, it doesn't have to, as it can route traffic to multiple servers on multiple interfaces simultaneously and take the first positive answer (or last negative one). To which interfaces traffic goes is purely decided on search/routing domains, which is a lot more fine-grained and expressive than priority based systems. Most likely we should just ignor the value.

[zx2c4]

Most likely we should just ignor the value.

Perhaps ignore and spit a warning? Or ignore silently like debian's resolvconf does. Your call.

[bl33pbl0p]

+1 for this.

[poettering]

A PR implementing this is waiting in #8296