4 ms·

Can DoH be used to bypass home DNS servers, such as the pihole?

by pimeys 6y ago

CarelessExpert 6y ago
Because DoH is implemented in the browser and bypasses the OS resolver configuration, it will specifically break things like pihole. The correct solution is a) do this at the OS so users can configure the behaviour, b) add support to pihole or similar for making DoH requests out to somewhere like CloudFlare, c) also add support for receiving DoH requests for those people using a pihole over untrusted networks.
- pimeys 6y ago
  That's what I've figured out too. A while ago I started blocking port 443 to known DoH servers to prevent any machine from internal network bypassing the pihole. I expect televisions, smart lights and many other IoT devices to start using DoH to be able to track the users with pihole installed...
  - Datenstrom 6y ago
    Is there a comprehensive list to block somewhere? I would like to do the same.
    - LinuxBender 6y ago
      Comprehensive, no. There are growing numbers of git repos of DoH names. [1] [2] [1] - https://github.com/bambenek/block-doh https://github.com/bambenek/block-doh [2] - https://github.com/Sekhan/TheGreatWall https://github.com/Sekhan/TheGreatWall
      - deleted 6y ago
        [deleted]
  - shawnz 6y ago
    Do you also block plain old third-party unencrypted DNS servers? Because those could also trivially be used to bypass content filtering on your local resolver, no DoH required. In fact some web appliances like the Chromecast already do exactly this without having to use any kind of technology like DoH. The problem you are describing is nothing to do with DoH, it is simply a consequence of the fact that DNS is not meant to provide access control. It is not an endpoint security management solution.
    - LinuxBender 6y ago
      I do. I have always intercepted 53 and 853 and route them to my Unbound DNS recursive server. Unbound caches requests, blocks known malicious domains, then forwards the requests over a vpn mesh to other unbound servers that talk to the root name servers. The weakest link of course is that the root servers do not talk TLS yet. DNSSEC can be useful for zones that are signed.
      - shawnz 6y ago
        Now consider you are visiting a friend's house and you find out they have such a setup on their network... you wouldn't be bothered to learn that all the domain names you visit, even over TLS, are being processed by the homeowner and could be logged?
        LinuxBender 6y ago
        At a friends house, my laptop will join my private VPN mesh and my DNS lookups will still use my servers. This does assume they allow outbound connectivity to more than 80/443. I have found places that do not allow this. I could run tinc [1] on 443, but if UDP is blocked, the VPN will be slower. That said, in fairness, not everyone sets up their own VPN mesh. Some people use commercial VPN providers. So in that case, it would assume my friend does not block access to that VPN provider. [1] - http://tinc-vpn.org/ http://tinc-vpn.org/
        shawnz 6y ago
- TheRealPomax 6y ago
  Or, you know, turn off DoH if you use a pihole. There is no problem to solve here, or indignity to get upset about. If you run a custom DNS, don't have DoH running. Done. "But users won't know ho-" if you are so far from the norm that you set up pihole to act as DNS level adblocker, then you most certainly do. There is no problem to solve here. "But what if browsers stop offering the choice?" why would we talk about "browsers" when this is about Mozilla's Firefox? The entire reason you're using it is because it keeps you in control, to the degree where if you think you know better than the browser itself, just open about:config and get to work. There is no problem to solve here.
  - tremon 6y ago
    If you run a custom DNS, don't have DoH running How do I enforce that? How can I ensure that no javascript payload or "smart" device on my network or app on my phone is connecting to a DoH server, when they're on my home network?
    - TheRealPomax 6y ago
      Did you suddenly forget how to care about privacy and security before you buy your devices? No. Vote with your dollars, don't buy things that don't do what you need them to. If some IoT device only uses DoH, you already know that before you buy it: don't buy it. If an app only works with DoH, you already discovered that because you're someone who reads and comments on HN, and so you're guaranteed to check some app reviews before you buy into to: don't use it. No one's forcing you into this beyond your control. Plus, right now we're talking about a browser adding DoH, and not some shit Google or Apple browser that makes the decision for you and it's final, but a fully configurable, user controlled, poweruser enabling browser that lets you modify its core behaviour without even having to recompile it yourself. You just open a tab and flip a boolean. There is no problem.
    - EvanAnderson 6y ago
      How do I enforce that? You don't. When the device manufacturers start being really evil and using certificate pinning for their DoH servers you simply don't buy those devices. When the only devices available in the market for a given function end up being "evil" you either implement the functionality yourself or you just live without. It's that or legislation (which will just become an arms race of manufacturers trying to work around the legislation). I do without. No "smart" devices for me or my family. It's working so far. I about the eventual future when no major appliances, vehicles, etc, will be available without "smart" features implemented in an owner-hostile manner.
- CarelessExpert 6y ago
  Replying to my own post: I hadn't looked into this recently but it looks like you can configure a pihole to use DoH for outbound requests: https://docs.pi-hole.net/guides/dns-over-https/ https://docs.pi-hole.net/guides/dns-over-https/ So personally I plan to a) enable that so my outbound requests are encrypted, and then b) install a DNS blocklist so the hosts on my network will fall back to regular DNS and use the pihole. Best of both worlds!
Datenstrom 6y ago
Yes, had this problem when I was setting up my pihole and took me a bit to figure out why it wasn't working with firefox. Imagine the sysadmin nightmare if you had to configure 100 different applications on every one of your systems to use the correct server... This is so obviously bad I don't understand.
- shawnz 6y ago
  I am inclined to think most users use client-side content blocking, and not DNS-based content blocking, which has always been trivially bypassable long before DoH was around. So given that DoH has real and practical security and privacy benefits, and non-DNS based content blocking solutions are already available, are more common, and work more effectively, I don't see how it is such a nightmare to adopt those more secure defaults for everyone. Furthermore I don't think anyone is suggesting "100 different applications" will each have their own resolvers embedded. It makes sense for browsers to be a special case since they are particularly in need of the additional privacy affordances that DoH can provide, and operating system vendors have been slow to implement it.
  - CarelessExpert 6y ago
    > I am inclined to think most users use client-side content blocking, and not DNS-based content blocking, I think you're missing the point, here. A lot of enterprises run their own delegating DNS server for a variety of reasons that have nothing to do with ad blocking. DoH breaks that en masse. Firefox has always struggled to gain adoption in corporate settings, and this looks like a nail in the coffin .
    - shawnz 6y ago
      If you control the workstation, you could just set your DNS server by a policy. See: https://github.com/mozilla/policy-templates/blob/master/README.md#dnsoverhttps https://github.com/mozilla/policy-templates/blob/master/READ... Of course that could be easily bypassed, but such a restriction could be easily bypassed by determined employees regardless of whether Firefox natively supports DoH or not. Local intranet sites will still continue to work without any changes because by default it will fall back to the native resolver if DoH can't resolve the domain. So there should be no breakage by default besides for content blocking use cases.

Can DoH be used to bypass home DNS servers, such as the pihole?

by pimeys 6y ago

Can DoH be used to bypass home DNS servers, such as the pihole?

Because DoH is implemented in the browser and bypasses the OS resolver configuration, it will specifically break things like pihole. The correct solution is a) do this at the OS so users can configure the behaviour, b) add support to pihole or similar for making DoH requests out to somewhere like CloudFlare, c) also add support for receiving DoH requests for those people using a pihole over untrusted networks.

pimeys 6y ago
That's what I've figured out too. A while ago I started blocking port 443 to known DoH servers to prevent any machine from internal network bypassing the pihole. I expect televisions, smart lights and many other IoT devices to start using DoH to be able to track the users with pihole installed...
- Datenstrom 6y ago
  Is there a comprehensive list to block somewhere? I would like to do the same.
  - LinuxBender 6y ago
    Comprehensive, no. There are growing numbers of git repos of DoH names. [1] [2] [1] - https://github.com/bambenek/block-doh https://github.com/bambenek/block-doh [2] - https://github.com/Sekhan/TheGreatWall https://github.com/Sekhan/TheGreatWall
    - deleted 6y ago
      [deleted]
- shawnz 6y ago
  Do you also block plain old third-party unencrypted DNS servers? Because those could also trivially be used to bypass content filtering on your local resolver, no DoH required. In fact some web appliances like the Chromecast already do exactly this without having to use any kind of technology like DoH. The problem you are describing is nothing to do with DoH, it is simply a consequence of the fact that DNS is not meant to provide access control. It is not an endpoint security management solution.
  - LinuxBender 6y ago
    I do. I have always intercepted 53 and 853 and route them to my Unbound DNS recursive server. Unbound caches requests, blocks known malicious domains, then forwards the requests over a vpn mesh to other unbound servers that talk to the root name servers. The weakest link of course is that the root servers do not talk TLS yet. DNSSEC can be useful for zones that are signed.
    - shawnz 6y ago
      Now consider you are visiting a friend's house and you find out they have such a setup on their network... you wouldn't be bothered to learn that all the domain names you visit, even over TLS, are being processed by the homeowner and could be logged?
      - LinuxBender 6y ago
        At a friends house, my laptop will join my private VPN mesh and my DNS lookups will still use my servers. This does assume they allow outbound connectivity to more than 80/443. I have found places that do not allow this. I could run tinc [1] on 443, but if UDP is blocked, the VPN will be slower. That said, in fairness, not everyone sets up their own VPN mesh. Some people use commercial VPN providers. So in that case, it would assume my friend does not block access to that VPN provider. [1] - http://tinc-vpn.org/ http://tinc-vpn.org/
        shawnz 6y ago
TheRealPomax 6y ago
Or, you know, turn off DoH if you use a pihole. There is no problem to solve here, or indignity to get upset about. If you run a custom DNS, don't have DoH running. Done. "But users won't know ho-" if you are so far from the norm that you set up pihole to act as DNS level adblocker, then you most certainly do. There is no problem to solve here. "But what if browsers stop offering the choice?" why would we talk about "browsers" when this is about Mozilla's Firefox? The entire reason you're using it is because it keeps you in control, to the degree where if you think you know better than the browser itself, just open about:config and get to work. There is no problem to solve here.
- tremon 6y ago
  If you run a custom DNS, don't have DoH running How do I enforce that? How can I ensure that no javascript payload or "smart" device on my network or app on my phone is connecting to a DoH server, when they're on my home network?
  - TheRealPomax 6y ago
    Did you suddenly forget how to care about privacy and security before you buy your devices? No. Vote with your dollars, don't buy things that don't do what you need them to. If some IoT device only uses DoH, you already know that before you buy it: don't buy it. If an app only works with DoH, you already discovered that because you're someone who reads and comments on HN, and so you're guaranteed to check some app reviews before you buy into to: don't use it. No one's forcing you into this beyond your control. Plus, right now we're talking about a browser adding DoH, and not some shit Google or Apple browser that makes the decision for you and it's final, but a fully configurable, user controlled, poweruser enabling browser that lets you modify its core behaviour without even having to recompile it yourself. You just open a tab and flip a boolean. There is no problem.
  - EvanAnderson 6y ago
    How do I enforce that? You don't. When the device manufacturers start being really evil and using certificate pinning for their DoH servers you simply don't buy those devices. When the only devices available in the market for a given function end up being "evil" you either implement the functionality yourself or you just live without. It's that or legislation (which will just become an arms race of manufacturers trying to work around the legislation). I do without. No "smart" devices for me or my family. It's working so far. I about the eventual future when no major appliances, vehicles, etc, will be available without "smart" features implemented in an owner-hostile manner.
CarelessExpert 6y ago
Replying to my own post: I hadn't looked into this recently but it looks like you can configure a pihole to use DoH for outbound requests: https://docs.pi-hole.net/guides/dns-over-https/ https://docs.pi-hole.net/guides/dns-over-https/ So personally I plan to a) enable that so my outbound requests are encrypted, and then b) install a DNS blocklist so the hosts on my network will fall back to regular DNS and use the pihole. Best of both worlds!

Datenstrom 6y ago

Yes, had this problem when I was setting up my pihole and took me a bit to figure out why it wasn't working with firefox. Imagine the sysadmin nightmare if you had to configure 100 different applications on every one of your systems to use the correct server... This is so obviously bad I don't understand.

shawnz 6y ago
I am inclined to think most users use client-side content blocking, and not DNS-based content blocking, which has always been trivially bypassable long before DoH was around. So given that DoH has real and practical security and privacy benefits, and non-DNS based content blocking solutions are already available, are more common, and work more effectively, I don't see how it is such a nightmare to adopt those more secure defaults for everyone. Furthermore I don't think anyone is suggesting "100 different applications" will each have their own resolvers embedded. It makes sense for browsers to be a special case since they are particularly in need of the additional privacy affordances that DoH can provide, and operating system vendors have been slow to implement it.
- CarelessExpert 6y ago
  > I am inclined to think most users use client-side content blocking, and not DNS-based content blocking, I think you're missing the point, here. A lot of enterprises run their own delegating DNS server for a variety of reasons that have nothing to do with ad blocking. DoH breaks that en masse. Firefox has always struggled to gain adoption in corporate settings, and this looks like a nail in the coffin .
  - shawnz 6y ago
    If you control the workstation, you could just set your DNS server by a policy. See: https://github.com/mozilla/policy-templates/blob/master/README.md#dnsoverhttps https://github.com/mozilla/policy-templates/blob/master/READ... Of course that could be easily bypassed, but such a restriction could be easily bypassed by determined employees regardless of whether Firefox natively supports DoH or not. Local intranet sites will still continue to work without any changes because by default it will fall back to the native resolver if DoH can't resolve the domain. So there should be no breakage by default besides for content blocking use cases.