How Do You Detect and Fix DNS Hijacking?

If sites are loading to unexpected pages or logins are being intercepted, your DNS may be hijacked. The fastest confirmation: run dig @8.8.8.8 example.com and compare the result to what your default resolver returns — a mismatch points directly at a rogue resolver. The fix depends on where the hijack lives: your router, your device, your ISP, or malware on the machine.

What DNS Hijacking Is

DNS hijacking substitutes a legitimate resolver with one controlled by an attacker. Instead of your query reaching a real recursive resolver and returning the correct IP, a rogue resolver answers with a fabricated address. Your browser connects to that IP, which may host a phishing clone, an ad injection page, or a credential-harvesting login screen that looks identical to the real site.

DNS hijacking differs from cache poisoning: poisoning corrupts the cache of a legitimate resolver with forged records; hijacking replaces the resolver itself. Both result in your device connecting to a rogue IP, but the diagnosis and fix path differ significantly.

Root Causes, Ranked by Frequency

1. Compromised Router

The most common cause by a wide margin. An attacker — through an exposed management interface, a default or weak admin password, or an unpatched firmware vulnerability — modifies the WAN DNS settings on your router. Every device on the network then inherits the rogue resolver through DHCP. Affected devices appear normal: their DNS is set to "automatic" and the router simply handed them a bad server IP. Some campaigns deliver this attack via cross-site request forgery, where visiting a single malicious page while your browser session is authenticated to the router admin panel is enough to change DNS settings silently, with no login required by the attacker.

2. Malware on a Single Device

Malware modifies either the network adapter's DNS configuration or the hosts file to hardcode IPs for specific domains. This affects only the infected device. On Windows, the hosts file is at C:\Windows\System32\drivers\etc\hosts. On Mac and Linux it is at /etc/hosts. A single injected line redirecting a banking domain can persist unnoticed for months.

3. ISP Transparent DNS Proxy

Some ISPs intercept all DNS queries on port 53 regardless of which resolver you configure. When you query 8.8.8.8, the ISP's proxy intercepts the packet and answers from its own resolver. You believe you are using Google's DNS; you are not. This is detectable by querying a resolver over DoT or DoH and comparing the result against a plain UDP query to the same IP.

4. Rogue DHCP Server

On a corporate network or shared Wi-Fi, a compromised device may be advertising itself as a DHCP server and distributing attacker-controlled DNS settings. Any client that receives a lease from the rogue server has its DNS hijacked without any compromise of the legitimate router.

5. BGP Route Manipulation

An attacker announces a more specific BGP prefix for a public DNS resolver's IP range, pulling queries to infrastructure they control. This is rare and mostly affects large operators, but it explains cases where switching to 8.8.8.8 does not fix the problem — the IP itself is being rerouted upstream before reaching Google's network.

Step 1: Confirm Your DNS Is Hijacked

Before changing any settings, gather evidence. On a system with dig installed (Mac, Linux, or Windows with BIND tools), run:

Compare the A record in the ANSWER SECTION. If the first response returns a different IP than the second and third, your default resolver is returning fabricated data. On Windows without dig, use nslookup:

If all three agree, the resolver is likely clean — proceed to checking the hosts file in Step 2.

Step 2: Find Where the Hijack Lives

Check Your Device's Active DNS Server

On Windows, open a command prompt and run:

Find the DNS Servers line under the active network adapter. An unfamiliar RFC 1918 address that is not your router's gateway IP is a red flag. On Mac:

On Linux with systemd-resolved:

On Linux without systemd-resolved:

Check Your Router's DNS Settings

Log in to your router's admin panel. Common default addresses: most home routers answer at 192.168.1.1 or 192.168.0.1. Branded access points use: TP-Link at tplinkwifi.net, ASUS at asusrouter.com, Netgear at routerlogin.net, Linksys at linksyssmartwifi.com, Xiaomi/MiWiFi at miwifi.com, Netgear Orbi at orbilogin.com.

Navigate to WAN or Internet settings and look for a DNS field. If it contains an IP you do not recognize — one that is not your ISP's documented resolver and not a known public resolver such as 8.8.8.8 or 1.1.1.1 — the router DNS has been changed. Also check the LAN/DHCP settings for a DNS server being pushed to clients that differs from the WAN DNS entry.

Menu paths vary by firmware version. On TP-Link (current firmware): Advanced > Network > Internet > DNS. On ASUS: WAN > Internet Connection > WAN DNS Setting. On Netgear: Settings > Internet > Domain Name Server (DNS) Address. On Linksys (current firmware): Connectivity > Internet Settings. On routers running OpenWrt, check Network > DHCP and DNS. On DD-WRT, look under Setup > Basic Setup for the Static DNS fields. If your interface does not match these, search the manufacturer's support pages for your exact model number — do not guess menu labels.

Check the Hosts File

On Windows, open Notepad as administrator and open C:\Windows\System32\drivers\etc\hosts. On Mac and Linux:

Any non-comment line — a line not starting with # — that maps a real domain name to an unexpected IP is a hijack entry. A clean hosts file contains only two active lines: 127.0.0.1 localhost and ::1 localhost.

Step 3: Fix the Hijack

Compromised Router

1. Change the router admin password immediately — before adjusting DNS settings. An attacker with persistent access will undo any changes you make first.
2. Apply any available firmware update. Navigate to Administration or System settings in the admin panel, or check the manufacturer's support page for your model number.
3. Navigate to WAN DNS settings and replace the rogue IP with a trusted public resolver: 8.8.8.8 / 8.8.4.4 (Google), 1.1.1.1 / 1.0.0.1 (Cloudflare), or 9.9.9.9 / 149.112.112.112 (Quad9).
4. If the router behaves erratically or you cannot determine the full extent of the changes made, perform a factory reset — typically a recessed button held for 10 seconds — then reconfigure from scratch with a strong password before reconnecting to the internet.
5. Disable remote (WAN-side) management unless you have a specific operational need for it.
6. Disable UPnP unless your devices require it. UPnP has been exploited by malware to modify router DNS settings without requiring the admin password.

Malware-Modified Device

1. Run a full scan in safe mode or from offline boot media. DNS-hijacking malware often restores its own settings when the OS is running normally, defeating live-mode scans.
2. After cleaning, set DNS manually. On Windows: Control Panel > Network and Internet > Network Connections > right-click your active adapter > Properties > Internet Protocol Version 4 (TCP/IPv4) > Properties > select "Use the following DNS server addresses" > enter 8.8.8.8 and 8.8.4.4.
3. On Mac: System Settings > Wi-Fi or Ethernet > Details > DNS. Remove all existing entries and add 1.1.1.1 and 1.0.0.1.
4. On Linux (systemd-resolved): edit /etc/systemd/resolved.conf, add DNS=1.1.1.1 1.0.0.1 under the [Resolve] section, then run systemctl restart systemd-resolved.
5. Restore the hosts file to its clean default: remove every non-comment line except the two localhost entries.

ISP Transparent Proxy Interception

If your ISP intercepts port 53 traffic, switching DNS IPs in your network settings does nothing — the proxy catches the packet before it leaves their network. The fix is to encrypt your DNS queries so the proxy cannot intercept them:

1. Enable DNS over HTTPS in your browser. Firefox: Settings > Privacy and Security > DNS over HTTPS. Chrome/Edge: Settings > Privacy and security > Security > Use secure DNS.
2. On Windows 11: Settings > Network and internet > Wi-Fi or Ethernet > DNS server assignment > Edit > Manual > enable Preferred DNS encryption.
3. On Android 9 and later: Settings > Network and internet > Private DNS. Enter a DoT hostname such as dns.google or one.one.one.one.
4. On iOS 14 and later: DoH/DoT requires installing a DNS configuration profile from your provider. Cloudflare and Quad9 both publish signed profiles for download on their official sites.

How to Confirm the Fix Worked

Flush your DNS cache and repeat the comparison queries from Step 1.

On Windows:

On Mac:

On Linux:

All queries should now return the same IP. If they still diverge, there is another hijack point you have not found. Re-check the hosts file, run another malware scan, and confirm the router settings actually saved — some firmware requires an explicit Apply or Save step that is easy to skip.

Preventing Recurrence

• Set a strong, unique router admin password at initial setup. Default credentials are publicly indexed for every major model and are the first thing automated attack tools try.
• Keep router firmware current. Most DNS hijacking campaigns targeting home routers exploit known, unpatched vulnerabilities for which the vendor has already released a fix.
• Disable UPnP unless your devices specifically require it.
• Disable WAN-side remote management unless needed. If you must enable it, restrict access to a specific trusted IP address.
• Enable DoH or DoT. Encrypted DNS blocks transparent proxying and makes interception attacks substantially harder at both the ISP and router level.
• Use a DNSSEC-validating resolver. Quad9 (9.9.9.9) and Cloudflare (1.1.1.1) validate DNSSEC by default, rejecting forged responses even when the underlying query transport has not been encrypted.
• Audit your hosts file when investigating any persistent redirect. Malware-injected entries are often overlooked because they target only a handful of high-value domains rather than all traffic.

Common Misdiagnoses

Slow DNS vs. Hijacked DNS

Slow page loads without redirects are almost never DNS hijacking. Run dig example.com and check the query time in the statistics output. If it is consistently above 200–300ms but the returned IP matches what 8.8.8.8 returns, you have a slow resolver, not a hijacked one. Switch to a faster public resolver and move on.

NXDOMAIN Search Redirect

When you type a nonexistent domain into a browser address bar, some ISPs serve a search results or advertising page rather than an NXDOMAIN error. This is technically DNS interception, usually disclosed in ISP terms of service, and applies only to nonexistent domains. Distinguish it from a real hijack: query a real domain and compare with 8.8.8.8. If only lookups for nonexistent domains differ, it is NXDOMAIN redirect, not an attack on live traffic.

Captive Portal on Public Wi-Fi

Hotel and coffee shop networks intercept HTTP traffic — and sometimes DNS — to redirect you to a login page. This presents identically to hijacking in a browser. If you are on a known public network and the behavior stops after authenticating, it is a captive portal, not a compromise.

Browser DNS Cache

Browsers maintain a DNS cache independent of the OS. A domain that resolved to a hijacked IP may continue loading from browser cache after you fix the underlying resolver. In Chrome and Edge, navigate to chrome://net-internals/#dns and click Clear host cache to flush it immediately.

2026 Update: Encrypted DNS and DNSSEC

Widespread adoption of DNS over HTTPS has substantially reduced the effectiveness of plain port-53 interception. DoH traffic is carried inside TLS on port 443, indistinguishable from ordinary HTTPS, meaning a proxy that listens only on port 53 misses it entirely. Router-level hijacking still works against DoH clients if the attacker modifies the router's upstream resolver before DoH negotiation begins, or executes a TLS man-in-the-middle attack using a forged certificate — but both require substantially more access than a simple DNS settings change.

DNSSEC adds cryptographic proof that a DNS response has not been tampered with in transit. A validating resolver rejects responses whose signatures do not verify, blocking cache poisoning and some response injection attacks. As described in Cloudflare's DNS reference, DNSSEC covers integrity, not privacy — it does not encrypt the query itself. Full protection requires combining DNSSEC validation with DoH or DoT. Quad9 (9.9.9.9) provides both by default. For the foundational protocol specification behind all DNS resolution, see RFC 1035.

IPv6 is a commonly overlooked attack surface. Hardening IPv4 DNS while leaving IPv6 DNS at ISP defaults means any dual-stack client is still exposed through the IPv6 path. Set both IPv4 and IPv6 DNS entries explicitly in your router's WAN configuration and LAN/DHCP settings. On OpenWrt and DD-WRT, the dnsmasq configuration section allows you to enforce DoT forwarding for all downstream clients, overriding whatever DNS server an individual device requests independently.