Remove DOH recommendations

[TommyTran732]

DOH doesn't do anything much for either security or privacy:

1. Your ISP can still see what you are visiting based on the IP. Granted, it makes it less identifiable if the site is behind a CDN like cloudflare and what not, but that is not always the case.

2. You now need to trust both the ISP and the DNS service to not log you.

3. Some users may not understand the implications of using DOH and combine DOH with a VPN or Tor, leading to DNS leaks.

4. DOH is supposed to block someone from modifying DNS queries, but https already solves that problem. The browser should check the TLS certificate of a website and see if its valid. If https is not used then the malicious actor can modify whatever other traffic you have instead, and can still snoop your password anyways.

All in all, DOH is not really effective, it introduces a new party for the user to trust, and the users can make mistakes as pointed out in point 3. Everyone should be using Tor or a VPN if they want privacy. If the VPN provider has DOH with their own servers, that is nice, but if they don't, it is okay as well.

Overall, as I said in other threads, I want to see PG making fewer recommendations over all, but quality ones. DOH is one of the not-so-high-quality recommendations that I'd like to see removed.

[Dyrimon]

I second this. DoH is not giving you any privacy advantages if the ISP can see the websites you visit by IP anyway. It can bypass site blocking iff the ISP is using DNS-level blocking, which hardly any ISPs do.

[jnton]

which hardly any ISPs do

At least in Italy, DNS-hijacking is usually the main method used to block websites (e.g: https://ooni.org/post/2021-italy-blocks-gutenberg-book-publishing-website/)

[TommyTran732]

which hardly any ISPs do

At least in Italy, DNS-hijacking is usually the main method used to block websites (e.g: thttps://ooni.org/post/2021-italy-blocks-gutenberg-book-publishing-website/)

It does not solve anything. You may bypass DNS blocking from the ISP, but they still know which site you visit. If the website is deemed illegal in your country, you would still get into trouble.

Even for bypassing censorship, a VPN would still be a much better approach.

[jnton]

It does not solve anything. You may bypass DNS blocking from the ISP, but they still know which site you visit.

Yes, I know. I was referring exclusively to bypassing censorship.

If the website is deemed illegal in your country, you would still get into trouble.

It depends on laws and countries, an Italian user can go to Gutenberg website risking nothing*...legal problem might occur if the the user downloads any of the 5 books that are protected by copyright in Italy, but even in this case it is very unlikely that the authorities will do anything.

*(because visiting that website is not illegal, but downloading copyright protected content is)

[TommyTran732]

It does not solve anything. You may bypass DNS blocking from the ISP, but they still know which site you visit.

Yes, I know. I was referring exclusively to bypassing censorship.

If the website is deemed illegal in your country, you would still get into trouble.

It depends on laws and countries, an Italian user can go to Gutenberg website risking nothing*...legal problem might occur if the the user downloads any of the 5 books that are protected by copyright in Italy, but even in this case it is very unlikely that the authorities will do anything.

*(because visiting that website is not illegal, but downloading copyright protected content is)

Why would one use encrypted DNS over a VPN though? Plus, even with this, you are assuming that the only form of blockage employed by the ISP is DNS based

[dngray]

which hardly any ISPs do

At least in Italy, DNS-hijacking is usually the main method used to block websites (e.g: thttps://ooni.org/post/2021-italy-blocks-gutenberg-book-publishing-website/)

It does not solve anything. You may bypass DNS blocking from the ISP, but they still know which site you visit. If the website is deemed illegal in your country, you would still get into trouble.

Even for bypassing censorship, a VPN would still be a much better approach.

This is particularly true for websites which don't do Encrypted Client Hello, which superseeds eSNI: Good-bye ESNI, hello ECH!. ECH isn't yet a finalized RFC.

[Mikaela]

I think you are assuming that there is always a VPN, while in my opinion encrypted DNS alongside HTTPS can be used to replace VPN entirely especially when the user's legislation has strong privacy laws, plase refer to Should I use an VPN.

I view there to be two cases where an encrypted DNS is particularly useful:

• When you have no control over your DHCP provided DNS servers. This appears to often be the case with 4G routers in Finland.
• When you are using a device that roams between networks you don't have control over. In my experience, neither Android, iOS or SailfishOS allow you to configure which DNS server to use for mobile data or all access points, unless encrypted DNS is used, those require static IP configuration per SSID, and that still leaves the mobile data unconfigured.

In my opinion, encrypted DNS and other encrypted connections (HTTPS everywhere, blocking plaintext connections) can be used to replace a VPN for a significant portition of users, please refer to Should I use a VPN?

DOH doesn't do anything much for either security or privacy:

Encrypted DNS alone doesn't do much, but it may give the option to use a malicious domain filtering DNS server (Quad9, Cloudflare security) or even adblocking (Adguard) which may be lighter for a weaker end device than local blocking/filtering that would need additional effort from the user to keep up-to-date. They can of course be used without encrypted DNS, but in that case, the user is vulnerable to ISP redirecting all queries to their own server.

1. Your ISP can still see what you are visiting based on the IP. Granted, it makes it less identifiable if the site is behind a CDN like cloudflare and what not, but that is not always the case.

There are scenarios in which a DNS query will not result to an actual connection to an IP address that could then be monitored. E.g. DNSBLs and DNS TXT record lookups while they are admittably rare.

2. You now need to trust both the ISP and the DNS service to not log you.

This also applies to a VPN provider and every ISP of a network where the end device connects to (metro, library, work, café, WiFi?)

3. Some users may not understand the implications of using DOH and combine DOH with a VPN or Tor, leading to DNS leaks.

Do you have suggestions how can we help the users understand this? We do mention this in the VPN info and in my opinion Mullvad makes especially good job in informing users about encrypted DNS providing their own and allowing it to be used regardless of whether VPN is currently connected.

4. DOH is supposed to block someone from modifying DNS queries, but https already solves that problem. The browser should check the TLS certificate of a website and see if its valid. If https is not used then the malicious actor can modify whatever other traffic you have instead, and can still snoop your password anyways.

Then again if the certificate is not valid, will the user think that there is nothing wrong or accept the error (perhaps due to alarm fatigue)

All in all, DOH is not really effective, it introduces a new party for the user to trust, and the users can make mistakes as pointed out in point 3. Everyone should be using Tor or a VPN if they want privacy. If the VPN provider has DOH with their own servers, that is nice, but if they don't, it is okay as well.

I think I made my disagreements and reasons clear including that encrypted DNS may also protect from user meistakes (in 4). There are some scenarios where Tor is not usable such as internet banking where Tor is likely to make the bank close the accounts suspecting a hack. VPNs also cost money (in addition to internet access) being additional commitment not everyone is able to pay and they may be further discouraged when experiencing slower speeds.

[TommyTran732]

• When you have no control over your DHCP provided DNS servers. This appears to often be the case with 4G routers in Finland.
  This shouldn't matter if you use a VPN.

In my opinion, encrypted DNS and other encrypted connections (HTTPS everywhere, blocking plaintext connections) can be used to replace a VPN for a significant portition of users, please refer to Should I use a VPN?

It doesn't.

A VPN does 2 things:

1. Shifts all of the risks associated with your ISP to itself. Instead of trusting the ISP, you are trusting the VPN provider to not log you.

2. Masks your IP from being viewed by random websites on the internet. From their point of view, while they cannot simply find out your personal identity just by a quick look at your IP, they still know where your general location is, which accounts are likely yours or related to you, etc.

A lot of sites run Google Analytics or some form of analytics engine, and those engines can figure out which website you visit just based on your IP. For example, you visit website A which runs Google analytics. You then visit website B which also runs Google analytics, and then website C which does the same thing. Since you are the only user using the IP, Google can easily tell that ur visiting all 3 websites if they want to.

So long as you are not doing something illegal (which will end up in a court order against you) and the website + vpn provider are not colluding to spy on you, it will be much harder for them to track you.

Compare this do encrypted DNS + https:

1. You are now trusting both the encrypted DNS provider and your ISP instead of just the ISP or VPN provider to not log you. You increase the number of trusted party with access to the websites you visit. https only hides what you are doing on the websites, not what sites you visit.

2. It does nothing to protect you against IP based tracking at all. Literally nothing.

Encrypted DNS alone doesn't do much, but it may give the option to use a malicious domain filtering DNS server (Quad9, Cloudflare security) or even adblocking (Adguard) which may be lighter for a weaker end device than local blocking/filtering that would need additional effort from the user to keep up-to-date. They can of course be used without encrypted DNS, but in that case, the user is vulnerable to ISP redirecting all queries to their own server.

Your VPN should be implementing this on their DNS server. ProtonVPN and IVPN does this. You shouldn't rely on a third party DNS provider to do this. Besides, this is enumerating badness, and would never entirely solve the problem of you downloading malware anyways. It's not an effective approach.

There are scenarios in which a DNS query will not result to an actual connection to an IP address that could then be monitored. E.g. DNSBLs and DNS TXT record lookups while they are admittably rare.

Yeah, they are so rare that they are irrelevant.

This also applies to a VPN provider and every ISP of a network where the end device connects to (metro, library, work, café, WiFi?)

No it doesn't. As I explained above, instead of just trusting the ISP or VPN provider, you are now trusting both the ISP and DNS provider.

Do you have suggestions how can we help the users understand this? We do mention this in the VPN info and in my opinion Mullvad makes especially good job in informing users about encrypted DNS providing their own and allowing it to be used regardless of whether VPN is currently connected.

Just don't recommend it at all. The privacy benefits are so small that it's practically theater. There will always be someone with the mindset of "hey let me just combine a million different privacy tools and that surely will make me very private" out there, so its best to just not recommend a set of tools that contradict each other like what's on PG right now.

I want to see a small number but quality recommendations on the site, not a bunch of recommendations that may include mediocre ones.

Then again if the certificate is not valid, will the user think that there is nothing wrong or accept the error (perhaps due to alarm fatigue)

If they do that then they are screwed anyways, regardless of whether you are doing encrypted DNS or not. What if the encrypted DNS server is the malicious actor here?

Your ISPs, VPN providers, and DNS providers are all potentially malicious actors. So are the Tor exit nodes. You should be trusting https to tell you whether a website is real or not, not whatever is providing you with the DNS record of a site.

[PhysicsIsAwesome]

I think you are assuming that there is always a VPN, while in my opinion encrypted DNS alongside HTTPS can be used to replace VPN entirely especially when the user's legislation has strong privacy laws, plase refer to Should I use an VPN.

A VPN or Tor should for most users be an essential part of tracking protection, especially if you have a static IP. The VPN section on PirvacyGuides is wrong on this. Please don't do circular reasoning by quoting PrivacyGuides as prove. And DoH can for sure not replace a VPN, even with strong privacy laws. A VPN allows you to do the following:

• Share your web facing IP with a lot of other users
• Easily cycle through IPs
• Most of the VPN providers have better privacy policies than most ISPs
• Usually have their own DNS servers, so one party less to trust and a lot of them with blocklists for malicious sites

All of this provides a significant benefit for privacy and lowers the possibilities for tracking.

Then again if the certificate is not valid, will the user think that there is nothing wrong or accept the error (perhaps due to alarm fatigue)

Well you can't hinder people from doing stupid things. All browsers show pretty clear warning, that you should not visit this website.

VPNs also cost money (in addition to internet access) being additional commitment not everyone is able to pay and they may be further discouraged when experiencing slower speeds.

There are also free VPNs. And yes, privacy can and usually will cost money, because you are not paying with your data. But compared to other measures, like buying a recent Google Pixel and install a custom OS, or being able to pay a privacy preserving cloud service, the money for a VPN is way less.

[ItsIgnacioPortal]

Besides, this is enumerating badness, and would never entirely solve the problem of you downloading malware anyways. It's not an effective approach.

Just like all things security, DNS filtering is not meant as a silver bullet to prevent malware interactions, but it does block off the vast majority of nefarious connections. Security is made of layers, and DNS filtering is a perfectly valid approach to blocking malware downloads.

DoH does not hide the IP addresses that the user visits, but it does hide the domain. DoH's approach is particularly useful for cloud-hosted websites, because unless you can see the Host header, it is not possible to know which page (under the same IP as many others) a user is visiting.

Having the visited IP addresses, an ISP would have to re-do the DNS queries to know which website was actually visited (which will be impossible if the page is cloud-hosted). Doing the of DNS queries for every single user of the ISP twice is quite a network-demanding task. I doubt an ISP would go through that effort unless they were specifically asked to do so by a government. And even then, they can practically only target individuals.

As always, there is no one silver bullet to protect our privacy, but we can make it increasingly harder to track us by using technology such as DoH.

In a way, DoH shifts trust from the LAN to the DoH provider. A user which is in an untrusted network may suspect that their DNS queries are being logged, so they may opt for using DoH to prevent this. Previously, the user had to trust the DNS provider, the ISP, and their local network not to log their DNS queries, but now, they only have to trust their DoH provider not to log their queries, and trust their ISP not to DNS lookup the logged IPs.
Anyhow, the result is that the LAN doesn't have to be trusted anymore.

I also agree that using DoH is the easiest way of setting a lookup server for mobile data. No downloads required; just change a setting and forget about it.

DoH may not be perfect, but its benefits are undeniable. I believe it should NOT be removed from the recommendations.

[ItsIgnacioPortal]

@dngray thoughts?

[dngray]

As far as privacy goes, observers can still observe what IP addresses your resolving, and potentially the domains through the TLS connection.

Some have mentioned here "it is free" and for people who "don't have money". If their threat model is a government, then it is absolutely the wrong tool for the job. Any ISP that blocking things with DNS is also likely keeping a metadata list of who is visiting blocked sites, and this exposes those users to repercussions. Therefore for that usecase VPN/Tor is the only solution. At least then they won't know what you're actually visiting. If those things are also illegal, then you may need to use more obfuscated methods, such as pluggable transports, v2ray etc.

Basically the TLDR is you should only use it if you're not worried about people knowing you've circumvented their blocks.

[Mikaela]

Quoting myself from Matrix:

I don't like the idea of centralising to Cloudflare with DNS any more than centralising to VPN providers, I don't think VPN is suitable for everyone and I still view encrypted DNS as a piece of the security puzzle. I think everyone is also thinking of different scenarios, while I think encrypted DNS fits everywhere as a piece

e.g. in cafés or public WiFi with captive portal, VPN will not work and requires the user to somehow bypass it's killswitch to get through the portal while encrypted DNS and captive portal handling are parts of the OS and thus the user is guided through the issue

Additionally when everything is encrypted, it's only the domains that get leaked, not the specific content there. What does it matter if a public network knows that the user is visiting facebook and maybe reading the news if they don't care about hiding that they are visiting the leaked domains as what happens there is hidden?

there are people in the world that don't have money for food, how are they supposed to have money for VPNs

https://matrix.to/#/!tYlyxcuAlXJvMzFqPE:aragon.sh/$5Ekf8owDBIWAiOHzi4zstLkCvjORS_CFElWvHBoorLQ?via=privacytools.io&via=matrix.org&via=envs.net

https://datatracker.ietf.org/doc/html/rfc8310#section-5 - DoT [opportunistic mode] gets attempted and if it works, it works. if it doesn't work, it will be downgraded to usual DoT. It's designed to avoid the centralisation to Cloudflare that Firefox does

https://matrix.to/#/!tYlyxcuAlXJvMzFqPE:aragon.sh/$b0oIe_9pUsYtbHycvcQleg4RKy43-3BcVHEMb6wC2bg?via=privacytools.io&via=matrix.org&via=envs.net

[dngray]

I don't like the idea of centralising to Cloudflare with DNS any more than centralising to VPN providers, I don't think VPN is suitable for everyone and I still view encrypted DNS as a piece of the security puzzle. I think everyone is also thinking of different scenarios, while I think encrypted DNS fits everywhere as a piece

Just because you might choose not to use CF or some other DNS provider you don't like doesn't mean the server you use doesn't forward there. DNS queries are recursive.

[dngray]

I do think a good focus for the encrypted DNS page might be to show how to enable it in various operating systems.

For example we've got or are getting systemwide support in Windows, MacOS 11 (Big Sur) iOS 14 and Android devices, (which only currently support DoT, although that appears to be changing in Android 13).

The focus should be on DoH (not DoT) as that is the direction industry is moving in. Likely at some point it will be further upgraded to DoQ (DNS over QUIC, aka HTTP/3).

[TommyTran732]

There are free VPNs, many people use them, and they are more effective at hiding your web browsing habits from a malicious ISP.

Free VPNs can not be trusted. How would they maintain themselves if they don't sell user data and/or inject ads into a users connection?

adding an additional party to trust.

It doesn't just add an additional party, it shifts from one party to another (DNS -> DoH), and thwarts the ISP from trivially logging queries.

Since you seem strongly opinionated, I won't try to convince you. I'm only trying to convince the reader.

1. No VPN or ISP are to be trusted. Assume they log your traffic, as always. Deal with that however you want, depending on your threat model.
2. It is impossible to inject ads into a https connection.
3. The ISP can trivially find out which website you visit and log it without much trouble, even if you use DoH. There are multiple ways to achieve this, including looking at your OSCP requests or your SNI. Besides, even if you somehow completely hides the DNS queries (which you won't with the current state of the internet), they can just figure it out by looking at which IP you visit anyways.

Using DoH for privacy is theater.

[TommyTran732]

Give me one threat model where encrypted DNS with a third party server is helpful.

You didn't ask me, but here is an hypothetical thread model where encrypted DNS with a third party server is helpful (that I have been offering a lot):

* ISP hijacks plaintext DNS queries.

* Device is used by non-technical user.
  
  * _I have discussed family tech support case before._

* Non-technical user ends up to phishing site.
  
  * _I don't mean that a technical user is immune to phishing._

* Phishing site is blocked by third party encrypted DNS server such as Adguard, BlahDNS, Cloudflare, NextDNS, or Quad9. (List is taken from PrivacyGuides DNS page and contains those that either say to have malicious domain filtering or which I know to have it,)

Can the same be done with a VPN? Maybe, I don't know what does ProtonVPN offer, I know that Mullvad doesn't reveal what exactly they are blocking (do they block only ads or where do they get malicious domains?)

This is less of a threat model but more like a specific scenario. That being said, this is easy to solve.

Say the ISP does DNS hijacking - so what? The user's browser would warn them that the https certificate is invalid and that the site might be dangerous.

If the user is not using https, then the malicious ISP can do whatever to mess them up, including injecting whatever they want in the packet stream between the browser and the site.

The solution for such problem is https, not DoH or a VPN. Neither of those technologies will solve this.

You are assuming a lot with your "solution":

1. You are assuming that the ISP is so malicious that they will hjack the DNS queries but will not take any further steps to attack the user.
2. You are assuming that the DNS provider is any more trust worthy than an ISP. Neither of them are to be trusted.
3. You are assuming that your block list has every phising site that the user will visit (surprise, surprise, it won't),

[Mikaela]

Say the ISP does DNS hijacking - so what? The user's browser would warn them that the https certificate is invalid and that the site might be dangerous.

By DNS hijacking I mean that the ISP is redirecting all plaintext DNS queries to their own server and assuming they didn't lie there is no reason to see certificate errors.

You are assuming that your block list has every phising site that the user will visit (surprise, surprise, it won't),

I consider any blocked query as a success while it naturally it cannot be a complete blocklist.

PS. I have left the team and if there is no further misunderstanding of my words I will not reply to the thread further, this discussion has been going on long enough in various places.

[TommyTran732]

Up to you whether you want to reply or not. "By DNS hijacking I mean that the ISP is redirecting all plaintext DNS queries to their own server and assuming they didn't lie there is no reason to see certificate errors." makes 0 sense whatsoever.

The system makes a DNS query. The query gets to the ISP's DNS server. The DNS server replies to the system. The system gets the IP address for a domain that it queried and makes a connection to it.

1. If the ISP's DNS server replies honestly, then the user connects to the legit website. Of course there will be no warnings, and there is no phishing going on.

2. If the ISP's DNS server replies dishonestly, then the user connects to a fake website. The browser will realize that the SSL certificate is invalid and will warn the user about the potential threat. This solves DNS hijacking.

I don't even know what you are going on about. How is DNS hijacking for phishing going to work when you are using https? It isn't.

[dngray]

DoH's purpose is not to validate your results. That's the purpose of DNSSEC. Additionally DoH isn't meant to determining whether or not something is hijacked. That's the purpose of the PKI (certificate validation, certificate transparency etc).

To be honest, I think there's a lot of comments in this discussion by people that really don't know how things work.

As far as censorship goes, it is definitely not the right tool for the job.

[Webinx]

DoH is a FREE option that could help in some cases, it should be better explained as you said in the point 3, but not removed.

[dngray]

DoH's purpose is not to validate your results. That's the purpose of DNSSEC.

DoH's purpose is encryption which DNSSEC hilariously lacks.

Authenticated DoH / Authenticated DoT that's in the IETF drafts will likely be way better than the much maligned DNSSEC

DNSSEC is not designed to provide confidentiality. DNSSEC is really meant for resolvers to be doing validation not clients. DNSSEC makes sure your recursive DNS resolver isn't fouled by any malicious upstream DNS servers. As for your DNS resolver fouling you, you have the PKI infrastructure for that. TLS connections to servers that do not have a valid certificate will be detected and rejected (how your browser detects an invalid certificate when you are using https is an example). There is nothing verifying that the DoH or DoT servers your computer talks to are the servers that you think it is talking to.

If your threat model becomes so extreme that the CAs themselves are a threat, your only 2 choices are to do certificate pinning and .onion addresses.

At no point does DoH or DoT encryption fit into the threat model. They do not provide anything for security. As for privacy, your ISP has multiple ways of figuring out what you are visiting, including IP logging or checking your OSCP / TLS requests. It is a very dangerous game to play, especially if the threat is a government.

I think there's a lot of comments in this discussion by people that really don't know how things work.

Hostile and uncalled for.

It's fact, please don't pearl clutch thanks.

[ignoramous]

DNSSEC is not designed to provide confidentiality.

So, what good is authentication if DNSSEC cannot provide confidentiality? DNSSEC is a failed standard for a reason.

It's fact, please don't pearl clutch thanks.

It is hostile, because it is disrespectful. It is uncalled for, because the fact that "people that don't really know how things work" is equally true for you, too dngray.

Community-driven consensus is a hairy-beast, so you folks will be subject to all sorts of hariness. I can have no qualms with whatever decisions the folks running privacy-guides take or however they choose to run the project. All I can do is offer my unsolicited feedback. If its pearl clutching to someone, then at least that's less harmful than being overtly hostile.

[TommyTran732]

1. DNSSEC is designed for authentication, not confidentiality. That is not its job. And DNSSEC is a very successful at what it does.

2. DOH and DOT does nothing for privacy. It is complete and utter privacy theater. For one, OSCP and SNI will still leak what you are doing. Two, even if you have OSCP Stapling (which is not widely used) and eSNI/ECH (also not widely used), your ISP can still deduce what you are visiting based on the IP. It is not a viable approach and should never be recommended as a way to stay private. You are not getting that confidentiality either ways.

3. Nothing @dngray has said is not factual. If there is, please point out with facts and logic instead of making comments like "DNSSEC is a failed standard".

4. You should take a mirror and look at yourself.

If there is anyone causing a hostile and disrespectful environment, it is you.

You have been lurking around this forum, posting some of the most insane, idiotic, plain out stupid statements while trying to sound smart and dangerous ("DoH's purpose is encryption which DNSSEC hilariously lacks", "DNSSEC is a failed standard", or "TLS is hillariously easy to pwn"). You spread misinformation like there is no tomorrow. You used examples of a completely compromised computer getting its TLS connection intercepted to compare to DOH and DOT not being able to fully hide which website a user visit even if the computer is 100% safe and sound. You made it sound like an ISP can trivially install a fake root certificate on a computer when it is complete non-sense. There is a difference between people who simply ask questions or stating their opinions and people who state bullshit as if they are facts.

At this point, it has become clear that you are nothing more than a concern troll. Beyond just posting complete garbage, you have also started going around and policing people for their words, crying wolf about how PG is not "neutral" on its wording regarding CalyxOS when it objectively lacks the hardening Graphene has, and how @dngray is supposedly hostile when all he stated was just facts.

You are the hostile entity. You are the one going around causing trouble. You are the one flooding PG with non-sensible conversations instead of tech and facts. I am not usually this angry in a conversation, but you are a special case. You need to go out and touch some grass.

[ignoramous]

Let's see how consistent your arguments are:

DNSSEC is designed for authentication, not confidentiality. That is not its job. And DNSSEC is a very successful at what it does.

Okay. Not DNSSEC's job.

DOH and DOT does nothing for privacy. It is complete and utter privacy theater. For one, OSCP and SNI will still leak what you are doing

So: it is DoH / DoT's job to protect infringement from SNI sniffing which is in fact part of the TLS standard.

"DNSSEC is a failed standard"

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

You made it sound like an ISP can trivially install a fake root certificate on a computer when it is complete non-sense

https://security.stackexchange.com/questions/80662/i-cant-access-websites-that-use-https-instead-getting-the-message-your-connec

https://www.reddit.com/r/sysadmin/comments/2l075f/my_isp_is_issuing_my_ssl_certificates_now/

https://www.zdnet.com/article/kazakhstan-government-is-now-intercepting-all-https-traffic/

Nothing @dngray has said is not factual...

I don't deny that, while I also don't deny that "people don't know how things work" are commenting here.

For ex: dngray goes, "At no point does DoH or DoT encryption fit into the threat model. They do not provide anything for security."

Nothing at all? That's a stretch.

RFC8484:

DNSSEC and DoH are independent and fully compatible protocols, each solving different problems.  The use of one does not diminish the need nor the usefulness of the other. 

But of course:

It is the choice of a client to either perform full DNSSEC validation of answers or to trust the DoH server to do DNSSEC validation and inspect the AD (Authentic Data) bit in the returned message to determine whether an answer was authentic or not.

Like I said, folks running privacy-guides are free to choose what they recommend. I participate because privacy-guides is community-driven, which comes with its own downsides (like dealing with strong, contrasting, oft times unsolicited, sometimes incorrect opinion and feedback) and upsides (like having active, meaningful, educational participation from non-members).

[dngray]

https://sockpuppet.org/blog/2015/01/15/against-dnssec/ 2015 article on a random website. By 2021 virtually every major DNS providers use DNSSEC.

https://security.stackexchange.com/questions/80662/i-cant-access-websites-that-use-https-instead-getting-the-message-your-connec
Did you even read this post you linked? It is quite literally the perfect example of PKI successfully protecting the user. You should read the stuff you link to.

https://www.reddit.com/r/sysadmin/comments/2l075f/my_isp_is_issuing_my_ssl_certificates_now/
Quite literally a perfect example of how a malicious ISP cannot just install a root certificate onto the user's computer controlling only the network. You need more access than just the network to do this. You need to fully control the device of the user. DoH/DoT do not help in that threat model.

https://www.zdnet.com/article/kazakhstan-government-is-now-intercepting-all-https-traffic/
You are quite literally giving examples of people being forced to install a root certificate on their computer, at which point, the entire computer is compromised. This is not someone trivially doing it from the network.

Besides, if there is a fake root CA on your computer, no DoH or DoT will save you.

For ex: dngray goes, "At no point does DoH or DoT encryption fit into the threat model. They do not provide anything for security."

The threat model being talked about was censorship/hijacking by an ISP.

RFC848:
DNSSEC and DoH are independent and fully compatible protocols, each solving different problems. The use of one does not diminish the need nor the usefulness of the other.

This literally says they don't conflict with each other. The only threat model in which DoH makes sense is when someone is obnoxiously redirecting your queries without care. It's also worth noting PKI protects the query from being modified in transit to you. That is the purpose of DoH.

It is not to fight censorship and should never be used for that. If your threat model involves censorship then chances are there's an authority which will be bothered by you circumventing it. Using DoH/DoT for this purpose will allow them to know about it trivially.

It is not confidentiality from resourced network operators for the same reason above. (They can still see the IP addresses you access, and the domains in the TLS handshakes as most services do not use eSNI/ECH).

It is the choice of a client to either perform full DNSSEC validation of answers or to trust the DoH server to do DNSSEC validation and inspect the AD (Authentic Data) bit in the returned message to determine whether an answer was authentic or not.

The purpose of DNSSEC is to validate the query from the upstream DNS server. It has nothing to do with the client.

Like I said, folks running privacy-guides are free to choose what they recommend. I participate because privacy-guides is community-driven, which comes with its own downsides (like dealing with strong, contrasting, oft times unsolicited, sometimes incorrect opinion and feedback) and upsides (like having active, meaningful, educational participation from non-members).

Privacy Guides is about providing best practices to realistic threat models using the right tools for the job. We aren't a community to present misinformation as fact.

[dngray]

So after reviewing the comments in this thread. The new page will have:

• Encrypted DNS doesn't make you anonymous, there is no expectation of privacy
• It shouldn't be used to bypass censorship (violations may still be recorded) and observers will still know what IP addresses your accessing.
• If you are using a VPN you should use your VPN provider's DNS server to minimize parties of trust
• If you are not using a VPN and there is no censorship you should use your ISP's DNS servers.
  • If you have an obnoxious ISP that redirects things eg start pages, then you might consider it knowing that you're now trusting someone else

Any server recommendations:

• Must support DNSSEC validation
• Must support DoH
• Must support anycast

Our content:

• Supply instructions for how to enable DoH with Windows/MacOS/iOS/Firefox with mention that Android only supports DoT but it will support DoH in Android 13.
• We're not going to mention random things like DNS resolvers ie unbound, dnscrypt-proxy etc as cards.

Potential usecases:

• Filtering advertising (adguard etc).
• Filtering obnoxious redirects like the one mentioned in the point above

[TommyTran732]

Totally agree with this.