Eh. He doesn't discuss which public dns upstream supports dtls and in some sense it's just picking who snoops, ie he argues against cloudflare snooping but doesn't discuss who else might.
Run hyperlocal root, run your own dns.
His "don't move off 22 for ssh" is also just opinion. He argues "you will be found" but misses the experience of those of us running on shifted ssh is continuously validated by the visibly lower level of probes we see. He offers no mathematical analysis of how quickly a port knock sequence will be uncovered, and again dismisses it as infeasible and useless.
I've got nothing against strongly held opinions and these are his. But, form your own opinions too.
Yeah I get almost no login attempts on ports other than 22. Should I even care about attempts on 22 though? They bounce off, and fail2ban blocks the IP after a while.
I sometimes think of putting my private servers on completely random IP addresses drawn from /64 IPv6 ranges. It should be near-impossible to find those by address scanning, unless I'm overlooking something dumb. Am I? It wouldn't surprise me.
An arbitrary IPv6 address is indeed not practical to find by scanning. However, unless you're willing to type in that 128-bit value each time you need it (which maybe you are) you'll advertise this address somehow and if you do that your advertisements can be read by others.
For example suppose you put my-private-server.vanity-domain.example in DNS with an AAAA pointing to your private server - "passive DNS" service means big DNS providers will sell the answers they saw when anybody (say, yourself, on somebody else's computer) asks AAAA? my-private-server.vanity-domain.example. They don't reveal who asked, so this isn't personal information, but they do reveal what the question was and its answer.
A long time ago we used this to build target portfolios, if we're going to sell your company our product X, this is way we can see that you already have products A, B and C, but not D, E or F so we look a bit smarter coming into the sale.
Yes, that's the idea of a private server. All the clients allowed to connect to it are mine, or at least authorized by me on a very small scale. Think of a backup server or a jump host.
Come to think of it, I could have a private DNS too. I haven't bothered with that.
I'm going to mention again dns0.eu which does support DNS over TLS. I haven't looked in-depth but I'm pretty sure some corporate networks block it somehow because on some networks my Android phone fails to connect to it.
> His "don't move off 22 for ssh" is also just opinion. He argues "you will be found"
Worse than that, that post misunderstands it's own statement:
"Sure, you will see fewer attacks than before, but most of the attackers are no longer just stupid bots"
That's a *good* thing, because the move has reduced the signal to noise ratio. By getting rid of most of the crufty noise of the internet, you now know that anything hitting your logs now is more likely to be an actual threat than the poorly automated dictionary attack bots.
Moving SSH to a different port doesn't make the system much more secure (and definitely shouldn't be the only thing you do), but it does generally enable you to be more responsive.
is it possible to route DoH over generic HTTPS service when i only inspect a certain route? so i could have a generic https-server, where at some route, DNS requests are answered, other stuff just gives me a normal website?
because then we could use DoH for hiding our DNS requests..
This is how it works already, the DoH endpoint is "/dns-query", both CloudFlare and Google route this endpoint to their resolver services, while the rest of the site (one.one.one.one or dns.google) is just a website.
DoH requests go to /dns-query so you only need that path to proxy onto your DoH handler.
Some DoH clients will also allow you to specify a custom path, so you can also obfuscate the path by configuring client and server to use /foobar instead.
But, re-using an existing site does come at the cost of generating a bunch of extra log noise (fine if it's just you, not so fine if it isn't). If you don't have some kind of auth in place, you might also find that you suddenly come under a lot of load (when I ran a public DoH service, I eventually started getting a lot of traffic from users in an authoritarian country)
If you live in a city or other urban area, typically you have the option of the decoupled telco (BT Openreach) that more or less everybody has, the entity which bought all the cable television companies (Virgin Media) and usually a fibre-for-purpose Internet company that decided to do your city or region.
If you live in a rural area where people are co-operative, there might be a community owned fibre operator plus Opeanreach, otherwise just Openreach.
If you live somewhere very silly, like up a mountain or on your own island, your only practical option will be paying Openreach to do the work.
Edited to add, Notably: Only Openreach is usable by an arbitrary service provider. So if you want to pick your service provider separately, the actual last mile delivery will always be Openreach. And if they're small it won't just be last mile, Openreach also sell backhaul to get your data from some distant city to the place where the ISP's hardware is, you're buying only the, like, actual service. Which is important - mine means no censorship, excellent live support and competent people running everything, but the copper under the ground is not something they're responsible for (though they are better than most at kicking Openreach when it needs kicking)
CityFibre is only available through wholesale ISP's. Other smaller alt-nets (such as the one I work for - Netomnia (including Brsk/YouFibre)) is gearing up to provide wholesale access.
In the UK there are even aggregators like Fibre Café [1] that makes it easier for ISP's to connect through multiple networks.
If you are lucky, yes. For example, I have a choice between CityFibre (XGS-PON), Openreach (GPON) and Virgin Media (DOCSIS) as well as 2 different 5G networks. It is rare for a property to only be covered by a single wired network these days in the UK.
You're next argument might be "but how do you know the server is really using ODNS?" You don't. If your security threat profile doesn't allow for this, whatever you're doing shouldn't be using a public internet network anyway.
> My ISP is bound by robust privacy, telecommunications interception and other legislation.
It really depends on which jurisdiction are you in, unfortunately. US ISPs are selling everything they can hover (including DNS information) to advertisers, and it is impossible to switch to another one unless you're lucky (because the monopoly is essentially maintained).
Cloudflare is not an ISP. They have other services they sell. Maybe they're selling your data, maybe not. I honestly have not read their agreements and terms, but it's not nearly as obvious that you're the product as something like Google
So this company based in the US which provides internet services is not an internet service provider.
Given that they are funded and run by the same forces american parastical capitalism provides I would trust them as much as I'd trust google or alphabet.
I'll continue to route my DNS to quad-nine over mullvad over my specifically chosen ISP, and everything on my network does that as I can easily intercept and redirect udp/53.
The weak point are treacherous devices which use DoH which is a constant fight to block.
They provide network services on the internet, but unless I'm missing some product they don't list on their website they do not provide actual basic IP internet connectivity for businesses, everything they sell is some service on top of your existing ISP services
And google don't provide actual basic IP internet connectivity for businesses. They are still an american company that provides internet services and uses and sells your data.
Why would cloudflare, built from the same corporate background, be any more trustworthy?
That's just one category of stuff that ISPs do. In the context of "who do I pay to get Internet at home", cloudflare is not an option, but in the context of the internet itself they are one. Hetzner, for example, is an ISP that mainly provides server hosting. There are companies that only provide Internet service at data centers too.
Using the definition of "do they provide IP transit to anyone", yes, they offer services which do this, Tunnels is one, there may be others, but this would mean they are technically and legally classified as a service provider (and hence also enjoy Section 230 protection) in that case.
Some may also consider reverse proxying/caching to be providing transit service, but I'm not sure if the majority of people would agree on that.
In addition, your ISP can also extract whichever metadata it wants from your communications, incl. a very likely perfect guess of the hostnames you visit at which times _even if you don't use DNS at all_, just by looking at IP traffic metadata such as addresses and packet sizes.
So you already have to trust your ISP anyway -- but there was no need to trust Cloudflare *. DoH to Cloudflare is almost certainly a net loss in privacy compared to using your ISP's DNS over clear text.
* Right until they became hosters of half of the WWW. So Cloudflare can pretty much also guess your activity even if you don't do DNS with them anyway.
That just shifts the trust from your ISP to your VPN provider. Moreover if you're already using a VPN, your DoH requests to cloudflare is already anonymized.
If you are using WireGuard between endpoints your traffic if opaque, but yeah if/where it exits it becomes (depending on the encapsulated protocol) visible.
> In addition, your ISP can also extract whichever metadata it wants from your communications, incl. a very likely perfect guess of the hostnames you visit at which times _even if you don't use DNS at all_, just by looking at IP traffic metadata such as addresses and packet sizes.
Does it, really? Have you seen wireshark output lately? (the GUI can be configured to do reverse lookup on all IP address)
If I check up right now, form the top 10 links in HN right now, it is trivial to distinguish the top-level domain from just the IPv4 or IPv6 address. Heck, even _for this website itself_ the current IPv4 reverse DNS points to ycombinator.com. I don't even need to go into packet size heuristics, or the myriad of ad networks, etc.
Sure there are some instances where you will share the IP of the CDN. This has been seen recently e.g. in the recent article of the "LaLiga" blocks in Spain. But bigger sites cannot afford for this to happen, and even smaller sites tend to have at least one paid IP address for mail (reputation is a bitch, and Cloudflare doesn't have any).
> If I check up right now, form the top 10 links in HN right now, it is trivial to distinguish the top-level domain from just the IPv4 or IPv6 address.
And you can't even tell the TLD, because the TLD is "io", but the reverse lookup on the IPs will give you a TLD ending in "com".
> Heck, even _for this website itself_ the current IPv4 reverse DNS points to ycombinator.com.
That's because HN isn't behind the kind of CDN I'm talking about. But a lot are. Is your argument "since your ISP can see some of the sites you're going to, we should remove all protections and let them see all sites you're going to?"
I said top-level domain. Anyway, you have a better estimate, for the types of sites people here would visit? If HN itself isn't an example, then Github subdomains definitely ain't (not even close to the traffic of the main domain).
Well, I appreciate the correction: I meant second level (or whatever is most distinguishing for that TLD). However, even if what you say is true, you really cannot disprove my claim with one nitpick, you need to talk majorities. (And, in case it needs to be said: i really don't think the issue here is distinguishing activity to github.io vs github.com)
This was literally the worst example you could possibly do. I hope you kept which one was which, I'd like to know if Copilot was right.
In the meanwhile, from the current top #30 articles on HN (also via copilot script, but I removed non-cloudflare IPs):
ycombinator.com -- no CDN
letsbend.de -- no CDN
grepular.com -- no CDN
xania.org -- cloudfront
github.io -- no common CDN
owlposting.com -- AWS, but IPv4 remained static
netfort.gr.jp -- no CDN
simonwillison.net -- cloudflare, 104.21.112.1 fixed
folklore.org -- azure, 13.107.246.1-255 range
danq.me -- no CDN
nature.com -- fastly, IPv4 remained static
daringfireball.net -- cloudflare, 104.26.4.133
ssp.sh -- no CDN
trebaol.com -- cloudflare, 104.21.3.245
glek.net -- cloudflare, 104.21.112.1
gov.uk -- AWS, but IPV4 remained static
phys.org -- no CDN
diwank.space -- cloudflare, 104.21.80.31
free.fr -- no CDN (my French ISP, btw)
ericgardner.info -- AWS, but IPv4 remained static
ghuntley.com -- fastly, IPv4 remained static
paavo.com -- no CDN
railway.com -- cloudflare, 104.18.24.53
alloc.dev -- cloudflare , 188.114.96.2
Look at how many of them are self-hosted, have zero CDN, or otherwise return me always the same IP (even when I try from 3 different ISPs) which makes them trivial to reverse address. This is already a pretty huge success rate and all my context is that you browsed HN first (which I know, see first result on the list). Now imagine the tools a ISP will have at its disposal:
- IPv6
- Its Geo region will actually match yours
- Routing tables
- The patience to also include resources fetched from these pages in the analysis (i.e. page X always gets its JS from Y domain which results in a constant Z KB transfer).
- The rest of your browsing activity
- The rest of everyone's browsing activity including most popular _current_ hosts for each hostname.
Do you still claim that it is "impossible" to track your activity because of CDNs? I still bet you your ISP can do it with _100%_ accuracy.
It took me the whole of one Copilot conversation to do the entire thing. Most of the top #30 results are in fact one reverse DNS away. The rest is not much more complicated.
They're never going to be "1 IP ECH" . That would be the end of the Internet as we know it.
If it ever happens that the majority of the WWW is 1 CDN, we have a bigger privacy problem than DNS. Much bigger.
The most important part of DoH, etc is that it allows you to make a choice. You can choose a vendor in your country. As a Canadian, I might want to use the service offered by my national TLD operator https://www.cira.ca/en/canadian-shield/configure/firefox/
Many ISPs explicitly sell DNS data, and are also advertising vendors.
With insecure DNS, the choice isn't meaningful since your ISP will see all of the data no matter which DNS server you pick to use. And those kinds of ISPs will probably block DoT because they want to keep seeing it all, but they can't block DoH.
I put my DNS service on a non-standard port. I’m the only one using it so standards be damned. Windows doesn’t allow setting a nonstandard port for DNS, but pretty-much everything else does.
Do ISPs do deep packet inspection to get lookup data? Maybe, but it increases the cost of doing so and makes the business aspect of it less viable. Perhaps a minor win.
With cleartext DNS, your queries may never reach your chosen server. Plenty of ISPs are configured to just answer any DNS query, regardless of its destination. Using a nonstandard port might help, but you’d be much better off deploying one of the DoH / DoT / DoQ / etc secure protocols.
No it's not. I'm saying don't let the perfect be the enemy of the good.
DoH does solve a problem for many people. Many large ISPs will sell your DNS requests, use them for targeted advertising, tamper with responses for various reasons, etc., and so DoH is an improvement over the status quo--not for everyone, but for many users, and I'd guess most users.
You're right, DoH might not be worth adopting if it were "stupid enough", but... it's not stupid enough.
Your ISP already has all this metadata and more from other sources, so it is pointless to switch to DoH in this case, and if you do you willingly give this metadata to Cloudflare, which (for the majority of users) may even be in a better position to do evil.
> Your ISP already has all this metadata and more from other sources
If you combine this with ECH and a good blocker, no they do not. That's exactly why Spain is blocking around 60% of the internet during football games now; the ISPs cannot tell which websites and subscribers are pirating football streams.
> Spain is blocking around 60% of the internet during football games now
[citation needed for the 60% figure]
Precisely due to these blocks is why I know that Cloudflare is NOT 60% of the WWW, not yet at least. Certainly, if Cloudflare was serving 60% of the Internet, I would consider switching my DNS to them. But that would be a privacy nightmare for another day (replacing federated ISPs with a single big centralized one? great idea /s). It is not yet the case as of today.
In fact, as of today, and even if you have a "good blocker", I, a total noob, have a high chance of reliably identifying which HN news item from the top #30 you clicked from just the addresses: https://news.ycombinator.com/item?id=44219061 . Imagine what the non-noobs at your ISP could do.
In the Politician's Fallacy, the chosen solution doesn't solve the problem. In this example, DoH solves many of the problems, perhaps not optimally, but better than the "do nothing" choice.
So it doesn't really solve the problem, and may generate more (privacy) problems of its own. "doing nothing" may be the better solution here, which was the entire point made in the original episode.
They don't really say if DoT is safer. I'm more confused than informed by this article. Would've been nicer if they provided some proofs or data to back up their claims.
Also, does anyone know what's the safest option? And how to configure it for all our home devices?
Anonymized DNSCrypt and Oblivious DoH are designed to keep your IP address hidden from resolvers, and there are DNS relays located all over the world. If you truly care about privacy, use anonymized DNS, not DoH.
His proposed alternative, DoT, still has one known peeper, and is easier to block. DoH, OTOH, looks like regular HTTPS traffic and is on port 443.
So the "abuse" of HTTP is not unnecessary, you get something in return.
In some situations, DoT is fine. In others, it won't work, but DoH will.
Even ignoring the question of the technical merits of DoT vs DoH, the way the author transitioned from "Cloudflare bad" to talking about DoT made no sense since DoT as an alternative does not solve the problems raised earlier in the post. Is the author opposed to DoH as a protocol or opposed to sending DNS requests to a company they don't like?
If we're getting into the technical part of the discussion though, I personally don't think DoH or DoT are great protocols for DNS. Security is fine, but it's a lot of overhead for relatively small requests where latency matters. I wish DNScrypt had gained more traction as an encrypted protocol designed specifically for DNS.
This is silly; CF is not the only DoH provider[0], using https and hopefully soon ubiquitous ECH also gives you censorship resistance (blends in with http traffic!) etc
maybe there is something to be said about the complexity but they left that to the last paragraph
I find it problematic that this article recommends disabling DoH, which leaves users with unencrypted DNS — still centralized (e.g. to Google’s 8.8.8.8 or an ISP) and now vulnerable to man-in-the-middle attacks. Replacing one form of centralization with another while giving up encryption doesn’t improve privacy — it worsens it.
If the goal is to reduce centralization, a better approach would be to use encrypted DNS (DoH or DoT) with resolver rotation or randomization. That way, users retain privacy from local networks and ISPs without concentrating all DNS traffic in a single provider’s hands.
Zero mainstream OSs ship encrypted DNS resolvers by default, unless you count ones that will automatically fall back to insecure DNS, which defeats the purpose since a network attacker can cause that.
If you're looking to implement encrypted DNS with multiple servers or providers, consider using unbound, which supports TLS resolvers and can operate in recursive mode. Alternatively, you might opt for AdGuard DNSProxy or dnscrypt-proxy, both of which support DNS over HTTPS (DoH), DNS over TLS (DoT), and DNSCrypt. You can run these tools on your local network or computer and configure your resolve.conf to point to them.
DoT is strictly worse than DoH. It doesn't actually fix any of the author's issues with DoH, and it has the gigantic downside that it's trivial for hostile networks to block.
This is a really good point that I haven't seen made much in this thread. Almost everyone is just talking about the privacy perspective, but DoH is also really important for preventing censorship, so it's critical that it's not trivially blockable at the network level.
I think one way or another you will have to trust some entity with your DNS. Unless you are willing to use tor all the way on OS level. Even running your own recursive DNS resolver will leak your IP to root servers. Put VPN in front of it and know you trust this VPN company (kudos Mullvad).
And abusing https is for a good reasons. Blocking ports 53 and 853 is easy and many ISPs will do that.
The author also make it feel like the only option is to use cloudflare DoH on Firefox while that's the first option, there is also nextdns and custom field. There are many providers I would trust more like quad9 and Mullvad DoH.
I think the reasons why not to use DoH is the same for why not using public dns from providers you don't trust anyway.
Most of the people are happily using 8.8.8.8 and handing all their dns information to the biggest advertisement company in the world. Or wosre, using their ISP provided DNS.
True, but at the end of the post the author also explicitly rejects the idea of the DoH protocol in general on questionable technical grounds, so clearly their objection isn't just Cloudflare. I think the argument would be a lot clearer if they didn't conflate "using Cloudflare for your DNS" with "using the DoH protocol for DNS" even if they think both of them are bad.
its funny you call out Mullvad in this specific case because its the one thing i really dislike about their VPN service. It wont route DNS to the root server, or any designated server really. They redirect DNS queries to their cache indiscriminately. which actually will harm the success of setting up a recursive resolver. I get this is done to prevent leaks, i would just like the option to opt out of it. been customer for many years now though. I use unbound semi recursively resolving using a forwarder with DNS over TLS. So Mullvad is not burdened with what i resolve and the forwarder not with information on who.
I tried configuring Mullvad DNS on Firefox (last year) with DoH/DoT and it would randomly flake out and not resolve some domains (different ones each time) and the only way to fix it was restarting the browser. Cloudflare at least Just Works (tm)
Isn’t that essentially what DNS is? It may cache results but it has to get the results at some point and they communicate with other DNS servers that have the information?
A recursive resolver starts at the root of the tree and walks downwards. Most OSes only have stub resolvers, which simply forward your request to a given recursive resolver, and don't traverse any tree.
> I think one way or another you will have to trust some entity with your DNS. Unless you are willing to use tor all the way on OS level. Even running your own recursive DNS resolver will leak your IP to root servers
With modern recursive DNS, you don't leak much to the root servers, just the tld you're trying to resolve. And you can axfr the root zone and then the root servers only know you're a resolver. The TLD servers know a lot, by necessity, though.
I think, though, for the purposes of this argument you can lump the TLD and root servers together. Lot of people are going to know who you are and what you're looking up if you run your own recursive resolver directly against the root servers
What modern recursive DNS uses is called Query Name Minimisation, and is enabled by default by some.
If you include the TLD as part of "Lot of people are going to know who you are and what you're looking up", ignoring any mitigating effect of Query Name Minimisation, the number of people is identical to any other setup.
For ISP resolver it will be the ISP and the owner of the domain name through web logs.
For public DNS resolver it will be the public resolver and owner of the domain through web logs.
for personal recursive resolver, it will be the TLD and the owner of the domain name through dns and web logs. The TLD job in this case is to give you the authoritative name servers of the domain name that the owner of the domain has.
With Query Name Minimisation, the TLD only get the domain name without any subdomains. They can't see the distinction between a user reading hacker news, or a user going to the main page of ycombinator to read about YC invests.
The Tor daemon exposes DNS resolvers if you enable them in torrc.
You'd of course be trusting Tor nodes for your DNS at that point, as I believe the network pulls records from exit nodes' resolvers, but you sidestep the quandary of deciding who you trust to directly make requests to.
You can also have multiple resolvers in the same daemon that use their own circuits, reducing the chances of receiving forged DNS records from potentially malicious exit nodes.
Similarly, DoH and DoT work over Tor.
You don't have to use it at a system level, just point your DNS clients at the daemon.
Not really. If motivated, building a bespoke DNS for personal (or whatever) use is easy these days. The hard part is the infrastructure to make it reliable and maintainable.
The issue isn't trusting DNS. It's trusting my local network. DNS is unecrypted UDP traffic. There are less than 65,535 ports that my machine can use to originate that request.
The problem with the protocol is poisoning not authority.
Alright so the article's tl;dr says to not use DoH as it merely reduces the number of peepers to one (which firstly is a good thing and secondly also offers protection against UDP spoofing attacks)... then goes on to recommending DoT, which would suffer from the exact same (non-)issue, but also actually gets to the actual problem with DoH, which is that the HTTP part has no business being there and increases complexity, which I as a former DNS resolver implementor wholeheartedly agree with!
Why discredit the whole post by adding an irrelevant tl;dr?
> also actually gets to the actual problem with DoH, which is that the HTTP part has no business being there and increases complexity, which I as a former DNS resolver implementor wholeheartedly agree with!
But that part is wrong too. The HTTP part has a very important reason to be there: because if it weren't, middleboxes would block the traffic.
That's just the 443 port – the middlebox can't see anything else anyway. Were that an actual concern, we could standardize running DoT on 443 instead of the status quo 853, and negotiating the protocol via ALPN. The "dot" ALPN is already standardized and implemented in actual production DNS software, so the port number is realistically the only obstacle.
I concur and generally advise against using large corporate DNS providers. Instead, consider setting up your own DNS infrastructure, such as your own recursive servers, or opt for a trustworthy DNS provider like Freifunk or CCC, rather than Google, Cloudflare, or Quad9.
The advantages of self-hosting recursive servers include complete configurability, absence of censorship, tracking, and rate limits. However, like any self-hosting solution, it requires an investment of time and money. It's also important to note that DNS lacks an authentication layer, so for access restrictions, it should be placed within a private network or VPN.
The issue of pre-configured DNS over HTTPS (DoH) in many browsers and mobile devices can be addressed through firewall rules on your router.
For creating your own DNS infrastructure, I recommend dnsdist if you have ample time, though bind and unbound are also viable options.
For the past three years, I have been running dnsdist with recursive servers on two ARM VPS instances, costing around 14 EUR per month. This setup provides me with DNS over TLS (DoT), DoH, and other features. I use them with unbound (TLS) or dnsproxy and dnscrypt-proxy across routers, servers, and other machines. For mobile devices, I utilize DoH directly.
Previously, I used bind in recursive mode without any encryption beyond SSH tunneling or VPN.
Alternatively, I can recommend ffmuc as a DNS provider.
I also run my own recursive DNS server on a VPS I rent, but I freely share it with other users of the Internet. This causes my "personal" signal of queries to authoritative servers to effectively disappear, and I also (marginally) benefit from caching effects of other users' lookups.
Well, concerning technical risks, DNS Cache Poisoning[0] is a thing - but I keep the software implementing my recursive DNS service up to date very eagerly, so I guess the risk of falling victim to such an attack is rather low.
I haven't taken this step yet, but I have considered it. Could you recommend whether I should share the service on a list such as dnscrypt.info/public-servers?
I was not aware of such a directory existing in the first place :) I only advertise "my" service (it only implements DNS and DoT) through word of mouth in communities I participate in.
dnsdist support QPS limits [1] and eBPF filtering [2]. And you can use dynamic Rules to drop traffic and there are several rules to set UDP and TCP limits.
That was indeed yet another one of Mozilla's well hidden moves to reduce our privacy. I've set up Adguard Home with a local recursive DNS resolver [1]. I haven't enabled encryption of the DNS queries, but I only ever connect through secure connections, so I don't mind. Sometimes queries are slightly slower or might fail (I'm guessing they time out), but I think it's really worth the extra privacy. I'm not really worried about leaking my IP to root servers, since at least they aren't run by an advertising company. (I hope?)
That's not a bad setup, but now your DNS requests to the root servers aren't encrypted, which means anyone between you and the root servers can see the requests. I guess it depends on whether it's more likely that someone is snooping the requests off the wire or that the server you're sending the requests directly to is snooping on them in addition to just resolving them.
I think the ideal solution would be if the root servers adopted encryption of some sort. But I can see why they're somewhat reluctant to do that, especially with relatively heavy protocols (compared to DNS) like DoH or DoT.
Edit: With the existence of QNAME minimization, I guess I should say that the requests to the root servers or authoritative DNS servers are unencrypted. This does at least spread out the risk a little, since other than your ISP there's probably some variation in who is actually between you and the various servers you're making requests to.
I totally agree with this and I wish root servers supported DoT, but I guess this setup is slightly better than having all your queries collected by a single entity (at least as far as you can know, because as you said, anyone in between can intercept requests). At least response integrity can be verified with DNSSEC and DNS-level censorship can be prevented much more effectively.
DoH using HTTPS for example is a reasonable choice; it blends the DNS traffic in with HTTPS traffic, not requiring network operators to open a new port and, in fact, making it harder for network operators to stop you from being able to use it. If you are not on a hostile network then there's not much of a practical advantage of picking DoH or DoT, but the reasoning for why DoH made this choice is not unreasonable. And HTTP may be more complicated than DNS, but neither of them are really close to the complexity of TLS, and any OS is going to need at least one good implementation of both if it plans on existing on the Internet, so I'm really not sure why this seems like a good place to draw the line.
Secondly, okay sure, don't trust Cloudflare... But, on the other hand, why is it better to send your DNS requests unencrypted? i.e. why would you disable DoH entirely? One party peeping is still less than an arbitrarily large number? In practice there is an extremely good chance that even if Cloudflare acted in a maximally malicious manner, having them as your DNS provider is the least scary implication. They already have untold amounts of information about you from the fact that they're a middle man terminating TLS for a lot of the websites you visit. And while it would be nice to have private DNS that is hardened against Cloudflare or the U.S. government spying on you, this is kind of at odds with having DNS be low latency, accurate and reliable.
I think a lot of actual dislike of DoH comes from people who believe that network operators should be the ultimate controllers of their domain, but in the future we actually got most people don't even control the WiFi in their home to any meaningful extent. As much as it's hard to trust Google or Cloudflare, since you know they have bad incentives to circumnavigate the will of the user and network operators, they are in the unfortunate situation of "having a good point" with regards to DoH. I ultimately never liked Firefox's decision to roll out DoH by just automatically sending DNS requests to Cloudflare using a trust-me-bro promise; oddly enough, Chrome did a more reasonable approach, trying to use whatever your configured DNS server is, but automatically upgrading it to DoH if it was a resolver that had a known DoH endpoint.
Granted, I believe Google Chromecast devices also will attempt to use DoH to get around a Pi Hole, so obviously I'm not trying to give any undue credit here. You still can't really trust Google or Cloudflare on the whole. But, being wrong about some things doesn't mean you're also wrong about other things, and the points made in favor of DoH still do stand, especially when it is configured explicitly by the end user. (P.S.: and it's silly to really dwell on this point too much anyways. If you had a truly malicious party, they could simply not use any kind of DNS to resolve names at all, in an effort to make their traffic harder to block. Using DoH is still less obscure.)
The bottom line is though, it's not clear if you can really trust your own ISP anymore than Cloudflare, especially depending on where you live. Ultimately, it's not hard to see why Firefox made this choice.
DoH does wonders against ISPs which filter DNS traffic (including traffic to third-party DNS servers). This happens more often than many people realize. My ISP blocks traffic to a couple of random websites (perfectly safe and legal) just because their security system doesn't like them, and they can't do anything about that. I only wish for more websites to deploy ECH, because they are using SNI filtering as well.
Same goes for if you have an IoT device behind a corporate firewall and you are being forced to use a enterprise DNS server running on some Cisco or Juniper device which doesn't respect TTL's, filters TXT records, etc.
Ah, are you a data exfiltrator or a ransomware operator? I jest.
I think the network as a chokepoint will slowly go away due to improvements in cryptography, and we'll need the endpoint to do all the inspection and enforcement.
> I think the network as a chokepoint will slowly go away due to improvements in cryptography, and we'll need the endpoint to do all the inspection and enforcement.
That's exactly what I want, because any solution other than that one would allow network operators to snoop on other people's endpoints.
> A decent corporate policy will block or decrypt DoH, same as it blocks direct outbound DNS.
DoH is simply HTTPS traffic as far as a firewall is concerned so how are you going to block or decrypt it?
If you take it a step further and you are running a DoH server on the same place where the API endpoints (REST, gRPC or whatever) for your IoT device are running no one is going to see the anything but HTTPS traffic
HTTPS decryption in corporate environments is standard. Have a corporate root CA, install certs on endpoints, and man-in-the-middle the network traffic.
This is surprisingly easy to beat using very funny methods, like splitting the request in the middle of SNI, or sending a request with a low TTL to an unblocked website first which gets dropped then repeating it to the correct SNI.
There are more methods all of which I find very funny for some reason. You can use GoodbyeDPI on Windows and zapret on Linux.
The disadvantage of those methods is that they require installing custom software, and they don't work on mobile devices unless you put them behind a router with custom firmware. In contrast, DoH works out of the box on most operating systems, and hopefully ECH will work as well.
I guess it depends on the situation then. My ISP doesn't pull such stunts and if they did, I would switch them in a moment. Fortunately others around here don't suck either. Cloudflare (or Google, or whoever) OTOH gets waaaay too much data from everybody. For my taste at least.
I'm glad your ISP doesn't do that, but there are a lot of people not as lucky as you, and we shouldn't deny them all a major increase in privacy just to avoid having you to change one browser setting.
If you're using insecure DNS, then you have no choice but to let your ISP see all your queries. But if you're using DoH, you can choose from plenty (see https://github.com/curl/curl/wiki/DNS-over-HTTPS) of other DoH providers instead if you don't trust Cloudflare.
Frankly, the article is doing a lot of disservice (and should be removed in HN because of its grossly outdated information). As josephcsible pointed out, there are many, many options for DoH.
Very true...
I used to be with Sky here in the UK, and at the time they were running a transparent proxy on port 53. Changing DNS providers made no difference to the dnsleaktest results. Don't know if they still do that now.
I'm now with a different ISP, and anyway have PiHole handling DNS queries on most devices in our house. It forwards DNS requests to dnscrypt-proxy running on the same Pi, which uses Quad9 over DoH.
Due to recent browser problems I was giving Brave a shot. It's an interesting browser, but it has DoH enabled in a way that seemingly cannot be entirely disabled. It can be frustrating to not be able to interact with a lot of services because the browser is disregarding my local policy on my system.
Topic is about privacy concerns for using provider not DoH itself. With Doh, i am not worried about some UDP based attacks, i can easily put WAF and other auth mechasims for self hosted Private DNS systems
297 comments
[ 6.0 ms ] story [ 208 ms ] threadRun hyperlocal root, run your own dns.
His "don't move off 22 for ssh" is also just opinion. He argues "you will be found" but misses the experience of those of us running on shifted ssh is continuously validated by the visibly lower level of probes we see. He offers no mathematical analysis of how quickly a port knock sequence will be uncovered, and again dismisses it as infeasible and useless.
I've got nothing against strongly held opinions and these are his. But, form your own opinions too.
I sometimes think of putting my private servers on completely random IP addresses drawn from /64 IPv6 ranges. It should be near-impossible to find those by address scanning, unless I'm overlooking something dumb. Am I? It wouldn't surprise me.
For example suppose you put my-private-server.vanity-domain.example in DNS with an AAAA pointing to your private server - "passive DNS" service means big DNS providers will sell the answers they saw when anybody (say, yourself, on somebody else's computer) asks AAAA? my-private-server.vanity-domain.example. They don't reveal who asked, so this isn't personal information, but they do reveal what the question was and its answer.
A long time ago we used this to build target portfolios, if we're going to sell your company our product X, this is way we can see that you already have products A, B and C, but not D, E or F so we look a bit smarter coming into the sale.
Come to think of it, I could have a private DNS too. I haven't bothered with that.
In terms of privacy, they still preserve it (according to GDPR principles).
Worse than that, that post misunderstands it's own statement:
"Sure, you will see fewer attacks than before, but most of the attackers are no longer just stupid bots"
That's a *good* thing, because the move has reduced the signal to noise ratio. By getting rid of most of the crufty noise of the internet, you now know that anything hitting your logs now is more likely to be an actual threat than the poorly automated dictionary attack bots.
Moving SSH to a different port doesn't make the system much more secure (and definitely shouldn't be the only thing you do), but it does generally enable you to be more responsive.
because then we could use DoH for hiding our DNS requests..
DoH requests go to /dns-query so you only need that path to proxy onto your DoH handler.
Some DoH clients will also allow you to specify a custom path, so you can also obfuscate the path by configuring client and server to use /foobar instead.
But, re-using an existing site does come at the cost of generating a bunch of extra log noise (fine if it's just you, not so fine if it isn't). If you don't have some kind of auth in place, you might also find that you suddenly come under a lot of load (when I ran a public DoH service, I eventually started getting a lot of traffic from users in an authoritarian country)
> Cloudflare gets all your DNS queries.
That's true, but Cloudflare is more trustworthy than my ISP, and probably most people's ISPs.
> Complexity is the enemy of security.
That's true, but that's no reason to go from an imperfect solution to a nonsolution.
> there is DNS over TLS
That doesn't solve most of the issues that the author brought up.
> How does a modern company in the IT business earn money? By selling data.
Maybe I'm naive, but I thought they made money by using all the data they collect for better threat prevention, and from their paid services.
Based on what?
The bar is real low, mostly for the fact that ISPs are mandated by law in most if not all countries to track traffic flowing through their pipes.
Cloudflare provides relatively better privacy guarantees for the public DNS resolvers it runs: https://developers.cloudflare.com/1.1.1.1/privacy/cloudflare...
If you live in a rural area where people are co-operative, there might be a community owned fibre operator plus Opeanreach, otherwise just Openreach.
If you live somewhere very silly, like up a mountain or on your own island, your only practical option will be paying Openreach to do the work.
Edited to add, Notably: Only Openreach is usable by an arbitrary service provider. So if you want to pick your service provider separately, the actual last mile delivery will always be Openreach. And if they're small it won't just be last mile, Openreach also sell backhaul to get your data from some distant city to the place where the ISP's hardware is, you're buying only the, like, actual service. Which is important - mine means no censorship, excellent live support and competent people running everything, but the copper under the ground is not something they're responsible for (though they are better than most at kicking Openreach when it needs kicking)
In the UK there are even aggregators like Fibre Café [1] that makes it easier for ISP's to connect through multiple networks.
[1] https://fibrecafe.co.uk/
You're next argument might be "but how do you know the server is really using ODNS?" You don't. If your security threat profile doesn't allow for this, whatever you're doing shouldn't be using a public internet network anyway.
CF issues are dealt with “hope to get a post on HN trending”.
Cloudflare, on the other hand is based in a foreign jurisdiction that offers none of these protections.
It really depends on which jurisdiction are you in, unfortunately. US ISPs are selling everything they can hover (including DNS information) to advertisers, and it is impossible to switch to another one unless you're lucky (because the monopoly is essentially maintained).
Given that they are funded and run by the same forces american parastical capitalism provides I would trust them as much as I'd trust google or alphabet.
I'll continue to route my DNS to quad-nine over mullvad over my specifically chosen ISP, and everything on my network does that as I can easily intercept and redirect udp/53.
The weak point are treacherous devices which use DoH which is a constant fight to block.
Why would cloudflare, built from the same corporate background, be any more trustworthy?
Some may also consider reverse proxying/caching to be providing transit service, but I'm not sure if the majority of people would agree on that.
So you already have to trust your ISP anyway -- but there was no need to trust Cloudflare *. DoH to Cloudflare is almost certainly a net loss in privacy compared to using your ISP's DNS over clear text.
* Right until they became hosters of half of the WWW. So Cloudflare can pretty much also guess your activity even if you don't do DNS with them anyway.
Even if you use a VPN?
Big CDNs and ECH make that impossible.
If I check up right now, form the top 10 links in HN right now, it is trivial to distinguish the top-level domain from just the IPv4 or IPv6 address. Heck, even _for this website itself_ the current IPv4 reverse DNS points to ycombinator.com. I don't even need to go into packet size heuristics, or the myriad of ad networks, etc.
Sure there are some instances where you will share the IP of the CDN. This has been seen recently e.g. in the recent article of the "LaLiga" blocks in Spain. But bigger sites cannot afford for this to happen, and even smaller sites tend to have at least one paid IP address for mail (reputation is a bitch, and Cloudflare doesn't have any).
Two of the top 10 links in HN right now (https://news.ycombinator.com/item?id=44215603 and https://news.ycombinator.com/item?id=44212446) are to different subdomains of github.io that resolve to the exact same IP addresses, so reverse DNS doesn't tell you which one is being visited.
And you can't even tell the TLD, because the TLD is "io", but the reverse lookup on the IPs will give you a TLD ending in "com".
> Heck, even _for this website itself_ the current IPv4 reverse DNS points to ycombinator.com.
That's because HN isn't behind the kind of CDN I'm talking about. But a lot are. Is your argument "since your ISP can see some of the sites you're going to, we should remove all protections and let them see all sites you're going to?"
"io" and "com" are top-level domains, and in the example I gave, you can't even distinguish between them.
In the meanwhile, from the current top #30 articles on HN (also via copilot script, but I removed non-cloudflare IPs):
Look at how many of them are self-hosted, have zero CDN, or otherwise return me always the same IP (even when I try from 3 different ISPs) which makes them trivial to reverse address. This is already a pretty huge success rate and all my context is that you browsed HN first (which I know, see first result on the list). Now imagine the tools a ISP will have at its disposal:- IPv6
- Its Geo region will actually match yours
- Routing tables
- The patience to also include resources fetched from these pages in the analysis (i.e. page X always gets its JS from Y domain which results in a constant Z KB transfer).
- The rest of your browsing activity
- The rest of everyone's browsing activity including most popular _current_ hosts for each hostname.
Do you still claim that it is "impossible" to track your activity because of CDNs? I still bet you your ISP can do it with _100%_ accuracy.
They're never going to be "1 IP ECH" . That would be the end of the Internet as we know it.
If it ever happens that the majority of the WWW is 1 CDN, we have a bigger privacy problem than DNS. Much bigger.
Many ISPs explicitly sell DNS data, and are also advertising vendors.
Cloudflare, on the other hand, doesn’t share or sell data and retains minimal data: https://developers.cloudflare.com/1.1.1.1/privacy/public-dns...
So does UDP based DNS, and TLS based DNS. It’s all the same in that regard.
Do ISPs do deep packet inspection to get lookup data? Maybe, but it increases the cost of doing so and makes the business aspect of it less viable. Perhaps a minor win.
With cleartext DNS, your queries may never reach your chosen server. Plenty of ISPs are configured to just answer any DNS query, regardless of its destination. Using a nonstandard port might help, but you’d be much better off deploying one of the DoH / DoT / DoQ / etc secure protocols.
They know your government id when you subscribe to their service.
CloudFlare, otoh, never have your identity. They only have the metadata
This is textbook politician's fallacy. Yes, it may be preferable to continue with a "non-solution" if the solution proposed is stupid enough.
DoH does solve a problem for many people. Many large ISPs will sell your DNS requests, use them for targeted advertising, tamper with responses for various reasons, etc., and so DoH is an improvement over the status quo--not for everyone, but for many users, and I'd guess most users.
You're right, DoH might not be worth adopting if it were "stupid enough", but... it's not stupid enough.
If you combine this with ECH and a good blocker, no they do not. That's exactly why Spain is blocking around 60% of the internet during football games now; the ISPs cannot tell which websites and subscribers are pirating football streams.
[citation needed for the 60% figure]
Precisely due to these blocks is why I know that Cloudflare is NOT 60% of the WWW, not yet at least. Certainly, if Cloudflare was serving 60% of the Internet, I would consider switching my DNS to them. But that would be a privacy nightmare for another day (replacing federated ISPs with a single big centralized one? great idea /s). It is not yet the case as of today.
In fact, as of today, and even if you have a "good blocker", I, a total noob, have a high chance of reliably identifying which HN news item from the top #30 you clicked from just the addresses: https://news.ycombinator.com/item?id=44219061 . Imagine what the non-noobs at your ISP could do.
We must do something. This is something. Therefore, we must do this.
Also, does anyone know what's the safest option? And how to configure it for all our home devices?
I'm currently using pi-hole configured to use DoT through Cloudflare.
In some situations, DoT is fine. In others, it won't work, but DoH will.
If we're getting into the technical part of the discussion though, I personally don't think DoH or DoT are great protocols for DNS. Security is fine, but it's a lot of overhead for relatively small requests where latency matters. I wish DNScrypt had gained more traction as an encrypted protocol designed specifically for DNS.
maybe there is something to be said about the complexity but they left that to the last paragraph
[0] like https://www.quad9.net
If the goal is to reduce centralization, a better approach would be to use encrypted DNS (DoH or DoT) with resolver rotation or randomization. That way, users retain privacy from local networks and ISPs without concentrating all DNS traffic in a single provider’s hands.
You’ll only be vulnerable to a MitM attack if your system’s resolver is insecure and also vulnerable to a MitM attack.
(I have weirdly strong and specific ideas about DNS security.)
Some of the websites just don't open without DoH.
And abusing https is for a good reasons. Blocking ports 53 and 853 is easy and many ISPs will do that.
The author also make it feel like the only option is to use cloudflare DoH on Firefox while that's the first option, there is also nextdns and custom field. There are many providers I would trust more like quad9 and Mullvad DoH.
I think the reasons why not to use DoH is the same for why not using public dns from providers you don't trust anyway.
Most of the people are happily using 8.8.8.8 and handing all their dns information to the biggest advertisement company in the world. Or wosre, using their ISP provided DNS.
In fairness, the date on the post is 2018 - when Firefox first launched this, Cloudflare was the only option
With modern recursive DNS, you don't leak much to the root servers, just the tld you're trying to resolve. And you can axfr the root zone and then the root servers only know you're a resolver. The TLD servers know a lot, by necessity, though.
If you include the TLD as part of "Lot of people are going to know who you are and what you're looking up", ignoring any mitigating effect of Query Name Minimisation, the number of people is identical to any other setup.
For ISP resolver it will be the ISP and the owner of the domain name through web logs.
For public DNS resolver it will be the public resolver and owner of the domain through web logs.
for personal recursive resolver, it will be the TLD and the owner of the domain name through dns and web logs. The TLD job in this case is to give you the authoritative name servers of the domain name that the owner of the domain has.
With Query Name Minimisation, the TLD only get the domain name without any subdomains. They can't see the distinction between a user reading hacker news, or a user going to the main page of ycombinator to read about YC invests.
You'd of course be trusting Tor nodes for your DNS at that point, as I believe the network pulls records from exit nodes' resolvers, but you sidestep the quandary of deciding who you trust to directly make requests to.
You can also have multiple resolvers in the same daemon that use their own circuits, reducing the chances of receiving forged DNS records from potentially malicious exit nodes.
Similarly, DoH and DoT work over Tor.
You don't have to use it at a system level, just point your DNS clients at the daemon.
The problem with the protocol is poisoning not authority.
>Is there an alternative way?
What about just using different provider that you trust?
What if I trust Cloudflare more than I do trust my ISP?
Why discredit the whole post by adding an irrelevant tl;dr?
But that part is wrong too. The HTTP part has a very important reason to be there: because if it weren't, middleboxes would block the traffic.
Article is a bunch of strong opinion with nothing to back them.
The advantages of self-hosting recursive servers include complete configurability, absence of censorship, tracking, and rate limits. However, like any self-hosting solution, it requires an investment of time and money. It's also important to note that DNS lacks an authentication layer, so for access restrictions, it should be placed within a private network or VPN.
The issue of pre-configured DNS over HTTPS (DoH) in many browsers and mobile devices can be addressed through firewall rules on your router.
For creating your own DNS infrastructure, I recommend dnsdist if you have ample time, though bind and unbound are also viable options.
For the past three years, I have been running dnsdist with recursive servers on two ARM VPS instances, costing around 14 EUR per month. This setup provides me with DNS over TLS (DoT), DoH, and other features. I use them with unbound (TLS) or dnsproxy and dnscrypt-proxy across routers, servers, and other machines. For mobile devices, I utilize DoH directly.
Previously, I used bind in recursive mode without any encryption beyond SSH tunneling or VPN.
Alternatively, I can recommend ffmuc as a DNS provider.
[0]: https://en.wikipedia.org/wiki/DNS_spoofing#Cache_poisoning_a...
You can't run a public service without reflecting something, but you can endeavour to make the reflection ratio small.
A in production config looks like: https://github.com/freifunkMUC/ffmuc-salt-public/blob/main/d...
[1] https://www.dnsdist.org/advanced/qpslimits.html
[2] https://www.dnsdist.org/advanced/ebpf.html
[1] https://github.com/semihalev/sdns
I think the ideal solution would be if the root servers adopted encryption of some sort. But I can see why they're somewhat reluctant to do that, especially with relatively heavy protocols (compared to DNS) like DoH or DoT.
Edit: With the existence of QNAME minimization, I guess I should say that the requests to the root servers or authoritative DNS servers are unencrypted. This does at least spread out the risk a little, since other than your ISP there's probably some variation in who is actually between you and the various servers you're making requests to.
https://adguard-dns.io/en/welcome.html
DoH using HTTPS for example is a reasonable choice; it blends the DNS traffic in with HTTPS traffic, not requiring network operators to open a new port and, in fact, making it harder for network operators to stop you from being able to use it. If you are not on a hostile network then there's not much of a practical advantage of picking DoH or DoT, but the reasoning for why DoH made this choice is not unreasonable. And HTTP may be more complicated than DNS, but neither of them are really close to the complexity of TLS, and any OS is going to need at least one good implementation of both if it plans on existing on the Internet, so I'm really not sure why this seems like a good place to draw the line.
Secondly, okay sure, don't trust Cloudflare... But, on the other hand, why is it better to send your DNS requests unencrypted? i.e. why would you disable DoH entirely? One party peeping is still less than an arbitrarily large number? In practice there is an extremely good chance that even if Cloudflare acted in a maximally malicious manner, having them as your DNS provider is the least scary implication. They already have untold amounts of information about you from the fact that they're a middle man terminating TLS for a lot of the websites you visit. And while it would be nice to have private DNS that is hardened against Cloudflare or the U.S. government spying on you, this is kind of at odds with having DNS be low latency, accurate and reliable.
I think a lot of actual dislike of DoH comes from people who believe that network operators should be the ultimate controllers of their domain, but in the future we actually got most people don't even control the WiFi in their home to any meaningful extent. As much as it's hard to trust Google or Cloudflare, since you know they have bad incentives to circumnavigate the will of the user and network operators, they are in the unfortunate situation of "having a good point" with regards to DoH. I ultimately never liked Firefox's decision to roll out DoH by just automatically sending DNS requests to Cloudflare using a trust-me-bro promise; oddly enough, Chrome did a more reasonable approach, trying to use whatever your configured DNS server is, but automatically upgrading it to DoH if it was a resolver that had a known DoH endpoint.
Granted, I believe Google Chromecast devices also will attempt to use DoH to get around a Pi Hole, so obviously I'm not trying to give any undue credit here. You still can't really trust Google or Cloudflare on the whole. But, being wrong about some things doesn't mean you're also wrong about other things, and the points made in favor of DoH still do stand, especially when it is configured explicitly by the end user. (P.S.: and it's silly to really dwell on this point too much anyways. If you had a truly malicious party, they could simply not use any kind of DNS to resolve names at all, in an effort to make their traffic harder to block. Using DoH is still less obscure.)
The bottom line is though, it's not clear if you can really trust your own ISP anymore than Cloudflare, especially depending on where you live. Ultimately, it's not hard to see why Firefox made this choice.
I think the network as a chokepoint will slowly go away due to improvements in cryptography, and we'll need the endpoint to do all the inspection and enforcement.
That's exactly what I want, because any solution other than that one would allow network operators to snoop on other people's endpoints.
If your OS doesn't trust a MitM box, it yells.
DoH is simply HTTPS traffic as far as a firewall is concerned so how are you going to block or decrypt it?
If you take it a step further and you are running a DoH server on the same place where the API endpoints (REST, gRPC or whatever) for your IoT device are running no one is going to see the anything but HTTPS traffic
This is surprisingly easy to beat using very funny methods, like splitting the request in the middle of SNI, or sending a request with a low TTL to an unblocked website first which gets dropped then repeating it to the correct SNI.
There are more methods all of which I find very funny for some reason. You can use GoodbyeDPI on Windows and zapret on Linux.
Instead of sending all my DNS traffic to sketchy multinational corporation A, we'll send all my traffic to sketchy multinational corporation B?
Doesn't seem like much of an increase in privacy to me.
I'm now with a different ISP, and anyway have PiHole handling DNS queries on most devices in our house. It forwards DNS requests to dnscrypt-proxy running on the same Pi, which uses Quad9 over DoH.
Due to recent browser problems I was giving Brave a shot. It's an interesting browser, but it has DoH enabled in a way that seemingly cannot be entirely disabled. It can be frustrating to not be able to interact with a lot of services because the browser is disregarding my local policy on my system.
Plus, the last comment on that thread says that "It works fine in incognito or a fresh profile". I suspect that some kind of caching is at play here.
https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-oha...
Agree with the general claim that anything "S" could be a power grab by a single peeper. Google pushing HTTPS in Chrome comes to mind.
If it's privacy, why offer DNS-over-TLS as an alternative? It has exactly the same privacy properties.
If it's security, then tl/dr and first section makes no sense.