DNS Hijacking: How It Works, How To Detect It, And How To Stop It

You type the right domain. The address bar looks normal. Then a customer sends a screenshot of a fake login page, a certificate warning, or a redirect to a site you have never seen.

That is what makes DNS hijacking so disorienting. The URL can be correct, but the lookup behind it can send visitors to the wrong server.

TL;DR: DNS hijacking redirects visitors from a real domain to the wrong server by tampering with DNS resolution. First, secure and restore DNS records, then scan WordPress for malware and harden accounts so a related compromise is not missed.

If this is happening now, do not start by changing random WordPress settings. First find out whether visitors are reaching your real server at all. The practical order is: check DNS from outside your own network, secure the account that controls DNS, restore the right records, then inspect WordPress, hosting, routers, and devices for anything connected to the incident.

What DNS hijacking is

DNS is the Internet’s address lookup system. When someone enters your domain, DNS tells the browser where to go for your website, email, CDN, or another service. DNS hijacking means that the answer is changed, forged, or intercepted. The visitor may type your real domain but land on a phishing page, malware page, ad page, or cloned version of your site.

For WordPress owners, the important part is simple: your WordPress files can be untouched while visitors are still sent away from your site. DNS sits before WordPress. If DNS points the browser somewhere else, your site may never see the request.

Normal DNS	Hijacked DNS
Your domain points to your real server or CDN.	Your domain points to a fake server, ad page, malware page, or unwanted destination.
Visitors reach your site.	Some or all visitors may never reach your site.
Hosting and WordPress logs usually reflect the traffic.	Logs may not match what visitors report.

The visible problem is usually a redirect, warning, or strange page, which can make DNS hijacking look like a website attack. The hidden problem is lower in the chain: who answered the DNS lookup, and what answer did they give?

Why it matters

People trust domains more than they should. If the address bar looks right, many users will enter passwords, payment details, email credentials, or private information before they notice anything odd. Attackers use DNS hijacking to send visitors to:

This is not only a website problem. DNS records also control email through MX records, service verification through TXT records, and many subdomains through CNAME records. A changed web record can steal visitors. A changed mail record can expose messages. A stale subdomain can point to an old service you no longer control.

That is why DNS incidents deserve calm urgency. Do not panic, but do not treat them like a cosmetic redirect either, especially when the symptoms overlap with signs that a website has been hacked.

DNS hijacking vs similar attacks

Security terms overlap, and that overlap wastes time during an incident. Use the distinction that changes your first move.

Threat	What changes	First response
DNS hijacking	DNS sends users to the wrong destination.	Find and restore the trusted DNS path.
DNS spoofing	A fake DNS answer is supplied.	Use trusted resolvers and validation.
DNS cache poisoning	A fake answer is stored by a resolver.	Clear or wait out cache and fix resolver exposure.
Domain hijacking	Attackers gain control of the domain registration or transfer.	Contact the registrar and recover ownership.
Domain shadowing	Attackers create malicious subdomains under your domain.	Remove the subdomains and secure DNS access.

The fastest diagnostic question is: who sees the wrong destination, and from where? That question separates resolver problems like DNS errors from account-level compromise. If everyone sees it, check the registrar and DNS-provider control first. If one office sees it, check the router. If one laptop sees it, check that device, then rule out browser or cookie stealing issues.

How DNS hijacking happens

DNS hijacking usually comes from one weak layer in the lookup chain. The mistake is assuming that every redirect must begin inside WordPress.

Registrar or DNS-provider access is stolen

This is the high-impact version. An attacker signs in to the registrar or DNS provider and changes name servers or records, which is one of the more damaging website hacking techniques. They may point your main web record to their own server, copy your login page, and collect passwords. Secure the account before restoring records. If the attacker still has access, they can change the records back.

Router DNS settings are changed

A router can tell every connected device which DNS server to use. It does this through DHCP, the system that hands network settings to devices when they join Wi-Fi or office internet. If your site works on mobile data but redirects on every office laptop, look at the router before you tear apart WordPress.

This can be selective. A compromised router may resolve most domains normally and only redirect banking, email, admin, or business-critical domains. That inconsistency is exactly why people lose time chasing the wrong cause.

One device is infected or misconfigured

Malware on a computer can change DNS settings, proxy settings, browser extensions, or the hosts file, a local file that can force a domain to resolve to a specific address. If only one person sees the wrong page, start with that device and change any exposed WordPress passwords after the machine is clean.

A resolver gives the wrong answer

A resolver is the DNS service that answers lookup requests for users. It may be run by an ISP, company network, router, or public DNS provider. If a resolver is compromised, poisoned, or serving an old answer, users who depend on it may see the wrong destination while others see the right site.

Old records are left behind

Not every hijack-like issue starts with a fresh break-in. Forgotten DNS records can become risk.

Old CNAME records, abandoned subdomains, expired domains, unused mail records, and stale vendor integrations are boring to audit. They are also how a domain can keep pointing at places nobody on the current team remembers.

Signs to take seriously

One odd symptom is not proof. A popup, slow page, or redirects can also come from WordPress malware, bad ads, browser extensions, caching, or CDN rules. Look for patterns that point to DNS:

Treat certificate warnings as high-signal during a suspected DNS incident. Do not tell users to click through them. A warning may mean the browser reached a server that is not yours.

What to check first

Your first job is not to fix everything. It is to locate the layer that is lying.

Cache can make recovery look messy. Browsers, operating systems, routers, resolvers, CDNs, and security tools may hold old answers for a while. A corrected record may not appear for every visitor at the same minute, even after you clear WordPress cache and local caches.

How to test for DNS hijacking

A useful DNS hijacking test compares what should happen with what different systems say is happening.

Start with a known-good baseline. Save the correct name servers, web records, mail records, TXT records, important subdomains, DNS account users, and API keys. If you did not have a baseline before, create one now from your host, DNS provider, registrar, and deployment records.

Then compare:

If DNS is clean but the site still redirects, the problem may be WordPress malware, a malicious plugin, an injected script, a CDN rule, or browser malware. That is where it helps to scan your WordPress site for malware with a tool such as MalCare and review broader WordPress security issues. It does not replace DNS recovery, but it can help confirm whether the site itself is also compromised.

How to remove a DNS hijack

Recovery starts with control. Do not only change the visible record. Close the access path that allowed the change.

The order matters. If an attacker still controls the DNS account, restoring the record is only a temporary pause.

MalCare fits the WordPress part of this recovery. If malware is found after DNS control is restored, use a website malware removal workflow, restore WordPress from a clean backup if rollback is safer, and harden the site so the DNS incident does not hide a site-level compromise.

How to prevent DNS hijacking

Prevention works best when each layer has its own protection. No single setting covers the registrar, DNS provider, router, resolver, device, hosting account, and WordPress site.

Lock down registrar and DNS access

Use a reputable registrar and DNS provider for important domains. Then protect the accounts that can change records.

Registry lock and client transfer lock add friction to domain changes or transfers. They do not replace account security.

Use DNSSEC with realistic expectations

DNSSEC helps prove that DNS answers have not been changed in transit. It is useful against spoofed answers and cache poisoning when your registrar, DNS provider, and setup support it cleanly.

DNSSEC does not save a stolen DNS-provider account. If an attacker signs in with real credentials and changes records through the real dashboard, those records may still validate.

Use DNSSEC as one layer, not the whole plan.

Keep DNS records clean

Audit DNS records on a schedule. Remove old CNAMEs, abandoned subdomains, expired-domain dependencies, unused mail records, forgotten TXT records, stale vendor integrations, and old staging records.

This is not glamorous work. It is also one of the cheapest ways to avoid a very expensive surprise.

Harden routers and networks

For offices, agencies, home businesses, and anyone who manages websites from shared networks, router security matters.

Encrypted DNS, such as DNS over HTTPS or DNS over TLS, can reduce some interception risk. It does not fix a stolen registrar account or clean malware from a device.

Protect WordPress and hosting

WordPress does not control registrar DNS, but it can still be part of the incident. Reused passwords, stolen admin accounts, compromised email, and hosting-panel access often connect the layers.

Keep WordPress core, plugins, and themes updated. Remove abandoned plugins and themes. For admin accounts, enable two-factor authentication for WordPress, limit admin roles, scan for malware, monitor vulnerabilities, and use a firewall for site-level attacks.

MalCare belongs here. It helps with WordPress malware scanning, cleanup, vulnerability monitoring, firewall protection, login protection, and post-incident hardening. It should sit beside DNS-provider controls, not pretend to replace them.

Can MalCare prevent DNS hijacking?

No WordPress security plugin can directly prevent DNS hijacking at the registrar, DNS provider, resolver, or router layer.

That limit matters. MalCare cannot enable registry lock, change authoritative DNS records, secure a registrar account, or stop a compromised router from handing out malicious DNS servers.

What MalCare can do is protect the WordPress layer around the incident. If DNS checks are clean but redirects continue, MalCare can help find WordPress malware. If the incident involved stolen credentials, suspicious admins, vulnerable plugins, or injected redirects, MalCare can help with scanning, cleanup, firewalling, and hardening.

The right model is layered security: DNS controls for DNS, registrar controls for domain ownership, network hygiene for routers and resolvers, and WordPress security for the site itself.

Mistakes to avoid

DNS incidents are stressful. These mistakes make them worse.

The goal is not to do everything at once. The goal is to fix the right layer in the right order.

FAQs

What is DNS hijacking in simple terms?

DNS hijacking is when the DNS answer for a domain is changed or intercepted so users go to the wrong destination. The typed domain may look correct, but the browser may reach a fake site, malware page, ad page, or attacker-controlled server.

How do I remove a DNS hijack?

Secure the registrar and DNS-provider accounts first. Then restore known-good DNS records, remove unauthorized records and users, flush caches where possible, check routers and devices, scan WordPress and hosting, rotate exposed credentials, notify affected users if needed, and monitor for repeat changes.

Is DNS hijacking the same as DNS spoofing?

No. DNS hijacking is the broader problem where DNS sends users to the wrong place. DNS spoofing is one method where a fake DNS answer is supplied. DNS cache poisoning is related, but it means a fake answer was stored by a resolver.

Can DNSSEC stop DNS hijacking?

DNSSEC helps protect against forged DNS answers and cache poisoning by validating DNS responses. It does not stop every DNS hijack. If an attacker uses stolen registrar or DNS-provider credentials to change records through the real account, DNSSEC alone will not protect you.

What should I do if users entered passwords on a fake site?

Restore DNS control, then treat those credentials as exposed. Reset passwords, revoke active sessions, rotate API keys, review email and payment accounts, check WordPress admins, and tell affected users what action to take.

Conclusion

DNS hijacking is confusing because the clue is often a normal-looking domain. The real question is not only what URL the visitor typed. It is which server DNS sent them to.

Start by finding the affected layer. Secure the account or device that controls that layer, restore the right records, and then check WordPress, hosting, routers, credentials, certificates, and post-cleanup measures. A clean DNS record gets visitors back to the right place. A complete recovery pairs DNS repair with WordPress security so the same incident does not return through another path.