Use DNSCrypt by default in Kicksecure? (not Whonix!)

Just created Encrypted DNS | Madaidan's Insecurities


Looks good. What about DNSSEC?
Some domains support it. Other’s don’t. Therefore probably nobody is setting their browsers or programs to only accept authenticated DNS replies.

1 Like

Encrypted DNS | Madaidan's Insecurities will likely apply to DNSSEC too.

This paper is nice as its relative to show aspects of clearnet DNS flaws and advantages of GNS.

This tool looks cool for system DNS.

1 Like

maybe this can be added to ESNI advantages and compromises:

1 Like

DNSSEC seems more useful in theory. Under the assumption that DNSSEC cannot be stripped similar to sslstrip… [1] [2]

DNSSEC can transmit information signed/authenticated information. (DNSSEC root trust key… [3]) Some such information can be potentially very worthwhile.

  • CAA policy:
  • DANE TLSA [5] [6]
    • In short: use DNS (authenticated by DNSSEC) to authenticate the TLS certificate.
    • Not an option for browsers yet, or ever(?) but perhaps good for mail servers? Didn’t investigate that.
  • Other seemingly less important DNS entries such as SPF, DKIM, DMARC.

Can browsers such as Firefox, Chrome, Tor Browser verify DNSSSEC and can these be DNSSEC striped in their current default configuration? If yes, are fixes planned? I mean, if a domain was DNSSEC signed and the signature was stripped, would these browsers reject the connection?

[1] Let’s call that DNSSEC strip?

[3] Ignoring the issue of who is holding the highest hierarchy DNSSEC root signing key. At least it is a different key holder than the many trusted key holders in the TLS CA system.
[4] public key infrastructure - Why don't browsers check CAA records to help ensure a certificate is valid? - Information Security Stack Exchange
[5] Dev/About Infrastructure - Kicksecure

It’s in Debian.
Kicksecure was previously enabling it by default. Considering an opt-in package to easily enable it.


I think it’s better to download the package from here - Release 2.0.44 · DNSCrypt/dnscrypt-proxy · GitHub
$ 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., give the wrong verdict 100% of the time, while others (e.g., just fails sometimes. See bugs 9867 and 12545 for more information.


1 Like

Why not using unbound

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.