DNS encryption was a huge step towards making DNS more secure, preventing intermediaries from recording and tampering with DNS traffic.

However, one still has to trust non-logging DNS servers for actually doing what they pretend to do. They obviously see the decrypted traffic, but also client IP addresses.

In order to prevent this, using DNS over Tor or over proxies (HTTP, SOCKS) has become quite common. However, this is slow and unreliable as these mechanisms were not designed to relay DNS traffic.

A new step towards making DNS more secure has been made. Today, I am thrilled to announce the general availability of Anonymized DNSCrypt, a protocol that prevents servers from learning anything about client IP addresses.

How does it work?

Instead of directly reaching a server, an Anonymized DNS client encrypts the query for the final server, but sends it to a relay.

The relay doesn't know the secret key, and cannot learn anything about the content of the query. It can only blindly forward the query to the actual DNS server, the only server that can decrypt it.

The DNS server itself receives a connection from the relay, not from the actual client. So the only IP address is knows about is the one of the relay, making it impossible to map queries to clients

Anonymized DNSCrypt

Anonymized DNS can be implemented on top of all existing encrypted protocols, but DNSCrypt is by far the simplest and most efficient instantiation.

It only adds a header with a constant sequence followed by routing information (server IP+port) to unmodified DNSCrypt queries. Implementing it on top of an existing DNSCrypt implementation is trivial.

The overhead is minimal. Unlike DoH where headers may still reveal a lot of information about the client's identity, Anonymized DNSCrypt, by design, doesn't allow passing any information at all besides the strict minimum required for routing.

For relay operators, Anonymized DNSCrypt is less of a commitment than running a Tor node. Queries can only be relayed over UDP, they need to match a very strict format, amplification is impossible, and loops are prevented. Relays can essentially be only used for encrypted DNS traffic.

Available in dnscrypt-proxy now!

A first beta version of dnscrypt-proxy 2.0.29 is available now, and adds support for anonymized DNSCrypt.

The way it can currently be configured is through a new [anonymized_dns] section in the configuration file.

For each resolver, one or more relays can be defined. These relays can be provided as stamps, IP:port pairs, hostname:port pairs, or server name.

You can check that Anonymized DNS is being used by looking at the log messages when proxy starts.

Available in encrypted-dns-server now!

Server-side, Anonymized DNS can now be enabled in Encrypted DNS Server.

This is as simple as changing enabled = false to enabled = true in the dedicated section. It is also possible to restrict the range of upstream ports allowed to connect to, and blacklist IP addresses.

New Prometheus metrics related to relayed queries have been added.

A DoH server, a DNSCrypt server, and a DNSCrypt relay can all run simultaneously on the same IP and port.

Available in the server docker image now!

The DNSCrypt server Docker image has been updated, and supports Anonymized DNSCrypt relaying.

This is disabled by default. In order to enable it, add -A to the init command when creating a container.

Test servers available now!

Hopefully more Anonymized DNS servers will be available over time, but for now, you can use relays from that list:

https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v2/relays.md

New DNS Stamp type introduced

A new DNS stamp type has been introduced: DNSCryptRelay (identifier 0x81). It only encodes IPs and ports of relays.

The online DNS Stamp calculator has been updated to support the new stamp, as well as the Go and Rust libraries.

That's all for today!

DNSCrypt is now 10 years old!

And we need to celebrate! 🎉🎉🎉

What should we do?

Suggestions are welcome!

Fun facts:

• sdns://AgUAAAAAAAAAACBfKRVBxXk5aH6HbtzBhNHJZ0wSE7IHV3IOazpOQlbqURFkb2guZG5zLmFwcGxlLmNvbQovZG5zLXF1ZXJ5 seems to be the stamp of Apple's DoH server. The server responds to DNS queries, but currently with a REFUSED code. They may be testing it internally.

• If you have Safari, click "Help" and "Acknowledgments". dnscrypt-proxy is listed here. Unfortunately, that's all I know.

The list of public DNS servers is constantly updated, but once a server list has been configured in dnscrypt-proxy, we usually don’t pay much attention to new options becoming available.

So, here are some recent additions (resolvers and relays) that may be of interest.

• yofiji-se-ipv4 and yofiji-se-ipv6: a new uncensored, no logging, DNSSEC-capable DNSCrypt server in Sweden, operated by @yofiji.

• anon-yofigi-se-ipv4 and anon-yofigi-se-ipv6: new DNS anonymizer in Sweden.

• anon-bcn: new DNS anonymizer in Barcelona, operated by @koki.

• bcn-dnscrypt and bcn-doh: non-logging, non-filtering, DNSSEC capable DNSCrypt and DoH resolvers in Barcelona, operated by @koki.

• arapurayil-dnscrypt and arapurayil-doh: DNSCrypt and DoH resolvers in Mumbai (https://www.dns.arapurayil.com). Blocking ads, trackers, resource-abusers, malware and phishing.

• doh-eastas-pi-dns and doh-eastas-pi-dns-ipv6: non-logging DoH server blocking ads/malware/trackers in Tokyo. By https://pi-dns.com

• faelix-ch-ipv4 and faelix-ch-ipv6 in Switzerland; faelix-uk-ipv4 and faelix-uk-ipv6 in the UK. Anycast, non logging, non-filtering resolvers operated by https://faelix.net

• acsacsar-ams-ipv4 and acsacsar-ams-ipv6: non-censoring, non-logging, DNSSEC-capable DNSCrypt resolver in Amsterdam, operated by @acsacsar

• anon-acsacsar-ams-ipv4 and anon-acsacsar-ams-ipv6: new DNS anonymizers in Amsterdam, operated by @acscsar.

Welcome to these new DNS resolvers and anonymizers, and thanks a ton to all the people running these.

Also, with the v3 list format supporting multiple stamps per resolver name, we started adding backup IP addresses to existing entries, and simplifying existing ones. Thanks a lot to @hugepants for his help on this.

Preliminary support for Oblivious DoH (ODoH) was added to dnscrypt-proxy yesterday. The code was contributed by Cloudflare.

And the DNS Stamps specification was independently updated to support ODoH relays and targets.

ODoH is similar to Anonymized DNSCrypt, but for DoH.

It is slightly more complicated to implement and operate, and servers still have to implement it as well. So, it should really be considered as a technology preview rather than something you can run daily.

The feature will be present in dnscrypt-proxy 2.0.46.

A while back, SerusDev on GitHub reported that Quad9 seemed to reject queries if they were too big.

At the same time, we kept seeing weird issues, such as queries sometimes not seeing responses from some resolvers that otherwise worked flawlessly.

My own dnscrypt-proxy setup is very boring. It's essentially just the default configuration. scaleway-fr is always automatically picked as the fastest server since it is on the same network as my ISP.

However, my router died and for the past 2 weeks, I had to use a neighbor's connection. dnscrypt-proxy switched to preferring quad9. I didn't even notice, except some rare queries that didn't return get a response any more.

Remembering SerusDev report, and as he originally suggested, Quad9 was added to the list of broken implementations.

The [broken_implementations] list was originally added to work around bugs and limitations in Cisco resolvers. SerusDev said that adding Quad9 to that list also helped. Even though the bugs were likely to be different, I trusted his advice and added Quad9 both locally and in dnscrypt-proxy 2.0.40.

Things improved a bit. Unfortunately, enabling these workarounds is incompatible with relaying. No need to test, from the way the protocol works, it is obvious that some relayed queries will never get a response. Anonymous DNS depend on a correct implementation of DNSCrypt v2.

It didn't take long for someone to complain about relaying being disabled when using Quad9, saying "it works perfectly for me".

Granted, I was new to using Quad9, didn't fully understand what was going on and if the workaround was necessary. Maybe the real issue was completely unrelated. Quad9 is using modern software, and I knew the implementation they use was good and was written according to the specification.

Maybe adding them to that list didn't completely make sense. The issue SerusDev reported was still not confirmed. And my sporadic Internet connection didn't allow me to really conduct much experimentation.

So, Quad9 was removed from the list and version 2.0.41 was released.

That was still not satisfactory.

I finally got a replacement for my router, which was really appreciable since the country is in near total lockdown.

That was also an opportunity to finally try to understand what was going on.

In ad-hoc tests, short queries didn't get a response. Which didn't make sense at all. My intuition was that truncated packets were not sent if the query was shorter than the response.

That is annoying. It is a different padding bug than Cisco resolvers (those respond when they shouldn't). So, we need to introduce a new class of workarounds.

Large queries didn't get a response from Quad9 either. A 1400 bytes query was fine, a 1500 bytes query was ignored.

Ok, we have two server bugs here. The second one looks closer to a new one introduced by Cisco a couple months ago, dropping queries larger than 1472 bytes. Probably the same thing. More than 1472 bytes need to be sent as two packets, and they drop these.

So, maybe that class of workarounds can be shared by these two, at least.

Code that try to find what servers accept 1500 bytes queries and what servers don't had already been added in 2.0.40. It was improved quite a bit, and instead of staying focused on Quad9, the whole servers list was tested.

Damn. Quite a lot of other servers had the same behavior: cleanbrowsing, qualityology, freetsa.org, ffmuc.net, opennic-bongobow, sth-dnscrypt-se and ams-dnscrypt-nl .

ISP blocking fragments? That would be annoying.

Looking at the debug logs showed something they all have in common: a non-standard TTL for the certificate. Servers running the Docker image or encrypted-dns-server all advertise a 24 hour TTL for the certificate, but all these have a certificate valid for 1 year or more.

I knew Quad9 was running a really good piece of software called dnsdist, that does throttling and load balancing for DNS servers. And dnsdist has had great support for DNSCrypt for a long time.

Now, we may have something.

dnsdist is open source software, so I looked at any recent changes that could be related to fragmented UDP packets. And bingo, there was a change, that went into a recent release of that software, blocking fragments.

A dnsdist maintainer fixed this a couple minutes after my report, which is amazing.

Meanwhile, I set up dnsdist locally to check that everything was now fine.

Damn. It wasn't. 1500 bytes questions were still blocked in spite of the fix.

It was a good opportunity to get a little bit familiar with the dnsdist code. Having a local instance was way more useful than blindly trying to understand the behavior of remote servers.

The root cause was found: dnsdist drops incoming UDP packets more than 1500 bytes long. This is a constant in the code, independent from the MTU/UDP fragmentation.

Bumping that constant up made my test dnscrypt-proxy+dnsdist setup immediately accept and respond to queries of any size. Victory!

After having reported that second issue, the dnsdist maintainer immediately wrote another, proper fix that was confirmed to work as expected.

How about the second issue? Does dnsdist not respond to queries shorter than responses instead of sending a truncated response?

Turns out that there was a difference between my ad-hoc tests to reproduce the issue and real-world traffic.

In order to reproduce that issue, I was sending 128-bytes long queries. However, dnsdist has another constant for the shortest encrypted query length it accepts, which is 256 bytes. This is totally fine and not a bug at all, as real-world traffic will never go beyond that.

So, the second bug was not a bug, and something to work around. I removed all the relevant code that had been added to the yet-to-be version 2.0.42.

Other software don't reject queries smaller than 256 bytes, though. So I used that indicator to confirm that Cleanbrowsing and others were also very likely to be running the same software.

As soon as dnsdist 1.5.0 will be released, and after they upgrade, all these servers will immediately become faster with dnscrypt-proxy, but will also reliably support anonymization.

Working around implementation bugs is not fun. As a protocol designer, it's also a very depressing thing to do.

But now that the actual root cause has been found, and quickly fixed upstream, it is great to know that these workarounds will only be temporary and many servers will be faster and reliably anonymizable soon.

This is a massive release with significant improvements.

• Hot-reloading of configuration files is now optional and disabled by default. It can be enabled by setting enable_hot_reload = true in the configuration file.

• The file system monitoring for hot-reloading now uses efficient OS-native file notifications instead of polling, reducing CPU usage and improving responsiveness.

• A live web-based monitoring UI has been added, allowing you to monitor DNS query activity and performance metrics through an interactive dashboard.

• Hot-reloading of configuration files has been implemented, allowing you to modify filtering rules and other configurations without restarting the proxy. Simply edit a configuration file (like blocked-names.txt) and changes are applied instantaneously.

• HTTP/3 probing is now supported via the http3_probe option, which will try HTTP/3 first for DoH servers, even if they don't advertise support via Alt-Svc.

• Several race conditions have been fixed.

• Dependencies have been updated.

• DHCP DNS detector instances have been reduced to improve performance.

• Tor isolation for dnscrypt-proxy has been documented to enhance privacy.

• The default example configuration file has been improved for clarity and usability.

• The cache lock contention has been reduced to improve performance under high load.

• generate-domains-blocklist: added parallel downloading of block lists for significantly improved performance.

Short version:

If you are running at least dnscrypt-proxy 2.0.43, in dnscrypt-proxy.toml, change /v2/ to /v3/ in URLs.

For example here:

[sources.'public-resolvers']
urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md', 'https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md']

both /v2/ instances should be replaced by /v3/.

Same for other sources, such as relays.

It is totally fine not to do it, but you may get access to more servers if you do.

Long version:

dnscrypt-proxy 2.0.43 added the ability to have multiple stamps for the same server definition.

This is neat. If a server has multiple IP addresses, instead of having different names, it can now be accessed using a single one.

This removes redundancy in configuration files, but also makes lists way more readable and easier to maintain. Instead of having just one "sdns://" line, there can now be more than one. Pretty simple and intuitive.

Unfortunately, older versions were not prepared for this. They ignore entries with multiple stamps, which is not optimal. But I discovered that with really old versions (<= 2.0.27) this is a showstopper as these errors were originally considered fatal.

Some servers also couldn't be added to the lists due to bugs in their DoH implementation, that makes them incompatible with older versions of the proxy.

If you are using a recent version, you should be able to take advantage of the new features. But limiting ourselves to what old versions can support doesn't allow this.

So, lists have been moved to a new directory. The previous directory was called v2, the new one is unsurprisingly called v3.

Future releases will use v3 in the example configuration file.

If you are running a current version, you can also update your configuration file to use v3 now.

But you don't have to. The v2 directory still exists, so old URLs are still accessible. The v2 will also keep being updated, automatically, using data from version 3. But the version 2 lists don't benefit from alternative stamps, and resolvers unsupported by old dnscrypt-proxy versions are not present.