In an industry flooded with flashy threat vectors—ransomware, zero-days, supply chain attacks—one of the most foundational parts of internet infrastructure remains dangerously neglected: DNS.
Despite powering every digital interaction, DNS configuration hygiene has long been treated like plumbing—out of sight, out of mind. But in a recent conversation with TFiR, Patrick Sullivan, CTO of Security Strategy at Akamai, made the case that DNS deserves much more scrutiny.
“DNS is often forgotten because it works. But when it fails, it’s catastrophic,” said Sullivan. “And attackers know this.”
Akamai’s answer is DNS Posture Management, a newly launched, agentless platform designed to give enterprises comprehensive visibility into their DNS infrastructure—spanning cloud providers, registrars, and SaaS services—while proactively flagging risks like misconfigurations, dangling CNAMEs, expired certs, and DNS-based compliance violations.
From Misconfigurations to Exploits: The Risk Landscape
DNS attacks aren’t hypothetical. In the past year alone, Akamai has tracked real-world campaigns where adversaries began their intrusion path by exploiting stale or misconfigured DNS entries.
One notable case? A financial institution with a single-character typo in a DNS record, which unknowingly routed sensitive traffic to a domain controlled by an external researcher. In another example, a security firm left behind a valid pointer to a deprecated application, which a bug bounty hunter successfully exploited—demonstrating just how easy it is for threat actors to hijack DNS-based trust.
Sullivan explained the mechanics: “Attackers love dangling CNAMEs or expired DNS entries. If a domain or subdomain is still pointing to an unused or unregistered target, it’s trivial to take control and intercept email, API calls, or SaaS validations.”
These issues are compounded by DNS sprawl—across departments, acquisitions, and cloud environments—and by the fact that DNS rarely has centralized ownership in large enterprises.
What DNS Posture Management Actually Does
Akamai’s solution performs continuous, agentless scans across all DNS configurations tied to an enterprise—regardless of DNS provider or hosting environment. By connecting via APIs or identity groups (depending on provider), the system gains read-only access to DNS zones and records, analyzing them for known security hygiene failures.
“We’re doing what Cloud Security Posture Management does for IaaS,” said Sullivan. “But we’re applying it to DNS, which until now has largely been invisible to these audits.”
The platform flags:
- Dangling CNAMEs
- Lame delegations
- Registry-level misconfigurations
- Weak, expired, or unapproved TLS certificates
- Leaky TXT records (e.g., exposed API keys)
- Noncompliant DMARC/DKIM/SPF email records
It also maps all DNS configs to compliance frameworks like HIPAA, PCI-DSS, and NIST, generating remediation checklists and allowing teams to not only pass audits—but actually align with security intent.
“We’ve seen DNS records carrying more compliance weight than people realize,” Sullivan said. “Take PCI—email security is now tied to DNS via DMARC and DKIM, and misconfigured records can flag merchants.”
Designed for Scale, Not Agent Fatigue
Akamai built the platform to be agentless and multi-cloud—critical for teams already drowning in tool fatigue. Whether DNS is hosted at a traditional registrar, a CDN, a SaaS provider, or a hyperscaler, the tool integrates without requiring endpoint deployment.
This model also supports distributed governance with centralized policy enforcement—ideal for orgs that have DNS managed by disparate teams, M&A units, or even outsourced IT.
Bridging the Skills Gap with Optional Managed Services
Sullivan acknowledges that DNS is often misunderstood or under-resourced—even by security teams. “The reality is teams are seeing more alerts than they can fix in a day,” he said. “So we offer a managed layer where Akamai engineers co-manage DNS risk, assist with remediation, and help customers make changes safely.”
This service builds on Akamai’s broader managed security operations—where customers can also rely on Akamai for application security, DDoS mitigation, and config hardening.
Deployment Speed and Visibility Gains
Initial deployment is fast. Sullivan says most customers start seeing results within 10 minutes of connecting a DNS provider. Over time, internal DNS records (often harder to access) can be integrated in phase two of a rollout plan.
Once live, the system continuously monitors DNS posture and hooks into existing SOC or SIEM workflows—ensuring risks don’t go unnoticed even if DNS entries silently fail in the background.
“DNS is designed for resilience, so failures can be masked by fallback records,” said Sullivan. “We’ve seen misconfigs sit undetected for years—until someone finally registers the domain and breaks everything.”
Final Thoughts: DNS as a Threat Surface
If you’re not tracking DNS like you do cloud assets or endpoints, you’re flying blind. And attackers are betting on that.
Akamai’s DNS Posture Management gives security and operations teams a rare thing: full-spectrum DNS visibility, mapped to real threats and tied to compliance controls. For organizations with sprawling cloud and SaaS estates, it could be the missing layer of defense.
“We’re not just surfacing issues—we’re helping teams fix them, fast,” Sullivan concluded.
Interview Transcript
Swapnil Bhartiya: DNS is one of the oldest building blocks of the internet, and ironically, is still one of the most overlooked when it comes to enterprise security and compliance. But misconfigurations, expired records, and blind spots across multi-cloud environments can expose critical services to outages, spoofing, and regulatory risks. Today, I’m joined by Patrick Sullivan – CTO, Security Strategy, Akamai – to talk about a major new launch: Akamai DNS Posture Management. It is a first-of-its-kind solution designed to help enterprises gain visibility, tighten control, and stay compliant across all DNS assets without adding agent sprawl or complexity. Patrick, it’s good to have you back on the show.
Patrick Sullivan: It’s great to be back. DNS is often treated like plumbing – out of sight, out of mind. You’re right. I think DNS is often sort of a forgotten service, but it’s so fundamental to everything we do. I think it’s forgotten because most of the time it works, right? And when it works, it’s invisible. But I think there’s actually a famous haiku – I think the only one I know of in IT – which basically says, you know, “It’s not DNS. It can’t be DNS. It was DNS,” right? When you see massive events on the internet, invariably, DNS plays a role. If there’s a big outage, that’s the most likely culprit that we see. So not only is there a lot of dependency on DNS from an availability perspective, but also other elements of security, I think, are closely intertwined with DNS, right? If DNS isn’t quite right, a lot of risk emerges, and that’s a pattern that we’ve seen over many, many years.
Swapnil Bhartiya: We know misconfigurations and expired DNS records can lead to serious threats like spoofing or even downtime. Can you talk about what exactly is DNS posture management, and how it helps teams?
Patrick Sullivan: Really, if we think about DNS posture management, it’s really about helping enterprises understand risk that could emerge primarily based around DNS misconfiguration before an adversary does, right? And the way I learned, sort of, you know, pen testing coming up is step one in red teaming, or pen testing is Recon – step one-A is DNSRecon, right? That’s typically where you start to fingerprint an organization, understand, you know, various domains and sort of what you’re dealing with from the outside. And so it’s fundamental, from that perspective, that DNS is configured appropriately so that you’re not equipping an adversary, you’re not leaking information, right? You’re not helping somebody understand the inner workings of an internal network that should be kept private.
But the real issues that we see are things where DNS configuration is not up to best practices. So a couple of things that could take place. One could be something like a DNS registry lock is not put in place, right? And I think we’ll talk over our conversation about some really, really kind of impactful attacks that we’re seeing, you know, over the last quarter, where that’s the vector, right? Where somebody commandeers sort of DNS at the registrar level, and then they’re at a very fundamental level of control over the organization, able to manipulate mail and SaaS and many other things.
Other risks that we see are around sort of as we move to a more distributed architecture where you’ve got cloud, you’ve got SaaS, you have third parties. DNS is often the invocation of third-party services. So if we look at Akamai, the vast majority of our customers are integrating with us via DNS, via a redirect, a CNAME, something along those lines. And the classic problem that you run into with any of these delegations is sort of the full lifecycle of an application as app dev teams work with infrastructure. At the beginning of the lifecycle of an app, you know, the DNS records are put in place. They’re configured appropriately. But then sometimes, at the end of that lifecycle, the app dev team would bring an application down, but there are pointers still in place. You know, we call those dangling CNAMEs, or there’s lame delegation. There’s a variety of nomenclature there, but it’s risk, right? Because the residual there is that the organization has a pointer, a valid pointer, out there that somebody could then go register, right? And now an adversary is on the receiving end of potentially a domain that’s valid – an asset that’s valid for your organization, right? So we see those bug bounty teams love those. They go looking for these dangling CNAMEs and try to make a claim there. So that’s one, right?
In other cases, it’s just human misconfiguration. So there was a very high-profile misconfiguration of DNS earlier this year with a world-class security organization at a big financial services company, and they had a DNS entry where they had one letter off, but now they’re pointing their DNS to a domain that was not a well-known domain because of the misspelling, and then a researcher registered that, and now they’re on the receiving end of really important DNS inquiries for financial transactions on the web, for email, for the enterprise that they could intercept – so many things that could go wrong there.
So I would say, at a high level, those are the problems that we try to solve with DNS posture management. The way that we solve those problems is with a vendor, provider-agnostic service that looks at DNS across all of your various authoritative DNS providers, your cloud service providers. Some people have DNS with their registrar and review those configurations on a regular cadence to look for risk emerging and find those things before somebody else would – sort of analogous to the way people look at the configuration hygiene of their cloud configs with cloud security posture management, same thing just looking at DNS.
Swapnil Bhartiya: How does Akamai DNS Posture Management help teams catch and fix those issues proactively?
Patrick Sullivan: So the approach here is sort of a proactive scanning of configurations. So if one of your DNS providers was Akamai, for example – it doesn’t have to be, it could be any other, but we provide a lot of DNS – there will be regular scans against your DNS to look for misconfiguration, and then that would be reported along with very simple instructions for how to go remediate that. You would also get sort of a compliance checklist of, you know, looking at CIS, sort of best practices for the configuration of DNS, how does our current configuration stack up against those benchmarks, overlaid against PCI framework, a HIPAA framework, you name it, NIST, any of the supported frameworks to give you that confidence from a GRC perspective, that you have best practice configurations in place.
Swapnil Bhartiya: The solution is described as both agentless and multi-cloud. Can you explain what that means in real terms and why those features matter for IT and security teams who are managing complex environments?
Patrick Sullivan: I think the multi-cloud and multi-vendor doesn’t have to be the traditional notion of cloud provider. Some of the large DNS providers may not be thought of as clouds, but I think that’s important, because we’ve seen DNS become highly distributed, right? You may have a preferred DNS provider, but perhaps a marketing team, or there’s M&A or just as you leverage a cloud provider, maybe you’re also availing yourself to their DNS services. But these DNS sprawl takes place across all of this infrastructure, and as we’ve seen, that sprawl and complexity can lead to misconfiguration, stale configurations that are in place. So here, what we’re doing is pulling that all in – sort of distributed DNS, but centralized governance – reviewing those configurations from a risk perspective, no matter where they live.
The agentless mechanism with which this is deployed, I think, is helpful for anybody who finds themselves with agent fatigue and sort of not excited about the prospect of yet another agent. You know, typically, the way that we’re able to do this is with an API-level access to the DNS provider. In some cases, you know, with the cloud providers, you join sort of an identity group, but it’s the same type of soft integration to the DNS config for read-only access.
Swapnil Bhartiya: Compliance is top of mind for industries governed by frameworks like HIPAA and PCI DSS. How does this platform help customers not just track compliance, but actually stay audit-ready? Sometimes compliance can be seen just as a check mark, but if you’re using the right tools, right practices, the check mark is there by default.
Patrick Sullivan: In the perfect world, they’re perfectly aligned, but I know sometimes they diverge. So I think the way we look at that is we sort of have a security review where there’s anything that’s a risk that gets called out and fed down a workflow with very, very easy instructions on how to remediate. You know, we talked about a dangling CNAME that may be something that you go revoke that entry, you know, so you don’t have that pointer that’s vulnerable out there. If you’re leaking information, maybe you got a TXT record that has API keys, you know, there’ll be instructions on how to remediate that.
Now, contrasting that with compliance there, it’s more of a high-level view, you know, against the frameworks you mentioned, HIPAA, for example, when we look at the DNS configuration, how is that stack up against HIPAA, or, you know, PCI? I think we now see it’s really kind of more on the overlap between DNS and email, but some of the protocols for email integrity, DMARC, DKIM, you know, PCI is pushing merchants now to have support for those protocols to ensure that recipients of an email can have confidence that there’s integrity there – that was actually sent by the merchant in place. So we look for those things as well, right?
Also, we’re checking the hygiene of certificates. Are they expired? Are they weak? Are they outside of your typical governance? Do we see you typically have a preferred CA, and all of a sudden there’s a cert issued that’s not on one of your preferred CAs, that could be a risk, and then probably the biggest thing from the certificate perspective is reviewing certs for post-quantum sort of resilience there, right? Are the algorithms in place resilient to quantum attacks or not, and then on an ongoing, continuous basis, giving your posture there as well?
Swapnil Bhartiya: Now, the fact is that even with the best tools, teams often struggle with bandwidth or deep DNS expertise. How does Akamai’s optional managed service help organizations operationalize this solution and close skill gaps that they may have?
Patrick Sullivan: So I think for teams that have sort of the available, you know, resources on the DNS team, everything that’s called out is very easy, from a self-service perspective to go remediate. I think one of the trends that we’ve seen for a lot of security teams is they have more alerts or requests – risks that are being called out – than the security team has hours in the day to go remediate. So you know, as part of our existing business, we help customers with application security, right? If there’s a policy update required for a new zero-day, we participate in sort of those configuration level exercises. If there’s an attack – a DDoS – you know, we have a SOC that helps knock down those attacks on behalf of a customer. So we’re extending that in DNS if an organization chooses to have an expert assist them with reducing the risks that we see around DNS or certificates that help would be available to assist and sort of co-manage things.
Swapnil Bhartiya: No matter how much we do, DNS issues can often fly under the radar until something breaks. What kind of visibility does this solution offer that teams did not have before?
Patrick Sullivan: You make a great point. I alluded to one DNS misconfiguration that was called out earlier this year because DNS has built-in sort of resilience – you get multiple responses back. So it was a period of years that this risk existed, because, you know, DNS clients, even though there was a failure to respond from one misconfigured DNS entry, there were several others. So as long as responses came in, it flew sort of under the radar, and it wasn’t until somebody actually registered the misconfigured domain and called out the risk that it was brought to their attention.
So we think that’s the answer. There is to have continuous monitoring, hook into existing, you know, SOC or other, you know, workflow activities, whatever the organization typically uses to understand a risk and go remediate that – plug into the existing workflow is sort of the way that we would go about that. And I alluded to it earlier. You know, some of these risks we’ve talked about are hypothetical, or are, you know, often being the surface or the discussion with bug bounty teams. But we do see these risks, you know, manifest themselves in actual attacks. I think there have been some recent write-ups on attack campaigns, sort of in the southern hemisphere, where the attack path would begin with somebody discovering that an organization doesn’t have good hygiene with DNS at the registrar, making them vulnerable to social engineering.
So sort of step one initial access would be to gain control of DNS at the registrar. At that point, an adversary has a very fundamental level of control over the organization’s applications. And then some of the things that those adversaries are then doing are, you know, creating modifications to mail records, MX records to insert themselves in a mail flow, and, you know, introducing risk. There are other things that they’re able to do – often, SaaS services use a validation in DNS to prove that you’re the valid owner of that organization, and if you control DNS, you can pass those types of challenges that you would get from a SaaS provider. So you know, adversaries have actually worked their way through commandeering SaaS apps. So it’s kind of a lateral movement via DNS to really some devastating ends to organizations.
Swapnil Bhartiya: How quickly can teams expect to see value after deploying this solution? And what’s the typical rollout path for enterprises with legacy DNS systems?
Patrick Sullivan: Yes, so it’s typically we kind of co-manage the first day one. So we often will be on a call synchronously, as somebody, you know, you add a cloud provider or a DNS provider like Akamai, a scan runs, and usually within 10 minutes, we’re starting to see the results of the data being populated. So it’s very easy to start. I think longer term. You know, internal DNS is typically a phase two that’s not quite as easy – getting at that requires a bit more work than public DNS, but that’s often deferred to a subsequent phase. But that’s how we see it. And then from there it’s sort of just like anything else, making sure that the workflow is well integrated into the organization, the SIEM connections, the other workflow connections are in place.
Swapnil Bhartiya: Patrick, thank you so much for joining me and walking us through this. DNS may not always make headlines, but it can save an organization from becoming a headline in the newspaper the next day. Thank you for great insights, and I look forward to chatting with you again.
Patrick Sullivan: Thank you. Thanks for having me.





