Default DNS Provider Discussion for Kicksecure (not Whonix!)

Development
21

Kicksecure('s servers) would be the best candidate for a recursive resolver, similar to how the GrapheneOS team uses their own servers:

This proposal reuses the same trust already provided from Kicksecure users, so only the technical implementation remains unaddressed. Here are a few base suggestions:

  1. DNSSEC-validated cached queries
  2. DoT/DoH(3)/DoQ/DNSCrypt from stub resolver to recursive resolver

Here are a few technical stretch goals:

  1. QNAME minimization[1] and aggressive NSEC(3) records[2]
  2. Opportunistic DNS encryption (DoT and DoQ) from recursive resolver to authoritative servers[3]
  3. Tor onion service similar to Cloudflare’s deployment[4]

I will be going though a lot of documentation/references about DNS during April for my own security and privacy needs, so I can provide step-by-step deployment instructions for the base suggestions if necessary, assuming a Debian(-like) cloud image.

  1. RFC 9156 - DNS Query Name Minimisation to Improve Privacy ↩︎

  2. RFC 9077 - NSEC and NSEC3: TTLs and Aggressive Use (obsoletes aggressive DNSSEC caching from RFC 8198) ↩︎

  3. RFC 9539 - Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS ↩︎

  4. Introducing DNS Resolver for Tor ↩︎

3 Likes
22

Unlikely that we’ll start hosting more infrastructure anytime soon. Adds lots of extra maintenance effort (sysadmin, legal, etc.).

Comparison with GrapheneOS is unsuitable. They’ve got a multiple of more users/donations/paid staff.

Writing guides on how to accomplish that can be useful since anyone can feel free to start providing such infrastructure as their own independent project.

1 Like
23

https://arxiv.org/pdf/2011.10121

By this we can use cloudflare (or any provider) to solve our DNS requests without any security or privacy concerns issues.

Method:

Your device locally encrypting ODoH query → Third-party relay → Cloudflare ODoH target → DNS resolution

  1. ISP or network sees encrypted HTTPS traffic.
  2. The relay know your IP address, but cannot decrypt the DNS query.
  3. Cloudflare decrypts the DNS query, but only sees the relay’s IP instead of yours.

Btw this is an already working thing not just an idea or a project that might come later.

1 Like
24

And if the relay and DNS provider are in cooperation, what then? The trust is just shifted from the DNS provider to the relay by doing this. If there were multiple relays, chosen randomly, and any random person could run a relay and have it added to a relay pool, and traffic was bounced between multiple relays, then it could work… but at that point you’ve just re-implemented Tor.

2 Likes
25

Let it be know I really hate crapflare cuz they have too much control over the web. If cloudflares complete infrastructure went down how much of the internet would be broken (put foil on and ponders if it is the plan?). The only credit I can give them is with ECH research.

What other providers have ODoH?

2 Likes
26

I like DNSCrypt but there are some caveats users can run into with systemd resolved and other settings depending on how they use it.

Can DNSCrypt interact negatively with VPN and TOR or can it be setup to seamlessly work so that:

  1. No broken DNS when using either
  2. No DNS leaks when using either
  3. Captive Portals Broken?
  • Captive portals are actively broken by DNSCrypt because they depend on DNS hijacking. dnscrypt-proxy has built-in mitigations, but you may need to temporarily disable encrypted DNS or use exception rules to authenticate on public Wi-Fi.

How would you address these 3 ???

1 Like
27

Decisions:

  • Cloudflare by default: Not planned.
  • Picking any centralized provider: Not planned.

As an optional, opt-in feature, if contributed [1], conceivable, but unlikely.

[1] First-Time Source Code Contributor Policy

1 Like
Implement a Local DNSSEC-Validating Recursive Resolver by Default in Kicksecure / was: Use DNSCrypt by default in Kicksecure? (not Whonix!)
28

Moderation comments:

Closed.

Reasons:

Development decisions are made.

Closing as per Development Discussion Policy [1] to avoid repetitive centralized provider discussions.

[1]