-
-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make TLS optional on remote-control #181
Comments
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 |
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 (optix2000/nsd_exporter#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.
(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:
You'll get a scary warning with this configuration though.
@wcawijngaards would you merge a pull request that brings |
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.
The text was updated successfully, but these errors were encountered: