DNS hijacking starts with a login: how to protect your DNS account

Intermediate 6 min read Updated

Most DNS hijacking does not break DNS at all. The attacker logs in to the account that controls your records, at the DNS provider or the registrar, with a stolen password, a leaked API key or a shared login, and changes an A, MX or NS record. From that moment the internet trusts the attacker's answers, DNSSEC signs them, and certificate authorities issue certificates for them. Protect the accounts, not just the protocol: multi-factor sign-in, one login per person, scoped API keys, an alert on every change, a registry lock for critical domains, and certificate transparency monitoring.

Contents
What you'll learn
  • How DNS hijacking differs from cache poisoning and why DNSSEC does not stop it
  • What an attacker gains from one changed record
  • Where the real attack surface is: accounts, keys and recovery paths
  • A defence checklist you can apply this week
  • How to notice a hijack in minutes instead of days

In January 2019 the US Cybersecurity and Infrastructure Security Agency issued an emergency directive after a campaign that redirected government domains. The attackers did not exploit a DNS vulnerability. They obtained credentials for the accounts that managed the DNS records, changed the records, and obtained valid certificates for the new destinations. The directive's first orders were plain account hygiene: audit DNS records, change the passwords of DNS accounts, add multi-factor authentication, and watch certificate transparency logs.

1 What DNS hijacking is, and what it is not

AttackWhere it happensDoes DNSSEC help?
Cache poisoning, spoofed answers on the networkBetween resolver and nameserverYes, forged answers fail validation
DNS hijacking through the provider or registrar accountAt the source of your recordsNo, the changed records are signed like any other
Domain hijacking (transfer or registrant change)At the registrar or registryNo, the new owner controls everything

The second and third rows are the common ones today, and both start with access to an account.

2 What one changed record gives an attacker

  • A or AAAA: your website or API now points at their server. They can proxy to the real one and read everything in between, and a certificate authority will issue them a valid certificate because your DNS points there.
  • MX: your incoming mail goes to them, including password reset links for every service registered with your addresses.
  • NS: a delegation to their nameservers hands over the whole zone or subdomain.
  • TXT and CNAME: domain verification records let them prove "ownership" of your domain to cloud and SaaS services, or complete an ACME DNS-01 challenge for any certificate.

Changes like these can be short-lived: the attacker switches a record for an hour, collects credentials or a certificate, and switches it back. Without a change log or an alert, nobody notices.

3 Where the real attack surface is

  • The registrar account, which can change nameservers and DS records for the domain.
  • The DNS provider account, which can change every record.
  • API keys in CI pipelines, scripts, certificate renewal tools and old laptops.
  • Shared logins used by an agency, a former employee or "the IT account".
  • The recovery path: the mailbox that receives password resets for these accounts. If that mailbox is on the same domain, a hijacked MX unlocks the rest.

4 A defence checklist

  1. Turn on multi-factor sign-in for the registrar and DNS accounts of everyone who has one. Prefer passkeys or authenticator apps over SMS.
  2. One login per person. Remove shared accounts; invite people individually with the smallest role they need, limited to the zones they work on.
  3. One API key per integration, with the narrowest permissions it needs. A certificate renewal job does not need to delete records. Rotate keys when people leave.
  4. Lock the domain. Keep the registrar lock on, and for critical domains ask for a registry lock, which requires a manual, out-of-band confirmation before nameservers or contacts can change.
  5. Alert on every change. Send DNS change notifications to a channel people read. A change nobody planned should be noticed in minutes.
  6. Keep an audit log with the old and new value of each change, and long enough retention to investigate weeks later.
  7. Restrict and watch certificates. Publish CAA records naming the certificate authorities you use, and monitor certificate transparency logs for certificates issued for your names.
  8. Keep the recovery mailbox off the domain it protects, or at least protected by its own multi-factor sign-in.
  9. Turn on DNSSEC anyway. It does not stop account takeover, but it removes the network attacks from the list.
dig +short CAA example.com      # e.g. 0 issue "letsencrypt.org"
dig +short NS example.com @a.gtld-servers.net   # the delegation as the parent sees it
curl -s "https://crt.sh/?q=example.com&output=json" | grep -o '"issuer_name":"[^"]*"' | sort | uniq -c

5 Notice a hijack fast

Prevention fails sometimes; detection decides whether a hijack lasts an hour or a month.

  • Change notifications from the DNS provider to chat or e-mail, for every record change.
  • A daily comparison of the zone with a known-good copy, for example a zone export committed to Git, as described in Who changed this DNS record?
  • Parent-side checks for NS and DS, which an attacker with registrar access changes without touching your zone.
  • Certificate transparency alerts for certificates you did not request.

Regulations increasingly expect this kind of control over critical configuration; the overview in our audit log article lists what NIS2, DORA, ISO 27001, SOC 2 and others ask for.

6 How PrimeDNS helps

  • Two-factor sign-in with an authenticator app (TOTP) and passkeys, with recovery codes.
  • One login per person: team members are invited individually with roles down to a single zone, and one login can work across several accounts.
  • Scoped API keys, so each integration gets only the permissions it needs.
  • Webhooks on every record change (record.created, record.updated, record.deleted), signed with HMAC so your receiver can verify them, plus alert rules, to put each change in front of people within seconds.
  • The Audit Log records every change with the old and new value, and also sign-ins, failed sign-ins, two-factor changes, API key creation and team changes, kept for two years.
  • DNSSEC in one click and CAA records to restrict which certificate authorities may issue for your names.

See the guides for Webhooks & Alerts, Team & RBAC and the Audit Log.

7 Frequently asked questions

What is DNS hijacking?

Changing where a domain's DNS points without the owner's consent. Today it usually means someone signed in to the registrar or DNS provider account, or used a leaked API key, and changed the records.

Does DNSSEC prevent DNS hijacking?

Not when the change is made in the account that manages the zone. DNSSEC proves an answer came from your zone unchanged; it signs a malicious record entered in the panel like any other.

What is a registry lock?

A lock at the domain registry that blocks changes to nameservers, contacts or transfers until the registrar confirms the request out of band, usually by phone or with named contacts. It is offered for many TLDs, often for a fee, and is worth it for domains your business depends on.

How do I know if my DNS was hijacked?

Look for record changes you did not make in the provider's audit log, unexpected NS or DS records at the parent zone, and certificates for your names that you did not request in certificate transparency logs.

8 References

  1. CISA Emergency Directive 19-01: Mitigate DNS Infrastructure Tampering
  2. RFC 8659: DNS Certification Authority Authorization (CAA) and RFC 8657: CAA accounturi and validationmethods
  3. RFC 6962: Certificate Transparency
  4. crt.sh: certificate transparency log search

Lock down who can change your DNS

Invite your team with roles per zone, turn on two-factor sign-in, and send every change to your chat.

Create an account Read the Webhooks & Alerts guide