DNS security is having a moment. In March 2026, NIST published SP 800-81r3, its first major update to federal DNS security guidance in thirteen years, and it reframes DNS from passive infrastructure into an active security control that should block threats, feed telemetry to security operations, and be audited like firewall rules. The EU's NIS2 directive references the same NIST guidance as a benchmark, bringing over 180,000 organizations into scope. DNS, long treated as plumbing, is now a compliance obligation.
As organizations respond, two terms come up that are easy to confuse: Protective DNS (PDNS) and DNS posture management. They both sit under the "DNS security" umbrella, they are both endorsed by the modern guidance, and they sound similar enough that people assume one covers the other. They do not. They protect different things, in different directions, and a complete DNS security program generally needs both. This article explains what each one is, why they are distinct, and how they fit together.
Protective DNS: Guarding Outbound Resolution
Protective DNS is a resolver-layer control. It sits between your users and devices and the internet, and it inspects every outbound DNS query they make. When a device tries to resolve a domain, PDNS checks that domain against threat intelligence and policy, and if the domain is known-bad, a phishing site, a malware host, a command-and-control server, it refuses to resolve it. The connection never forms, because the name never turns into an address.
The direction here is important: PDNS protects your people from reaching dangerous places. It is about your outbound traffic. If an employee clicks a phishing link or a piece of malware tries to phone home to its command-and-control infrastructure, PDNS is the layer that can stop the DNS lookup from succeeding. Services like Cisco Umbrella, Cloudflare Gateway, and Quad9 operate in this category, and national programs run PDNS at population scale. It is, deservedly, one of the highest-leverage security controls an organization can deploy, and the new guidance endorses it strongly.
DNS Posture Management: Guarding Your Own Domains
DNS posture management points in the opposite direction. It is not about your users' outbound resolution at all. It is about the security and correctness of the domains your organization owns and publishes to the world.
Where PDNS asks "is this domain my user is trying to reach dangerous?", DNS posture management asks "are my own domains configured securely and behaving as they should?" That means continuously checking your domains for dangling records that enable subdomain takeover, verifying your DNSSEC chain of trust is intact, confirming your SPF, DKIM, and DMARC records actually protect against spoofing, watching for unauthorized nameserver and registrar changes that signal hijacking, and tracking domain expirations. This is the discipline we describe in our guide to DNS posture management.
The direction is inbound and self-directed: it protects the domains that represent you to the rest of the world, so that customers, partners, and email recipients who interact with your domains are interacting with something secure and uncompromised.
Why One Does Not Cover the Other
Put the two directions side by side and the distinction is clear. PDNS watches what your users try to resolve, outbound, and blocks the dangerous ones. DNS posture management watches the state of your own published domains, inbound and self-owned, and flags when they are misconfigured or tampered with.
A concrete example shows why you need both. Consider a domain-spoofing attack. In April 2026, a commodity trading firm lost 6.6 million dollars after attackers used a lookalike domain, one with two letters transposed, to impersonate a genuine supplier in email. Two different DNS security layers touch this scenario from two sides. PDNS could help stop your own employees from resolving a known malicious lookalike domain if they were targeted. DNS posture management, on your side, ensures your real domain's email authentication (SPF, DKIM, DMARC) is correctly configured so that attackers cannot easily spoof you, and that your DNSSEC is intact so those authentication records cannot be tampered with in transit. One protects your people from reaching bad domains; the other makes your own domain harder to abuse. Neither substitutes for the other.
This is why the modern guidance treats them as separate pillars. NIST SP 800-81r3 endorses Protective DNS as an active control and, in the same document, treats DNSSEC integrity, email authentication, and continuous DNS auditing as distinct requirements. They are different chapters because they solve different problems.
How They Fit Together in a Complete Program
The reassuring part is that PDNS and DNS posture management are complementary, not competing. A mature DNS security program runs both:
- Protective DNS handles the outbound side, filtering the domains your users and systems try to reach, and cutting off phishing, malware, and command-and-control at the resolution layer.
- DNS posture management handles the inbound, self-owned side, continuously assessing that your own domains are securely configured, uncompromised, and correctly authenticating.
Together they cover both directions of DNS risk: the threats your people might resolve toward, and the integrity of the domains the world resolves toward you. The regulatory momentum behind the whole category, NIST SP 800-81r3, NIS2, and the national PDNS programs, is really a recognition that DNS security is multi-layered and that treating DNS as an afterthought is no longer acceptable. Both layers are part of that answer.
What the New Guidance Actually Asks You to Do
Beyond the PDNS-versus-posture distinction, it is worth extracting the practical, vendor-neutral checklist that NIST SP 800-81r3 implies, because that is what the guidance is really asking organizations to act on. None of this is specific to any product; it is the shape of a modern DNS security program:
- Deploy Protective DNS for outbound resolution. Put a filtering resolver between your users and the internet so known-malicious domains cannot be reached. This is the active-blocking pillar the guidance newly endorses.
- Verify your DNSSEC is deployed and valid. A signed zone with an intact chain of trust protects the integrity of your DNS answers, including the TXT records your email authentication depends on. Broken or expired signatures are worse than no DNSSEC, so this needs ongoing validation, not a one-time setup.
- Harden SPF, DKIM, and DMARC. These live in DNS and determine whether your domain can be spoofed. Move DMARC toward an enforcement policy rather than monitoring-only, since the guidance treats email authentication as integral to DNS security.
- Audit DNS like a security control, not plumbing. The core conceptual shift is that DNS configuration should be reviewed and monitored continuously, the way firewall rules are, rather than configured once and forgotten.
- Feed DNS telemetry to your security operations. DNS events and changes should flow into your SIEM so they can be correlated with other signals, which the guidance calls out explicitly.
- Mind your TTLs. The guidance recommends most DNS records use TTLs roughly between 30 minutes and one day, prohibits a TTL of zero, and discourages very short values on DNSSEC-signed records.
A useful way to self-assess: PDNS covers the first item, and DNS posture management covers the middle four (DNSSEC validation, email authentication health, continuous DNS auditing, and feeding change telemetry to your SIEM). If you have a PDNS resolver but nothing continuously checking your own domains' configuration, that is the gap most organizations have.
Being Clear About What DNS Assistant Does
It is worth stating plainly where DNS Assistant sits, because the distinction is the whole point of this article. DNS Assistant is a DNS posture management platform. It monitors the security and correctness of the domains you own: dangling records and subdomain-takeover risk, DNSSEC status, email authentication health, TLS posture, and registrar, WHOIS, and nameserver changes, alerting you in real time when something changes.
DNS Assistant is not a Protective DNS resolver. It does not sit between your users and the internet, and it does not filter or block their outbound queries. If your organization needs PDNS, a resolver-layer filtering service is the right tool for that job, and it is a good one to have. DNS Assistant complements it by covering the other direction, the posture of your own domains, which a PDNS resolver does not assess. The two work well side by side, and together they address more of what the modern DNS security guidance now expects.
Assess Your DNS Posture
You can inspect the posture of a domain you own, its records, DNSSEC status, email authentication, and TLS, with the free DNS lookup tool or a Free Domain Risk Report.
To add continuous DNS posture management alongside your resolver-layer protections, start free at dnsassistant.com. For how this fits broader requirements, see our guide to preparing for NIS2 and DORA DNS requirements.
Start Monitoring Your DNS Today
Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.
Sign Up Free