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?
To me, DoH seems less about protecting the user from attackers and more about protecting apps and devices from the user.
Of course, you'd have to add in some permanent exceptions once you realize just how much hardware and software implodes as a result of this.
Some expected, like peer-to-peer applications, though those allow you to define an outbound ephemeral port range you can limit them to (except perhaps for some poor implementations in commercial game launchers trying to offload bandwidth costs). So some are fairly easy to define.
Others you'll have to log and see. Like your Google Home hardware..
I got some minis and disabled the mics since they had hardware switches. I hacked around a bit emulate sending them audio programmatically and discovered they use external DNS and therefore couldn't resolve the local network web server hosting the audio clips I wanted to play. So I had to permanent-lease the hostname's IP and give it an IP address.. They were already bypassing local DNS blockers years ago.
That ship has sailed now that some of the functionality provided by TCP moved up to HTTPS. Whereas in the past you could expect the same IP to expose DNS on port 53, FTP on port 21, or HTTP on port 80, now the same IP will serve you everything over the handy port 443.
So a software developer can very well go this route if they want to obfuscate DNS calls and you wouldn't be able to discriminate the traffic like you would today with ports.
Any global (OS/network) policies become meaningless if your browser or app decide to only ask the DoH resolver "who is google.com" or "who is facebook.com" once, and have all subsequent queries go that way inside an encrypted HTTPS stream.
Key word is any single intermediary. The announcement even explicitly says "no single entity can see both at the same time".
I wonder what it would be like if there were multiple entities in cooperation, each sharing their component of your request with their partners to recover the entirety. You could cover the entire planet with access to even as few as three or five or so large networks.
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.
You can only do this for the devices that respect your DHCP-provided DNS config. Even if you redirect all port 53 traffic on your network to your pihole, a device can make its own (DoH or non-DoH) https connection and gets DNS responses via that, bypassing your pi-hole.
This was discussed extensively a few days ago on a thread about "72% of smart TVs and 46% of game consoles hardcode DNS settings":
Of course, that assumes IPv4, whereas with IPv6 and SLAAC I believe the only way is to firewall them out.
You essentially run a little proxy server on your pihole setup, and configure pihole to use it as your upstream dns resolver.
E.g., a proxy server running at 127.0.0.1:5053 which uses the Cloudflare ipv4/ipv6 DNS over HTTPS endpoints. This can also use other DoH endpoints as desired:
/usr/local/bin/cloudflared proxy-dns \
--port 5053 \
--upstream https://1.1.1.1/dns-query \
--upstream https://1.0.0.1/dns-query \
--upstream https://2606:4700:4700::1111/dns-query \
--upstream https://2606:4700:4700::1001/dns-queryhttps://tools.ietf.org/html/draft-dempsky-dnscurve-01
It’s being worked on again. The “client side” (from client to resolver) got all the attention in recent years. Even though it’s arguably less important than encrypting resolver to Auth traffic (as the resolver can often be close.).
Cynics say this is because there was money behind DoH which pushed it through standardisation, as the big providers are hungry for the data.
arguably the less important part of the equation
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.
SSL/TLS's servername extension puts those names in plaintext just like DNS. The popular browsers all include this extension even when the website does not require it.
As such, one can get a list of names by snooping on HTTPS traffic, instead of DNS traffic:
https://github.com/kontaxis/snidump
ESNI-enabled software and Clouflare's ESNI-enabled CDN is an option, but you have to keep making DNS queries to get a key that changes every hour.
I don’t. Like most people I can control my network.
I have all sorts of crap on my network from Bose and amazon and Nintendo and Apple etc on my IoT vlan.
Without going to a monk style digital life aka RMS, the best bet is to segment them into a secure network and limit what they can communicate with. The DOH Culture and the like takes away my freedoms.
> people taking what devices could already do and standardizing it so that anyone can use it in a more uniform way.
In this case, standardization makes a huge difference.
Before DoH, this was theoretically possible, but needed enormous effort to pull off: The simplest thing a device could do was to hardcode custom DNS servers - but the network admin could easily bypass that by redirecting the packets, as described in this subthread.
Any more interception-proof solutions would have involved designing a custom network protocol, running a custom server and implementing custom bootstrapping logic to connect the device to the server - and even then, the traffic would stand out enough than an admin could still block or redirect it easily enough.
With DoH, there are publicly accessible servers that accept requests over plain HTTPS: This means, someone who wants to keep their ads from being blocked does not need to run any server infrastructure and does not need to fiddle with network code at all - they can just drop in a DoH client library, hardcode a list of public DoH servers and client certs and be done. This is absolutely a game-changer.
Which is a good thing for end users on balance.
The Internet is going 100% encrypted and that's a good thing. This helps towards that goal. Relying on unencrypted traffic will no longer work. Networks must not have the ability to intercept device traffic unless the device administrator (not the network administrator) configures it as such; any such mechanism completely breaks the security properties this is trying to achieve. Ultimately, your choice with uncooperative devices is "block the device or don't" (in addition to isolating it on a separate network), along with "replace it with a cooperative device". Stop telling people they need to stop using encryption so that your local network interception will keep working, because your local network interception is indistinguishable from other people's local network interception.
This feels like the geek version of DRM fallacies or the fallacies that governments believe about encryption. Somehow, there continue to be threads full of arguments that amount to "It should be possible for 'good' network admins to intercept traffic from devices that don't trust them, but 'bad' network admins shouldn't be able to intercept traffic from devices that don't trust them". That's fundamentally not possible; any mechanism usable by 'good' network admins can be used by 'bad' network admins. (Leaving aside that 'good' and 'bad' are relative.) And worse, people get so invested in their local network interception that once it becomes clear that isn't possible, some will start arguing that their local network interception is more important than general Internet security.
There are enough outside opponents of Internet security; let's not start holding back security ourselves because it makes our own hacks stop working. We have enough work to do fighting for the ability to keep the Internet secure against real adversaries. We absolutely need full control over our own devices, but many of the people most capable of fighting for that control got complacent about it because a subset of people could hack around it with local network interception stunts.
That's not what I see at all.
I see people pointing out that DoH hurts privacy and reduces control for end users by providing a convenient turnkey solution for device vendors to bypass filtering at the network level.
I also see it pointed out that DoH could have been specified in a way that facilitated filtering for the local network. Given that it's so obviously possible, the fact that it wasn't speaks volumes.
Note that (IIUC) your ISP can still see which sites you visit because TLS still transmits the FQDN in plaintext (https://security.stackexchange.com/questions/86723). Even if that stopped happening tomorrow, the destination IP would still be visible (not quite as bad but still reveals a huge amount of information). On top of all that, DNSSEC already exists which allows you to verify the authenticity of the query result. As such, the argument in favor of DoH would seem to be limited to preventing your DNS resolver (but not your ISP or VPN!) from tracking which sites you visit. I don't find that to be very compelling in light of the immediate downsides.
No, it couldn't have been, and this is exactly what I was referring to in my comment. Any mechanism that allows the local network to intercept the traffic of a device that doesn't trust the network can and will be abused. The entire point of DoH was to make DNS clients secure, by preventing ISPs and other network providers from monitoring, intercepting, or tampering with DNS results.
You're asking for DNS to be left insecure, so that you can tamper with it. You're asking for the security of clients that actually give users control (laptops, phones, etc) to be sacrificed so that you can continue to tamper with DNS results for clients that don't give users control.
> On top of all that, DNSSEC already exists which allows you to verify the authenticity of the query result.
DNSSEC isn't nearly widespread enough to expect to find it everywhere. Only very specialized clients could make it a requirement; most clients cannot. DNSSEC requires upgrading most of the world before people can rely on it; DoH is an incremental solution.
> As such, the argument in favor of DoH would seem to be limited to preventing your DNS resolver (but not your ISP or VPN!) from tracking which sites you visit.
SNI is being fixed. Once SNI is fixed, DNS is one of the last holes that allows your ISP or other network provider to track you.
And as mentioned above, since DNSSEC is not a viable solution anytime soon, DoH is also critically important to prevent ISPs and other network providers to tamper with your DNS results.
You can check this for yourself: make a list of domains, and then write a trivial script:
#!/bin/sh
while read domain
do
ds=$(dig ds $domain +short)
echo "$domain $ds"
doneBe careful what you wish for
What I think will end up happening, most of the devices will go encrypted route [1]. Most things will run over https, and with encrypted sni, you won't even be able to block domains.
Encryption will be backdoored by governments (and of course other people that will reverse those backdoors or have friends in LEA ).
End result is encryption that people are championing as improving our privacy will make us more exposed and more vulnerable, because other people will have more access to our network, devices and data than we do.
I can and do run linux, so I don't have to worry about my os. But my hardware might phone home on its own. Phones are already lost causes. TV's almost as well.
I do hope you are right and I am wrong, I'd much rater be wrong.
[1] You already have hard time buying non smart TV. A lot of things nowadays expect network connection, and that trend is increasing.
It doesn't make sense to say that encryption will be backdoored so we should use plaintext. We should fight for security across the board, and fight against any threat to that security.
That's not the distinction at all.
It's that you should be able to set up interception on the local network at install time, but all other interception should be blocked. It's extremely possible.
It might be good for the average technophobic end user to trust google instead of their ISP, but it’s not good for me to trust google over my ISP.
The device admin of an iPhone is Apple, the device admin of a non-rooted Android phone is Google, the device admin of a Windows 10 PC is Microsoft and the device admin of a smart TV is likely Samsung. Is that the point you want to make?
All of those companies have incentives to collect user data and are known to push user-hostile changes. They also either have known ties with the NSA or can be coerced via National Security Letters, making even the tired point about "defense against state actors" moot. Do you trust any of them?
If, say, Tencent brought a phone to market in the US that turns out wildly popular but happened to exchange vast amounts of data with servers in China, would you be ok with that?
Most devices today have locked-doen bootloaders, so I don't actually have a choice about the device admin for my device. The position of network admin can be abused, too, but at least there is a possibility I can fill this position myself or can delegate it to someone who I trust.
> Ultimately, your choice with uncooperative devices is "block the device or don't", along with "replace it with a cooperative device".
Right now there are huge market incentives to make devices ever more uncooperative. Unless something changes, the choice for consumers will likely be soon "tolerate an uncooperative device and don't block it - or opt out of technological progress altogether".
> That's fundamentally not possible; any mechanism usable by 'good' network admins can be used by 'bad' network admins.
This argument doesn't get any more coherent no matter how often it's repeated. Somehow the tech industry keeps arguing that the key to any kind of mandatory backdoor will leak with mathematical certainty - while employing that exact same kind of backdoor for their own purposes without any worry - in the form of forced updates and forced telemetry. How exactly can the same technology be a security risk when used by a government but a security best practice when used by a private company?
> We absolutely need full control over our own devices, but many of the people most capable of fighting for that control got complacent about it because a subset of people could hack around it with local network interception stunts.
So then what would be your idea how to gain control?
If you own the device(s) (your internet connection, phone or a colo), and it is someone else's network - you want security.
If it's a device (smart tv, media player, iot) that you don't "own" on your network you want control.
At least, I couldn't figure out how to do it with IPv6 (no (need for) NAT) - I ended up dropping them if not destined for my desired DNS instead.
(NAT lets you Translate Addresses, usually to save IPv4 space, but here to redirect to a different DNS. IPv6 fixes the address space problem with more addresses, so the hack is done away with, and everything on the network can 'route itself' to everything else without any translation, as pre-NAT and as always intended.)
NAT doesn't really have much to do with it, other than you with NAT, you certainly have a device on your network that's capable of being a transparent proxy, whereas without NAT, you could just have a unmanaged switch to share your upstream connection between multiple computers; assuming your provider is enlightened and provides ethernet or an ethernet bridge with nothing else in the way.
I think that's probably the crux of what I'm getting at - and I should say this is all from fiddling at home and not working in networking - with iptables you can `-j DNAT --destination $desired_dns_ip`, but if you don't have NAT then you're left with `-j REDIRECT --dport $portchange`, which yes, takes a destination port, not IP.
> other than you with NAT, you certainly have a device on your network that's capable of being a transparent proxy
Yes exactly, that's all I meant really. After all, the context is a home user configuring a home user's 'router' (i.e. switch, firewall, AP, ...) to send DNS requests to PiHole, right.
It's just that our starting point here was something like 'what can a software engineer do in an hour or so one evening to get their home DNS traffic going through a Raspberry Pi on the LAN'.
I happened to have, er, exactly this experience recently with my (OpenWRT) router(+...) and with that tooling, I couldn't make it work. I settled for DNAT for v4 & DROP^ for v6 because that's what I could get done that evening and it didn't (and hasn't) seem(ed) to be a problem.
^(as in, anything trying to use a different IP, if it's already destined for my DNS that's fine. The hope being that it falls back on v4 at least, even if not the provided DNS over v6.)
Of course it's technically possible, it's all just packets of data that you can change, at the end of the day. I just meant that the easy way to do it (AIUI) went away with IPv6 because you were never supposed to need to do that, and with v6 you 'don't'.
It's not like the purpose of firewalls is redirection.
NAT66 is an experimental (10 years old IIUC!) RFC for one-to-one IPv6 mapping. While there's no RFC specifying an official method of masquerading behind a single address, AFAIK iptables "just works" (as long as you aren't running FreeBSD).
So no ability to block ads in TV or malicious domains that IoT deviced connect to or even blocking Windows, macOS telemetry network wide as all DNS requests will be encrypted which they are not as of right now.
Not really if that hoster is Cloudflare.
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://techcommunity.microsoft.com/t5/networking-blog/windo...
https://blogs.windows.com/windows-insider/2020/08/05/announc...
I still think Chrome and FF having it is a net positive though - The steam hardware survey shows 7% of users' OS is a Windows version before 10, so all of these users can use it today before it gets to them in the next major Windows 10 update.
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.
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.
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.
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.
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.
Also often perfect security isn’t required. Doors with locks are good, but useless if the burglar just breaks the full length glass window next to it. They still serve a purpose, but don’t need to be an absolute comprehensive solution.
Literally all of the security issues caused by the public cloud network architecture instantly evaporate with IPv6, as well as much of the configuration complexity.
No more private networks with non-routable addresses! Instead you get a public-routable IPv6 block.
No more split-routing issues.
No more "gateways" or "peerings" or "service endpoints".
No more Private DNS Zones that may or may not work across virtual network boundaries.
No more copying DNS records into on-premises Active Directory DNS.
Every VM can get a globally unique address. So can every service, of any type! No more conflicts. No need to carefully "carve up" and "allocate" addresses. Just let the system take care of it...
No more sharing IPs with other customers. Every resource, no matter how tiny can get a dedicated address. Got an S3 bucket with 1KB of files in it? You get your own IP!
Every VM or service sees the real client IP, not the reverse proxy IP.
No need for SNI, ESNI, or even host headers since every web server can have a dedicated IP.
No reverse proxy means that load-balancers can simply set up the TCP handshake and then everything runs directly at wire speed. There is never a need to "scale" a load balancer.
The IPv6 addresses are consistent, globally. The IP address of the cloud VM is the address you register on-premises to SSH to it. No NAT magic involved at any point.
Adding a private link (e.g.: ExpressRoute) doesn't change your address ranges. They're the same, only the routes change. This would be a completely transparent change to your firewall rules of whitelisting setup.
Etc...
PS: The current Azure IPv6 architecture reproduces all of the limitations of their IPv4 architecture. They even NAT the addresses! You literally cannot have any of the above, ever, with Azure using IPv6 as it is now. They even limit the number of IPv6 addresses to further restrict you. If they do fix it, you'll have to redo your entire IPv6 setup. It's insanity.
Pi-hole type filtering is then implemented based on IP blocks instead of DNS queries. Any unrecognizable IP address is default denied. Tracking, analytics, and ads could still be proxied by a remote host, but that can already happen anyway.
Of course, your ISP (or VPN, or anyone else along the network path) could employ the exact same approach to determine the services you connect to. Which leads me right back to DoH being largely pointless and Tor or similar being a hard requirement for actual privacy. Unless I'm missing something?
The solution of dedicated IPv4/IPv6 is necessary for proper network control. But for the reasons above many won’t do so.
Also IPv6 is fundamentally not ready for real world use within small/medium businesses and homes IMO. I know you were talking about IP networking within clouds, forgive me, this rant isn’t aimed at that, it’s just my general IPv6 is not ready rent. At least not without NAT. Why?
- Can’t just simply put one IPv6 router/firewall behind another. Not all IPv6 routers support DHCP-PD, and even if they did, you could have 2-3-4 levels of routers/firewalls at a business. I’m not making this up- retail/gas/food industries often have a plethora of networks at a location, and the business/franchise owner is not tech literate, or even if they were, the equipment is managed by third party vendors and they don’t want to customise their IP network for each location. It makes for messy deployment and maintenance.
- Can’t just simply open a firewall rule on the main site router to forward say HTTPS to an internal service. Why? Not all ISPs give static IPv6 prefixes, not all PCs/servers/devices support DHCP6 for static leases, and then there’s IPv6 privacy addresses. Yes, you can statically configure (only if ISP is static too!). No, I don’t want to open the port to all devices on the LAN and no I can’t rely on each device to be running their own firewall (let alone a properly configured one!).
- WAN failover / multiple ISPs is hard. You have a fibre primary feed, and a secondary cellular/5G feed. Each has different IPv6 addresses. How do you ensure the right ISP is used at any given point? IPv6 shifts this decision to the client. This makes load balancing and policy based traffic routing (eg VoIP over fibre 1, FTP over fibre 2, etc). Also the cost of using a multi-homed IPv6 subnet & BGP in a SME/retail business is out of the question (plus the cellular ISP wouldn’t support it anyway).
All the above works fine out of the box with IPv4 and NAT. It’s bread and butter easy. At the cost of not having dedicated unique public IPs but these places simply don’t need them.
What IPv6 should have done to ensure a smooth migration is allowed for NAT from the very start. That would have let everyone who needed public IPs get them straight away, and those that didn’t to still migrate anyway with as little drama as possible. But it’s just not the case, NAT has been slowly added but it’s support is far from ubiquitous that IPv4 has.
"No one can have glass windows in their homes, because a few people like to walk around naked at home, and they're worried about their privacy."
or
"You can't have steak, because if a baby were to eat it, they might choke."
> Right now CDNs provide this privacy
Nothing at all stops you using CDNs with IPv6.
> Also IPv6 is fundamentally not ready for real world use within small/medium businesses and homes IMO.
The protocol has been ready for 10+ years. I'm on an IPv6-enabled home network right now, and it works just fine.
As for the rest of your arguments: They're a side-effect of there being insufficient pressure on ISPs to do their jobs.
If public cloud providers primarily used IPv6, that would very rapidly force ISPs to get their act together and fix their woeful IPv6 support!
This problem goes back a lot further than that — even prior to having CDNs in common usage you had plenty of different clients sharing IP space at hosting companies and the really malicious stuff just using compromised computers. It's also not fully covering the threat model here: for example, if you are concerned about privacy there are whole classes of device which you simply cannot allow because blocking one feature simply means that the vendor will run everything through the same endpoints required for the device to work.
> Also often perfect security isn’t required. Doors with locks are good, but useless if the burglar just breaks the full length glass window next to it. They still serve a purpose, but don’t need to be an absolute comprehensive solution.
Perfect is the enemy of the good but you have to also think about the asymmetry here. Trying to hijack DNS is only useful when you control the network but neither the client or server. Trying to stop malware by politely asking them to play nicely is a losing game and the IoT devices many people worry about have entire teams devoted to bypassing you as well (e.g. if any significant number of people tried to block a TV from reporting your viewing activity, the endgame is that viewing history and software updates would both go through samsung.com, not that they'll give up millions of dollars in revenue). That leaves you with cases where you do control the client and thus have less invasive alternatives such as installing an ad blocker or using a different browser.
This is a very common scenario in retail and SME businesses where you can’t control the on site hardware, eg fuel pumps or CCTV or cash registers or footfall counters or vending machines or whatever, and you can’t control what IPs they talk to. But you still have an obligation to minimise their network access.
Unfortunately they use services hosted on the cloud in dynamic IPs, so you either need to MITM TLS (can’t, no way to change the trusted CA list in these devices), or you need to MITM DNS / SNI. It’s not perfect security, and ideally the business simply wouldn’t buy such poorly securable products, but technology decisions are very rarely vetoed by security considerations, especially when cost is a factor. This is an example of the appropriate level of security for the business risk appetite. Telling the business to buy products that can be locked down perfectly is normally a non-starter.
In every case, once they get the server(s) to connect to you lose all further visibility unless you’re blocking 443 and forcing traffic through an inspection proxy.
With DoH, it's easy to not just hardcode the resolver's IP but also the resolver's certificate. How would a proxy be able to intercept that?
If you're trying to configure transparent proxying where the network redirects traffic to a different device, you would need to have a local CA so you can forge certificates — that's not uncommon in enterprise IT but it's definitely a security risk associated to having something which can MITM anything on your network.
In either case, the real question is whether you control the endpoint. If it doesn't support configuring a proxy or installing a CA, all you have is the binary decision to decide whether or not to allow it on the network at all since whoever does control the client has so many options for smuggling traffic out.
Why can't you redirect all 53 traffic to a pihole and block that single name?
This is not hypothetical: it's how DoH works now but it's also how various things have worked for decades. Malware liked it for hiding command-and-control name queries from the few people who monitor DNS but it was also an option for anyone who had problems with buggy or malicious local DNS servers to add public resolvers like 8.8.8.8 or their own infrastructure into the search list so they didn't get support calls due to some ISP breaking their own DNS server.
The key part is remembering that this was always possible. DoH just meant that more people became aware of the gap they'd always had in their network management.
> Firefox, for example, sends hostname to SOCKS proxy without resolving it.
So a simple proxy can bypass local restrictions.
-----
I remember doing something similar back in my IT days just to see if it was possible. It was.
Then it won't do anything to DNS over HTTPS traffic that is going over port 443. And it won't be able to distinguish that traffic from any other HTTPS traffic.
Not going to be possible in a few years or so:
Just because it is not a silver bullet doesn't mean it is not effective for a large percentage of users.
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.
- 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?
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.
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.
https://blog.apnic.net/2020/02/28/how-to-deploy-dot-and-doh-...
With the 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!
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.
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?
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 ...
I, and many users on my home network, use that site a lot :)
That's what we can do with the Portmaster (https://github.com/safing/portmaster). Check it out!
(I need to block distraction sites during instruction time - otherwise it’s endless Minecraft videos while in zoom meetings...)
Your filtering can still break these devices.
Obviously, it would work with DoT (853) only with cert verification disabled.
The options are simply not there for consistent management of your network.
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)
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.
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.
It's the user's machine not the application developer's.
But we don’t, we just have a default
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.