Most DNS incidents trace back to something a periodic review would have caught: a registrar account without MFA, a critical domain with no lock, a CNAME pointing at a deleted cloud resource, or resolvers that will look up any malicious domain they are asked for. This checklist is the run sheet for that review. It covers the three layers an organisation controls: the registrar and registry (who can change your delegation), the authoritative zones (what your records say), and your recursive resolvers (what your users and workloads can reach). Each line is a pass or fail check with the evidence to collect. It is written for network, DNS and security teams running an annual or quarterly DNS audit. Why each control matters is explained in the DNS Security Guide; this page is the checklist.
How to use this template
Replace every [placeholder] with your values. Run the checklist for each registered domain in the critical tier, and sample the rest; list domains in section 1.
Mark each line Pass, Fail, Partial or Not applicable and record evidence (registrar screenshot, WHOIS or RDAP status output, zone export, resolver configuration, ticket reference).
Do not make changes during the review. DNS mistakes propagate and cache: fix failures through change control, lower TTLs before planned changes, and keep the previous zone file for rollback.
Run the full checklist at least [annually] and after any registrar change, DNS provider migration, merger or DNS incident. Run sections 2, 4 and 6 [quarterly].
[internal resolvers; protective DNS service; cloud resolvers]
DNSSEC status per critical domain
[signed / unsigned]
Reviewer, date, result
[Name], [date], [Pass / Pass with findings / Fail]
2. Registrar and registry accounts
#
Check
Expected result
Result and evidence
2.1
All critical domains are held in an organisation-owned registrar account, not a personal or agency account
Registrant is [Organisation]; account owned by a role mailbox
[ ]
2.2
Every user on the registrar and DNS hosting accounts is named, current and needed
No shared logins; leavers removed
[ ]
2.3
MFA is enforced for every user on registrar and DNS hosting accounts, using phishing-resistant factors where supported, not SMS
MFA on 100% of users
[ ]
2.4
API keys and tokens that can change registration or records are inventoried, scoped to the zones they need, stored in [secrets manager] and owned
Token list with owner, scope, expiry
[ ]
2.5
Registrar lock is set: clientTransferProhibited at minimum, plus clientUpdateProhibited and clientDeleteProhibited for critical domains
Status codes visible in RDAP or WHOIS
[ ]
2.6
Registry lock (serverUpdateProhibited, serverTransferProhibited, serverDeleteProhibited) is set for critical domains where the TLD and registrar offer it, with named authorised contacts and a tested unlock process
Server status codes visible; unlock contacts listed
[ ]
2.7
Auto-renew is on, payment details are current, and renewal notices go to a monitored role mailbox
Expiry over [12 months] away for critical domains
[ ]
2.8
Registrant and admin contact email addresses use a domain different from the one they protect, or a domain the attacker could not control through this one
Recovery not dependent on the domain itself
[ ]
3. Delegation and DNSSEC
#
Check
Expected result
Result and evidence
3.1
NS records at the parent match the intended authoritative providers and the NS set in the zone
No unknown name servers
[ ]
3.2
Critical zones are signed with DNSSEC using algorithm 13 (ECDSAP256SHA256) or 15 (ED25519)
Signed; RSASHA1 not used
[ ]
3.3
The DS record at the parent uses a SHA-256 digest and matches a current key
Validation succeeds from an external validating resolver
[ ]
3.4
Denial of existence uses NSEC, or NSEC3 with zero iterations and no salt
Configuration export
[ ]
3.5
Signature expiry and key rollovers are automated and monitored, with alerts before RRSIG expiry
Alert rule exists and has fired in test
[ ]
3.6
Secondary DNS or a second provider is in place for critical zones, with zone transfers restricted to named servers (and authenticated with TSIG where used)
Public records on all authoritative and secondary servers resolve to the intended locations; NS records and records for key services (web, mail, VPN, identity) checked first
Every record matches the inventory
[ ]
4.2
Every record has a known owner, recorded in [DNS inventory]
No ownerless records
[ ]
4.3
No CNAME, alias, A or AAAA record points to a deprovisioned cloud resource, expired third-party service or unregistered domain
Dangling record scan clean
[ ]
4.4
Cloud custom domains use the provider's domain verification records (for example asuid TXT records for Azure App Service) and alias records where available
Verification records present
[ ]
4.5
"Remove DNS record" is a mandatory step in the decommissioning checklist for cloud and SaaS resources
Step present in [procedure]
[ ]
4.6
CAA records name the certificate authorities allowed to issue (issue, issuewild) and an iodef contact
CAA present on critical domains
[ ]
4.7
Mail records are correct: SPF, DKIM and DMARC published for sending domains; non-sending and parked domains publish SPF "v=spf1 -all", a reject DMARC policy and a null MX
Authoritative servers do not offer open recursion to the internet
Recursive queries from outside refused
[ ]
5.2
Self-hosted DNS software is supported and patched within [vulnerability management timescales]
Version within support
[ ]
5.3
Administrative access to DNS servers and management consoles uses named privileged accounts with MFA; changes are logged
Admin list and audit log sample
[ ]
5.4
Dynamic updates to internal zones are restricted to authenticated clients (for example secure dynamic updates only in Active Directory integrated zones)
Zone settings export
[ ]
5.5
Response rate limiting or provider DDoS protection is in place for authoritative service
Configuration or contract evidence
[ ]
6. Recursive resolvers and protective DNS
#
Check
Expected result
Result and evidence
6.1
All corporate devices, servers and cloud workloads use [approved resolvers]; outbound port 53 to other resolvers is blocked at the perimeter
Firewall rule and test
[ ]
6.2
A protective DNS service or resolver policy blocks or sinkholes lookups of known malicious domains, and covers roaming and remote devices, not just the office network
Block test with a test domain
[ ]
6.3
Resolvers perform DNSSEC validation
Lookup of a deliberately broken test domain fails
[ ]
6.4
Encrypted DNS (DoH, DoT) from browsers and applications is either directed to the approved resolver or blocked, so it cannot bypass protective DNS
Browser and endpoint policy evidence
[ ]
6.5
Internal resolvers are not reachable from the internet
Alerts fire on any change to NS, DS or registration status codes for critical domains
Monitoring rule and test result
[ ]
7.2
Certificate Transparency logs are monitored for certificates issued for [Organisation] domains, and unrequested certificates are reported to the issuing CA
CT monitoring in place
[ ]
7.3
Registrar and DNS hosting audit logs (logins, record changes, API use) are forwarded to [SIEM]
Log source present
[ ]
7.4
Resolver query logs are retained for [90 days] and searchable by the SOC, including protective DNS block events
Query a known event
[ ]
7.5
Lookalike and typosquat domain registrations are monitored for critical brands
Signed off by [DNS service owner] and [CISO] on [date]. Next review due [date].
Implementation guidance
Where the checks come from
Record audits, credentials and CT: CISA Emergency Directive 19-01, issued to US federal civilian agencies in early 2019 (its first status report was due on 25 January 2019) after DNS infrastructure tampering, required agencies to audit public DNS records on all authoritative and secondary servers (prioritising NS records and key services), change passwords on accounts that can change DNS records, add MFA to those accounts, and monitor Certificate Transparency logs for unrequested certificates. CISA states the directive remains in effect until replaced or terminated. Checks 2.3, 4.1 and 7.2 follow it, and are good practice for any organisation.
Locks: registry lock sets the server status codes at the registry, so a stolen registrar password alone cannot move name servers; availability and the unlock process vary by registry and registrar. See the Authoritative DNS and Registrar Account Security Guide.
Dangling DNS: Microsoft describes a dangling record as a CNAME that still points to a deprovisioned resource, which anyone who claims that resource name can then serve content from, harvest cookies scoped to the parent domain and obtain valid certificates for. Its recommendations, domain verification records, alias records, delete locks and DNS removal as a decommissioning step, are generic patterns reflected in section 4.
Protective DNS: CISA's Protective DNS Resolver, mandated for US federal civilian agencies, blocks, redirects or sinkholes queries that match threat intelligence and covers mobile, roaming and cloud assets. Check 6.2 asks for the same outcome from whatever service you use.
DNSSEC parameters: algorithm, digest and NSEC3 settings in section 3 follow RFC 8624 and RFC 9276 as summarised in the DNSSEC Deployment Guide. NIST SP 800-81 Rev. 3, the Secure DNS Deployment Guide, was published as final on 19 March 2026; see the NIST SP 800-81 Rev. 3 Secure DNS Deployment Guide.
Running the review
Export the domain list from every registrar account and reconcile it with finance records of domain renewals; unknown domains are a finding.
Pull status codes, NS and DS for each critical domain from public RDAP and DNS, not from the registrar portal alone.
Export every zone and match records to the cloud asset inventory to find dangling targets.
Test resolvers from a corporate device, a remote device and a cloud workload, using a protective DNS test domain and a DNSSEC-broken test domain.
Record findings in section 8, fix through change control with lowered TTLs and a saved previous zone file, then re-test.
Where identity fits
DNS control is an identity problem first: the registrar login, the DNS hosting console and the API tokens used by automation and certificate tooling can each redirect every service on a domain. Treat them as privileged accounts and non-human identities, with MFA, named owners, scoped tokens and rotation. See the Domain Registrar Compromise Playbook.
Measures
Lock coverage: percentage of critical domains with registrar lock and, where offered, registry lock.
MFA coverage: percentage of registrar and DNS hosting users with MFA (target 100%).
Dangling records: number found per quarter and median time to remove.
Protective DNS coverage: percentage of endpoints and workloads whose queries pass through the protective resolver.
Renewal margin: critical domains expiring within [90 days] without confirmed renewal (target zero).
Common failure patterns
Expired or abandoned domains still trusted: in ForcedLeak, an expired domain bought for $5 helped turn an AI agent into a data exfiltration tool. Checks 2.7 and 4.3 look for exactly these leftovers.
Locks without a tested unlock: a registry lock nobody knows how to lift delays legitimate emergency changes. Check 2.6 requires named contacts and a tested process.
Office-only protective DNS: remote and cloud workloads bypass it. Checks 6.1, 6.2 and 6.4 cover them.
NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 8 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security.
nhimg.org
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.