8 ms·

Why not use DNS over HTTPS (DoH)?

154 points by Bogdanp 1y ago

jamesponddotco 1y ago
Personally, I prefer DNSCrypt over DoH or DoT (and run my own DNSCrypt servers), but I see no problem with DoH. It's certainly an improvement over unencrypted DNS.
ggm 1y ago
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.
- throwaway81523 1y ago
  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.
  - tialaramex 1y ago
    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.
    - KwanEsq 1y ago
      Couldn't you just make my-private-server.vanity-domain.example a manual /etc/hosts entry to prevent advertising it?
      - kvdveer 1y ago
        You could. You'd only have the ability to log in from your own machine though. If that compromise works is very much dependent on your situation.
        throwaway81523 1y ago
        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.
        NewJazz 1y ago
        At that point don't open port 22 to the internet, just set up wireguard or tailscale.
      - hk1337 1y ago
        Just as easy, you could just set the Host in your ssh config. Then you don’t have to deal with dns
    - miyuru 1y ago
      For a real world example, I use IPv6 only SSH+public DNS and my fail2ban has 2 fails for a uptime with 285 days.
- j0057 1y ago
  I agree that sooner or later your SSH port will end up on Shodan anyway. Putting SSH behind a Wireguard VPN solves this completely.
- mhitza 1y ago
  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.
  - ignoramous 1y ago
    If privacy is your concern then dns0.eu is not "no logs" (like BlahDNS or Mullvad DoH/DoT are, for example). They share "anonymized intelligence feeds" with their partners: https://docs.dns0.eu/threat-intelligence-partners/anonymized-query-logs https://docs.dns0.eu/threat-intelligence-partners/anonymized...
    - mhitza 1y ago
      Thank you for the heads-up. That's an important point, and I wasn't aware about that feature. In terms of privacy, they still preserve it (according to GDPR principles).
- btasker 1y ago
  > 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.
deknos 1y ago
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..
- crabique 1y ago
  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.
- btasker 1y ago
  Yes. 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)
creata 1y ago
The points here aren't technically wrong, but it still feels like disabling DoH would be a reduction in security. For example: > 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.
- archerx 1y ago
  > That's true, but Cloudflare is more trustworthy than my ISP, and probably most people's ISPs. Based on what?
  - ignoramous 1y ago
    > 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-resolver-firefox/ https://developers.cloudflare.com/1.1.1.1/privacy/cloudflare...
- pacifika 1y ago
  In the UK you can typically pick from a dozen ISPs, some of which are more trustworthy
  - ortichic 1y ago
    Can you also choose which company provides the physical infrastructure that connects to your home?
    - tialaramex 1y ago
drykiss 1y ago
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?
jedisct1 1y ago
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.
- josephcsible 1y ago
  Oblivious DoH would be fine, but isn't anonymized DNSCrypt distinguishable on the wire from HTTPS even though it's over port 443?
- issafram 1y ago
  Are there any guides on how to set this up? I'm currently using pi-hole configured to use DoT through Cloudflare.
sudahtigabulan 1y ago
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.
- rainsford 1y ago
  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.
throawayonthe 1y ago
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 [0] like https://www.quad9.net https://www.quad9.net
xrmagnum 1y ago
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.
- WhyNotHugo 1y ago
  Disabling DoH in your browser’s settings should make it fall back to you system’s resolver. You’ll only be vulnerable to a MitM attack if your system’s resolver is insecure and also vulnerable to a MitM attack.
  - sammy2255 1y ago
    (which all are by default)
    - NewJazz 1y ago
      No, plenty of OSs ship encrypted DNS resolvers by default.
      - josephcsible 1y ago
        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.
    - WhyNotHugo 1y ago
      That's a pretty serious security issue, which affects every other process on your host.
- 1y ago
om8 1y ago
I trust cloudflare more than my ISP, since I live in a place where internet is very state controlled. Some of the websites just don't open without DoH.
- josephcsible 1y ago
  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.
elashri 1y ago
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.
- btasker 1y ago
  > The author also make it feel like the only option is to use cloudflare DoH on Firefox In fairness, the date on the post is 2018 - when Firefox first launched this, Cloudflare was the only option
  - elashri 1y ago
    Now that makes more sense regarding this point. I missed the date. I think the submission title needs (2018).
  - rainsford 1y ago
    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.
  - josephcsible 1y ago
    Even back then, wasn't Cloudflare just the only listed option? Couldn't you still have manually entered a different DoH server that you knew of?
tester756 1y ago
wtf is this? >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?
spiffyk 1y ago
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?
- josephcsible 1y ago
  > 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.
  - spiffyk 1y ago
    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.
arbll 1y ago
Ah yes I'm going to disable DoH and go from trusting a central entity to trusting another central entity and everyone else on the wire. Article is a bunch of strong opinion with nothing to back them.
exiguus 1y ago
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.
- c0l0 1y ago
  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.
  - victorbjorklund 1y ago
    Are there any security risks with sharing it wiyh others?
    - c0l0 1y ago
      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. [0]: https://en.wikipedia.org/wiki/DNS_spoofing#Cache_poisoning_attacks https://en.wikipedia.org/wiki/DNS_spoofing#Cache_poisoning_a...
creatonez 1y ago
DNSCrypt has a list of DoH and ODoH resolvers other than Cloudflare: https://github.com/DNSCrypt/dnscrypt-resolvers https://github.com/DNSCrypt/dnscrypt-resolvers
a022311 1y ago
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?) [1] https://github.com/semihalev/sdns https://github.com/semihalev/sdns
- rainsford 1y ago
  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.
  - a022311 1y ago
    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.
    - tptacek 1y ago
      DNSSEC doesn't do anything to prevent DNS-level censorship, and DoT is easier to block than DoH --- that's why there's DoH in the first place.
dev_l1x_be 1y ago
Two raspberries with Adguard combined with Tailscale is pretty safe and removes a nice chunk of garbage from the internet https://adguard-dns.io/en/welcome.html https://adguard-dns.io/en/welcome.html
- leosanchez 1y ago
  Why two ? For redundancy or am I missing anything?
  - dev_l1x_be 1y ago
    Redundancy
jchw 1y ago
This is a very strange article. 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.
dabacaba 1y ago
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.
- jsiepkes 1y ago
  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.
  - unethical_ban 1y ago
    A decent corporate policy will block or decrypt DoH, same as it blocks direct outbound DNS.
    - josephcsible 1y ago
      The hope is we eventually get enough things like DoH and ECH that it stops being feasible for corporate policies to block things.
      - unethical_ban 1y ago
        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.
        josephcsible 1y ago
        > 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.
ddtaylor 1y ago
DoH is problematic in other ways too. 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.
- EbNar 1y ago
  How is that? It's just a switch, as in any other Chromium browser.
  - ddtaylor 1y ago
    https://github.com/brave/brave-browser/issues/39028 https://github.com/brave/brave-browser/issues/39028
    - josephcsible 1y ago
      What does that have to do with DoH?
      - ddtaylor 1y ago
        It's an example of how Brave will not respect the configurations given because it still attempts to use DoH.
        EbNar 1y ago
        It works fine on my end, checked a lot of times with https://dnscheck.tools https://dnscheck.tools. 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.
    - tredre3 1y ago
      None of that thread seems to be related to DoH, though? More likely a caching issue.
toomim 1y ago
You can solve the problems with DoH by using OHAI: https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-oha...
thr0w 1y ago
With DNS over UDP, you have plausible deniability that you didn't actually make the request. With DNS over HTTP(S), you don't. 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.
- lokar 1y ago
  By claiming src spoofing?
ahmetozer 1y ago
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
theamk 1y ago
Not a very coherent article. .. is author's problem privacy or security? 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.
orbital-decay 1y ago
The tone is pretty manipulative and sounds like a weird FUD. >DoH is not about protecting your DNS queries from peepers. That is a big lie. It is about making sure only one peeper can see all of your queries. How is this a lie? It does protect your queries from MitM. I doubt anyone ever said anything about protecting from everyone - either you keep a synced copy of the entire DNS database (or its part) locally, or send your query to someone else's computer. How else do you expect it to work? >Refuse to use it today "Refuse"? Why??? >Is there an alternative way? Yes, there is. It is called DNS over TLS How does this eliminate the single peeper? You're still sending your query to someone else's computer. DoT encrypts, so it must be a good thing, right?
api 1y ago
I have blocked outbound raw DNS on my home LAN in favor of DoH from a pi hole.
dec0dedab0de 1y ago
i want to be able to man in the middle anything that phones home.
- josephcsible 1y ago
  If they're your own devices, sure. But without DoH, it would be possible to man-in-the-middle other people's devices too, and you shouldn't be able to do that.
- throwaway290 1y ago
  How do you deal with pinning which most apps do now?
  - dec0dedab0de 1y ago
    i hate it. hsts mixed with doh exist to take control, and transparency away from users, because most users never knew they had the option to begin with.
conradev 1y ago
Is there an alternative way? Yes, there is. It is called DNS over TLS and is specified as a proposed standard in RFC 7858. This provides transport encryption to DNS without abusing HTTP as transport protocol. HTTP/3 is a full VPN protocol via MASQUE. I don’t understand how DNS over TLS is anything but slightly less convenient and otherwise no different than DNS over HTTP.
mixdup 1y ago
Is DoH a bad idea because Cloudflare sees your queries or you're overloading HTTP as a protocol? This article seems to be advocating two different things At the end of the day, if your problem is you don't trust the DNS provider to also be snooping, no flavor of encrypted DNS will solve it. Whoever lands the DNS query will be able to snoop whether it's TLS or DoH
Mister_Snuggles 1y ago
The thing that bothers me most about DoH is that it moves the responsibility for name resolution from the operating system to each application. So now you don't have the ability to set up your own DNS server system-wide, you need to do it per-application and per-device. Assuming, of course, that the applications and devices in question allow you to do this and/or respect your choice when you do it. Also shoving every protocol under the sun into HTTPS just feels wrong. I get why it's happening (too many middleware boxes and ISPs think internet == web). But shouldn't we fix the ISPs and middleware instead of endlessly working around it?
- mlhpdx 1y ago
  Yes, but it won’t be easy. Heavy investment has gone into HTTP and we have great tooling and support for it as a result. That has a lot of benefits and I’m glad for it. But there is a cost. HTTP is a blunt hammer and computing sometimes needs a scalpel. Lighter, more efficient protocols are important, as QUIC and WireGuard have proven.
  - Mister_Snuggles 1y ago
    To play devil's advocate, shoving everything into HTTP/HTTPS also allowed a ton of innovation. Would video streaming sites (Youtube, Vimeo, etc) ever have gotten off the ground if they had to go to IANA to get a port number assigned, then wait for browsers to support the new protocol that runs over the new port, etc? Probably not to be honest. Or maybe browsers would just let JavaScript connect to any port, which would be terrifying from a security standpoint. I'm firmly convinced that shoving everything into HTTP/HTTPS was a mistake. But I'm also willing to acknowledge that it's probably the least-worst solution to a bunch of problems.
    - mlhpdx 1y ago
      Absolutely. The investment in HTTP means I can setup a website or API in a few clicks and pay nothing (or nearly so) for it. That has made it possible for me to try many, many things over the years. It’s fabulous. I would very much like to see that same freedom to innovate when using other protocols.
yegle 1y ago
I don't understand any of the arguments. Why mentioning DNS-over-TLS if you are against DNS-over-HTTPS? They have all the same "downside". What's wrong with one less peeper (your ISP)? You _have_ to use a DNS server unless you use something fancy like dnsmasq to round-robin between multiple DNS servers (but your ISP can still see everything) Besides, you can run your own DoH server with ease, you don't have to use Cloudflare's.
josephcsible 1y ago
This article is totally wrong. I'm not sure how it got so much traction. Details: > But slowly people started to realize what the collaboration between Mozilla and Cloudflare really means: Cloudflare gets all your DNS queries. There are a lot of DoH providers other than Cloudflare. https://github.com/curl/curl/wiki/DNS-over-HTTPS https://github.com/curl/curl/wiki/DNS-over-HTTPS lists several. If you don't want Cloudflare seeing your DNS requests, then use one of them instead. (And even for users who do just stick with the default, I think it's better privacy-wise for Cloudflare to see that data than for the average American ISP to.) > Yes, there is. It is called DNS over TLS and is specified as a proposed standard in RFC 7858. This provides transport encryption to DNS without abusing HTTP as transport protocol. The only difference between DoT and DoH is that DoT is easier to block and force fallback to totally insecure DNS. There's no reason to ever use DoT if you can use DoH. (And I don't get why the author likes it better: whoever runs the DoT server gets the exact same data that they'd get with a DoH server instead.) > No, it is not. Abusing HTTP as a transport protocol for DNS data adds a unneeded complexity to the protocol. You must add a HTTP module to all DNS servers or interact with a separated HTTP server on the same system in order to support DoH. That is a lot of code which can contain a lot of bugs and security flaws. Complexity is the enemy of security. The extra complexity of HTTP is massively outweighed by the significant reduction in fallbacks to insecure DNS.
- AnthonyMouse 1y ago
  > If you don't want Cloudflare seeing your DNS requests, then use one of them instead. Normal people have no idea that this even exists, much less how to do it, so they're still having all their queries routed to Cloudflare by default. > The only difference between DoT and DoH is that DoT is easier to block and force fallback to totally insecure DNS. A normal middlebox can't even tell the difference between DoH and DoT because they both just look like TLS. A corporate one that requires you to install certificates on the client so that it can, is just as able to block DoH as DoT. And fallback isn't required in either case. If some network is blocking encrypted DNS, the client device can be configured to fail rather than use the insecure DNS, at which point the user knows that the network is adversarial and can switch to a VPN or a cellular connection etc.
juliangmp 1y ago
>Refuse to use it today That's genuinely awful advice. Besides the fact that there are other DNS providers that can do DNS over HTTPS, disabling it just makes things worse. - you still fire all of your DNS requests to a single host (whether that's cloudflare or any other) - you also do it in clear text
finalhacker 1y ago
DOH is a protection for your privacy from ISP. Actually you can set multi DOH server with load balance to avoid your dns info concentrately collected by one dns provider.
KingLancelot 1y ago
[dead]
exabrial 1y ago
DNS over HTTPS exclusively exists because stuff like Pi-hole started eating into Ad Revenue for Google. That's why this "feature" is so hard to disable in the browsers as well. I hope they're forced to divest from Android and Chrome. It's absolute anti-consumer garbage. DNSCurve exists and was a far better solution, but that in turn... you know cut into ISP spying as well.
- nobody9999 1y ago
  >DNS over HTTPS exclusively exists because stuff like Pi-hole started eating into Ad Revenue for Google. That's why this "feature" is so hard to disable in the browsers as well. Exactly. Which is why I point my Pi-Hole at my own recursive resolver. Can my ISP see those queries? Sure. Are they using transparent proxies to redirect my queries to their resolvers? No. Is my ISP cataloguing all my recursive resolutions? Maybe. But probably not. Theoretically, they could, but mirroring all the traffic to storage for tens of millions of customers seems exorbitant, unnecessary and wasteful. More likely, I'd expect that at some point (likely the router interface at my local head-end), they use Netflow[0] and/or something similar, to characterize the IP-based traffic being transmitted through it. The collected data wouldn't contain the DNS queries themselves, so my ISP would need to rely on just the Netflow data. And while it is possible for ISPs to correlate DNS queries to Netflow streams[1][2], using a recursive resolver rather than their resolver makes it more cumbersome for them (or Cloudflare, or Google, etc.) to do so. Regardless, I'd much prefer that my recursive resolver use encrypted communications, not so much between it and the root servers, but between it and authoritative servers. The former would be nice, but depending on the encryption overhead (TLS or even just TCP connections to the root servers would require significant extra resources), likely impractical. >DNSCurve exists and was a far better solution Is there any recent activity WRT that protocol? I found some stuff from at least a decade ago. The IETF's DNS Private Exchange[3] (dpriv) working group has a few interesting things, but it sure would be nice to have the DNS equivalent of smtp's 'starttls'[5] feature, perhaps ala RFC9539[4]? Perhaps one day there will be mainstream support for that. What I do works for my use case, but likely isn't workable for many (most?) other folks. [0] https://en.wikipedia.org/wiki/NetFlow https://en.wikipedia.org/wiki/NetFlow [1] https://arxiv.org/pdf/2211.05682 https://arxiv.org/pdf/2211.05682 [2] https://github.com/maganiss/FlowDNS https://github.com/maganiss/FlowDNS [3] https://datatracker.ietf.org/wg/dprive/documents/ https://datatracker.ietf.org/wg/dprive/documents/ [4] https://www.rfc-editor.org/rfc/rfc9539.txt https://www.rfc-editor.org/rfc/rfc9539.txt [5] https://en.wikipedia.org/wiki/Opportunistic_TLS https://en.wikipedia.org/wiki/Opportunistic_TLS
aborsy 1y ago
Part of the reason I let Tailscale up even if I don’t need connectivity is DoH. It can send DNS in all devices encrypted to a public or private DNS server. It can force this by overriding client configuration if desired.
tsoukase 1y ago
Marginally offtopic: DNS filtering was tricky for me. I setup a pihole instance with secondary DNS a regular 8s. But the router accessed both servers arbitrarily and not if only the first was down. So pihole is totally USELESS if you have only one instance. For a mobile device, where ads are much more penetrating, I discovered the fantastic android option of "Private DNS". It forces ALL traffic through it. I inserted a free ad blocking DNS server which works though DoH (thank you controld) and all companies are ditched. On the desktop ublock guards the browser. Better a company to know some sites I visit than dozens to penetrate my digital life.
1vuio0pswjnm7 1y ago
"Adversaries critic that all DNS queries are directed to single DNS provider who becomes the one known peeper." There could be other "peepers", known or unknown, between the DoH provider and each authoritative nameserver. Generally, with no exceptions that I am aware of, the DNS traffic between (a) the third party DNS provider/open resolver/shared cache/DoH provider, and (b) each authoritative nameserver is unencrypted. "It is called DNS over TLS and is specified as a proposed standard in RFC 7858. This provides transport encryption to DNS without abusing HTTP as transport protocol." Same problem as with DoH. Generally, the DNS traffic between (a) the third party DNS provider/open resolver/shared cache/DoT provider, and (b) each authoritative nameserver is unencrypted. "The DNS needs security features that prevent the peepers from reading your DNS traffic. I'm all in for it. But DoH is NOT the answer to this." The only working DNS encryption solution I am aware of is DNSCurve, making it is easy for authoritative nameservers to encrypt their responses. I use DNSCurve via CurveDNS at home on the local network. Originally I was just testing it to see if and how it would break. That was over over 15 years ago. It is still working. I have seen HN commenters with high karma try to discredit DNSCurve. Not because it doesn't work, but because it is not popular. There are few DNSCurve-protected authoritative nameservers on the internet. Meanwhile the most popular encryption that is used for HTTPS, including DoH, is from the same author as DNSCurve. Pay no mind. As a proof of concept, I have thought about starting a DNS registry that requires registrants to offer DNSCurve-encrypted responses from their authoritative nameservers. DoH has commercial motives. It is based on (yet) another weird Silicon Valley definition of "privacy". Nevertheless, I have managed to find good uses for it. For example, it allows for bulk DNS retrieval via HTTP/1.1 pipelining. It can also be useful when hotel-provided internet service is intercepting DNS. IMHO, DoH is an option that is useful to have. This is not to say I would rely on it. Perhaps I'm generally OK with DoH because I do not use remote DNS. I stopped letting applications use remote DNS before DoH was introduced. I now use a forward proxy with all name-to-IP mappings stored in memory. DNS queries only travel over the loopback to own authoritative servers and generally all RRs point to the loopback address of the proxy. DoH is useful as a source of DNS data retrieved in bulk from various providers. It is not the only source I use. Arguably the debate over DNS encryption is moot because domainnames appear in plaintext on the wire anyway, via the TLS "Server Name Indication" (SNI) extension.^1 TLS has become extremely popular. The extension mainly serves the needs of CDNs. The proposed Band-Aid for the harmful effects of SNI, put forth by the CDNs (i.e., the source of the problem), is known as "ECH". It is not popular. ECH coverage is narrow. One might be able to use ECH with a specific browser and version and a Cloudflare website.^2 For the rest of the myriad software that use TLS, and the rest of the www not accessible via Cloudflare's CDN, including other major CDNs and millions of websites not hosted on major CDNs, all bets are off. The famous "example.com" certainly supports TLS. It does not support ECH. Neither does news.ycombinator.com 1. Test: https://github.com/kontaxis/snidump https://github.com/kontaxis/snidump 2. Test: https://test.defo.ie https://test.defo.ie
esbeeb 1y ago
DoH is the enemy of all self-hosters. When port 443 is used, you can't discriminate on it - to perhaps monitor it, work towards debugging it, block it, re-route it, etc. DNS shouldn't be a stow-away within some other protocol like HTTP, hiding from network-level scrutiny and control. DoT is the friend of all self-hosters. Self-hosters need to control their own DNS if they want to use SSL within their LANs, within their self-hosted VPNs, and within their own self-hosted VPN subnets especially (I use Wireguard subnets a lot). Secure DNS with TLS, sure, but this control-ability, at the port level (853), is what a self-hoster needs to keep their life sane.

154 points by Bogdanp 1y ago

Personally, I prefer DNSCrypt over DoH or DoT (and run my own DNSCrypt servers), but I see no problem with DoH. It's certainly an improvement over unencrypted DNS.

ggm 1y ago

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.

throwaway81523 1y ago
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.
- tialaramex 1y ago
  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.
  - KwanEsq 1y ago
    Couldn't you just make my-private-server.vanity-domain.example a manual /etc/hosts entry to prevent advertising it?
    - kvdveer 1y ago
      You could. You'd only have the ability to log in from your own machine though. If that compromise works is very much dependent on your situation.
      - throwaway81523 1y ago
        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.
        NewJazz 1y ago
        At that point don't open port 22 to the internet, just set up wireguard or tailscale.
    - hk1337 1y ago
      Just as easy, you could just set the Host in your ssh config. Then you don’t have to deal with dns
  - miyuru 1y ago
    For a real world example, I use IPv6 only SSH+public DNS and my fail2ban has 2 fails for a uptime with 285 days.
j0057 1y ago
I agree that sooner or later your SSH port will end up on Shodan anyway. Putting SSH behind a Wireguard VPN solves this completely.
mhitza 1y ago
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.
- ignoramous 1y ago
  If privacy is your concern then dns0.eu is not "no logs" (like BlahDNS or Mullvad DoH/DoT are, for example). They share "anonymized intelligence feeds" with their partners: https://docs.dns0.eu/threat-intelligence-partners/anonymized-query-logs https://docs.dns0.eu/threat-intelligence-partners/anonymized...
  - mhitza 1y ago
    Thank you for the heads-up. That's an important point, and I wasn't aware about that feature. In terms of privacy, they still preserve it (according to GDPR principles).
btasker 1y ago
> 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.

deknos 1y ago

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..

crabique 1y ago
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.
btasker 1y ago
Yes. 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)

creata 1y ago

The points here aren't technically wrong, but it still feels like disabling DoH would be a reduction in security. For example: > 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.

archerx 1y ago
> That's true, but Cloudflare is more trustworthy than my ISP, and probably most people's ISPs. Based on what?
- ignoramous 1y ago
  > 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-resolver-firefox/ https://developers.cloudflare.com/1.1.1.1/privacy/cloudflare...
pacifika 1y ago
In the UK you can typically pick from a dozen ISPs, some of which are more trustworthy
- ortichic 1y ago
  Can you also choose which company provides the physical infrastructure that connects to your home?
  - tialaramex 1y ago

drykiss 1y ago

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?

jedisct1 1y ago

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.

josephcsible 1y ago
Oblivious DoH would be fine, but isn't anonymized DNSCrypt distinguishable on the wire from HTTPS even though it's over port 443?
issafram 1y ago
Are there any guides on how to set this up? I'm currently using pi-hole configured to use DoT through Cloudflare.

sudahtigabulan 1y ago

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.

rainsford 1y ago
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.

throawayonthe 1y ago

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 [0] like https://www.quad9.net https://www.quad9.net

xrmagnum 1y ago

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.

WhyNotHugo 1y ago
Disabling DoH in your browser’s settings should make it fall back to you system’s resolver. You’ll only be vulnerable to a MitM attack if your system’s resolver is insecure and also vulnerable to a MitM attack.
- sammy2255 1y ago
  (which all are by default)
  - NewJazz 1y ago
    No, plenty of OSs ship encrypted DNS resolvers by default.
    - josephcsible 1y ago
      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.
  - WhyNotHugo 1y ago
    That's a pretty serious security issue, which affects every other process on your host.
1y ago

om8 1y ago

I trust cloudflare more than my ISP, since I live in a place where internet is very state controlled. Some of the websites just don't open without DoH.

josephcsible 1y ago
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.

elashri 1y ago

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.

btasker 1y ago
> The author also make it feel like the only option is to use cloudflare DoH on Firefox In fairness, the date on the post is 2018 - when Firefox first launched this, Cloudflare was the only option
- elashri 1y ago
  Now that makes more sense regarding this point. I missed the date. I think the submission title needs (2018).
- rainsford 1y ago
  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.
- josephcsible 1y ago
  Even back then, wasn't Cloudflare just the only listed option? Couldn't you still have manually entered a different DoH server that you knew of?

tester756 1y ago

wtf is this? >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?

spiffyk 1y ago

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?

josephcsible 1y ago
> 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.
- spiffyk 1y ago
  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.

arbll 1y ago

Ah yes I'm going to disable DoH and go from trusting a central entity to trusting another central entity and everyone else on the wire. Article is a bunch of strong opinion with nothing to back them.

exiguus 1y ago

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.

c0l0 1y ago
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.
- victorbjorklund 1y ago
  Are there any security risks with sharing it wiyh others?
  - c0l0 1y ago
    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. [0]: https://en.wikipedia.org/wiki/DNS_spoofing#Cache_poisoning_attacks https://en.wikipedia.org/wiki/DNS_spoofing#Cache_poisoning_a...

creatonez 1y ago

DNSCrypt has a list of DoH and ODoH resolvers other than Cloudflare: https://github.com/DNSCrypt/dnscrypt-resolvers https://github.com/DNSCrypt/dnscrypt-resolvers

a022311 1y ago

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?) [1] https://github.com/semihalev/sdns https://github.com/semihalev/sdns

rainsford 1y ago
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.
- a022311 1y ago
  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.
  - tptacek 1y ago
    DNSSEC doesn't do anything to prevent DNS-level censorship, and DoT is easier to block than DoH --- that's why there's DoH in the first place.

dev_l1x_be 1y ago

Two raspberries with Adguard combined with Tailscale is pretty safe and removes a nice chunk of garbage from the internet https://adguard-dns.io/en/welcome.html https://adguard-dns.io/en/welcome.html

leosanchez 1y ago
Why two ? For redundancy or am I missing anything?
- dev_l1x_be 1y ago
  Redundancy

jchw 1y ago

This is a very strange article. 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.

dabacaba 1y ago

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.

jsiepkes 1y ago
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.
- unethical_ban 1y ago
  A decent corporate policy will block or decrypt DoH, same as it blocks direct outbound DNS.
  - josephcsible 1y ago
    The hope is we eventually get enough things like DoH and ECH that it stops being feasible for corporate policies to block things.
    - unethical_ban 1y ago
      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.
      - josephcsible 1y ago
        > 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.

ddtaylor 1y ago

DoH is problematic in other ways too. 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.

EbNar 1y ago
How is that? It's just a switch, as in any other Chromium browser.
- ddtaylor 1y ago
  https://github.com/brave/brave-browser/issues/39028 https://github.com/brave/brave-browser/issues/39028
  - josephcsible 1y ago
    What does that have to do with DoH?
    - ddtaylor 1y ago
      It's an example of how Brave will not respect the configurations given because it still attempts to use DoH.
      - EbNar 1y ago
        It works fine on my end, checked a lot of times with https://dnscheck.tools https://dnscheck.tools. 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.
  - tredre3 1y ago
    None of that thread seems to be related to DoH, though? More likely a caching issue.

toomim 1y ago

You can solve the problems with DoH by using OHAI: https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-oha...

thr0w 1y ago

With DNS over UDP, you have plausible deniability that you didn't actually make the request. With DNS over HTTP(S), you don't. 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.

lokar 1y ago
By claiming src spoofing?

ahmetozer 1y ago

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

theamk 1y ago

Not a very coherent article. .. is author's problem privacy or security? 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.

orbital-decay 1y ago

The tone is pretty manipulative and sounds like a weird FUD. >DoH is not about protecting your DNS queries from peepers. That is a big lie. It is about making sure only one peeper can see all of your queries. How is this a lie? It does protect your queries from MitM. I doubt anyone ever said anything about protecting from everyone - either you keep a synced copy of the entire DNS database (or its part) locally, or send your query to someone else's computer. How else do you expect it to work? >Refuse to use it today "Refuse"? Why??? >Is there an alternative way? Yes, there is. It is called DNS over TLS How does this eliminate the single peeper? You're still sending your query to someone else's computer. DoT encrypts, so it must be a good thing, right?

api 1y ago

I have blocked outbound raw DNS on my home LAN in favor of DoH from a pi hole.

dec0dedab0de 1y ago

i want to be able to man in the middle anything that phones home.

josephcsible 1y ago
If they're your own devices, sure. But without DoH, it would be possible to man-in-the-middle other people's devices too, and you shouldn't be able to do that.
throwaway290 1y ago
How do you deal with pinning which most apps do now?
- dec0dedab0de 1y ago
  i hate it. hsts mixed with doh exist to take control, and transparency away from users, because most users never knew they had the option to begin with.

conradev 1y ago

Is there an alternative way? Yes, there is. It is called DNS over TLS and is specified as a proposed standard in RFC 7858. This provides transport encryption to DNS without abusing HTTP as transport protocol. HTTP/3 is a full VPN protocol via MASQUE. I don’t understand how DNS over TLS is anything but slightly less convenient and otherwise no different than DNS over HTTP.

mixdup 1y ago

Is DoH a bad idea because Cloudflare sees your queries or you're overloading HTTP as a protocol? This article seems to be advocating two different things At the end of the day, if your problem is you don't trust the DNS provider to also be snooping, no flavor of encrypted DNS will solve it. Whoever lands the DNS query will be able to snoop whether it's TLS or DoH

Mister_Snuggles 1y ago

The thing that bothers me most about DoH is that it moves the responsibility for name resolution from the operating system to each application. So now you don't have the ability to set up your own DNS server system-wide, you need to do it per-application and per-device. Assuming, of course, that the applications and devices in question allow you to do this and/or respect your choice when you do it. Also shoving every protocol under the sun into HTTPS just feels wrong. I get why it's happening (too many middleware boxes and ISPs think internet == web). But shouldn't we fix the ISPs and middleware instead of endlessly working around it?

mlhpdx 1y ago
Yes, but it won’t be easy. Heavy investment has gone into HTTP and we have great tooling and support for it as a result. That has a lot of benefits and I’m glad for it. But there is a cost. HTTP is a blunt hammer and computing sometimes needs a scalpel. Lighter, more efficient protocols are important, as QUIC and WireGuard have proven.
- Mister_Snuggles 1y ago
  To play devil's advocate, shoving everything into HTTP/HTTPS also allowed a ton of innovation. Would video streaming sites (Youtube, Vimeo, etc) ever have gotten off the ground if they had to go to IANA to get a port number assigned, then wait for browsers to support the new protocol that runs over the new port, etc? Probably not to be honest. Or maybe browsers would just let JavaScript connect to any port, which would be terrifying from a security standpoint. I'm firmly convinced that shoving everything into HTTP/HTTPS was a mistake. But I'm also willing to acknowledge that it's probably the least-worst solution to a bunch of problems.
  - mlhpdx 1y ago
    Absolutely. The investment in HTTP means I can setup a website or API in a few clicks and pay nothing (or nearly so) for it. That has made it possible for me to try many, many things over the years. It’s fabulous. I would very much like to see that same freedom to innovate when using other protocols.

yegle 1y ago

I don't understand any of the arguments. Why mentioning DNS-over-TLS if you are against DNS-over-HTTPS? They have all the same "downside". What's wrong with one less peeper (your ISP)? You _have_ to use a DNS server unless you use something fancy like dnsmasq to round-robin between multiple DNS servers (but your ISP can still see everything) Besides, you can run your own DoH server with ease, you don't have to use Cloudflare's.

josephcsible 1y ago

This article is totally wrong. I'm not sure how it got so much traction. Details: > But slowly people started to realize what the collaboration between Mozilla and Cloudflare really means: Cloudflare gets all your DNS queries. There are a lot of DoH providers other than Cloudflare. https://github.com/curl/curl/wiki/DNS-over-HTTPS https://github.com/curl/curl/wiki/DNS-over-HTTPS lists several. If you don't want Cloudflare seeing your DNS requests, then use one of them instead. (And even for users who do just stick with the default, I think it's better privacy-wise for Cloudflare to see that data than for the average American ISP to.) > Yes, there is. It is called DNS over TLS and is specified as a proposed standard in RFC 7858. This provides transport encryption to DNS without abusing HTTP as transport protocol. The only difference between DoT and DoH is that DoT is easier to block and force fallback to totally insecure DNS. There's no reason to ever use DoT if you can use DoH. (And I don't get why the author likes it better: whoever runs the DoT server gets the exact same data that they'd get with a DoH server instead.) > No, it is not. Abusing HTTP as a transport protocol for DNS data adds a unneeded complexity to the protocol. You must add a HTTP module to all DNS servers or interact with a separated HTTP server on the same system in order to support DoH. That is a lot of code which can contain a lot of bugs and security flaws. Complexity is the enemy of security. The extra complexity of HTTP is massively outweighed by the significant reduction in fallbacks to insecure DNS.

AnthonyMouse 1y ago
> If you don't want Cloudflare seeing your DNS requests, then use one of them instead. Normal people have no idea that this even exists, much less how to do it, so they're still having all their queries routed to Cloudflare by default. > The only difference between DoT and DoH is that DoT is easier to block and force fallback to totally insecure DNS. A normal middlebox can't even tell the difference between DoH and DoT because they both just look like TLS. A corporate one that requires you to install certificates on the client so that it can, is just as able to block DoH as DoT. And fallback isn't required in either case. If some network is blocking encrypted DNS, the client device can be configured to fail rather than use the insecure DNS, at which point the user knows that the network is adversarial and can switch to a VPN or a cellular connection etc.

juliangmp 1y ago

>Refuse to use it today That's genuinely awful advice. Besides the fact that there are other DNS providers that can do DNS over HTTPS, disabling it just makes things worse. - you still fire all of your DNS requests to a single host (whether that's cloudflare or any other) - you also do it in clear text

finalhacker 1y ago

DOH is a protection for your privacy from ISP. Actually you can set multi DOH server with load balance to avoid your dns info concentrately collected by one dns provider.

KingLancelot 1y ago

[dead]

exabrial 1y ago

DNS over HTTPS exclusively exists because stuff like Pi-hole started eating into Ad Revenue for Google. That's why this "feature" is so hard to disable in the browsers as well. I hope they're forced to divest from Android and Chrome. It's absolute anti-consumer garbage. DNSCurve exists and was a far better solution, but that in turn... you know cut into ISP spying as well.

nobody9999 1y ago
>DNS over HTTPS exclusively exists because stuff like Pi-hole started eating into Ad Revenue for Google. That's why this "feature" is so hard to disable in the browsers as well. Exactly. Which is why I point my Pi-Hole at my own recursive resolver. Can my ISP see those queries? Sure. Are they using transparent proxies to redirect my queries to their resolvers? No. Is my ISP cataloguing all my recursive resolutions? Maybe. But probably not. Theoretically, they could, but mirroring all the traffic to storage for tens of millions of customers seems exorbitant, unnecessary and wasteful. More likely, I'd expect that at some point (likely the router interface at my local head-end), they use Netflow[0] and/or something similar, to characterize the IP-based traffic being transmitted through it. The collected data wouldn't contain the DNS queries themselves, so my ISP would need to rely on just the Netflow data. And while it is possible for ISPs to correlate DNS queries to Netflow streams[1][2], using a recursive resolver rather than their resolver makes it more cumbersome for them (or Cloudflare, or Google, etc.) to do so. Regardless, I'd much prefer that my recursive resolver use encrypted communications, not so much between it and the root servers, but between it and authoritative servers. The former would be nice, but depending on the encryption overhead (TLS or even just TCP connections to the root servers would require significant extra resources), likely impractical. >DNSCurve exists and was a far better solution Is there any recent activity WRT that protocol? I found some stuff from at least a decade ago. The IETF's DNS Private Exchange[3] (dpriv) working group has a few interesting things, but it sure would be nice to have the DNS equivalent of smtp's 'starttls'[5] feature, perhaps ala RFC9539[4]? Perhaps one day there will be mainstream support for that. What I do works for my use case, but likely isn't workable for many (most?) other folks. [0] https://en.wikipedia.org/wiki/NetFlow https://en.wikipedia.org/wiki/NetFlow [1] https://arxiv.org/pdf/2211.05682 https://arxiv.org/pdf/2211.05682 [2] https://github.com/maganiss/FlowDNS https://github.com/maganiss/FlowDNS [3] https://datatracker.ietf.org/wg/dprive/documents/ https://datatracker.ietf.org/wg/dprive/documents/ [4] https://www.rfc-editor.org/rfc/rfc9539.txt https://www.rfc-editor.org/rfc/rfc9539.txt [5] https://en.wikipedia.org/wiki/Opportunistic_TLS https://en.wikipedia.org/wiki/Opportunistic_TLS

aborsy 1y ago

Part of the reason I let Tailscale up even if I don’t need connectivity is DoH. It can send DNS in all devices encrypted to a public or private DNS server. It can force this by overriding client configuration if desired.

tsoukase 1y ago

Marginally offtopic: DNS filtering was tricky for me. I setup a pihole instance with secondary DNS a regular 8s. But the router accessed both servers arbitrarily and not if only the first was down. So pihole is totally USELESS if you have only one instance. For a mobile device, where ads are much more penetrating, I discovered the fantastic android option of "Private DNS". It forces ALL traffic through it. I inserted a free ad blocking DNS server which works though DoH (thank you controld) and all companies are ditched. On the desktop ublock guards the browser. Better a company to know some sites I visit than dozens to penetrate my digital life.

1vuio0pswjnm7 1y ago

"Adversaries critic that all DNS queries are directed to single DNS provider who becomes the one known peeper." There could be other "peepers", known or unknown, between the DoH provider and each authoritative nameserver. Generally, with no exceptions that I am aware of, the DNS traffic between (a) the third party DNS provider/open resolver/shared cache/DoH provider, and (b) each authoritative nameserver is unencrypted. "It is called DNS over TLS and is specified as a proposed standard in RFC 7858. This provides transport encryption to DNS without abusing HTTP as transport protocol." Same problem as with DoH. Generally, the DNS traffic between (a) the third party DNS provider/open resolver/shared cache/DoT provider, and (b) each authoritative nameserver is unencrypted. "The DNS needs security features that prevent the peepers from reading your DNS traffic. I'm all in for it. But DoH is NOT the answer to this." The only working DNS encryption solution I am aware of is DNSCurve, making it is easy for authoritative nameservers to encrypt their responses. I use DNSCurve via CurveDNS at home on the local network. Originally I was just testing it to see if and how it would break. That was over over 15 years ago. It is still working. I have seen HN commenters with high karma try to discredit DNSCurve. Not because it doesn't work, but because it is not popular. There are few DNSCurve-protected authoritative nameservers on the internet. Meanwhile the most popular encryption that is used for HTTPS, including DoH, is from the same author as DNSCurve. Pay no mind. As a proof of concept, I have thought about starting a DNS registry that requires registrants to offer DNSCurve-encrypted responses from their authoritative nameservers. DoH has commercial motives. It is based on (yet) another weird Silicon Valley definition of "privacy". Nevertheless, I have managed to find good uses for it. For example, it allows for bulk DNS retrieval via HTTP/1.1 pipelining. It can also be useful when hotel-provided internet service is intercepting DNS. IMHO, DoH is an option that is useful to have. This is not to say I would rely on it. Perhaps I'm generally OK with DoH because I do not use remote DNS. I stopped letting applications use remote DNS before DoH was introduced. I now use a forward proxy with all name-to-IP mappings stored in memory. DNS queries only travel over the loopback to own authoritative servers and generally all RRs point to the loopback address of the proxy. DoH is useful as a source of DNS data retrieved in bulk from various providers. It is not the only source I use. Arguably the debate over DNS encryption is moot because domainnames appear in plaintext on the wire anyway, via the TLS "Server Name Indication" (SNI) extension.^1 TLS has become extremely popular. The extension mainly serves the needs of CDNs. The proposed Band-Aid for the harmful effects of SNI, put forth by the CDNs (i.e., the source of the problem), is known as "ECH". It is not popular. ECH coverage is narrow. One might be able to use ECH with a specific browser and version and a Cloudflare website.^2 For the rest of the myriad software that use TLS, and the rest of the www not accessible via Cloudflare's CDN, including other major CDNs and millions of websites not hosted on major CDNs, all bets are off. The famous "example.com" certainly supports TLS. It does not support ECH. Neither does news.ycombinator.com 1. Test: https://github.com/kontaxis/snidump https://github.com/kontaxis/snidump 2. Test: https://test.defo.ie https://test.defo.ie

esbeeb 1y ago

DoH is the enemy of all self-hosters. When port 443 is used, you can't discriminate on it - to perhaps monitor it, work towards debugging it, block it, re-route it, etc. DNS shouldn't be a stow-away within some other protocol like HTTP, hiding from network-level scrutiny and control. DoT is the friend of all self-hosters. Self-hosters need to control their own DNS if they want to use SSL within their LANs, within their self-hosted VPNs, and within their own self-hosted VPN subnets especially (I use Wireguard subnets a lot). Secure DNS with TLS, sure, but this control-ability, at the port level (853), is what a self-hoster needs to keep their life sane.