This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update product-os/flowzone action to v11.3.11

Detected dependencies

I am running DNSCrypt-Proxy on a Rasbpberry Pi 4 with Pi OS via PiHole.

Since the update to version 2.1.0 the proxy no longer appears to be working. The docker logs show that the service is ready, and loads the server lists, however I am unable to browse to any websites. I have tried a fresh dnscrypt-proxy.toml file but the problem still exists. If I revert to version 2.0.45, everything works as before. I am using anonymized DNS.

In my .toml I have:

log_level = 1
dnscrypt_servers = true
doh_servers = false
odoh_servers = true
require_dnssec = true
require_nolog = true
require_nofilter = true

I've also uncommented the section to use the lists of ODOH servers and relays.

Under the anonymization section, I've made sure every server has a valid route, and I have this:

skip_incompatible = true
direct_cert_fallback = false

The problem is that ODOH servers work, but Anonymized DNSCrypt ones don't.

In the log, for every Anonymized DNSCrypt server, I get this:

[NOTICE] Anonymizing queries for [<server>] via [<relay>]
[NOTICE] [<server>] OK (DNSCrypt) - rtt: XXms
[INFO] [<server>] couldn't be reached anonymously, it will be ignored

Right now the log is showing different timezone from my location, would be helpful if you can do that. Thanks

Hey Kyle. Hope everything is well.
I was trying to get at the dnscrypt logs but can't figure out how to. I can't attach to the container with a shell so can't go in and manually look at the logs. I was wondering if you had any ideas or suggestions?

In the dnscrypt-proxy.toml, there is an option to enable logging:

## Log file for the application, as an alternative to sending logs to
## the standard system logging service (syslog/Windows event log).
##
## This file is different from other log files, and will not be
## automatically rotated by the application.

# log_file = 'dnscrypt-proxy.log'

Is there a way to view it (or the standard syslog) in the container?

Thanks,
Adit

I deployed dnscrypt-docker-proxy, and saw in the logs the "permission denied" error discussed in issue #15. After reading through the comments there, I realized that the problem is that the config directory I specified was owned by root:root, and changing it to nobody:nogroup fixed the error.

That issue was resolved by adding a note to the README stating:

# note that the files must be readable by world, or owned by nobody:nogroup

but I suggest that this be further clarified to indicate that it's not just any provided configuration files that must have this ownership, but the provided configuration directory itself must have it as well to avoid permission errors.

Normally, one can go into docker container shell and check extra logs using docker exec -it container /bin/sh. I've tried bash, sh, /bin/bash, /bin/sh - always the same error:

OCI runtime exec failed: exec failed: unable to start container process: exec: "/bin/sh": stat /bin/sh: no such file or directory: unknown

How can I access the container to check extra logs?

Hi.

I have running dnscrypt-proxy with mapped volume to store dnscrypt-proxy.toml configuration file and I'm getting permission denied for both files at docker logs.

[WARNING] /config/public-resolvers.md: open sf-psizzome646u2elx.tmp: permission denied

Both files appeared at mapped volume first time I run, but why is it now showing permission denied? Both files have same user:group like configuration file.

Any way to not have those permission denied?

Thanks.

Hello!

I hope you are doing well!

We are a security research team. Our tool automatically detected a vulnerability in this repository. We want to disclose it responsibly. GitHub has a feature called Private vulnerability reporting, which enables security research to privately disclose a vulnerability. Unfortunately, it is not enabled for this repository.

Can you enable it, so that we can report it?

Thanks in advance!

PS: you can read about how to enable private vulnerability reporting here: https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository

Hi Kyle,

First I wanted to say that this image is great, I just love it!

The only thing missing is support for timezone (specially if you want to output nx.log like I do). Normally it's very trivial to add TZ=America/Montreal as an envrionement variable but the package tzdata needs to be installed on the image first.

The overhead should be very minimal, specially on alpine.

Let me know if this can be added or if you have a workaround I'm all ears.

Thank you!

https://github.com/DNSCrypt/dnscrypt-proxy/releases/tag/2.1.0

I don't know if this is an issue with the 2.1.0 build or whether there is something I am not doing correctly with the dns-proxy.toml file to get oDoH working. I have set the parameters as I believe they should be. The dnscrypt-proxy shows that the server list has loaded but I am unable to browse any websites. If I switch my config back to use DNSCrypt Anonymised DNS everything works. Below is an extract from the server log, and an extract of what i have put into the dsncrypt-proxy.toml file,

Thanks.

[2021-08-18 20:04:04] [NOTICE] dnscrypt-proxy is ready - live servers: 7,
[2021-08-18 20:04:04] [NOTICE] Sorted latencies:,
[2021-08-18 20:04:04] [NOTICE] - 212ms odoh-id-gmail,
[2021-08-18 20:04:04] [NOTICE] - 33ms odoh-cloudflare,
[2021-08-18 20:04:04] [NOTICE] - 43ms odoh-koki-ams,
[2021-08-18 20:04:04] [NOTICE] - 108ms odoh-crypto-sx,
[2021-08-18 20:04:04] [NOTICE] - 250ms odoh-jp.tiar.app,
[2021-08-18 20:04:04] [NOTICE] - 276ms odoh-tiarap.org,
[2021-08-18 20:04:04] [NOTICE] - 308ms odoh-jp.tiarap.org,
[2021-08-18 20:04:04] [NOTICE] Server with the lowest initial latency: odoh-cloudflare (rtt: 33ms)

Changes I have made to the dnscrypt-proxy.toml file

server_names = ['odoh-id-gmail', 'odoh-cloudflare' , 'odoh-crypto-sx' , 'odoh-jp.tiar.app' , 'odoh-jp.tiarap.org' , 'odoh-koki-ams' , 'odoh-tiarap.org']

Use servers implementing the Oblivious DoH protocol

odoh_servers = true

ODoH (Oblivious DoH) servers and relays

[sources.'odoh-servers']
urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/odoh-servers.md', 'https://download.dnscrypt.info/resolvers-list/v3/odoh-servers.md', 'https://ipv6.download.dnscrypt.info/resolvers-list/v3/odoh-servers.md', 'https://download.dnscrypt.net/resolvers-list/v3/odoh-servers.md']
cache_file = 'odoh-servers.md'
minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
refresh_delay = 24
prefix = ''
[sources.'odoh-relays']
urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/odoh-relays.md', 'https://download.dnscrypt.info/resolvers-list/v3/odoh-relays.md', 'https://ipv6.download.dnscrypt.info/resolvers-list/v3/odoh-relays.md', 'https://download.dnscrypt.net/resolvers-list/v3/odoh-relays.md']
cache_file = 'odoh-relays.md'
minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
refresh_delay = 24
prefix = ''

routes = [
{ server_name='odoh-id-gmail', via=['odohrelay-crypto-sx', 'odohrelay-surf' , 'odohrelay-koki-bcn' , 'odohrelay-koki-ams'] },
{ server_name='odoh-cloudflare', via=['odohrelay-crypto-sx', 'odohrelay-surf' , 'odohrelay-koki-bcn' , 'odohrelay-koki-ams'] },
{ server_name='odoh-crypto-sx', via=['odohrelay-crypto-sx', 'odohrelay-surf' , 'odohrelay-koki-bcn' , 'odohrelay-koki-ams'] },
{ server_name='odoh-jp.tiar.app', via=['odohrelay-crypto-sx', 'odohrelay-surf' , 'odohrelay-koki-bcn' , 'odohrelay-koki-ams'] },
{ server_name='odoh-jp.tiarap.org', via=['odohrelay-crypto-sx', 'odohrelay-surf' , 'odohrelay-koki-bcn' , 'odohrelay-koki-ams'] },
{ server_name='odoh-koki-ams', via=['odohrelay-crypto-sx', 'odohrelay-surf' , 'odohrelay-koki-bcn' , 'odohrelay-koki-ams'] },
{ server_name='odoh-tiarap.org', via=['odohrelay-crypto-sx', 'odohrelay-surf' , 'odohrelay-koki-bcn' , 'odohrelay-koki-ams'] }
]

Hello,

First of all, thank you for the great image. I hadn't updated to the latest image for quite awhile and decided to do that today. I run this image on two Raspberry Pis. On the first Pi, a Raspberry Pi 2, I ran docker pull klutchell/dnscrypt-proxy which pulled the latest image, removed the old container, and executed my docker run command. Everything went good and I was up and running successfully on version 2.1.5.

On the second Pi, a Raspberry Pi Zero, I went through the same process, but this time the container running on the latest image constantly restarts. The status when running docker ps -a shows statuses such as Restarting (132) 7 seconds ago. I also tried specifically pulling the linux/arm/v6 image by its sha256 hash, in case the wrong architecture was being pulled, but the result was the same. Reverting back to the prior image of version 2.1.4 runs without issue and is what I've been running for months.

Any thoughts on what changed between the last two images that would cause the latest to no longer successfully run on the Pi Zero? Any way I could help troubleshoot this? Since it runs fine on the Pi 2, but not the Zero that leads me to believe it may be related to the Pi Zero's linux/arm/v6 architecture.

Thanks again!

Hello. I've been using your docker container, dnscrypt-proxy, for about a month now and it's worked fine. I'm mapping to an external configuration folder - -v /path/to/config:/config. I did not have the -c /config/dnscrypt-proxy.toml option and it worked as expected until the latest image.
Do you have any suggestions as to what may have "broken" it?

--
In the mean time I'll go back to 2.0.27.

Thanks,
Adit Sood

I have a fully working Pi-hole Docker container (https://github.com/pi-hole/docker-pi-hole) and want its upstream DNS server to point to this dnscrypt-proxy Docker container. I have tried using the IP address and appropriate port of both the host machine and the dnscrypt-proxy Docker container but that results in DNS requests not being resolved.

My dnscrypt-proxy.toml file is the same as the example-dnscrypt-proxy.toml file except with for changing the listen_addresses to listen_addresses = ['0.0.0.0:53000'].

I use docker-compose to run my containers. As a result, each container runs in bridge networking mode with their own, separate network. They are all on the same LAN (no VLAN on my network) and there have been no issues with my Plex Docker container (also on its own network) communicating with my Pi-hole Docker container. I have been able to run docker-compose up for dnscrypt-proxy and it appears to work looking at the log file below:

dnscrypt-proxy    | [2020-08-05 15:51:08] [NOTICE] dnscrypt-proxy 2.0.44
dnscrypt-proxy    | [2020-08-05 15:51:08] [NOTICE] Network connectivity detected
dnscrypt-proxy    | [2020-08-05 15:51:08] [NOTICE] Now listening to 0.0.0.0:53000 [UDP]
dnscrypt-proxy    | [2020-08-05 15:51:08] [NOTICE] Now listening to 0.0.0.0:53000 [TCP]
dnscrypt-proxy    | [2020-08-05 15:51:09] [NOTICE] Source [public-resolvers] loaded
dnscrypt-proxy    | [2020-08-05 15:51:09] [NOTICE] Source [relays] loaded
dnscrypt-proxy    | [2020-08-05 15:51:09] [NOTICE] Firefox workaround initialized
dnscrypt-proxy    | [2020-08-05 15:51:09] [NOTICE] [d0wn-tz-ns1] OK (DNSCrypt) - rtt: 237ms
[...]
dnscrypt-proxy    | [2020-08-05 15:52:17] [NOTICE] [dnscrypt.eu-dk] OK (DNSCrypt) - rtt: 133ms
dnscrypt-proxy    | [2020-08-05 15:52:17] [NOTICE] Sorted latencies:
dnscrypt-proxy    | [2020-08-05 15:52:17] [NOTICE] -     8ms nextdns
[...]
dnscrypt-proxy    | [2020-08-05 15:52:17] [NOTICE] -   317ms doh.ffmuc.net
dnscrypt-proxy    | [2020-08-05 15:52:17] [NOTICE] Server with the lowest initial latency: nextdns (rtt: 8ms)
dnscrypt-proxy    | [2020-08-05 15:52:17] [NOTICE] dnscrypt-proxy is ready - live servers: 61

dnscrypt-proxy docker-compose.yaml file:

services:
  dnscrypt-proxy:
    container_name: dnscrypt-proxy
    image: klutchell/dnscrypt-proxy:latest
    ports:
      - "53000:53000/udp"
      - "53000:53000/tcp"
    volumes:
      - ./docker-volumes/dnscrypt-proxy.toml:/config/dnscrypt-proxy.toml
    restart: unless-stopped

networks:
  default:
    external:
      name: dnscrypt-proxy

command used to create the dnscrypt-proxy external network:

docker network create --ipv6 --subnet "172.xx.xx.0/24" --subnet "fdxx:xxxx:xxxx:xxxx::/64" dnscrypt-proxy

The network for the pi-hole is similar to above, but with different subnets.

services:
  dnscrypt-proxy:
    container_name: dnscrypt-proxy
    image: klutchell/dnscrypt-proxy:latest
    volumes:
      - ./dnscrypt-proxy/:/config/
    restart: unless-stopped
    networks:
      pihole_net:
        ipv4_address: 172.16.251.6

networks:
  pihole_net:
    name: pihole_net
    driver: bridge
    ipam:
      config:
        - subnet: 172.16.251.0/24
          gateway: 172.16.251.1

fails to start with error:
sudo docker logs dnscrypt-proxy:

[2021-07-09 17:15:52] [FATAL] Unable to load the configuration file [/config/dnscrypt-proxy.toml] -- Maybe use the -config command-line switch?
[2021-07-09 17:16:18] [FATAL] Unable to load the configuration file [/config/dnscrypt-proxy.toml] -- Maybe use the -config command-line switch?
[2021-07-09 17:17:11] [FATAL] Unable to load the configuration file [/config/dnscrypt-proxy.toml] -- Maybe use the -config command-line switch?

If I download and manually add https://raw.githubusercontent.com/klutchell/dnscrypt-proxy/main/dnscrypt-proxy.toml then the issue is resolved. But for some reason if the folder is mounted the container fails to start

installed the docker container and mounted the config via:

dnscrypt-proxy:
   image: klutchell/dnscrypt-proxy:latest
   container_name: dnscryptproxy
   restart: always
   ports:
     - "5053:53/udp"
   volumes:
     - $USERDIR/docker/dnscrypt-proxy/dnscrypt-proxy.toml:/config/dnscrypt-proxy.toml
   networks:
     traefik_web:
       ipv4_address: 172.21.0.43

Modified the server names to use Cisco: server_names = ['cisco', 'cisco-doh']

But on startup I see:
[2021-09-17 13:45:52] [NOTICE] Server with the lowest initial latency: uncensoreddns-ipv4 (rtt: 17ms)
[2021-09-17 13:45:52] [NOTICE] dnscrypt-proxy is ready - live servers: 123

Permission on the folder and toml file are nobody:nogroup 775

Hi @klutchell,

As it can be seen in commit remove drill and internal healthcheck the HEALTHCHECK was removed. My question is, why was it removed?
The reason I ask is because I'm trying to use this dnscrypt-proxy container image and it uses the same HEALTHCHECK.
But, if the drill cmd is taking a long time to complete the time out kicks in and that seems to leave drill processes in a zombie state. Causing a resource limit issue. As zombie processes still counts against the max user open processes. And that number is at some point met.
So some background on why it was removed would be lovely.

Thank you very much and a Happy Easter

Greetings!

It'd be handy to be able to provide a user id to run dnscrypt-proxy. Currently the container defaults to 1001.

Thanks for creating this container!

Hi there!

I happen to run this image on my Kubernetes cluster. It has happened to me a couple times that, for reasons not related to this image, the deployment is not working as expected. While most of the time is due to networking issues, DNS issues are notoriously hard to debug (as the meme goes).

I think being able to define a readiness or health probe could help with this, as Kubernetes (or any other orchestration system) could notice right away that a container is not working as expected and flag it somewhere.

Unlike HTTP probes though, DNS probes are not supported by orchestration systems themselves, so we need to resort to probes that run a command and see if it exits with 0. This is, however, impossible with the current image, as it does not include any binary that can be used to check if dnscrypt-proxy is running as expected.

I propose that we add dig to the container image, so users can define a readiness probe like the following:

readinessProbe:
  periodSeconds: 5
  failureThreshold: 2
  exec:
    command:
      - dig
      - google.com
      - "@127.0.0.1"
      - -p
      - "5353"

And therefore be notified when the container stops responding to queries.

Hello. Does your container support the new anonymized dnscrypt functionality?

I tried the most recent ARM image using anonymization witht the quad9 pri and alt DNScrypt servers but it gave an error.
Does the container need to be started with additional arguments or in a different way to use anonymization (like the official dnscrypt container). This is a link which may give you some info.

Thanks,
Adit

Hey there Chainguard here.

We noticed that you are using Chainguard Images, thank you! We wanted to make you aware of an upcoming change that will impact your project.

Starting August 16, 2023 public users will no longer be able to pull images from our registry (cgr.dev/chainguard) by tags other than latest or latest-dev. Please see the announcement for more information.

You are currently using the following.

In https://github.com/klutchell/dnscrypt-proxy-docker/blob/e540a0a2d099aff872a6805b4142027614f89974/Dockerfile:

• cgr.dev/chainguard/go:1.20.5

Our goal is to prevent your project from experiencing any disruptions. Please see the migration guide for options.

If there's more we can do to help please reply to this issue or email us at [email protected].

Thank you!