DNS NXDOMAIN hijacking happens when a DNS resolver, instead of returning an NXDOMAIN (Non-Existent Domain) error for a query it can’t resolve, redirects the user to a different, often malicious, website. This is typically done by manipulating the DNS resolution process, either on the client-side or by compromising the DNS server itself.
Let’s see this in action. Imagine a user tries to visit a non-existent domain, this-domain-definitely-does-not-exist-12345.com.
Normally, their system would query a DNS resolver. If that resolver has no record for this-domain-definitely-does-not-exist-12345.com, it should respond with an NXDOMAIN.
dig this-domain-definitely-does-not-exist-12345.com
; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> this-domain-definitely-does-not-exist-12345.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;this-domain-definitely-does-not-exist-12345.com. IN A
;; AUTHORITY SECTION:
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2021010100 7200 3600 604800 86400
;; Query time: 50 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Jan 01 12:00:00 UTC 2023
;; MSG SIZE rcvd: 98
Notice the status: NXDOMAIN. This is the correct, expected response.
Now, if NXDOMAIN hijacking is in play, the user might instead be redirected to a page like http://www.hijacked-search-results.com or http://www.malicious-ads.net. The dig command might still report NXDOMAIN, but the browser experience is entirely different. This is because the resolver is returning a different IP address than it should, or it’s returning a valid IP that then performs a redirect.
The core problem NXDOMAIN hijacking solves is a security vulnerability where unresolvable domain requests are exploited for malicious purposes. Attackers can intercept these requests and redirect users to phishing sites, malware distribution pages, or ad-filled portals. This exploits the fact that users often don’t pay close attention to the exact URL they are visiting, especially if they mistype something.
Understanding how this works involves tracing the DNS resolution path. When you type a domain into your browser, your operating system first checks its local cache. If not found, it queries your configured DNS resolver (often provided by your ISP, router, or a public service like Google DNS or Cloudflare). This resolver then recursively queries other DNS servers until it either finds the IP address or determines the domain doesn’t exist. Hijacking can occur at any point in this chain where the resolver is compromised or its configuration is manipulated.
The levers you control are primarily your DNS resolver configuration and the security of your network. You can choose to use trusted, public DNS resolvers known for their security features, or you can set up your own DNS server and secure it. On the client-side, ensuring your operating system and browser are up-to-date and free from malware is crucial, as some hijacking techniques involve injecting malicious code into your machine.
One significant aspect of NXDOMAIN hijacking is that it can be incredibly subtle. A user might simply think they’ve mistyped a URL and end up on a seemingly legitimate search engine or portal that looks almost like what they intended. This social engineering aspect is a key component of its effectiveness. The hijacking mechanism often involves the DNS server returning a valid IP address for a non-existent domain, and that IP address hosts a web server configured to respond to any hostname by showing a specific page. This is sometimes referred to as "wildcard DNS" or "catch-all DNS" misconfiguration, but in the context of hijacking, it’s intentionally malicious.
To detect and block NXDOMAIN hijacking, you need to monitor your DNS traffic for unusual patterns. Tools like tcpdump or Wireshark can capture DNS packets. Look for queries that return a valid IP address but are for domains that you know or suspect should not exist. A common indicator is seeing many NXDOMAIN queries suddenly resolving to the same IP address, or to a known malicious IP range.
The most robust way to block it is to ensure you are using a DNS resolver that actively defends against this. Many public DNS providers offer features to block known malicious domains and IPs, and some specifically address NXDOMAIN hijacking by returning true NXDOMAIN responses or by using DNSSEC to validate responses. If you manage your own DNS server (e.g., BIND, Unbound), you can configure it to be more strict. For BIND, you can use dnssec-enable yes; and dnssec-validation auto; in your options block to enable DNSSEC validation, which cryptographically verifies the authenticity of DNS records. For Unbound, ensure val-clean-additional: yes is set and harden-dnssec-stripped: yes is enabled.
If you suspect your ISP’s DNS is hijacking, you can switch your client devices or router to use public DNS servers. On Linux, you’d edit /etc/resolv.conf and replace nameserver 127.0.0.53 (or your ISP’s DNS) with nameserver 8.8.8.8 (Google DNS) and nameserver 1.1.1.1 (Cloudflare DNS).
# Example /etc/resolv.conf for public DNS
nameserver 8.8.8.8
nameserver 1.1.1.1
This forces your system to use these external, trusted resolvers, bypassing any potential manipulation by your ISP. The dig command on your local machine will now query these external servers.
The next issue you’ll likely encounter after securing your DNS resolution is dealing with DNS spoofing attacks that target existing domains.