Post-Quantum Cryptography Is Coming, but Your DNS Might Not Be Ready

• Post-quantum cryptography (PQC) introduces significantly larger signature sizes (e.g., ML-DSA), which break the DNS assumption that responses fit within a single UDP packet, forcing frequent fallbacks to TCP.
• Because “Harvest now, decrypt later” attacks are currently underway, adversaries are actively collecting encrypted DNS records to decrypt and exploit once quantum technology matures.
• The rise of machine-to-machine agentic AI workflows — which generate rapid, high-volume DNS queries — amplifies the risk, as TCP latency spikes and silent validation time-outs can cascade and break automated business logic.
• Achieving true “crypto-agility” requires overcoming fragmented multicloud infrastructure and DNS sprawl. The primary hurdle to PQC readiness is the lack of a clear, unified view of the distributed cloud environment.
• Organizations must transition from asking if they are ready for PQC to actively mapping their existing DNS configurations, third-party dependencies, and cryptographic exposures using tools like Akamai DNS Posture Management.

Post-quantum cryptography (PQC) is usually framed as a cryptographic transition: swap RSA and ECC cryptography algorithms for quantum-resistant alternatives and complete the migration. That framing makes the challenge feel manageable. But PQC doesn't just change how we encrypt data. It changes how the internet behaves — and the infrastructure underneath it wasn't built for what's coming.

Consider key sizes. Today, an Elliptic Curve Digital Signature Algorithm (ECDSA) signature is approximately 64 bytes. The new NIST-standardized replacement, ML-DSA, produces signatures between 2,400 and 4,600 bytes. That's not a minor increase; it represents a fundamental structural transformation. 

DNS was designed around the assumption that responses fit inside a single UDP packet. PQC breaks that assumption by default, forcing responses to fragment or fall back to TCP across infrastructure that has operated the same way for decades. DNSSEC, the system that adds cryptographic trust to DNS itself, is particularly exposed. What is currently an edge case becomes the norm.

This is what a cryptographic transition looks like when it meets the real internet.

There is a temptation to treat PQC as a future problem, something to monitor, plan for, and eventually act on. That framing is increasingly hard to justify.

“Harvest now, decrypt later” attacks are already underway. Adversaries are collecting encrypted DNS records today with the intent to decrypt them once quantum capabilities mature. For DNS specifically, that harvested data is valuable well beyond individual transactions. DNS queries reveal application use patterns, internal architecture, and organizational dependencies. 

Adversaries who can eventually forge DNSSEC signatures don't need to attack your infrastructure directly. They can redirect traffic at scale in ways that are currently cryptographically impossible, and do so in a way that passes validation.

The risk isn't contingent on quantum computers arriving. The data being collected now carries that risk forward, and the clock is already running.

The PQC pressure on DNS isn't just coming from human users. It's coming from machines, too, and they're far less patient.

The shift from human-centric search and browsing to agentic machine-to-machine interaction is already underway. AI agents don't wait for a page to load or retry a failed request the way a user might. They operate on tight time frames, executing chains of dependent API calls across distributed cloud environments — spanning global hyperscalers and regional cloud provider networks — often with no human in the loop to absorb or recover from a failure. 

Every one of those calls begins with a DNS lookup. At scale, AI agents will generate orders of magnitude more DNS queries than the human workflows they replace — and they will generate them faster, in tighter windows, with less tolerance for delay.

This is where PQC introduces a new category of operational risk that goes beyond cryptographic correctness.

When PQC-standard encryption forces a DNSSEC response to exceed a UDP packet boundary, the connection falls back to TCP. For a human who is browsing a website, that fallback is invisible. For an AI agent in the middle of a task — e.g., orchestrating a sequence of service calls across a distributed cloud architecture and executing business logic that depends on each step completing within a defined time-out — that latency spike can be enough to break the chain. 

A DNSSEC misconfiguration that causes a validation failure doesn't generate an error message for the user. It produces a silent time-out that cascades through dependent systems, failing workflows in ways that can be difficult to trace back to their root cause.

The same DNS infrastructure that carries the cryptographic weight of PQC will also carry the operational weight of agentic AI. These two transitions are arriving simultaneously. Organizations that treat DNS as a background concern — something that simply works — are building their agentic future on a foundation that they haven't examined. 

Any gap in DNS visibility, any orphaned record, any inconsistent DNSSEC configuration, becomes a potential point of failure that autonomous systems will reliably find and that human operators may not immediately recognize as a DNS problem at all.

Getting DNS right for PQC isn't just about cryptographic hygiene. It's about making sure the infrastructure that agentic AI depends on across distributed cloud environments can actually support what it's being asked to do.

This is where most PQC conversations stop short. The focus tends to land on algorithm selection: which standards to adopt, which time lines to follow. But the ability to swap cryptographic algorithms without rebuilding infrastructure — what practitioners call crypto-agility — depends on something more fundamental. It depends on understanding and maintaining the environment those algorithms are deployed into.

Many organizations will begin their PQC migration by carrying years of accumulated DNS sprawl, including orphaned records, dangling CNAMEs pointing to decommissioned resources, and abandoned subdomains. These don't just create isolated security risks. They make a complex migration significantly more dangerous. 

An attacker who can hijack a trusted subdomain during a period of major cryptographic change doesn't need to break the new algorithm; they only need to exploit the gaps left behind by the old infrastructure.

A poorly maintained DNS estate is not crypto-agile, regardless of which PQC algorithms it eventually adopts. That's the problem most organizations haven't fully reckoned with yet.

Before organizations can ask how to migrate to PQC, most need to answer a more basic question: “Where is cryptography actually being used across our DNS?”

Without that answer, it's difficult to: 

• Identify which domains rely on vulnerable RSA or ECDSA-based DNSSEC signatures 
• Understand where DNSSEC is deployed or misconfigured
• Map dependencies on external providers
• Predict how larger PQC signatures will affect performance and resilience across a specific environment

DNS visibility is already fragmented by design. Organizations operating across distributed cloud infrastructure — running workloads and DNS zones across AWS, Azure, Google Cloud, and third-party DNS providers — often have no unified view of where legacy algorithms remain in use. Domains carrying vulnerable signatures may be scattered across dozens of providers, with no single team owning the full picture. 

Adding a cryptographic migration on top of that distributed cloud fragmentation, without first addressing it, doesn't just complicate the transition. It makes a high-pressure migration more likely to surface problems at the worst possible moment.

The biggest barrier to PQC readiness isn't the technology. It's the absence of a clear, unified view of the distributed cloud environment.

The instinct in security is to focus on the end state: quantum-safe algorithms, updated protocols, full migration. In practice, large-scale infrastructure changes rarely start there.

Instead of “Are we ready for post-quantum cryptography?” the more useful question is “Do we understand how PQC will impact our DNS infrastructure?”

That means: 

• Discovering whether your DNS can handle the operational shift to larger signature sizes and more frequent TCP fallbacks
• Understanding which configurations are inconsistent or exposed
• Mapping your third-party dependencies across your distributed cloud estate before the migration forces you to discover them under pressure
• Building the kind of crypto-agility that comes from a well-understood, well-maintained environment — not just from adopting the right PQC standards

The organizations that navigate this transition successfully won't simply be the ones that moved to new algorithms first. They'll be the ones that understood how those changes would ripple across their entire distributed cloud environment — including their agentic workloads — before they started making them.

For most organizations, PQC readiness begins not with replacing algorithms, but with building a clear picture of: 

• How DNS is configured today across the full distributed cloud estate 
• Which assets carry cryptographic exposure 
• Where DNSSEC is deployed, misconfigured, or absent 
• How services and dependencies interact across a complex, multiprovider environment

Akamai DNS Posture Management is built for exactly this starting point. It provides a unified view of DNS configurations and cryptographic exposure across your entire distributed cloud environment, including agentless discovery to identify which assets remain vulnerable to quantum threats and which are already moving toward quantum-safe standards. 

For security teams managing the operational complexity of a PQC migration — and the agentic workloads that depend on reliable DNS resolution — that visibility isn't a nice-to-have. It's what everything else depends on, including the crypto-agility that will determine how smoothly the transition goes when it arrives.

Contact your Akamai representative to see how DNS Posture Management can help your organization take the first step with confidence.