Whoever can change your DNS records can redirect your web traffic and email, and can obtain valid TLS certificates for your domains without touching a single server you own. CISA described exactly this pattern in its January 2019 DNS infrastructure hijacking alert: stolen credentials for a DNS or registrar account, altered A, MX or NS records, then trusted certificates that let the attacker decrypt redirected traffic. This template gives [Organisation] a ready-to-adopt playbook for responding to tampered authoritative records, delegation changes and compromised resolvers. It is written for DNS and network administrators, security operations, the identity team and the managers who must approve registrar and certificate actions. Replace every [bracketed] placeholder and complete the provider sheet now, while you still control the accounts.
How to use this template
- Adopt, then tailor: copy sections 1 to 8 into your incident response plan. See the Incident Response Plan Template and, for architecture, the DNS Security Guide.
- Base it on ED 19-01: CISA Emergency Directive 19-01 required US federal agencies to audit public DNS records, change passwords on every account able to change DNS, add MFA to those accounts and monitor Certificate Transparency logs. Those four actions are the spine of sections 3 to 6 and apply to any organisation.
- Know where the change happened: at the DNS hosting provider (records), at the registrar or registry (delegation), or at a resolver you run (answers to your own users). Each has a different owner and fix.
- If the registrar account itself is lost, also run the Domain Registrar Compromise Playbook.
- Review annually and after every incident or provider change. Owner: [Head of Network Operations].
1. Scope and triggers
1.1 This playbook covers unauthorised changes to DNS data for domains [Organisation] owns or operates: authoritative zone records, NS delegation and DS records at the parent zone, registrar contact and transfer settings, and the configuration of internal or customer-facing recursive resolvers.
1.2 Scenarios covered.
| Scenario | Where the change is | Typical sign | ATT&CK |
|---|---|---|---|
| Record tampering | DNS hosting provider zone | A, AAAA, CNAME or MX record points to unknown IP | T1584.002 DNS Server (adversary use of your DNS) |
| Delegation hijack | Registrar or registry | NS records at the parent differ from your provider; DS removed or changed | T1584.002 |
| Domain theft or expiry | Registrar | Registrant contact changed, transfer started, domain lapsed | T1583.001 Domains |
| Resolver compromise or poisoning | Your recursive resolvers, routers, DHCP | Internal users get different answers from public resolvers | T1557 Adversary-in-the-Middle |
| Dangling record takeover | Your zone pointing at a released cloud resource | Subdomain serves content you did not publish | T1584.002 |
1.3 Triggers: DNS monitoring alert on a changed record or SOA serial; a Certificate Transparency alert for a certificate you did not request; registrar notification of a contact, lock or transfer change; email delivery failure or DMARC report anomalies; users reporting certificate warnings or wrong sites; provider audit log entries from unknown sessions or API tokens.
2. Roles and contacts
| Role | Named owner | Responsibilities |
|---|---|---|
| Incident Lead | [Security Operations Manager] | Declares the incident, keeps the decision log and timeline |
| DNS Lead | [DNS or Network Operations Lead] | Record audit, provider and registrar actions, resolver fixes |
| PKI Lead | [Certificate or PKI owner] | CT log review, CA contact, revocation and reissue |
| Identity Lead | [IAM Lead] | Account and API token resets, MFA, session revocation |
| Email Lead | [Messaging Administrator] | MX, SPF, DKIM, DMARC checks, mail flow and possible interception |
| Communications Lead | [Head of Communications] | Customer, staff and press messages |
| Legal Counsel | [General Counsel] | Proof of ownership, law enforcement, regulator notices |
2.1 Provider sheet: for each registrar, DNS host, CDN and certificate authority record the 24/7 security contact, account numbers, the people authorised to request emergency changes, how the provider verifies identity, and the registrar's procedure for reclaiming a hijacked domain. The NCSC advises keeping registration documents that prove ownership. Store the sheet offline.
2.2 Do not rely on email at the affected domain for coordination: MX records may be redirected. Use an out-of-band channel.
3. Detection and triage
- Capture the current state: query the affected names against your authoritative servers directly, against the parent zone (NS and DS), and against two or more public resolvers. Save outputs with timestamps, plus WHOIS or RDAP data for the domain.
- Audit records against the baseline: as ED 19-01 required, confirm every public record on primary and secondary authoritative servers resolves to the intended place, starting with NS records and records for key services (web, MX, VPN, SSO, API endpoints).
- Locate the change: parent NS differs from your provider: registrar or registry. Records differ inside your provider: DNS hosting account or API token. Only internal answers differ: resolver or network device.
- Search CT logs: list certificates issued for your domains and subdomains since the earliest possible change. An unexpected certificate is strong evidence that an attacker controlled your DNS. See the Certificate Transparency Guide.
- Assess impact: what traffic was redirected (web logins, email, API clients), for how long (consider record TTLs and resolver caching), and whether credentials or mail could have been captured.
Decision point A: if MX or SSO records were redirected, treat all credentials entered and mail sent during the window as exposed and start the credential response in section 5 in parallel.
Evidence to preserve: query outputs and zone exports; provider and registrar audit logs (logins, record changes, API calls, IP addresses); registrar notification emails; CT log entries and certificate details; resolver logs; DMARC aggregate reports; mail gateway logs for the window. Record hashes and chain of custody.
4. Containment
- Regain control of the account: from a clean device, change passwords and revoke all sessions and API tokens on the DNS host and registrar. If you are locked out, call the provider's security line using the provider sheet.
- Restore correct records from your version-controlled zone source or last good export. Lower TTLs only after restoration if you expect further changes.
- Restore delegation at the registrar: correct NS and DS records, registrant contacts and transfer lock (clientTransferProhibited). Ask the registrar to apply registry lock where the TLD supports it.
- Revoke rogue certificates: report every certificate you did not request to the issuing CA and request revocation, as ED 19-01 required.
- Fix resolvers: for internal compromise, restore resolver and DHCP configuration, flush caches, and block resolution of known attacker infrastructure.
Decision point B: if the registrar cannot restore control quickly and the domain is critical, the Incident Lead and Legal Counsel decide whether to escalate to the registry operator and whether to publish alternative service addresses to customers.
Decision point C: do not delete attacker-created records or users before exporting them as evidence.
5. Eradication
5.1 Close the entry path: phished admin, reused password, account without MFA, leaked API token, compromised reseller, or an exploited resolver or router.
5.2 Credential and NHI resets.
| Credential | Action |
|---|---|
| Registrar and DNS host user accounts | New passwords, phishing-resistant MFA, remove former staff and shared logins |
| DNS provider API tokens and keys (Terraform, ACME DNS-01, CDN, external-dns) | Revoke all, reissue scoped to single zones and record types, set expiry, restrict source IP where supported |
| TSIG keys for zone transfers and dynamic updates | Regenerate and redistribute to secondaries |
| DNSSEC signing keys | Roll the KSK and ZSK if the signing system or key material may be exposed; update DS at the parent |
| Credentials entered on redirected sites | Force reset for affected users and service accounts; revoke tokens issued in the window |
| Mailbox and SMTP credentials if MX was redirected | Reset and review forwarding rules |
5.3 Remove dangling records that point to released cloud resources. See the Secrets Rotation Runbook Template.
6. Recovery
- Confirm correct answers from many public resolvers and regions, and wait out the longest TTL that applied to tampered records before declaring traffic restored.
- Re-enable or validate DNSSEC: check the chain from the parent DS to your DNSKEY validates. ICANN called in 2019 for DNSSEC on all unsecured domain names, while noting it does not stop every attack.
- Keep enhanced monitoring for [30] days: record-change alerts, registrar notifications and daily CT checks.
- Close the incident once the review is complete and the Business Owner signs off.
7. Communication and notification
| Audience | When | Owner | Content |
|---|---|---|---|
| Registrar, DNS host, CA | Immediately | DNS Lead and PKI Lead | Unauthorised changes, revocation requests |
| Executives | Within [1] hour | Incident Lead | Redirected services, exposure window, decisions |
| Users and customers | If credentials or mail may have been captured | Communications Lead | What to reset, how to verify the real site |
| Regulators | If personal data was intercepted, within statutory deadlines (for example 72 hours under UK GDPR and GDPR Art. 33) | Legal Counsel | Breach notification |
| National CERT and law enforcement | For targeted or state-linked campaigns | Legal Counsel | Indicators, attacker IPs, certificates |
| Partners consuming your APIs | Same day | Incident Lead | Window, endpoints affected, tokens to rotate |
8. Post-incident review
8.1 Within [10] business days review: time from change to detection, to correct records, to certificate revocation; how the account was accessed; which tokens could change DNS and who owned them. See the Post-Incident Review and Root Cause Analysis Template.
8.2 Track actions: registry lock on high-value domains, MFA on every DNS-capable account, a register of DNS API tokens, CAA records, and zone files under version control.
Implementation guidance
Preventive controls and their trade-offs.
| Control | Protects against | Trade-off |
|---|---|---|
| MFA on registrar and DNS accounts | Credential theft, the vector in the 2019 campaign | Shared or legacy accounts must be eliminated first |
| Registrar transfer lock | Unauthorised transfers | Does not stop changes made from a compromised registrar account |
| Registry lock | NS and contact changes, even from the registrar account | Extra cost, slower legitimate changes, not available for every TLD |
| DNSSEC signing | Forged responses; detects unauthorised changes made outside the signing system | Key management complexity; some cloud and GSLB services lack support (NCSC) |
| CAA records | Certificate issuance by CAs you do not use | An attacker with zone control can change CAA too |
| CT log monitoring | Detects certificates obtained after a hijack | Detection, not prevention; needs an owner to triage alerts |
| Record-change monitoring | Fast detection of tampering | Needs a maintained baseline to avoid noise |
Rollout.
- Inventory every domain, registrar, DNS host and every human account and API token able to change DNS.
- Consolidate registration under one team with auto-renewal on an organisation payment method, as the NCSC advises.
- Move zones into version control and deploy changes through reviewed pipelines with narrowly scoped tokens.
- Enable MFA, then transfer lock, then registry lock for the top [10] domains; add CT and record monitoring.
- Pilot DNSSEC on a low-risk zone, test key rollover and a rollback (removing DS at the parent, then unsigning after TTLs expire) before signing critical zones.
- Run a tabletop each year using the 2019 campaign as the scenario.
Small vs large organisations. A small organisation with a handful of domains can get most of the benefit from MFA, transfer lock, auto-renewal and a free CT monitor. A large one needs registry lock, central token governance and resolver monitoring.
Metrics. Percentage of DNS-capable accounts with phishing-resistant MFA; DNS API tokens without owner or expiry; critical domains under registry lock; mean time to detect a record change; mean time from unexpected certificate to revocation request; days since the provider sheet was verified.
Framework mapping.
| Framework | References |
|---|---|
| NIST CSF 2.0 | DE.CM-09 monitoring of software and data; RS.MA-01 coordinated response; RS.CO-02 stakeholder notification; RC.RP-01 recovery execution |
| NIST SP 800-53 Rev. 5 | SC-20 Secure Name/Address Resolution Service (Authoritative Source); SC-21 (Recursive or Caching Resolver); SC-22 Architecture and Provisioning; IR-4; IR-6; IA-2; CM-3 |
| MITRE ATT&CK | T1584.002 DNS Server; T1583.001 Domains; T1557 Adversary-in-the-Middle; T1078 Valid Accounts |
Where identity fits. DNS control is held by a small set of human accounts and a growing set of non-human ones: infrastructure-as-code tokens, ACME DNS-01 automation, Kubernetes external-dns and CDN integrations. Each can rewrite your domains. Give them an owner, a single-zone scope and an expiry. See the API Key Management Guide.
Standards and references
- CISA: Emergency Directive 19-01 Mitigate DNS Infrastructure Tampering
- CISA: DNS Infrastructure Hijacking Campaign
- NCSC: Managing Public Domain Names
- ICANN: Ongoing Risk to DNS Infrastructure and call for full DNSSEC deployment
- ICANN: DNS security checklist for registries, registrars and resellers
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations
- MITRE ATT&CK: T1584.002 DNS Server
Related NHI Mgmt Group resources: DNS Security Guide · Certificate Transparency Guide · Domain Registrar Compromise Playbook · Incident Response Plan Template · Website Defacement Playbook