In our previous posts about Verisign Informed™, we’ve talked about the importance of high-assurance infrastructure and how it is a critical underpinning for delivering at-time-of-use status information. We recounted some historical perspective on digital certificates that motivates the essential need to use evidence to build trust in internet security deployments, including revocation status which can change after the certificate is issued, and even after it expires. We then introduced an important idea – stale trust – and explained that failing to check for updated status, or relying on old data, results in stale (or absent) evidence, which is the essence of the stale trust problem. We will now discuss how, despite the importance of status to inform trust, browser makers have largely deprecated the Online Certificate Status Protocol (OCSP), one of the only tools available to determine certificate status on a per-certificate basis. While the reasoning behind that decision may be sound, we believe that the solution for certificate status in general lies in improving and modernizing the performance of OCSP, rather than abandoning it.

To illustrate the significance of the stale trust problem, we first need to explore the nature of stale trust in more detail, and how trends have caused the stale trust issue to become a more significant cybersecurity challenge in recent years. Specifically, we will examine how changing perceptions of OCSP contributed to the stale trust problem, leading to changes that impacted the use of certificates to identify and secure communications with web servers and, more importantly, broad assumptions that adversely influenced other use cases. We’ll further consider how these other certificate-powered use cases, including emerging ones, can benefit from OCSP-based status information to support their unique security and operational requirements.

The decision to deprecate OCSP appears to have been driven by a number of legitimate objectives, such as removing uncertainty in browser-to-website connection timing and removing external operational dependencies on the many Certification Authorities (CA) and their individual OCSP services. Shortened overall certificate lifespans have been implemented in an attempt to span the gap left by abandoning OCSP, but this is no substitute for a breach alerting mechanism, particularly in the face of AI-driven compromise and exploitation.

What’s even more important is to understand the difference between the web and other use cases, how compromises could happen, and how security status from a well-operated OCSP infrastructure remains the best defense against the vulnerabilities associated with stale trust.

OCSP saw tremendous growth following its launch in 1999 and through the next 10 years, powered largely by the rising tide of business-to-consumer e-commerce and the burgeoning need for security. During that same time, work was ongoing to understand and improve the use of OCSP, both to improve end-user privacy and to manage the rapidly increasing request volume and the resulting infrastructure costs to operators.

Operators of websites depend on visits and maximizing user activity, many of which take place over very short periods of time (i.e., milliseconds). With such short transactions, protections only last for seconds or milliseconds, so introducing anything up front, like online status checking, which could slow down a visitor, became a tradeoff with the risk that users would become victims of a Man in the Middle (MitM) attack leveraging compromised certificates. OCSP checking and validation at the initiation of a very short website session appear to have become more burdensome, both financially and technically, than beneficial. And, while investment could have delivered speed and reliability, for instance through “stapling,” eliminating OCSP checking delivered an immediate speed benefit, but at the cost of security.

While browsers focused on connection speed, the volume of connections grew dramatically. From 1999 to 2008, OCSP request volumes grew 184 percent year-over-year (see more detail below), and there was no direct cost recovery mechanism to fund scaling of OCSP infrastructure. Certificates were sold based on a fixed annual fee, and OCSP was a bundled cost of doing business with hard-to-estimate usage. But the costs to build and scale a high-performance infrastructure at those growth rates, multiplied by the number of certificate providers, seemed to be insurmountable. Slowly but surely, response times from OCSP responders increased, or failed to deliver a response at all. CAs looked to leverage outside providers to deliver cached responses to reduce costs, but introduced new external spending as a consequence.

All of this led to the period between 2008-2012, when discussion focused on minimizing cost and operational interdependency on status checking in the browser connection process. Without recognition of the foundational importance of status and trust, proposed security status improvements and workarounds were either disregarded or only implemented to minimum standards. Browsers started exhibiting ‘soft fail’ behaviors, where a missing OCSP response was ignored and the connection was allowed to proceed anyway. Thus, not only was stale trust discarded as a technical or security problem to be solved, but the incentive structure also actively worked against solving it.

By volume, this is not a surprising outcome. Consider these figures:

They show us that Web PKI (“website/server certificates”) was the major driver of all certificate validity status checks during OCSP’s first growth period. The next two largest use cases – centering around Microsoft’s Authenticode, and the EAP-TLS authentication mechanism – both grew even faster than Web PKI, but the combined volume was only a quarter of the total.

Then, in 2012, Chrome disabled OCSP by default and instead adopted CRLSets, a partial solution to status checking. Web trust had moved from current, to stale, to absent altogether (in some cases), under the tradeoff given that the absence didn’t matter because the unexamined risk was not perceived to be big enough to make a difference or would be absorbed elsewhere in the system. Moreover, while blocking compromised certificates via CRLSets would protect some browser users, effective interventions for other users and applications would involve additional steps beyond the simplicity of an OCSP response — a point illustrated in a recent incident.

Fast forward to 2023, when the CA/Browser Forum voted to make OCSP optional for Web PKI TLS certificates. By then, all participants who focused specifically on the website use case (not just browser vendors, but CAs, OS vendors, and site operators) had apparently concluded that OCSP was unnecessary. It appeared to be that, without universal Service Level Agreements (SLAs) directly responsive to the needs of the web use case, operational reliance introduced too much interdependency and failed connection risk. OCSP was effectively sidelined for mainstream consumer browser use cases, and it appeared to some as if the industry might stop using certificate revocation status altogether. For those in the web ecosystem, the generalization that “OCSP was done” became the common punchline. Were other OCSP use cases, where trust data was still an integral part of the solution, overlooked in this debate? Stale trust was the inevitable result – since no alternative high-assurance approach was available.

Since 2008, private enterprise use of certificates and OCSP validation for internal applications – including network access, Authenticode, email, VPN authentication, device authentication, and now agentic AI communication – has grown tremendously and may well eclipse publicly visible use as measured by total OCSP status request volume. Agentic AI tools in particular are driving an enormous increase in the creation and management of machine identities, almost all of which are tied to digital certificates which need ongoing status checks to evaluate permissions and contain unanticipated actions.

And while the assessments which led to OCSP’s deprecation for Web PKI use cases were performed with one set of needs and constraints in mind, other use cases, subjected to a similar assessment, have already proven to arrive at a very different conclusion. To this exact point, our previous blog and technical report illustrate the need for trust and the foundational role of security status via OCSP.

At its core, stale trust is not just a security risk, but also a business risk. Failure to validate trust can lead to exfiltration of customer data, compromise of systems, and hijacking of confidential company information.

Nowhere is this more important than in new certificate-powered use cases, working at machine speed and via automation and AI. This new environment forces a revisitation of those assumptions about how big the risk of ignoring trust really is. Industry reports frequently cite agentic AI ‘red team’ tools (designed to find and exploit security vulnerabilities) as being able to successfully compromise systems in under a minute.

The need for trust validation in such circumstances is clear and consistent with overarching Zero Trust principles already being pursued by enterprises across industries and geographies. Making decisions without sufficiently fresh trust data is increasingly dangerous, since old assumptions that vulnerabilities are unlikely to be discovered and exploited no longer hold true.

Stale trust is not new. The decaying confidence that arose from long-validity-period OCSP responses was noted in the early days, and attention faded as the dominant use case – Web PKI certificates – moved away from the protocol. Less visibly, strong adoption of OCSP continued in code signing, authentication, and more recently, digital provenance, and machine and agentic identity applications – anywhere that revalidation of an object or identity is critical for security. In that sense, perhaps OCSP was ahead of its time, where the utility of up-to-date, per-certificate status information was waiting for higher-value use cases to present themselves.

Rather than abandoning OCSP, Verisign Informed builds on its strong foundation, leveraging new approaches to accelerate its performance, maximize its benefit, and re-insert this critical tool in the trust chain. With Verisign Informed, we seek to preserve the interoperability and worldwide standardization that made OCSP so effective, while adding a new layer of performance, and backing it with a high-assurance infrastructure that can meet the volume and demand of modern use cases.

The post Why OCSP Now? A Fresh Take on Certificate Status Checking appeared first on Verisign Blog.

   

Related Stories

• Join Verisign and a Guest Speaker From Forrester for a Webinar Examining the Implications of Stale Trust
• From Verification to Trust: Refreshing the Security Status Quo
• Celebrating Verisign CTO Burt Kaliski’s Lifetime Achievement Award

 

On Nov. 17, 2026, Verisign will host a webinar featuring a guest speaker from Forrester examining the implications of stale trust in detail. The webinar will feature findings from a recent Forrester Consulting study commissioned by Verisign and will include practical steps organizations can take to combat stale trust and dramatically limit exposure windows, advance their Zero Trust objectives, and inform trust at the speed of modern threats.

Register for the webinar here.

The post Join Verisign and a Guest Speaker From Forrester for a Webinar Examining the Implications of Stale Trust appeared first on Verisign Blog.

   

Related Stories

• Why OCSP Now? A Fresh Take on Certificate Status Checking
• From Verification to Trust: Refreshing the Security Status Quo
• Celebrating Verisign CTO Burt Kaliski’s Lifetime Achievement Award

 

Digital signatures, introduced by Whitfield Diffie and Martin E. Hellman in 1976’s “New Directions in Cryptography,” have provided the cornerstone of the internet’s cybersecurity apparatus for decades. Every moment of every day, behind the scenes of nearly every secure online interaction, these signatures enable critical trust decisions made across the globe. As the threat landscape accelerates — with AI and quantum threats challenging the status quo — there is a growing need to focus on current security status when signatures are used, making the transition from verification to trust.

Current security status is what Verisign Informed™ is designed to provide. By delivering real-time checks on the current status of any participating digital certificate, Verisign Informed aims to close the gap between cached validation data that can grow dangerously stale in the hours and days after it was provided versus the current security status of the certificate. For more details about Verisign Informed, check out our blog.

Half a century ago, Diffie and Hellman revolutionized cryptography when they proposed “new types of cryptographic systems, which minimize the need for secure key distribution channels and supply the equivalent of a written signature.”

Prior cryptographic systems had assumed that communicating parties shared a common, secret key. Public-key cryptography, introduced by Diffie and Hellman, suggested instead that complementary cryptographic operations could be “governed by distinct keys” where one could be made public while the other remained private.

In addition to providing a new framework for encryption, this breakthrough “asymmetric” approach also offered a new form of data authentication. One user — and only that one user — could process a message mathematically with a private key, in effect “signing” the message. And another user — any other user — could check that the processing was performed correctly using the public key, thus “verifying” the signature (see Figure 1).

Figure 1. A digital signature scheme includes three operations: (1) Key Pair Generation generates a new public key and private key; (2) Signature Generation generates a signature on a message using the private key; (3) Signature Verification verifies the signature using the corresponding public key.

This “sign and verify” process would provide the “equivalent of a written signature” for the digital era — a digital signature.

The revolutionary value of the digital signature led to tremendous innovation, including in the underlying cryptography which supported it. Diffie and Hellman’s “New Directions in Cryptography” was followed soon after by the RSA algorithm, invented by Ronald L. Rivest, Adi Shamir, and Leonard Adleman. That was further followed by cryptographic techniques based on different mathematical problems including NIST’s Digital Signature Algorithm (DSA), Elliptic Curve DSA (ECDSA), and more recently, two post-quantum algorithms, SLH-DSA and ML-DSA.

Five decades later, digital signatures have become a ubiquitous foundation for verifying the authenticity of data, information, and essentially every World Wide Web transaction.

Though it is hard to overstate the importance of digital signatures as a concept, it is also easy to overestimate the import of a particular digital signature. A digital signature provides evidence that at some time in the past, someone who controlled a specific private key mathematically processed a message with the private key. But who this party may have been — and whether the messages they digitally sign can be trusted — and whether a particular message, even if “true” when it was digitally signed, is still correct — are all questions requiring yet more evidence — and perhaps more digital signatures.

Digital Certificates

Introduced by Loren M. Kohnfelder in his 1978 bachelor’s thesis, a digital certificate is a digitally signed statement by a certification authority (CA) that a named party controls the private key corresponding to a specified public key. (In Kohnfelder’s terminology, the CA is a “public file” and the private key is a “decryption function.”)

As Kohnfelder observed, because the decryption function might be “lost,” i.e., the private key might be compromised, relying parties would benefit from additional evidence about whether a party continued to maintain control of its key — in today’s terms, whether a certificate is still valid.

Kohnfelder suggested three types of additional evidence, each motivated by analogy with “lost credit cards”:

• a list of “lost decryption functions” or “names of certificates to be ignored,” distributed by the public file;
• certificate expiration dates which bound the time period to which the certificate applies, after which a new certificate is needed; and
• an update directly from the public file indicating whether the certificate is still valid, or if not, as Kohnfelder put it, “the associated certificate has been cancelled due to a certificate leak.”

Digital certificates and the first two types of evidence would be standardized a decade later in ITU-T (formerly CCITT) Recommendation X.509. The third type of evidence would later be provided via the Online Certificate Status Protocol (OCSP), published in 1999.

The evidence available to relying parties has varied over the years and by use case. For example, the CA/Browser Forum has adopted a schedule of progressively shorter certificate lifespans and made OCSP optional for web server certificates. And some certificates may not offer security status at all.

Meanwhile, applications involving object security, where the object being protected has a separate lifetime from the public / private key pair protecting it, introduce foundational factors that dictate a different approach.

Consider code signing — an object security application where a device assesses whether to install a software resource based on evidence such as the following:

1. Code signer’s signature on software resource. A statement by the author of the code attesting that the software resource — typically identified by its cryptographic hash — was originated by the author. The implication is the software is safe to install and use. This statement is digitally signed with the code signer’s private key.
2. Code signer’s certificate. A statement by a CA attesting that the code signer — identified by its name and public key — adequately protects its private key and that they are who they say they are. This statement is digitally signed with the CA’s private key.
3. Timestamp. A statement by a timestamping authority (TA) attesting that statements (1) and (2) existed at a given point in time.

Is this enough evidence for the device to trust that the software resource is safe to install and use? As Verisign’s Distinguished Scientist Eric Osterweil explains in a new Verisign Labs Technical Report, “Origin Verification Is Not Enough,” more evidence might be needed.

The Importance of Current Security Status

The TA’s timestamp protects a relying party against a compromise of the code signer’s private key or operational practices that occurs after the timestamp was produced, because it provides evidence that the signature and certificate existed before the compromise.

But what if the compromise occurred before the timestamp was produced — yet this “contrary evidence” did not become known until later? Or if there were later evidence that the CA has issued the certificate to the incorrect party? Are there other relevant pieces of evidence that may have developed or come to light after signing?

Even if the TA checked a Certificate Revocation List (CRL) or OCSP response at the time of its signing to confirm that the certificate was still valid — and even if the TA included this information in the timestamp — the result would be the same, because the evidence of compromise wasn’t yet available.

A device that makes its trust decision based on only the three pieces of evidence from moment of timestamp is relying on old security status — on stale trust.

Current evidence is the driver for high-assurance security decisions. Tenet 7 in NIST’s Zero Trust Architecture includes this principle:

• “The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.”

Accordingly, insights into the “current state” should be used to “improve security posture.”

One of those insights is the current security status of the certificate. In contrast to the security status that might have been available to the TA at the time of its signing, the current security status is the information available to relying parties now. That information includes whether the signer’s private key or operational practices were learned to have been compromised at any time, including before the timestamp, even if the certificate has since expired.

As the technical report explains, the security status can also include other information that may affect a relying party’s decision, such as whether the signer’s public key has been included in another certificate, and whether the certificate’s serial number is indeed unique.

A system aware of all this additional evidence would be better informed to make its trust decision on installing the software — changing the security “status quo.”

Conclusion

Digital signatures have borne the weight of the internet’s cybersecurity apparatus for decades. As the threat landscape accelerates to new levels, the concept of current security status becomes critical in the path from verification to trust.

The technical report “Origin Verification Is Not Enough” provides a more formal treatment of security status and evidence-based trust, starting with the code signing use case.

The post From Verification to Trust: Refreshing the Security Status Quo appeared first on Verisign Blog.

   

Related Stories

• Join Verisign and a Guest Speaker From Forrester for a Webinar Examining the Implications of Stale Trust
• Why OCSP Now? A Fresh Take on Certificate Status Checking
• Celebrating Verisign CTO Burt Kaliski’s Lifetime Achievement Award

 

New technology is accelerating global reliance on digital infrastructure, yet also enabling and surfacing new security threats. Among these is “stale trust,” in which critical trust decisions are made based on out-of-date validation information. Verisign Informed™ addresses this problem by enabling trust decisions to be made using current status information for any digital certificate transaction, reducing online and enterprise risk.

There are two clear trends that together present significant risks to online commerce, privacy, and security. The first is a perennial and increasing reliance on digital services, and this reliance is increasing rapidly with the growing use of AI. We see this increasing reliance in the rapid growth of transactions in the DNS infrastructure we operate. Over the 7-year period 2016-2022, the average number of daily DNS transactions Verisign processed rose by a compound annual growth rate of 9.3 percent; in the 3-year period 2023-2025, the compound rate nearly doubled to 17.3 percent. Our analyses indicate that an increasing segment of this growth is driven by rapid AI deployment.

The second trend is the growth of cyberthreat risks and attacks, which are increasing in frequency and sophistication. The velocity and volume of new zero-day attacks threaten the effectiveness of traditional defense mechanisms and practices, such as patching. Exploit time – defined as the time between a vulnerability being discovered and that vulnerability being exploited – has dropped from hundreds of days to only minutes. Breakout time – defined as the time it takes for an attacker to penetrate beyond a compromised system to other parts of a network – has dropped from days to minutes. AI-created deepfakes fundamentally erode users’ ability to trust what they see, enabling online and other fraud. And, as we’re learning, it must be assumed that with AI, all vulnerabilities will be identified and followed by near-immediate AI-enabled attack chains.

Digital certificate trust foundations – operationally hardened and enhanced to meet the modern threat landscape – can significantly mitigate many of these new risks. Public-key Infrastructure, or PKI, has long been the bedrock for powering security and privacy protections in network protocols, digital credentials, secure documents, images, embedded devices, and much more. It plays a key role in numerous standards and has been well tested. As a result, its supporting features, tools, and extended protocol support have positioned it at the heart of many of our most effective security solutions. Containing and limiting agent behavior, a growing concern, already recognizes the importance of PKI trust tools for verifying, authorizing, and restricting access. With much of this activity occurring machine-to-machine, high-performance and globally available trust services become essential.

Use of PKI to minimize risk is cited frequently in NIST’s Zero Trust (ZT) architecture, which offers risk-reduction principles based on a “never trust, always verify” approach. Understanding trust at the time of transactions – the purpose for which Verisign Informed was designed – is critical in today’s threat landscape. Private PKI, object security and the emergence of agentic AI underline why current trust status information is of paramount importance. An organization’s “mean time to adapt” once a compromise has been detected hinges on their ability to signal that to relying parties, and thereby substantially reduce the risk of further damage.

PKI’s importance also makes it an implicit target for attackers, as un-remediated compromise of credentials can enable systematic and enduring compromise of dependent systems, both within and outside of the observation space of the target. Verisign Informed provides current security status to clients and other relying parties and is also a foundation for providing richer context via the extensible architecture of the Online Certificate Status Protocol (OCSP). This allows security practitioners to quantifiably minimize their “vulnerability windows,” – the periods when compromised credentials can be exploited.

Although these issues are well understood by security professionals, until now, there has been no clear solution. In a March 2026 Forrester Consulting study of IT leaders commissioned by Verisign, 97 percent said that extended digital certificate validation gaps are a risk when making trust decisions in light of identity-based threats, and that reducing digital certificate validation gaps in private PKI is becoming increasingly critical as cyberthreats and agentic AI accelerate the speed and scale of identity-based threats.

These same individuals saw numerous benefits to closing these windows of vulnerability; notably, 84 percent identifying closing validation gaps as key to a stronger Zero Trust posture for their organizations. Rapidly closing these windows is necessary so that compromised credential remediation can occur.

Microsegmentation, the Zero Trust-specified practice of treating networks as isolated segments, each requiring validated credentials authorizing access for clients and workloads, further accelerates the number of validations performed by policy enforcement points.

Verisign Informed delivers highly available, current certificate status information, enabling “at time of use” verification of a certificate’s validity and the trust it underlies. In existing solutions, validity information can be hours – or days – out of date, creating attack windows where a relying party trusts a credential that has already been known compromised and even revoked, but the current status hasn’t been effectively conveyed to relying party applications or services.

Validation at time of trust decision is fundamental for public and private transactions, and critical for establishing trust in current and new uses of the internet. Alongside the introduction of Verisign Informed, Verisign is actively engaged in helping create standards for solving new challenges with trust in the internet. The emerging challenge of AI-created deepfakes is being combatted by the Coalition for Content Provenance and Authenticity (C2PA) and the Creator Assertions Working Group (CAWG), of which Verisign is a participating member, by incorporating and leveraging PKI. In Agentic discovery, capability assessment, trust establishment and secure communications, we have identified certificate-based solutions, including Domain Name System Security Extensions (DNSSEC) and DNS-based Authentication of Named Entities (DANE), and are proposing new certificate validated DNS record types to facilitate optimal Agentic use of the DNS, alongside an evaluation framework for assessment of potential agent discovery approaches.

Verisign Informed builds on Verisign’s significant experience in both high-assurance critical infrastructure and Public-key Infrastructure. Verisign’s two-pronged history is one of deep experience in operating high-assurance critical DNS infrastructure, and pioneering PKI at global scale. We are now leveraging the synergies between these two critical technologies to meet an emergent security challenge.

Verisign Informed is powered and backed by Verisign’s high-assurance infrastructure: We define “high assurance” as a service that can deliver the highest levels of availability, accuracy, and performance, all at global scale. Our secure and resilient global DNS infrastructure has provided over 29 years of uninterrupted, 100% service level availability of our COM/NET resolution services. As AI automates more business processes on which services and revenues depend, reliability takes on new significance.

Today, we are processing more than 746 billion authoritative DNS transactions on average per day (and growing), which equates to approximately 8.6 million transactions per second, every second of every day. We provide cryptographically protected responses globally, with the vast majority answered within milliseconds. Through a variety of methods, we have and will continue to maintain multiple orders of magnitude in reserve capacity. And we will continue to maintain the security and stability of our cryptographic protections for the long term, including through our pioneering leadership in preparing DNSSEC for the post-quantum era.

Our purpose-built infrastructure has continually evolved over decades to serve one purpose: delivering services worldwide with speed, accuracy, and availability. Put simply, we believe that Verisign Informed, operating in our high assurance infrastructure, will significantly strengthen one of today’s most widely used and critically important tools of trust.

Finally, Verisign has applied for the .pki gTLD in the next round of ICANN’s new gTLD program. We see .pki as a potentially useful gTLD within PKI usage scenarios.

Today marks the opening of the limited beta for Verisign Informed. Verisign Informed was developed, tested, and enabled in our infrastructure during late 2025 and early 2026. The initial development and operational testing processes are complete. With the current OCSP standard providing a means for specifying the validation service provider of choice, the provisioning, activation, and transaction flow are nearly identical to domain registration and resolution, delivering the full performance and availability benefits of our high-assurance infrastructure at global scale.

To learn more about Verisign Informed, visit https://www.verisigninformed.com/.
To access the full set of insights gained in the Forrester study, visit the Forrester Opportunity Snapshot.

Accompanying this blog and in additional writings in the coming weeks we will share more details about Verisign Informed, analyses of the threats it addresses, and the importance of high-assurance validation in a series of blogs. Our plan is to make Verisign Informed generally available in the first half of 2027. Verisign Informed is designed to be enabled by PKI services providers, including Registrars who offer enterprise PKI services, or directly by end customers that manage their own PKI, by leveraging the features already built into the OCSP standard.

Verisign Informed, operating within our High-Assurance infrastructure, can provide a stronger foundation of high-security tools on which new services can be deployed with the speed, trust, and reliability required in today’s world of accelerating risks and threats.

The post Introducing Verisign Informed™: A High-Assurance Solution for Validating Trust at the Speed of Modern Threats appeared first on Verisign Blog.

   

Related Stories

• Join Verisign and a Guest Speaker From Forrester for a Webinar Examining the Implications of Stale Trust
• Why OCSP Now? A Fresh Take on Certificate Status Checking
• From Verification to Trust: Refreshing the Security Status Quo

 

This blog post is based on a paper titled “Efficient and Secure Discovery for AI Agents: The Case for DNS,” authored by Ramachandra Rao Seethiraju, Sameer Thakar, Karthik Shyamsunder, and Eric Osterweil. This blog was co-authored by all four authors.

For more than three decades, domain names have served as a foundational identity layer for internet applications. Initially used to identify early network services such as TELNET, FTP, and email, they later became essential to web browsing and a growing range of online services. Their enduring value lies in their ability to provide unique, stable, neutral, and widely recognized identifiers across changing technologies and use cases.

Now, the Domain Name System (DNS) has the potential to serve as a foundational element to certain key aspects of artificial intelligence (AI) discovery, as we discuss in a new Internet Engineering Task Force (IETF) Internet-Draft.

Intersection of the DNS and AI Agent Communication

The internet’s infrastructure and services are beginning to rely on AI, and AI agent deployments are now growing at an unprecedented rate. As they become more prolific across the internet, AI agents are increasingly operating across organizational and technological boundaries. While many AI agents still operate within relatively “closed world” environments, trusted and secure cross-platform interaction is poised to become a foundational challenge.

In this new AI-enabled world, AI agents have some basic operational requirements. They need to discover one another, identify each other’s capabilities, establish trust, authenticate their endpoints, and exchange information securely across heterogeneous environments. At the internet’s scale, these requirements introduce important challenges around discoverability, interoperability, integrity, and transaction efficiency. This frames large design and deployment challenges.

Fortunately, the DNS already provides a globally deployed and proven naming and resolution infrastructure for the internet that is well suited to these challenges. Combined with DNSSEC and DNS-based Authentication of Named Entities (DANE), the DNS also provides mechanisms for integrity protections, authenticated associations, and trust establishment. These characteristics become more relevant as AI agents continue expanding beyond platform-specific ecosystems.

Phases of AI Agent Communication

Foundationally, AI agent communication can be deconstructed into two logical phases: AI agent discovery and runtime interaction. We’ve developed an evaluation framework to propose a basic set of metadata that may be necessary and sufficient for conducting AI agent discovery. Our results indicate that this metadata set fits well within practical DNS operational limits under common deployment conditions. This enables the initial discovery and bootstrapping using existing DNS transaction models and infrastructure already deployed at internet scale. Our research shows that the “necessary and sufficient” metadata set consists of a protocol identifier, coarse-grained capabilities, a service endpoint, and identity verification. As agentic AI continues to mature, additional sets of runtime metadata may continue to evolve, but the set we have identified will likely remain necessary and sufficient for discovery.

Binding AI Agent Metadata to Domain Names

Building off our research, our recent IETF Internet-Draft DNS-Based Agent Naming (DAN): AIDISCA and AIINDEX Resource Records for AI Agent Discovery structures agentic AI discovery as a use case for DANE associations – i.e., in a similar fashion to the way DANE enables authenticated associations for Transport Layer Security (TLS). This protocol is designed to enable AI agents to locate and connect to each other using necessary metadata and secure DNS associations. It proposes two new DNS Resource Record (RR) types:

• AIDISCA, a DANE-like domain name-to-AI agent association record, and
• AIINDEX, a DNS-based discovery mechanism for enumerating AI agent publication points within a domain name.

AIDISCA provides an atomic representation of the metadata necessary to establish connectivity with an AI agent, including protocol identifiers, capabilities, service endpoints, and certificate associations. Correlating this interoperable bootstrap metadata directly with domain names reduces external dependencies and minimizes additional resolution steps during discovery.

AIINDEX enables domain-scoped discovery of AI agent publication points without requiring extensive DNS crawling or other discovery systems.

Together, these mechanisms allow AI agents to retrieve authoritative metadata through a minimal number of DNS transactions, reducing lookup overhead, improving consistency, and enabling low-latency interaction establishment across organizational and platform boundaries.

Binding agent metadata to domain names provides organizations an opportunity to leverage the trust they have built over the years with their domain names.

Publication of Royalty-Free Licensing Terms

We have already started working with the community on extending existing internet naming and trust infrastructure toward AI agent discovery, and we will continue to socialize, gather feedback, and fine-tune the various proposals, including these new DNS resource record types. Additionally, as part of this work, we announced a royalty-free public license to support standardization of DAN (see the DAN Internet-Draft IPR declarations for the official language).

We are encouraged by these timely efforts toward scalable, interoperable, and authoritative interaction across organizational and technological boundaries.

The post Proposed New DNS Resource Record Types for AI Agent Discovery appeared first on Verisign Blog.

   

Related Stories

• The 2024-2026 Root Zone KSK Rollover: Updates and Observations
• Preparing DNSSEC for the Post-Quantum Era
• Celebrating Verisign CTO Burt Kaliski’s Lifetime Achievement Award

 

This blog post is co-authored by Duane Wessels (Verisign) and Roy Arends (ICANN).

Roughly a year and a half ago, Verisign and the Internet Corporation for Assigned Names and Numbers (ICANN) began the important, multi-year process of updating the cryptographic key that secures the authoritative Domain Name System (DNS) root zone. This work has been largely invisible to the public, but vital to the security of many everyday online activities.

As we near the end of the deployment of this new key – called KSK-2024, scheduled for completion in October 2026 – we’d like to review what we’ve learned and share our observations. This blog post, paired with our first blog post on the topic from March 2025, paints a complete picture of a process that has gone smoothly and predictably.

DNSSEC and the Root Zone

The Domain Name System Security Extensions (DNSSEC) are an increasingly important component of internet security. DNSSEC forms the secure basis for several aspects of online interactions, including authenticating destination addresses, securing email transactions, validating domain name relationships, and more.

The DNS root zone was originally signed with DNSSEC in 2010, and the root zone Key Signing Key (KSK) was first updated (or “rolled over”) in 2018. Now, in 2026, we’re about to update the root zone KSK again.

The 2017-2018 KSK Rollover

The first root zone KSK rollover was originally scheduled to take place in October 2017. In the months leading up to the rollover, we began to collect and observe data from a recently developed feature known as trust anchor signals, described in RFC 8145. These signals, from a relatively small population of DNS clients, were “noisy”: they frequently contained what seemed to be false negatives, in that some resolvers signaled use of trust anchor keys that were never deployed for the root zone, and others were contradictory, sometimes indicating possession of the new KSK and at other times only the old KSK, which might happen if multiple DNS resolver clients share a single IP address.

Out of an abundance of caution, the KSK rollover was postponed for one year in order to analyze our findings and determine how to resolve the issues we were seeing. While this gave operators time to re-examine their configurations, it also gave us time to reach out to software developers who neglected to update the KSK in their software codebase, and to resolver operators who also apparently were not yet using the new KSK.

The rollover successfully took place one year later, in October 2018.

Lessons Learned

The outcomes of the 2018 KSK rollover are described and discussed in ICANN’s “Review of the 2018 DNSSEC KSK Rollover” report and the peer-reviewed paper “Roll, Roll, Roll your Root,” both published in 2019.

While there were a few disruptions that could have been prevented had organizations been better prepared and their systems properly configured, there was nothing to indicate that the proper mechanisms malfunctioned. With this in mind, we’re looking towards execution of the current KSK rollover in 2026.

The original plan was to roll the KSK on a three-year cycle. However, the COVID-19 pandemic disrupted operations in 2021, when in-person key signing ceremonies had to be replaced with remote attendance. It wasn’t until 2022 that we could resume normal, in-person ceremonies.

In 2023, a new KSK was generated but had to be retired when the Hardware Security Modules (HSMs), used to protect the key material, had reached end-of-support. That meant a key generated at that point would outlive the supported lifetime of the hardware. To address this, the operation transitioned to new HSMs from a different vendor, after which the current KSK, KSK-2024, was generated.

The Current KSK Rollover

The KSK rollover currently underway began back in 2024. The new KSK was generated and then replicated at key signing ceremonies mid-year. In January 2025, the new KSK’s public component was first published in the root zone.

Through the process documented in RFC 5011, most internet resolvers will notice the new KSK and start a “virtual timer” of sorts. If the resolver observes – and can validate – the new KSK for a period of 30 days, it can be added to the local set of trusted keys. This behavior is something we can track via the RFC 8145 trust anchor signals, which are transmitted to the root name servers. The graph below indicates the percentage of signal-sending resolvers that are using the current key (KSK-2017) and the new key (KSK-2024), as well as the old key (KSK-2010).

The sharp increase in KSK-2024 signals in February 2025 reflects the RFC 5011 process: 30 days after publication, the majority of resolvers had added the new key to their trust store.

Essentially 100% of sources indicate they’re using KSK-2017. Without it, DNSSEC validation on the internet would fail today. About 3.5% still retain KSK-2010, created in 2010 and revoked in 2019.

Comparing the two rollovers reveals a striking consistency. Aligning the datasets to a common starting point, when each KSK was first published in the root zone, shows nearly identical adoption curves.

The similarities are notable, except for the anomalous dip in KSK-2017 signals, which eventually recovered to previous levels (remember that the population of signaling resolvers was much smaller in 2018 than it is today). Both rollovers show very similar trends leading up to and immediately following KSK pre-publication. After some 500 days, both rollovers show adoption of the incoming key above 95%.

Next Steps: Ensure You’re Prepared

On Oct. 11, 2026, the root zone will begin publishing DNSKEY RRsets signed exclusively by KSK-2024. Any DNSSEC-validating resolver that has not yet added KSK-2024 to its trust anchor set will experience DNS resolution failures from that date.

Most resolvers running current software have been shipped with KSK-2024 or will have picked up KSK-2024 automatically via RFC 5011. However, system administrators should verify this now: the correct key has a keytag of 38696. The table below shows where to find trust anchor configuration files for common resolver software.

If KSK-2024 is not present, administrators will want to check whether automatic trust anchor updates are enabled and whether the resolver process has “write” access to the key storage directory.

Wrapping Up

As we near the end of the current rollover process, we take stock of the lessons we’ve learned – during this rollover and the previous one – and consider them invaluable guidance as we move forward. Verisign and ICANN will continue to work together to maintain the security, stability, and resiliency of the DNS, with an eye toward upholding operational excellence and high-assurance services and infrastructure.

The post The 2024-2026 Root Zone KSK Rollover: Updates and Observations appeared first on Verisign Blog.

   

Related Stories

• The 2024-2026 Root Zone KSK Rollover: Initial Observations and Early Trends

 

Today, the latest issue of The Domain Name Industry Brief Quarterly Report was released by DNIB.com, showing the second quarter of 2026 closed with 401.6 million domain name registrations across all top-level domains (TLDs), an increase of 9.1 million domain name registrations, or 2.3% compared to the first quarter of 2026. Domain name registrations increased by 29.9 million, or 8.1%, year over year.

Check out the latest issue of The Domain Name Industry Brief Quarterly Report to see domain name stats from the second quarter of 2026, including:

• Top 10 largest TLDs by number of reported domain names, with quarterly renewal percentages when available
• Top 10 largest ccTLDs by number of reported domain names, with quarterly renewal percentages when available
• Top 10 largest gTLDs by number of reported domain names, with quarterly renewal percentages and other key statistics

DNIB.com and The Domain Name Industry Brief Quarterly Report are sponsored by Verisign. To see past issues of the quarterly report, interactive dashboards and learn about DNIB.com’s statistical methodology, please visit DNIB.com.

The post Domain Name Industry Brief Quarterly Report: DNIB.com Announces 401.6 Million Domain Name Registrations in the Second Quarter of 2026 appeared first on Verisign Blog.

   

Related Stories

• Domain Name Industry Brief Quarterly Report: DNIB.com Announces 371.7 Million Domain Name Registrations in the Second Quarter of 2025
• Domain Name Industry Brief Quarterly Report: DNIB.com Announces 362.4 Million Domain Name Registrations in the Second Quarter of 2024
• Domain Name Industry Brief Quarterly Report: DNIB.com announces 356.6 Million Domain Name Registrations in the Second Quarter of 2023

 

Today, the latest issue of The Domain Name Industry Brief Quarterly Report was released by DNIB.com, showing the first quarter of 2026 closed with 392.5 million domain name registrations across all top-level domains (TLDs), an increase of 5.6 million domain name registrations, or 1.4% compared to the fourth quarter of 2025. Domain name registrations increased by 24.1 million, or 6.5%, year over year.

Check out the latest issue of The Domain Name Industry Brief Quarterly Report to see domain name stats from the first quarter of 2026, including:

• Top 10 largest TLDs by number of reported domain names, with quarterly renewal percentages when available
• Top 10 largest ccTLDs by number of reported domain names, with quarterly renewal percentages when available
• Top 10 largest gTLDs by number of reported domain names, with quarterly renewal percentages and other key statistics

DNIB.com and The Domain Name Industry Brief Quarterly Report are sponsored by Verisign. To see past issues of the quarterly report, interactive dashboards and learn about DNIB.com’s statistical methodology, please visit DNIB.com.

The post Domain Name Industry Brief Quarterly Report: DNIB.com Announces 392.5 Million Domain Name Registrations in the First Quarter of 2026 appeared first on Verisign Blog.

   

Related Stories

• Domain Name Industry Brief Quarterly Report: DNIB.com Announces 368.4 Million Domain Name Registrations in the First Quarter of 2025
• Domain Name Industry Brief Quarterly Report: DNIB.com Announces 362.4 Million Domain Name Registrations in the First Quarter of 2024

 

Today, the latest issue of The Domain Name Industry Brief Quarterly Report was released by DNIB.com, showing the fourth quarter of 2025 closed with 386.9 million domain name registrations across all top-level domains (TLDs), an increase of 8.4 million domain name registrations, or 2.2% compared to the third quarter of 2025. Domain name registrations increased by 22.7 million, or 6.2%, year over year.

Check out the latest issue of The Domain Name Industry Brief Quarterly Report to see domain name stats from the fourth quarter of 2025, including:

• Top 10 largest TLDs by number of reported domain names, with quarterly renewal percentages when available
• Top 10 largest ccTLDs by number of reported domain names, with quarterly renewal percentages when available
• Top 10 largest gTLDs by number of reported domain names, with quarterly renewal percentages and other key statistics

DNIB.com and The Domain Name Industry Brief Quarterly Report are sponsored by Verisign. To see past issues of the quarterly report, interactive dashboards and learn about DNIB.com’s statistical methodology, please visit DNIB.com.

The post Domain Name Industry Brief Quarterly Report: DNIB.com Announces 386.9 Million Domain Name Registrations in the Fourth Quarter of 2025 appeared first on Verisign Blog.

   

Related Stories

• Domain Name Industry Brief Quarterly Report: DNIB.com Announces 401.6 Million Domain Name Registrations in the Second Quarter of 2026
• Domain Name Industry Brief Quarterly Report: DNIB.com Announces 392.5 Million Domain Name Registrations in the First Quarter of 2026
• Domain Name Industry Brief Quarterly Report: DNIB.Com Announces 378.5 Million Domain Name Registrations in the Third Quarter Of 2025

 

In October, stock “short sellers” – investors who bet on the likelihood that stocks will decline in value – published misleading and inaccurate reports about “parked” .com domain names and how those domain names would be affected by ongoing changes to Google AdSense. We believe that the short sellers hoped to profit by declines in our stock price due to the false information they published. While we explained the inaccuracy of these reports at the time of their publication based on historical data, we now have a growing body of publicly available data that empirically refutes the short sellers’ predictions.

Before we review the data, let’s recall what the short sellers said. One of the most dramatic predictions was that 30 percent of the .com domain name base was “at risk of churning” in the next 12 months, as a result of Google AdSense changes. For perspective, 30 percent would equate to “churn” of about 48 million .com domain names. As we noted in October, parked domain names for which the registrant is primarily attempting to monetize traffic with website advertising represent less than two percent of the .com domain name base (as opposed to the 30 percent imagined by short sellers), a percentage that has been declining for more than a decade when Google AdSense changes first began, even as the .com domain name base has steadily grown.

We can now compare publicly available zone data to the short seller predictions. If there existed a “Short Sellers’ Cohort” of about 48 million domain names deleting between late September 2025 – when monetization platforms reported significant impact from the latest Google AdSense changes – and September 2026, we’d expect the .com zone to lose 131,506 domain names per day, above and beyond normal fluctuations we see with the registration and deletion of domain names.

Most domain names have one-year registration terms, which means that since Oct. 1, 2025, nearly a quarter of all .com domain names have reached the end of their terms and were either renewed or deleted, so if the Google AdSense changes represented, as short sellers suggested – a precipitating event for the deletion of a massive number of domain names – we’d expect those deletions to begin right away. We know these Google AdSense changes caused turmoil in recent months among the small group of companies that depended on Google AdSense revenue for parked domain names, so if they were going to impact the .com domain name base significantly, as short sellers predicted, we would expect the effects to be visible right away, and certainly within three months.

Does the zone data reveal evidence of this massive negative impact to the COM zone? No.

The following charts reflect an analysis of publicly available data from ICANN’s Centralized Zone Data Service (CZDS):

COM Zone Changes 7-Day Average¹

The chart shows a seven-day rolling average for COM zone data for the past 12 months. The flat line in the graph shows the average number of zone deletions for the year, and the vertical line notes the time in September when the latest Google AdSense impacts were reported. The data does not show any incremental increase in the number of deletions. Based on this data alone, the Short Sellers’ Cohort of about 48 million “churn” domain names simply cannot exist.

In addition to the zone data, each month ICANN publishes registration and deletion data for all gTLDs including .com, 90-days after it is received. While the September data won’t be publicly available until next month, it should mirror what we are seeing in the publicly available zone data, which is to say, the non-existence of a Short Sellers’ Cohort of about 48 million “at risk” .com domain names.

The clarity of this publicly available data refutes the short sellers’ flawed thesis they propagated in October. We hope that when stakeholders read reports by short sellers, they do so with a clear understanding of the financial motivations that can influence their predictions, and a clear memory of their flawed analysis of the impact on .com from the Google AdSense changes.

1. The rate of .com domain name turnover remains largely steady over time, consistent with a renewal rate that has been between 73%-75% since 2017. Renewal rates for first-time domain name registrations are lower than those for domain names that have been renewed more than once, contributing to relatively minor variations in that range over time. ↩︎

The post Data Refutes Short Sellers’ Flawed Reports About Negative Impacts on .Com Domain Name Base appeared first on Verisign Blog.

   

Related Stories

• Domain Name Industry Brief Quarterly Report: DNIB.com Announces 401.6 Million Domain Name Registrations in the Second Quarter of 2026
• Domain Name Industry Brief Quarterly Report: DNIB.com Announces 392.5 Million Domain Name Registrations in the First Quarter of 2026
• Domain Name Industry Brief Quarterly Report: DNIB.com Announces 386.9 Million Domain Name Registrations in the Fourth Quarter of 2025