An ISP’s DNS interference gave itself away when an encrypted lookup returned another address

Changing the DNS provider did not change the answer. Karthikey Hegde was troubleshooting a Podman container that could not reach an external site. Ordinary lookups against several providers kept producing the same address. A request through Cloudflare’s DNS-over-HTTPS endpoint produced a different one. The detour had finally left a forwarding address.

In his firsthand account, Hegde says the address returned by the ordinary lookups belonged to his ISP. That is the evidence behind his description of DNS hijacking. It is a report of his connection and his troubleshooting, not an independently reproduced finding about every customer of an identified provider. The post does not name the ISP, so attaching a familiar villain would be casting without an audition.

The important difference was how the request traveled. Selecting a different resolver while still sending ordinary plaintext DNS did not stop an intermediary from interfering. An encrypted request changed that path’s exposure. Choosing a new destination and protecting the trip are separate decisions; a new address on a postcard does not stop the carrier reading it.

Hegde tackles a familiar reply, “Just use DNSSEC,” by distinguishing validation from encryption. DNSSEC can authenticate signed DNS data when validation succeeds. It does not encrypt the lookup’s contents. For a signed domain, a validating resolver can refuse a tampered response instead of handing back the false address. That is a meaningful protection, but it cannot be generalized into encryption or complete coverage for unsigned domains.

The post also explains why a locally run recursive resolver does not automatically solve transit exposure. That resolver still has to ask other nameservers for information, traditionally over plaintext DNS. Local ownership of the first box does not turn every upstream connection into a private one. The home-server badge comes with plenty of privileges; invisibility is sold separately (of course it is).

Encrypted DNS has its own boundary. DNS-over-HTTPS and DNS-over-TLS protect the connection to a chosen resolver, while that resolver still handles the query. Hegde explicitly points out that trusting a different party remains part of the arrangement. Advertising the change as total privacy would conceal the very dependency the fix introduces.

His practical setup uses AdGuard locally with dnscrypt-proxy for upstream requests, plus a fallback resolver for containers where a local DNS failure would be particularly disruptive. The post connects that fallback to a specific maintenance risk: an update that breaks local DNS should not drag every dependent container into the same outage. It is an availability decision alongside the privacy decision.

Someone investigating similar symptoms could compare answers for the same hostname through ordinary and encrypted paths, then check the ownership of any surprising address. A difference deserves investigation rather than an instant public accusation; configuration and caching can also affect answers. The next useful evidence would be a reproducible trace of the particular interference. Merely changing the resolver field had already proved too quiet a change to notice.

The ISP returned its own address.