DNS hijacking is an attack in which DNS queries are intercepted and redirected to malicious or unauthorised nameservers or IP addresses without the knowledge or consent of the domain owner or the user making the query. Instead of receiving the legitimate answer from the authoritative nameserver the victim receives a fraudulent response, potentially pointing to a fake website designed to steal credentials, serving malware, or simply redirecting traffic to a competitor or a monetisation page.

The word hijacking captures the nature of the attack accurately, legitimate DNS traffic is taken over and redirected somewhere it was never intended to go. The domain owner continues to operate their authoritative nameserver with correct records. The user continues to type the correct domain name. But somewhere in the resolution path, between the user and the authoritative nameserver, the query or response is intercepted and substituted with a fraudulent one.

DNS hijacking is distinct from other DNS-related attacks in that it manipulates the DNS resolution process itself rather than the content served at a destination. A successful DNS hijacking attack is invisible to most users, the domain name they typed is correct, their browser shows no obvious warning in many cases, and they see a page that may look identical to the legitimate site. The attack is insidious precisely because it exploits the trust users place in domain names as proxies for legitimate destinations.

Understanding DNS hijacking is relevant for anyone managing domains because the consequences, lost traffic, credential theft, malware distribution, SEO damage, are severe and the attack vectors include compromising domain registrar accounts, nameserver infrastructure, and resolver caches that domain owners have varying degrees of control over.

How DNS hijacking works

DNS hijacking can be executed at several different points in the DNS resolution chain, each attack vector targeting a different layer of the DNS infrastructure. The specific mechanism determines who is affected, how the attack is detected, and how it is remediated.

Registrar-level hijacking: an attacker gains access to the domain owner’s registrar account, through phishing, credential theft, social engineering, or exploiting registrar security vulnerabilities, and changes the domain’s NS records to point to nameservers under the attacker’s control. The attacker’s nameservers return fraudulent DNS records for the domain, pointing the domain’s A record to malicious servers, modifying MX records to intercept email, or serving any other records the attacker chooses.

This is one of the most impactful forms of DNS hijacking because it affects all users worldwide, every resolver that looks up the domain receives the attacker’s fraudulent records from the attacker’s nameservers. The legitimate authoritative nameserver still has correct records but nobody is querying it, the NS records at the TLD level now point to the attacker’s servers instead.

Registrar-level hijacking is also called domain hijacking or domain theft. It is the attack vector that caused high-profile DNS incidents at major organisations, attackers compromised registrar credentials and redirected entire domains to malicious infrastructure for hours or days before the legitimate owners detected and reversed the changes.

Resolver-level hijacking, cache poisoning: an attacker injects fraudulent DNS records into a recursive resolver’s cache, a technique called cache poisoning. The resolver serves the fraudulent records to all clients using it until the poisoned cache entries expire. Users on the affected resolver receive incorrect IP addresses for the targeted domain and are directed to the attacker’s servers.

Cache poisoning exploits the fact that resolvers accept DNS responses without cryptographic verification unless DNSSEC is deployed. An attacker who can send a forged DNS response to a resolver, timed to arrive before the legitimate response, can poison its cache with fraudulent records. The Kaminsky attack, discovered in 2008, demonstrated a practical cache poisoning technique that affected most DNS resolvers at the time and drove widespread adoption of source port randomisation as a mitigation.

ISP-level DNS hijacking: some internet service providers deliberately intercept DNS queries to their resolvers and return modified responses. A common form is NXDOMAIN hijacking, when a user queries for a domain that does not exist the ISP returns a page full of advertisements rather than the standard NXDOMAIN response indicating the domain does not exist. The user sees a monetisation page instead of the expected error.

More invasive ISP DNS hijacking redirects queries for specific domains, competitor services, file sharing sites, to ISP-controlled pages. This is controversial because it violates user expectations about DNS resolution behaviour even when the stated purpose is to block access to illegal content.

Malware-based DNS hijacking: malware installed on a user’s device modifies the device’s DNS configuration, changing the configured resolver to an attacker-controlled server or modifying the local hosts file to override DNS for specific domains. Every DNS query from the infected device goes to the attacker’s resolver which returns fraudulent responses for targeted domains.

Router firmware hijacking, malware compromising home or office routers, achieves similar effects at a network level. All devices on the network use the router for DNS. Changing the router’s DNS configuration to point to a malicious resolver affects every device on the network simultaneously. The individual devices are unmodified, the compromise is at the router level.

Man-in-the-middle DNS hijacking: an attacker positioned on the network path between a user and their resolver intercepts DNS queries and substitutes fraudulent responses before the legitimate response arrives. This is a network-level attack requiring the attacker to have access to the network path, possible on unsecured public Wi-Fi networks or through compromised network infrastructure.

DNS hijacking vs DNS spoofing vs cache poisoning

These three terms are related and sometimes used interchangeably but describe different aspects of DNS-based attacks.

DNS hijacking: the broad category of attacks where DNS resolution is redirected to unintended destinations. Encompasses all the attack vectors described above, registrar compromise, resolver manipulation, malware, man-in-the-middle attacks.

DNS spoofing: sending fraudulent DNS responses that impersonate legitimate authoritative nameservers. Spoofing is the technique used in cache poisoning and man-in-the-middle attacks. A spoofed DNS response looks like it came from the authoritative nameserver but actually came from the attacker.

Cache poisoning: a specific attack that uses DNS spoofing to inject fraudulent records into a resolver’s cache. The cache is poisoned with incorrect data that is then served to all users of that resolver. Cache poisoning is one mechanism by which DNS hijacking is achieved at the resolver level.

Consequences of DNS hijacking

The consequences of a successful DNS hijacking attack depend on the scope of the compromise and the attacker’s objectives.

Credential harvesting: the most common objective of targeted DNS hijacking. The attacker points a domain to a server hosting a fake version of the legitimate website. Users who navigate to the domain see a convincing replica and enter their credentials, which are captured by the attacker. Because the domain name in the browser is correct, the hijacking happened at the DNS level not the URL level, users have no obvious reason to suspect they are not on the legitimate site.

Traffic interception and monitoring: redirecting a domain’s DNS to an intermediate proxy server allows the attacker to intercept and monitor all traffic between users and the legitimate destination. The proxy forwards requests to the legitimate server and returns responses to users while capturing all content, credentials, session cookies, private communications, in transit.

Redirect to competitor or monetisation: less sophisticated but economically motivated hijacking redirects domain traffic to competitor sites or to pages monetised through advertising. The domain owner loses traffic and revenue. Users reach irrelevant destinations. In the domain parking and SEO context this represents a direct attack on a domain’s value.

Malware distribution: the hijacked domain serves malware to visitors rather than legitimate content. Users who navigate to a trusted domain receive drive-by malware installations exploiting browser vulnerabilities.

Email interception: modifying MX records redirects all incoming email for the domain to attacker-controlled mail servers. The attacker receives email intended for the legitimate domain owner, including password reset emails, authentication codes, and sensitive business communications.

SEO equity and link juice theft: if a hijacked domain’s A record is redirected to a different site the accumulated SEO authority and link equity of the hijacked domain benefits the destination rather than the legitimate owner. This is particularly relevant for domain theft where an expired domain is hijacked by a new registrant who then uses its accumulated authority for their own SEO.

SSL certificate issuance: in registrar-level hijacking scenarios where the attacker controls the domain’s DNS they can pass DNS validation challenges and obtain valid SSL certificates for the hijacked domain. Visitors see a valid SSL certificate, the padlock icon in their browser, providing false assurance that the connection is secure and the site is legitimate.

DNS hijacking and legitimate redirects

It is worth clearly distinguishing DNS hijacking from legitimate redirect management. Both involve DNS records being used to route traffic. The critical difference is authorisation and intent.

A legitimate redirect, connecting a domain to redirect infrastructure via CNAME or A record, is configured by the domain owner with full knowledge and intent. The domain owner controls both the DNS records and the redirect rules. Visitors are redirected to intended destinations as configured.

DNS hijacking involves an attacker modifying DNS configuration without the domain owner’s knowledge or consent. The domain owner has not authorised the changes. Visitors are redirected to destinations chosen by the attacker for malicious purposes.

ISP DNS hijacking: where ISPs return modified responses for NXDOMAIN queries, occupies a contested middle ground. The ISP controls the resolver and considers the modification authorised within their infrastructure. Users who expected standard DNS behaviour consider it an unauthorised manipulation. This debate has not been definitively resolved but the practice is widely criticised by the technical community.

Protecting domains against DNS hijacking

Domain owners have several layers of protection available against DNS hijacking, particularly the registrar-level attacks that represent the most impactful vector.

Registrar account security: since registrar-level hijacking requires compromising the registrar account strong account security is the primary defence.

Use a strong unique password for the registrar account, not reused from any other service. Enable multi-factor authentication, preferably hardware security keys like YubiKey rather than SMS-based codes which are vulnerable to SIM swapping attacks. Use a dedicated email address for the registrar account that is not used for other services and is itself protected with strong authentication.

Registry lock, domain locking: most registrars offer domain locking, a setting that prevents changes to the domain’s nameservers, DNS records, or registration details without additional verification steps. A basic registrar lock prevents accidental changes and requires the lock to be explicitly removed before changes are made. More advanced registry locks, like ICANN’s Transfer Lock, require out-of-band verification with the registry operator before any changes take effect.

Premium registry lock services, offered by registrars for high-value domains, require verification through secure channels, phone calls to verified numbers, physical documentation, before DNS changes are processed. These are expensive but appropriate for domains representing significant business value.

DNSSEC: DNS Security Extensions add cryptographic signatures to DNS records. Resolvers that validate DNSSEC signatures can detect forged or tampered records. If an attacker modifies DNS records and does not have the cryptographic keys to generate valid signatures DNSSEC-validating resolvers reject the forged responses.

DNSSEC protects against cache poisoning and man-in-the-middle attacks at the resolver level. It does not protect against registrar-level hijacking, if an attacker controls the domain’s DNS they also control the DNSSEC keys and can sign fraudulent records with the legitimate keys.

DNS monitoring and alerting: continuously monitoring DNS records for unexpected changes allows rapid detection of hijacking. Services that periodically query authoritative nameservers and compare results against expected values send alerts when records change unexpectedly, giving domain owners the opportunity to respond before significant damage occurs.

Monitoring should cover A records, NS records, MX records, and any other critical records. Changes to NS records, which could indicate registrar-level hijacking, are particularly important to detect quickly.

CAA records: CAA records specify which certificate authorities can issue SSL certificates for a domain. While they do not prevent DNS hijacking they limit the damage by preventing an attacker who has hijacked the domain from obtaining a valid SSL certificate, making credential harvesting attacks more obvious to users who notice the invalid certificate warning.

Registrar choice: choosing a registrar with strong security practices, support for hardware security keys, registry lock availability, security incident response history, reduces the likelihood of successful registrar-level hijacking. Registrar security quality varies significantly. High-value domains warrant using registrars with premium security offerings.

Detecting DNS hijacking

Detection of DNS hijacking requires comparing observed DNS responses against expected values, any discrepancy indicates a potential compromise.

Regular DNS record audits: periodically querying authoritative nameservers for all critical records and comparing against documented expected values. Unexpected changes, particularly to NS records or A records, are red flags requiring investigation.

Querying from multiple resolvers: comparing DNS responses from multiple resolvers and locations. If different resolvers return different values for the same domain one or more resolvers may be serving hijacked or poisoned responses. Consistent results across resolvers are reassuring. Inconsistencies warrant investigation.

Certificate transparency monitoring: certificate transparency logs publish all SSL certificates issued for a domain. Services like cert.sh allow monitoring for new certificates issued for a domain. An unexpected certificate issuance, particularly from a CA not listed in CAA records, may indicate DNS hijacking enabling fraudulent certificate issuance.

Traffic and server log analysis: unexpected drops in traffic to legitimate servers alongside reports from users of unusual behaviour, credential prompts, unexpected redirects, security warnings, may indicate active DNS hijacking. Server access logs showing dramatically reduced legitimate traffic while the domain appears online is a warning sign.