I wrote about the death of DNSCrypt and I recommend to use DNS-over-TLS which might be a thing, however the problem with DNS-over-TLS is that it leaks the hostname in plain text by the Server Name Indication (SNI) extension for TLS. This can be a problem and there will be no solution for it, the currently implementation of TLS-over-DNS is a bit tricky because not every server owner uses the RFC or he tries to ‘fix’ something which might break the connection, as a result you see often a disconnect or packages getting ‘lost’. That’s why stubby is unstable, cause every test server is nothing but that .. a test and there all more or less unstable for a daily usage.
So the old DNSCrypt is dead due some reasons and what you can use, DNS-over-TLS or .. well DNSCrypt-Proxy 2. The project is from the same Frank Denis,
Current status/features
Features | dnscrypt-proxy 1.x | dnscrypt-proxy 2.x |
---|---|---|
Status | Old PoC, barely maintained any more | Very new, but quickly evolving |
Code quality | Big ugly mess | Readable, easy to work on |
Reliability | Poor, due to completely broken handling of edge cases | Excellent |
Security | Written in C, bundles patched versions from old branches of system libraries | Written in standard and portable Go |
Dependencies | Specific versions of dnscrypt-proxy, libldns and libtool | None |
Upstream connections using TCP | Catastrophic, requires client retries | Implemented as anyone would expect, works well with TOR |
XChaCha20 support | Only if compiled with recent versions of libsodium | Yes, always available |
Support of links with small MTU | Unreliable due to completely broken padding | Reliable, properly implemented |
Support for multiple servers | Nonexistent | Yes, with automatic failover and load-balancing |
Custom additions | C API, requires libldns for sanity | Simple Go structures using miekg/dns |
AAAA blocking for IPv4-only networks | Yes | Yes |
DNS caching | Yes, with ugly hacks for DNSSEC support | Yes, without ugly hacks |
EDNS support | Broken with custom records | Yes |
Asynchronous filters | Lol, no, filters block everything | Of course, thanks to Go |
Session-local storage for extensions | Impossible | Yes |
Multicore support | Nonexistent | Yes, thanks to Go |
Efficient padding of queries | Couldn’t be any worse | Yes |
Multiple local sockets | Impossible | Of course. IPv4 & IPv6, as many as you like |
Automatically picks the fastest servers | Lol, it supports only one at a time, anyway | Yes, out of the box |
Official, always up-to-date pre-built libraries | None | Yes, for many platforms. See below. |
Automatically downloads and verifies servers lists | No. Requires custom scripts, cron jobs and dependencies (minisign) | Yes, built-in, including signature verification |
Planned features
- New super simple (to copy & paste), extensible format for servers parameters: “stamps”
- Filtering with regexes
- Offline responses
- Local DNSSEC validation
- Flexible logging
- Windows support that doesn’t suck
- DNS-over-HTTP2
- Some real documentation
Final words
It’s always good to have some alternatives, especially in case something dies or if you’re unhappy with solution x. I think the project looks as promising as the original DNSCrypt project and I will keep an eye on it.
A alpha download can be found here, since the project is on an earlier stage I not want to give a conclusion because I see the benefits and what is planned, such huge changes need time, testing and a lot effort, so give it time.
The given binaries worked on my end on Linux and under Windows, I had several disconnects but it overall already worked well.
You must be logged in to post a comment.