Because your ISP will hijack the queries it makes.

Don't they only hijack the queries that you send to the ISPs DNS servers? Or do they MITM all DNS requests no matter the destination DNS server and hijack them? A local recursive resolver will generally not forward requests to the ISPs DNS servers.

It’s on the honor system: if you’re worried about the problems encrypted DNS prevents, your ISP is the most likely threat.

With traditional DNS, your ISP can monitor everything you query passively. They also see every host name you connect to using TLS with SNI. Since that’s passive, you don’t know who they share that with except to the extent that you trust your government’s privacy law’s & enforcement.

They can also spoof DNS replies if they want to send you to a different server. This used to be common for Wi-Fi login systems when most of the web ran on HTTPS but TLS breaks it now. This is an active attack which is usually pretty blatant so you won’t see it commonly on residential ISPs.

DNS over TLS/HTTPS breaks all of the passive DNS monitoring & active spoofing. It does not help with TLS SNI monitoring but there’s an Encrypted Client Hello extension being tested now for that.

I'm convinced that (American) ISPs do passively log unencrypted DNS requests, so replacing their DNS with things like quad9 and not using dot/doh is mostly pointless, but the question was: will the isp hijack the response? I've never heard of one doing that, you?

When in doubt, rely on Comcast for an example of bad behavior:

https://arstechnica.com/tech-policy/2009/08/comcasts-dns-red...

At the ISP level, does it really matter that they can sniff my queries/SNI? They're just as capable of seeing the IP4/6 I'm connecting to and rDNSing that to know the hostname. SNI gets them past the multiple sites on a single IP, but even encrypted Hello might only hide your activities in the vanishingly rare instances where IPs are actually shared. The obvious analogy is sending postal mail to an address without the recipient's name: it's still pretty obvious who you're communicating with.

Maybe I'm just bitter because I've found DoH (and even DoT) to be slow and occasionally unreliable. Even using Cloudflare, which is my fastest DNS, I see my local caches hitting strange resolve errors or in the minimum, durations 4-10x slower than good old UDP.

> At the ISP level, does it really matter that they can sniff my queries/SNI? They're just as capable of seeing the IP4/6 I'm connecting to and rDNSing that to know the hostname.

Shared hosting breaks that. If I connect to an IP used by AWS, Akamai, Fastly, etc. there are literally millions of things I could be using but the SNI header will tell them which one.

As a practical example, if a school administrator in Texas sees a connection to 104.16.12.208 they only know that someone is connecting to one of the millions of sites behind Cloudflare. SNI tells them it’s Planned Parenthood and they can call the police to report an offense against the church.

I can't find it right now, but there was a study about this that concluded shared hosting actually mostly doesn't break IP to domain correlation.

They MITM all DNS requests no matter the destination DNS server and hijack them. (Clarification: every ISP can. Some, but not all, actually do so.)

> Some, but not all, actually do so

Can you name one that does?

That really depends.

While that could very well be the case, I find it funny people tend to assume their ISP does this, and also assume that trusting large corporates (often outside the jurisdiction they are in and subject to foreign law enforcement requests) with that data is better than their ISP.

In the absence of widely-deployed ECH the ISP can potentially still see all hostnames visited from SNI field.

Some fears you commonly hear about from US users, like ISPs selling user browsing data, is illegal in other territories like the EU. So this calculation is different in various contexts. Where ISPs are not able to monetize it you would wonder what the business case for the (very expensive) snooping of queries is.

I wanted to, but the classic villain, systemd, fights its damndest to retain control of local DNS resolution.

If there was a bulletproof, straightforward way to run it, I am there (not Nix). I probably gave up too early, but my initial attempts with Unbound broke all internet access until I was able to reverse my configuration.

Why not permit systemd-resolved to act as the local resolver along with resolved.conf? You can use Unbound listening on whatever is free on (ipv4)127.0.0.0/8 and (ipv6)[:1]:9953 (or any other free port), and configure resolved.conf to use that local address as the "upstream" DNS= option.

You're probably going to still need Unbound to talk to an encrypted DNS server on the Internet (DoH or DoT), or else your ISP will be capable of intercepting and manipulating your queries.

https://www.freedesktop.org/software/systemd/man/systemd-res...

https://www.freedesktop.org/software/systemd/man/resolved.co...

That feels like a brilliant strategy. Theoretically only ever requiring a one line configuration change if I ever need to reverse it.

It would be a lot better if systemd would play nicely, but this is pretty minimal jank.

You can make /etc/resolv.conf immutable using chattr +i and then nothing can mess with your DNS. Of course if your apps aren't using /etc/resolv.conf and going direct to systemd-resolved then you'll have to deal with that instead of unbound/kresd/etc.

See, that feels like bandaging over the problem. A solution that is probably fine, until it is not.

Auth dns is a different beast. There are efforts in the IETF to work on it:

https://datatracker.ietf.org/doc/draft-ietf-dprive-unilatera...

The average user is not capable of running that themselves.

Further, DNS really benefits from caching as it scales up. As someone who runs my own resolver locally myself, I can attest to the sometimes long delay to resolve a hostname (requiring multiple external requests as the tree from root server is recursively queried).

I still run my own recursive resolver, I find it the best option overall, so ultimately I agree with your statement. But like anything there are trade-offs.