What Is DNS Hijacking?
DNS hijacking is any attack or technique that causes the DNS resolution process to return a false IP address for a domain name. Instead of receiving the legitimate IP address published by the domain's authoritative nameserver, your device receives an attacker-chosen address pointing to a different server — one the attacker controls. From your browser's perspective, you appear to be visiting the correct domain. The URL in your address bar may look right. But the server you are actually communicating with is not the real one.
This makes DNS hijacking an exceptionally powerful attack primitive. It underpins phishing campaigns that clone legitimate banking and e-commerce sites, credential harvesting operations, malware distribution networks, and censorship infrastructure deployed by nation-states and ISPs. Because most users never verify that a domain resolved to the correct IP address, hijacking can go undetected for extended periods.
Type 1: Local DNS Hijacking
Local DNS hijacking occurs when malware running on your device directly modifies the DNS configuration in your operating system. On Windows, this typically means altering the DNS server address in the network adapter settings — replacing your ISP's or a public resolver's address with an attacker-controlled server. On macOS and Linux, malware may modify /etc/resolv.conf or equivalent configuration files. Once the local DNS settings are changed, every DNS query from that device is sent to the malicious resolver, which can return any IP address the attacker chooses for any domain.
Local hijacking is particularly insidious because it operates below the browser level — it affects all applications on the device, not just web browsers. Antivirus software and regular security scans are the primary defenses, along with operating system hardening to prevent unauthorized changes to network configuration.
Type 2: Router DNS Hijacking
Router DNS hijacking compromises the DNS settings at your network gateway, affecting every device connected to that network simultaneously. Attackers gain access to a router's admin interface by exploiting weak or default passwords, unpatched firmware vulnerabilities, or through cross-site request forgery (CSRF) attacks that trick a user's browser into making admin requests while visiting a malicious website. Once inside, they change the router's configured DNS servers to point at a malicious resolver.
Because routers distribute DNS settings to connected devices via DHCP, every device on the network — phones, laptops, smart TVs, and IoT devices — begins using the attacker's resolver without any indication that anything has changed. A 2019 campaign targeting Brazilian users hijacked hundreds of home routers to redirect banking domains, demonstrating the scale at which this attack can be deployed. Changing your router's default admin password to a strong unique credential and enabling automatic firmware updates are essential protections.
Type 3: ISP DNS Hijacking
ISP-level DNS hijacking is technically not always malicious — some ISPs deliberately intercept DNS queries to redirect failed lookups (NXDOMAIN responses for non-existent domains) to monetized search pages showing advertisements. This practice is widely considered a form of DNS hijacking because it overrides the expected DNS behavior without user consent. More concerning is when ISPs intercept queries for existing domains and redirect them for censorship or surveillance purposes, which is common practice in some jurisdictions.
ISP DNS hijacking affects users regardless of which DNS server they configure on their devices, because some ISPs transparently intercept all UDP port 53 traffic at the network level and reroute it through their own resolvers. Switching to a public DNS server does not bypass this if your ISP operates a transparent DNS proxy. Using DNS over HTTPS or DNS over TLS is the effective countermeasure, because the encrypted traffic cannot be transparently intercepted and redirected without breaking the TLS authentication.
Type 4: Man-in-the-Middle DNS Hijacking
Man-in-the-middle (MITM) DNS hijacking occurs when an attacker positioned between your device and the legitimate DNS resolver intercepts queries and injects forged responses. On a local network, ARP poisoning or rogue Wi-Fi access point attacks place the attacker in this position. The attacker monitors DNS queries on UDP port 53, identifies queries for target domains, and sends a forged response with a malicious IP address before the legitimate resolver's response arrives. Because DNS accepts the first matching response it receives and has no built-in authentication, the forged answer wins.
Public Wi-Fi networks are particularly susceptible to this attack. DNS over HTTPS and DNS over TLS both defend against it because the TLS channel encrypts and authenticates the responses — a forged response cannot be injected without the resolver's private key.
DNS Cache Poisoning
DNS cache poisoning is a specific MITM-style attack targeting recursive resolvers rather than individual users. Exploiting predictable transaction IDs and source ports in older DNS implementations, an attacker can flood a resolver with thousands of forged responses, hoping one matches the transaction ID of an in-flight query before the legitimate response arrives. A successfully poisoned cache entry causes the resolver to return a false IP to all users who query that domain — potentially thousands or millions of users — until the cached entry expires.
The Kaminsky attack of 2008 demonstrated this could be accomplished in under a minute against unpatched resolvers. Modern resolvers randomize source ports and transaction IDs to make guessing impractical, and DNSSEC eliminates the attack entirely by requiring cryptographic proof of record authenticity that no attacker can forge without the zone's private key.
How to Detect DNS Hijacking
The most direct detection method is comparing expected and actual DNS responses. Use the dig or nslookup command to query a domain and note the returned IP address. Cross-check that IP against a trusted reference — for example, Cloudflare's IP ranges for domains served by Cloudflare. An unexpected IP is a strong indicator of hijacking. DNS leak test services such as dnsleaktest.com reveal which resolver is actually answering your queries, which may differ from what you configured if transparent DNS proxying is in effect. SSL certificate warnings on familiar sites — especially banking or shopping sites — are also a red flag, as the attacker's server may not have a valid certificate for the hijacked domain.
DNS Hijacking Attack Types at a Glance
| Attack Type | Attack Vector | What Is Compromised | What Attacker Can Do | Detection Method | Prevention |
|---|---|---|---|---|---|
| Local DNS hijack | Malware on device | Device DNS settings | Redirect all queries from that device | Check adapter DNS settings; antivirus scan | Antivirus, OS hardening, endpoint protection |
| Router DNS hijack | Weak router password, CSRF, firmware exploit | Router admin settings | Redirect all queries from all devices on network | Check router DNS config; DNS leak test | Strong router password, firmware updates |
| ISP DNS hijacking | ISP infrastructure | Resolver responses | Redirect NXDOMAIN or specific domains | DNS leak test; compare responses to 8.8.8.8 | Use DoH or DoT to bypass transparent proxy |
| MITM / cache poisoning | Network position; forged UDP responses | Resolver cache or in-flight query | Redirect domain for all resolver users | Verify returned IP; DNSSEC validation failure | DNSSEC, DoH/DoT, randomized source ports |
Frequently Asked Questions
How do I know if my DNS has been hijacked?
The most reliable method is to compare the IP address your DNS returns against the known correct IP for a domain. Use the dig or nslookup command to query a domain like google.com, then compare the returned IP to what a trusted source reports. If your DNS returns a different IP, your resolver may be compromised. You can also run a DNS leak test at dnsleaktest.com — it shows which resolver is answering your queries. Unexpected redirects to search pages when you mistype a URL, or warnings about SSL certificate mismatches on familiar sites, are also signs of DNS hijacking.
Can my router hijack my DNS?
Yes. Router DNS hijacking is one of the most common attack vectors. If an attacker gains access to your router's admin interface — through a weak password, an unpatched vulnerability, or a malicious script on a web page — they can change the router's DNS settings to point all devices on your network to a malicious resolver. That resolver then returns fake IP addresses for any domain, enabling phishing attacks against every device on your network simultaneously. Securing your router with a strong unique password and keeping its firmware updated are the primary defenses.
Does DNSSEC prevent all DNS hijacking?
No. DNSSEC prevents cache poisoning attacks — forged DNS responses injected into a recursive resolver's cache. A validating resolver that receives a DNSSEC-signed response with an invalid signature will reject it and return SERVFAIL instead. However, DNSSEC does nothing to prevent local DNS hijacking (malware on your device changing DNS settings), router hijacking (an attacker who already controls your router), or ISP-level DNS redirection. DNSSEC validates record authenticity; it does not encrypt transport or secure the local configuration of your device or router.
Does using 8.8.8.8 or 1.1.1.1 prevent DNS hijacking?
Switching to a public resolver like Google (8.8.8.8) or Cloudflare (1.1.1.1) protects against ISP-level DNS hijacking and redirections, since you bypass your ISP's resolver entirely. It also makes cache-poisoning attacks harder because these resolvers are well-maintained and respond quickly. However, it does not protect against router hijacking (your router can intercept and redirect traffic destined for 8.8.8.8 to a malicious server) or local DNS hijacking (malware can override which resolver your device uses). For stronger protection, combine a public resolver with DNS over HTTPS or DNS over TLS.
What is DNS cache poisoning?
DNS cache poisoning is an attack where a malicious actor injects a forged DNS response into a recursive resolver's cache, causing the resolver to return a false IP address for a domain to all users who query it. The classic method, demonstrated by Dan Kaminsky in 2008, exploited the fact that DNS uses predictable transaction IDs and source ports — an attacker who sent thousands of forged responses could guess the right combination and poison the cache before the legitimate response arrived. DNSSEC defeats cache poisoning by requiring cryptographic signatures on every record that resolvers must verify before caching.
How does DoH protect against DNS hijacking?
DNS over HTTPS protects against man-in-the-middle DNS hijacking by encrypting queries inside an authenticated HTTPS connection. An attacker on the network path cannot read, modify, or forge the DNS responses because they are protected by TLS encryption and the server's certificate is verified. This prevents the classic MITM attack where a device on the same network intercepts unencrypted UDP port 53 traffic and substitutes fake responses. DoH does not protect against router-level hijacking if the router redirects all traffic — including port 443 — to a malicious endpoint, which requires a compromised router to also have a valid TLS certificate for the resolver hostname.