I think it’s better to download the package from here - Release 2.0.44 · DNSCrypt/dnscrypt-proxy · GitHub
Unpack.
Run:
$ sudo ./dnscrypt-proxy
Thus, it can be used when needed.
Can be installed as a service.
I don’t see any reason for this. And there are reasons against that:
1 Like
Unbound (in Debian [archive]) is a is a validating, recursive, and caching DNS resolver with DoT and DoH support
However, at time of writing the Debian Unbound package does not enable DoH [archive].
In context of censorship circumvention, routing DoT over Tor is possible and fast enough according to the DoHoT: making practical use of DNS over HTTPS over Tor [archive].
Root name servers [archive] do not support encryption yet [archive].
1 Like
Wouldn’t it be possible to use DNSSEC and DoT within systemd instead?
1 Like
Quote Evaluating Local DNSSEC Validators – /techblog
Problematic Observations
- systemd-resolved suffers from a fundamental design flaw that causes it to frequently flag its upstream DNS server as being incompatible with DNSSEC (even though it is not). When this happens, all DNS lookups will fail (until the flag is manually cleared with
resolvectl reset-server-features). Different variations of this issue are reported in systemd bugs 6490, 8451, 9384 and 11171.- systemd-resolved will in some cases return an incorrect Bogus verdict for lookups that should have been Insecure. Some domains (e.g.,
savannah.gnu.org) give the wrong verdict 100% of the time, while others (e.g.,ring.nlnog.net) just fails sometimes. See bugs 9867 and 12545 for more information.
Thoughts?
1 Like
Not stable enough by default. If local IPv6 is enabled but unsupported by the ISP, DNS resolution will always fail. Not sure if there’s an upstream bug report yet.
Needs more testing and contributors.
ECH (ex ESNI) has already been available in Firefox and Chromium based browsers for quite some time now and is working. It can be tested with Wireshark-like inspection tools, using an online service like Cloudflare’s, or employing it directly with an ISP that blocks known domains using DPI and terminating TLS connection negotiations.
Unfortunately, it not only requires support from browsers (which will take a while to be properly documented and elevated from “experimental” stage for … reasons), but also server (resolver and target website) support. I only know of one other public resolver besides Cloudflare that officially supports it: Quad9. Good news on the websites front is that, by virtue of being situated behind Cloudflare’s edge, many of them are already supporting it.
I don’t see much use at the operating system level for employing a DNS service with ECH support, in its current implementation, since there aren’t m/any applications that make use of the SNI encryption key obtained from the TRR (trusted recursive server) besides browsers which can already do their own DNS resolving through DoH.
1 Like
Its OS feature, and btw windows (optionally) doing it (specially windows 11).
Having it doesnt harm, any app which support it then it gonna support it if not then not, there is no downside to this (app wont be disconnected if it doesnt support DOH/ECH).
So if possible to have it then better to have it.
If it’s possible + stable + improvement (+ free in effort + free in time) = yes, implement.
Obviously. But the technical details matter and that complexity cannot be brushed away. The topic of DNS security is complex… DNS Security - Kicksecure
dnscrypt-proxy is DNSSEC aware but dnscrypt-proxy at time of writing is DNSSEC non-validating. That I find weird. Therefore the answer for Use DNSCrypt by default in Kicksecure? (not Whonix!) for now is “no”.
When re-purposing this forum thread with a more general open question, “which DNS security improvements should Kicksecure deploy by default” the answer is unresolved too. First…
1. Choose an option.
I split the policy discussion from this and moved it here: