29 ms·

The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pus

The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pushed into applications themselves to support these new features (such as Chrome and Firefox), which bypasses any system resolvers configured on the host. In most cases there is no way to signal from the network that it is not desirable to do this (Firefox being the sole exception). There also is no good way for enterprises to centrally manage these settings. DNS is a major source of information when doing threat hunting on a network and having that go dark is a big problem. Enterprises aside, there has been a rise of people using solutions like pi-hole in their home networks to filter out traffic not just for ads, but known malicious domains, and telemetry trackers (which Apple does get filtered by, only calling them out specifically because they have an active interest in not being filtered like this). Yes I think it's also a problem that ISPs are snooping and selling this information, but I think that is a less severe problem than rampant malware infections and the excessive collection of online usage data in the telemetry systems present in every webapp, OS, mobile, or IoT device. This increases privacy in one place, while making it much harder to actively protect yourself from the more aggressive and invasive sources of data collection.

hkt 6y ago
Applications still have fallback though, right? If so, I foresee blocks on DoH/etc to common resolvers like 8.8.8.8 and 1.1.1.1. I'll be blocking them at home on the assumption that I only want regular DNS lookups so I can point them to my own DNS server etc.
- 0x426577617265 6y ago
  Blocking traffic for known DoH services would be trivial. How about blocking unknown, how would you block that?
  - dhaavi 6y ago
    Think out of the box: Just don't let the app connect to an IP it has not resolved a domain name for. That's what we can do with the Portmaster (https://github.com/safing/portmaster https://github.com/safing/portmaster). Check it out!
    - 0x426577617265 6y ago
      Thanks, I will check it out.
- TrueDuality 6y ago
  Firefox and Chrome do yes, but none of these standards specify any kind of fall-back behaviour. There are no guarantees that any specific device or application needs to do that or how. There is a cost to firewall rules like that as well. Who is going to maintain a list of all the IPs on the internet that are hosting DoH servers that could be used? What about the potentially more prolific proxies specified in this protocol enhancement? How does a network administrator keep all of those in sync with their edge networks? How does a home user? Since DoH uses HTTPS there is no reason a service can't be multihomed on the same IP just like SNI allows multiple HTTPS servers on one IP. Would you be willing to block a legitimate website just so the applications on your network might fall-back to the name server you want them too?
  - fiddlerwoaroof 6y ago
    You can snoop SNI and use that to block traffic, right? In another thread, someone suggested also stripping the keys for encrypted SNI from DNS queries which, when combined with a firewall that attempts to make a DoH query to every new SNI name it sees might potentially work.
    - kelnos 6y ago
      For now. Encrypted SNI is in development and will eventually be used by devices and apps that want to do this sort of thing and hide what they're doing.
      - fiddlerwoaroof 6y ago
        The solution to that is pretty simple. ESNI, I believe, requires encryption keys in DNS records: if you control DNS, you control ESNI. ECH might be harder to deal with, but you can always just block HTTPS connections you don’t want to support. Also, will some sort of certificate fingerprinting still work?
  - hkt 6y ago
    Well, adblock lists exist, DNS block lists exist, this is just something along similar lines that can be tested and aggregated and distributed. Not a perfect solution, but pi-hole as a router or similar could do it.
- salgernon 6y ago
  Trying to do content filtering on the kids chrome books for remote learning, I installed a pi-hole and was generally pleased with it. Then the kids (8 & 12) figured out to change the dns to cloudflare or google directly. I ended up having to add static routes on the router to block those paths. (I need to block distraction sites during instruction time - otherwise it’s endless Minecraft videos while in zoom meetings...)
  - remarkEon 6y ago
    Any "how to" recommendations for setting up something similar? I have a pi-hole but after reading this thread I feel like im severely under-utilizing it.
- specto 6y ago
  I have blocked 1.1.1.1 and 8.8.8.8 and noticed some devices behave very badly, often crashing or restarting. Debugging the issue, once I removed the firewall rule they behaved normally. Almost all of the affected devices were google related, Android TV for example.
  - vetinari 6y ago
    You can also DNAT all port 53 traffic to your resolver. Devices will think they are talking to 8.8.8.8 or whatever, but in reality they will ask your resolver and your filtering will apply. Your filtering can still break these devices.
    - Spivak 6y ago
      This only works as long as DNS is both unauthenticated and unencrypted.
      - vetinari 6y ago
        Which, at port 53, it is. Obviously, it would work with DoT (853) only with cert verification disabled.
- rsync 6y ago
  "If so, I foresee blocks on DoH/etc to common resolvers like 8.8.8.8 and 1.1.1.1. I'll be blocking them at home on the assumption that I only want regular DNS lookups so I can point them to my own DNS server etc." I wish it were that easy but it's very predictable that google will start resolving DoH on plain old "google.com". So will everyone else ... it's not going to be malicious.userhostile.resolver.samsung.com, it's just going to be samsung.com ... so you can block it but you'll be blocking more than just the resolver ...
  - hkt 6y ago
    Grim thought, but surely they'd have to be serving from the same IPs?
    - rsync 6y ago
      Right, but do you want to block all access to google.com ? I, and many users on my home network, use that site a lot :)
yegle 6y ago
Enterprise can disable DoH in Chrome using a group policy.
- TrueDuality 6y ago
  You're right, that doesn't help with Apple devices though which has seen a huge market share increase with day to day users in the businesses that I interact with. Same thing goes for mobile devices, even those with enterprise management systems attached. The options are simply not there for consistent management of your network.
- vinay_ys 6y ago
  Enterprises can also disable direct outbound connections to anywhere. They can insist only way to access anything is via http proxies. You can do the same at home with a pi-hole. On iOS/MacOS you can install content/network filters. If a browser or app breaks these basic functionalities of Internet, then good luck to them.
crispyporkbites 6y ago
why should DNS be handled at the system layer and not by applications? There's zero controls in place to stop this so I don't see why it's assumed that every application developer will want to use system defaults and not override it.
- gumby 6y ago
  > I don't see why it's assumed that every application developer will want to use system defaults It's the user's machine not the application developer's.
  - kibwen 6y ago
    And users get to decide which applications to install. Tunneling has been a thing for decades; likewise for malicious programs. Vigilance when installing programs on a networked device has always been and remains necessary.
  - crispyporkbites 6y ago
    But it’s not under the users control if they install an app- there’s nothing hard that prevents the abuse. Now if the OS had a system wide / network level proxy that checks the correct DNS calls are getting made and overrides with a user chosen default, then you’d have something. But we don’t, we just have a default
- j16sdiz 6y ago
  Because, DNS, like default gateway and ip address, are configured by DHCP? Zoned DNS server for intranet is very common.
gumby 6y ago
> Querying nameservers is being pushed into applications themselves... I agree: this absurd trend will lead to every app essentially including an entire O/S. There are several reason why OSes provide services to applications and one is that the OS manages the user's configuration (e.g. what devices are plugged in, where and how to resolve names, cacheing data, etc). I also find it rather insane the amount of overhead required to resolve a name when an entire http connection needs to be set up and torn down for the process.
- rusk 6y ago
  I presume there’s some kind of connection pooling going on ... but yeah you’ve still got the needless verbosity of HTTP for a specialised high volume protocol ...
stevepike 6y ago
As someone who recently set up a pihole, I was shocked that it was possible to redirect all DNS requests on the network (in plain text!) to the pi. I did the method where you set up a network firewall at the router level that redirects all port 53 traffic to the pi. It's a nice feature for getting my xbox filtered, but it really felt like an insecure historical quirk rather than a feature we should be praising. Surely it's progress for devices to be able to securely access name servers? I can't snoop on the network traffic going over https but somehow I can get a list of all names queried?
- TrueDuality 6y ago
  You're definitely right that it is an issue that the traffic is plaintext but there are trade off costs that are not addressed by these standards, mostly in user control and fall back behaviour. You've started using a pi-hole, and presumably are getting value from it. These protocols can potentially make it so you can't use that pi-hole at all. Traffic that is local to a network being unencrypted is not a huge privacy problem. If this protocol was adopted by local resolvers, your pi-hole or network router could use it for any requests it makes while still preserving its ability to filter the traffic. It's basically all win under this scenario. The problem comes back to applications implementing this in ways that can't be managed taking the option away from end users and administrators. Without the protocols specifying control and fall-back behaviours on networks that don't need or want this, it's more harmful than useful.
  - stevepike 6y ago
    Can you explain (or share a link) to some proposal for how to enable my pihole to securely talk to upstream resolvers but force all embedded devices on my network to go through the pihole? Anything that lets my pihole sidestep my ISP seems like it'd also work for my xbox.
    - TrueDuality 6y ago
      I don't have any resources handily available for that. I would be truly surprised if pi-hole's don't support DoH though so I'd just try searching for something like "enabling DoH on a pihole" or similar. Basically sounds like you've already done the hardest parts. Your router is redirecting all DNS traffic to your pi-hole, this will prevent any normal unencrypted DNS traffic from leaving your local network. You pi-hole will be in turn making all the DNS requests. If you turn on DoH for the pi-hole all the DNS requests on your network will be encrypted.
acdha 6y ago
The problem is that the things you most want to block can trivially bypass your local DNS filtering - DoH is just standardizing something which has been done for decades. The only effective measure is to block outbound network access and require use of a proxy, possibly optimized by allowing direct traffic only from clients with functioning endpoint monitoring agents.
- fiddlerwoaroof 6y ago
  How can they trivially bypass this local filtering? If the router is redirecting all port 53 traffic, there is no way to bypass aside from some alternate name resolution scheme.
  - chipb 6y ago
    How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? What about 80 or 443?
    - vageli 6y ago
      > How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? How about 80 or 443? Just because it is not a silver bullet doesn't mean it is not effective for a large percentage of users.
    - fiddlerwoaroof 6y ago
      Well, it’s more complicated, but in theory you could do some deep packet inspection that understands the protocols: personally, I’d use this to break DoH connections (for every host name seen in SNI, attempt a DoH query, if it resolves, reset the connection) and attempt to force everything to fall back to plain DNS. Then, whitelist a couple outbound ports (on most networks, maybe just 443 + 53?) and block VPNs.
      - judge2020 6y ago
        > or every host name seen in SNI Not going to be possible in a few years or so: https://news.ycombinator.com/item?id=25344311 https://news.ycombinator.com/item?id=25344311
JMTQp8lwXL 6y ago
Can't you do something analogous to editing your hosts file (but for name servers) and then re-centralize all of your apps using a single name server, which you can then control however you like?
- iso947 6y ago
  No, because instead of setting your network to give out your DNs server to all of your devices, it’s ignored by the apps Instead of setting your devices to use a dns server of your choice it’s ignored by the apps Some apps allow you to configure them, so now you’re configuring 200 apps on 20 devices rather than just one dhcp setting. (Oh and OSs have generally broken hosts files)
  - JMTQp8lwXL 6y ago
    Sorry, what I was trying to say is: you know each app tries to use a certain DNS server. So, in your Rasp Pi, you route their DNS server to point your own (as you would with an /etc/hosts file), that way when DoH occurs, you control the final resolution. What I'm suggesting isn't merely setting up the 'default' dns server. What I'm suggesting is 'cnaming' the name servers that apps attempt connecting to, to point elsewhere.
    - iso947 6y ago
      If you know the iP the DOH client uses you can intercept it. But you can’t spoof it without breaking TLS, which means deploying your own certificate This general industry move will lead to more tls breaking proxies and more network interception. All because people don’t want to understand how a network and os work. Making doh at the application later normal it moves the power towards the centralised advertising network and away from the individual. That the SV culture likes this is unsurprising.
rubyfan 6y ago
When enterprises own the devices on their networks they can add whatever root certificate they like and MITM filter whatever they like. This makes over the network traffic more secure and does nothing to really impact threat detection. If you don’t own the device then 1) should you be interfering or snooping the traffic at all? 2) if you need to limit threat then subnet clients you don’t own.
- TrueDuality 6y ago
  Adding in root certificates and performing HTTPS MITM even on your own network is a huge risk on its own. You're basically breaking many layers of security such as certificate pinning that just get disabled with any custom root certificate. Those middleboxes will always break client certificate authentication and you're trusting that they are checking the various revocation lists they should be (CRL/OSCP/various built-in blocklists). For your basic premise to work, it also means that the MITM middleboxes will need to support the DoH protocols and support recording, and filtering those responses. Additionally, custom roots certificates will only work on devices that you can actually set a custom root certificate for, a great example is IoT devices. Is your TV suddenly talking to a botnet or was that a legitimate update? We can argue about whether those middleboxes are even sane to deploy (hint: they're not), but what is historically true is that they are known to update slowly to new protocols, if at all and are known to cause compatibility issues for traffic that is inherently expected to be unchanged. They're enough of a problem at the _TCP_ layer that QUIC was explicitly designed that minimal information is available in the protocol headers so middleboxes would have less to mess with.
  - rubyfan 6y ago
    oh don’t get me wrong, i’m not advocating for root certs and MITM boxes. i’m just saying DOH isn’t really going to challenge an enterprise’s ability to sniff and intercept DNS. notwithstanding other technical issues, it’s just bad practice to create the sort of experience MITM creates. when people are used to seeing compromised https when on the corp network or mitm boxes prompting for auth periodically it basically lowers people’s guard on that stuff and opens the door.
- 6y ago
admax88q 6y ago
Pi-hole is still very much niche, and outside of that and enterprise network admins, the majority of users are stuck using the trash resolver of their operating system directed to the trash DNS servers of their ISP. If DNS level blocking ever becomes popular enough, malware authors will change their systems to not use the system's DNS, or to use hard coded DNS over TLS/HTTP servers that they know will serve them the data they want. Preventing proprietary applications from doing malicious things is a constant cat and mouse game. Pi-hole works well for now, I would argue, because it's not popular enough to put a big enough dent in the success rate of malware.
- TrueDuality 6y ago
  pi-hole is the most recognized name on here, but I think you're wrong about DNS level blocking. There are lot of home routers that have started integrating that feature natively. A few examples that I know off hand: - Motorola MH7022 - Eero - Disney Circle Basically any of them that say "content filtering" in their product sheet are using DNS level filtering. > ...the trash resolver of their operating system... I'm very curious why you think the well tested, vetted, and constantly updated resolvers built into OS's are "trash". Is it just because most don't have support for DoH or DoT?
  - admax88q 6y ago
    Most of the OS level resolvers just forward to the resolver provided via DHCP. Which is fine for enterprise, but for home users means using the ISPs resolver, which can track users and has a history of injecting ads on failed resolutions. Not to mention the user interface for configuring them has never evolved beyond /etc/hosts and the total disaster that is /etc/resolv.conf (on modern linux distros). The fact that I have to run a separate device such as pi-hole to intercept DNS rather than just point my OS resolver to a blacklist indicates how OS level resolvers have not kept up with the use cases people are asking of them. And of course, no support for DoH or DoT or even DNSSEC.
- zamadatix 6y ago
  DNS level blocking is extraordinarily common in enterprise settings though so the cat and mouse game for malware trying to avoid it is decades in the making at this point, pi-hole is just a recent common name in the prosumer space.
wtetzner 6y ago
I don't know much about the tech, but would it be possible to setup your own local DNS server that your machines point to, and do the filtering within that DNS server?
- zachm0 6y ago
  Yep! If you have a Raspberry Pi, look into Pihole. Some routers have this capability too.
- rsync 6y ago
  I run my own recursive resolver (DNS server) in a datacenter. This DNS server gets its upstream resolution from nextdns.io which is configured with several blocklists - including one that is roughly analogous to ublock origin. On my local network, my DHCP server hands out my DNS server to all clients. This means that all clients on my network get fairly robust ad-blocking even if they do not have an adblocker installed. It also means that non-browser clients (Sonos, AppleTV, etc.) get ad/tracker blocking as well. DoH sort of breaks all of this, unfortunately. Individual devices or clients or browsers can now connect to trackers and ad-servers over HTTPS, bypassing my adblocking resolver. I thought that perhaps there was a solution wherein you would pre-query every single new IP you connected to over HTTPS and send it a test DNS query .. and if it answered DNS, you would just refuse to talk to it. I think this falls apart, however, if (for instance) google just queries "google.com" ... now you're denying google.com because it answers DNS queries over HTTPS... Look, back when 8.8.8.8 came online I could just smell it ... I knew there was a user-hostile arms race somewhere in there I just didn't know where. Now we know.
  - 1vuio0pswjnm7 6y ago
    Google public DNS (8.8.8.8, 8.8.4.4) was created because OpenDNS was redirecting "Google queries" typed into the browser GUI (rather than typed into an HTML form on a website).
- 1vuio0pswjnm7 6y ago
  It is not difficult to run own DOH server. For example, dnsdist >1.4 seems to be a popular choice: https://blog.apnic.net/2020/02/28/how-to-deploy-dot-and-doh-with-dnsdist/ https://blog.apnic.net/2020/02/28/how-to-deploy-dot-and-doh-...
saurik 6y ago
On every single operating system it is possible for this kind of improvement to be installed as a system-wide replacement for the local resolver, whether by a direct plugin or by running a resolver on localhost. This is how these upgrades can be deployed if you don't want to wait for the OS. The problem is that browsers and other applications are just unwilling to let the user see how their products work or decide anything for themselves--or even just architect their installers to involve dependencies on a shared resolver upgrade--and so we end up in this hell of applications actively hiding their traffic from you. And like, "great": now we have a new version of DoH and have to wait for everyone to upgrade their apps that upgraded to DoH before? This is ridiculous bullshit... this should be a single app on your device you now upgrade. Hell: Cloudflare even develops that app for a number of platforms! They aren't even the problem... it is everyone who jumps on "embedding" this behavior :/ :/ :/. (For a more technically-comprehensive rant about this, read my comment from a year ago:) https://news.ycombinator.com/item?id=21701808 https://news.ycombinator.com/item?id=21701808
- judge2020 6y ago
  iOS and MacOS technically have this (requires a profile[0]) but Microsoft will probably drag their feed on this for the next 2 years with the amount of enterprise customers they have to keep happy; and, given that the network adapter config is still based on Aero controls, they're probably in no rush to add more configuration options before upgrading it to Metro controls. 0: https://paulmillr.com/posts/encrypted-dns/ https://paulmillr.com/posts/encrypted-dns/
  - 1over137 6y ago
    Why on earth is a "configuration profile" required for this?
    - judge2020 6y ago
      I imagine Apple is weary about having a UI for this since it might cause more bad PR/complaints about people being able to get around (for example) school website filters. Chrome eased its UI rollout by introducing a managed policy that admins could configure before the UI was enabled. https://cloud.google.com/docs/chrome-enterprise/policies/?policy=DnsOverHttpsMode https://cloud.google.com/docs/chrome-enterprise/policies/?po...
notwedtm 6y ago
Giving the user the ability to expose these requests by sending an HMAC of the domain to a local resolver could help with the privacy portion, but still allow for custom routing based on context.
dhaavi 6y ago
> bypasses any system resolvers configured on the host With the Portmaster (https://github.com/safing/portmaster https://github.com/safing/portmaster) we actually tackle this problem by notifying software (eg. Firefox) or blocking their connections, forcing them back to plain DNS, which we can redirect and handle. Take a look!
josephcsible 6y ago
It's a good thing that network-level filtering is getting harder. If you can use network-level filtering to block ads/trackers/malware from your own devices, countries and ISPs can use network-level filtering to censor other people's devices. If you want to protect your own devices, do it locally, even if it means configuring Firefox instead of just the OS.
deleted 6y ago
[deleted]

hkt 6y ago

Applications still have fallback though, right? If so, I foresee blocks on DoH/etc to common resolvers like 8.8.8.8 and 1.1.1.1. I'll be blocking them at home on the assumption that I only want regular DNS lookups so I can point them to my own DNS server etc.

0x426577617265 6y ago
Blocking traffic for known DoH services would be trivial. How about blocking unknown, how would you block that?
- dhaavi 6y ago
  Think out of the box: Just don't let the app connect to an IP it has not resolved a domain name for. That's what we can do with the Portmaster (https://github.com/safing/portmaster https://github.com/safing/portmaster). Check it out!
  - 0x426577617265 6y ago
    Thanks, I will check it out.
TrueDuality 6y ago
Firefox and Chrome do yes, but none of these standards specify any kind of fall-back behaviour. There are no guarantees that any specific device or application needs to do that or how. There is a cost to firewall rules like that as well. Who is going to maintain a list of all the IPs on the internet that are hosting DoH servers that could be used? What about the potentially more prolific proxies specified in this protocol enhancement? How does a network administrator keep all of those in sync with their edge networks? How does a home user? Since DoH uses HTTPS there is no reason a service can't be multihomed on the same IP just like SNI allows multiple HTTPS servers on one IP. Would you be willing to block a legitimate website just so the applications on your network might fall-back to the name server you want them too?
- fiddlerwoaroof 6y ago
  You can snoop SNI and use that to block traffic, right? In another thread, someone suggested also stripping the keys for encrypted SNI from DNS queries which, when combined with a firewall that attempts to make a DoH query to every new SNI name it sees might potentially work.
  - kelnos 6y ago
    For now. Encrypted SNI is in development and will eventually be used by devices and apps that want to do this sort of thing and hide what they're doing.
    - fiddlerwoaroof 6y ago
      The solution to that is pretty simple. ESNI, I believe, requires encryption keys in DNS records: if you control DNS, you control ESNI. ECH might be harder to deal with, but you can always just block HTTPS connections you don’t want to support. Also, will some sort of certificate fingerprinting still work?
- hkt 6y ago
  Well, adblock lists exist, DNS block lists exist, this is just something along similar lines that can be tested and aggregated and distributed. Not a perfect solution, but pi-hole as a router or similar could do it.
salgernon 6y ago
Trying to do content filtering on the kids chrome books for remote learning, I installed a pi-hole and was generally pleased with it. Then the kids (8 & 12) figured out to change the dns to cloudflare or google directly. I ended up having to add static routes on the router to block those paths. (I need to block distraction sites during instruction time - otherwise it’s endless Minecraft videos while in zoom meetings...)
- remarkEon 6y ago
  Any "how to" recommendations for setting up something similar? I have a pi-hole but after reading this thread I feel like im severely under-utilizing it.
specto 6y ago
I have blocked 1.1.1.1 and 8.8.8.8 and noticed some devices behave very badly, often crashing or restarting. Debugging the issue, once I removed the firewall rule they behaved normally. Almost all of the affected devices were google related, Android TV for example.
- vetinari 6y ago
  You can also DNAT all port 53 traffic to your resolver. Devices will think they are talking to 8.8.8.8 or whatever, but in reality they will ask your resolver and your filtering will apply. Your filtering can still break these devices.
  - Spivak 6y ago
    This only works as long as DNS is both unauthenticated and unencrypted.
    - vetinari 6y ago
      Which, at port 53, it is. Obviously, it would work with DoT (853) only with cert verification disabled.
rsync 6y ago
"If so, I foresee blocks on DoH/etc to common resolvers like 8.8.8.8 and 1.1.1.1. I'll be blocking them at home on the assumption that I only want regular DNS lookups so I can point them to my own DNS server etc." I wish it were that easy but it's very predictable that google will start resolving DoH on plain old "google.com". So will everyone else ... it's not going to be malicious.userhostile.resolver.samsung.com, it's just going to be samsung.com ... so you can block it but you'll be blocking more than just the resolver ...
- hkt 6y ago
  Grim thought, but surely they'd have to be serving from the same IPs?
  - rsync 6y ago
    Right, but do you want to block all access to google.com ? I, and many users on my home network, use that site a lot :)

yegle 6y ago

Enterprise can disable DoH in Chrome using a group policy.

TrueDuality 6y ago
You're right, that doesn't help with Apple devices though which has seen a huge market share increase with day to day users in the businesses that I interact with. Same thing goes for mobile devices, even those with enterprise management systems attached. The options are simply not there for consistent management of your network.
vinay_ys 6y ago
Enterprises can also disable direct outbound connections to anywhere. They can insist only way to access anything is via http proxies. You can do the same at home with a pi-hole. On iOS/MacOS you can install content/network filters. If a browser or app breaks these basic functionalities of Internet, then good luck to them.

crispyporkbites 6y ago

why should DNS be handled at the system layer and not by applications? There's zero controls in place to stop this so I don't see why it's assumed that every application developer will want to use system defaults and not override it.

gumby 6y ago
> I don't see why it's assumed that every application developer will want to use system defaults It's the user's machine not the application developer's.
- kibwen 6y ago
  And users get to decide which applications to install. Tunneling has been a thing for decades; likewise for malicious programs. Vigilance when installing programs on a networked device has always been and remains necessary.
- crispyporkbites 6y ago
  But it’s not under the users control if they install an app- there’s nothing hard that prevents the abuse. Now if the OS had a system wide / network level proxy that checks the correct DNS calls are getting made and overrides with a user chosen default, then you’d have something. But we don’t, we just have a default
j16sdiz 6y ago
Because, DNS, like default gateway and ip address, are configured by DHCP? Zoned DNS server for intranet is very common.

gumby 6y ago

> Querying nameservers is being pushed into applications themselves... I agree: this absurd trend will lead to every app essentially including an entire O/S. There are several reason why OSes provide services to applications and one is that the OS manages the user's configuration (e.g. what devices are plugged in, where and how to resolve names, cacheing data, etc). I also find it rather insane the amount of overhead required to resolve a name when an entire http connection needs to be set up and torn down for the process.

rusk 6y ago
I presume there’s some kind of connection pooling going on ... but yeah you’ve still got the needless verbosity of HTTP for a specialised high volume protocol ...

stevepike 6y ago

As someone who recently set up a pihole, I was shocked that it was possible to redirect all DNS requests on the network (in plain text!) to the pi. I did the method where you set up a network firewall at the router level that redirects all port 53 traffic to the pi. It's a nice feature for getting my xbox filtered, but it really felt like an insecure historical quirk rather than a feature we should be praising. Surely it's progress for devices to be able to securely access name servers? I can't snoop on the network traffic going over https but somehow I can get a list of all names queried?

TrueDuality 6y ago
You're definitely right that it is an issue that the traffic is plaintext but there are trade off costs that are not addressed by these standards, mostly in user control and fall back behaviour. You've started using a pi-hole, and presumably are getting value from it. These protocols can potentially make it so you can't use that pi-hole at all. Traffic that is local to a network being unencrypted is not a huge privacy problem. If this protocol was adopted by local resolvers, your pi-hole or network router could use it for any requests it makes while still preserving its ability to filter the traffic. It's basically all win under this scenario. The problem comes back to applications implementing this in ways that can't be managed taking the option away from end users and administrators. Without the protocols specifying control and fall-back behaviours on networks that don't need or want this, it's more harmful than useful.
- stevepike 6y ago
  Can you explain (or share a link) to some proposal for how to enable my pihole to securely talk to upstream resolvers but force all embedded devices on my network to go through the pihole? Anything that lets my pihole sidestep my ISP seems like it'd also work for my xbox.
  - TrueDuality 6y ago
    I don't have any resources handily available for that. I would be truly surprised if pi-hole's don't support DoH though so I'd just try searching for something like "enabling DoH on a pihole" or similar. Basically sounds like you've already done the hardest parts. Your router is redirecting all DNS traffic to your pi-hole, this will prevent any normal unencrypted DNS traffic from leaving your local network. You pi-hole will be in turn making all the DNS requests. If you turn on DoH for the pi-hole all the DNS requests on your network will be encrypted.

acdha 6y ago

The problem is that the things you most want to block can trivially bypass your local DNS filtering - DoH is just standardizing something which has been done for decades. The only effective measure is to block outbound network access and require use of a proxy, possibly optimized by allowing direct traffic only from clients with functioning endpoint monitoring agents.

fiddlerwoaroof 6y ago
How can they trivially bypass this local filtering? If the router is redirecting all port 53 traffic, there is no way to bypass aside from some alternate name resolution scheme.
- chipb 6y ago
  How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? What about 80 or 443?
  - vageli 6y ago
    > How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? How about 80 or 443? Just because it is not a silver bullet doesn't mean it is not effective for a large percentage of users.
  - fiddlerwoaroof 6y ago
    Well, it’s more complicated, but in theory you could do some deep packet inspection that understands the protocols: personally, I’d use this to break DoH connections (for every host name seen in SNI, attempt a DoH query, if it resolves, reset the connection) and attempt to force everything to fall back to plain DNS. Then, whitelist a couple outbound ports (on most networks, maybe just 443 + 53?) and block VPNs.
    - judge2020 6y ago
      > or every host name seen in SNI Not going to be possible in a few years or so: https://news.ycombinator.com/item?id=25344311 https://news.ycombinator.com/item?id=25344311

JMTQp8lwXL 6y ago

Can't you do something analogous to editing your hosts file (but for name servers) and then re-centralize all of your apps using a single name server, which you can then control however you like?

iso947 6y ago
No, because instead of setting your network to give out your DNs server to all of your devices, it’s ignored by the apps Instead of setting your devices to use a dns server of your choice it’s ignored by the apps Some apps allow you to configure them, so now you’re configuring 200 apps on 20 devices rather than just one dhcp setting. (Oh and OSs have generally broken hosts files)
- JMTQp8lwXL 6y ago
  Sorry, what I was trying to say is: you know each app tries to use a certain DNS server. So, in your Rasp Pi, you route their DNS server to point your own (as you would with an /etc/hosts file), that way when DoH occurs, you control the final resolution. What I'm suggesting isn't merely setting up the 'default' dns server. What I'm suggesting is 'cnaming' the name servers that apps attempt connecting to, to point elsewhere.
  - iso947 6y ago
    If you know the iP the DOH client uses you can intercept it. But you can’t spoof it without breaking TLS, which means deploying your own certificate This general industry move will lead to more tls breaking proxies and more network interception. All because people don’t want to understand how a network and os work. Making doh at the application later normal it moves the power towards the centralised advertising network and away from the individual. That the SV culture likes this is unsurprising.

rubyfan 6y ago

When enterprises own the devices on their networks they can add whatever root certificate they like and MITM filter whatever they like. This makes over the network traffic more secure and does nothing to really impact threat detection. If you don’t own the device then 1) should you be interfering or snooping the traffic at all? 2) if you need to limit threat then subnet clients you don’t own.

TrueDuality 6y ago
Adding in root certificates and performing HTTPS MITM even on your own network is a huge risk on its own. You're basically breaking many layers of security such as certificate pinning that just get disabled with any custom root certificate. Those middleboxes will always break client certificate authentication and you're trusting that they are checking the various revocation lists they should be (CRL/OSCP/various built-in blocklists). For your basic premise to work, it also means that the MITM middleboxes will need to support the DoH protocols and support recording, and filtering those responses. Additionally, custom roots certificates will only work on devices that you can actually set a custom root certificate for, a great example is IoT devices. Is your TV suddenly talking to a botnet or was that a legitimate update? We can argue about whether those middleboxes are even sane to deploy (hint: they're not), but what is historically true is that they are known to update slowly to new protocols, if at all and are known to cause compatibility issues for traffic that is inherently expected to be unchanged. They're enough of a problem at the _TCP_ layer that QUIC was explicitly designed that minimal information is available in the protocol headers so middleboxes would have less to mess with.
- rubyfan 6y ago
  oh don’t get me wrong, i’m not advocating for root certs and MITM boxes. i’m just saying DOH isn’t really going to challenge an enterprise’s ability to sniff and intercept DNS. notwithstanding other technical issues, it’s just bad practice to create the sort of experience MITM creates. when people are used to seeing compromised https when on the corp network or mitm boxes prompting for auth periodically it basically lowers people’s guard on that stuff and opens the door.
6y ago

admax88q 6y ago

Pi-hole is still very much niche, and outside of that and enterprise network admins, the majority of users are stuck using the trash resolver of their operating system directed to the trash DNS servers of their ISP. If DNS level blocking ever becomes popular enough, malware authors will change their systems to not use the system's DNS, or to use hard coded DNS over TLS/HTTP servers that they know will serve them the data they want. Preventing proprietary applications from doing malicious things is a constant cat and mouse game. Pi-hole works well for now, I would argue, because it's not popular enough to put a big enough dent in the success rate of malware.

TrueDuality 6y ago
pi-hole is the most recognized name on here, but I think you're wrong about DNS level blocking. There are lot of home routers that have started integrating that feature natively. A few examples that I know off hand: - Motorola MH7022 - Eero - Disney Circle Basically any of them that say "content filtering" in their product sheet are using DNS level filtering. > ...the trash resolver of their operating system... I'm very curious why you think the well tested, vetted, and constantly updated resolvers built into OS's are "trash". Is it just because most don't have support for DoH or DoT?
- admax88q 6y ago
  Most of the OS level resolvers just forward to the resolver provided via DHCP. Which is fine for enterprise, but for home users means using the ISPs resolver, which can track users and has a history of injecting ads on failed resolutions. Not to mention the user interface for configuring them has never evolved beyond /etc/hosts and the total disaster that is /etc/resolv.conf (on modern linux distros). The fact that I have to run a separate device such as pi-hole to intercept DNS rather than just point my OS resolver to a blacklist indicates how OS level resolvers have not kept up with the use cases people are asking of them. And of course, no support for DoH or DoT or even DNSSEC.
zamadatix 6y ago
DNS level blocking is extraordinarily common in enterprise settings though so the cat and mouse game for malware trying to avoid it is decades in the making at this point, pi-hole is just a recent common name in the prosumer space.

wtetzner 6y ago

I don't know much about the tech, but would it be possible to setup your own local DNS server that your machines point to, and do the filtering within that DNS server?

zachm0 6y ago
Yep! If you have a Raspberry Pi, look into Pihole. Some routers have this capability too.
rsync 6y ago
I run my own recursive resolver (DNS server) in a datacenter. This DNS server gets its upstream resolution from nextdns.io which is configured with several blocklists - including one that is roughly analogous to ublock origin. On my local network, my DHCP server hands out my DNS server to all clients. This means that all clients on my network get fairly robust ad-blocking even if they do not have an adblocker installed. It also means that non-browser clients (Sonos, AppleTV, etc.) get ad/tracker blocking as well. DoH sort of breaks all of this, unfortunately. Individual devices or clients or browsers can now connect to trackers and ad-servers over HTTPS, bypassing my adblocking resolver. I thought that perhaps there was a solution wherein you would pre-query every single new IP you connected to over HTTPS and send it a test DNS query .. and if it answered DNS, you would just refuse to talk to it. I think this falls apart, however, if (for instance) google just queries "google.com" ... now you're denying google.com because it answers DNS queries over HTTPS... Look, back when 8.8.8.8 came online I could just smell it ... I knew there was a user-hostile arms race somewhere in there I just didn't know where. Now we know.
- 1vuio0pswjnm7 6y ago
  Google public DNS (8.8.8.8, 8.8.4.4) was created because OpenDNS was redirecting "Google queries" typed into the browser GUI (rather than typed into an HTML form on a website).
1vuio0pswjnm7 6y ago
It is not difficult to run own DOH server. For example, dnsdist >1.4 seems to be a popular choice: https://blog.apnic.net/2020/02/28/how-to-deploy-dot-and-doh-with-dnsdist/ https://blog.apnic.net/2020/02/28/how-to-deploy-dot-and-doh-...

saurik 6y ago

On every single operating system it is possible for this kind of improvement to be installed as a system-wide replacement for the local resolver, whether by a direct plugin or by running a resolver on localhost. This is how these upgrades can be deployed if you don't want to wait for the OS. The problem is that browsers and other applications are just unwilling to let the user see how their products work or decide anything for themselves--or even just architect their installers to involve dependencies on a shared resolver upgrade--and so we end up in this hell of applications actively hiding their traffic from you. And like, "great": now we have a new version of DoH and have to wait for everyone to upgrade their apps that upgraded to DoH before? This is ridiculous bullshit... this should be a single app on your device you now upgrade. Hell: Cloudflare even develops that app for a number of platforms! They aren't even the problem... it is everyone who jumps on "embedding" this behavior :/ :/ :/. (For a more technically-comprehensive rant about this, read my comment from a year ago:) https://news.ycombinator.com/item?id=21701808 https://news.ycombinator.com/item?id=21701808

judge2020 6y ago
iOS and MacOS technically have this (requires a profile[0]) but Microsoft will probably drag their feed on this for the next 2 years with the amount of enterprise customers they have to keep happy; and, given that the network adapter config is still based on Aero controls, they're probably in no rush to add more configuration options before upgrading it to Metro controls. 0: https://paulmillr.com/posts/encrypted-dns/ https://paulmillr.com/posts/encrypted-dns/
- 1over137 6y ago
  Why on earth is a "configuration profile" required for this?
  - judge2020 6y ago
    I imagine Apple is weary about having a UI for this since it might cause more bad PR/complaints about people being able to get around (for example) school website filters. Chrome eased its UI rollout by introducing a managed policy that admins could configure before the UI was enabled. https://cloud.google.com/docs/chrome-enterprise/policies/?policy=DnsOverHttpsMode https://cloud.google.com/docs/chrome-enterprise/policies/?po...

notwedtm 6y ago

Giving the user the ability to expose these requests by sending an HMAC of the domain to a local resolver could help with the privacy portion, but still allow for custom routing based on context.

dhaavi 6y ago

> bypasses any system resolvers configured on the host With the Portmaster (https://github.com/safing/portmaster https://github.com/safing/portmaster) we actually tackle this problem by notifying software (eg. Firefox) or blocking their connections, forcing them back to plain DNS, which we can redirect and handle. Take a look!

josephcsible 6y ago

It's a good thing that network-level filtering is getting harder. If you can use network-level filtering to block ads/trackers/malware from your own devices, countries and ISPs can use network-level filtering to censor other people's devices. If you want to protect your own devices, do it locally, even if it means configuring Firefox instead of just the OS.

deleted 6y ago

[deleted]