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
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
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
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
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
RFC 8110 describes Opportunistic Wireless Encryption (OWE), a mode that allows unauthenticated clients to connect to a network using encrypted traffic. This document transfers the ongoing maintenance and further development of the protocol to the IEEE 802.11 Working Group.
This document updates RFC 8110 by noting that future work on the protocol described therein will occur in the IEEE 802.11 Working Group.
View details
RFC 9632 - Finding and Using Geofeed Data
RFC Editor, RFC Editor (2024), pp. 23
Preview abstract
This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to geofeed comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the geofeed data files. This document obsoletes RFC 9092.
View details
SAC124 - SSAC Advice on Name Collision Analysis
Internet Corporation for Assigned Names and Numbers (ICANN), ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2024), pp. 15
Preview abstract
In this document the Security and Stability Advisory Committee (SSAC) provides its analysis of
the findings and recommendations presented within the Name Collision Analysis Project
(NCAP) Study Two and the proposed Name Collision Risk Assessment Framework. The SSAC
also provides additional commentary on several aspects of the NCAP Study Two Report and
makes recommendations to the ICANN Board.
View details
SAC125 - SSAC Report on Registrar Nameserver Management
Gautam Akiwate
Tim April
kc claffy
Internet Corporation for Assigned Names and Numbers (ICANN), ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2024), pp. 56
Preview abstract
During domain registration, a minimum of two nameservers are typically required, and this
remains a requirement for any future updates to the domain. Often, domains are delegated to
nameservers that are subordinate to some other domains, creating inter-domain dependencies.
This network of dependencies creates a scenario where the functionality of a domain depends
on the operational status of another domain. This setup lacks contractual or procedural
safeguards against disruption or misuse, especially when the nameserver parent domain expires.
Most registries forbid deleting an expired domain if other domains depend on it for name
resolution. These constraints aim to prevent disruptions in DNS resolution for the dependent
domains. However, this also means that the expired domain remains in a liminal state, neither
fully operational nor completely removed. When registrars cannot delete expired domains with
dependents, they are forced to bear the burden of sponsoring the domain without remuneration
from the registrant. A peer-reviewed study, "Risky BIZness: Risks derived from Registrar Name
Management," observed that some registrars have found and utilized a loophole to these
constraints by renaming the host objects that are subordinate to the expiring domain.1 Once
renamed, the host objects are what Akiwate et al.—and subsequently the SSAC—refers to as
sacrificial nameservers.
This report focuses on a specific type of sacrificial nameserver where the parent domains of the renamed host objects are considered to be unsafe because they are registrable. Registrable
parent domains of sacrificial nameservers introduce a new attack surface for domain resolution
hijacking, as malicious actors can exploit unsafe sacrificial nameservers to gain unauthorized
control over the dependent domains, leading to manipulation or disruption. Unlike traditional
domain hijacking techniques that exploit compromised account credentials or manipulate the
resolution protocol, this report focuses on this unforeseen risk arising from a longstanding
practice employed by some registrars.
In this report, the SSAC explores potential solutions to remediate exposed domains and prevent
the creation of new unsafe sacrificial nameservers. The SSAC examines each proposed solution for its feasibility, effectiveness, and potential to reduce the attack surface without introducing undue complexity or new vulnerabilities into the DNS ecosystem.
View details
SAC126 - DNSSEC Delegation Signer (DS) Record Automation
Internet Corporation for Assigned Names and Numbers (ICANN), ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2024), pp. 39
Preview abstract
The deployment of Domain Name System (DNS) Security Extensions (DNSSEC) has been
hindered by a number of obstacles. This report focuses on one: the management of Delegation
Signer (DS) records, which connect a child zone’s DNSSEC public key and signatures to the
chain of trust provided by its parent zone (e.g., a zone corresponding to a top-level domain).
DNSSEC is not simply enabled by signing a delegated domain’s DNS zone with DNSSEC
signatures. It is also necessary to configure (and later maintain) appropriate DS records, which
involves coordinated actions by the DNS operator, registrant, registrar, and registry.
In the case where the domain’s DNS service is operated by the registrar, this process can be
reduced to a simple internal operation by the registrar. If the functions are separated, this is not
possible. This report is therefore focused on when the domain’s DNS service is not operated by
the registrar, but by a third-party DNS operator.
In such a scenario, current practice holds the registrant responsible for coordinating DS
maintenance. The registrant (or someone appointed by them) needs to first obtain DNSSEC
public key parameters from the DNS operator, and convey these parameters to the registrar
(potentially via a reseller). The registrar will then need to relay these DNSSEC public key
parameters to the registry, who will use them to create and publish the DS record in the parent
zone. This process often involves idiosyncratic interfaces for each combination of DNS operator
and registrar, requiring a level of engagement and time investment, awareness, and
understanding that often do not match with what the registrant knows or expects. The complexity of the process further introduces opportunity for error.
This can be alleviated by employing automation for the data exchanges required for DS
maintenance so that, when the domain’s DNS service is operated by a third party, registries or
registrars can, without human involvement, obtain all information needed for keeping DS records up to date. Various approaches to achieve this are possible, such as a scheme where the registry or registrar actively contacts the Child DNS operator, or vice versa. The different approaches come with different challenges with respect to authentication, timing, and efficiency.
The IETF has standardized specifications around the first approach, where the parent pulls
information from the Child DNS operator, and operational experience has been gained over
recent years. However, some standardization gaps remain (such as to improve efficiency and
error handling). In addition, the industry could benefit from further development of best practices in deploying the technology.
The SSAC believes that automated DS maintenance should be a goal for the domain name
industry. To make this a reality, the SSAC makes several recommendations with the goal to spur
industry players and ICANN towards an industry best practice for DNSSEC DS automation.
View details
