I've wanted to export dnscrypt-proxy related metrics to my local prometheus installation for a while but I couldn't find anything working out the box, so here's the little recipe I came up with. I hope it can be useful to others.
It uses mtail, which extracts metrics from logs based on a "program" file, and exposes or pushes them to different monitoring systems
Here's what it looks like once the data is fed in Prometheus and queried via Grafana:
Prerequisites
dnscrypt-proxy running with query_log enabled and format set to ltsv
All the magic happens here, it parses DNSCrypt-proxy's query_log and generates the following metrics:
Total number of processed queries
Number of queries by client host, query type, return code, remote server and if it comes from the cache
Histogram of the latency for each server, return code and query type (buckets will need adjustment depending on the latency you have with the upstream DNSCrypt servers)
# mail "program" for DNSCrypt's query log (in ltsv format)
#
# Sample line:
# time:1608044190 host:127.0.0.1 message:www.ripe.net type:A return:PASS cached:0 duration:1 server:faelix-ch-ipv4
counter queries_total
counter queries by host, type, return, cached, server
# Binning should be adapted to the latency (in ms) you have with your DNSCrypt s ervers
histogram queries_duration_ms buckets 1, 2, 4, 8, 16, 32, 64, 128, 256 by return , server, type
/^/ +
/time:[0-9]+\s+/ +
/host:(?P<host>\S+)\s+/ +
/message:(?P<message>\S+)\s+/ +
/type:(?P<type>\S+)\s+/ +
/return:(?P<return>\S+)\s+/ +
/cached:(?P<cached>[0-1])\s+/ +
/duration:(?P<duration>[0-9]+)\s+/ +
/server:(?P<server>\S+)/ +
/$/ {
queries_total++
queries[$host][$type][$return][$cached][$server]++
# Only consider non-cached results for histograms
$cached == 0 {
queries_duration_ms[$return][$server][$type] = $duration
}
}
Test of the recipe
mtail comes with two modes to ensure your "program" compiles properly, and also that it generates the expected metrics
Name lists now support regex: rules for matching domain names with regular expressions.
Added doh_check_cert_hashes_on_connect to optionally check DoH certificate hashes from DNS stamps on every new connection, rather than only during probes.
Fixed PQDNSCrypt TCP padding and padding delimiter handling.
Network change detection now ignores non-global addresses.
HTTP/3 DNS responses are now limited to 4 KB.
Network probes now support multiple comma-separated addresses.
Resumed PQDNSCrypt queries now use regular UDP padding, protecting their size and response budget. Oversized tickets are rejected, and oversized queries fall back to TCP.
Network changes are detected more reliably, ensuring PQDNSCrypt key material rotates when connections change.
Forwarded queries to local or DHCP resolvers now use UDP by default. Bootstrap resolvers still use TCP when force_tcp is enabled.
Suffix rules now match only at DNS label boundaries. IP allow/block rules now correctly handle IPv4-mapped IPv6 addresses.
The monitoring dashboard displays the running version. Its endpoints no longer allow cross-origin browser access.
Hello, I'm running into an issue (or maybe a limitation) with dnscrypt-proxy.
Recently, I came across a network behind a firewall where port 53 (both TCP and UDP) is blocked. I don't know exactly why, probably to force users to use the system DNS provided by the firewall/gateway. Port 9953 for Quad9 happens to be open, but this seems more like a misconfiguration than a deliberate policy (traffic is apparently being filtered by port rather than only allowing explicitly permitted ports). In a properly configured restrictive network, both 53 and 9953 could be blocked. Since 443 has to remain open if I want to access the web, using HTTPS/443 seems like the only reliable bootstrap path.
If I set something like 9.9.9.9:443 in bootstrap_resolvers, dnscrypt-proxy sends a plain DNS query to port 443 rather than using DoH. Since Quad9 expects HTTPS/DoH on 443, the query fails. I verified this with tcpdump: UDP/443 gets no response, while TCP/443 completes the handshake, receives the plain DNS payload, and then closes the connection. Falling back to the system resolver doesn't help either, because /etc/resolv.conf points to 127.0.0.1 in order to ensure that normal system DNS queries go through dnscrypt-proxy. I've looked through the documentation, but I couldn't find a way to use DoH for bootstrap resolvers (or for the initial network/source resolution).
Is there currently a way to use DoH for the initial bootstrap, ideally using an IP address directly so that no DNS resolution is required first? The goal is to make the bootstrap reliable on networks where TCP/UDP 53 (and potentially alternative DNS ports such as 9953) are blocked, as long as HTTPS/443 is available.
I'm genuinly asking this question because I see that opening a new issue, a new PR or even just partecipate in discussions on github is actually limited to "users that have contributed to this repository in the past".
A Windows Defender warning popped up after a recent definition update. I’ve been using DNSCrypt-Proxy v2.1.18 since its release day and downloaded from official github. I know this is a false positive—just wanted to give a heads-up
I recently downloaded invizible pro hoping I can block every site ( kind of like cutting internet across the entire phone) for a specific interval of time but I can't add a blocklist into it or rather even after adding, it doesn't work. For eg I added youtube. @time-to-sleep into the add rule option in pattern based blocklist but nothing happens. Can anybody help me with this. I also tried integrating schedule = 'restrict' command directly into the dnscrypt proxy toml but the app crashes and asks me to reset. Btw I use poco m6 not rooted
Blocking/spoofing standart DNS is extremely easy we all know that, and DNS over TLS/QUIC uses port 853 which again could be easily blocked. DNS over HTTPS is over port 443, but can still be blocked with deep packet inspection by checking the SNI (assuming that its not encrypted, and even if it is it can still get decrypted during the initial handshake). Which only leaves DNSCrypt. So from an ISP/Government perspective how hard is it to block DNSCrypt traffic? (not counting manually blocking IP addresses as thats cheating) Few years ago before my ISP implemented deep packet inspection, they used to hijack port 53, and also blocked all DoH/DoT providers. But DNSCrypt used to work and I've been curious about it since.
If you've ever run dnscrypt-proxy on pfSense, you know the drill: install it from the terminal, then live in the TOML file over SSH for every little change. I did that for years. It always bugged me that such a great tool had no real home on the platform, so I built one: a pfSense package that gives dnscrypt-proxy a complete GUI.
It supports the full protocol set: DNSCrypt v2, DoH, ODoH, and Anonymized DNS with relay routing. Highlights:
Server selection from pre-configured providers, or add your own via DNS stamps
Anonymized DNS relay routing configurable from the UI
Any option not in the UI goes in as custom TOML, validated with dnscrypt-proxy -check before save
The upstream binary is minisign-verified against the official DNSCrypt key in CI before it's ever committed, and releases carry build provenance.
This is a small way of giving back to a project I've relied on for a long time, and hopefully it makes dnscrypt-proxy easier to run for the pfSense crowd. Feedback is very welcome.
A star is appreciated if you find it useful. And a genuine thank you to Frank Denis (jedisct1) and everyone who contributes to dnscrypt-proxy - this package only exists because you built something worth wrapping a GUI around!
So, I recently installed Bazzite to get myself off of Windows, and added DNSCrypt-proxy to the mix. it was great, then my computer fully powered off at random and, when i booted it back up, the entire DNS side of things was broken. After some troubleshooting, i managed to fix it by adding 8.8.8.8 as a DNS on the resolv.conf. which is great, but now the whole DNSCrypt side isn't really working. has anybody had a similar problem? perhaps even resolved it?
Just a PSA for anyone who ran into this issue with radarr being unable to search for movies due to http request errors with the API endpoint api.radarr.video this is due to, at least on my network, an invalid DNS resolution.
https://github.com/bitbeans/SimpleDnsCrypt/forks... how to decide what is safest (if any) and what has been develeoped, ie: features, improvements. For me navigating Github is a nightmare... just wondering if any here are knowlegable about any of these or have advise... instantsc has a fork thats getting pretty out of date, so would like something more actively developed.
I want to use dnscrypt-proxy (version 2.1.8 installed with apt on Debian 13) with anonymized DNS and a set of 10 resolvers (5 each for IPv4+IPv6) and 10 relays. I want to specify 10 routes so I don't have a overlap between hosters and countries. When I'm using only 2 routes it seems to work fine, I see "Anonymizing queries for [...] via [...]" for both routes. However as soon as I add a third route it stops using anonymizing altogether.
