Comment by ignoramous | Hacker News Reader

Comment by ignoramous | Hacker News Reader

I absolutely love the DNS based solution for ad-blocking and preventing tracking. I use AdGuard DNS on my PC (DNSCrypt) [0] and phone (DoTLS) [1], and it has improved performance of apps (not just websites), 'cause I guess there's a lot less going on under the hood now (trackers like new-relic and segment might be consuming a good percentage of resources which they wouldn't now since their domains are NX'ing?).

What am I worried about is DNS based black-holing is trivial to workaround against (as an ad-provider, one could simply force use a custom DNS client and pin to a DNS resolver of choice) [2][3][4]. What's next for pi-hole and solutions like AdGuard DNS short of re-writing packets going through UDP/53? Not sure how one would intercept the DoTLS / DoHTTPS connections, to rewrite those.

I'd like to hear if anyone has some thoughts on this, or if this has been discussed elsewhere.

[0] https://simplednscrypt.org/

[1] https://news.ycombinator.com/item?id=18788410

[2] https://news.ycombinator.com/item?id=19170671

[3] https://news.ycombinator.com/item?id=19106023

[4] Firefox 64 for PC, by default, was configured to ignore OS/Network Interface provided DNS resolver and used CloudFlare's over HTTPS.

DoTLS and DoHTTPS can be intercepted on your own devices by adding a privately generated certificate to your root store and MITMing the traffic. By design this is the only way to filter this traffic based on content.

Regardless name resolution based ad blocking is relatively futile against even naive workarounds. For instance what is to stop someone from using a custom DoHTTPS format on any webpage to resolve the name directly in browser? What's to prevent them from obfuscating it in a way your MITM couldn't realistically detect?

In the end ad blocking is best done directly on the client through something like uBlock Origin. Not only does this allow you to create a network request block list (now with the added capability of reading/filtering on the whole URI) but it also allows for style based blocks where the ad content could even be blocked if it comes from the same server and resources serving the actual page.

You honestly need both.

Of course, a pihole will not be able to block someone who goes to the length of developing and using a custom DNS-over-TLS or DNS-over-HTTPS webpage.

Similarly uBlock origin is not available for anything else except browsers. There is nothing preventing native apps from using or pinning different nameservers. On a scale of hardness, using or pinning a specific DNS server is easy and is known to be used in wild. Custom DoT or DoH is still rare but I am aware that there will be a time when a significant chunk of internet will use it.

Name-resolution based ad-blocking is not futile yet. My pihole has alone blocked 5k+ queries in the past 24h.

What native apps are you running have advertising built in?

That sounds horrifying.

Windows 10?

That sounds horrifying

Almost all "free" mobile apps?

Like Vixie said, route and answer 8.8.8.8. He is complaining that he has to do it. He is not saying that there is no solution.

Putting a DNS client in Chrome (I think they removed it but who knows), or Chromecast, or whatever is "evolutionary pressure".

It forces users to evolve the solution to work around it. This is good.

If users are forced to learn to use an RPi for DNS (and we can see they are doing that with Pi-Hole), and eventually another pocket-sized computer with open-source software for routing, that benefits the community of users who want to avoid ads.

If avoiding ads is the goal, then using a pocket-sized computer with a user-installed OS is better than a solution marketed by a commercial third-party, as almost always those third parties rely partially/wholly/directly/indirectly on the ad business.

I don't understand Vixie. I have a Chromecast Ultra. On my Firewall at all, I reject all requests to 8.8.8.8(and .4.4) with a ICMP unreachable. This forces the CC Ultra to use the DHCP allocated DNS Server (a pihole) which works just fine.

I don't understand why he says you have to route and answer 8.8.8.8. You really don't.

If his point is you can't override the built in DNS without some sort of FW hackery though, then yea his point stands.

Does the dest unreach solution work on the original Chromecast?

Yup, I have a CC original, 2 CC Audio and a CC Ultra. This trick works for them all

How about Roku, AppleTV, Amazon Fire whatever? (I do not know all the correct brand names but I am presuming other companies are trying to hardcode DNS servers too.)

I don't own any of those. But given those devices don't have ties to Google, I doubt they're trying to force people to use their own DNS. I don't even think Roku, Apple or Amazon run public DNS servers.

Like you, I do not have these to test, but I have read that at least Roku have been hardcoding GoogleDNS servers.

Re #4: really?! I missed that news. Sounds horrible. So instead of using my ISP, that I chose and trust, all my DNS queries now go to some foreign megacorp?!

This is also the first time I heard about it, but my immediate reaction was "sounds amazing".

- Removes all DNS leak privacy issues, for all Firefox users, automatically

- Removes all possibility for a MitM to view or corrupt DNS queries or responses, for all Firefox users, automatically

And Cloudflare claims to delete all DNS-related logs of Firefox users within 24 hours: https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...

Even if you distrust Cloudflare or think they're not secure against breaches, it's still a massive security and privacy upgrade over using your ISP's DNS servers, which will pretty much always leak sensitive information about your connection (potentially leading to deanonymization while using an anonymizing service) and send/receive everything in unauthenticated plaintext.

And in addition, your ISP likely is less trustworthy and less secure against breaches (even if you aren't using Comcast, Verizon, or AT&T) than Cloudflare. But again, even if you don't trust them, this would still be the best move for security.

Plus it's a big latency decrease and performance boost for most or all users.

Who said the router on the network I'm connected to handed out a DNS server that was from my ISP? And why are you so sure my ISP is less secure & trustworthy than Cloudflare?

At least in the US nearly all ISP are either directly selling their customer data or own outright publishing arms that rely on advertiser revenue.

Even in Europe big telcos like Telenor have adtech holdings.

It doesn’t mean you can’t trust your ISP but certainly there are red flags.

Although Joe Average won't know how to, most/all OSes let you pretty easily change your DNS server, you don't have to use your ISP's. But Firefox's UI to _not_ use Cloudflare is _way_ less straightforward.

Most/all routers let you change the DNS that's handed out, too, even the all-in-ones given out by the major ISPs still let you change the default DNS for the entire network.

But also somewhat common[1] is the router handing out itself as the DNS server, which is really important if you want local domains to resolve correctly. Firefox skipping straight to 1.1.1.1 means it won't be able to resolve my local network servers via name, which is stupid.

1: Not common in home use sure, but definitely common in anything run by an IT staff.

Sure it has some advantages, but it has disadvantages too. It really erodes my trust in Mozilla that they did this without notification upon upgrade, and as opt-out instead of opt-in.

My ISP is trustworthy and is in my own city/country. Today I've discovered that all my DNS queries now go to a foreign company that I know nothing about, and did not consent to communicate with.

I'm all for encrypted DNS, but I'm not for my DNS server choice being silently overridden.

How do you feel that even with your isp your data still passes through servers in multiple countries before it gets to you? When you request to view a site it’s not a single hope from you to the server the site is hosted on.

Is that not the point of SSL?

DNS is in the clear by default.

I thought that once DNS is resolved the DNS request doesn't go any further and the actual request is sent to the IP address...

Yes, but the parent comment you replied to was, I believe, referring to data leakage via DNS, not data leakage over HTTP requests. Two different things. What they were getting at is your ISP's DNS servers--and every DNS server hit along the path of resolution--know something about every request made by one of your devices when your devices route DNS through them. Assuming every request to domain.com is encrypted, your ISP may not know what you're sending to domain.com, but they do know you are sending data to domain.com because DNS is in the clear by default. This has led a number of ISPs to capture this information and use it for purposes a customer often does not know about, understand, or may object to--such as selling that information, using it for injecting advertising or hijacking requests, and other actions. What's worse is that many ISPs (in the US, at least) ensure this behavior can occur by requiring customers to use gateways/routers that are locked down to ISP DNS servers, and many of these devices prevent users from modifying the DNS servers used.

Encrypted DNS and devices like the Pi-hole provide end users a means of bypassing this behavior by avoiding ISP DNS servers entirely so even where you're trying to go isn't known by them.

This is one of the many concerns, yes.

Another big concern is privacy from the other side: if you're using Tor or an anonymizing VPN while visiting a website looking to deanonymize users, and the website owners see a DNS query to their nameserver from a Comcast DNS server somewhere in a midwestern state timed perfectly before your HTTP request coming from a Tor exit node or anonymizing VPN, they can potentially infer your broad location and ISP, and potentially narrow your identity down from there (especially if you ever visited that site, or an affiliated site or site that shares data with them, in the past without using an anonymizer), negating the purpose of the anonymizer.

If all they see is a query from 1.1.1.1 or 8.8.8.8, you could be anywhere in the world, using any ISP.

And your ISP can do this in an even more precise way. Customer makes DNS query for siteispsdontlike.com and then immediately sends a lot of traffic to a server registered to an anonymizing VPN company. That tells the ISP "this customer is visiting this 'suspicious' website, and also covering it up by using this specific anonymizer".

And the original GP was pointing out that they had carefully selected an ISP that they trust and wanted to use as their DNS provider and did not want the browser ignoring that...

We basically seem to both agree with the original GP. Things just got a little confused.

Unless I've missed something, Firefox still uses the system resolver. DNS over HTTPS is available but not enabled by default.

Disclosure: I work at Mozilla but not on this.

AFAIK this is not activated by default in FF65; the about:config key for it is 'network.trr.mode'. The default is currently 0 (off). 5 is also off, but explicitly user-set to be off (opt-out). See https://wiki.mozilla.org/Trusted_Recursive_Resolver

Yeah, a European ISP will always be preferable to ANY US corporation I'm afraid to say.

I have a pfsense box. It's quite arbitrary to block DNS request that are anywhere except to your pfsense box. eg. https://docs.netgate.com/pfsense/en/latest/dns/blocking-dns-...

If I'm not mistaken, that will work only for regular old DNS, not DNS over HTTPS (DoH), which, I presume, uses port 443, not 53.

Seems like blocking Firefox and Chrome from usurping your DNS choices is going to be much harder going forward. :(

It’s going to have to work though. For example, corporate users absolutely require the ability to access private internal domains that are not served by public DNS servers. The browser vendors aren’t going to be able to enable DoH directly from the browser by default and break that.

I think the main reason the browsers have added support is so they can get the data they need to make encrypted SNI work. They’re going to have to get operating system APIs to be able to do this from the OS’s resolver or else it will screw all sorts of things up.

TLS it seems it actually uses port 853 (which I didn't know). https://tools.ietf.org/html/rfc7858

So I guess in theory you can block that port outbound to all hosts to handle TLS's use case.

HTTPS is tougher, but just block all traffic to those hostnames with a DNS blacklist.

That's DNS-over-TLS which, while similar, is something completely different than DNS-over-HTTPS (DoH).

DoH does, in fact, use 443/TCP, just like regular HTTPS traffic.

Could just point to an IP directly as well. That could be blacklisted as well but in today's tech stack it is really easy to change variables so that a block would have a short term effect on the client.

I bought the Pi-Hole kit for ~$US100 but was never able to get it to work properly with SSL/TLS sites despite some (admittedly cursory) Googling. It's a great idea in theory.

https://uk.pi-supply.com/products/pi-hole-kit-network-wide-a...

Is that a raspberry pi and some cables sold for $100?

No, there's also a 16GB SD card with the software preloaded, and a plastic cover.

Basically.

You got swindled.

Just got a RPi3B+ with all of that from Microcenter for 53 dollars

That is official pi-hole in a nice box preloaded with software. It is not a swindle, it is a way to help project: https://pi-hole.net/shop/

Somebody is overcharging you on this one. I installed it on my Raspberry Pi B from like 2012. I installed Raspbian, input a small one liner and it was installed.

WAIT, just updated to the latest version and it's working great now. All I had to do was set my Airport to use the Pi-Hole for DNS and now every device on my home network is 99% ad-free. Very impressive.

What is "Firefox 64 for PC"? Does this mean non-mobile Firefox?

Reply on news.ycombinator.com