Do you mean when communicating directly with a root DNS server over unencrypted UDP or TCP?
You're right. There's currently no universal way to encrypt direct queries to root DNS servers. To work around this, the best approach is to host your own public DNS server outside your untrusted ISPs network and connect to it securely using DoH, DoQ, or DoT. Alternatively, you can rely on a trusted third-party public DNS provider that supports encrypted connections.
In the end, there's no perfect solution. You have to choose who to trust. Personally, I trust my ISP more than external DNS providers.
For anonymity you could route your DNS root queries throe tor or a VPN for the cost of performance.
I also used third-party public resolvers before. Mainly FFM (its not on the list) but non-profit, EU and encrypted. If you boil down the list (from the website) to this categories, you have 4 providers. You can trust, in my opinion. But the problem with all this provider is, that you ran quick into rate limits or some query type restrictions. Especially if you run your own mail server or other DNS expensive task.
Fun fact about hosting your own DNS infrastructure and offering it to friends and family: They might actually trust other providers more than they trust you. Even if they know and trust you personally. Because they know you can theoretically read their queries, it’s more convenient for them to have a stranger do it instead.
Your friends and family probably don't know what DNS privacy is. If they do know, they'll already be hosting their own. They will care if it works better. When my ISP fucked up DNS once I had my family use mine instead.
On my notebooks, I run two Docker instances of AdGuards dnsproxy, using my own DNSCrypt resolvers as upstream servers. This setup provides anonymity from the resolver and protects against man-in-the-middle attacks, since DNSCrypt authenticates DNS responses.
However, root DNS queries from the upstream remain unencrypted. Additionally, not all nameservers support DNSSEC, so a fallback is often needed. Which can still leave the upstream vulnerable to man-in-the-middle attacks.
Of course, DNSCrypt is more secure (authentication, no bootstrapping), faster and anonym (against the resolver). But i think it is still not useable for "normal" people. And as a provider, the setup is more complex then DoH, DoT or DoQ, because of cert rotation and the DNS entries.
Versus letting a singular entity snoop everything? If you actually open a connection to the result what is the difference? The only way to fully deal with all that is an overlay or mixnets.
During the TLS handshake, you send the domain name in clear text (Server Name Indication - SNI extension) so that the hoster can present the correct certificate for that domain.
When all the authoritative servers support TLS I can enable TLS outbound but very few of them do at the moment. At some point someone is decrypting, turtles all the way down. I could of course just do DoT to another instance of Unbound somewhere else but I do not need to do that as my ISP does not care about my queries. I used to keep standby DoT Unbound servers around but I have never once seen a US ISP tinker with my traffic. If they did I would put up billboards saying they what they are doing.
Yours is not particularly problematic but I've always wondered how come advertising agencies allow highly controversial topics on their billboards in the US.
I know some (all?) EU advertisers deny creatives based on optics i.e. "our name and logo is on the billboard frame, we don't wanna get associated with topic X".
They like money. Controversial is not illegal. Slander is. If I purchase billboard space and spread defamation that will be problematic. The ISP could always take me to court but they would very likely lose provided I can prove I am telling the truth.
There are but I will wait until all the authoritative resolvers support TLS. If I wanted to hide my traffic from my ISP then I would just use DoT from my firewall Unbound instance to a few Unbound instances I already have around the web.
I understand your concerns. I personally do not share these concerns though I did when I resided in California that is for sure.
I know just about everyone at my ISP. I know where many of them live. We all live in the same small tight knit community. They tried really hard to get me to join their network team.
Afaik many harnesses ship the "default" which is grep+read (like Claude Code). But I agree, IMO it's a weird gap. To be fair I don't think providers are that incentivised to reduce token burn at the moment, but my guess is that that will change and tools like this will become at least an natively supported option in some harnesses.
I would be surprised if, in the "mature" future of AI tools/products, the labs building the models are also selling/building to end users like they are now.
Would or wouldn't be? I think it makes sense that they will be because of the feedback loop on training. The lab generates tons of example text as part of the training run and if they have that using their own tools then the models will tend to prefer those tools.
Never mind russians putting starlinks on flying bombs to blow up Ukrainians. But those poor Russian Internet users you invented. While it’s jailable offense in russia to own starlink.
I think you misunderstood, I do not pity them at all. I am just pointing out it is bad strategy to be dependent on foreign potentially-hostile technology.
And this is different from DNS how exactly? The key and resulting cert still needs to be distributed among your servers no matter which method is used.
With dns-01, multiple servers could, independently of each other, fetch a certificate for the same set of hostnames. Not sure if it’s a good idea though.
I guess it depends on the CA, but some do. Let’s Encrypt does, for example. I guess it’s useful for HA deployments, where load balancers might be spread out across multiple datacenters and stuff like that.
Not really, just forward .well-known/acme-challenge/* requests to a single server or otherwise make sure that the challenge responses are served from all instances.
