DNS security just landed in NIST CSF 2.0. A mapping still isn't a working control.

NIST's OLIR program has finalized and published a mapping between SP 800-81r3, its Secure DNS Deployment Guide, and the Cybersecurity Framework 2.0. In plain terms, the DNS guidance NIST finalized back in March now has a traceable line into the framework most security teams already report against. If you assess your program against CSF 2.0, you can point to specific subcategories and see DNS security called out as part of how you meet them.

That is a real change, and a good one. It is also paperwork. Worth being clear about the difference.

What the mapping does, and what it doesn't

The mapping is a crosswalk. It says: this outcome in CSF 2.0 lines up with this guidance in SP 800-81r3. It puts DNS in the conversation for functions like Detect, where DNS logging and monitoring live, and Protect, where DNSSEC, access control, and DNS hygiene sit. It also hands audit and procurement a standards reference they didn't have before.

What it does not do is tell you whether your own DNS holds up. A crosswalk describes what good looks like. It doesn't check your zones. You can be fully mapped on paper and still be running a domain with no DNSSEC and an A record pointing at an IP that turns up on a threat feed. The framework now agrees DNS matters. Your scan results are still your scan results.

About the numbers everyone quotes

Since we're on the subject, a quick word on the stats that always ride along with this topic. The line that "92 percent of malware uses DNS" is real, but it traces back to Cisco's 2016 Annual Security Report, not to anything recent. Worth knowing before it goes on a slide.

The more current, and more useful, number comes straight from CISA. Since 2022, its Protective DNS service has blocked close to 700 million connection attempts from federal agencies to malicious domains. That one is first party and recent, and it makes the operational case without any help.

Turning the guidance into things you can actually check

SP 800-81r3 organizes DNS security into three pillars: running Protective DNS, protecting the DNS protocol, and protecting the DNS service and infrastructure.

Some of that is internal, and a scanner can't see it. Whether you've deployed a filtering resolver, how you separate duties, how your internal infrastructure is put together - that's an inside job, and no external tool should pretend otherwise.

But a good chunk of it is observable from the outside, and that's the part worth auditing on a schedule:

1. Whether DNSSEC is actually enabled and validating, not just on the roadmap
2. Whether the IPs your records resolve to appear on current threat intelligence
3. What you're exposing at the registration layer

You can poke at most of this by hand. A few of the checks that matter, and what a bad answer looks like:

# 1. DNSSEC: is the zone actually signed, or just talked about?
$ dig +dnssec example.com A
;; flags: qr rd ra;              # no "ad" flag, so the answer isn't authenticated
example.com.  300  IN  A  203.0.113.10
                                # no RRSIG beside the A record either, zone is unsigned

# 2. Spoofing posture: is DMARC even published?
$ dig +short TXT _dmarc.example.com
                                # empty, no DMARC record, the domain is trivial to spoof

# 3. Registration layer: is the domain locked against transfer?
$ curl -s https://rdap.org/domain/example.com | jq '.status'
[
  "active"                      # no "client transfer prohibited", not locked
]

Output above is illustrative. It shows what a failing result looks like, not example.com's live records.

None of that needs access to your network. It needs someone looking at the domain the way anyone on the internet can, and doing it often enough to catch changes.

Where DNSAudit.io fits

This is the gap DNSAudit.io was built for. It scores the DNS security posture of a domain, checks the reputation of the IPs that domain resolves to, and flags what you're exposing at the registration layer. Then it watches for change and alerts you when something moves, so a silent DNSSEC break or a new record pointing somewhere it shouldn't doesn't sit unnoticed for a month.

It is not a CSF assessment and it is not a Protective DNS deployment. It is the evidence layer for the DNS outcomes you can observe from outside, kept current. The mapping tells you which of those outcomes count. A scan tells you where you actually stand on them.

The part that protects anyone

If the news made you wonder how your own domains would score against this, that's the right instinct. Run one through DNSAudit and read the result. Fix what's worth fixing. The framework catching up to DNS is useful on its own. Knowing your zones pass is the part that does the protecting.