Implicit assumption that dnsmasq is on-host

[lucab]

This is a followup from coreos/fedora-coreos-tracker#519 and containernetworking/plugins#380.

The DNSMasq services are not configured or managed by systemd but rather only by the plugin itself.

This part assumes that a dnsmasq binary exists in the host OS, it can be owned/run by the CNI plugin and its build-time configuration and its version suits whatever are the requirements here. This does not match reality on modern Linux distributions, where:

• the binary may not be found in PATH, if a dnsmasq service is not meant to run on that host (e.g. because it's not useful in such environment, or because it runs as a containerized service instead)
• the binary found in PATH may be tailored to users' need regarding versioning/patching/build-tuning, and it is anyway not a CLI utility

In short, this proposed plugin takes a design decision to use an on-host dnsmasq to implement part of its logic. However, that binary is commonly regarded as a user-service, not a widespread CLI utility.
This clashes with real world Linux distributions tailored at containerized workloads, which is where this plugin is most likely to run. Additionally, dnsmasq is a component with a less-than-stellar security history.
A memory-safe and self-contained design for the same feature would better suit CNI consumers.

[Ma124]

I've already experimented with creating a plugin which uses github.com/miekg/dns.

My design implements the CLI of a CNI plugin and provides a special command-line switch to launch into DNS Server mode.

When a container joins the network, the plugin checks if there's already an instance in DNS Server mode running and if there isn't, starts one by calling os.Args[0] with the special switch.

Then the plugin sends the instructions about which Domains map to which IPs by RPC over a Unix Domain Socket.

When a container disconnects, the plugin checks again whether a DNS Server is running. If there is, it sends instructions to the server to unmap the IPs. If this was the last container, the server waits for new directions for a bit and then shuts down if there aren't any. If there was no server running in the first place, it does nothing.

A CHECK could be implemented either by just checking if there's a running DNS Server or by sending a DNS query and checking whether it gets resolved correctly.

So much for the theory. But in practice, I haven't got the DNS Server working yet, and I'm not very familiar on how to bind only to specific network interfaces.

I'm not quite sure how to integrate this with the current project, but I'd be happy to contribute to this repo. I'm always open for feedback on the design or concrete implementation ideas!

[baude]

the podman team has made an explicit decision to not integrate networking into our code such as docker has done. this comes with benefits and disadvantages. requiring dnsmasq is one of those disadvantages. when this work was done and planned, we double checked for dnsmasq on fcos and it was present.

[dshenai]

Hi,

Is it possible to confirm that the following is also an implicit assumption :
The dnsname service will refer to the host's /etc/resolve.conf to resolve any names, that it can not, on its own

This means that the entries (second entry onward, as first entry is dnsname server) in container's /etc/resolv.conf (which could be referring to a DNS different than the one being referred by host) do not matter. Only host's resolve.conf is referred by dnsname plugin, in case, the resolution is not possible through its own addnhosts conf file.

Could you please confirm that above is the correct understanding?

Thank you

[mheon]

Please be aware that dnsname has been deprecated, and replcaed by the Netavark/Aardvark network tools. These do not require external dependencies, a deliberate choice we made due to the experiences we had with dnsname. All development on this repo has halted as such.