Over the past several weeks, there has been significant discussion about Verisign and its management of the .com top-level domain (TLD) registry. Much of this discussion has been distorted by factual inaccuracies, a misunderstanding of core technical concepts, and misinterpretations regarding pricing, competition, and market dynamics in the domain name industry.

Billions of internet users and trillions of dollars in global commerce rely on the continuing security, stability, and resiliency of the .com TLD and the technical infrastructure that powers it, so it is vital that discussions about this topic be rooted in fact.

To set the record straight, we have collected and addressed the most common myths currently circulating about the .com TLD.

Myths vs. Facts about .com

Myth: The technology that powers the .com TLD is not sophisticated.

Fact: Verisign has invested continuously for decades to build and evolve the infrastructure that powers the .com TLD, which is the most technically sophisticated of its kind. This infrastructure includes an advanced registration system, which reliably updates and maintains an accurate record of all registered .com domain names on a continuous basis, ensuring that millions of registry transactions are processed correctly, and millions of daily changes – including cryptographic updates to support Domain Name System Security Extensions (DNSSEC) – are distributed to a highly resilient global resolution constellation within seconds. This system ensures that users around the world maintain continuous, round-the-clock access to .com domain names and all the resources and services they support. Verisign has also played a vital role in the development and deployment of DNSSEC technology which uses cryptographic protections to ensure those connections are delivered with reliability and trust.

Verisign’s infrastructure processes an average of 329 billion Domain Name System (DNS) transactions each day, operating at a peak of more than six million transactions per second so far this year. Verisign’s resolution infrastructure is engineered to handle peak query loads significantly greater than the highest ever observed, to ensure continuous operation regardless of demand. This infrastructure has delivered 100 percent DNS availability for .com for more than 27 years without interruption. Verisign accomplishes this by operating a large, globally distributed registry operation, made up of hundreds of technical sites spread across 60+ nations on six continents. These sites run purpose-built technology invented by Verisign technologists for the unique demands of the .com TLD. Verisign engineers have developed specialized technologies and protocols that are designed to achieve higher availability and resiliency to prevent disruption. Examples of this design include employing network, system, and application-level diversification approaches such as using hardware from multiple vendors for network and data center operations and using multiple operating system providers to better withstand localized failures or single-threaded supplier issues. Using in-house purpose-built systems, as opposed to leveraging public cloud operations, lowers the risks of circular dependencies as most public cloud providers also rely on .com and the root infrastructure operated by Verisign. These approaches ensure diversity and redundancy for every component of .com operations.

Verisign is also tasked with defending against highly sophisticated and massive volumetric cyberattacks while managing ever-increasing global demand. Trillions of dollars in global commerce and billions of internet users depend on the availability of Verisign infrastructure 24/7. To defend .com against cyberattacks, including by highly sophisticated nation-state actors, Verisign employs a comprehensive enterprise risk management program and threat-driven defensive practices that drive continuous improvements to Verisign’s systems and programs. Verisign has operationalized the National Institute of Standards and Technology’s (NIST) Cybersecurity Framework and the Center for Internet Security’s (CIS) Critical Security Controls in the ongoing design and evolution of its infrastructure, with a security-first mindset. In addition, Verisign employs advanced information security measures such as continuous monitoring, real-time threat detection, ongoing vulnerability assessments, bug bounty programs, and rigorous security audits to safeguard its infrastructure.

Verisign’s infrastructure powers more than just .com. In addition to operating other TLDs, Verisign plays a unique role as Root Zone Maintainer and operator of two of the world’s 13 root servers, a critical function necessary for internet navigation. Hundreds of Verisign employees have developed highly specialized skills, honed over decades, to develop, maintain, and operate this unique global infrastructure. Verisign holds more than 500 patents for DNS and related technologies, and its innovations are deployed globally by other critical internet infrastructure operators. Verisign has made many of its critical DNS patents available on a royalty-free basis to the global DNS community and those technologies have been deployed around the world.

Myth: The annual wholesale price for .com domain names – $10.26 as of Sept. 1 – is much higher than market value and is harming consumers.

Fact: While other generic TLDs (gTLDs) do not share .com’s pricing transparency, the annual wholesale renewal price of a .com domain name is lower than 87 percent of the 448 gTLDs for which such data is available from registrars. Based on that data, some of the largest original gTLDs, which have been in the market for over 20 years, have renewal pricing of $9.93 (.org), $15.00 (.biz), and $17.50 (.info). Some of the largest new gTLDs, which have been in the market for over 10 years, have renewal pricing of $10 (.xyz – increasing to $11 by the end of September), $25.00 (.online), and $40.00 (.store). The available market data makes it clear that .com domain names are priced at or below market value. It is notable that competing TLDs have continued to grow market share while pricing their domain names over twice as high as .com domain names.

Customers of .com domain names are more likely to be affected by two factors outside of Verisign’s control: 1) the rising cost of retail registrations that are outpacing wholesale prices, with some registrars now charging more than double the wholesale price to renew a .com domain name; and 2) the unregulated secondary market, which accumulates large inventories of domain names and charges markups that are – in some cases – thousands of times higher than the regulated wholesale price.

Myth: Verisign spends an unusual amount on share repurchases and dividends at the expense of infrastructure investment.

Fact: Verisign’s technological infrastructure is unmatched in the DNS industry for its scale, technical diversity, security, and resiliency. Verisign has invested for years to evolve and harden that technology, a fact illustrated by the company’s 27-year DNS uptime record. During the 2000s, Verisign offered a number of DNS-related services, including distributed denial-of-service (DDoS) attack mitigation and managed DNS. Significant capacity was added during that period. In 2018, when Verisign divested the last of its non-core businesses to focus on .com and other DNS operations, the company not only maintained, but increased capacity in order to meet growing DNS demand as well as to address growing DDoS volumetric attacks.

Verisign is certainly a profitable company and is proud of its operational success and history of sound financial management, which are important factors in maintaining the security, stability, and resiliency of the DNS. Some critics have singled out Verisign’s methods of increasing shareholder value, a duty of all public companies. Verisign has fulfilled this duty in part through share repurchases and dividends, which benefit a large and diverse group of shareholders including individuals, public employee retirement systems, index funds, and mutual funds (benefiting their millions of investors). Less than one percent of Verisign’s shares are held by company officers and directors.

Verisign’s return of capital practices are well in line with those of other successful public companies. In 2023, more than 90 percent of S&P 500 companies returned capital to shareholders and Verisign ranked 216th out of the S&P 500 in terms of cash returned to shareholders as a percentage of market capitalization. In terms of profitability, market expectation of Verisign’s earnings per share (a reliable measure of profitability) is $8.36 for the next 12 months, which places it 198th in the S&P 500.

Verisign’s sound and transparent financial management underpins its successful management of the .com TLD and other key internet infrastructure. Verisign has been a public company for 26 years and an S&P 500 company for 18 years. As a publicly listed company operating critical internet infrastructure, the public and the DNS ecosystem benefit from Verisign’s transparency in its operating and financial results, which must comply with the SEC’s disclosure rules and regulations for public companies. Verisign’s financial statements must also undergo an independent audit each year. By contrast, many other registries, registrars, and resellers, including some who focus on the secondary market, serve only the narrow interests of their private owners and do so with no obligations surrounding public disclosure or transparency of their ownership, profitability, operations, or otherwise. Adding obligations for these entities to report ownership, profitability, and other metrics to The Internet Corporation for Assigned Names and Numbers (ICANN) and the public would benefit the entire DNS ecosystem.

Myth: Contracts to operate gTLD registries should be routinely rebid, and a presumptive right of renewal for such contracts is bad for consumers and the internet.

Fact: The National Telecommunications and Information Administration (NTIA) recently opined that “The security, stability, and resilience of the Internet’s unique identifier systems is of paramount importance…” This position is shared by Verisign and the majority of participants in the global multistakeholder system of internet governance. ICANN has supported and clarified this priority and the role it plays in registry contracts. The contracts for .com and all other gTLDs reflect this priority (i.e., that stability and predictability in registry operations leads to long-term investments by operators). Verisign’s right to renew its .com Registry Agreement is conditioned on meeting rigorous technical and operational requirements to ensure .com’s continued security, stability, and continuous availability to billions of internet users. This contractual approach encourages gTLD operators to invest in infrastructure to support rising demand and defend against cyberattacks. Due to its investments, Verisign has operated .com with 100 percent DNS uptime for over 27 years.

Myth: Verisign’s operation of .com constitutes a “monopoly.”

Fact: There are nearly 1,200 gTLDs, and more than 250 country-code TLDs (ccTLDs), operating today. Each of these TLDs offer the same core functionality, allowing users to establish and maintain an online presence, establish websites, and create email addresses. Globally, there are over 362 million registered domain names – the majority of which are registered in TLDs not operated by Verisign. The number of domain names registered in non-Verisign operated gTLDs and ccTLDs has grown consistently as those TLDs have grown their share of the marketplace. In addition to this competition at the wholesale level, there are more than 2,800 ICANN-accredited registrars, and thousands more resellers, offering domain names at a range of prices and in a range of packages to consumers.

Further, from a practical perspective, the technical nature of TLD registries requires that they each be run by a single operator, but with so many operators in the marketplace, consumers have a broad and diverse array of choices at a range of prices. Other TLDs like .org, .shop, .ai, and .uk are not “monopolies” and neither is .com.

Myth: Verisign sets .com domain name prices for consumers.

Fact: Domain name registrars set unregulated retail prices for .com domain names, and those prices vary widely among the 2,800 ICANN-accredited registrars and associated resellers. Some registrars charge more than double the annual wholesale price for .com domain name renewals, and, in many cases, those price increases have outpaced Verisign’s tightly regulated .com wholesale price increases. In analyzing registrar pricing, it is important to distinguish introductory offers – which are often set lower to attract new customers – from renewal prices, which is what registrars charge existing customers to maintain their domain name registrations.

In addition to the retail registrar market, there is also a multibillion-dollar secondary market for domain names, in which domain investors, or “domainers,” accumulate millions of desirable domain names in order to resell them at markups that can be thousands of times higher than Verisign’s regulated wholesale prices. The gap between wholesale prices and secondary market prices makes it possible for domainers to hold names for years – making them prohibitively expensive to the general public. The profitability of the secondary market has also attracted successful retail registrars to expand into it, acquiring large portfolios of .com domain names and creating auction sites where they are sold well above retail prices. A blog that reports on high-profile domain name sales reported that just one reselling site handled $90 million in secondary sales in the second quarter of 2024 alone. Although the secondary marketplace may serve a function within the DNS ecosystem, it is completely unregulated.

Myth: The U.S. Government lifted price caps on .com domain names in 2018.

Fact: Amendment 35 to the Cooperative Agreement retained wholesale price restrictions in the .com TLD, while also retaining legacy regulations prohibiting Verisign from operating as a registrar in the .com TLD. Of the nearly 1,200 gTLDs overseen by ICANN and the global multistakeholder community, .com, .net, and .name (also operated by Verisign) remain the only three that are governed by maximum price restrictions. Those restrictions remain in place today and will remain in place after the .com Registry Agreement is renewed later this year.

The post Setting the Record Straight – Myths vs. Facts about .com appeared first on Verisign Blog.

Today, the latest issue of The Domain Name Industry Brief Quarterly Report was released by DNIB.com, showing the second quarter of 2024 closed with 362.4 million domain name registrations across all top-level domains (TLDs), unchanged compared to the first quarter of 2024. Domain name registrations increased by 5.8 million, or 1.6%, 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 2024, 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 362.4 Million Domain Name Registrations in the Second Quarter of 2024 appeared first on Verisign Blog.

Today, the latest issue of The Domain Name Industry Brief Quarterly Report was released by DNIB.com, showing the first quarter of 2024 closed with 362.4 million domain name registrations across all top-level domains (TLDs), an increase of 2.5 million domain name registrations, or 0.7%, compared to the fourth quarter of 2023. Domain name registrations also increased by 7.5 million, or 2.1%, year over year.

Starting with the Q1 2024 report, the DNIB Quarterly Report now includes new information on quarterly renewal percentages for all TLDs, as available, summary information on other legacy gTLDs as a group and an expanded overall analysis of gTLDs.

Check out the latest issue of The Domain Name Industry Brief Quarterly Report to see domain name stats from the first quarter of 2024, 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 362.4 Million Domain Name Registrations in the First Quarter of 2024 appeared first on Verisign Blog.

Every day, there are tens of thousands of domain names registered across the globe – often as a key first step in creating a unique online presence. Making that experience possible for Verisign-operated top-level domains (TLDs) like .com and .net is a powerful and flexible technology platform first introduced 25 years ago.

Thanks to the Shared Registration System (SRS) – a hardware and software system conceptualized, designed, and launched by our teams 25 years ago – we’re able to successfully manage relationships with approximately 2,000 ICANN-accredited registrars who generally submit more than 100 million domain name transactions daily. Over the past quarter century, the SRS has thrived and grown with the global internet, in large part because we’ve continuously scaled and evolved the technology to meet exponentially increasing global demand, and a rapidly changing cyberthreat landscape.

In addition to enabling domain name registration, the usefulness of the technology extends beyond Verisign and its registry operations: many other companies subsequently adopted SRS concepts and implemented their own shared registration systems, making its impact far-reaching and long-lasting.

In this blog post, we commemorate the 25th anniversary of the launch of the Verisign SRS by reflecting on the insight and collaboration that went into developing a structure for domain name registration in those early days of the internet’s mainstream adoption.

When It All Began

Network Solutions, which Verisign acquired in 2000, had been functioning as both the sole registry and registrar for TLDs including .com, .net, and .org prior to 1999. The SRS was initially developed to make domain name registration more competitive and to encourage greater international participation, consistent with The Framework for Global Electronic Commerce, a directive to the U.S. Department of Commerce (DoC) to privatize the internet’s Domain Name System (DNS).

Work began in 1998 to develop and implement the SRS so that an unlimited number of registrars could provide domain name registration services, all under the administration of a common registry for each TLD. For several high-profile TLDs – including .com and .net – that registry was Network Solutions. That same year, the Internet Corporation for Assigned Names and Numbers (ICANN) – a multistakeholder not-for-profit organization dedicated to the management of key elements of the DNS – was formed.

Designing and Deploying the System

Over a period of several months, Network Solutions designed and installed the system, which was officially deployed on April 3, 1999. Through a testing period that ran through the second half of 1999, the number of test registrars grew from an initial five – AOL, CORE, France Telecom/Oleane, Melbourne IT, and Register.com – to more than 20 by the end of that year.

That same year, Network Solutions implemented modifications to the SRS so that a registrar could accept registrations and renewals in one-year increments, as well as enable a registrar to add one year to a registrant’s registration period when transferring a domain from one registrar to another. Once the SRS was live, it was made accessible to all ICANN-accredited registrars, providing each one with equivalent access to register domain names in the TLDs.

Moving Forward: The Extensible Provisioning Protocol

When the SRS was first launched, a simple protocol called the Registry-Registrar Protocol (RRP) was deployed to handle the registration and management of domain names by many registrars in one TLD. However, we recognized that the use of this protocol could only be temporary given the growth of the internet and the need for a registration system with increased scalability. Work on a more sophisticated registration system began almost immediately – in 1999 – and that came in the form of the Extensible Provisioning Protocol, or EPP. EPP officially became an Internet Standard in 2009.

Today, EPP is used to register domain names and perform domain name-related functions, and there are over 2,000 ICANN-accredited registrars that all use EPP. EPP is central to the way that Verisign and many other authoritative registry operators do business: these registry operators work with domain name registrars to register domain names, and the registrars in turn offer a diverse range of domain name products to end users. Indeed, the simplicity of registering domains through EPP, and, for TLDs operated by Verisign, through the SRS, not only opened the door to easy access to domain name registration services, but also paved the way for new digital commerce and communications capabilities.

Powering Registrations in the Past, Present, and Future

For the past 25 years, the SRS has been a critical component of the internet’s backend technology, even though it’s not widely known outside the DNS community. Thanks to the foresight and planning of many talented technologists, we built and evolved this system in such a way that it has successfully supported hundreds of millions of domain name registrations across the globe, serving as a first step for many on the path to establishing durable online identities. Along the way, we’ve added support for new technologies, including DNSSEC and Internationalized Domain Names (IDNs). We’ve made the system more secure by strengthening the domain name locking and transfer processes. We’ve also expanded the SRS to support additional TLDs administered by Verisign. In its own quiet way, the SRS has helped to support the dynamic growth of the internet, while prioritizing equivalent access to domain name registration.

Many of the people who worked on the launch of the SRS are still with Verisign today, myself included. We are fortunate to have the chance to continue working together – 25 years later – always with an eye toward the future and how we can continue to help the internet grow and prosper.

The post The Verisign Shared Registration System: A 25-Year Retrospective appeared first on Verisign Blog.

Today, the latest issue of The Domain Name Industry Brief Quarterly Report was released by DNIB.com, showing the fourth quarter of 2023 closed with 359.8 million domain name registrations across all top-level domains (TLDs), an increase of 0.6 million domain name registrations, or 0.2%, compared to the third quarter of 2023. Domain name registrations also increased by 8.9 million, or 2.5%, 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 2023, including:

• Top 10 largest TLDs by number of reported domain names
• Top 10 largest ccTLDs by number of reported domain names
• ngTLDs as percentage of total TLDs
• Geographical ngTLDs as percentage of total corresponding geographical TLDs

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 359.8 Million Domain Name Registrations in the Fourth Quarter of 2023 appeared first on Verisign Blog.

The quantum computing era is coming, and it will change everything about how the world connects online. While quantum computing will yield tremendous benefits, it will also create new risks, so it’s essential that we prepare our critical internet infrastructure for what’s to come. That’s why we’re so pleased to share our latest efforts in this area, including technology that we’re making available as an open source implementation to help internet operators worldwide prepare.

In recent years, the research team here at Verisign has been focused on a future where quantum computing is a reality, and where the general best practices and guidelines of traditional cryptography are re-imagined. As part of that work, we’ve made three further contributions to help the DNS community prepare for these changes:

• an open source implementation of our Internet-Draft (I-D) on Merkle Tree Ladder (MTL) mode;
• a new I-D on using MTL mode signatures with DNS Security Extensions (DNSSEC); and
• an expansion of our previously announced public license terms to include royalty-free terms for implementing and using MTL mode if the I-Ds are published as Experimental, Informational, or Standards Track Requests for Comments (RFCs). (See the MTL mode I-D IPR declaration and the MTL mode for DNSSEC I-D IPR declaration for the official language.)

About MTL Mode

First, a brief refresher on what MTL mode is and what it accomplishes:

MTL mode is a technique developed by Verisign researchers that can reduce the operational impact of a signature scheme when authenticating an evolving series of messages. Rather than signing messages individually, MTL mode signs structures called Merkle tree ladders that are derived from the messages to be authenticated. Individual messages are authenticated relative to a ladder using a Merkle tree authentication path, while ladders are authenticated relative to a public key of an underlying signature scheme using a digital signature. The size and computational cost of the underlying digital signatures can therefore be spread across multiple messages.

The reduction in operational impact achieved by MTL mode can be particularly beneficial when the mode is applied to a signature scheme that has a large signature size or computational cost in specific use cases, such as when post-quantum signature schemes are applied to DNSSEC.

Recently, Verisign Fellow Duane Wessels described how Verisign’s DNSSEC algorithm update — from RSA/SHA-256 (Algorithm 8) to ECDSA Curve P-256 with SHA-256 (Algorithm 13) — increases the security strength of DNSSEC signatures and reduces their size impact. The present update is a logical next step in the evolution of DNSSEC resiliency. In the future, it is possible that DNSSEC may utilize a post-quantum signature scheme. Among the new post-quantum signature schemes currently being standardized, though, there is a shortcoming; if we were to directly apply these schemes to DNSSEC, it would significantly increase the size of the signatures¹. With our work on MTL mode, the researchers at Verisign have provided a way to achieve the security benefit of a post-quantum algorithm rollover in a way that mitigates the size impact.

Put simply, this means that in a quantum environment, the MTL mode of operation developed by Verisign will enable internet infrastructure operators to use the longer signatures they will need to protect communications from quantum attacks, while still supporting the speed and space efficiency we’ve come to expect.

For more background information on MTL mode and how it works, see my July 2023 blog post, the MTL mode I-D, or the research paper, “Merkle Tree Ladder Mode: Reducing the Size Impact of NIST PQC Signature Algorithms in Practice.”

Recent Standardization Efforts

In my July 2023 blog post titled “Next Steps in Preparing for Post-Quantum DNSSEC,” I described two recent contributions by Verisign to help the DNS community prepare for a post-quantum world: the MTL mode I-D and a public, royalty-free license to certain intellectual property related to that I-D. These activities set the stage for the latest contributions I’m announcing in this post today.

Our Latest Contributions

• Open source implementation. Like the I-D we published in July of this year, the open source implementation focuses on applying MTL mode to the SPHINCS+ signature scheme currently being standardized in FIPS 205 as SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) by the National Institute of Standards and Technology (NIST). We chose SPHINCS+ because it is the most conservative of NIST’s post-quantum signature algorithms from a cryptographic perspective, being hash-based and stateless. We remain open to adding other post-quantum signature schemes to the I-D and to the open source implementation.
  We encourage developers to try out the open source implementation of MTL mode, which we introduced at the IETF 118 Hackathon, as the community’s experience will help improve the understanding of MTL mode and its applications, and thereby facilitate its standardization. We are interested in feedback both on whether MTL mode is effective in reducing the size impact of post-quantum signatures on DNSSEC and other use cases, and on the open source implementation itself. We are particularly interested in the community’s input on what language bindings would be useful and on which cryptographic libraries we should support initially. The open source implementation can be found on GitHub at: https://github.com/verisign/MTL
• MTL mode for DNSSEC I-D. This specification describes how to use MTL mode signatures with DNSSEC, including DNSKEY and RRSIG record formats. The I-D also provides initial guidance for DNSSEC key creation, signature generation, and signature verification in MTL mode. We consider the I-D as an example of the kinds of contributions that can help to address the “Research Agenda for a Post-Quantum DNSSEC,” the subject of another I-D recently co-authored by Verisign. We expect to continue to update this I-D based on community feedback. While our primary focus is on the DNSSEC use case, we are also open to collaborating on other applications of MTL mode.
• Expanded patent license. Verisign previously announced a public, royalty-free license to certain intellectual property related to the MTL mode I-D that we published in July 2023. With the availability of the open source implementation and the MTL mode for DNSSEC specification, the company has expanded its public license terms to include royalty-free terms for implementing and using MTL mode if the I-D is published as an Experimental, Informational, or Standards Track RFC. In addition, the company has made a similar license grant for the use of MTL mode with DNSSEC. See the MTL mode I-D IPR declaration and the MTL mode for DNSSEC I-D IPR declaration for the official language.

Verisign is grateful for the DNS community’s interest in this area, and we are pleased to serve as stewards of the internet when it comes to developing new technology that can help the internet grow and thrive. Our work on MTL mode is one of the longer-term efforts supporting our mission to enhance the security, stability, and resiliency of the global DNS. We’re encouraged by the progress that has been achieved, and we look forward to further collaborations as we prepare for a post-quantum future.

Footnotes

1. While it’s possible that other post-quantum algorithms could be standardized that don’t have large signatures, they wouldn’t have been studied for as long. Indeed, our preferred approach for long-term resilience of DNSSEC is to use the most conservative of the post-quantum signature algorithms, which also happens to have the largest signatures. By making that choice practical, we’ll have a solution in place whether or not a post-quantum algorithm with a smaller signature size is eventually available. ↩︎

The post Verisign Provides Open Source Implementation of Merkle Tree Ladder Mode appeared first on Verisign Blog.

Today, the latest issue of The Domain Name Industry Brief Quarterly Report was released by DNIB.com, showing the third quarter of 2023 closed with 359.3 million domain name registrations across all top-level domains (TLDs), an increase of 2.7 million domain name registrations, or 0.8%, compared to the second quarter of 2023. Domain name registrations also increased by 8.5 million, or 2.4%, year over year.

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

• Top 10 largest TLDs by number of reported domain names
• Top 10 largest ccTLDs by number of reported domain names
• ngTLDs as percentage of total TLDs
• Geographical ngTLDs as percentage of total corresponding geographical TLDs

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 359.3 Million Domain Name Registrations in the Third Quarter of 2023 appeared first on Verisign Blog.

Celebrating National Hispanic Heritage Month reminds us how the wide range of perspectives and experiences among our employees makes us stronger both as a company and as a steward of the internet. In honor of this month, we are proud to recognize the stories of three of our Hispanic employees, and the positive impact they make at Verisign.

Carlos Ruesta

As Verisign’s director of information security, Carlos Ruesta draws inspiration from his father’s community commitment as an agricultural engineer in Peru, working to bring safe food and water to isolated communities. His father’s experiences inform Carlos’ belief in Verisign’s mission of enabling the world to connect online with reliability and confidence, anytime, anywhere and motivates his work as part of a team that ensures trust.

As a leader in our security compliance division, Carlos ensures that his team maintains a robust governance, risk, and compliance framework, translating applicable laws and regulations into security control requirements. “Being part of a team that emphasizes trust, motivates me,” he said. “Management trusts me to make decisions affecting large-scale projects that protect our company. This allows me to use my problem-solving skills and leadership abilities.”

Carlos commends Verisign’s respectful and encouraging environment, which he considers vital in cultivating successful career paths for newcomers navigating the cybersecurity field. He says by recognizing individual contributions and supporting each other’s professional growth, Hispanic employees at Verisign feel a sense of belonging in the workplace and are able to excel in their career journeys.

Alejandro Gonzalez Roman

Alejandro Gonzalez Roman, a senior UX designer at Verisign, combines his artistic talent with technical expertise in his role, collaborating among various departments across Verisign. “My dad is an artist, and still one of my biggest role models,” he said. “He taught me that to be good at anything means to dedicate a lot of time to perfecting your craft. I see art as a way to inspire people to make the world a better place. In my job as a UX designer, I use art to make life a little easier for people.”

As a UX designer, Alejandro strives to make technology accessible to everyone, regardless of background or abilities. He believes that life experiences and cultural knowledge provide individuals with a unique perspective, which he considers an invaluable source of inspiration when designing. And with the Hispanic population being one of the largest minorities in the United States, cultural knowledge is crucial. Understanding how different people interact with technology and integrating cultural insights into the work is essential to good UX design.

Overall, Alejandro is motivated by the strong sense of teamwork at Verisign. “Day-to-day work with our strong team has helped me improve my work” he said. “With collaboration and encouragement, we push each other to be better UX designers. I couldn’t succeed as I have without this amazing team around me.”

Rebecca Bustamante

Rebecca Bustamante, senior manager of operations analysis, says Verisign’s “people-first” culture is part of her motivation, and she is grateful for the opportunities that allowed her to take on different roles within the company to learn and broaden her skills. “I’ve had opportunities because people believed in my potential and saw my work ethic,” she said. “These experiences have given me the understanding and skills to succeed at the job I have today.”

One of these experiences was joining the WIT@Verisign (Women in Technology) leadership team, which proved instrumental to her personal growth and led to valuable work friendships. In fact, one of her most cherished memories at Verisign includes leading a Verisign Cares team project in Virginia’s Great Falls Park, where she and her coworkers worked together to clear invasive plants and renovate walking paths.

Rebecca sees this type of camaraderie among employees as a crucial part of the people-first culture at Verisign. She particularly commends Verisign’s team leaders who value consistent communication and take the time to listen to people’s stories, which fosters an authentic understanding. This approach makes collaboration more natural and allows teamwork to develop organically. Rebecca emphasizes the significance of celebrating her culture, as it directly influences her job performance and effective communication. But she pointed out that the term “Hispanic” encompasses a wide diversity of peoples and nations. She advocates respect, practices active listening, and promotes a culture celebrating each other’s successes.

Joining the Verisign Team

These three individuals – as well as their many team members – contribute to Verisign’s efforts to enable and enhance the security, stability, and resiliency of key internet infrastructure every single day.

At Verisign, we recognize the importance of talent and culture in driving an environment that fosters high performance, inclusion, and integrity in all aspects of our work. It’s why recruiting and retaining the very best talent is our continual focus. If you would like to be part of the Verisign Team, please visit Verisign Careers.

The post Verisign Celebrates Hispanic Heritage Month appeared first on Verisign Blog.

Today, the latest issue of The Domain Name Industry Brief Quarterly Report was released by DNIB.com, showing the second quarter of 2023 closed with 356.6 million domain name registrations across all top-level domains (TLDs), an increase of 1.7 million domain name registrations, or 0.5%, compared to the first quarter of 2023. Domain name registrations also increased by 4.3 million, or 1.2%, 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 2023, including:

• Top 10 largest TLDs by number of reported domain names
• Top 10 largest ccTLDs by number of reported domain names
• ngTLDs as percentage of total TLDs
• Geographical ngTLDs as percentage of total corresponding geographical TLDs

With the launch of the DNIB.com dashboards, 16 additional TLDs have been included in applicable calculations. The applicable current and historical data presented in this edition of the quarterly report have been adjusted accordingly, and applicable quarterly and year-over-year trends have been calculated using those adjusted figures. More information is available at DNIB.com.

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 356.6 Million Domain Name Registrations in the Second Quarter of 2023 appeared first on Verisign Blog.

As part of Verisign’s ongoing effort to make global internet infrastructure more secure, stable, and resilient, we will soon make an important technology update to how we protect the top-level domains (TLDs) we operate. The vast majority of internet users won’t notice any difference, but the update will support enhanced security for several Verisign-operated TLDs and pave the way for broader adoption and the next era of Domain Name System (DNS) security measures.

Beginning in the next few months and continuing through the end of 2023, we will upgrade the algorithm we use to sign domain names in the .com, .net, and .edu zones with Domain Name System Security Extensions (DNSSEC).

In this blog, we’ll outline the details of the upcoming change and what members of the DNS technical community need to know.

DNSSEC Adoption

DNSSEC provides data authentication security to DNS responses. It does this by ensuring any altered data can be detected and blocked, thereby preserving the integrity of DNS data. Think of it as a chain of trust – one that helps avoid misdirection and allows users to trust that they have gotten to their intended online destination safely and securely.

Verisign has long been at the forefront of DNSSEC adoption. In 2010, a major milestone occurred when the Internet Corporation for Assigned Names and Numbers (ICANN) and Verisign signed the DNS root zone with DNSSEC. Shortly after, Verisign introduced DNSSEC to its TLDs, beginning with .edu in mid-2010, .net in late 2010, and .com in early 2011. Additional TLDs operated by Verisign were subsequently signed as well.

In the time since we signed our TLDs, we have worked continuously to help members of the internet ecosystem take advantage of DNSSEC. We do this through a wide range of activities, including publishing technical resources, leading educational sessions, and advocating for DNSSEC adoption in industry and technical forums.

Growth Over Time

Since the TLDs were first signed, we have observed two very distinct phases of growth in the number of signed second-level domains (SLDs).

The first growth phase occurred from 2012 to 2020. During that time, signed domains in the .com zone grew at about 0.1% of the base per year on average, reaching just over 1% by the end of 2020. In the .net zone, signed domains grew at about 0.1% of the base per year on average, reaching 1.2% by the end of 2020. These numbers demonstrated a slow but steady increase, which can be seen in Figure 1.

Figure 1: A chart spanning 2010 through the present shows the number of .com and .net domain names with DS – or Delegation Signer – records. These records form a link in the DNSSEC chain-of-trust for signed domains, indicating an uptick in DNSSEC adoption among SLDs.

We’ve observed more pronounced growth in signed SLDs during the second growth phase, which began in 2020. This is largely due to a single registrar that enabled DNSSEC by default for their new registrations. For .com, the annual rate increased to 0.9% of the base, and for .net, it increased to 1.1% of the base. Currently, 4.2% of .com domains are signed and 5.1% of .net domains are signed. This accelerated growth is also visible in Figure 1.

As we look forward, Verisign anticipates continued growth in the number of domains signed with DNSSEC. To support continued adoption and help further secure the DNS, we’re planning to make one very important change.

Rolling the Algorithm

All Verisign TLDs are currently signed with DNSSEC algorithm 8, also known as RSA/SHA-256, as documented in our DNSSEC Practice Statements. Currently, we use a 2048-bit Key Signing Key (KSK), and 1280-bit Zone Signing Keys (ZSK). The RSA algorithm has served us (and the broader internet) well for many years, but we wanted to take the opportunity to implement more robust security measures while also making more efficient use of resources that support DNSSEC-signed domain names.

We are planning to transition to the Elliptic Curve Digital Signature Algorithm (ECDSA), specifically Curve P-256 with SHA-256, or algorithm number 13, which allows for smaller signatures and improved cryptographic strength. This smaller signature size has a secondary benefit, as well: any potential DDoS attacks will have less amplification as a result of the smaller signatures. This could help protect victims from bad actors and cybercriminals.

Support for DNSSEC signing and validation with ECDSA has been well-established by various managed DNS providers, 78 other TLDs, and nearly 10 million signed SLDs. Additionally, research performed by APNIC and NLnet Labs shows that ECDSA support in validating resolvers has increased significantly in recent years.

The Road to Algorithm 13

How did we get to this point? It took a lot of careful preparation and planning, but with internet stewardship at the forefront of our mission, we wanted to protect the DNS with the best technologies available to us. This means taking precise measures in everything we do, and this transition is no exception.

Initial Planning

Algorithm 13 was on our radar for several years before we officially kicked off the implementation process this year. As mentioned previously, the primary motivating properties were the smaller signature size, with each signature being 96 bytes smaller than our current RSA signatures (160 bytes vs. 64 bytes), and the improved cryptographic strength. This helps us plan for the future and prepare for a world where more domain names are signed with DNSSEC.

Testing

Each TLD will first implement the rollover to algorithm 13 in Verisign’s Operational Test & Evaluation (OT&E) environment prior to implementing the process in production, for a total of two rollovers per TLD. Combined, this will result in six total rollovers across the .com, .net, and .edu TLDs. Rollovers between the individual TLDs will be spaced out to avoid overlap where possible.

The algorithm rollover for each TLD will follow this sequence of events:

1. Publish algorithm 13 ZSK signatures alongside algorithm 8 ZSK signatures
2. Publish algorithm 13 DNSKEY records alongside algorithm 8 DNSKEY records
3. Publish the algorithm 13 DS record in the root zone and stop publishing the algorithm 8 DS record
4. Stop publishing algorithm 8 DNSKEY records
5. Stop publishing algorithm 8 ZSK signatures

Only when a successful rollover has been done in OT&E will we begin the process in production.

Who is affected, and when is the change happening?

Now that we’ve given the background, we know you’re wondering: how might this affect me?

The change to a new DNSSEC-signing algorithm is expected to have no impact for the vast majority of internet users, service providers, and domain registrants. According to the aforementioned research by APNIC and NLnet Labs, most DNSSEC validators support ECDSA, and any that do not will simply ignore the signatures and still be able to resolve domains in Verisign-operated TLDs.

Regarding timing, we plan to begin to transition to ECDSA in the third and fourth quarters of this year. We will start the transition process with .edu, then .net, and then .com. We are currently aiming to have these three TLDs transitioned before the end of the fourth quarter 2023, but we will let the community know if our timeline shifts.

Conclusion

As leaders in DNSSEC adoption, this algorithm rollover demonstrates yet another critical step we are taking toward making the internet more secure, stable, and resilient. We look forward to enabling the change later this year, providing more efficient and stronger cryptographic security while optimizing resource utilization for DNSSEC-signed domain names.

The post Verisign Will Help Strengthen Security with DNSSEC Algorithm Update appeared first on Verisign Blog.

In 2021, we discussed a potential future shift from established public-key algorithms to so-called “post-quantum” algorithms, which may help protect sensitive information after the advent of quantum computers. We also shared some of our initial research on how to apply these algorithms to the Domain Name System Security Extensions, or DNSSEC. In the time since that blog post, we’ve continued to explore ways to address the potential operational impact of post-quantum algorithms on DNSSEC, while also closely tracking industry research and advances in this area.

Now, significant activities are underway that are setting the timeline for the availability and adoption of post-quantum algorithms. Since DNS participants – including registries and registrars – use public key-cryptography in a number of their systems, these systems may all eventually need to be updated to use the new post-quantum algorithms. We also announce two major contributions that Verisign has made in support of standardizing this technology: an Internet-Draft as well as a public, royalty-free license to certain intellectual property related to that Internet-Draft.

In this blog post, we review the changes that are on the horizon and what they mean for the DNS ecosystem, and one way we are proposing to ease the implementation of post-quantum signatures – Merkle Tree Ladder mode.

By taking these actions, we aim to be better prepared (while also helping others prepare) for a future where cryptanalytically relevant quantum computing and post-quantum cryptography become a reality.

Recent Developments

In July 2022, the National Institute of Standards and Technology (NIST) selected one post-quantum encryption algorithm and three post-quantum signature algorithms for standardization, with standards for these algorithms arriving as early as 2024. In line with this work, the Internet Engineering Task Force (IETF) has also started standards development activities on applying post-quantum algorithms to internet protocols in various working groups, including the newly formed Post-Quantum Use in Protocols (PQUIP) working group. And finally, the National Security Agency (NSA) recently announced that National Security Systems are expected to transition to post-quantum algorithms by 2035.

Collectively, these announcements and activities indicate that many organizations are envisioning a (post-)quantum future, across many protocols. Verisign’s main concern continues to be how post-quantum cryptography impacts the DNS, and in particular, how post-quantum signature algorithms impact DNSSEC.

DNSSEC Considerations

The standards being developed in the next few years are likely to be the ones deployed when the post-quantum transition eventually takes place, so now is the time to take operational requirements for specific protocols into account.

For DNSSEC, the operational concerns are twofold.

First, the large signature sizes of current post-quantum signatures selected by NIST would result in DNSSEC responses that exceed the size limits of the User Datagram Protocol, which is broadly deployed in the DNS ecosystem. While the Transmission Control Protocol and other transports are available, the additional overhead of having large post-quantum signatures on every response — which can be one to two orders of magnitude as long as traditional signatures —introduces operational risk to the DNS ecosystem that would be preferable to avoid.

Second, the large signatures would significantly increase memory requirements for resolvers using in-memory caches and authoritative nameservers using in-memory databases.

Figure 1, from Andy Fregly’s recent presentation at OARC 40, shows the impact on a fully signed DNS zone where, on average, there are 2.2 digital signatures per resource record set (covering both existence and non-existence proofs). The horizontal bars show the percentage of the zone file that would be comprised of signature data for the two prevalent current algorithms, RSA and ECDSA, and for the smallest and largest of the NIST PQC algorithms. At the low and high end of these examples, signatures with ECDSA would take up 40% of the zone and SPHINCS+ signatures would take up over 99% of the zone. The vertical bars give the percentage size increase of the zone file due to signatures. Again, comparing the low and high end, a zone fully signed with SPHINCS+ would be about 50 times the size of a zone fully signed with ECDSA.

Merkle Tree Ladder Mode: Reducing Size Impact of Post-Quantum Signatures

In his 1988 article, “The First Ten Years of Public-Key Cryptography,” Whitfield Diffie, co-discoverer of public-key cryptography, commented on the lack of progress in finding public-key encryption algorithms that were as fast as the symmetric-key algorithms of the day: “Theorems or not, it seemed silly to expect that adding a major new criterion to the requirements of a cryptographic system could fail to slow it down.”

Diffie’s counsel also appears relevant to the search for post-quantum algorithms: It would similarly be surprising if adding the “major new criterion” of post-quantum security to the requirements of a digital signature algorithm didn’t impact performance in some way. Signature size may well be the tradeoff for post-quantum security, at least for now.

With this tradeoff in mind, Verisign’s post-quantum research team has explored ways to address the size impact, particularly to DNSSEC, arriving at a construction we call a Merkle Tree Ladder (MTL), a generalization of a single-rooted Merkle tree (see Figure 2). We have also defined a technique that we call the Merkle Tree Ladder mode of operation for using the construction with an underlying signature algorithm.

Similar to current deployments of public-key cryptography, MTL mode combines processes with complementary properties to balance performance and other criteria (see Table 1). In particular, in MTL mode, rather than signing individual messages with a post-quantum signature algorithm, ladders comprised of one or more Merkle tree nodes are signed using the post-quantum algorithm. Individual messages are then authenticated relative to the ladders using Merkle authentication paths.

Although the signatures on the ladders might be relatively large, the ladders and their signatures are sent infrequently. In contrast, the Merkle authentication paths that are sent for each message are relatively short. The combination of the two processes maintains the post-quantum property while amortizing the size impact of the signatures across multiple messages. (Merkle tree constructions, being based on hash functions, are naturally post-quantum.)

The two-part approach for public-key algorithms has worked well in practice. In Transport Layer Security, symmetric keys are established in occasional handshake operations, which may be more expensive. The symmetric keys are then used to encrypt multiple messages within a session without further overhead for key establishment. (They can also be used to start a new session).

We expect that a two-part approach for post-quantum signatures can similarly work well in an application like DNSSEC where verifiers are interested in authenticating a subset of messages from a large, evolving message series (e.g., DNS records).

In such applications, signed Merkle Tree Ladders covering a range of messages in the evolving series can be provided to a verifier occasionally. Verifiers can then authenticate messages relative to the ladders, given just a short Merkle authentication path.

Importantly, due to a property of Merkle authentication paths called backward compatibility, all verifiers can be given the same authentication path relative to the signer’s current ladder. This also helps with deployment in applications such as DNSSEC, since the authentication path can be published in place of a traditional signature. An individual verifier may verify the authentication path as long as the verifier has a previously signed ladder covering the message of interest. If not, then the verifier just needs to get the current ladder.

As reported in our presentation on MTL mode at the RSA Conference Cryptographers’ Track in April 2023, our initial evaluation of the expected frequency of requests for MTL mode signed ladders in DNSSEC is promising, suggesting that a significant reduction in effective signature size impact can be achieved.

Verisign’s Contributions to Standardization

To facilitate more public evaluation of MTL mode, Verisign’s post-quantum research team last week published the Internet-Draft “Merkle Tree Ladder Mode (MTL) Signatures.” The draft provides the first detailed, interoperable specification for applying MTL mode to a signature scheme, with SPHINCS+ as an initial example.

We chose SPHINCS+ because it is the most conservative of the NIST PQC algorithms from a cryptographic perspective, being hash-based and stateless. It is arguably most suited to be one of the algorithms in a long-term deployment of a critical infrastructure service like DNSSEC. With this focus, the specification has a “SPHINCS+-friendly” style. Implementers familiar with SPHINCS+ will find similar notation and constructions as well as common hash function instantiations. We are open to adding other post-quantum signature schemes to the draft or other drafts in the future.

Publishing the Internet-Draft is a first step toward the goal of standardizing a mode of operation that can reduce the size impact of post-quantum signature algorithms.

In support of this goal, Verisign also announced this week a public, royalty-free license to certain intellectual property related to the Internet-Draft published last week. Similar to other intellectual property rights declarations the company has made, we have announced a “Standards Development Grant” which provides the listed intellectual property under royalty-free terms for the purpose of facilitating standardization of the Internet-Draft we published on July 10, 2023. (The IPR declaration gives the official language.)

We expect to release an open-source implementation of the Internet-Draft soon, and, later this year, to publish an Internet-Draft on using MTL mode signatures in DNSSEC.

With these contributions, we invite implementers to take part in the next step toward standardization: evaluating initial versions of MTL mode to confirm whether they indeed provide practical advantages in specific use cases.

Conclusion

DNSSEC continues to be an important part of the internet’s infrastructure, providing cryptographic verification of information associated with the unique, stable identifiers in this ubiquitous namespace. That is why preparing for an eventual transition to post-quantum algorithms for DNSSEC has been and continues to be a key research and development activity at Verisign, as evidenced by our work on MTL mode and post-quantum DNSSEC more generally.

Our goal is that with a technique like MTL mode in place, protocols like DNSSEC can preserve the security characteristics of a pre-quantum environment while minimizing the operational impact of larger signatures in a post-quantum world.

In a later blog post, we’ll share more details on some upcoming changes to DNSSEC, and how these changes will provide both security and operational benefits to DNSSEC in the near term.

Verisign plans to continue to invest in research and standards development in this area, as we help prepare for a post-quantum future.

The post Next Steps in Preparing for Post-Quantum DNSSEC appeared first on Verisign Blog.

Verisign today announced the launch of DNIB.com, the new Domain Name Industry Brief (DNIB) website.

Sponsored by Verisign, DNIB.com is a source for insights and analysis from subject-matter experts on key topics relevant to the global Domain Name System (DNS). DNIB.com will offer insight on policy, governance, technology, security, and business trends relevant to analysts, entrepreneurs, policymakers, and anyone with an interest in the DNS. The website features a collection of new, searchable, and interactive dashboards tracking relevant DNS data and trends, that is designed to be a valuable day-to-day resource for industry stakeholders, and anyone interested in learning more about global domain name operations.

DNIB.com is also the new home of the DNIB quarterly report, which Verisign has published for more than a decade, providing a trusted and valued resource for stakeholders across the globe seeking to understand the dynamism and trends of the domain name industry.

The report will be published each quarter at DNIB.com, summarizing the state of the domain name industry through a variety of statistical and analytical research. The new and expanded DNIB.com dashboards take that statistical data to the next level, enabling exploration of trend data across the industry, providing additional history and depth, and offering expert insights and commentary.

The post Announcing the Launch of DNIB.com, a New Source for DNS News, Information, Research, and Analysis appeared first on Verisign Blog.

Today, we released the latest issue of The Domain Name Industry Brief, which shows that the first quarter of 2023 closed with 354.0 million domain name registrations across all top-level domains (TLDs), an increase of 3.5 million domain name registrations, or 1.0%, compared to the fourth quarter of 2022.^1,2 Domain name registrations also increased by 3.5 million, or 1.0%, year over year.^1,2

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

• Top 10 Largest TLDs by Number of Reported Domain Names
• Top 10 Largest ccTLDs by Number of Reported Domain Names
• ngTLDs as Percentage of Total TLDs
• Geographical ngTLDs as Percentage of Total Corresponding Geographical TLDs

This issue of the Domain Name Industry Brief includes a correction to the March 2023 issue, which incorrectly reported the number of domain name registrations in the .eu ccTLD.² This was the result of a one-time error in the .eu domain name registration data, provided by ZookNIC, which has since been resolved.

To see past issues of The Domain Name Industry Brief, please visit https://verisign.com/dnibarchives.

1. All figure(s) exclude domain names in the .tk, .cf, .ga, .gq, and .ml ccTLDs. Quarterly and year-over-year trends have been calculated relative to historical figures that have also been adjusted to exclude these five ccTLDs. For further information, please see the Editor’s Note contained in Vol. 19, Issue 1 of The Domain Name Industry Brief.
2. The generic TLD, ngTLD and ccTLD data cited in the brief: (i) includes ccTLD internationalized domain names, (ii) is an estimate as of the time this brief was developed and (iii) is subject to change as more complete data is received. Some numbers in the brief may reflect standard rounding.

The post Verisign Domain Name Industry Brief: 354.0 Million Domain Name Registrations in the First Quarter of 2023 appeared first on Verisign Blog.

This blog was co-authored by Verisign Distinguished Engineer Mike Hollyman and Verisign Director – Engineering Hasan Siddique. It is based on a lightning talk they gave at NANOG 87 in February 2023, the slides from which are available on the NANOG website.

At Verisign, we believe that continuous improvements to the safety and security of the global routing system are critical for the reliability of the internet. As such, we’ve recently embarked on a path to implement Resource Public Key Infrastructure (RPKI) within our technology ecosystem as a step toward building a more secure routing system. In this blog, we share our ongoing journey toward RPKI adoption and the lessons we’ve learned as an operator of critical internet infrastructure.

While RPKI is not a silver bullet for securing internet routing, practical adoption of RPKI can deliver significant benefits. This will be a journey of deliberate, measured, and incremental steps towards a larger goal, but we believe the end result will be more than worth it.

Why RPKI and why now?

Under the Border Gateway Protocol (BGP) – the internet’s de-facto inter-domain routing protocol for the last three decades – local routing policies decide where and how internet traffic flows, but each network independently applies its own policies on what actions it takes, if any, with data that connects through its network. For years, “routing by rumor” served the internet well; however, our growing dependence upon the global internet for sensitive and critical communications means that internet infrastructure merits a more robust approach for protecting routing information. Preventing route leaks, mis-originations, and hijacks is a first step.

Verisign was one of the first organizations to join the Mutually Agreed Norms for Routing Security (MANRS) Network Operator Program in 2017. Ever since the establishment of the program, facilitating routing information – via an Internet Routing Registry (IRR) or RPKI – has been one of the key “actions” of the MANRS program. Verisign has always been fully supportive of MANRS and its efforts to promote a culture of collective responsibility, collaboration, and coordination among network peers in the global internet routing system.

Just as RPKI creates new protections, it also brings new challenges. Mindful of those challenges, but committed to our mission of upholding the security, stability, and resiliency of the internet, Verisign is heading toward RPKI adoption.

Adopting RPKI ROV and External Dependencies

In his March 2022 blog titled “Routing Without Rumor: Securing the Internet’s Routing System,” Verisign EVP & CSO, Danny McPherson, discussed how “RPKI creates new external and third-party dependencies that, as adoption continues, ultimately replace the traditionally autonomous operation of the routing system with a more centralized model. If too tightly coupled to the routing system, these dependencies may impact the robustness and resilience of the internet itself.” McPherson’s blog also reviewed the importance of securing the global internet BGP routing system, including utilizing RPKI to help overcome the hurdles that BGP’s implicit trust model presents.

RPKI Route Origin Validation (ROV) is one critical step forward in securing the global BGP system to prevent mis-originations and errors from propagating invalid routing information worldwide. RPKI ROV helps move the needle towards a safer internet. However, just as McPherson pointed out, this comes at the expense of creating a new external dependency within the operational path of Verisign’s critical Domain Name System (DNS) services.

RPKI Speed Bumps

At NANOG 87, we shared our concerns on how systemic and circular dependencies must be acknowledged and mitigated, to the extent possible. The following are some concerns and potential risks related to RPKI:

• RPKI has yet to reach the operational maturity of related, established routing protocols, such as BGP. BGP has been around for over 30 years, but comparatively, RPKI has been growing in the Internet Engineering Task Force (IETF) Secure Inter-Domain Routing Operations (SIDROPS) working group for only 12 years. Currently, RPKI Unique Prefix-Origin Pairs are seen for just over 40% of the global routing prefixes, and much of that growth has occurred only in the last four years. Additionally, as the RPKI system gains support, we see how it occasionally fails due to a lack of maturity. The good news is that the IETF is actively engaged in making improvements to the system, and it’s rewarding to see the progress being made.
• Every organization deploying RPKI needs to understand the circular dependencies that may arise. For example, publishing a Route Origin Authorization (ROA) in the RPKI system requires the DNS. Additionally, there are over 20 publishing points in the RPKI system today with fully qualified domain names (FQDNs) in the .com and .net top-level domains (TLDs). All five of the Regional Internet Registries (RIRs) use the .net TLD for their RPKI infrastructure.
• Adopting RPKI means taking on additional, complex responsibilities. Organizations that participate in RPKI inherit additional operational tasks for testing, publishing, and alerting of the RPKI system and ultimately operating net-new infrastructure; however, these 24/7 services are critical when it comes to supporting a system that relates to routing stability.
• In order to adequately monitor RPKI deployment, ample resources are required. Real-time monitoring should be considered a basic requirement for both internal and external RPKI infrastructure. As such, organizations must allocate technical engineering resources and support services to meet this need.

Additional considerations include:

• the shared fate dependency (i.e., when all prefixes are signed with ROAs)
• long-term engineering support
• operational integration of RPKI systems
• operational experience of RIRs as they now run critical infrastructure to support RPKI
• overclaiming with the RIR certification authorities
• lack of transparency for operator ROV policies
• inconsistency between open source RPKI validator development efforts
• the future scale of RPKI

These items require careful consideration before implementing RPKI, not afterwards.

Managing Risks

To better manage potential risks in our journey towards RPKI adoption, we established “day zero” requirements. These included firm conditions that must be met before any further testing could occur, including monitoring data across multiple protocols, coupled with automated ROA/IRR provisioning.

The deliberate decision to take a measured approach has proved rewarding, leaving us better positioned to manage and maintain our data and critical RPKI systems.

Investing engineering cycles in building robust monitoring and automation has increased our awareness of trends and outages based on global and local observability. As a result, operations and support teams benefit from live training on how to respond to RPKI-related events. This has helped us improve operational readiness in response to incidents. Additionally, automation reduces the risk of human error and, when coupled with monitoring, introduces stronger guardrails throughout the provisioning process.

Balancing Our Mission with Adopting New Technology

Verisign’s core mission is to enable the world to connect online with reliability and confidence, anytime, anywhere. This means that as we adopt RPKI, we must adhere to strict design principles that don’t risk sacrificing the integrity and availability of DNS data.

Our path to RPKI adoption is just one example of how we continuously strive for improvement and implement new technology, all while ensuring we protect Verisign’s critical DNS services.

While there are obstacles ahead of us, at Verisign we strongly advocate for consistent, focused discipline and continuous improvement. This means our course is set – we are firmly moving toward RPKI adoption.

Conclusion

Our goal is to improve internet routing security programs through efforts such as technology implementation, industry engagement, standards development, open-source contributions, funding, and the identification of shared risks which need to be understood and managed appropriately.

Implementing RPKI at your own organization will require broad investment in your people, processes, and technology stack. At Verisign specifically, we have assigned resources to perform research, increased budgets, completed various risk management tasks, and allocated significant time to development and engineering cycles. While RPKI itself does not address all security issues, there are incremental steps we can collectively take toward building a more resilient internet routing security paradigm.

As stewards of the internet, we are implementing RPKI as the next step in strengthening the security of internet routing information. We look forward to sharing updates on our progress.

The post Building a More Secure Routing System: Verisign’s Path to RPKI appeared first on Verisign Blog.

The launch of .web top-level domain is once again at risk of being delayed by baseless procedural maneuvering.

On May 2, the Internet Corporation for Assigned Names and Numbers (ICANN) Board of Directors posted a decision on the .web matter from its April 30 meeting, which found “that NDC (Nu Dotco LLC) did not violate the Guidebook or the Auction Rules” and directed ICANN “to continue processing NDC’s .web application,” clearing the way for the delegation of .web. ICANN later posted a preliminary report from this meeting showing that the Board vote on the .web decision was without objection.

Less than 24 hours later, however, Altanovo (formerly Afilias) – a losing bidder whose repeatedly rejected claims already have delayed the delegation of .web for more than six years – dusted off its playbook from 2018 by filing yet another ICANN Cooperative Engagement Process (CEP), beginning the cycle of another independent review of the Board’s decision, which last time cost millions of dollars and resulted in years of delay.

Under ICANN rules, a CEP is intended to be a non-binding process designed to efficiently resolve or narrow disputes before the initiation of an Independent Review Process (IRP). ICANN places further actions on hold while a CEP is pending. It’s an important and worthwhile aspect of the multistakeholder process…when used in good faith.

But that does not appear to be what is happening here. Altanovo and its backers initiated this repeat CEP despite the fact that it lost a fair, ICANN-sponsored auction; lost, in every important respect, the IRP; lost its application for reconsideration of the IRP (which it was sanctioned for filing, and which was determined to be frivolous by the IRP panel); and has now lost before the ICANN Board.

The Board’s decision expressly found that these disputes “have delayed the delegation of .web for more than six years” and already cost each of the parties, including ICANN, “millions of dollars in legal fees.”

Further delay appears to be the only goal of this second CEP – and any follow-on IRP – because no one could conclude in good faith that an IRP panel would find that the thorough process and decision on .web established in the Board’s resolutions and preliminary report violated ICANN’s bylaws. At the end of the day, all that will be accomplished by this second CEP and a second IRP is continued delay, and delay for delay’s sake amounts to an abuse of process that threatens to undermine the multistakeholder processes and the rights of NDC and Verisign.

ICANN will, no doubt, follow its processes for resolving the CEP and any further procedural maneuvers attempted by Altanovo. But, given Altanovo’s track record of losses, delays, and frivolous maneuvering since the 2016 .web auction, a point has been reached when equity demands that this abuse of process not be allowed to thwart NDC’s right, as determined by the Board, to move ahead on its .web application.

The post Will Altanovo’s Maneuvering Continue to Delay .web? appeared first on Verisign Blog.

For Murray Green, working for a company that is a steward of critical internet infrastructure is a mission that he can get behind. Green, a senior engineering manager at Verisign, is a U.S. Army veteran who served during Operation Desert Storm and sees stewardship as a lifelong mission. In both roles, he has stayed focused on the success of the mission and cultivating great teamwork.

Teamwork is something that Laura Street, a software engineer and U.S. Air Force veteran, came to appreciate through her military service. It was then that she learned to appreciate how people from different backgrounds can work together on missions by finding their commonalities.

While military and civilian roles are very different, Verisign appeals to many veterans because of the mission-driven nature of the work we do.

Green and Street are two of the many veterans who have chosen to apply their military experience in a civilian career at Verisign. Both say that the work is not only rewarding to them, but to anyone who depends on Verisign’s commitment in helping to maintain the security, stability, and resiliency of the Domain Name System (DNS) and the internet.

At Verisign, we celebrate Military Appreciation Month by paying tribute to those who have served and recognizing how fortunate we are to work alongside amazing veterans whose contributions to our work provide enormous value.

Introducing Data-Powered Technology

Before joining the military, Murray Green studied electrical engineering but soon realized that his true passion was computer science. Looking for a way to pay for school and explore and excel as a Programmer Analyst, he turned to the U.S. Army.

He served more than four years at the Walter Reed Army Medical Center in Washington as the sole programmer for military personnel, using a proprietary language to maintain a reporting system that supplied data analysis. It was a role that helped him recognize the importance of data to any mission – whether for the U.S. Army or a company like Verisign.

At Walter Reed, he helped usher in the age of client-server computing, which dramatically reduced data processing time. “Around this time, personal computers connected to mini servers were just coming online so, using this new technology, I was able to unload data from the mainframe and bring it down to minicomputers running programs locally, which resulted in tasks being completed without the wait times associated with conventional mainframe computing,” he said. “I was there at the right time.”

His work led him to receive the Meritorious Service Medal, recognizing his expertise in the proprietary programming language that was used to assist in preparation for Operation Desert Storm, the first mobilization of U.S. Army personnel since Vietnam.

In the military, he also came to understand the importance of leadership – “providing purpose, direction, and motivation to accomplish the mission and improve the organization.”

Green has been at Verisign for over 20 years, starting off in the registry side of the business. In that role, he helped maintain the .com/.net top level-domain (TLD) name database, which at the time, held 5 million domain names. Today, he still oversees this database, managing a highly skilled team that has helped provide uninterrupted resolution service for .com and .net for over a quarter of a century.

Sense of Teamwork Leaves a Lasting Impression

Street had been in medical school, looking for a way to pay for her continued education, when she heard about the military’s Health Professional Scholarship Program and turned to the U.S. Air Force.

“I met some terrific people in the military,” she said. “My favorite experiences involved working with people who cared about others and were able to motivate them with positivity.” But it was the sense of teamwork she encountered in the military that left a lasting impression.

“There’s a sense of accountability and concern for others,” she said. “You help one another.”

While working in the Education and Training department, she had been working with a support team to troubleshoot a video that wasn’t loading properly and was impressed with how the developers worked to fix the problem. She immediately took an interest in programming and enrolled in night classes at a local community college. After completing her service in the U.S. Air Force, she went back to school to pursue a bachelor’s degree in computer science.

She’s been at Verisign for two years and, while the job itself is rewarding because it taps into so many of her interests – from Java programming to network protection and packet analysis – it was the chemistry with the team that was most enticing about the role.

“I felt as at-ease as one can possibly feel during a technical interview,” she said. “I got the sense that these were people who I would want to work with.

Street credits the military for teaching her valuable communication and teamwork skills that she continues to apply in her role, which focuses on keeping the .com and .net top-level-domains available around the clock, around the world.

A Unique and Global Mission

Both Green and Street encourage service members to stay focused on the success of their personal missions and the teamwork they learned in the military, and to leverage those skills in the civilian world. Use your service as a selling point and understand that companies value that background more than you think, they said.

“Being proud of the service we provide to others and paying attention to details allows us at Verisign to make a global difference,” Green said. “The veterans on our team bring an incredible skillset that is highly valued here. I know that I’m a part of an incredible team at Verisign.”

Verisign is proud to create career opportunities where veterans can apply their military training. To learn more about our current openings, visit Verisign Careers.

The post Verisign Honors Vets in Technology For Military Appreciation Month appeared first on Verisign Blog.

The Domain Name System (DNS) root zone will soon be getting a new record type, called ZONEMD, to further ensure the security, stability, and resiliency of the global DNS in the face of emerging new approaches to DNS operation. While this change will be unnoticeable for the vast majority of DNS operators (such as registrars, internet service providers, and organizations), it provides a valuable additional layer of cryptographic security to ensure the reliability of root zone data.

In this blog, we’ll discuss these new proposals, as well as ZONEMD. We’ll share deployment plans, how they may affect certain users, and what DNS operators need to be aware of beforehand to ensure little-to-no disruptions.

The Root Server System

The DNS root zone is the starting point for most domain name lookups on the internet. The root zone contains delegations to nearly 1,500 top-level domains, such as .com, .net, .org, and many others. Since its inception in 1984, various organizations known collectively as the Root Server Operators have provided the service for what we now call the Root Server System (RSS). In this system, a myriad of servers respond to approximately 80 billion root zone queries each day.

While the RSS continues to perform this function with a high degree of dependability, there are recent proposals to use the root zone in a slightly different way. These proposals create some efficiencies for DNS operators, but they also introduce new challenges.

New Proposals

In 2020, the Internet Engineering Task Force (IETF) published RFC 8806, titled “Running a Root Server Local to a Resolver.” Along the same lines, in 2021 the Internet Corporation for Assigned Names and Numbers (ICANN) Office of the Chief Technology Officer published OCTO-027, titled “Hyperlocal Root Zone Technical Analysis.” Both proposals share the idea that recursive name servers can receive and load the entire root zone locally and respond to root zone queries directly.

But in a scenario where the entire root zone is made available to millions of recursive name servers, a new question arises: how can consumers of zone data verify that zone content has not been modified before reaching their systems?

One might imagine that DNS Security Extensions (DNSSEC) could help. However, while the root zone is indeed signed with DNSSEC, most of the records in the zone are considered non-authoritative (i.e., all the NS and glue records) and therefore do not have signatures. What about something like a Pretty Good Privacy (PGP) signature on the root zone file? That comes with its own challenge: in PGP, the detached signature is easily separated from the data. For example, there is no way to include a PGP signature over DNS zone transfer, and there is no easy way to know which version of the zone goes with the signature.

Introducing ZONEMD

A solution to this problem comes from RFC 8976. Led by Verisign and titled “Message Digest for DNS Zones” (known colloquially as ZONEMD), this protocol calls for a cryptographic digest of the zone data to be embedded into the zone itself. This ZONEMD record can then be signed and verified by consumers of the zone data. Here’s how it works:

Each time a zone is updated, the publisher calculates the ZONEMD record by sorting and canonicalizing all the records in the zone and providing them as input to a message digest function. Sorting and canonicalization are the same as for DNSSEC. In fact, the ZONEMD calculation can be performed at the same time the zone is signed. Digest calculation necessarily excludes the ZONEMD record itself, so the final step is to update the ZONEMD record and its signatures.

A recipient of a zone that includes a ZONEMD record repeats the same calculation and compares its calculated digest value with the published digest. If the zone is signed, then the recipient can also validate the correctness of the published digest. In this way, recipients can verify the authenticity of zone data before using it.

A number of open-source DNS software products now, or soon will, include support for ZONEMD verification. These include Unbound (version 1.13.2), NSD (version 4.3.4), Knot DNS (version 3.1.0), PowerDNS Recursor (version 4.7.0) and BIND (version 9.19).

Who Is Affected?

Verisign, ICANN, and the Root Server Operators are taking steps to ensure that the addition of the ZONEMD record in no way impacts the ability of the root server system to receive zone updates and to respond to queries. As a result, most internet users are not affected by this change.

Anyone using RFC 8806, or a similar technique to load root zone data into their local resolver, is unlikely to be affected as well. Software products that implement those features should be able to fully process a zone that includes the new record type, especially for reasons described below. Once the record has been added, users can take advantage of ZONEMD verification to ensure root zone data is authentic.

Users most likely to be affected are those that receive root zone data from the internic.net servers (or some other source) and use custom software to parse the zone file. Depending on how such custom software is designed, there is a possibility that it will treat the new ZONEMD record as unexpected and lead to an error condition. Key objectives of this blog post are to raise awareness of this change, provide ample time to address software issues, and minimize the likelihood of disruptions for such users.

Deployment Plan

In 2020, Verisign asked the Root Zone Evolution Review Committee (RZERC) to consider a proposal for adding data protections to the root zone using ZONEMD. In 2021, the RZERC published its recommendations in RZERC003. One of those recommendations was for Verisign and ICANN to develop a deployment plan and make the community aware of the plan’s details. That plan is summarized in the remainder of this blog post.

Phased Rollout

One attribute of a ZONEMD record is the choice of a hash algorithm used to create the digest. RFC 8976 defines two standard hash algorithms – SHA-384 and SHA-512 – and a range of “private-use” algorithms.

Initially, the root zone’s ZONEMD record will have a private-use hash algorithm. This allows us to first include the record in the zone without anyone worrying about the validity of the digest values. Since the hash algorithm is from the private-use range, a consumer of the zone data will not know how to calculate the digest value. A similar technique, known as the “Deliberately Unvalidatable Root Zone,” was utilized when DNSSEC was added to the root zone in 2010.

After a period of more than two months, the ZONEMD record will transition to a standard hash algorithm.

Hash Algorithm

SHA-384 has been selected for the initial implementation for compatibility reasons.

The developers of BIND implemented the ZONEMD protocol based on an early Internet-Draft, some time before it was published as an RFC. Unfortunately, the initial BIND implementation only accepts ZONEMD records with a digest length of 48 bytes (i.e., the SHA-384 length). Since the versions of BIND with this behavior are in widespread use today, use of the SHA-512 hash algorithm would likely lead to problems for many BIND installations, possibly including some Root Server Operators.

Presentation Format

Distribution of the zone between the Root Zone Maintainer and Root Server Operators primarily takes place via the DNS zone transfer protocol. In this protocol, zone data is transmitted in “wire format.”

The root zone is also stored and served as a file on the internic.net FTP and web servers. Here, the zone data is in “presentation format.” The ZONEMD record will appear in these files using its native presentation format. For example:

. 86400 IN ZONEMD 2021101902 1 1 ( 7d016e7badfd8b9edbfb515deebe7a866bf972104fa06fec
e85402cc4ce9b69bd0cbd652cec4956a0f206998bfb34483 )

Some users of zone data received from the FTP and web servers might currently be using software that does not recognize the ZONEMD presentation format. These users might experience some problems when the ZONEMD record first appears. We did consider using a generic record format; however, in consultation with ICANN, we believe that the native format is a better long-term solution.

Schedule

Currently, we are targeting the initial deployment of ZONEMD in the root zone for September 13, 2023. As previously stated, the ZONEMD record will be published first with a private-use hash algorithm number. We are targeting December 6, 2023, as the date to begin using the SHA-384 hash algorithm, at which point the root zone ZONEMD record will become verifiable.

Conclusion

Deploying ZONEMD in the root zone helps to increase the security, stability, and resiliency of the DNS. Soon, recursive name servers that choose to serve root zone data locally will have stronger assurances as to the zone’s validity.

If you’re interested in following the ZONEMD deployment progress, please look for our announcements on the DNS Operations mailing list.

The post Adding ZONEMD Protections to the Root Zone appeared first on Verisign Blog.

Over the past several years, domain name queries – a critical element of internet communication – have quietly become more secure, thanks, in large part, to a little-known set of technologies that are having a global impact. Verisign CTO Dr. Burt Kaliski covered these in a recent Internet Protocol Journal article, and I’m excited to share more about the role Verisign has performed in advancing this work and making one particular technology freely available worldwide.

The Domain Name System (DNS) has long followed a traditional approach of answering queries, where resolvers send a query with the same fully qualified domain name to each name server in a chain of referrals. Then, they generally apply the final answer they receive only to the domain name that was queried for in the original request.

But recently, DNS operators have begun to deploy various “minimization techniques” – techniques aimed at reducing both the quantity and sensitivity of information exchanged between DNS ecosystem components as a means of improving DNS security. Why the shift? As we discussed in a previous blog, it’s all in the interest of bringing the process closer to the “need-to-know” security principle, which emphasizes the importance of sharing only the minimum amount of information required to complete a task or carry out a function. This effort is part of a general, larger movement to reduce the disclosure of sensitive information in our digital world.

As part of Verisign’s commitment to security, stability, and resiliency of the global DNS, the company has worked both to develop qname minimization techniques and to encourage the adoption of DNS minimization techniques in general. We believe strongly in this work since these techniques can reduce the sensitivity of DNS data exchanged between resolvers and both root and TLD servers without adding operational risk to authoritative name server operations.

To help advance this area of technology, in 2015, Verisign announced a royalty-free license to its qname minimization patents in connection with certain Internet Engineering Task Force (IETF) standardization efforts. There’s been a steady increase in support and deployment since that time; as of this writing, roughly 67% of probes were utilizing qname-minimizing resolvers, according to statistics hosted by NLnet Labs. That’s up from just 0.7% in May 2017 – a strong indicator of minimization techniques’ usefulness to the community. At Verisign, we are seeing similar trends with approximately 65% of probes utilizing qname-minimizing resolvers in queries with two labels at .com and .net authoritative name servers, as shown in Figure 1 below.

Kaliski’s article, titled “Minimized DNS Resolution: Into the Penumbra,” explores several specific minimization techniques documented by the IETF, reports on their implementation status, and discusses the effects of their adoption on DNS measurement research. An expanded version of the article can be found on the Verisign website.

This piece is just one of the latest to demonstrate Verisign’s continued investment in research and standards development in the DNS ecosystem. As a company, we’re committed to helping shape the DNS of today and tomorrow, and we recognize this is only possible through ongoing contributions by dedicated members of the internet infrastructure community – including the team here at Verisign.

Read more about Verisign’s contributions to this area:

Query Name Minimization and Authoritative DNS Server Behavior – DNS-OARC Spring ’15 Workshop (presentation)

Minimum Disclosure: What Information Does a Name Server Need to Do Its Job? (blog)

Maximizing Qname Minimization: A New Chapter in DNS Protocol Evolution (blog)

A Balanced DNS Information Protection Strategy: Minimize at Root and TLD, Encrypt When Needed Elsewhere (blog)

Information Protection for the Domain Name System: Encryption and Minimization (blog)

The post Minimized DNS Resolution: Into the Penumbra appeared first on Verisign Blog.

Today, we released the latest issue of The Domain Name Industry Brief, which shows that the fourth quarter of 2022 closed with 350.4 million domain name registrations across all top-level domains (TLDs), an increase of 0.5 million domain name registrations, or 0.1%, compared to the third quarter of 2022.^1,2 Domain name registrations have increased by 8.7 million, or 2.6%, year over year.^1,2

Check out the latest issue of The Domain Name Industry Brief to see domain name stats from the fourth quarter of 2022, including:
• Top 10 Largest TLDs by Number of Reported Domain Names
• Top 10 Largest ccTLDs by Number of Reported Domain Names
• ngTLDs as Percentage of Total TLDs
• Geographical ngTLDs as Percentage of Total Corresponding Geographical TLDs

To see past issues of The Domain Name Industry Brief, please visit https://verisign.com/dnibarchives.

1. All figure(s) exclude domain names in the .tk, .cf, .ga, .gq, and .ml ccTLDs. Quarterly and year-over-year trends have been calculated relative to historical figures that have also been adjusted to exclude these five ccTLDs. For further information, please see the Editor’s Note contained in Vol. 19, Issue 1 of The Domain Name Industry Brief.
2. The generic TLD, ngTLD and ccTLD data cited in the brief: (i) includes ccTLD internationalized domain names, (ii) is an estimate as of the time this brief was developed, and (iii) is subject to change as more complete data is received. Some numbers in the brief may reflect standard rounding.

The post Verisign Domain Name Industry Brief: 350.4 Million Domain Name Registrations in the Fourth Quarter of 2022 appeared first on Verisign Blog.

Every few months, an important ceremony takes place. It’s not splashed all over the news, and it’s not attended by global dignitaries. It goes unnoticed by many, but its effects are felt across the globe. This ceremony helps make the internet more secure for billions of people.

This unique ceremony began in 2010 when Verisign, the Internet Corporation for Assigned Names and Numbers (ICANN), and the U.S. Department of Commerce’s National Telecommunications and Information Administration collaborated – with input from the global internet community – to deploy a technology called Domain Name System Security Extensions (DNSSEC) to the Domain Name System (DNS) root zone in a special ceremony. This wasn’t a one-off occurrence in the history of the DNS, though. Instead, these organizations developed a set of processes, procedures, and schedules that would be repeated for years to come. Today, these recurring ceremonies help ensure that the root zone is properly signed, and as a result, the DNS remains secure, stable, and resilient.

In this blog, we take the opportunity to explain these ceremonies in greater detail and describe the critical role that Verisign is honored to perform.

A Primer on DNSSEC, Key Signing Keys, and Zone Signing Keys

DNSSEC is a series of technical specifications that allow operators to build greater security into the DNS. Because the DNS was not initially designed as a secure system, DNSSEC represented an essential leap forward in securing DNS communications. Deploying DNSSEC allows operators to better protect their users, and it helps to prevent common threats such as “man-in-the-middle” attacks. DNSSEC works by using public key cryptography, which allows zone operators to cryptographically sign their zones. This allows anyone communicating with and validating a signed zone to know that their exchanges are genuine.

The root zone, like most signed zones, uses separate keys for zone signing and for key signing. The Key Signing Key (KSK) is separate from the Zone Signing Key (ZSK). However, unlike most zones, the root zone’s KSK and ZSK are operated by different organizations; ICANN serves as the KSK operator and Verisign as the ZSK operator. These separate roles for DNSSEC align naturally with ICANN as the Root Zone Manager and Verisign as the Root Zone Maintainer.

In practice, the KSK/ZSK split means that the KSK only signs the DNSSEC keys, and the ZSK signs all the other records in the zone. Signing with the KSK happens infrequently – only when the keys change. However, signing with the ZSK happens much more frequently – whenever any of the zone’s other data changes.

DNSSEC and Public Key Cryptography

Something to keep in mind before we go further: remember that DNSSEC utilizes public key cryptography, in which keys have both a private and public component. The private component is used to generate signatures and must be guarded closely. The public component is used to verify signatures and can be shared openly. Good cryptographic hygiene says that these keys should be changed (or “rolled”) periodically.

In DNSSEC, changing a KSK is generally difficult, whereas changing a ZSK is relatively easy. This is especially true for the root zone where a KSK rollover requires all validating recursive name servers to update their copy of the trust anchor. Whereas the first and only KSK rollover to date happened after a period of eight years, ZSK rollovers take place every three months. Not coincidentally, this is also how often root zone key signing ceremonies take place.

Why We Have Ceremonies

The notion of holding a “ceremony” for such an esoteric technical function may seem strange, but this ceremony is very different from what most people are used to. Our common understanding of the word “ceremony” brings to mind an event with speeches and formal attire. But in this case, the meaning refers simply to the formality and ritual aspects of the event.

There are two main reasons for holding key signing ceremonies. One is to bring participants together so that everyone may transparently witness the process. Ceremony participants include ICANN staff, Verisign staff, Trusted Community Representatives (TCRs), and external auditors, plus guests on occasion.

The other important reason, of course, is to generate DNSSEC signatures. Occasionally other activities take place as well, such as generating new keys, retiring equipment, and changing TCRs. In this post, we’ll focus only on the signature generation procedures.

The Key Signing Request

A month or two before each ceremony, Verisign generates a file called the Key Signing Request (KSR). This is an XML document which includes the set of public key records (both KSK and ZSK) to be signed and then used during the next calendar quarter. The KSR is securely transmitted from Verisign to the Internet Assigned Numbers Authority (IANA), which is a function of ICANN that performs root zone management. IANA securely stores the KSR until it is needed for the upcoming key signing ceremony.

Each quarter is divided into nine 10-day “slots” (for some quarters, the last slot is extended by a day or two) and the XML file contains nine key “bundles” to be signed. Each bundle, or slot, has a signature inception and expiration timestamp, such that they overlap by at least five days. The first and last slots in each quarter are used to perform ZSK rollovers. During these slots we publish two ZSKs and one KSK in the root zone.

At the Ceremony: Details Matter

The root zone KSK private component is held inside secure Hardware Security Modules (HSMs). These HSMs are stored inside locked safes, which in turn are kept inside locked rooms. At a key signing ceremony, the HSMs are taken out of their safes and activated for use. This all occurs according to a pre-defined script with many detailed steps, as shown in the figure below.

Also stored inside the safe is a laptop computer, its operating system on non-writable media (i.e., DVD), and a set of credentials for the TCRs, stored on smart cards and locked inside individual safe deposit boxes. Once all the necessary items are removed from the safes, the equipment can be turned on and activated.

The laptop computer is booted from its operating system DVD and the HSM is connected via Ethernet for data transfer and serial port for console logging. The TCR credentials are used to activate the HSM. Once activated, a USB thumb drive containing the KSR file is connected to the laptop and the signing program is started.

The signing program reads the KSR, validates it, and then displays information about the keys about to be signed. This includes the signature inception and expiration timestamps, and the ZSK key tag values.

Validate and Process KSR /media/KSR/KSK46/ksr-root-2022-q4-0.xml...
#  Inception           Expiration           ZSK Tags      KSK Tag(CKA_LABEL)
1  2022-10-01T00:00:00 2022-10-22T00:00:00  18733,20826
2  2022-10-11T00:00:00 2022-11-01T00:00:00  18733
3  2022-10-21T00:00:00 2022-11-11T00:00:00  18733
4  2022-10-31T00:00:00 2022-11-21T00:00:00  18733
5  2022-11-10T00:00:00 2022-12-01T00:00:00  18733
6  2022-11-20T00:00:00 2022-12-11T00:00:00  18733
7  2022-11-30T00:00:00 2022-12-21T00:00:00  18733
8  2022-12-10T00:00:00 2022-12-31T00:00:00  18733
9  2022-12-20T00:00:00 2023-01-10T00:00:00  00951,18733
...PASSED.

It also displays an SHA256 hash of the KSR file and a corresponding “PGP (Pretty Good Privacy) Word List.” The PGP Word List is a convenient and efficient way of verbally expressing hexadecimal values:

SHA256 hash of KSR:
ADCE9749F3DE4057AB680F2719B24A32B077DACA0F213AD2FB8223D5E8E7CDEC
>> ringbolt sardonic preshrunk dinosaur upset telephone crackdown Eskimo rhythm gravity artist celebrate bedlamp pioneer dogsled component ruffled inception surmount revenue artist Camelot cleanup sensation watchword Istanbul blowtorch specialist trauma truncated spindle unicorn <<

At this point, a Verisign representative comes forward to verify the KSR. The following actions then take place:

1. The representative’s identity and proof-of-employment are verified.
2. They verbalize the PGP Word List based on the KSR sent from Verisign.
3. TCRs and other ceremony participants compare the spoken list of words to those displayed on the screen.
4. When the checksum is confirmed to match, the ceremony administrator instructs the program to proceed with generating the signatures.

The signing program outputs a new XML document, called the Signed Key Response (SKR). This document contains signatures over the DNSKEY resource record sets in each of the nine slots. The SKR is saved to a USB thumb drive and given to a member of the Root Zone KSK Operations Security team. Usually sometime the next day, IANA securely transmits the SKR back to Verisign. Following several automatic and manual verification steps, the signature data is imported into Verisign’s root zone management system for use at the appropriate times in the next calendar quarter.

Why We Do It

Keeping the internet’s DNS secure, stable, and resilient is a crucial aspect of Verisign’s role as the Root Zone Maintainer. We are honored to participate in the key signing ceremonies with ICANN and the TCRs and do our part to help the DNS operate as it should.

For more information on root key signing ceremonies, visit the IANA website. Visitors can watch video recordings of previous ceremonies and even sign up to witness the next ceremony live. It’s a great resource, and a unique opportunity to take part in a process that helps keep the internet safe for all.

The post Verisign’s Role in Securing the DNS Through Key Signing Ceremonies appeared first on Verisign Blog.