{"id":2914,"date":"2017-08-14T13:26:45","date_gmt":"2017-08-14T13:26:45","guid":{"rendered":"http:\/\/www.dns.icann.org\/?page_id=2914"},"modified":"2021-03-12T19:35:49","modified_gmt":"2021-03-12T19:35:49","slug":"rssac024-response","status":"publish","type":"page","link":"https:\/\/www.dns.icann.org\/rssac\/rssac024-response\/","title":{"rendered":"RSSAC024 Response"},"content":{"rendered":"

This document<\/h4>\n

The Root Server System Advisory Committee<\/a> has developed RSSAC024<\/a> to document the Key Technical Elements of Potential Root Server Operators<\/a>.<\/p>\n

This page describes how ICANN<\/a> meets the service and technical key element expectations for the ICANN Managed Root Server service<\/a> it operates. This is a living web page and it is reviewed and updated as and when ICANN reviews and improves the processes and tools it uses to provide the ICANN Managed Root Server service and at least twice a year.<\/p>\n

How ICANN stands within RSSAC024 requirements<\/h4>\n

3.1 RSSAC001 and RFC7720<\/h4>\n

The candidate operator must be evaluated with respect to existing operational expectations and requirements, namely RSSAC001 and RFC7720. Some of these might not be applicable to candidate operators. Others may be evaluated against a candidate\u2019s already existing services. Summaries of these expectations and requirements are given in Appendices A and B.<\/i><\/p>\n\n\n\n
3.1<\/b><\/td>\nICANN adheres to both RFC7720 as well as RSSAC001.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

3.2.1 Overall Service Design<\/h4>\n

The candidate operator\u2019s overall design must be evaluated with respect to its utility in serving the root zone. The candidate operator should provide as many design details as possible. Design choices might include hardware platforms, networking technology, use of virtualization, locations of servers (e.g., data centers, exchange points, shared cabinets), overall capacity, and out-of-band access.<\/i><\/p>\n\n\n\n
3.2.1<\/b><\/td>\nICANN uses an anycast routing model to allow for greatest service delivery while minimizing outage and downtime. ICANN uses multiple hardware and software vendors in order to mitigate bugs and exploits. ICANN clustered sites in (CA, DC, CZ) have an even split between Linux and FreeBSD. Any of the clustered sites can handle the entirety of ICANN\u2019s normal root server traffic load. ICANN also operates 160+ \u2018singles\u2019 distributed around the globe, hosted with various entities to allow for maximum coverage, higher resiliencey and stability, and shorter network paths for all consumers.ICANN\u2019s root server infrastructure announces both a specific and covering prefix, so that even if maintenance is done and the more specific route announcement is withdrawn, we still have visibility to the node.Secure OOB(out of band) communication is used for changes to all systems. Change control via a central repository is in place, all changes are reviewed by staff as well as tested in a non-production environment.  After testing and vetting changes are pushed out during well know maintenance windows.  In case of issues, rollback procedures are followed as soon as it is deemed appropriate.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

3.2.2 Service Availability<\/h4>\n

The candidate operator\u2019s proposal must be evaluated with respect to its approach to maximizing service availability. Per RSSAC001 E.3.3-B<\/a>, the candidate operator’s design is expected to eliminate or minimize single points of failure. This might include diversity elements described in section 3.4.<\/em><\/p>\n\n\n\n
3.2.2<\/b><\/td>\nICANN root servers use anycast routing to maximize availability and minimize outages, as well as to be able to accommodate flash traffic spikes due to increased usage and\/or attacks(DoS\/DDoS). Anycast also provides lower latency for our customers.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

3.2.3 Service Capacity<\/h4>\n

The candidate operator’s service capacity must be evaluated for its ability to withstand Denial of Service (DoS) and other forms of attacks. See RSSAC001 E.3.4-A<\/a>.<\/em><\/p>\n\n\n\n
3.2.3<\/b><\/td>\nICANN\u2019s root server infrastructure can withstand traffic spikes and or sustained traffic, several orders of magnitude above the current normal average DNS query rate. ICANN\u2019s root server\u2019s currently operate at 0.69% of total capacity, the highest recorded spike was 7.13% of total capacity.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

3.2.4 Performance<\/h4>\n

The candidate’s design should be evaluated with respect to its performance characteristics, such as latency, serviced regions, RSSAC002 metrics and RFC7720 requirements.<\/em><\/p>\n\n\n\n
3.2.3<\/b><\/td>\nICANN Managed Root Server infrastructure is RFC7720 compliant with regards to protocol availability and delivery. Per RSSAC002 ICANN publishes all pertinent data pertaining to root zone performance and propagation. http:\/\/stats.dns.icann.org\/rssac\/<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

3.3.1 DNS Operational Experience<\/h4>\n

Previous or current experience operating large-scale DNS services by the candidate operator should be considered. Such operation is expected to include both IPv4 and IPv6, and both UDP and TCP. Existing services of the candidate operator should be evaluated for similarities to the candidates expected root server operation (e.g., query rate, use of anycast, zone size, zone update frequency).<\/em><\/p>\n\n\n\n
3.3.1<\/b><\/td>\nICANN has been operating global DNS services and specifically supporting Root Server Operations  for the past 20 years.  The team has an ethos that enforces community collaboration and constant training. we are currently involved and feed into DNS-OARC and RSSAC.  Team members have a strong community involvement and years of DNS experience across public and private entities.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

3.3.2 Security Audit<\/h4>\n

A security audit of the candidate operator should be performed and will be evaluated with respect to best current practices. It is expected that any security audit will be conducted by an organizations unaffiliated with the candidate operator. Audit results must be kept private unless otherwise agreed to by candidate operator.<\/em><\/p>\n\n\n\n
3.3.2<\/b><\/td>\nICANN undertakes annual  independent 3rd party security audits and pen testing against its root server infrastructure. ICANN DNS Engineering has internal tooling and testing which insures all change management is tracked and any anomalies are flagged.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

3.3.3 Addressing Resources<\/h4>\n

The candidate operator must obtain its own AS number(s) and IPv4 and IPv6 address allocations for operating a root server. It is assumed that IP anycast will be used. If IP anycast will not be used, a technology providing similar or better service levels should be specified. Provider address space or addresses that cannot be used with anycast are undesirable. The expected production IPv4 and IPv6 address blocks must be severable from the candidate\u2019s organization to facilitate emergency or planned transfers.<\/em><\/p>\n\n\n\n
3.3.3<\/b><\/td>\nICANN has clearly defined anycast prefixes and covering prefixes for all IP space. ICANN also has a unique ASN for it’s root server operations.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

3.3.4 DNS PTR Records<\/h4>\n

The candidate operator should demonstrate the ability to set DNS PTR records for its IPv4 and IPv6 address space.<\/em><\/p>\n\n\n\n
3.3.4<\/b><\/td>\nICANN follows best practices for DNS PTR records and has reverse zones for it’s IP address blocks, populated with PTR entries for all actively used addresses.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

3.3.5 Address Reputation<\/h4>\n

The reputation of the candidate operator\u2019s IP address blocks should be evaluated. Addresses with a bad reputation that are listed in one or more black lists (e.g., Spamhaus Don\u2019t Route Or Peer List) might affect a client\u2019s ability to reach the candidate’s servers.<\/em><\/p>\n\n\n\n
3.3.5<\/b><\/td>\nICANN Managed Root Server address space can be checked in a number of ways, we use the following services<\/p>\n