Most DNS attacks people know about involve changing where a domain points: cache poisoning, hijacking, subdomain takeover. But two of the more insidious DNS attack techniques work differently. DNS rebinding turns a victim's own browser into a tool for reaching systems it should never be able to touch. NXDOMAIN hijacking exploits the moment when a domain doesn't exist, turning "not found" into an opportunity for manipulation. Neither is as widely understood as it should be, and both remain relevant threats.
These attacks are worth understanding because they exploit legitimate DNS behavior rather than breaking it. They don't require compromising your nameservers or stealing credentials. They abuse the way DNS and browsers are designed to work, which makes them harder to spot and defend against.
This guide explains both attacks, how they work, who they target, and what defends against them.
DNS Rebinding: Turning a Browser Against Its Own Network
DNS rebinding is an attack that lets a malicious website bypass the browser's same-origin policy to interact with devices and services on the victim's local network, the very systems a remote attacker normally can't reach.
The Problem It Exploits
Browsers enforce a same-origin policy: a script from evil.com can't read responses from yourcompany-internal.local or 192.168.1.1. This is a fundamental web security boundary. But the same-origin policy is based on the hostname, not the IP address. DNS rebinding exploits the gap between the two.
How the Attack Works
-
The victim visits a malicious site. They load
attacker.com, perhaps through an ad, a link, or a compromised page. The attacker controls the DNS for this domain. -
The first DNS response is legitimate. When the browser resolves
attacker.com, the attacker's nameserver returns the attacker's real server IP, with a very short TTL (a few seconds). The malicious JavaScript loads and runs. -
The attacker "rebinds" the domain. After the page loads, the short TTL expires. The malicious script makes another request to
attacker.com. This time, the attacker's nameserver responds with a different IP, an internal address like192.168.1.1(the victim's router) or127.0.0.1(their own machine). -
The browser now talks to the internal target. As far as the browser's same-origin policy is concerned, the script is still talking to
attacker.com, the origin hasn't changed. But the requests now go to the internal IP. The attacker's script can now interact with the victim's router admin panel, local services, internal APIs, or IoT devices, reading responses and sending commands.
The attack effectively uses the victim's browser as a proxy into their own private network, defeating the network boundary that would normally protect those internal systems from the internet.
What DNS Rebinding Targets
- Router and gateway admin interfaces (often at predictable IPs like 192.168.1.1 with default or weak credentials)
- IoT and smart home devices with local web interfaces and little authentication
- Internal services and APIs that assume "if you can reach me, you're trusted" because they're not exposed to the internet
- Local development servers and admin tools running on the victim's own machine
The core danger is that many internal services have weak or no authentication precisely because they rely on network isolation for protection. DNS rebinding breaks that isolation.
Defending Against DNS Rebinding
- DNS rebinding protection in resolvers: Many resolvers and DNS filtering services can block responses where an external domain resolves to a private/internal IP address. This is the most effective network-level defense. Some routers and resolvers (and tools like a configured Pi-hole or NextDNS) offer this.
-
Host header validation: Internal services should validate the
Hostheader and reject requests that don't match their expected hostname. Since the rebinding attack sends requests with the attacker's domain in the Host header, strict validation blocks them. - Authentication on internal services: Never rely solely on network isolation. Internal admin panels, routers, and APIs should require authentication, so reaching them isn't enough to control them.
- HTTPS on internal services: TLS certificate validation adds another barrier the attack must overcome.
NXDOMAIN Hijacking: Exploiting "Does Not Exist"
NXDOMAIN is the DNS response code meaning "this domain does not exist." NXDOMAIN hijacking (also called NXDOMAIN substitution or redirection) is the practice of intercepting these "does not exist" responses and replacing them with something else, usually a page the interceptor controls.
How It Works
When you type a domain that doesn't exist, you should get an NXDOMAIN response and your browser shows an error. In NXDOMAIN hijacking, an intermediary, often an ISP or a resolver, intercepts that NXDOMAIN and instead returns an IP address pointing to their own server, typically showing a search page, ads, or a "did you mean?" page.
This was historically common among ISPs, who monetized typos and mistyped domains by redirecting NXDOMAIN responses to ad-laden search pages. While it might seem like a minor annoyance, it has real security implications.
Why It's a Security Problem
- It breaks the expected "does not exist" signal. Applications and security tools that rely on NXDOMAIN to detect non-existent domains get a false "this exists" answer, which can mask problems or break functionality.
- It creates an injection point. An intermediary substituting DNS responses is, by definition, manipulating your traffic. If that intermediary is malicious or compromised, the same mechanism used for ad redirection can be used to redirect real traffic.
- It interferes with security mechanisms. Some security and anti-malware systems use NXDOMAIN responses as signals. Substituting them can blind these systems or cause false results.
- It can expose user behavior. The intermediary sees every mistyped or non-existent domain a user queries, a privacy concern.
NXDOMAIN and Attack Detection
There's an important defensive flip side. Monitoring NXDOMAIN patterns is actually a useful security signal. A sudden spike in NXDOMAIN responses from inside a network can indicate malware using a domain generation algorithm (DGA), where malware algorithmically generates many candidate domains to find its command-and-control server. Most generated domains don't exist (NXDOMAIN), so a flood of NXDOMAIN responses is a red flag. NXDOMAIN hijacking that masks these responses can hide this signal, which is another reason it's problematic.
Defending Against NXDOMAIN Hijacking
- Use a trustworthy resolver. Reputable public resolvers (and properly configured private ones) return honest NXDOMAIN responses rather than substituting them. Choosing a resolver that doesn't hijack NXDOMAIN is the first step.
- Use encrypted DNS (DoH/DoT). DNS over HTTPS and DNS over TLS prevent on-path intermediaries from seeing and modifying your DNS queries and responses, blocking the interception that NXDOMAIN hijacking relies on. We cover these in our DoH vs DoT guide.
- DNSSEC for your own domains. While DNSSEC doesn't directly stop NXDOMAIN substitution for domains you query, it does cryptographically authenticate responses for signed domains, including authenticated denial of existence (proving a name really doesn't exist), which prevents forged NXDOMAIN-related manipulation for your zones.
What These Attacks Have in Common
DNS rebinding and NXDOMAIN hijacking both share a defining characteristic: they exploit DNS as a manipulation layer rather than attacking DNS records directly. They don't change your A record or compromise your nameserver. Instead, they abuse the resolution process itself, the short-TTL re-resolution in rebinding, the response substitution in NXDOMAIN hijacking.
This makes them different from the attacks much of DNS security focuses on. They're a reminder that DNS security isn't only about protecting your own records from unauthorized change; it's also about the integrity of the resolution process that connects users to your domain, and the systems that process DNS responses.
How DNS Assistant Fits In
DNS Assistant focuses on monitoring the security posture of your own domains, the authoritative side of DNS. While rebinding and NXDOMAIN hijacking are primarily resolver-side and client-side attacks, strong posture on your own domains is part of the broader defense:
- DNSSEC validation monitoring ensures your domains are properly signed, enabling authenticated denial of existence and protecting against forged responses for your zones.
- Record monitoring ensures your legitimate records are correct and unchanged, so the authoritative answers feeding resolvers are trustworthy.
- Continuous validation of your DNS configuration, with alerting via email, Slack, Microsoft Teams, webhooks, and SMS.
Defending against rebinding and NXDOMAIN hijacking primarily involves resolver choice, encrypted DNS, internal service authentication, and host-header validation, but maintaining strong DNSSEC and record integrity on your own domains is the authoritative-side contribution to a healthy DNS ecosystem.
Check Your DNS Posture
Verify your domains are properly signed with DNSSEC and your records are correct using the DNS lookup tool at dnsassistant.com/tools, or run a Free Domain Risk Report for a comprehensive view including DNSSEC status.
For continuous monitoring of your DNS security posture with real-time alerting, sign up at dnsassistant.com.
This article describes attack techniques for educational and defensive purposes, to help you understand and protect against them. The information reflects publicly documented security research on DNS rebinding and NXDOMAIN manipulation.