DNS, DHCP and IP address management (DDI) platforms drift out of a safe state one forgotten record, one extra administrator and one unlogged resolver at a time, and nobody notices until a subdomain serves an attacker's content or a domain is transferred away. This health check is a quarterly, measured review of the DNS and DDI estate as a whole: external zones, internal resolvers, the DDI management plane and the registrar accounts that sit above them. It turns nine recurring risks into metrics with formulas, data sources and green, amber and red thresholds. It is for network and DNS owners, DDI administrators, security operations and the risk owners who need evidence that the naming layer is still under control.
The DNS Security Checklist is the item-by-item review form for a single estate; this page is the trend measurement that runs every quarter and tells you whether those controls are holding. Design guidance sits in the DNS Security Guide, and platform selection in the DDI buyer's guide.
What this health check covers
The nine metrics cover four areas:
- External zone integrity: dangling CNAMEs, stale records and zone transfer exposure on authoritative servers.
- Trust and protection: DNSSEC signing and validation coverage, and the share of clients whose queries pass through protective DNS.
- Management plane: DDI administrator count and hygiene, registrar lock status, and the accuracy of IPAM data against what is really on the network.
- Visibility: resolver query logging coverage, the data incident responders need first in most investigations.
Who runs it: the DNS or DDI platform owner collects the data, security operations reviews the logging and protective DNS figures, and the head of infrastructure or CISO signs it off. How to audit DNS with it: run all nine metrics each quarter, raise a finding for every amber or red result, and attach the zone exports, admin role export and registrar status output as evidence.
The metrics evidence NIST SP 800-53 Rev. 5 SC-20 (secure name and address resolution service, authoritative source), SC-21 (recursive or caching resolver) and SC-22 (architecture and provisioning for name and address resolution), with CM-8 (system component inventory), AC-2 (account management) and AU-2 (event logging). In NIST CSF 2.0 they support ID.AM-03 (authorised network communication and data flows), DE.CM-01 (networks and network services are monitored) and PR.PS-04 (log records are generated and made available). The detailed deployment guidance is NIST SP 800-81 Rev. 3, Secure Domain Name System (DNS) Deployment Guide, published as Final in March 2026; see the NIST SP 800-81 Rev. 3 Secure DNS Deployment Guide.
Key takeaways
- Dangling CNAMEs should be zero. Every record that points at a deprovisioned cloud resource is a subdomain an outsider may be able to claim, with your cookies and a valid certificate.
- Measure from outside as well as inside. Zone transfer exposure and registrar lock status are only proven by testing from the internet and reading the registry's own status output.
- Coverage beats configuration. DNSSEC and protective DNS count only for the zones and clients they actually reach; report percentages, not "enabled".
- The DDI console is a tier 0 system. Whoever can change DNS can redirect mail, sign-in and software updates, so admin count, MFA and named accounts are core metrics.
- Logs you do not collect cannot help responders. Resolver logging coverage below 100% leaves blind spots for DNS tunnelling, command and control and malware lookups.
How to use this template
Copy the metrics table and the findings log into your own tracker, then run this DNS and DDI Health Check at the cadence set out below. Collect each figure from the data sources described, score it against the thresholds, and record every amber or red result as a finding with an owner and a due date. Keep each completed review so you can compare quarters: a rising stale record count or a creeping admin count is a warning even while the score is still green.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Dangling record scan of external zones | Weekly (automated), reviewed monthly | DNS platform owner | Cloud platform lead | Scan output, removal tickets |
| Certificate Transparency monitoring for owned domains | Continuous, reviewed monthly | Security operations | DNS platform owner | Alert log, unauthorised certificate reports |
| Full health check (all nine metrics) | Quarterly | DNS or DDI platform owner | Head of infrastructure or CISO | Metrics table, findings log, zone and role exports |
| DDI and registrar admin review | Quarterly | Identity team | DNS platform owner | Role export, MFA status, registrar user list |
| Registrar and registry lock check | Quarterly and after any registrar change | Domain portfolio owner | Legal or brand owner | Registry status output per domain |
| Independent assurance | Annually | Internal audit | Audit committee | Audit report, management responses |
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "Critical domains" are the registered domains used for email, customer sign-in, public websites and software distribution. "Managed clients" are the endpoints, servers and workloads your organisation configures.
| ID | Metric | Formula | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| DNS-01 | Dangling CNAMEs | Count of CNAME, A and AAAA records in public zones whose target cloud resource, hostname or IP address is no longer provisioned in an account you own | Zone export joined to cloud resource inventory; dangling record scanner output | 0 | 1 to 2, each removed within 5 days | Any older than 5 days, or any on a critical domain |
| DNS-02 | Zone transfer exposure | Authoritative servers (primary and secondary, internal and external) that answer an AXFR or IXFR request from an address outside the approved transfer list, or without TSIG where TSIG is policy / authoritative servers | External and internal transfer test results; server transfer configuration | 0% | Internal server open to internal networks only | Any server answering transfer requests from the internet |
| DNS-03 | DNSSEC coverage | Two figures: public zones signed with a valid chain of trust (DS published at the parent) / public zones in scope; and recursive resolvers performing validation / recursive resolvers | Zone signing status, DS record lookup at the parent, resolver configuration | ≥ 95% signed and 100% validating | 80% to below 95% signed, or any non-validating resolver with an approved exception | < 80% signed, or a signed zone with an expired signature or broken chain |
| DNS-04 | Protective DNS coverage | Managed clients whose DNS queries resolve through the protective DNS service (on network and roaming) / managed clients | Endpoint DNS configuration report, protective DNS client list, firewall logs of outbound port 53, 853 and DoH traffic that bypasses it | ≥ 98% | 90% to below 98% | < 90% |
| DNS-05 | Stale records | Records with no owner, no matching asset and no query hits in the last 90 days / total records (report public and internal zones separately) | Zone export, IPAM or CMDB owner field, authoritative query logs | ≤ 2% | Above 2% to 5% | > 5% |
| DNS-06 | DDI admin count and hygiene | Count of accounts with write access to zones, DHCP scopes or platform settings; plus the share that are named, use phishing-resistant MFA through SSO and were reviewed this quarter | DDI console role export, identity provider assignment and MFA logs, API key list | Count at or below the approved maximum and 100% hygiene | Count up to 20% above maximum, or 95% to below 100% hygiene | Shared or local admin accounts in use, or hygiene < 95% |
| DNS-07 | IPAM accuracy | Sampled live IP addresses (from DHCP leases, ARP or network scan) whose IPAM record matches in status, owner and hostname / sampled live addresses | IPAM export, DHCP lease table, network discovery scan | ≥ 95% | 85% to below 95% | < 85% |
| DNS-08 | Resolver logging coverage | Recursive resolvers and protective DNS services whose query logs (client, query name, type, response code) reach the SIEM with no gap over 1 hour in the quarter / recursive resolvers and services | Resolver logging configuration, SIEM ingestion health report | 100% | 90% to below 100% | < 90% |
| DNS-09 | Registrar lock status | Critical domains showing clientTransferProhibited, clientUpdateProhibited and clientDeleteProhibited (or a registry lock where offered) and auto-renew on / critical domains | Registry status output (RDAP or WHOIS), registrar portfolio export | 100% | Transfer lock on all, update or delete lock missing on some | Any critical domain without transfer lock, or expiring within 30 days without auto-renew |
Alongside the table, report two counts without thresholds: the number of unauthorised certificates found in Certificate Transparency logs for your domains, and the number of DNS changes made outside the change process. Both should be zero; any non-zero value is an investigation, not a trend.
How to collect the data
- Join zones to cloud inventory (DNS-01, DNS-05). Export every public and internal zone. For each CNAME, A and AAAA record, check whether the target exists in a cloud account, subscription or project you own. Microsoft's guidance on subdomain takeover describes the risk: a CNAME that still points to a deleted resource lets another tenant claim that resource name and serve content, harvest cookies scoped to the parent domain, obtain a valid certificate or receive mail. Pull query counts per record from authoritative logs to spot records nothing uses.
- Test zone transfers from outside and inside (DNS-02). From an approved external test host and from a normal internal subnet, request a transfer from every authoritative server listed in your NS records and every hidden primary. RFC 5936 states that implementations should restrict transfers to specific clients, should not default to open, and recommends TSIG or SIG(0) based access control.
- Read DNSSEC status at the parent (DNS-03). For each public zone, confirm a DS record is published at the parent and that signatures are valid and not near expiry. RFC 9364 (BCP 237) names DNSSEC as the best current practice for origin authentication of DNS data, and points to RFC 7344 and RFC 8078 for automating DS maintenance, which removes the most common cause of broken chains during key rollover. Check that every recursive resolver has validation turned on.
- Prove protective DNS reaches clients (DNS-04). Compare the endpoint inventory with the protective DNS client or site list, then look for bypass: outbound DNS on port 53 to resolvers other than your own, DNS over TLS on port 853, and DNS over HTTPS to public providers. Services such as the NCSC Protective DNS and the CISA Protective DNS resolver block resolution of known malicious domains and make log data available; a roaming client is what covers laptops off the corporate network.
- Export DDI roles and keys (DNS-06). List every user, group, API key and integration account with write access to zones, DHCP scopes, IPAM or platform settings, and match each to a named owner and an identity provider MFA record. Include automation accounts used by provisioning pipelines and certificate tooling. CISA Emergency Directive 19-01 required MFA on all accounts on systems that can change DNS records, and that is a sound baseline for every organisation.
- Sample IPAM against the network (DNS-07). Take a random sample of at least 100 live addresses from DHCP leases and a discovery scan across several subnets, and check each against its IPAM record. See IPAM for Security Teams for why responders depend on this data.
- Check log arrival, not log settings (DNS-08). Use the SIEM's ingestion report per resolver for the quarter. A resolver that is configured to log but whose logs never arrive scores as not covered. See the DNS Logging and Detection Guide for the fields to keep.
- Read registry status codes (DNS-09). Query RDAP or WHOIS for each critical domain and record the EPP status codes. ICANN explains that client codes such as clientTransferProhibited are set by registrars, while server codes are set by registries and take precedence; server locks are usually applied at the registrant's request through a registry lock service. Confirm registrar account users and their MFA at the same time.
Store evidence outside the DDI platform. If the platform or registrar account were compromised, its own reports are the first thing an attacker would change.
Red flags that need action now
- A dangling CNAME on a domain used for sign-in, email or customer portals, or any evidence that the target has already been claimed by someone else.
- An authoritative server answering zone transfers from the internet.
- A signed zone with expired signatures or a DS record that no longer matches the key, which makes the zone fail to resolve for validating resolvers.
- Records changed at the registrar or authoritative provider with no matching change ticket, or a new certificate for your domain that nobody requested.
- A critical domain without a transfer lock, or within 30 days of expiry with auto-renew off.
- Shared or local DDI admin accounts, registrar logins without MFA, or API keys with full write access and no owner.
- A resolver whose logs stopped arriving in the SIEM and nobody was alerted.
Treat changed records, unexpected certificates and new registrar users as possible signs of DNS hijacking. Adversaries compromise DNS servers as attack infrastructure (MITRE ATT&CK T1584.002, Compromise Infrastructure: DNS Server) and gather DNS data for reconnaissance (T1590.002, Gather Victim Network Information: DNS). Follow the DNS Hijack Playbook rather than fixing records quietly.
Findings log
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-DNS-01 | [e.g. 3 CNAMEs point to deleted storage and app hosting endpoints] | DNS-01 | [Critical] | [DNS platform owner] | [date] | [Open] |
| HC-DNS-02 | [e.g. secondary server at hosting provider allows transfers to any address] | DNS-02 | [High] | [Network lead] | [date] | [Open] |
| HC-DNS-03 | [e.g. 14% of laptops send DoH to a public resolver, bypassing protective DNS] | DNS-04 | [High] | [Endpoint team] | [date] | [Open] |
| HC-DNS-04 | [e.g. 2 shared DDI admin accounts and 1 ownerless API key] | DNS-06 | [Critical] | [Identity team] | [date] | [Open] |
Severity guide: Critical where an outsider could take over a name or redirect traffic now, High for exposure or coverage gaps on critical domains and resolvers, Medium for internal hygiene gaps, Low for record-keeping gaps.
Where identity fits
Three identity populations decide whether the DNS estate stays safe: human DDI administrators, registrar portal users and the non-human identities that change DNS automatically. The last group grows fastest. Infrastructure as code pipelines, certificate automation that writes ACME DNS challenge records, external DNS controllers in Kubernetes and DDI integrations with cloud providers all hold credentials that can create or delete records. Scope each one to the zones it needs, prefer short-lived or federated credentials over long-lived API keys, give each an owner, and include them in DNS-06. See the Authoritative DNS and Registrar Account Security Guide for account controls at the registrar.
Remediation map
| Finding type | Where the fix is described |
|---|---|
| Dangling CNAMEs and stale records | Subdomain Takeover and Dangling DNS Guide; if a name was claimed, the Subdomain Takeover Response Playbook |
| Unsigned zones or broken DNSSEC chains | DNSSEC Deployment Guide |
| Clients bypassing protective DNS | Protective DNS Guide and Encrypted DNS Enterprise Guide |
| Registrar locks, registrar users and domain expiry | Authoritative DNS and Registrar Account Security Guide and Domain and DNS Management Policy Template |
| Resolver logging gaps | DNS Logging and Detection Guide |
| Platform hardening (zone transfers, admin roles, API keys); platforms listed alphabetically | BIND DNS Server Hardening, CoreDNS Security, Infoblox DDI Security, PowerDNS Security, Windows Server DNS and DHCP Security |
Related guides
- DNS Security Checklist: the item-by-item review form behind these metrics.
- DNS Security Guide: the design this check measures.
- DDI buyer's guide: platform capabilities that make these metrics easier to collect.
- IPAM for Security Teams: why accurate IPAM data matters in investigations.
- DNS Hijack Playbook: what to do when a red flag turns out to be an attack.
References
- NIST: SP 800-81 Rev. 3, Secure Domain Name System (DNS) Deployment Guide
- CISA: Emergency Directive 19-01, Mitigate DNS Infrastructure Tampering
- IETF: RFC 9364, DNS Security Extensions (DNSSEC)
- IETF: RFC 5936, DNS Zone Transfer Protocol (AXFR)
- ICANN: EPP Status Codes, What Do They Mean, and Why Should I Know?
- Microsoft Learn: Prevent dangling DNS entries and avoid subdomain takeover
- NCSC: Protective Domain Name Service (PDNS)
- CISA: Protective Domain Name System Resolver
Related NHI Mgmt Group resources: DNS Security Checklist, DNS Security Guide, the DDI buyer's guide and Subdomain Takeover and Dangling DNS Guide.