Warren Kumari
Warren Kumari is Director of Internet Standards.
He currently serves as an Internet Engineering Task Force (IETF) Operations and Management Area Director. He has previously chaired the CAPPORT, DPRIVE,DANE, OpsAWG and OpSec Working Groups in the IETF, and also co-chairs the Internet Engineering and Planning Group (IEPG). He is also active in ICANN, serving on the Security and Stability Advisory Committee (SSAC), Root Server System Advisory Committee (RSSAC) and also served as the IAB appointed representative to the ICANN Technical Liaison Group.
Authored Publications
Sort By
SAC133 - SSAC Comments on Proposed Root KSK Algorithm Rollover
Wes Hardaker
Internet Corporation for Assigned Names and Numbers (ICANN), ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2026), pp. 9
Preview abstract
The SSAC supports the transition from RSA with SHA-256 (Algorithm 8) to ECDSA P-256
with SHA-256 (Algorithm 13) as the cryptographic algorithm for the RootKSK. The root zone
has relied on RSA-based algorithms since DNSSEC signing began in 2010. The algorithm did
not change during the first KSK rollover in 2018 or during the second rollover currently
underway and scheduled to complete in October 2026. Establishing a clear and predictable
process for algorithm transitions is essential to the long-term security of the root zone, and the
SSAC observes that the proposal addresses the Recommendation 23 of the SSR2 Review
accordingly.
The SSAC notes that the proposal builds upon the Root Zone DNSSEC Algorithm Rollover
Study published by ICANN in May 2024, which assessed resolver and authoritative server
support for alternative algorithms, analyzed rollover methodologies, and evaluated operational
risks. The SSAC finds that the proposal implements the study’s recommendations. The SSAC also notes that this proposal is consistent with the SSAC’s prior work on DNSSEC key rollover,
including SAC063, SAC073, SAC102, and SAC108.
The SSAC encourages ICANN to proceed with this rollover. Specific comments on the
proposal’s methodology, timeline, and operational readiness follow
View details
SAC132 - The Domain Name System Runs on Free and Open Source Software (FOSS)
Internet Corporation for Assigned Names and Numbers (ICANN), ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2025), pp. 47
Preview abstract
The Domain Name System (DNS) is a globally distributed, hierarchical, and decentralized
system whose information underpins nearly every online interaction. Its principal purpose is to
map user-friendly domain names to the computer-friendly IP addresses required to locate
resources on the network. Whether browsing the web, sending an email, or using a mobile
application, every online connection relies on information that originates from and is structured
by the DNS.
This report’s core finding is that the DNS is built and sustained on Free and Open Source
Software (FOSS). This is not a niche practice, but the dominant reality. FOSS is the norm for the
most fundamental components of DNS infrastructure. For example, at least nine of the 12
independent organizations that operate the Internet’s root server system (RSS) exclusively use
FOSS implementations, and nine of the 10 largest service providers for top-level domains
(TLDs) use FOSS. This dominance stems from the inherent strengths of the FOSS development
model, which combines economic efficiency and low-friction adoption with the transparency,
collaborative security, and operational resilience essential for critical infrastructure.
Although the FOSS development model is fundamentally different from that of proprietary
software, FOSS is not inherently more or less secure. The security of any software project is
determined by the quality of its development and maintenance processes, not the visibility of its
source code. Unlike commercial software, FOSS is a collaborative, global effort built upon four
essential freedoms: to use, study, share, and change. This ecosystem depends on a global
network of maintainers and contributors who are often unpaid volunteers. While many are
unpaid volunteers, the DNS space is unique in also relying on a handful of long-lived
maintenance organizations. This creates a model based on community collaboration rather than the commercial contracts that define a traditional software supply chain, which introduces unique risks related to financial sustainability for the maintenance organizations and maintainer burnout for volunteers.
These unique characteristics mean that regulatory frameworks designed for proprietary software may not be well-suited for FOSS and therefore could have severe unintended consequences to the stability of critical Internet infrastructure. To navigate these complexities and foster a secure digital ecosystem, the Security and Stability Advisory Committee (SSAC) provides the following guidelines for policymakers:
• Acknowledge the Critical Role of FOSS: Policymakers should explicitly acknowledge
in any relevant legislation or regulation that critical Internet infrastructure relies on
FOSS, and that its use is a strength to be preserved.
• Consult the FOSS Community: Developing legislation and regulations should be
informed by consulting all parts of the FOSS ecosystem, from individual maintainers to
non-profits and corporations.
• Make Use of the Contemporary Cases in FOSS Regulation: Policymakers can
reference recent case studies in the report of contemporary approaches that incorporate
the unique characteristics of the FOSS development model.
• Incentivize FOSS Sustainability: Encourage public and private sector contributions to
critical FOSS projects as a form of investment in a shared public good.
• Address Systemic Risks Collectively: Foster and fund collaborative, ecosystem-wide
solutions to mitigate risks from shared dependencies instead of burdening individual
maintainers.
View details
SAC127 - DNS Blocking Revisited
Internet Corporation for Assigned Names and Numbers (ICANN), ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2025), pp. 42
Preview abstract
The Domain Name System (DNS) translates human-readable domain names to Internet Protocol (IP) addresses that are used by computers to communicate with each other on the Internet. DNS blocking is a method for restricting access to information or services on the Internet by interfering with the normal process of responding to DNS queries about domain names or IP addresses. This is done either by denying that a name or address exists or by providing false information about it.
Blocking is one of several approaches to restricting or regulating access to Internet information. Often, DNS blocking is employed because it is relatively easy to implement, but it has limitations and potential side effects.
This report focuses on the technical means by which DNS blocking can be accomplished, and the effects—both intended and unintended—of its use in different contexts. The aim of this report is to advise the Internet community, and especially policymakers and government officials, of the implications and consequences of using DNS blocking to control access to resources on the Internet.
DNS blocking can be accomplished by changing the behavior of a DNS server so that it responds in a way that is different from normal, e.g. as was intended by the administrator of the domain name. When an end user wishes to connect to a web site or other service, a recursive resolver translates the domain name of that site or service into an IP address. DNS blocking via recursive resolvers modifies or blocks this translation.
DNS blocking is effective only to the extent that users rely on the DNS infrastructure where the blocking is implemented. Blocking can be bypassed by various methods, such as using an alternative DNS resolver to avoid a resolver where a block has been implemented or using a Virtual Private Network (VPN). The effectiveness of DNS blocking is often a matter of degree. It is crucial to understand that DNS blocking does not remove or alter the underlying content - it merely attempts to prevent access through the most common and convenient pathway. The content itself typically remains available at the original IP address or through alternative domain names or protocols, meaning that determined users can still reach it using other means. DNS blocking can have serious side effects. A block may affect users outside the jurisdiction of the party doing the blocking. Users may not know that a block is in place, and can interpret it as a site outage or other error, encouraging potentially insecure behavior to "fix" it. A block may affect domains that provide services for other domains, causing collateral damage beyond the intended scope of the block.
Governments use DNS blocking for complex purposes, and these can be controversial. One motivation is public safety, such as blocking domains that a government decides enable illegal activities or incite violence. Some governments use DNS blocking as a tool for censorship. The
SSAC notes that whether an action constitutes censorship, or the legality of any specific case of DNS blocking, will depend upon local laws (which vary widely across the globe), and can involve personal convictions, about which people may vary in good faith. For these reasons, the SSAC does not make statements in this report about the propriety of specific cases of DNS blocking–such discussions are more suited for political fora. The merits or advisability of governmental or other attempts to control access to resources on the Internet are beyond the scope of this report.
View details
RFC 9774 - Deprecation of AS_SET and AS_CONFED_SET in BGP
RFC Editor, RFC Editor (2025), pp. 13
Preview abstract
BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol (BGP). This document advances that recommendation to a standards requirement in BGP; it prohibits the use of the AS_SET and AS_CONFED_SET path segment types in the AS_PATH. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a BGP route clearer. This will also simplify the design, implementation, and deployment of various BGP security mechanisms. This document updates RFC 4271 by deprecating the origination of BGP routes with AS_SET (Type 1 AS_PATH segment) and updates RFC 5065 by deprecating the origination of BGP routes with AS_CONFED_SET (Type 4 AS_PATH segment). Finally, it obsoletes RFC 6472.
View details
SAC130 - SSAC Comments on Name Collision Guidelines in the Proposed Language for the Draft Next Round Applicant Guidebook
Internet Corporation for Assigned Names and Numbers (ICANN), ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2025), pp. 12
Preview abstract
In this document, the SSAC focuses on a specific name collision scenario: when a new gTLD
applicant applies for a string already in use in an alternative, non-DNS naming system (e.g.,
blockchain-based naming systems). Several alternative naming systems increasingly utilize the
syntax of DNS names.Without explicit guidelines and proactive management, these alternative
naming systems may create collisions with new gTLDs delegated through the New gTLD
Program: Next Round.
The SSAC believes these collisions could cause the following problems:
● Security vulnerabilities stemming from misdirected traffic or unexpected system
interactions.
● Operational instability for network operators and end-users.
● User confusion due to unpredictable resolution behavior.
The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address
these (previously identified) risks, so that the final AGB fully reflects this guidance.
View details
Preview abstract
This document retires the use of GOST R 34.10-2001 (mnemonic "ECC- GOST") and GOST R 34.11-94 within DNSSEC.
RFC 5933 (Historic) defined the use of GOST R 34.10-2001 and GOST R 34.11-94 algorithms with DNS Security Extensions (DNSSEC). This document updates RFC 5933 by deprecating the use of ECC-GOST.
View details
SAC131 - SSAC Comments on Functional Model for Root Server System Governance
Internet Corporation for Assigned Names and Numbers (ICANN), ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2025), pp. 6
Preview abstract
The SSAC wishes to explicitly acknowledge the crucial role the Root Server Operators (RSOs)
have performed over the years. Their steadfast stewardship and operational excellence have been critical to the global stability of the DNS. This architecture features:
● Independence at many different levels and dimensions of technology and operations.
● Resilient coverage throughout the world.
● Protocol and technology (e.g., anycast) that have evolved with the needs of the
community.
● An exemplary uptime record.
The SSAC supports the proposed Functional Model as a structural foundation for coordination
and decision-making to support future RSS governance.
The proposed Functional Model needs further specificity on several important issues::
● Clearly articulated governance principles that provide guardrails for decision-making and
evolution of the governance structure.
● A structured, staged implementation roadmap that balances operational continuity with
the need for incremental governance maturity.
● The emphasis on inclusivity, transparency, and performance accountability across all
phases of the governance structure.
● The recognition of the importance of diverse stakeholder participation and liaison
relationships to ensure broad technical and policy alignment.
The SSAC also notes the identification of funding stability for RSOs and their operations as an
essential consideration. The SSAC supports and encourages continued dialogue among the
community to explore sustainable funding approaches that safeguard long-term operational
stability, reduce dependency risks, and ensure the RSS remains secure, reliable, and resilient.
View details
SAC128 - SSAC Comments on Draft Governance Document for the Recognition, Maintenance, and Derecognition of RIRs
Internet Corporation for Assigned Names and Numbers (ICANN), ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2025), pp. 5
Preview abstract
The SSAC supports the overarching goals of the RIR Governance Document to establish clear
rules and criteria for the recognition of new RIRs, the ongoing operational obligations of existing RIRs, and the processes for derecognition. The SSAC recognizes this document as a significant advancement over the existing Internet Coordination Policy 2 (ICP-2) and we commend the ASO AC for undertaking this important work to ensure the long-term security and stability of the Internet Numbers Registry System. In this report, the SSAC provides both general and specific comments intended to further strengthen the RIR Governance Document and enhance its practical applicability and robustness.
View details
Preview abstract
The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support.
This document replaces and obsoletes RFC 8624 and moves the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from RFC 8624 to the IANA DNSSEC algorithm registries. This is done to allow the list of requirements to be more easily updated and referenced. Extensions to these registries can be made in future RFCs. This document also updates RFC 9157 and incorporates the revised IANA DNSSEC considerations from that RFC.
View details
Preview abstract
This document deprecates the use of the RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms for the creation of DNS Public Key (DNSKEY) and Resource Record Signature (RRSIG) records.
It updates RFCs 4034 and 5155 as it deprecates the use of these algorithms.
View details
