When Your Lookups Are Quietly Redirected.

What DNS hijacking is

Hijacking is redirection. Instead of forging one reply and hoping it wins a race, an attacker takes control of a point your lookups already pass through and changes where they go or what comes back. Because the redirect sits in the machinery, the wrong answer is not a lucky one-off; it is what you get every time, for as long as the control point stays compromised. The resolver you think you are using has quietly been replaced, or its answers overwritten, by one that serves someone else's purpose.

The effect can be crude or subtle. It might send a bank's name to a convincing fake, or turn a mistyped address into a page of ads, or simply block a site by pointing it nowhere. The common thread is that the name stays right while the destination goes wrong, which is exactly why it slips past people who know to check the address bar.

Where it happens

There are a few control points, roughly in order of how close they sit to you:

• On the device. Malware changes the system's DNS setting, or edits the local hosts file, so every lookup on that one machine is answered by the attacker's server before it ever leaves.
• On the home router. Default passwords and old firmware let an attacker change the router's DNS settings once, and every phone, laptop, and TV behind it inherits the poisoned resolver without any of them being touched.
• At the ISP. Some providers intercept plain lookups on port 53 and answer them from their own resolver regardless of what you configured, a setup known as a transparent DNS proxy. A common commercial version turns typos and dead domains into a search or ad page instead of the honest “does not exist” reply.
• A handed-to-you resolver. A rogue Wi-Fi network, a shady VPN, or an installed configuration profile can quietly set a resolver you never chose, and it answers however its operator likes.

A different beast, worth naming so you can set it aside, is hijacking the domain itself at its registrar or authoritative servers. That attacks the site for everyone at once and is the site owner's problem to defend; the four points above are about your own path being redirected, which is the part you can do something about.

How it differs from spoofing

The two get blurred together, but they attack different things. Spoofing and cache poisoning is a race: an attacker fires a forged reply and tries to beat the real one to the resolver, and if a bad answer lands it gets cached and served for a while. It is opportunistic and time-limited, and it is exactly what DNSSEC was built to stop, because a forged answer fails the signature check.

Hijacking does not race anything. It owns a control point, so it does not need to arrive first; it simply is the path. That is why the fix is different too. Encryption is what removes the on-path control points, and good hygiene removes the local ones. Spoofing is about the integrity of an answer; hijacking is about who gets to answer at all.

How to tell it is happening

The signs are the small wrongnesses: a mistyped address that lands on a search or ad page instead of an error, unexpected ads injected into plain pages, a login page that looks a little off, or a browser certificate warning where there was never one before. On its own each is easy to shrug off, which is the point.

The clean way to check is to look at which resolver is actually answering you. A DNS leak test shows the resolver your queries are really reaching; if it is not the one you set, something on the path is redirecting them, and the fix a DNS leak guide walks through closing that gap. It is also worth opening your router's admin page and confirming its DNS settings are what you expect.

Why encrypted DNS shuts most of it down

Encrypted DNS pins your lookups to a named resolver and wraps them in TLS, so the router and the ISP see only ciphertext headed to a server whose certificate has to match. They can no longer read the question, quietly answer it themselves, or bend a port-53 interception around it. In one step it closes the two most common control points, the router and the ISP, which is why it is the first change worth making.

Two honest caveats. Encryption protects the link, not the endpoints, so malware already on your device can still meddle before the query is sealed; that is a job for the usual device hygiene, not for DNS. And encryption proves you are talking to the resolver you named, but not that the resolver is honest, so which resolver you trust is still the decision that matters, the theme of what a resolver is. Point yourself at a trustworthy one over an encrypted link and the redirect has nowhere left to sit.

For the router vector specifically, the plain fixes still apply: change the default admin password and keep the firmware current, so no one can quietly rewrite its DNS in the first place.