Open simondeziel opened 3 years ago
This is partially already supported, if you enable remote control using a unix socket. Then key and cert files are not needed, (use directory permissions). Use an absolute path to the socket to use this, so control-interface: "/tmp/nsd.control.sock"
instead of 127.0.0.1.
I know but that's however not always feasible to expose that socket to the consumer. Our use case is a prometheus exporter that runs containerized in a snap (https://github.com/optix2000/nsd_exporter/pull/8). This means the easy way is to use the localhost IP in which case it's annoying to do TLS as we need to copy the certs where the snap can access them.
Even if you can get nsd_exporter to find the keys, TLS still won't work if it's been built with a new-ish version of Go.
Oct 13 15:12:13 weatherwax nsd_exporter[54866]: 2021/10/13 15:12:13 x509: certificate relies on legacy Common Name field, use SANs instead
(subjectAltName makes little sense for this use-case but I'll leave that windmill to someone else.)
You could use socat to connect a Unix domain socket to a TCP socket. Or you you can trick NSD to create a plain transfer socket by creating two sockets:
remote-control:
control-enable: yes
control-interface: /var/run/nsd.ctl
control-interface: 127.0.0.1
control-port: 8952
You'll get a scary warning with this configuration though.
[2021-10-13 16:22:25.890] nsd[39847]: warning: control-interface 127.0.0.1 is not using TLS, but plain transfer, because first control-interface in config file is a local socket (starts with a /).
@wcawijngaards would you merge a pull request that brings rc->use_cert
into the configuration file if I submit one? Since it's possible to create plain transfer sockets anyway, I think having it documented and easily configurable should be okay.
Unbound supports making TLS/certificate optional for the remote control facility using
control-use-cert
. This is handy when listening on localhost.Same would be useful with NSD.