Docker image and/or instructions are utterly broken

[RobinJ1995]

• The documented -P option that's still in the example Kubernetes config files does not exist anymore.
• Examples and instructions only mount the keys folder. I had to dig into to entrypoint script to figure out that init also generates a configuration file outside this folder that DNSCrypt won't start without. But as it's outside the volume mount, a start after an init run will simply tell you to run init again as it can't find the config file.
• When the configuration is in place, the Docker image simply does not accept any connections. From inside the Docker container;

  root@dnscrypt-d75cf9b8-brjmj:/tmp# telnet localhost 53
  Trying 127.0.0.1...
  Trying ::1...
  telnet: Unable to connect to remote host: Cannot assign requested address

  
  root@dnscrypt-d75cf9b8-brjmj:/tmp# curl https://127.0.0.1 -v

• Trying 127.0.0.1:443...
• TCP_NODELAY set
• Connected to 127.0.0.1 (127.0.0.1) port 443 (#0)
• ALPN, offering h2
• ALPN, offering http/1.1
• successfully set certificate verify locations:
• CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• OpenSSL SSL_connect: Connection reset by peer in connection to 127.0.0.1:443
• Closing connection 0 curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to 127.0.0.1:443

  
  Neither port 53 (traditional DNS) nor port 443 (HTTPS) accept any connections.

This piece of software, or at least its Docker image, currently seems to be in a non-functional state.

[jedisct1]

Hi!

And thanks for reporting this!

The Kubernetes examples may not be used much. I personally never used Kubernetes, so maybe these configuration files don’t work. If you know how to fix them, your help would be much appreciated! If not, maybe we should just remove them.

Only the keys needs to be a persistent volume. Configuration files are created from its content, but these are ephemeral, recreated on startup, and you shouldn’t have to worry about them.

There’s an internal DNS server, but it is listening to port 553 and is not meant to be visible externally. There is no web server. Port 443 is for DNSCrypt, which is the purpose of that Docker image. It can optionally proxy HTTPS content to a HTTPS server, but that has to be enabled with -T <HTTP server address>.

Anyway, I can try to understand what is wrong with the Kubernetes example (maybe minikube is enough to run that configuration? I don’t have a Google Cloud account or whatever is needed to run the actual thing). Maybe the wrong option name (-P instead of -M) having been fixed makes it work as expected. If you know Kubernetes, please let me know! Thank you!

[jedisct1]

Without Kubernetes, the Docker image should work fine. This is what most servers are running and have been running for a long time.