Your users type your domain into their browser. They get a login page that looks exactly like yours. They enter their credentials. You never see any of it.
That's DNS hijacking. No one broke into your servers. No one touched your code. They just changed where your domain points.
How DNS actually works (the part that matters)
When someone visits yourapp.com, their browser asks a DNS resolver: "what IP address is this?" The resolver checks its cache, and if it doesn't have an answer, it walks up the DNS hierarchy until it finds one. Your authoritative nameserver, the one you control through your registrar, gives the final answer.
The whole process takes milliseconds and happens invisibly. It's also built on a foundation of trust. DNS was designed in 1983, when the internet was a handful of universities sharing files. Authentication was an afterthought added decades later, and most of the internet still doesn't use it.
That gap is where hijacking lives.
The three ways it actually happens
Registrar account compromise
This is the most common and the most damaging. Your domain registrar account gets compromised, and the attacker changes your nameservers to ones they control. Every DNS query for your domain now goes to their server. They answer however they want.
From the outside, nothing looks wrong. The domain name is yours. The WHOIS still shows your company. Users have no way of knowing they're talking to the wrong server.
The 2019 Sea Turtle campaign, attributed to a nation-state actor, used exactly this method to target government and military domains across the Middle East and North Africa. They didn't attack the targets directly. They compromised registrars and DNS providers upstream, then redirected traffic to collect credentials. Some victims went months without noticing.
DNS cache poisoning
Resolvers cache DNS responses to avoid asking the same question twice. Cache poisoning tricks a resolver into storing a fake answer, so every user who asks that resolver for your domain gets sent to the wrong IP.
The classic attack exploits the fact that DNS uses UDP, which has no built-in verification. An attacker who can guess the query ID (a 16-bit number, so 65,536 possibilities) can inject a fake response before the real one arrives. Kaminsky's 2008 disclosure showed this was practical at scale. The patch was randomizing the source port on top of the query ID, which raised the guessing space to around 2 billion. Better, but not foolproof.
BGP hijacking with DNS as a side effect
Border Gateway Protocol is how internet routers know which paths to use. It's also almost entirely based on trust between autonomous systems. When a network announces that it owns an IP range it doesn't, traffic for those IPs can get rerouted through the attacker's infrastructure.
In 2018, attackers briefly hijacked the BGP routes for Amazon's Route 53 DNS service. They redirected DNS queries for MyEtherWallet to a server they controlled, which served a fake version of the site and collected around $150,000 in cryptocurrency in two hours. The DNS records themselves were never touched.
What attackers do with it
Credential harvesting is the obvious one. Serve a convincing copy of your login page, collect usernames and passwords, pass the credentials through to the real site so users don't notice anything is off.
But it goes further than that. If your domain is used for email (MX records), an attacker who controls your DNS controls where your email goes. Password reset links, internal notifications, customer data, all of it can be redirected.
HTTPS doesn't save you here. An attacker who controls your DNS can request a valid TLS certificate for your domain from any CA using HTTP-01 or DNS-01 validation. The padlock in the browser will be green. The certificate will show your domain name. It will be completely legitimate from the browser's perspective.
Signs something is wrong
Most teams find out from users. "Your site looks weird" or "my password stopped working" are common first signals, by which point the damage is done.
What to actually watch:
Your NS records should never change unless you're deliberately migrating DNS providers. Set up monitoring for them. If your authoritative nameservers change without a ticket in your system, something is wrong.
TTL spikes are suspicious. Attackers sometimes lower TTLs before a hijacking to make the switch propagate faster and to make rollback harder. A sudden drop in TTL across your zone is worth investigating.
Response time changes. If your DNS responses start coming from unexpected geographic locations or taking longer than usual, a resolver somewhere is getting wrong answers.
Certificate transparency logs, which we covered in the previous post on CT logs, will show you if a certificate was issued for your domain from an unexpected CA. This is often one of the first visible signs of an active hijack.
Tools like ZeroHook monitor your DNS records continuously and alert you when something changes, NS records, A records, MX records, anything. The window between a hijack starting and you noticing it manually is often days. Automated monitoring closes that window considerably. Worth setting up: zerohook.org.
How to actually protect yourself
Lock your domain at the registrar. Most registrars offer a "registrar lock" or "transfer lock" that prevents nameserver changes without an additional out-of-band confirmation. Enable it. Some registrars also offer registry lock, which requires a phone call or signed document to make changes. For critical domains, that friction is worth it.
Enable DNSSEC on your zone. DNSSEC adds cryptographic signatures to DNS records, so resolvers can verify that the answer they received came from your authoritative server and wasn't tampered with in transit. Adoption is still patchy, but it defends against cache poisoning and some man-in-the-middle attacks.
Harden your registrar account. Use a strong unique password, enable MFA, and restrict access to the minimum number of people who actually need it. The Sea Turtle campaign worked because registrar accounts are often treated as low-value administrative accounts rather than the critical infrastructure they are.
Use CAA records to restrict which certificate authorities can issue certs for your domain. If your CAA record says only Let's Encrypt can issue for yourapp.com, a hijacker using a different CA will get rejected. It's not foolproof but it raises the bar.
Monitor, not just your servers but your DNS. Uptime monitoring tells you when your site is down. It doesn't tell you that your site is up but serving someone else's content.
TL;DR
DNS hijacking doesn't require access to your servers or your code. It requires access to wherever your domain's DNS records live, which is usually a registrar account protected by a password and maybe SMS two-factor.
The attack is invisible to users. HTTPS doesn't stop it. You can lose credentials, email, and customer trust before anyone on your team notices.
Lock your domain. Enable DNSSEC. Watch your NS records. Set up monitoring that tells you when your DNS changes, not just when your site goes down.