What is DNS hijacking and how do you detect and prevent it?

DNS hijacking is when an attacker changes the DNS records for a domain, or the answers a resolver gives, so that users reach attacker-controlled servers. The strongest defenses are locking down the account that edits your DNS, enforcing MFA, auditing records regularly and monitoring certificate transparency logs.

How does a domain get hijacked?

CISA's Emergency Directive 19-01, issued in January 2019 after a campaign of DNS infrastructure tampering, describes the sequence. The attacker compromises credentials, or obtains them another way, for an account that can change DNS records. They alter records such as address (A), mail exchanger (MX) or name server (NS) records, replacing the legitimate address of a service with one they control. Traffic can then be redirected for manipulation or inspection before being passed on to the real service.

CISA stressed a second problem. Because the attacker controls the records, they can also obtain valid encryption certificates for the organization's domain names. That lets them decrypt redirected traffic, and users see no browser warning because the certificate is valid for the domain.

Mail is part of it too. Altered MX records divert email, which means password reset messages can be intercepted.

How is this different from DNS spoofing or a resolver attack?

Hijacking at the registrar or DNS host changes the source of truth, so every user sees the wrong answer. Attacks on a resolver, or on the path between a user and a resolver, give wrong answers to some users only. The Domain Name System Security Extensions, described in RFC 4033, add data origin authentication and data integrity to DNS. They help a validating resolver detect forged answers, but if an attacker legitimately edits your signed zone through your account, the forged data may be signed too. Account security comes first.

What did CISA require, and what does it teach?

The directive set four actions, which still make a sensible checklist (the directive was closed in January 2026 after CISA concluded its purpose had been met):

1. Audit public DNS records on all authoritative and secondary DNS servers to verify they resolve to the intended location, prioritizing NS records and records for key services.
2. Change passwords for all accounts that can make DNS changes.
3. Add multi-factor authentication to those accounts, preferring factors resistant to phishing. The directive notes that SMS-based MFA is not recommended, consistent with NIST SP 800-63B.
4. Monitor certificate transparency logs for certificates issued that you did not request, and report unauthorized ones to the issuing certificate authority.

A constructed example

A company's registrar account is protected by a password reused from an old forum breach. An attacker logs in and changes the NS records to servers they run. The company's website and mail now resolve through the attacker. A few hours later, the attacker requests a certificate for the domain and gets one. The company's first sign is a customer reporting a login page that looks right but sends credentials elsewhere. A team that had a certificate transparency alert would have seen the unexpected issuance earlier, and a team with phishing-resistant MFA on the registrar would likely not have been breached at all.

How to check or apply this

1. List every account and API key that can change DNS or registrar settings, and remove the ones nobody needs.
2. Turn on MFA with phishing-resistant factors for all of them.
3. Enable registrar locks where offered, to block unauthorized transfers and changes.
4. Export your DNS records, store a known-good copy and compare on a schedule.
5. Subscribe to certificate transparency monitoring for your domains.
6. Consider signing your zones with DNSSEC, and understand its limits.
7. Keep a response plan: how to regain the account, who contacts the registrar, and how to revoke rogue certificates.
8. Remove dangling DNS entries that point to services you no longer use.

Quick check

Sources

• CISA, ED 19-01: Mitigate DNS Infrastructure Tampering
• RFC 4033, DNS Security Introduction and Requirements

Last reviewed: 18 October 2026.