6 ms·

DNS over HTTPS is a trojan horse to allow application developers to subvert the system administrator's DNS policy. Specifically, so that companies like Google,

DNS over HTTPS is a trojan horse to allow application developers to subvert the system administrator's DNS policy. Specifically, so that companies like Google, Microsoft, Amazon can ensure that you cannot prevent ads being displayed in their little black boxes (hardware or software). This is dangerous, anti-user, and should be avoided at all costs. DNS over TLS is the correct and appropriate solution here. You can ensure your (Firefox) browser does not use DNS over HTTPS by configuring a canary domain: https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet https://support.mozilla.org/en-US/kb/canary-domain-use-appli... but let's be clear here, nobody besides Firefox is going to respect user choice about using DoH.

jeroenhd 5y ago
DoH and DoT both hide DNS requests from the sysadmins. If the sysadmins want to capture DNS for some reason, they can just provision their own DoH server (I do that with my Pihole) or disable the feature all together with a simple canary domain (https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https https://support.mozilla.org/en-US/kb/configuring-networks-di...) in the local DNS resolver. Although I hate the idea that everything must now be layered on top of HTTPS because shitty middleboxes can't deal with internet protocols, I think Oblivious DOH is superior to simple DoT. It not only provides security, but also anonymity in DNS requests. I'm not sure if that's what Firefox actually implements by default, though.
- jeena 5y ago
  So how do you deal with what the parent mentioned that Chromecast will stop using your piholes DNS and just always go directly to Googles?
  - jeroenhd 5y ago
    Chromecast doesn't respect any settings and only communicates over TLS (and some local broadcast protocols for compatibility). If you don't like that, don't buy a Chromecast. I've managed to get it to use my PiHole by forwarding all outbound traffic to UDP/53 that's not coming from my PiHole to the PiHole itself through a DNAT rule in Firehol: ipv4 dnat to "${pihole4}" proto udp dport 53 src not "${pihole4}" dst not "${pihole4}" inface not "${world}" ipv6 dnat to "${pihole6}" proto udp dport 53 src not "${pihole6}" dst not "${pihole6}" inface not "${world}" So far, I haven't seen any weird traffic that's trying to bypass this rule, but honestly, I don't really care. Whenever I block any of its domains I just get weird error messages about connectivity problems, or a non-working Chromecast. The real meat is inside the TLS connection anyway, and I can't block that. You can't buy a closed-source, always-online Google product and expect it to let you block it. If I wanted that, I would've disconnected it from the internet or just used a Kodi box instead. We've lost to ability to introspect and filter connections the moment we started switching to TLS. If you don't trust a device, don't install it in your network, that's my take.
    - mobiuscog 5y ago
      I have an LG SoundBar and a couple of other IoT devices that do the same. I have a similar setup on pfsense as you do on FireHol. The correct answer is not to support hardware that does this, in the future.
  - deleted 5y ago
    [deleted]
  - Gigachad 5y ago
    The chromecast is proprietary anti user software/hardware. Stallman has been warning about this for decades. DoH has very little to do with this. The Chromecast could hardcode the Google dns server already.
    - yjftsjthsd-h 5y ago
      > The Chromecast could hardcode the Google dns server already. Could nothing; Chromecasts have always hardcoded Google DNS AFAIK. This is a right pain when you want them to stream something from an internal site that has a perfectly good DNS entry but not a public DNS record, and we ended up casting things that used raw IPs because of it. I've also seen some people end up having their router rewrite packets from 8.8.8.8 to their own DNS, but that might actually be more icky IMO.
      - vetinari 5y ago
        > I've also seen some people end up having their router rewrite packets from 8.8.8.8 to their own DNS, but that might actually be more icky IMO. It is actually very simple, just dst-nat everything destined for any ip, 53/udp, 53/tcp, to your resolver, except traffic originated by the resolver itself. Works very well.
    - josephcsible 5y ago
      > The Chromecast could hardcode the Google dns server already. This wouldn't work, because routers/firewalls can easily rewrite the destination of insecure DNS queries. But what it could do is to hardcode all of the IPs of the servers it really wanted to talk to, instead of using DNS at all.
      - tptacek 5y ago
        It doesn't need to use DNS at all. As long as it can rendezvous through some IP, it can just tunnel all of it's discovery stuff through TLS, or anything else it wants. This is a particularly silly cat-and-mouse game that network pentesters have been winning for decades; it's only because DNS people had a strange heyday as botnet hunters, and botnet authors are really dumb, that this folk wisdom about the importance of DNS policy set in so firmly.
- throw0101a 5y ago
  > DoH and DoT both hide DNS requests from the sysadmins. DoT at least uses a separate port which the network owner can block just like it can block outgoing connections for SMTP (tcp/25).
  - josephcsible 5y ago
    Which is a big downside of DoT and reason to prefer DoH. The people that have an easier time blocking DoT are the very people who are the reason that you'd want to use it in the first place.
    - throw0101a 5y ago
      As a sysadmin who is in charge of network security, at work and at home, I disagree.
creatonez 5y ago
This is FUD. This possibility has nothing to do with HTTP vs. [some other DNS-like protocol] sitting on top of an encrypted connection. This possibility is, however, enabled by having the application package its own DNS resolution. It's unfortunate that more and more software is doing this with no way to opt out (Chromecast and Nintendo Switch are the worst offenders) -- but the way firefox does it, it is opt-out. I think it's a double edged sword; having in-application DNS as an option has an important advantage of subverting malware as well as public wifi networks configured for surveillance. In an ideal world, we don't have to "subvert malware", but we live in a world where a big chunk of users have some sort of malware installed or in their general proximity. If you want to use DNS over HTTPS as a system-wide daemon, you can use DNSCrypt 2 (https://dnscrypt.info/ https://dnscrypt.info/ ) and disable DoH within Firefox/Chrome.
- _jal 5y ago
  Software that does its own resolution will not run on my network, and we have banned it by policy at work. Of course it becomes another game of whack-a-mole. My house, my rules; you don't get to subvert my network security and continue to use my network.
  - creatonez 5y ago
    Right, and the feature is not designed for you. It's designed for the billions of users who are not on your network, and are sitting in their own home or in a coffee shop where there is no such security policy or skilled network administrator in sight. Aside: If you are using Firefox in an enterprise environment, you should be locking the settings to begin with. If I remember correctly, the Firefox ESR downloads don't even prompt about enabling DoH.
  - jeroenhd 5y ago
    That's a perfectly acceptable policy to have, but you'll have to check and monitor that policy like you always have. You can add an A/AAAA record for use-application-dns.net and Firefox won't turn on DoH on your network unless the user overrides it. Chrome's DoH model will use your existing DNS server: if it supports DoH, Chrome switches to DoH, otherwise it'll stick to normal DNS. Do note that malware and even legitimate software (some Android apps, some Windows applications) have been using HTTP(S) based domain lookups for years, though, years before DoH was even proposed. I've used free HTTP proxies over fifteen years ago to bypass school filters, for one, and that's without any infrastructure of my own! You'll have to configure an intercepting proxy to exclusively allow traffic through if you want to catch problematic software in the act, and add some pretty sophisticated filtering. With the modern take on inserting your own certificate authority (certificate pinning, unrooted Android, NodeJS, etc. all avoiding your user certificate store) you'll have to go through great lengths to get that working, though. Truth be told, DNS was never really much of a security measure if you don't have control over what applications do or do not use it.
deleted 5y ago
[deleted]
tptacek 5y ago
The only functional difference between DoT and DoH is that it's easy for ISPs to block DoT.
- bluejekyll 5y ago
  This is one of my concerns with DoQ (DNS-over-QUIC). Currently DoQ is designated to be on port 853, like DoT, but DoH is great because it's not easily distinguished from other traffic on 443. But, DoQ is a much better protocol so I hope that there is a resolution here, which I'm guessing will be the same as HTTP/3, so we'll see. Maybe in the end it will be the same as DoH.
  - ekr____ 5y ago
    I don't know for sure how the Fx stack presently behaves, but I would expect that eventually it would do DoH/3 if the server provided the appropriate indications (e.g., Alt-Svc).
  - zamadatix 5y ago
    The DoQ RFC is working on and explicitly setting aside provisions for automatic discovery of alternative ports for the port 443 "blend-in" use case. The designated port is just there for having a standard number to use when admins don't want to have to multiplex everything over UDP 443.
- jeroenhd 5y ago
  It's not exactly difficult to block 8.8.8.8:443 and 1.1.1.1:443 if ISPs want to block it. There's also no technical reason why DoT should use port 853 even if it's the default; using 443 will work with most clients I've tested, although shitty middleboxes might get confused about the protocol not being HTTPS.
  - tptacek 5y ago
    This isn't my analysis; I stole it from Paul Vixie. That many networks tend to block 853/tcp and not 443/tcp is, literally, a feature of DoT, not a bug.
viraptor 5y ago
If you know how to manage your DNS policy, you know how to turn off DoH or at least how to learn about it. Especially if you're an administrator. I may want to run my own DoH endpoint, which is very much pro-user in that case.
Cupprum 5y ago
> but let's be clear here, nobody besides Firefox is going to respect user choice about using DoH. I strongly feel like Brave would also respect users choices, even though they made some mistakes in the past.
charcircuit 5y ago
If operating systems weren't so slow in adopting DoH Firefox wouldn't have to ship it themselves.
bscphil 5y ago
This is sort of like claiming that the spread of encryption is bad and dangerous because it provides tools to terrorists. The problem with the claim is that even if every person or organization producing end-user software stopped developing or supporting DoH, the cat is fully out of the bag. It's just technology at the end of the day, and any company making hardware that wants to hide their DNS requests is completely able to do so already. Some are even building VPNs into their IOT devices. This can't be stopped; ending development on uses of the technology that do benefit the end user is not just pointless but actively a bad idea. There's also a weird conflation that happens between the claim that DoH is "anti-user" and that DoH is "anti-sysadmin". These are two completely different things. If you're a sysadmin who wants to provide a useful DNS service with some additional features on your domain / network, DoH makes it harder for you to do that. I fully agree with this point, and in fact it's a pain point for me because I run Unbound on my router myself! However, this is completely different from the claim that it's "anti-user". Most people do not have friendly local competent admins setting up DNS for them. Those who do are given the choice to opt out of DoH by changing their settings in e.g. Firefox. For other users, DoH is a massive security win. It absolutely makes sense for it to be the default. Anti-admin != anti-user.
- Gigachad 5y ago
  The hacker news hysteria over DoH is quite absurd and disappointing. Seeing comments massively exaggerate to downright lie about the situation because they are angry their pihole setup no longer works. Imo Firefox is representing the users best interests here. The router, and ISP dns servers can not be trusted. The user wants their browsing session to be as private as possible. Cutting out one more source of data leakage is what the user wants.
  - johnklos 5y ago
    Go ahead and give us evidence about how Cloudflare can be trusted. At least we have legally binding contracts with our ISPs. Also, are you trying to suggest that people who know enough to run Piholes don't know enough to run their own DNS servers (or at least select good ones) and their own routers? That's pretty rich.
easrng 5y ago
DNS over HTTPS is useful tool that gives users agency instead of being subjected to the system administrator's DNS policy. It means that in many cases I don't need to use Tor or a VPN to get around network blocks, except on networks with Fortinet. Fortinet even tries to block Tor, but I made a little tool[1] that tunnels BridgeDB requests over docs.google.com so I don't need to worry about that anymore. [1]: data:text/html,<script>google={visualization:{Query:{setResponse:o=>document.write(atob(o.table.rows.map(e=>e.c[0].v).join("")))}}}</script><script src="https://docs.google.com/spreadsheets/d/1SOK9rEPrVLId1NR4KM-mgDO7tlmRk2K5nNi0tv-9gCY/gviz/tq?tqx=out:json"></script>
- easrng 5y ago
  For example, my school laptop had Cisco Umbrella forcing DNS connections to itself, but half the time it never responded. Firefox DoH still worked because it didn't rely on the system DNS setting, which needs admin perms to change. Eventually I fixed the problem entirely by escalating to admin with PrintNightmare and deleting Cisco Umbrella altogether.
- freedomben 5y ago
  As a user it's pretty easy to ignore the DNS settings in DHCP and use whatever you want. An aggressive network admin can identify packets headed to outbound 53 on tcp/udp and block them (or reroute them to the preferred DNS) but they could also block known DoH endpoints. As soon as enterprises realize that DoH is happening, they will definitely do that.
  - easrng 5y ago
    But sometimes you're on a device where you can run binaries but don't have admin access. Firefox lets you use a custom DoH server regardless of the DNS settings set by the admin.
    - jeroenhd 5y ago
      If your admin has set up the necessary policies, you won't be able to configure a custom DoH server in Firefox either! That doesn't work for personal devices, of course, but DoH is explicitly not intended to work around system administrators' configuration.
josephcsible 5y ago
> DNS over HTTPS is a trojan horse to allow application developers to subvert the system administrator's DNS policy. No, it's a very important tool to help users bypass censorship and surveillance performed by hostile network operators. > Specifically, so that companies like Google, Microsoft, Amazon can ensure that you cannot prevent ads being displayed in their little black boxes (hardware or software). They don't need DoH to do this. They can do this by either hardcoding the IPs of their ad servers, or by serving their ads from the same hosts as the content you want. > This is dangerous, anti-user, and should be avoided at all costs. No, it's very pro-user and should be used at all costs. > DNS over TLS is the correct and appropriate solution here. No, because that's too easy for the aforementioned hostile network operators to block. > You can ensure your (Firefox) browser does not use DNS over HTTPS by configuring a canary domain: https://support.mozilla.org/en-US/kb/canary-domain-use-appli https://support.mozilla.org/en-US/kb/canary-domain-use-appli... This is a misfeature that needs to go away. Thankfully, Firefox has an override that lets you manually enable DoH even if a hostile network operator configures that. > but let's be clear here, nobody besides Firefox is going to respect user choice about using DoH. Correct, but not in the way you meant. Most operating systems and programs will never use DoH even if the user does want it.
- inetknght 5y ago
  > Most operating systems and programs will never use DoH even if the user does want it. Let Mozilla publish their DNS server addresses then. Let Mozilla (or anyone, it's open source) write a DoH module for pihole. Problem ~~solved~~ deferred.
  - jeroenhd 5y ago
    I'm running https://crates.io/crates/doh-proxy https://crates.io/crates/doh-proxy on my Pihole for DoH access (with an nginx frontend for TLS, though that's not necessary of course). You can just plug it into Firefox and it'll work. With nginx in front you can put a stream {} block to proxy pi.hole:853/tcp to pi.hole:53 to enable DoT at the same time: stream { server { listen 853 ssl; proxy_pass pi.hole:53; ssl_[...] } } This setup worked great for me with Android, though it doesn't log the requesting device separately anymore (which is why I switched to a DNS server over a WireGuard VPN instead).
drdaeman 5y ago
Yes and no. The problem is different - the problem is application vs OS DNS resolvers. It's not an application job to be a DNS client, this is what actually subverts system administrator policies. Just as if some application has a hardcoded DNS (over UDP) address, but worse because there's encryption and authentication involved, so the system administrator cannot enforce the policy (sans patching the binary or hooking it at runtime). But if DNS over HTTPS is implemented at the system resolver level there is no issue (and the actual transport doesn't matter).
iJohnDoe 5y ago
@denkmoon Thank you for speaking up. There are many things about DOH/DOT that many don’t understand. There are protocol issues, privacy issues, security issues. DNS over TLS should be the natural progression.
- josephcsible 5y ago
  What advantage do you see of DoT over DoH other than that it's easier to block at the network level? If you want to block other people's computers from using DoT or DoH, then you're the adversary that they're meant to protect us from.
  - nobody9999 5y ago
    >What advantage do you see of DoT over DoH other than that it's easier to block at the network level? If you want to block other people's computers from using DoT or DoH, then you're the adversary that they're meant to protect us from. Not GP, but I don't want to block other people's computers. I'm only concerned with my computers. And when one of them gets uppity and tries to bypass the policies on my network, it needs to be smacked down. Hard. As for anyone else's devices? Have at it. Do whatever you want. But my devices on my network will abide by my policies. That may make you wonder if I'm going to try and steal your DNS requests. But don't worry, I won't invite you into my home.
    - josephcsible 5y ago
      > That may make you wonder if I'm going to try and steal your DNS requests. But don't worry, I won't invite you into my home. The problem isn't guests using your house's network. The problem is that if there's a way for you to network-level block DoH at your own house, then nothing is stopping Comcast or China from implementing the same network-level block.
      - nobody9999 5y ago
        >The problem isn't guests using your house's network. The problem is that if there's a way for you to network-level block DoH at your own house, then nothing is stopping Comcast or China from implementing the same network-level block. Fair enough. But I'd posit that you can't prevent a bad actor who controls your network access from doing whatever the hell they please with/on your traffic, whether you use DoH or not[0]. [0] cf. Transparent TLS proxies ( https://en.wikipedia.org/wiki/TLS_termination_proxy https://en.wikipedia.org/wiki/TLS_termination_proxy ) Edit: Changed prose to actually make sense.

jeroenhd 5y ago

DoH and DoT both hide DNS requests from the sysadmins. If the sysadmins want to capture DNS for some reason, they can just provision their own DoH server (I do that with my Pihole) or disable the feature all together with a simple canary domain (https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https https://support.mozilla.org/en-US/kb/configuring-networks-di...) in the local DNS resolver. Although I hate the idea that everything must now be layered on top of HTTPS because shitty middleboxes can't deal with internet protocols, I think Oblivious DOH is superior to simple DoT. It not only provides security, but also anonymity in DNS requests. I'm not sure if that's what Firefox actually implements by default, though.

jeena 5y ago
So how do you deal with what the parent mentioned that Chromecast will stop using your piholes DNS and just always go directly to Googles?
- jeroenhd 5y ago
  Chromecast doesn't respect any settings and only communicates over TLS (and some local broadcast protocols for compatibility). If you don't like that, don't buy a Chromecast. I've managed to get it to use my PiHole by forwarding all outbound traffic to UDP/53 that's not coming from my PiHole to the PiHole itself through a DNAT rule in Firehol: ipv4 dnat to "${pihole4}" proto udp dport 53 src not "${pihole4}" dst not "${pihole4}" inface not "${world}" ipv6 dnat to "${pihole6}" proto udp dport 53 src not "${pihole6}" dst not "${pihole6}" inface not "${world}" So far, I haven't seen any weird traffic that's trying to bypass this rule, but honestly, I don't really care. Whenever I block any of its domains I just get weird error messages about connectivity problems, or a non-working Chromecast. The real meat is inside the TLS connection anyway, and I can't block that. You can't buy a closed-source, always-online Google product and expect it to let you block it. If I wanted that, I would've disconnected it from the internet or just used a Kodi box instead. We've lost to ability to introspect and filter connections the moment we started switching to TLS. If you don't trust a device, don't install it in your network, that's my take.
  - mobiuscog 5y ago
    I have an LG SoundBar and a couple of other IoT devices that do the same. I have a similar setup on pfsense as you do on FireHol. The correct answer is not to support hardware that does this, in the future.
- deleted 5y ago
  [deleted]
- Gigachad 5y ago
  The chromecast is proprietary anti user software/hardware. Stallman has been warning about this for decades. DoH has very little to do with this. The Chromecast could hardcode the Google dns server already.
  - yjftsjthsd-h 5y ago
    > The Chromecast could hardcode the Google dns server already. Could nothing; Chromecasts have always hardcoded Google DNS AFAIK. This is a right pain when you want them to stream something from an internal site that has a perfectly good DNS entry but not a public DNS record, and we ended up casting things that used raw IPs because of it. I've also seen some people end up having their router rewrite packets from 8.8.8.8 to their own DNS, but that might actually be more icky IMO.
    - vetinari 5y ago
      > I've also seen some people end up having their router rewrite packets from 8.8.8.8 to their own DNS, but that might actually be more icky IMO. It is actually very simple, just dst-nat everything destined for any ip, 53/udp, 53/tcp, to your resolver, except traffic originated by the resolver itself. Works very well.
  - josephcsible 5y ago
    > The Chromecast could hardcode the Google dns server already. This wouldn't work, because routers/firewalls can easily rewrite the destination of insecure DNS queries. But what it could do is to hardcode all of the IPs of the servers it really wanted to talk to, instead of using DNS at all.
    - tptacek 5y ago
      It doesn't need to use DNS at all. As long as it can rendezvous through some IP, it can just tunnel all of it's discovery stuff through TLS, or anything else it wants. This is a particularly silly cat-and-mouse game that network pentesters have been winning for decades; it's only because DNS people had a strange heyday as botnet hunters, and botnet authors are really dumb, that this folk wisdom about the importance of DNS policy set in so firmly.
throw0101a 5y ago
> DoH and DoT both hide DNS requests from the sysadmins. DoT at least uses a separate port which the network owner can block just like it can block outgoing connections for SMTP (tcp/25).
- josephcsible 5y ago
  Which is a big downside of DoT and reason to prefer DoH. The people that have an easier time blocking DoT are the very people who are the reason that you'd want to use it in the first place.
  - throw0101a 5y ago
    As a sysadmin who is in charge of network security, at work and at home, I disagree.

creatonez 5y ago

This is FUD. This possibility has nothing to do with HTTP vs. [some other DNS-like protocol] sitting on top of an encrypted connection. This possibility is, however, enabled by having the application package its own DNS resolution. It's unfortunate that more and more software is doing this with no way to opt out (Chromecast and Nintendo Switch are the worst offenders) -- but the way firefox does it, it is opt-out. I think it's a double edged sword; having in-application DNS as an option has an important advantage of subverting malware as well as public wifi networks configured for surveillance. In an ideal world, we don't have to "subvert malware", but we live in a world where a big chunk of users have some sort of malware installed or in their general proximity. If you want to use DNS over HTTPS as a system-wide daemon, you can use DNSCrypt 2 (https://dnscrypt.info/ https://dnscrypt.info/ ) and disable DoH within Firefox/Chrome.

_jal 5y ago
Software that does its own resolution will not run on my network, and we have banned it by policy at work. Of course it becomes another game of whack-a-mole. My house, my rules; you don't get to subvert my network security and continue to use my network.
- creatonez 5y ago
  Right, and the feature is not designed for you. It's designed for the billions of users who are not on your network, and are sitting in their own home or in a coffee shop where there is no such security policy or skilled network administrator in sight. Aside: If you are using Firefox in an enterprise environment, you should be locking the settings to begin with. If I remember correctly, the Firefox ESR downloads don't even prompt about enabling DoH.
- jeroenhd 5y ago
  That's a perfectly acceptable policy to have, but you'll have to check and monitor that policy like you always have. You can add an A/AAAA record for use-application-dns.net and Firefox won't turn on DoH on your network unless the user overrides it. Chrome's DoH model will use your existing DNS server: if it supports DoH, Chrome switches to DoH, otherwise it'll stick to normal DNS. Do note that malware and even legitimate software (some Android apps, some Windows applications) have been using HTTP(S) based domain lookups for years, though, years before DoH was even proposed. I've used free HTTP proxies over fifteen years ago to bypass school filters, for one, and that's without any infrastructure of my own! You'll have to configure an intercepting proxy to exclusively allow traffic through if you want to catch problematic software in the act, and add some pretty sophisticated filtering. With the modern take on inserting your own certificate authority (certificate pinning, unrooted Android, NodeJS, etc. all avoiding your user certificate store) you'll have to go through great lengths to get that working, though. Truth be told, DNS was never really much of a security measure if you don't have control over what applications do or do not use it.

deleted 5y ago

[deleted]

tptacek 5y ago

The only functional difference between DoT and DoH is that it's easy for ISPs to block DoT.

bluejekyll 5y ago
This is one of my concerns with DoQ (DNS-over-QUIC). Currently DoQ is designated to be on port 853, like DoT, but DoH is great because it's not easily distinguished from other traffic on 443. But, DoQ is a much better protocol so I hope that there is a resolution here, which I'm guessing will be the same as HTTP/3, so we'll see. Maybe in the end it will be the same as DoH.
- ekr____ 5y ago
  I don't know for sure how the Fx stack presently behaves, but I would expect that eventually it would do DoH/3 if the server provided the appropriate indications (e.g., Alt-Svc).
- zamadatix 5y ago
  The DoQ RFC is working on and explicitly setting aside provisions for automatic discovery of alternative ports for the port 443 "blend-in" use case. The designated port is just there for having a standard number to use when admins don't want to have to multiplex everything over UDP 443.
jeroenhd 5y ago
It's not exactly difficult to block 8.8.8.8:443 and 1.1.1.1:443 if ISPs want to block it. There's also no technical reason why DoT should use port 853 even if it's the default; using 443 will work with most clients I've tested, although shitty middleboxes might get confused about the protocol not being HTTPS.
- tptacek 5y ago
  This isn't my analysis; I stole it from Paul Vixie. That many networks tend to block 853/tcp and not 443/tcp is, literally, a feature of DoT, not a bug.

viraptor 5y ago

If you know how to manage your DNS policy, you know how to turn off DoH or at least how to learn about it. Especially if you're an administrator. I may want to run my own DoH endpoint, which is very much pro-user in that case.

Cupprum 5y ago

> but let's be clear here, nobody besides Firefox is going to respect user choice about using DoH. I strongly feel like Brave would also respect users choices, even though they made some mistakes in the past.

charcircuit 5y ago

If operating systems weren't so slow in adopting DoH Firefox wouldn't have to ship it themselves.

bscphil 5y ago

This is sort of like claiming that the spread of encryption is bad and dangerous because it provides tools to terrorists. The problem with the claim is that even if every person or organization producing end-user software stopped developing or supporting DoH, the cat is fully out of the bag. It's just technology at the end of the day, and any company making hardware that wants to hide their DNS requests is completely able to do so already. Some are even building VPNs into their IOT devices. This can't be stopped; ending development on uses of the technology that do benefit the end user is not just pointless but actively a bad idea. There's also a weird conflation that happens between the claim that DoH is "anti-user" and that DoH is "anti-sysadmin". These are two completely different things. If you're a sysadmin who wants to provide a useful DNS service with some additional features on your domain / network, DoH makes it harder for you to do that. I fully agree with this point, and in fact it's a pain point for me because I run Unbound on my router myself! However, this is completely different from the claim that it's "anti-user". Most people do not have friendly local competent admins setting up DNS for them. Those who do are given the choice to opt out of DoH by changing their settings in e.g. Firefox. For other users, DoH is a massive security win. It absolutely makes sense for it to be the default. Anti-admin != anti-user.

Gigachad 5y ago
The hacker news hysteria over DoH is quite absurd and disappointing. Seeing comments massively exaggerate to downright lie about the situation because they are angry their pihole setup no longer works. Imo Firefox is representing the users best interests here. The router, and ISP dns servers can not be trusted. The user wants their browsing session to be as private as possible. Cutting out one more source of data leakage is what the user wants.
- johnklos 5y ago
  Go ahead and give us evidence about how Cloudflare can be trusted. At least we have legally binding contracts with our ISPs. Also, are you trying to suggest that people who know enough to run Piholes don't know enough to run their own DNS servers (or at least select good ones) and their own routers? That's pretty rich.

easrng 5y ago

DNS over HTTPS is useful tool that gives users agency instead of being subjected to the system administrator's DNS policy. It means that in many cases I don't need to use Tor or a VPN to get around network blocks, except on networks with Fortinet. Fortinet even tries to block Tor, but I made a little tool[1] that tunnels BridgeDB requests over docs.google.com so I don't need to worry about that anymore. [1]: data:text/html,<script>google={visualization:{Query:{setResponse:o=>document.write(atob(o.table.rows.map(e=>e.c[0].v).join("")))}}}</script><script src="https://docs.google.com/spreadsheets/d/1SOK9rEPrVLId1NR4KM-mgDO7tlmRk2K5nNi0tv-9gCY/gviz/tq?tqx=out:json"></script>

easrng 5y ago
For example, my school laptop had Cisco Umbrella forcing DNS connections to itself, but half the time it never responded. Firefox DoH still worked because it didn't rely on the system DNS setting, which needs admin perms to change. Eventually I fixed the problem entirely by escalating to admin with PrintNightmare and deleting Cisco Umbrella altogether.
freedomben 5y ago
As a user it's pretty easy to ignore the DNS settings in DHCP and use whatever you want. An aggressive network admin can identify packets headed to outbound 53 on tcp/udp and block them (or reroute them to the preferred DNS) but they could also block known DoH endpoints. As soon as enterprises realize that DoH is happening, they will definitely do that.
- easrng 5y ago
  But sometimes you're on a device where you can run binaries but don't have admin access. Firefox lets you use a custom DoH server regardless of the DNS settings set by the admin.
  - jeroenhd 5y ago
    If your admin has set up the necessary policies, you won't be able to configure a custom DoH server in Firefox either! That doesn't work for personal devices, of course, but DoH is explicitly not intended to work around system administrators' configuration.

josephcsible 5y ago

> DNS over HTTPS is a trojan horse to allow application developers to subvert the system administrator's DNS policy. No, it's a very important tool to help users bypass censorship and surveillance performed by hostile network operators. > Specifically, so that companies like Google, Microsoft, Amazon can ensure that you cannot prevent ads being displayed in their little black boxes (hardware or software). They don't need DoH to do this. They can do this by either hardcoding the IPs of their ad servers, or by serving their ads from the same hosts as the content you want. > This is dangerous, anti-user, and should be avoided at all costs. No, it's very pro-user and should be used at all costs. > DNS over TLS is the correct and appropriate solution here. No, because that's too easy for the aforementioned hostile network operators to block. > You can ensure your (Firefox) browser does not use DNS over HTTPS by configuring a canary domain: https://support.mozilla.org/en-US/kb/canary-domain-use-appli https://support.mozilla.org/en-US/kb/canary-domain-use-appli... This is a misfeature that needs to go away. Thankfully, Firefox has an override that lets you manually enable DoH even if a hostile network operator configures that. > but let's be clear here, nobody besides Firefox is going to respect user choice about using DoH. Correct, but not in the way you meant. Most operating systems and programs will never use DoH even if the user does want it.

inetknght 5y ago
> Most operating systems and programs will never use DoH even if the user does want it. Let Mozilla publish their DNS server addresses then. Let Mozilla (or anyone, it's open source) write a DoH module for pihole. Problem ~~solved~~ deferred.
- jeroenhd 5y ago
  I'm running https://crates.io/crates/doh-proxy https://crates.io/crates/doh-proxy on my Pihole for DoH access (with an nginx frontend for TLS, though that's not necessary of course). You can just plug it into Firefox and it'll work. With nginx in front you can put a stream {} block to proxy pi.hole:853/tcp to pi.hole:53 to enable DoT at the same time: stream { server { listen 853 ssl; proxy_pass pi.hole:53; ssl_[...] } } This setup worked great for me with Android, though it doesn't log the requesting device separately anymore (which is why I switched to a DNS server over a WireGuard VPN instead).

drdaeman 5y ago

Yes and no. The problem is different - the problem is application vs OS DNS resolvers. It's not an application job to be a DNS client, this is what actually subverts system administrator policies. Just as if some application has a hardcoded DNS (over UDP) address, but worse because there's encryption and authentication involved, so the system administrator cannot enforce the policy (sans patching the binary or hooking it at runtime). But if DNS over HTTPS is implemented at the system resolver level there is no issue (and the actual transport doesn't matter).

iJohnDoe 5y ago

@denkmoon Thank you for speaking up. There are many things about DOH/DOT that many don’t understand. There are protocol issues, privacy issues, security issues. DNS over TLS should be the natural progression.

josephcsible 5y ago
What advantage do you see of DoT over DoH other than that it's easier to block at the network level? If you want to block other people's computers from using DoT or DoH, then you're the adversary that they're meant to protect us from.
- nobody9999 5y ago
  >What advantage do you see of DoT over DoH other than that it's easier to block at the network level? If you want to block other people's computers from using DoT or DoH, then you're the adversary that they're meant to protect us from. Not GP, but I don't want to block other people's computers. I'm only concerned with my computers. And when one of them gets uppity and tries to bypass the policies on my network, it needs to be smacked down. Hard. As for anyone else's devices? Have at it. Do whatever you want. But my devices on my network will abide by my policies. That may make you wonder if I'm going to try and steal your DNS requests. But don't worry, I won't invite you into my home.
  - josephcsible 5y ago
    > That may make you wonder if I'm going to try and steal your DNS requests. But don't worry, I won't invite you into my home. The problem isn't guests using your house's network. The problem is that if there's a way for you to network-level block DoH at your own house, then nothing is stopping Comcast or China from implementing the same network-level block.
    - nobody9999 5y ago
      >The problem isn't guests using your house's network. The problem is that if there's a way for you to network-level block DoH at your own house, then nothing is stopping Comcast or China from implementing the same network-level block. Fair enough. But I'd posit that you can't prevent a bad actor who controls your network access from doing whatever the hell they please with/on your traffic, whether you use DoH or not[0]. [0] cf. Transparent TLS proxies ( https://en.wikipedia.org/wiki/TLS_termination_proxy https://en.wikipedia.org/wiki/TLS_termination_proxy ) Edit: Changed prose to actually make sense.