What Is DNS Hijacking?
Key takeaways
- A hijacked resolver can send a banking login to a convincing copy site while the address bar still shows the correct bank domain.
- Routers are the most common hijack point in Indian small offices, because DNS settings are editable from the local network and rarely checked again.
- DNS over TLS encrypts the lookup itself, so the answer cannot be altered on the way from the client to the resolver.
- DNS over HTTPS carries lookups inside an ordinary HTTPS connection, which makes them hard to distinguish from browsing and hard to block.
- Restricting outbound DNS at the firewall to approved resolvers stops a compromised device from quietly using its own.
As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.
How does DNS hijacking work in practice?
Every time you type a domain name, a resolver looks up its address. If an attacker controls that lookup, your browser goes wherever the attacker says, and the address bar can still show the name you typed. Four variants matter. Router-level hijacking happens when someone with the admin password changes the DNS settings of the office router, which is why that password and a configuration review belong on a checklist. Device-level hijacking comes from malicious software or a pushed configuration. Network-level hijacking is DNS traffic silently redirected by rogue infrastructure. Finally, registrar or DNS account takeover redirects the authoritative records for your own domain, which is an account-security problem before it is a network one.
What is the difference between DNS over TLS and DNS over HTTPS?
Both encrypt the lookup, but they carry it differently. DNS over TLS uses a dedicated TLS connection on port 853, with its own certificate, which is clean and efficient but can be blocked by networks that only permit standard web traffic. DNS over HTTPS runs the lookup inside a normal HTTPS connection on port 443, so it blends with ordinary browsing, which makes it harder to block and harder to detect as DNS. In India, DNS over HTTPS tends to survive filtering better. Neither is complete protection on its own, because a compromised resolver that receives your encrypted request can still answer it wrongly, so pair encryption with control of which resolvers you trust.
How do I detect a hijack that has already happened?
Three ways. First, compare what your internal resolver returns against an independent public resolver for the same name, especially for your own domain and for banks and payment providers. A mismatch is the finding. Second, read the router and firewall configuration for DNS settings that nobody in the business can explain, and check the modification dates on the running configuration. Third, watch the DNS logs on the resolver for a sudden change in query volume or a burst of queries for unrelated names, which often shows up as a device trying to resolve many advertising and tracking hosts. If you suspect an attacker-controlled device, isolate it and rebuild it rather than cleaning it.
| Entry point | How it happens | Control |
|---|---|---|
| Office router | Admin password used to change DNS settings | Rotate router credentials, review config, log changes |
| Managed endpoint | Malicious software or pushed configuration | Endpoint hardening, DoH policy, application allow-listing |
| Local network | Rogue traffic on the wire redirects lookups | 802.1X, port security, switch monitoring |
| Outbound DNS | Device uses its own resolver over the internet | Firewall allows DNS only to approved resolvers |
| Domain registrar | Account takeover changes authoritative records | MFA on the registrar, registrar lock, change alerts |
| Resolver provider | Compromised or misconfigured upstream | Encrypted lookups, second resolver for validation |
What are the frequently asked questions?
Get a straight answer on this
Send us your current resolver and firewall rules, and we will run a DNS hijack exposure check and return a ranked list of the paths to close.
Send us the details See pricing