Diagnosing ISP DNS hijacking when standard resolvers fail

Karthikey Hegde discovered that his Podman container could not reach a specific website, despite standard troubleshooting steps. Queries sent to major public resolvers like Google and Cloudflare all returned an IP address owned by his Internet Service Provider (ISP), while encrypted DNS revealed the correct destination. This incident highlights a critical vulnerability for self-hosters: changing your DNS server settings often provides no protection if your ISP intercepts traffic on port 53.

What happened

Hegde’s investigation began when a service in his local environment failed to resolve a domain name. He tested multiple public DNS resolvers, including 1.1.1.1, 8.8.8.8, and 9.9.9.9. Surprisingly, every plaintext query returned the same IP address, which a WHOIS lookup confirmed belonged to his ISP. When he used Cloudflare’s DNS over HTTPS (DoH) endpoint, the query returned the legitimate IP address for the target site. This discrepancy proved that his ISP was actively intercepting and rewriting UDP DNS packets on port 53, regardless of the resolver address specified.

This behavior renders common advice ineffective. Telling users to switch to 1.1.1.1 or 8.8.8.8 assumes the ISP will faithfully forward those packets. In reality, unauthenticated UDP traffic on port 53 can be intercepted by any network device along the path. As noted in technical discussions surrounding the incident, UDP DNS interception is trivial for network operators. The ISP’s equipment simply captures the packet and replies with a forged response, making it appear as though the requested resolver provided the incorrect data.

Key details

• Plaintext DNS queries on port 53 lack authentication, allowing ISPs to intercept and rewrite responses easily.
• Multiple public resolvers returning the same incorrect IP suggests a single point of interception, not independent resolver errors.
• DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt queries, preventing in-transit modification by intermediate networks.
• A mismatch between plaintext and encrypted DNS results requires verification via WHOIS to distinguish tampering from CDN geography.
• Only about 7.1% of graded domains were DNSSEC signed and valid as of November 2026, limiting detection coverage.
• Self-hosted recursive resolvers like Unbound are also vulnerable if they forward queries via plaintext UDP on port 53.

Background

DNS resolution traditionally relies on UDP port 53, a protocol designed for speed rather than security. It does not verify the identity of the responder or the integrity of the data. When you configure a device to use a specific DNS server, your operating system sends a request to that IP address. However, without encryption, any router or firewall between your device and the intended resolver can read the query and inject a fake answer. This is known as DNS hijacking or spoofing.

Encrypted DNS protocols like DoH and DoT wrap these queries in TLS, similar to how HTTPS secures web browsing. This prevents network operators from seeing or altering the content of the query. However, adoption is not universal. Many self-hosted setups still rely on plaintext forwarding for simplicity or compatibility. Additionally, DNSSEC adds a layer of cryptographic validation to ensure data integrity, but it requires both the domain owner to sign records and the resolver to validate them. With only a small fraction of domains supporting DNSSEC, it remains an incomplete shield against hijacking.

Why it matters

For teams running self-hosted software, reliable DNS resolution is foundational. If your ISP hijacks DNS, your internal services may fail to connect to external APIs, package repositories, or update servers. More critically, you might be directed to malicious servers controlled by the interceptor. While ISPs often claim this is for filtering or caching, the lack of transparency means you cannot trust the routing. Standard monitoring tools may report services as "down" when they are merely unreachable due to incorrect DNS resolution, leading to wasted troubleshooting time.

Furthermore, relying on public resolvers without encryption gives a false sense of security. System administrators often assume that pointing their firewall or router to 1.1.1.1 secures their DNS traffic. This incident proves that assumption wrong. If your ISP is aggressive enough to intercept port 53 traffic globally, your choice of upstream resolver is irrelevant unless you enforce encryption at the edge of your network. This affects everything from container orchestration to simple cron jobs that fetch external data.

What you can do

• Test for hijacking by comparing plaintext dig results against a DoH endpoint like Cloudflare’s for a failing domain.
• Verify ownership of suspicious IP addresses using WHOIS lookups to confirm if they belong to your ISP.
• Implement DNS over HTTPS or DNS over TLS on your local resolver, such as configuring AdGuard Home with dnscrypt-proxy.
• Avoid using port 5353 for encrypted DNS proxies to prevent conflicts with multicast DNS services like Avahi.
• Configure Unbound to forward queries over TLS by specifying forward-tls-upstream: yes and providing a CA bundle.
• Use tools like OONI to perform independent measurements if you suspect broader network interference beyond DNS.