Whoever controls your registrar account or your authoritative DNS provider controls where your website, email and single sign-on traffic goes, and can obtain valid certificates for your domain without touching any of your servers. DNS hijacking campaigns have repeatedly worked by logging in, not by breaking cryptography: stolen registrar or DNS panel credentials were enough to change NS, A or MX records. This guide covers the identity and access model of registrars, registries and DNS hosting, the EPP status codes behind registrar lock and registry lock, privileged access to DNS control planes, the API tokens and automation that change records, monitoring and a hardening baseline. It is for DNS, network and identity teams and for whoever owns the company's domain portfolio. The wider DNS threat picture is in the DNS Security Guide; this page goes deeper on the registrar and authoritative side.
Key takeaways
- Three control planes, three sets of credentials: the registrar (delegation and ownership), the DNS host (records) and any cloud or automation identity that writes records. Each can redirect your traffic on its own.
- Registry lock is the strongest control for critical domains: it sets serverUpdateProhibited, serverTransferProhibited and serverDeleteProhibited at the registry, so a stolen registrar password alone cannot change name servers.
- Phishing-resistant MFA and named accounts everywhere: CISA Emergency Directive 19-01 required MFA on every account that can change DNS records and explicitly did not recommend SMS.
- Scope automation tokens to the record they need: an ACME DNS-01 token should be able to write one TXT name, not the whole zone, and certainly not the delegation.
- Monitor delegation, not just records: watch parent-zone NS and DS records, registration status codes, CT logs and renewal dates; changes there are incidents until explained.
How identity and access work across registrar, registry and DNS host
| Control plane | What it controls | Who authenticates | What an attacker gains |
|---|---|---|---|
| Registry (TLD operator) | Delegation in the TLD zone: NS records, glue, DS records; server status codes | Only accredited registrars, through EPP; registry lock changes need out-of-band confirmation by the registrar and registry | Rarely attacked directly; registry lock moves the decision here |
| Registrar account | Registration contacts, name server delegation, DS records, transfer authorisation code, client status codes, renewal | Your users in the registrar's portal or API | Repoint NS to attacker servers, transfer the domain away, remove DNSSEC, let it expire |
| Authoritative DNS host (managed DNS, cloud DNS or your own servers) | Records in the zone: A, AAAA, MX, TXT, CNAME, CAA | Users, API tokens, cloud IAM roles, TSIG keys for zone transfer and dynamic updates | Redirect web, mail or SSO; pass domain validation for certificates; plant SPF or DKIM records |
| Automation and integrations | Records written by IaC pipelines, ACME clients, SaaS verification flows | Non-human credentials | Same as the DNS host, often with less monitoring |
CISA's Emergency Directive 19-01 (January 2019) describes the attack pattern: compromise credentials for an account that can change DNS records, alter A, MX or NS records to point at attacker infrastructure, intercept or manipulate traffic before forwarding it, and obtain valid certificates because the attacker now controls the DNS answers. The directive required agencies, within 10 business days, to audit public records (prioritising NS, key service and MX records), change passwords on every account able to change DNS (including registrar and third-party DNS panels), add MFA and monitor Certificate Transparency logs.
Registrar lock and registry lock: what the status codes do
Domain status is expressed in EPP status codes. ICANN distinguishes codes set by your registrar (client codes) from codes set by the registry (server codes), and server codes take precedence.
| Status code | Set by | Effect | Use |
|---|---|---|---|
clientTransferProhibited | Registrar | Blocks transfer to another registrar | Every domain ("registrar lock") |
clientUpdateProhibited | Registrar | Blocks changes to the domain, including name servers | Critical domains |
clientDeleteProhibited | Registrar | Blocks deletion | Every domain |
serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited | Registry, on request through the registrar | Together these make up registry lock; removing them takes longer because the registrar must forward the request to the registry | Domains whose hijack would be a major incident: primary brand, email, SSO, API and payment domains |
pendingTransfer | Registry | A transfer request is being processed | If you did not request it, contact the registrar immediately to deny it |
clientHold / serverHold | Registrar / registry | Domain removed from DNS, so it does not resolve | Alert on it: often a billing, abuse or dispute action |
- Registrar lock is necessary but weak: an attacker who logs into your registrar account can usually remove client codes in the same session.
- Registry lock adds a human, out-of-band step: the exact process (named authorised contacts, passphrases, call-backs) varies by registry and registrar, so confirm before an emergency how long an unlock takes and who can request it. Plan legitimate name server changes around that delay.
- Availability varies: not every TLD registry or registrar offers registry lock, and it often costs extra. For critical domains, choose a registrar and TLD that support it.
Admin roles and privileged access
ICANN's SSAC report SAC044, A Registrant's Guide to Protecting Domain Name Registration Accounts (November 2010), remains a sound baseline, and most of its advice maps directly to identity controls:
- Named users, not a shared login: keep an authorised contacts list, give each administrator an individual account where the registrar supports it, and revoke access when people change roles, as SAC044 advises. Shared logins with the password in a team wiki defeat every other control.
- Phishing-resistant MFA: use passkeys or security keys on registrar and DNS host accounts; ED 19-01 explicitly did not recommend SMS. Disable weaker fallback factors and recovery by email alone where the provider allows. See the Phishing-Resistant MFA Guide.
- Contact email outside the domain: SAC044 recommends hosting registration contact email on a different mail domain, so an attacker who alters your DNS cannot intercept registrar notices or password resets. Use role mailboxes protected by MFA.
- Role-based contacts: separate registrant, administrative, technical and billing contacts as role identities, and route notices to the teams that act on them.
- SSO with care: federating a DNS provider to your identity provider centralises MFA and offboarding, but it also means an identity provider compromise reaches DNS. For the most critical zones, keep a break-glass local account with a hardware key in a safe, and alert on its use.
- Least privilege in the DNS host: separate read, record edit and account administration roles; restrict who can change NS, DS and delegation settings to a very small group.
- Restrict where admins log in from: use IP allow lists or conditional access for registrar and DNS consoles where offered, and manage them from privileged access workstations.
Integrations, API tokens and service accounts
Most DNS changes in a modern estate are made by machines. These credentials can redirect mail or issue certificates for any name they can write, so scope them as tightly as the provider allows.
| Integration | Credential | Scope it to | Example control |
|---|---|---|---|
| ACME DNS-01 challenges | DNS provider token or cloud role | TXT records under _acme-challenge for the names being certified | On Amazon Route 53, IAM condition keys route53:ChangeResourceRecordSetsNormalizedRecordNames, route53:ChangeResourceRecordSetsRecordTypes and route53:ChangeResourceRecordSetsActions can restrict a role to one record name and type |
| Infrastructure as code pipelines | Cloud role or provider token in CI | The zones the pipeline owns; no registrar or delegation rights | Federated, short-lived CI credentials; zone changes through reviewed pull requests |
| Managed DNS provider APIs | Scoped API token | One zone, read or edit as needed | Cloudflare scoped tokens can be limited to specific zones and permission groups, with client IP filtering and a TTL; avoid the legacy Global API Key |
| Zone transfer and dynamic update | TSIG keys | Named secondaries and update clients only | Per-pair keys, rotation, transfers refused to everyone else |
| Registrar API | API key | Read-only monitoring where possible | Separate monitoring key from change key; IP allow list; rotate |
| SaaS domain verification | TXT records added by staff | One record per verification | Remove stale verification records; they can let a former tenant reclaim the domain in that service |
Treat these as non-human identities: owner, purpose, scope, rotation date, and storage in a secrets manager. See the API Key Management Guide and the ACME and Automated Certificate Management Guide.
Delegation, DNSSEC and certificate controls
- NS and glue at the parent: the delegation in the TLD zone is what resolvers follow. Monitor it from outside (query the TLD servers directly), not only your own zone's NS records, which an attacker who changed the delegation will not touch.
- DS records: with DNSSEC, the DS record at the registry links the parent to your signing key. An attacker with registrar access can remove DS (turning validation off) or replace it with their own, so DS changes deserve the same alerting as NS changes. Deployment detail is in the DNSSEC Deployment Guide.
- CAA records: RFC 8659 lets you name the certificate authorities allowed to issue for a domain (
issue,issuewild) and a reporting contact (iodef). CAA reduces mis-issuance by other CAs, but the RFC notes it cannot stop an attacker who can forge or suppress CAA answers, which is why it pairs with DNSSEC and account security rather than replacing them. - Certificate Transparency: monitor CT logs for certificates you did not request, as ED 19-01 required. See the Certificate Transparency Monitoring Guide for Web Teams.
- Multiple providers: two authoritative DNS providers improve availability, but double the number of control planes to secure. Apply the same MFA, roles and monitoring to both.
Logging and detection
| Signal | Source | Response |
|---|---|---|
| Change to parent NS, glue or DS records | External monitoring of the TLD servers; registrar change notifications | Treat as an incident until matched to a change ticket; start the Domain Registrar Compromise Playbook |
EPP status change (lock removed, pendingTransfer, hold) | RDAP or WHOIS polling against a baseline | Contact registrar; deny unrequested transfers |
| Record changes outside the pipeline (A, MX, NS, TXT, CAA) | DNS provider audit log, cloud audit trail | Compare with version-controlled zone; revert |
| New admin user, MFA removed, API token created | Registrar and DNS provider audit logs | Verify with the account owner |
| Login from new location or repeated MFA prompts | Provider login history or identity provider | Investigate for credential theft or MFA fatigue (ATT&CK T1621) |
| Unexpected certificate issued for your domain | CT log monitoring | Check DNS and registrar for tampering; ask the CA to revoke |
| Renewal due, payment method expiring | Registrar portfolio report | Renew early; SAC044 treats lapsed renewals as a serious threat |
In ATT&CK terms, attackers who take over DNS are using compromised infrastructure (T1584.002 DNS Server), and lapsed domains can be re-registered by others (T1583.001 Domains). Measure the programme with:
- Share of critical domains with registry lock (target 100% where the TLD supports it).
- Share of registrar and DNS accounts with phishing-resistant MFA and named users (target 100%).
- DNS automation credentials scoped to specific zones or records (target 100%), and their age against rotation policy.
- Time to detect a test delegation or record change made in a controlled exercise.
- Domains within 60 days of expiry without auto-renew confirmed (target 0).
Hardening baseline
- Inventory the portfolio: every registered domain, registrar, account, DNS host, contacts, expiry date, lock status and business criticality. SAC044 also advises keeping records that prove registration.
- Consolidate registrars: fewer accounts with stronger controls beat many forgotten ones; choose registrars that support MFA with security keys, named users, audit logs and registry lock.
- Lock accounts: named users, phishing-resistant MFA, contact email on a separate domain, role contacts, break-glass procedure.
- Lock domains: client transfer and delete prohibitions everywhere; registry lock for critical domains; document and test the unlock procedure with the registrar.
- Zones as code: keep zones in version control, apply changes through pipelines with reviewed pull requests, and compare live answers with the repository daily.
- Scope machine credentials: per-zone or per-record tokens, short-lived CI credentials, TSIG per secondary, no registrar rights for automation.
- Add CAA and DNSSEC: CAA for every domain that issues certificates; DNSSEC where you can operate key management reliably.
- Monitor: delegation, status codes, CT logs, audit logs and renewals, with alerts routed to on-call.
Testing and rollback: rehearse a registry-locked change end to end before you need it, so the unlock delay is known; lower TTLs before planned migrations; keep the previous zone in version control so a bad change is a revert, not a rebuild. NIST SP 800-81 Rev. 3, the Secure DNS Deployment Guide finalised in March 2026, is the reference for the wider deployment; see the NIST SP 800-81 Rev. 3 Secure DNS Deployment Guide.
Small versus large: a small organisation with a handful of domains can reach a strong position in a day: one reputable registrar, security keys, registrar lock, auto-renew with a valid card, CAA and CT alerts. Large portfolios need a domain management function, registry lock for tier 1 domains, consolidated registrars, and API-driven monitoring.
Common misconfigurations
- Shared registrar login with SMS or no MFA: the most common root cause of DNS hijacks, and exactly what ED 19-01 targeted.
- Registrar contact email on the same domain: once DNS is changed, password reset and change notifications go to the attacker.
- Zone-wide API tokens for certificate automation: a leaked ACME token can change MX or NS records, not just TXT challenges.
- Forgotten domains and lapsed renewals: expired domains used in email addresses, SSO redirect URIs or software packages can be re-registered by anyone.
- Monitoring only your own zone: delegation changes at the parent go unnoticed because your zone file never changed.
- Untested registry lock: a legitimate emergency migration stalls for days because nobody knows the unlock contacts.
Framework mapping
| Framework | Reference | Control |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-20 Secure Name/Address Resolution Service (Authoritative Source); SC-22 Architecture and Provisioning for Name/Address Resolution Service | Authoritative DNS integrity and resilient architecture |
| NIST SP 800-53 Rev. 5 | AC-2 Account Management; IA-2(1) MFA to Privileged Accounts; CM-3 Configuration Change Control; AU-6 Audit Record Review | Registrar and DNS admin accounts, change control, log review |
| NIST CSF 2.0 | PR.AA-05; PR.PS-01; DE.CM-09 | Access permissions managed; configuration management; monitoring |
| ISO/IEC 27001:2022 Annex A | A.5.15 Access control; A.8.2 Privileged access rights; A.8.9 Configuration management; A.8.32 Change management | DNS control planes as privileged, configuration-managed systems |
| CISA | Emergency Directive 19-01 | Record audit, credential reset, MFA, CT monitoring |
| ICANN SSAC | SAC044 | Registrant account protection |
| MITRE ATT&CK | T1584.002 DNS Server; T1583.001 Domains; T1621 MFA Request Generation | DNS takeover, lapsed domain abuse, MFA fatigue |
Practitioner checklist
- Inventory every domain with registrar, DNS host, contacts, lock status, expiry and criticality.
- Enforce named users and phishing-resistant MFA on every registrar and DNS host account; remove SMS fallbacks.
- Move registration contact email to a separate domain with role mailboxes.
- Set client transfer, update and delete prohibitions; add registry lock for critical domains and rehearse unlocks.
- Manage zones as code with reviewed changes and daily drift checks against live answers.
- Scope DNS automation tokens to zones or records; give automation no registrar rights.
- Publish CAA records and deploy DNSSEC where key management is reliable.
- Monitor parent NS and DS, EPP status, CT logs, audit logs and renewals, with on-call alerts.
- Enable auto-renew with a valid payment method and review the portfolio quarterly.
Standards and references
- CISA: Emergency Directive 19-01, Mitigate DNS Infrastructure Tampering
- NIST: SP 800-81 Rev. 3, Secure Domain Name System (DNS) Deployment Guide
- ICANN: EPP Status Codes, What Do They Mean, and Why Should I Know?
- ICANN SSAC: SAC044, A Registrant's Guide to Protecting Domain Name Registration Accounts
- IETF: RFC 8659, DNS Certification Authority Authorization (CAA) Resource Record
- AWS: Using IAM policy conditions for fine-grained access to Route 53 record sets
- Cloudflare: Create an API token
- MITRE ATT&CK: Compromise Infrastructure: DNS Server
Related NHI Mgmt Group resources: DNS Security Guide · DNS Hijack Playbook · Domain Registrar Compromise Playbook · DNSSEC Deployment Guide