How DNS by echo reply aligns with NIST SP 800-81r3
NIST published SP 800-81r3, Secure Domain Name System (DNS) Deployment Guide, in March 2026. It supersedes SP 800-81-2 from September 2013. NIST also links a potential-updates workbook from the publication page, so implementers should check that page for errata alongside the PDF.
The document covers three areas. Section 3 addresses authoritative DNS services, Section 4 covers recursive and forwarding services, and Section 5 covers stub resolvers. It also introduces protective DNS as a significant new topic (Section 2.1).
This article maps the recommendations relevant to authoritative DNS management to what DNS by echo reply does and does not do. The goal is to give you concrete talking points for compliance reviews and vendor evaluations — not a marketing pitch.
Why this update matters
The 2013 version of this guide predated widespread adoption of DNS-over-TLS and DNS-over-HTTPS, predated ECDSA as a common DNSSEC algorithm, and predated the shift to cloud-hosted DNS management. The threat landscape has changed substantially. DNS hijacking, credential-based zone takeover, and supply chain attacks on DNS providers are all documented attack vectors that the previous guidance did not address.
SP 800-81r3 reflects this. The executive summary frames DNS as “a foundational layer of network security in zero trust and defense-in-depth security risk management approaches.” That is a meaningful shift — DNS is no longer treated as just an operational service but as a security control in its own right.
Even if your organisation is not US-based and not required to follow NIST guidance, SP 800-81r3 can be a useful baseline. Organisations subject to NIS2 or DORA can use a documented mapping to explain why they selected particular DNS controls. The mapping is supporting technical evidence, not a legal conclusion or certification.
This article focuses on Section 3 of SP 800-81r3 — managing threats to authoritative services — since that is what the platform provides.
Recommendation mapping
A note on scope. SP 800-81r3 is a protocol and infrastructure security guide. It does not prescribe specific management platform features like RBAC or change approval workflows. Where the platform’s capabilities align with the intent of a recommendation — for example, preventing unauthorized zone modifications — this article says so explicitly rather than implying NIST mandates a specific implementation.
DNSSEC signing algorithms (Sec 3.8.1)
SP 800-81r3 lists the current set of DNSSEC signing algorithms in Table 1, referencing RFC 8624:
| Algorithm | DNSSEC code |
|---|---|
| RSA/SHA-256 | 8 |
| ECDSA P-256/SHA-256 | 13 |
| ECDSA P-384/SHA-384 | 14 |
| Ed25519 | 15 |
| Ed448 | 16 |
The document states that algorithms such as ECDSA and Ed448 are preferable to RSA because they produce smaller keys and signatures. RSA is still listed, and the table should not be presented as a mandate that every listed algorithm is equally preferred.
Implemented platform control: New signing uses the configured PowerDNS algorithm, whose platform default is ECDSAP256SHA256 (algorithm 13). The compliance view reads the stored key algorithm per signed zone and flags its posture. Operators should verify deployed configuration and existing zones rather than assume every zone uses the default.
Key management and rollover (Sec 3.8.1, 3.8.2)
The document recommends a maximum key lifetime of 1–3 years for signing keys and notes that automated tools exist for ZSK rollovers and should be used. KSK rollovers involve the delegating parent zone and are more complex. HSM storage is recommended for KSK material where practical. DNSKEY RRSIG validity periods should be kept short — 5–7 days — to limit the window of exposure if a key is compromised.
Current platform status: PowerDNS generates and stores signing keys server-side, and the platform exposes the DS information needed at the parent. The compliance view measures signing-key age against its review thresholds. Automatic ZSK or KSK rollover is not implemented, so operators remain responsible for planning, executing and validating rollover before keys exceed their policy limits.
Zone transfer security (Sec 3.1)
SP 800-81r3 recommends restricting zone transfers to known secondary servers via access control lists, using TSIG for authentication and integrity of zone transfer transactions, and using TLS for confidentiality. The document also recommends hidden primary configurations where the primary authoritative server is not listed in the zone’s NS RRset.
Implemented platform control: Private Masters require TSIG-authenticated transfers. Plain DNS-over-TCP is the default transport. XFR-over-TLS is an opt-in mode when the customer’s primary supports it. Transfer health is monitored. Customers must configure their primary, ACLs, TSIG handling and optional TLS endpoint correctly.
Zone content protection (Sec 3.2, 3.3, 3.6)
Several sections of SP 800-81r3 address the risk of unauthorized zone modifications. Section 3.3 documents threats from unauthorized dynamic updates — adding illegitimate resources, deleting legitimate ones, or altering delegation records. Section 3.6 covers external domain integrity threats including dangling CNAME exploitation and lame delegation hijacking. Section 2.2.3 recommends that organizations “continuously monitor and validate the integrity of their public domains.”
The document does not prescribe a specific change management workflow for DNS management platforms, but the risks it identifies — unauthorized modifications reaching production zones — are exactly what change management controls exist to prevent.
Implemented platform control: Stashed changes support proposal, diff review, approval and rejection. Users with a separate self-approval permission can apply their own changes, so customers must assign roles and approval policy to achieve the separation of duties they require.
TTL policies (Sec 3.7.1)
SP 800-81r3 provides specific guidance on TTL values. The recommended range is 1800 seconds (30 minutes) to 86400 seconds (1 day). The document states that “a TTL of 0 should never be used” and warns that very low TTL values (30 seconds or less) can cause problems with DNSSEC-validating caches. DNSSEC signature validity periods must also be considered — TTL values should be less than the RRSIG validity period.
Current platform status: Record input rejects non-positive values and the web form currently enforces a minimum of 60 seconds, but it does not enforce NIST’s full 1800–86400-second recommended range. Customers should set TTL policy appropriate to their zones and review exceptions. This recommendation is therefore only partially addressed.
DNS logging (Sec 2.1.3)
The document states that “government agencies and regulated enterprises should implement robust DNS traffic logging mechanisms to meet compliance requirements.” It specifies that logging should capture both current and historical DNS traffic to enable digital forensics and incident response (DFIR), and that logs should be integrated with SIEM or log analysis platforms.
It is worth noting that SP 800-81r3 primarily discusses DNS query and response traffic logging, not management-plane audit trails. These are two different things. Query logging tracks what is being resolved, while audit logging tracks who changed what in the zone configuration.
Implemented platform control: The platform provides append-protected, tenant-scoped management history and activity views for supported resources, with CSV history export and Enterprise PDF/CSV compliance reports. Login history and management-model history are separate datasets. An IP address or complete before/after state is not promised for every event. Retention follows the applicable product policy rather than a universal 12-month period. This is management-plane evidence and does not replace authoritative DNS query/response logging or SIEM integration.
Alignment summary
| NIST recommendation | Section | Platform status | Notes |
|---|---|---|---|
| Use a recommended DNSSEC algorithm | 3.8.1 | Supported, verify per zone | Algorithm 13 is the configured default. Actual keys are inspected |
| Signing-key lifecycle management | 3.8.1, 3.8.2 | Partial | Age checks are implemented. Rollover remains an operator task |
| Secure zone transfers | 3.1 | Supported, configuration-dependent | TSIG is required. XFR-over-TLS is optional |
| Zone content protection | 3.2, 3.3, 3.6 | Supported, policy-dependent | Stashed review exists. Authorised users may self-approve |
| TTL policies (1800–86400s range) | 3.7.1 | Partial | Basic validation exists. The full recommended range is not enforced |
| DNS administrative logging | 2.1.3 | Complementary control | Append-protected management history. Not DNS traffic logging |
Using this for internal discussions
If you are evaluating DNS management platforms, the table above works as a checklist. Ask your current provider the same questions. What DNSSEC algorithm do they default to? Do they support TSIG+TLS for zone transfers, enforce TTL policies, and provide an audit trail of zone changes?
For organisations subject to NIS2 or DORA, NIST alignment is not an EU legal requirement. A dated control mapping can show how technical guidance informed your choices, but the organisation remains responsible for assessing applicability, documenting exceptions and testing the controls. For the DORA-specific context, see DORA compliance for DNS infrastructure.
SP 800-81r3 gives you a framework for the conversation with management. The recommendations are specific and the section references are citable. That is more useful than a checkbox.
Further reading
- NIST SP 800-81r3 — full document (free)
- DORA compliance for DNS infrastructure — how DORA maps to DNS operations
- DNSSEC setup — platform DNSSEC documentation
- NIS2 compliance guide — NIS2 compliance features