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
Google Publications
Other Publications
Sort By
SAC122 - SSAC Report on Urgent Requests in the gTLD Registration Data Policy
Internet Corporation for Assigned Names and Numbers (ICANN) , vol. ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2023), pp. 14
Preview abstract
This paper examines the process that led to the proposed language for Urgent Requests and
asserts the following questions should be asked if the same or similar requirements for
processing special requests are pursued in the future.
● What is known about the need for special requests? Is there documentation of the
frequency, urgency, source and outcomes of requests of this type?
● Is the rationale for creating a separate process for these special requests fully specified,
well defined, and accepted by all parties?
● Is the proposed special process fit for purpose? (i.e., Will the resulting policy or
implementation accomplish its stated purpose?)
This paper concludes with three recommendations. The first recommendation adds additional
structure so that Urgent Requests will be handled in an appropriately expedited fashion. The
second recommendation requests that the response time policy for Urgent Requests be fit for
purpose. Finally, the third recommendation requests ICANN org begin gathering data on Urgent
Requests and make it available to the community to inform future policy making efforts.
View details
SAC123 - SSAC Report on the Evolution of Internet Name Resolution
Internet Corporation for Assigned Names and Numbers (ICANN) , vol. ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2023), pp. 36
Preview abstract
New technologies are changing how name resolution happens on the Internet. The DNS remains the prominent, or default, naming system for the Internet, but alternative naming systems are in use as well. This is nothing particularly new, as there have always been naming systems besides the DNS in use throughout the Internet’s history. These alternative naming systems use the same syntax as the DNS, dot-separated labels. There are many motivations for copying this syntax, but the primary reason is because designers of these alternative naming systems wish to benefit from the existence of software applications built to receive DNS names as input.
This has the potential to create situations where the same name exists in DNS and in an
alternative system, potentially causing name collisions. However, there is only one domain
namespace and its referential integrity is important for Internet users and for the stability and
security of Internet names. Thus, as alternative naming systems increase in popularity their use
threatens to increase ambiguity in the shared single domain namespace. This increased ambiguity in Internet naming threatens to undermine the trust that users have in Internet identifiers and the services that rely on them.
Additionally, names are becoming less visible to Internet end users, yet they remain vital to the
security and stability of Internet infrastructure. Technologies such as QR codes and URL
shorteners offer great utility to Internet users while also obscuring the underlying domain names used and creating new opportunities for malicious behavior. Meanwhile, QR codes and URL shorteners use domain names to access the Internet resource, even if the human user does not see it.
These are the two main trends that the SSAC identifies in this report. The same name can resolve in different ways (ambiguous name resolution), and names of service endpoints are less visible (names are less conspicuous to end users). It is the combination of these two trends that fundamentally threatens to undermine confidence in services on the Internet.
View details
Preview abstract
This document reserves a Top-Level Domain (TLD) label "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers creating alternative namespaces.
View details
SAC121 - SSAC Briefing on Routing Security
Tim April
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2022), pp. 36
Preview abstract
Like all other Internet applications, the Domain Name System (DNS) depends on the Internet’s
routing system, which controls the data paths across the Internet’s more than 70,000
autonomously managed networks. A longstanding problem with the routing system is that its key protocol, the border gateway protocol (BGP), does not protect against incorrect routing
information. BGP was designed in the late 1980’s and early 1990’s when the Internet consisted
of only a few hundred networks that all trusted one another. As the Internet grew and the number of networks increased, the number of routing incidents increased and this implicit
trustworthiness waned. The routing system today is subject to a continuous stream of routing
anomalies that affect its integrity and that sometimes cause large DNS outages. For example, in April of 2018 attackers were able to “hijack” routes to Amazon’s Route53 DNS services, which
resulted in DNS traffic for domains hosted on this service ending up at a different destination
network where it was served by malicious DNS servers.
In this report, the SSAC discusses events like these and what impact similar incidents can have
on the DNS, surveys the pros and cons of various solutions, and discusses future security
extensions of the routing system (e.g., path validation). The main focus of this report is on the
security and stability implications for the DNS, although most of it also applies to other types of
Internet applications (e.g., email, web, media streaming).
This report provides a tutorial-style discussion accessible to non-technical members of the
ICANN community and elsewhere (e.g., policy makers and legal experts). It does not contain
any recommendations to the ICANN Board. Because this report is intended to be understandable to a non-technical audience, it sometimes simplifies technical details that are not relevant to the discussion.
View details
SAC118 - SSAC Comments on Initial Report of the EPDP on the Temporary Specification for gTLD Registration Data
Steve Crocker
Tara Whalen
Ben Butler
Greg Aaron
Benedict Addis
James Galvin
Robert Guerra
Julie Hammer
Merike Käo
John Levine
Danny McPherson
Rod Rasmussen
Mark Seiden
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, Internet Corporation for Assigned Names and Numbers (ICANN) (2021), pp. 11
Preview abstract
In this document the SSAC presents both general comments about the overall Expedited Policy
Development Process and specific comments on individual recommendations in the EPDP 2A
Initial Report.
View details
RFC 9092 - Finding and Using Geofeed Data
Randy Bush
Massimo Candela
Russ Housley
IETF Request For Comments, RFC Editor (2021), pp. 21
Preview abstract
This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed data comma-separated values (CSV) files and describes an optional scheme that uses the Routing Public Key Infrastructure to authenticate the geofeed data CSV files.
View details
RSSAC056 - RSSAC Advisory on Rogue DNS Root Server Operators
Ken Renard
Abdulkarim Oloyede
Barbara Schleckser
Brad Verd
Di Ma
Duane Wessels
Fred Baker
Hiro Hotta
Jaap Akkerhuis
Jeff Osborn
Kazunori Fujiwara
Kevin Wright
Mallory Knodel
Marc Blanchet
Nicolas Antoniello
Paul Hoffman
Paul Muchene
Peter DeVries
Russ Mundy
Shinta Sato
Wes Hardaker
Yazid Akanho
ICANN Root Server System Advisory Committee (RSSAC) Reports and Advisories, Internet Corporation for Assigned Names and Numbers (ICANN) (2021), pp. 8
Preview abstract
In this report, the ICANN Root Server System Advisory Committee (RSSAC) examines both measurable and subjective activities of a root server operator (RSO) that could be considered rogue to inform future Root Server System (RSS) governance bodies. Future RSS governance bodies may use this document to develop a more complete definition of rogue RSO actions and will ultimately be the authority in determining subjective factors such as intent, when judging the actions of a RSO. The audience of this report is the Board of Directors of the Internet Corporation for Assigned Names and Numbers (ICANN), future root server system governance bodies, and, more broadly, the Internet community
View details
RFC 8976 - Message Digest for DNS Zones
Duane Wessels
Piet Barber
Matt Weinberg
Wes Hardaker
IETF Request For Comments, RFC Editor (2021), pp. 31
Preview abstract
This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes.
ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets (DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications.
As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones.
View details
SAC115 - SSAC Report on an Interoperable Approach to Addressing Abuse Handling in the DNS
Greg Aaron
Benedict Addis
Lyman Chapin
kc Claffy
John Levine
Mark Seiden
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, vol. SSAC115 (2021), pp. 39
Preview abstract
There are many ways to define the term “DNS Abuse” including, abuse of the protocol itself,
abuse of the DNS infrastructure, using the DNS as a supporting service for some other abuse,
and the use of domain names themselves in an abusive manner. In this report, the SSAC focuses
on cases where domain names themselves are used in an abusive manner. These are often
colloquially referred to within the ICANN community as “technical abuses”, which generally
refer to abuses spelled out in ICANN’s registry agreements in Specification 11.3 (b) and that have been the focus of many community discussions from 2018-2020.
In general, the term “DNS abuse” in this report refers to the use of domain names, or the DNS system, to perpetuate abusive activities. Abuse on the Internet continues to victimize millions annually,
reducing trust in the Internet, including the DNS, as a place to conduct commercial and non-commercial
activities. This erosion of trust negatively impacts all parties in the Internet ecosystem, from endusers to infrastructure service providers.
In this report, the SSAC proposes a general framework of best practices and processes to
streamline reporting DNS abuse and abuse on the Internet in general. This effort is focused on
determining approaches and methodologies that could ultimately reduce the severity and
duration of victimization for end-users. This report focuses on one specific area of the DNS
abuse lifecycle, namely abuse handling. Other topics in the space, including, but not limited to,
prevention, mitigation methods, and education may be explored in future SSAC work. This
report is intended to be of benefit to the victims of DNS abuse, reporters of DNS abuse, and to
those responsible for identifying and remediating DNS abuse.
View details
SAC114 - SSAC Comments on the GNSO New gTLD Subsequent Procedures Draft Final Report
Lyman Chapin
KC Claffy
James Galvin
Julie Hammer
Geoff Huston
Merike Kaeo
Barry Leiba
Ram Mohan
Rod Rasmussen
Suzanne Woolf
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2021), pp. 31
Preview abstract
The SSAC makes the following comments and recommendations. For the full and
official recommendations see Section 4 of this publication.
● First, the SSAC believes that the introduction of more gTLDs to the root namespace is
not consistent with ICANN’s mission and commitment to keep the Internet secure, stable,
and interoperable. The fundamental question from the SSAC’s security and stability
perspective is whether adding more generic top-level domains (gTLDs) to the root
namespace should remain a primary response to furthering the overall objectives of
ICANN, namely “keeping the Internet secure, stable and interoperable. [ICANN]
promotes competition and develops policy on the Internet's unique identifiers.”2 This
comment is not a criticism of the Final Report or the community effort, but the SSAC
thinks now is a good time for the ICANN Board to address this question.
The SSAC recommends that the ICANN Board initiate a fundamental review to
determine whether continuing to increase the number of gTLDs is consistent with
ICANN’s strategic objective to “evolve the unique identifier systems in coordination and
collaboration with relevant parties to continue to serve the needs of the global Internet
user base.”3 This review should be considered an input towards updating ICANN’s
strategic goals in conjunction with implementing the CCT Review Team’s
recommendations (see Recommendation 1).
● Second, given a general intent to proceed with this program in any case, there is a clear
need to add greater levels of not only process oversight, but also a systemic consideration
of the program’s impact, attendant risks and appropriate mitigations to the DNS itself.
The systemic considerations would include addressing, monitoring and mitigating
impacts on the entire DNS resolution chain (e.g., root servers, DNS recursive resolver
performance) and services that provide and/or are dependent upon it.
In addition, numerous items relating to risks, outcomes, and impacts of increasing the
gTLD namespace need to be measured and analyzed to better understand some of the
fundamental questions considered by the Working Group as well as areas it did not
explore. The SSAC agrees with the measurements proposed by the Working Group
Recommendations 7.1 - 7.5 and suggests additional goals and measurements.
The SSAC recommends that, as part of the process for creating new gTLDs, ICANN
develop and adopt a protocol for measuring progress against stated goals of the program
and thresholds, which if crossed, may require mitigation actions. Such measurements and
actions should consider the entirety of the DNS ecosystem (see Recommendation 2).
● Third, on the issue of DNS abuse, while the SSAC agrees that a holistic approach to DNS
abuse issues has merit, we note that security threats and attendant abuse of the DNS
remain a constant and rapidly evolving challenge, and that ICANN recognizes “Domain
name abuse continues to grow” as a Strategic Risk to the achievement of its Strategic
Objectives. Waiting until efforts to mitigate DNS abuse can be equally applied to all
existing and new gTLDs effectively cedes the ground to malicious actors who can depend
upon a long policy development process to hinder meaningful anti-abuse measures.
The SSAC recommends that the ICANN Board, prior to launching the next round of new
gTLDs, commission a study of the causes of, responses to, and best practices for the
mitigation of the domain name abuse that proliferates in the new gTLDs from the 2012
round. This activity should be done in conjunction with implementing the CCT Review
Team’s relevant recommendations. The best practices should be incorporated into
enforced requirements, as appropriate, for at least all future rounds (see Recommendation
3).
View details
SAC117 - Report on Root Service Early Warning Systems
Joe Abley
Jaap Akkerhuis
Tim April
Patrik Fältström
James Galvin
Julie Hammer
Geoff Huston
Russ Mundy
Rod Rasmussen
Matthew Thomas
Suzanne Woolf
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, Internet Corporation for Assigned Names and Numbers (ICANN) (2021), pp. 22
Preview abstract
The concept of an early warning system for the root zone comes originally from the Root Scaling Study Team and TNO Reports, both published in 2009. Since then the concept has evolved away from an original intention of modelling the potential impact on the operation of the root service with the addition of
internationalized domain names (IDNs), IPv6, and new gTLDs to the root zone into a concept
that is intended to provide feedback about the operational stability of the root service as more
gTLDs are added to the root zone.
In reviewing these publications, the SSAC came to the conclusion that an early warning system
for the root zone is currently infeasible, as was also concluded by OCTO-15. The root zone
system is highly complex, and our current understanding of it does not allow us to predict
imminent failure within its conventional and conservative operational parameters. This however,
should not take away from efforts to better understand and gather data on the root server system,
which root server operators are collecting, as described in RSSAC002 and RSSAC047.
View details
RFC 9119 - Multicast Considerations over IEEE 802 Wireless Media
Charles E. Perkins
Mike McBride
Dorothy Stanley
Juan Carlos Zúñiga
IETF Request For Comments, RFC Editor (2021), pp. 22
Preview abstract
Well-known issues with multicast have prevented the deployment of multicast in 802.11 (Wi-Fi)
and other local-area wireless environments. This document describes the known limitations of
wireless (primarily 802.11) Layer 2 multicast. Also described are certain multicast enhancement
features that have been specified by the IETF and by IEEE 802 for wireless media, as well as some
operational choices that can be made to improve the performance of the network. Finally, some
recommendations are provided about the usage and combination of these features and
operational choices.
View details
RFC 9098 - Operational Implications of IPv6 Packets with Extension Headers
Fernando Gont
Nick Hilliard
Gert Doering
Geoff Huston
Will (Shucheng) Liu
IETF Request For Comments, RFC Editor (2021), pp. 17
Preview abstract
This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension
headers are often dropped in the public Internet.
View details
Preview abstract
In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the user can do until the user has satisfied the captive portal conditions.
This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some sort of captive portal enforcement device, and that they will need to satisfy the Captive Portal conditions to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a standardized approach for hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of satisfying and interacting with the captive portal are out of scope of this document.
This document replaces RFC 7710, which used DHCP code point 160. Due to a conflict, this document specifies 114. Consequently, this document also updates RFC 3679.
View details
SAC108 - SSAC Comments on the IANA Proposal for Future Root Zone KSK Rollovers
Joe Abley
Jaap Akkerhuis
Tim April
KC Claffy
Patrik Fältström
James Galvin
Geoff Huston
Andrei Kolesnikov
Jacques Latour
Barry Leiba
Danny McPherson
Ram Mohan
Russ Mundy
Rod Rasmussen
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2020), pp. 10
Preview abstract
The DNS root zone was first signed with DNSSEC in 2010. On October 11, 2018 the DNSSEC
Key Signing Key (KSK) was first rolled in the root zone. Having now completed that first roll,
the Internet Assigned Numbers Authority (IANA) has asked the ICANN Community to respond
to its plan for subsequent KSK rollovers. The SSAC would like to thank ICANN, and
specifically IANA, for engaging with the technical community on planning related to KSK
rollovers, and for incorporating past advice from the technical community into its current work.
This comment represents the SSAC's full input to IANA on its Proposal for Future Root Zone
KSK Rollovers, which will henceforth be referred to in this document as the Proposal.
The SSAC has previously commented on root zone KSK rollovers in SAC063, SAC073 and
SAC102. This comment specifically addresses concerns relating to future KSK rolls, and focuses
on items in the Proposal where the SSAC has concerns. In general, the SSAC is confident that
the Proposal as written is an adequate and viable high-level plan and does not believe that further
delay in planning for subsequent KSK rollovers is merited.
View details
RFC 8805 - A Format for Self-Published IP Geolocation Feeds
Erik Kline
Krzysztof Duleba
Zoltan Szamonek
Stefan Moser
IETF RFCs, RFC Editor (2020), pp. 23
Preview abstract
This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location.
Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds.
This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated.
View details
RSSAC047 - RSSAC Advisory on Metrics for the DNS Root Servers and the Root Server System
Russ Mundy
Duane Wessels
Alejandro Acosta
Jaap Akkerhuis
Fred Baker
Ray Bellis
Kazunori Fujiwara
Paul Hoffman
Kevin L. Jones
Akira Kato
Matt Larson
Daniel Migault
Ken Renard
Shinta Sato
Ryan Stephenson
Robert Story
Kevin Wright
Zhiwei Yan
Internet Corporation for Assigned Names and Numbers (ICANN) (2020), pp. 31
Preview abstract
In this report, the RSSAC:
• Defines measurements, metrics, and thresholds that root server operators (RSOs) meet to
provide a minimum level of performance. The thresholds are based on technical metrics
designed to assess the performance, availability, and quality of service that each root
server identifier (RSI) provides. The thresholds and the metrics on which they are based
are included as the RSSAC’s input to a yet-to-be defined evaluation process for future
RSOs.
• Defines system-wide, externally verifiable metrics and thresholds which demonstrate that
the root server system (RSS) as a whole is online and serving correct and timely
responses.
The metrics described in this report are based on the current awareness of, experience with, and
understanding of the root servers and RSS. In the future, different metrics may be required to
better understand the RSS and quantify performance, availability, and quality of service. As the
metrics and this document are revised, current and future RSOs may have to adapt their
architectures over time to meet the changing needs of the RSS.
View details
SAC109 - The Implications of DNS over HTTPS and DNS over TLS
Barry Leiba
Suzanne Woolf
Joe Abley
Tim April
Paul Ebersman
Ondrej Filip
Geoff Huston
Jacques Latour
John Levine
Chris Roosenraad
Tara Whalen
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2020), pp. 34
Preview abstract
Encrypted DNS technologies, including DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT),
are recent protocols developed for the primary purpose of enhancing user privacy. They
accomplish this in several ways, including encrypting their traffic in transit and permitting DNS
resolver selection and resolution in applications.
Major browser vendors, Internet Service Providers (ISPs), and others are deploying support for
these technologies. Their deployment brings a number of possible implications, both positive and
negative, to the ICANN community, operators and users of the DNS, and Internet users.
This report analyzes the initial effects of these technologies by identifying some groups whose
online experiences around privacy could change with the deployment of these technologies.
Detailed analysis of effects will have to wait for more widespread deployment and measurement.
This report discusses implications occurring now, and raises some longer-term questions for the
future. This report frames the issues from the perspectives of interested parties, with the
understanding that the issues are nuanced, and that readers coming from different perspectives
will have different sensitivities: readers from two different perspectives are likely to view a
single issue in two different ways.
The intended audience for this report is both the ICANN community and the greater Internet
community. This includes network operators, DNS software implementers, policy makers, and
concerned Internet users.
View details
RSSAC002v4 - Advisory on Measurements of the Root Server System.
Alejandro Acosta
Duane Wessels
Jaap Akkerhuis
John Bond
John Heidemann
Ken Renard
Ondřej Surý
Paul Hoffman
Paul Vixie
Ray Bellis
Shinta Sato
Zhiwei Yan
ICANN Root Server System Advisory Committee (RSSAC) Reports and Advisories (2020), pp. 19
Preview abstract
In this Advisory, the RSSAC identifies and recommends a set of parameters that would be useful for monitoring and establishing baseline trends of the root server system.
In response to a desire voiced by the ICANN Board, the RSSAC made a commitment to
prepare for an implementation of an early warning system that shall assist in detecting and
mitigating any effects (or the absence of such effects) which might challenge the scaling
and/or normal performance of the Internet's DNS root server system (RSS) caused by growth
of the DNS root zone itself or changes in client behavior from a larger root zone file.
As a first step, the RSSAC has begun work to determine a list of metrics that define the
desired service trends for the RSS. These metrics include the measured latency in the
publication of the root zone, number of queries and responses, distribution of response types,
distribution of message sizes, and the number of sources seen. With knowledge of these
metrics in hand, the RSSAC can then seek to produce estimates of acceptable root zone size
dynamics to ensure the overall system works within a set of parameters. The future work to
define these parameters will involve RSSAC working closely with the root server operators
(RSOs) to gather best practice estimates for the size and update frequency of the root zone.
It must be well understood that the measurements described in this document are a response
to the current awareness, experience, and understanding of the RSS. As time progresses
more, fewer, or entirely different metrics may be required to investigate new concerns or
defined problem statements.
View details
SAC113 - SSAC Advisory on Private-Use TLDs
Greg Aaron
Joe Abley
Jaap Akkerhuis
Tim April
Lyman Chapin
kc claffy
Patrik Fältström
James Galvin
Cristian Hesselman
Geoff Huston
Merike Kaeo
Barry Leiba
John Levine
Danny McPherson
Russ Mundy
Rod Rasmussen
Mark Seiden
Suzanne Woolf
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2020), pp. 27
Preview abstract
In this document, the SSAC recommends the reservation of a DNS label that does not (and
cannot) correspond to any current or future delegation from the root zone of the global DNS.
This label can then serve as the top-level domain name (TLD) of a privately resolvable
namespace that will not collide with the resolution of names delegated from the root zone. In
order for this to work properly, this reserved private-use TLD must never be delegated in the
global DNS root.
Currently, many enterprises and device vendors make ad hoc use of TLDs that are not present in
the root zone when they intend the name for private use only. This usage is uncoordinated and
can cause harm to Internet users.
The DNS has no explicit provision for internally-scoped names, and current advice is for the
vendors or service providers to use a sub-domain of a public domain name for internal, or private use. Using sub-domains of registered public domain names is still the best practice to name internal resources. The SSAC concurs with this best practice, and encourages enterprises, device vendors, and others who require internally-scoped names to use sub-domains of registered public domain names whenever possible. However, this is not always feasible and there are legitimate use cases for private-use TLDs.
The need for private-use identifiers is not unique for domain names, and a useful analogy can be drawn between the uses of private IP address space and those of a private-use TLD. Network
operators use private IP address space to number resources not intended to be externally
accessible, and private-use TLDs are used by network operators in a similar fashion. This
document proposes reserving a string in a manner similar to the current use of private IP address space. A similar rationale can be used to reserve more strings in case the need arises.
This document does not recommend a specific string for reservation. Instead, criteria are
provided in Section 4.1 to guide the decision on which string to choose and assist the ICANN
Board in making its determination. Four criteria are provided to help guide this decision and
reasoning is provided for each.
This advisory takes a pragmatic approach to an issue that the DNS allows by its design. Because of the decentralized nature of the DNS, there is no way to prevent ad hoc use of a TLD, rather than use of an explicitly reserved private string as this advisory recommends. Nevertheless, the SSAC believes that the reservation of a private string will help to reduce the ad hoc usage, provide greater predictability for network administrators and equipment vendors, and, over time, reduce erroneous queries to root servers.
View details
Preview abstract
This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC 2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days.
View details
RFC 8914 - Extended DNS Errors
Evan Hunt
Roy Arends
Wes Hardaker
David C Lawrence
IETF Request For Comments, RFC Editor (2020), pp. 13
Preview abstract
This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs.
View details
RSSAC026v2 - RSSAC Lexicon
Fred Baker
Wes Hardaker
Paul Hoffman
Lars-Johan Liman
Daniel Migault
Russ Mundy
Karl Reuss
Brad Verd
Paul Vixie
Duane Wessels
ICANN Root Server System Advisory Committee (RSSAC) Reports and Advisories (2020), pp. 9
Preview abstract
The precise technical language often found in Internet Engineering Task Force (IETF)
Request for Comments (RFCs), while often providing consistency and clarity to technical
communities, can sometimes be incomprehensible or misleading when used in a
non-technical setting. The purpose of this document is to increase the understanding of
terms used commonly when discussing the root server system to the broader ICANN
community. It is not to redefine or provide guidance to any technical communities on the
correct use of these terms.
This document and its terms should be useful to anyone discussing the DNS root server
system. This includes the ICANN community, ICANN staff, RSSAC Caucus members and
the RSSAC itself. It will be updated by the RSSAC as the vocabulary used to discuss the
root server system evolves. Definitions for other DNS terms can be found in RFC 8499,
DNS Terminology.
View details
Preview abstract
Deploying a new network device in a location where the operator has no staff of its own often requires that an employee physically travel to the location to perform the initial install and configuration, even in shared facilities with "remote-hands" (or similar) support.
In many cases, this could be avoided if there were an easy way to transfer the initial configuration to a new device while still maintaining confidentiality of the configuration.
This document extends existing vendor proprietary auto-install to provide limited confidentiality to initial configuration during bootstrapping of the device.
View details
Preview abstract
Some DNS recursive resolvers have longer-than-desired round-trip
times to the closest DNS root server; those resolvers may have
difficulty getting responses from the root servers, such as during a
network attack. Some DNS recursive resolver operators want to
prevent snooping by third parties of requests sent to DNS root
servers. In both cases, resolvers can greatly decrease the round-
trip time and prevent observation of requests by serving a copy of
the full root zone on the same server, such as on a loopback address
or in the resolver software. This document shows how to start and
maintain such a copy of the root zone that does not cause problems
for other users of the DNS, at the cost of adding some operational
fragility for the operator.
This document obsoletes RFC 7706.
View details
SAC105 - The DNS and the Internet of Things: Opportunities, Risks, and Challenges
Tim April
Lyman Chapin
Cristian Hesselman
Merike Kaeo
Jacques Latour
Danny McPherson
Dave Piscitello
Rod Rasmussen
Mark Seiden
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2019), pp. 29
Preview abstract
The Internet of Things (IoT) promises to enhance our daily lives by seamlessly and autonomously
sensing and acting upon our physical environment through tens of billions of connected devices.
While this makes the IoT vastly different from traditional Internet applications like email and web
browsing, we expect that a significant number of IoT deployments will use the DNS to locate
remote services that they need, for instance to enable telemetry data transmission and collection
for monitoring and analysis of sensor data.
In this report, the SSAC provides a discussion on the interplay between the DNS and the IoT,
arguing that the IoT represents both an opportunity and a risk to the DNS. It is an opportunity
because the DNS provides functions and data that can help make the IoT more secure, stable, and
transparent, which is critical given the IoT's interaction with the physical world. It is a risk because
various measurement studies suggest that IoT devices may stress the DNS, for instance, because
of complex DDoS attacks carried out by botnets that grow to hundreds of thousands or in the future
millions of infected IoT devices within hours.
We also identify and discuss five challenges for the DNS and IoT industries (e.g., DNS and IoT
operators and software developers) to address these opportunities and risks, for instance by making
the DNS’s security functions (e.g., response verification and encryption) available on popular IoT
operating systems and by developing a shared system that allows different DNS operators to
automatically and continually exchange data on IoT botnet activity.
View details
SAC106 - SSAC Comments on Evolving the Governance of the Root Server System
Joe Abley
Geoff Huston
Danny McPherson
Ram Mohan
Russ Mundy
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN - Internet Corporation for Assigned Names and Numbers (2019), pp. 9
Preview abstract
This publication represents the full SSAC input to the Evolving the Governance of the Root
Server System ICANN Public Comment Proceeding.
The primary motivation of the SSAC during the review of the proposed Root Server System
(RSS) evolution was to ensure that the RSS was adequately positioned for long term
sustainability as the RSS is critical to the security and stability of the Domain Name System. The
SSAC reviewed the proposed framework in order to assure itself, and others, that the proposed
governance structures are capable of identifying issues and responding to them as they arise,
including but not limited to issues of technology, policy, operations, or security.
View details
RFC 8374 - BGPsec Design Choices
Chris Morrow
Rob Austein
Steven Bellovin
Russ Housley
Stephen Kent
Matt Lepinski
Kotikalapudi Sriram
Request for Comments, RFC Editor (2018), pp. 50
Preview abstract
This document captures the design rationale of the initial draft version of what became RFC 8205 (the BGPsec protocol specification). The designers needed to balance many competing factors, and this document lists the decisions that were made in favor of or against each design choice. This document also presents brief summaries of the arguments that aided the decision process. Where appropriate, this document also provides brief notes on design decisions that changed as the specification was reviewed and updated by the IETF SIDR Working Group and that resulted in RFC 8205. These notes highlight the differences and provide pointers to details and rationale regarding those design changes.
View details
SAC102 - SSAC Comment on the Updated Plan for Continuing the Root KSK Rollover
Preview
Benedict Addis
Jaap Akkerhuis
Lyman Chapin
Jay Daley
Patrik Fältström
Paul Ebersman
James Galvin
Geoff Huston
Barry Leiba
John Levine
Danny McPherson
Ram Mohan
Russ Mundy
Suzanne Woolf
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, Internet Corporation for Assigned Names and Numbers (2018), pp. 4
Preview abstract
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key.
View details
RSSAC040 - Recommendations on Anonymization Processes for Source IP Addresses Submitted for Future Analysis
Jaap Akkerhuis
Ray Bellis
John Bond
Joao Damas
Brian Dickson
John Heidemann
Paul Hoffman
Geoff Huston
Akira Kato
Lars-Johan Liman
Robert Story
Brad Verd
Paul Vixie
Duane Wessels
Internet Corporation for Assigned Names and Numbers (ICANN) (2018), pp. 19
Preview abstract
DNS operators, in particular Root Server Operators (RSOs), are periodically requested to collect
query data and submit it to a central storage location where it is accessible for future research.
The typical example is the yearly Day In The Life of the Internet (DITL) collections undertaken
by the DNS Operations Analysis and Research Center (DNS-OARC). Some operators are
uncomfortable sharing IP addresses of the query sources and some are even legally prevented
from doing so. In those cases, the compromise has been for the RSO in question to anonymize
the source IP addresses of the queries.
View details
SAC101- SSAC Advisory Regarding Access to Domain Name Registration Data
Greg Aaron
Joe Abley
Benedict Addis
Jaap Akkerhuis
Jeff Bedser
Don Blumenthal
Ben Butler
kc claffy
Jay Daley
James Galvin
Robert Guerra
Julie Hammer
Geoff Huston
Merike Kaeo
John Levine
Carlos Martinez
Danny McPherson
Ram Mohan
Russ Mundy
Rod Rasmussen
Doron Shikmoni
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN - Internet Corporation for Assigned Names and Numbers (2018), pp. 29
Preview abstract
Reliable, consistent, and predictable access to domain name registration data (via Registration
Data Directory Services, or RDDS) is essential for a variety of legitimate purposes, especially
the identification and mitigation of various types of Internet abuse and technical problems. In
recent years, access to the data by those who have a legitimate need for it has been diminished,
and availability is more constrained and more restricted than ever. This has happened for two
main reasons: new legal and policy developments, and an operational practice known as rate
limiting. These developments represent a shift in the abuse detection and mitigation landscape.
The ability of security practitioners and law enforcement to detect and mitigate cybercrime and
DNS abuse has been negatively affected, and the current situation is imposing greater operational
and administrative burdens on those defenders. This in turn impairs the general usability and
trustworthiness of the Domain Name System (DNS) and the Internet. This document describes
the results of SSAC’s extended deliberation on RDDS access issues and offers recommendations
for how to move forward.
View details
Preview abstract
The policy defined in RFC 6761 for IANA registrations in the
"Special-Use Domain Names" registry has been shown, through
experience, to present challenges that were not anticipated when RFC
6761 was written. This memo presents a list, intended to be
comprehensive, of the problems that have since been identified. In
addition, it reviews the history of domain names and summarizes
current IETF publications and some publications from other
organizations relating to Special-Use Domain Names.
This document should be considered required reading for IETF
participants who wish to express an informed opinion on the topic of
Special-Use Domain Names.
View details
RSSAC028 - Technical Analysis of the Naming Scheme Used For Individual Root Servers
Joe Abley
John Bond
Brian Dickson
Paul Hoffman
Suresh Krishnaswamy
Matt Larson
Declan Ma
Bill Manning
Jim Martin
Robert Martin-Legene
Daniel Migault
Shinta Sato
Arturo Servin
Davey Song
William Sotomayor
Paul Vixie
Wesley Wang
Suzanne Woolf
ICANN Root Server System Advisory Committee (RSSAC) Reports and Advisories (2017)
Preview abstract
The Domain Name System (DNS) is supported by root servers that serve the root zone.
Individual root servers were named under the “root-servers.net” domain in 1995. The
root-servers.net zone is delegated to the root servers.
This naming scheme has worked well for root servers and the Internet community at large
for over two decades. However, given today’s Internet environment, the RSSAC has
studied the naming scheme used for individual root servers and considered the
consequences of making changes.
The study documents a risk analysis of different alternative naming schemes.
This analysis includes:
Where the names reside in the DNS hierarchy
Who administers the zone in which the names reside
How different naming schemes affect DNSSEC validation of priming responses
The size of priming responses
From the risk analysis, the document aims at providing:
Recommendation to root server operators, root zone management partners, and
ICANN on whether changes should be made, and what those changes should be
Recommendations on signing the addresses associated with the root servers
Recommendation on the naming scheme for the root servers
View details
Preview abstract
The DNS relies upon caching to scale; however, the cache lookup
generally requires an exact match. This document specifies the use
of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers
to generate negative answers within a range and positive answers from
wildcards. This increases performance, decreases latency, decreases
resource utilization on both authoritative and recursive servers, and
increases privacy. Also, it may help increase resilience to certain
DoS attacks in some circumstances.
This document updates RFC 4035 by allowing validating resolvers to
generate negative answers based upon NSEC/NSEC3 records and positive
answers in the presence of wildcards.
View details
Preview abstract
This memo describes Opportunistic Wireless Encryption (OWE) -- a mode of opportunistic security [RFC7435] for IEEE Std 802.11 that provides encryption of the wireless medium but no authentication.
View details
RFC 8205 - BGPsec Protocol Specification
Rob Austein
Steven Bellovin
Russ Housley
Stephen Kent
Doug Montgomery
Chris Morrow
Sandy Murphy
Keyur Patel
John Scudder
Samuel Weiler
Matthew Lepinski
Kotikalapudi Sriram
IETF RFCs, RFC Editor (2017), pp. 45
Preview abstract
This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route.
View details
RFC 8145 - Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
Duane Wessels, Verisign
Paul Hoffman, ICANN
Internet Engineering Task Force (IETF), IETF (2017)
Preview abstract
The DNS Security Extensions (DNSSEC) were developed to provide origin
authentication and integrity protection for DNS data by using digital
signatures. These digital signatures can be verified by building a
chain of trust starting from a trust anchor and proceeding down to a
particular node in the DNS. This document specifies two different
ways for validating resolvers to signal to a server which keys are
referenced in their chain of trust. The data from such signaling
allow zone administrators to monitor the progress of rollovers in a
DNSSEC-signed zone.
View details
SAC078 - SSAC Advisory on Uses of the Shared Global Domain Name Space
Geoff Huston
Lyman Chapin
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2016), pp. 6
Preview abstract
It is widely known that the Domain Name System (DNS) includes both a set of rules for constructing syntactically valid domain names (the “domain name space”) and a protocol for associating domain names with data such as IP addresses (“domain name resolution”).
It is less widely understood, however, that DNS name resolution coexists with other name resolution systems that also use domain names. In many cases these other name resolution systems deliberately use domain names, rather than some other naming scheme, for compatibility with the widely deployed infrastructure of the DNS. They depend on the ability of DNS name resolution protocols and interface conventions to recognize their domain names but treat them in some special way.
...
The SSAC wishes to ensure that the ICANN Board and ICANN community are aware of discussions and ongoing work in multiple venues to more fully define what a namespace is, and how to avoid potential side effects, including name collisions, across the broad set of name resolution systems and expectations for their use.
View details
SAC073 - SSAC Comments on Root Zone Key Signing Key Rollover Plan
Patrik Fältström
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2016), pp. 41
Preview abstract
SSAC Comments on the Design Teams Draft Report on the Root Zone Key Signing Key Rollover Plan.
View details
RSSAC024 - Key Technical Elements of Potential Root Operators
Wes Hardaker
Paul Hoffman
Shane Kerr
Russ Mundy
Internet Corporation for Assigned Names and Numbers (ICANN) (2016)
Preview abstract
In this document the RSSAC defines key technical elements of potential new root
operators that would be a critical part of any potential root server operator designation
process.
RSSAC001 (“Service Expectations of Root Servers”) and RFC 7720 (“DNS Root Name
Service Protocol and Deployment Requirements”) are considered as starting points;
alone, they are insufficient to evaluate potential operators.
Non-technical aspects, such as trustworthiness, ethos, funding, business models,
openness, community participation and politics are out of scope for this document. The
RSSAC believes these non-technical aspects to be important, and although this document
does not address them, we expect them to be part of the overall evaluation. The elements
defined in this document are designed to be:
• Technical in nature
• As specific as possible
• Provable, documentable, and/or measurable
View details
SAC079 - SSAC Advisory on the Changing Nature of IPv4 Address Semantics
Don Blumenthal
Russ Mundy
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2016), pp. 17
Preview abstract
In this advisory, the SSAC considers the changing role of Internet Protocol Version 4 (IPv4) addresses caused by the increasing scarcity, and subsequent exhaustion, of IPv4 addresses. The exhaustion of the IPv4 address supply has been predicted since the end of the 1980s. However, the large scale adoption of mobile devices and their associated IPv4 addressing needs accelerated the exhaustion timetable, and placed increased pressure on network operators to conserve IPv4 addresses. This pressure has resulted in a marked increase in the use of Network Address Translation (NAT) technologies, altering the attributability characteristics of IPv4 addresses, and requiring changes to their interpretation by parties wishing to use them as endpoint identifiers.
View details
SAC090 - SSAC Advisory on the Stability of the Domain Namespace
Joe Abley
Jaap Akkerhuis
Don Blumenthal
Lyman Chapin
Patrik Fältström
Jim Galvin
Geoff Huston
John Levine
Danny McPherson
Ram Mohan
Russ Mundy
Rod Rasmussen
Doron Shikmoni
Suzanne Woolf
ICANN, ICANN (2016), pp. 14
Preview abstract
This advisory is concerned only with the risks to security and stability that arise from
ambiguity in the use of the domain namespace. Because no one owns (or can own) the
domain namespace, and programmers and network managers cannot be prevented from
creating their own names and naming scopes, these risks arise regardless of how policy
debates about authority or oversight are resolved. Therefore, the observations and
recommendations in this advisory are directed at mitigating clearly identified risks and
developing policies that provide practical guidance to software and system developers,
rather than debating whether or not private network operators should use the domain
namespace, or who (if anyone) should have the authority to declare and enforce exclusive
uses for specific individual domain name labels or categories of labels.
View details
Preview abstract
RSSAC has begun work to determine a list of parameters that define the
desired service trends for the root zone system. These parameters include the measured
latency in the distribution of the root zone, the frequency of the updates, and their size.
With knowledge of these parameters in hand, RSSAC can then seek to produce estimates
of acceptable root zone size dynamics to ensure the overall system works within a set of
parameters. The future work to define these parameters will involve RSSAC working
closely with the root server operators to gather best practice estimates for the size and
update frequency of the root zone.
View details
Preview abstract
This document describes an Extension Mechanisms for DNS (EDNS0)
option that is in active use to carry information about the network
that originated a DNS query and the network for which the subsequent
response can be cached. Since it has some known operational and
privacy shortcomings, a revision will be worked through the IETF for
improvement.
View details
RFC 7535 - AS112 Redirection Using DNAME
Joe Abley
Brian Dickson
George Michaelson
IETF RFCs, Internet Engineering Task Force (2015), pp. 16
Preview abstract
AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily, using DNAME resource records.
This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure.
View details
RFC 7646 -Definition and Use of DNSSEC Negative Trust Anchors
Jason Livingood
Chris Griffiths
IETF RFCs, Internet Engineering Task Force (2015), pp. 15
Preview abstract
DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains.
View details
Preview abstract
In many environments offering short-term or temporary Internet access
(such as coffee shops), it is common to start new connections in a
captive-portal mode. This highly restricts what the customer can do
until the customer has authenticated.
This document describes a DHCP option (and a Router Advertisement
(RA) extension) to inform clients that they are behind some sort of
captive-portal device and that they will need to authenticate to get
Internet access. It is not a full solution to address all of the
issues that clients may have with captive portals; it is designed to
be used in larger solutions. The method of authenticating to and
interacting with the captive portal is out of scope for this
document.
View details
RFC 7607 - Codification of AS 0 Processing
Randy Bush
Heather Schiller
Keyur Patel
IETF RFCs, Internet Engineering Task Force (2015), pp. 5
Preview abstract
This document updates RFC 4271 and proscribes the use of Autonomous System (AS) 0 in the Border Gateway Protocol (BGP) OPEN, AS_PATH, AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR attributes in the BGP UPDATE message.
View details
SAC070 - ICANN SSAC Advisory on the Use of Static TLD / Suffix Lists
Jaap Akkerhuis
Patrik Fältström
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2015), pp. 32
Preview abstract
This advisory investigates the security and stability needs surrounding the growing use of public suffix lists on the Internet.
For the purposes of this Advisory, a public suffix is defined as “a domain under which multiple parties that are unaffiliated with the owner of the Public Suffix domain may register subdomains.”
Examples of Public Suffix domains include "org", "co.uk", "k12.wa.us" and "uk.com".
There is no programmatic way to determine the boundary where a Domain Name System (DNS) label changes stewardship from a public suffix, yet tracking the boundary accurately is critically important for security, privacy, and usability issues in many modern systems and applications, such as web browsers. One method of determining this boundary is by use of public suffix lists (PSLs), which are static files listing the known public suffixes.
View details
Preview abstract
Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1).
This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator.
View details
RSSAC002 - RSSAC Advisory on Measurements of the Root Server System
ICANN Root Server System Advisory Committee ( RSSAC ) Reports and Advisories, Internet Corporation for Assigned Names and Numbers (ICANN) (2015), pp. 15
Preview abstract
RSSAC has begun work to determine a list of parameters that define the
desired service trends for the root zone system. These parameters include the measured
latency in the distribution of the root zone, the frequency of the updates, and their size.
With knowledge of these parameters in hand, RSSAC can then seek to produce estimates
of acceptable root zone size dynamics to ensure the overall system works within a set of
parameters. The future work to define these parameters will involve RSSAC working
closely with the root server operators to gather best practice estimates for the size and
update frequency of the root zone.
It must be well understood that the measurements described in this document are a
response to the current awareness, experience, and understanding of the Root Zone
System. As time progresses more, less, or entirely different metrics may be required to
investigate new concerns or defined problem statements.
View details
RSSAC003 - RSSAC Report on Root Zone TTLs
ICANN Root Server System Advisory Committee ( RSSAC ) Reports and Advisories, Internet Corporation for Assigned Names and Numbers (ICANN) (2015), pp. 35
Preview abstract
Root zone TTLs have not changed since 1999. In this report, the RSSAC Caucus studies
the extent to which the current root zone TTLs are still appropriate for today’s Internet
environment.
Selecting a TTL for a given resource record involves finding the right balance between a
few tradeoffs. Intuitively, shorter TTLs are beneficial for data that changes frequently,
whereas longer TTLs are beneficial for data that is relatively stable. Related to this,
longer TTLs provide robustness in the event of operational failures. All other things
being equal, and assuming software involved in queries and responses follow the DNS
protocol standards, shorter TTLs generally result in higher query rates, and longer TTLs
result in lower query rates.
View details
RFC 7304 - A Method for Mitigating Namespace Collisions
IETF RFCs, Internet Engineering Task Force (2014)
Preview abstract
This document outlines a possible, but not recommended, method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict.
View details
RFC 7342 - Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers
IETF RFC, Internet Engineering Task Force (2014)
Preview abstract
This memo documents some operational practices that allow ARP and Neighbor Discovery (ND) to scale in data center environments.
View details
RFC 7344 - Automating DNSSEC Delegation Trust Maintenance
IETF RFCs, Internet Engineering Task Force (2014)
Preview abstract
This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.
View details
SAC064 - ICANN SSAC Advisory on Search List Processing
Jaap Akkerhuis
Don Blumenthal
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2014), pp. 17
Preview abstract
This advisory examines how current operating systems and applications process
search lists. It outlines the issues related to the current search list behavior, and
proposes both a strawman to improve search list processing in the long term and
mitigation options for the Internet Corporation for Assigned Names and Numbers (ICANN) and the Internet community to consider in the short term. The purpose of these proposals is to help introduce new generic Top Level Domains (gTLDs) in a secure and stable manner with minimum disruptions to currently deployed systems.
View details
SAC063 - SSAC Advisory on DNSSEC Key Rollover in the Root Zone
Russ Mundy
Matt Larson
Jaap Akkerhuis
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2013)
Preview abstract
There is consensus in the security and domain name system (DNS) communities that the root zone DNS Security Extensions (DNSSEC) system poses unique challenges for standard DNSSEC practices. While there is agreement that an eventual root zone Key-Signing Key (KSK) rollover is inevitable regardless of whether that rollover is caused by a key compromise or other factors, there is no solid consensus in the technical community regarding the frequency of routine, scheduled KSK rollovers.
In this Advisory the SSAC addresses the following topics:
* Terminology and definitions relating to DNSSEC key rollover in the root zone;
* Key management in the root zone;
* Motivations for root zone KSK rollover;
* Risks associated with root zone KSK rollover;
* Available mechanisms for root zone KSK rollover;
* DNS response size considerations;
* Quantifying the risk of failed trust anchor update; and
* DNS response size considerations
View details
SAC057 - ICANN SSAC Advisory on Internal Name Certificates
Steve Crocker
Patrik Fältström
Ondrej Filip
James Galvin
Danny McPherson
Ram Mohan
Doron Shikmoni
ICANN SSAC Reports and Advisories, ICANN (Internet Corporation for Assigned Names and Numbers) (2013)
Preview abstract
The SSAC has identified a Certificate Authority (CA) practice that, if widely exploited, could pose a significant risk to the privacy and integrity of secure Internet communications. This CA practice could impact the new gTLD program. The SSAC thus advises ICANN take immediate steps to mitigate the risks.
View details
SAC062 - ICANN SSAC Advisory Concerning the Mitigation of Name Collision Risk
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2013)
Preview abstract
The term “name collision” refers to the situation in which a name that is properly defined in one operational domain or naming scope may appear in another domain (in which it is also syntactically valid), where users, software, or other functions in that domain may misinterpret it as if it correctly belonged there. The circumstances that may cause this can be accidental or malicious.
In the context of Top Level Domains (TLDs), the conflicting
namespaces are the DNS namespace defined in the root zone as published by the root management partners (ICANN, U.S. Dept. of Commerce National Telecommunications Information Administration (NTIA), and VeriSign) and any privately defined namespace, whether that namespace is defined only for the Domain Name System (DNS) or is also intended to “work” for other namespaces such as Active Directory
View details
RFC 6583 - Operational Neighbor Discovery Problems
Igor Gashinsky, Yahoo!
Joel Jaeggli, Zynga
IETF RFCs, Internet Engineering Task Force (2012)
Preview abstract
In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted.
This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks.
View details
SAC056 - ICANN SSAC Advisory on Impacts of Content Blocking via the Domain Name System
Alain Aina
Jaap Akkerhuis
Don Blumenthal
KC Claffy
David Conrad
Patrik Fältström
James Galvin
Jason Livingood
Danny McPherson
Ram Mohan
Paul Vixie
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (Internet Corporation for Assigned Names and Numbers) (2012)
Preview abstract
The use of Domain Name System (DNS) blocking to limit access to resources on
the Internet has become a topic of interest in numerousInternet governance
venues. Several governments around the world, whether by law, treaty, court
order, law enforcement action, or other actions or agreements, have either
implemented DNS blocking or are actively considering doing so. However, due to
the Internet’s architecture, blocking by domain name can be easily bypassed by
end users and is thus likely to be largely ineffective in the long term and fraught
with unanticipated consequences in the near term. In addition, DNS blocking can
present conflicts with the adoption of DNS Security Extensions(DNSSEC) and
could promote balkanization of the Internet into a country-by-country view of the
Internet’s name space.
View details
Preview abstract
This document recommends against the use of the AS_SET and
AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to
simplify the design and implementation of BGP and to make the
semantics of the originator of a route more clear. This will also
simplify the design, implementation, and deployment of ongoing work
in the Secure Inter-Domain Routing Working Group.
View details
RFC 5635 - Remote Triggered Black Hole filtering with uRPF
IETF, IETF (2009)
Preview abstract
Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks.
This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well.
View details
No Results Found
