Read through the above conversation and some other posts about this topic. This is my best attempt at figuring out how things might be able to work.
Before we even get to asking what kind of DNS resolution we want, we need to ask, what is our threat model? Who are we trying to protect against? Based on the above discussion, it looks like there are broadly X different threats that we would like to mitigate on the DNS level:
- Incorrect, maliciously crafted DNS responses intended to get the victim to connect to the wrong host. This is the most critical of the threats we want to mitigate. This could be caused by an attacker on the local network, a malicious ISP, or even a malicious third-party DNS provider. This is what DNSSEC is intended to mitigate.
- Blocked DNS replies preventing the victim from accessing the host they are attempting to access. This can be split into two different types of attacks:
- MitM attack by an adversary on the local network or between the router and the ISP. This can be mitigated by DoH, then blocking access to DNS becomes an all-or-nothing proposition where you either kill the victimâs Internet entirely or let everything through.
- âAttackâ perpetrated by the DNS provider itself, possibly for legal reasons. This should be able to be mitigated by recursive DNS resolution carried out through the root servers, however this leaves the MitM case unresolved. Sadly these canât be combined since the DNS root servers donât support encrypted DNS.
- Surveillance of DNS queries. Could be carried out by an eavesdropper on the network, an MitM, the ISP, the DNS provider, or anyone in between. Welcome to the world of unencrypted Internet traffic. This is more of a privacy concern than a security one.
- Can only be partially mitigated with DoH - this prevents anyone but the DNS provider from logging the connection, but this comes with similar problems to VPN services - youâre now trusting the DNS provider to be safe, and this is unverifiable except via auditing (which is a monumental task thatâs also easy to do wrong).
I believe thatâs the entirety of the threat model.
In an ideal world, the solution to this would be simple. The root DNS servers would support encrypted DNS, thus DNSSEC, DoH, and recursive resolution could be used in tandem, providing a semi-private, authenticated, difficult-to-censor solution. Everything is mitigated perfectly. Unfortunately, since the root DNS servers donât support this, a massive wrench is now thrown in the works:
- Fully effective anti-censorship is impossible. If you try to use the root servers unencrypted, your connection is world-readable and anyone in between you and the servers can choose to just not send packets that are trying to resolve things the man in the middle doesnât want you to access. Thus everyone between you and the servers can censor your connection. If you use a third-party server, you now trust them to not censor your connection - we know from history this is not something you can trust a third-party server to do because of the Quad9 lawsuit (they appear to have won that one but they might not win future battles) and the debacle between Cloudflare and archive.today (the later of which is a technical conflict but had an end-result that is indistinguishable from censorship to the end user). On top of that, even if a third-party DNS service is entirely trustworthy, you still canât trust that your connection wonât be censored, because an MitM between the third party and the root servers can trivially censor the third partyâs connection and thus censor yours. There is no anti-censorship, the best you can do is frustrate censorship. (Notably. Tor can frustrate censorship extremely well here, but even it isnât perfect since if your exit node is having its DNS restricted by censorship, that will affect you too.)
- Fully effective privacy is also impossible unless you bring Tor into the picture. Either everyone can read your DNS traffic, or a third-party who may very well be a tattletale can read your DNS traffic. If you route all your DNS over Tor, you can mitigate that, but thatâs about the only way to do it. (Note that I am intentionally assuming here that the root servers are somehow absolutely trustworthy and will never log or snoop on traffic beyond what is necessary to provide DNS - this is quite possibly a fatally flawed assumption, but if you donât want to trust even the root servers and the servers they delegate to, then youâre again stuck with âTor all the thingsâ. Weâre investigating solutions that donât require Tor, so we have to assume the root servers and the servers under them are trustworthy.)
- The only thing we can reliably prevent is a maliciously crafted DNS response. Thatâs it.
Just based on the above, my initial thought is that we need something better than DNS because this is just a mess. It would be far better if all machines had a master list of all domains and IP addresses on the Internet on them that would allow fully local DNS resolution, and have that list constantly updated on an as-needed basis. But thatâs obviously impractical for now and probably impractical in the long run (I assume the list of all domains on the Internet probably isnât public and probably is many hundreds of gigabytes if not terabytes of data), so letâs just forget about that for the time being.
There are (roughly) two approaches we can take at this point:
- If we canât guarantee a feature, donât even bother. Forget about privacy and anti-censorship and decide DNSSEC is as far as we want to take things. Force DNSSEC validation and use the root servers directly since thatâs the most trustworthy servers we can use. If the user wants privacy, they can use Tor, and if they want anti-censorship, they can start their own DNS server.
- Try to mitigate all the threats as best as we can. Choose a trustworthy third-party DNS provider, use DoH to provide better privacy and assume theyâll do the right thing with regard to privacy and censorship if theyâre legally capable of doing so. Pick the country in which the provider is in carefully so that legal concerns are as unlikely as possible to be a problem.
On the surface, the second option sounds obviously better than the first one. Perhaps it is. Iâm going to argue for the first option though, because I think itâs a better direction for Kicksecure specifically to go.
- Trusting a specific third-party DNS provider is really scary. At least if we use the root servers directly, only targeted users will have their privacy violated. If we make everyone use MyAwesomeDNS (a random fictional company) and it turns out MyAwesomeDNS is sending detailed logs about everything to the the Malicious Republic of Hackers (a random fictional country), thatâs going to have a far worse impact on our userbase than using the non-private root servers.
- Third-party DNS providers seem to be far easier targets than the core DNS servers for censorship-related interference. This is the only reasonable explanation I can see for why Sony went after Quad9 to get some websites blocked rather than trying to get them kicked off of the Internet as a whole.
- If a third-party DNS provider goes down permanently, all our users will lose Internet and have to manually fix it to get it working again. We wonât be able to just push an update to fix it since our users would have to have Internet in the first place to get that update. Theyâll still be able to contact IP addresses, sure, but most âusefulâ ways of using the Internet will be gone, including the ability to download anything with
apt.
- Trusting a specific third-party provider opens us up to controversy. DNS providers are like ice cream flavors - people have strong preferences here and may be highly critical of someone trying to âpush their preferenceâ if it differs from theirs. As has been covered above, allowing users to pick their desired server is also problematic from both a UX standpoint and an avoidance-of-confusion standpoint, and even that may not fix the issue (if we include Cloudflare in the list, some people will be upset with us, if we donât include Cloudflare in the list, different people will be upset with us).
- Thereâs no way for us to know what third-party server is truly trustworthy. Popularity is not a good metric here, and thereâs no chance of any of us going and performing an audit on any provider. We donât have the time, experience, or money for that.
- Trusting a specific third-party provider is complex. Even if we assume all providers are perfectly truthful about how they work and what they do, figuring out the right attributes to look for in a third-party provider is no small task and there may be many factors we miss and that are only pointed out after we make a choice. Trusting the root servers and the servers they delegate to is on the other hand almost trivial to justify - no choice of provider avoids indirectly trusting them. If youâre going to trust them anyway, keep the number of parties you trust low and just trust them directly. (This doesnât tackle the question of âbut what if the root servers and the servers under them are logging traffic invasively?â, and it is true that using a third-party provider might mitigate that risk if you found a trustworthy provider, but as established above finding a trustworthy provider is extremely difficult and doesnât really fix the problems anyway.)
With all of the above in mind, I think the option to go with ârecursive, unencrypted, validating, cachingâ is the clear winner. It doesnât handle censorship or privacy, but Tor can be used to solve or at least mitigate those problems better than any third party could even hope to achieve. This also falls in line with Kicksecureâs and Whonixâs goals - it remains solely security-focused, and allows Whonix to handle the privacy aspect of things.
Now, pivoting to the technical side of things, how do we actually get DNSSEC validation working? Unbound seems to be the only server that actually does the right thing here for some weird reason, but it has severe issues when IPv6 is supposedly available but isnât really. In that instance though, IPv6 traffic should just not work in general, so we could probably write some sort of service that would check IPv6 connectivity, configure Unbound to use it if it actually worked, and configure Unbound to avoid it if it didnât work. We could also attempt to upstream something similar to this into Unbound itself (something akin to do-ip6: only-if-working (not sure if this exists or even can exist), or perhaps an option to accept so-called âlameâ responses without hesitation), though this might take longer and might not be accepted upstream.