It's always DNS.
And when it's not DNS, it's BGP.
Every ops engineer has said it. Every CISO has heard it. Every 3 AM outage ends up there eventually. The meme is tired because it's true. For thirty years we've treated the two protocols that hold the internet together as plumbing. Simpler than they are. More resilient than they were designed to be. More critical than anyone wanted to admit.
And we've under-funded it accordingly. Under-staffed it. Under-invested in it. DNS has been neglected for too long, by too many organizations, for reasons everyone in the industry already knows.
Now NIST has caught up.
NIST SP 800-81r3, the latest revision of the DNS guidance that hadn't been meaningfully touched in over a decade, quietly does something its predecessors never did. It stops treating DNS as infrastructure to defend and starts treating it as a control surface in its own right. A policy enforcement point. A telemetry source. A place where Zero Trust decisions actually get made and where bypass attempts actually happen.
That's a real shift. It's also the first time most of us in this business have seen a federal standards body say out loud what operators have known for years. DNS is not plumbing. It's not background. It's load-bearing.
Why the memes exist
DNS was designed in 1983 for an internet with a few thousand hosts and a trust model that assumed everyone was essentially on the same team. BGP came a few years later with a similar set of assumptions. Both protocols were written to answer simple questions about reachability, not to carry the weight of a global economy, a zero trust control plane, and a nation-state threat model.
We've bolted on DNSSEC, RPZ, Protective DNS, encrypted transports, and a decade of operational pain to make them behave. Most of the time it works. When it doesn't, it's always DNS. When it's really not DNS, it's BGP. We reach for those memes because the underlying reality is uncomfortable. The most critical protocols we have are also the most casually operated.
NIST 800-81r3 is an honest acknowledgment that this matters.
What 800-81r3 actually says
Strip away the vendor blog coverage and the text is measured. DNS should integrate "with the wider security ecosystem as part of a defense-in-depth or zero trust approach." Protective DNS is explicitly called out as a way to block harmful resolution before malicious activity starts. DNS query logs are flagged as useful enrichment for access decisions and detection of C2, DGAs, and exfiltration patterns. Clients should be prevented from reaching around enterprise resolvers with rogue DoH or unmanaged egress.
Read together, NIST is saying three things. DNS is a useful enforcement point. DNS is a useful sensor. DNS is a path around your other controls if you don't govern it.
That's it. That's the news. That's all NIST actually said.
It's a meaningful reframe. It isn't a revolution. It isn't a mandate.
Then the marketing got hold of it
Within days of the publication, the vendor chorus started. "DNS is the frontline of Zero Trust." "The first layer of cyber defense." "A game-changer for your security architecture." Blog posts describing 800-81r3 as a "wake-up call." Webinars pivoting immediately into per-seat pricing for cloud Protective DNS platforms. Zero Trust diagrams with DNS suddenly at the center.
NIST did not say any of that.
NIST said DNS is an additional enforcement layer and data source within a broader architecture. The document still spends real page count on the unglamorous work: securing authoritative and recursive infrastructure, DNSSEC validation, resolver hardening, configuration management, and abuse mitigation. The stuff operators should have been doing anyway, and mostly haven't.
There's a difference between a new recognition and a new religion. The vendors are selling the religion.
DNS deserves real investment. It still isn't the first layer of defense.
Both of those things are true at the same time, and you have to hold them together.
DNS is overdue for budget, staffing, and attention. NIST is right to elevate it. Every enterprise I know has a DNS practice that's either neglected, outsourced to the networking team as an afterthought, or quietly running on equipment that was supposed to be replaced years ago. That's a real problem. 800-81r3 is the right call.
And it still isn't the first layer of cyber defense. It's probably not the fifth. Attack Surface Management matters more. Identity matters more. EDR matters more. Patching matters more. Incident response matters more. DNS hygiene belongs on the list of things every mature security program gets right. That's exactly why it deserves real attention, real staffing, and a real line item. A DNS platform on top of all of that is a complement, not a substitute.
DNS is a cheap, broad-coverage enforcement and detection layer that complements the rest of the stack. That's a meaningful role, and it's under-invested almost everywhere. It still isn't the top of the list. And if a vendor needs me to believe it is in order to justify their price tag, that tells me more about the vendor than about the protocol.
No CISO I talk to is going to suddenly change buying patterns because of a NIST revision. Nor should we. If the value isn't there, a NIST citation doesn't create it. If the value is there, a NIST citation isn't what closes the deal. Either way, the vendor's job is the same: show the value.
What this actually looks like in a real enterprise
A reasonable response to 800-81r3 from a security leader looks like this. Harden your authoritative and recursive DNS. Turn on DNSSEC validation. Route clients to enterprise resolvers. Block rogue DoH. Enable Protective DNS, even if it's the open-source or low-friction version. Pipe DNS logs into your SIEM alongside identity and endpoint data. Use DNS as an early, cheap signal in your detection pipeline.
That's most of what NIST is asking for. None of it requires a new seven-figure platform.
If a vendor wants more budget than that, they need to earn it. Show me what your Protective DNS catches that mine doesn't. Show me the integration with identity and endpoint data I can't build in-house. Show me the threat feed I can't get from my SIEM vendor. Show me the response automation that earns its place in the stack. Show me the value without the hype.
If you can't make that case without rewriting the NIST document in your favor, you don't have a case. I've sat through too many vendor pitches where the strongest argument was an appeal to a standards body. That isn't a pitch. That's a hope. That's a tell.
To vendors
Read 800-81r3 carefully. Map your product to what it actually says, not what your marketing team wishes it said. Lead with the specific thing you do better. Retire the "frontline of Zero Trust" line. Stop conflating "NIST mentions DNS" with "NIST endorses our platform."
The hyperbole doesn't land with anyone who's been in the chair. It damages your credibility with the buyers you're trying to reach. It costs you deals you'd otherwise win.
To CISOs
Read 800-81r3 yourself. It's a reasonable document written in plain language, and it will take you less time than one vendor briefing. Treat DNS the way NIST treats it: a useful layer in a broader architecture. Do the boring work. Harden your resolvers, turn on PDNS, pipe the logs into your SIEM, enforce a single egress resolver path, and keep spending your money where the risk actually lives.
To the market
DNS has been ignored for too long. NIST's recognition is earned. The DNS security vendors have real work to do on the internet, and they deserve a share of the budget and the attention that have passed them by for two decades. What none of them deserve is a free pass to inflate the case.
NIST is right. DNS deserves the investment. Most of the vendors aren't telling the story honestly. Don't confuse the three.