DNS hijacking means lookups for your domain return the wrong answer, sending visitors to a server you don't control. It can happen on a home router, at a recursive resolver, at your DNS hosting provider or through changed nameservers at the registrar. Comparing what public resolvers return with what your authoritative nameservers say shows where the tampering sits.
With DNS hijacking, nothing on your website is broken. Server, files and database are clean, yet visitors end up somewhere else. That makes it awkward to diagnose: you load the site from the office and everything looks normal, while a customer on another network gets a login form you never built.
Detecting DNS hijacking with three queries
The question is always: where in the chain does the answer go wrong? All you need is dig, which ships with macOS and Linux (on Windows, use WSL or nslookup).
First, what your own resolver returns, i.e. what your machine sees right now:
dig A example-shop.com +shortSecond, what public resolvers return:
dig A example-shop.com @1.1.1.1 +short
dig A example-shop.com @8.8.8.8 +shortThird, the source itself. Find the nameservers, then ask one of them directly:
dig NS example-shop.com +short
dig A example-shop.com @ns1.your-dns-host.net +norecurse +shortHow to read the result:
| Result | Likely cause |
|---|---|
| Only your local answer is wrong | Router, device or local resolver tampered with |
| Public resolvers wrong, authoritative server right | Stale cache or an attack on a resolver |
| Authoritative server returns the wrong IP | Your DNS hosting account is compromised |
dig NS shows nameservers you don’t recognise | Delegation changed at the registrar; the domain is effectively hijacked |
The last row is the serious one. It is no longer about individual records but about control of the domain. Go to domain hijacked and work through the checklist there.
The four layers where DNS gets tampered with
Router and device. The best-known example is DNSChanger, malware that pointed infected computers and routers at criminal DNS servers. The FBI took over its infrastructure in 2011 as part of Operation Ghost Click. Today this mostly hits routers with default passwords or old firmware, and only users on that network are affected.
Resolver. If forged answers are slipped into a recursive resolver’s cache, everyone using that resolver gets the wrong IP. DNSSEC was designed for exactly this case.
DNS hosting. Anyone with your DNS provider’s login simply edits the A or MX record. To the rest of the world, the wrong answer is now the authoritative one.
Registrar. Here the attacker replaces the nameservers and runs their own zone for your domain. In January 2019, after a wave of such attacks on government domains, the US Cybersecurity and Infrastructure Security Agency (CISA) issued Emergency Directive 19-01. It ordered federal agencies to audit DNS records, change account passwords, add multi-factor authentication and monitor Certificate Transparency logs.
A related case is route hijacking via BGP. In 2018 attackers briefly announced address space belonging to Amazon’s Route 53 DNS service to redirect users of the MyEtherWallet cryptocurrency wallet to a fake site. As a domain owner you can do little about BGP, but DNSSEC would have let validating resolvers reject the forged answers.
What to do at each layer
Local: open the router’s admin page, check the DNS settings, change the admin password, update the firmware. On the computer, check the network settings for an unexpected DNS server.
DNS host: change the password, enable two-factor login, regenerate API tokens, then fix the records. Set a low TTL such as 300 seconds while you repair so corrections spread quickly. Bear in mind that wrong answers stay cached for as long as the TTL on the tampered record.
Registrar: this is an account compromise. The process is in registrar account hacked.
Certificates: the part people forget
If an attacker controls your DNS for even an hour, a certificate authority may issue them a valid TLS certificate for your domain, because domain validation checks exactly what they currently control. With that certificate the fake site looks perfectly normal in a browser.
Every publicly trusted certificate is logged in Certificate Transparency logs. Searching crt.sh for your domain lists each certificate with issue date and issuer. If one appears from the incident window that you didn’t request, ask the issuer to revoke it. A CAA record also limits which authorities may issue for your domain at all:
example-shop.com. 3600 IN CAA 0 issue "letsencrypt.org"It only helps while the attacker can’t edit the CAA record too, but it is a sensible layer.
Prevention that actually helps
Most real incidents involve accounts, not protocols. So two-factor login at your registrar and DNS host comes first, followed by transfer and update locks. For domains that carry real weight, a registry lock means nameserver changes need extra confirmation outside your customer account.
DNSSEC adds protection at the protocol level. For it to work, your registrar and DNS host must support it and the key must be published at the registry; the setup is in enable DNSSEC. At betadomain you can turn on DNSSEC for .com and around 490 other extensions.
If you change DNS automatically, for example from a deployment pipeline, treat API keys exactly like passwords. betadomain’s domain API for developers is one example of such an interface: convenient, but every key is another route to your records.
After any incident, write down the correct nameservers and key records somewhere outside your DNS account. Next time you can compare in a minute instead of an hour. And while you are at it, see whether your name is free under other extensions with a quick availability check.
Step by step
- Compare answersQuery the same name with dig through your local resolver, a public resolver and directly at the authoritative nameserver.
- Identify the layerIf only the local answer differs, it's the device or router. If the authoritative server is wrong too, the zone or delegation has been changed.
- Secure the accountsReset passwords and 2FA for the router, DNS host or registrar, depending on the layer affected.
- Fix the recordsRestore nameservers and A, AAAA and MX records and keep the TTL low while you repair.
- Check certificatesSearch Certificate Transparency logs for certificates issued for your domain during the incident and have unknown ones revoked.
Found your domain? You can check and register it directly at compare domain prices – yearly price from €2.99.
FAQ
What is the difference between DNS hijacking and DNS spoofing?
The terms overlap. DNS spoofing usually means injecting forged answers into a resolver, for example through cache poisoning. DNS hijacking is the broader term for any redirection, including edited records at your DNS host or swapped nameservers at the registrar.
Does HTTPS protect against DNS hijacking?
Partly. Without a valid certificate for your domain, browsers show a warning. But an attacker who controls your DNS records can often get a genuine certificate issued through domain validation. That is why watching Certificate Transparency logs for your domain is worth the effort.
Does DNSSEC stop every kind of DNS hijacking?
No. DNSSEC detects forged answers between your nameservers and a validating resolver. An attacker with access to your DNS host or registrar account can edit the signed zone or switch DNSSEC off. Two-factor login and a registry lock cover that case.
Can my router be hijacked?
Yes. Malware or someone with access to the router's admin page can change the DNS server every device on that network uses. Only people on that network are affected. Check the router's DNS settings, change its admin password and update the firmware.