Applicant Information

Does or will this RSP have a publicly verifiable, 3rd party certification (e.g. ISO 27001) held directly by the organization and relevant to the registry services under application?

Yes

Does or will this RSP have processes and controls to manage physical access to infrastructure and systems, including building access controls, security cameras and/or other sensors, physical environmental monitoring and safety equipment, and alarm systems related to the physical infrastructure?

Yes

Does or will this RSP have processes and controls to manage non-physical access to infrastructure, including network access from both internal systems and external Internet systems, intrusion detection systems, security information and event management systems, network firewalls, network segmentation and isolation, user identification and authentication, and authorization schemes?

Yes

Does or will this RSP have processes and controls pertaining to the selection of vendors and equipment suppliers, management and maintenance of assets while in use, procurement of assets, and safe disposal of assets?

Yes

Does or will this RSP routinely renew and keep safe all cryptographic material necessary for the operation of the RSP?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) at-rest data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) in-transit data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

If applicable, does or will this RSP have security controls for data in virtualized environments, including controls relevant to both on-premises or private virtualization environments as well as public clouds, network isolation, memory isolation, process isolation, and hypervisor access controls?

Yes

Does or will this RSP have a senior executive primarily in charge of and responsible for security?

Yes

Does or will this RSP conduct background checks, both initial and on-going, of personnel and vendors relevant to the registry services under application?

Yes

Describe the solutions and mitigations to be used to thwart Distributed Denial of Service (DDOS) attacks against the authoritative DNS services.

Registry Services LLC dba GoDaddy Registry understands the critical importance of protecting DNS services against DDoS attacks. Our comprehensive approach to mitigating DDoS threats incorporates multiple layers of defense & advanced technologies. Our solutions ensure the DNS remains highly available, secure, & resilient against DDoS attacks, and provides robust protection for critical Registry services. ABSORB ATTACKS - Infrastructure has been greatly over provisioned to handle sudden traffic spikes, with the platform running at 5% capacity under regular load, allowing 20x traffic spikes to be absorbed - Anycast announcements are designed & engineered to ensure a global spread of traffic & that no one single site services all traffic for a TLD. This ensures a localized DDoS event does not impact a TLD globally & assists in spreading the attack traffic across more sites TRAFFIC FILTERING - Standard edge router protection to block RFC1918 addresses, as well as malformed packets provides the first line of defense DNS TOOLS - Inbuilt functionality within ISC BIND is configured to assist with the management of abnormal traffic loads, including features such as Response Rate Limiting. - Tools installed at each location also allow the inspection of traffic & identification of abnormal patterns. If the traffic can be blocked regionally based on the source IP, this can be implemented at the host level MANAGED DDOS PROTECTION SERVICES Our DNS also utilizes a highly-scaled 3rd party DDoS mitigation service, integrated into our DNS platform. Mitigation facilities are located at 14 globally distributed sites, referred to as scrubbing centers. Each scrubbing center contains sophisticated detection & mitigation equipment, connected to high bandwidth interconnects from diverse providers & currently has a total of 15Tbps scrubbing capacity. Each site has between 10 & 20 providers. Total capacity at each mitigation site is between 200Gbps & >800Gbps. We ensure that there are at least five Tier 1 carriers at each site, with the remaining providers being Tier 2. The mix of providers & peering has been chosen to reduce collateral damage from malicious attacks. Often attacks can be diverted to a single scrubbing center, ensuring that legitimate users are not impacted. This service protects our DNS network from both volumetric & non-volumetric attacks. The service’s network & GoDaddy Registry DNS network were designed to be complementary. Scrubbing locations are generally located in the same localities as DNS sites. While there has been a deliberate choice to avoid having DNS & mitigation equipment in the same physical location, they are proximate enough to ensure network latency in the low tens of milliseconds between DNS node & scrubbing centers. The mitigation equipment within each scrubbing center only adds a few microseconds (one-millionth of a second) to overall latency. This combination of extremely low latency scrubbing & short network access means that DDoS events can be mitigated without impacting the experience of ordinary users. The service is fully automated, with NetFlow traffic monitoring in place, with thresholds set to trigger automatic failover of traffic to the DDoS service. This include the BGP advertisements from the scrubbing centers & the eventual withdrawal of DDoS services once the event has finished. This automation ensures response within minutes to a DDoS event. All incidents will result in a report containing the following, as well as any other relevant information: Attack vector type; Sources of attack traffic; Destinations of attack traffic; Mitigation actions; Traffic graphs; Top talker sources; Top source IP Address locations by country; and Social media & chat monitoring. 24/7 SECURITY OPERATIONS CENTER - Continuous monitoring: Provides round-the-clock monitoring & rapid response to potential threats - Incident response plan: Quickly mitigate & recover from DDoS attacks is maintained & regularly updated

Does or will this RSP comply with BCP 38?

Yes

Does or will this RSP implement routing security of some nature, such as automated route filters, RPKI route origin validation, or other operational practices defined by the Internet Society and Global Cyber Alliance's Mutually Agreed Norms for Routing Security (MANRS)?

Yes

Does or will this RSP have documented, regular, and active practices for the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the secure development of software?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the development of software?

Yes

Does or will this RSP use Infrastructure-as-Code (IaC) to manage all systems relevant to operation of the registry services under application?

Yes

Does or will this RSP use automated orchestration to manage all systems relevant to the operation of the registry services under application?

Yes

Describe the methods resiliency for DNS, including the use of anycast, primary and secondary DNS authoritative servers, and hidden DNS zone transfer servers.

Registry Services, LLC d/b/a GoDaddy Registry has deployed DNS infrastructure that implements multiple layers of resiliency to ensure continuous service availability and optimal performance. This multi-layered approach ensures continuous DNS service availability, with automatic failover capabilities and geographic redundancy. The system is designed to maintain optimal performance even during localized outages or DDoS attacks, providing enterprise-grade DNS resolution services globally. The following methods are employed. ANYCAST IMPLEMENTATION - Deployment across 30 globally distributed sites, on all continents (excluding Antarctica). - Each site maintains redundant high capacity (10G+) links to multiple major network transit providers. - Strategic positioning near major Internet exchanges. - Both IPv4 and IPv6 Anycast addresses for each DNS group. - Site selection optimized for low-latency DNS responses worldwide. - Multiple Anycast prefixes used across multiple ASN. - Diverse Anycast announcement strategy ensuring a mix of prefixes are announced from each DNS site. PRIMARY AND SECONDARY DNS ARCHITECTURE - Secure stealth (hidden) nameservers acting as primary DNS - Hidden DNS servers are protected inside of segregated private networks in multiple geographic locations and replicated out to public network segments to distribute to the Anycast nodes. - Transaction-based DNS update software for dynamic record management. - Multiple versions of OS and DNS software used to mitigate risk. - Custom monitoring of DNS zone transfer freshness at each transfer point. - Secondary/Edge DNS services split across two distinct and separate hardware and network providers. - Each Anycast site has a minimum of four physical, high specification servers capable of over 100,000 queries per second each. DNS ZONE TRANSFER CONFIGURATION - Distribution services firewalled limiting access from explicit nodes. - Restricted zone transfers using TSIG keys, limited to specified secondary servers. - End-to-end IPv4 and IPv6 zone activity monitoring capability. - Dedicated unicast addresses (IPv4 and IPv6) for monitoring and maintenance purposes. - Multiple redundant servers for each stage of the DNS zone transfer; creation, signing, validation and distribution to Anycast nodes - Transfers done using industry standard IXFR or AXFR processes. ADDITIONAL RESILIENCY FEATURES - Each nameserver maintains both AAAA and A address records. - Infrastructure capacity designed at many times peak demand. - Direct connectivity to major transit providers at each site. - Comprehensive DDoS detection and automatic mitigation platform. - Rate limiting and anti-abuse measures configured on each server. - All changes first tested in Test and OTE environments and reviewed before approval to deploy to production. - Multi-staged deployment processes used to gradually implement any change across the global fleet in multiple waves over multiple hours or days – also meeting SOX, SOC2 and ISO 27001 audit requirements. - Global monitoring of all servers, including edge nodes for RTT and availability, to make sure SLAs are met or exceeded. - Multiple points of monitoring, including server level and service level, including multiple checks every minute against each Anycast announcement from an independent network of monitoring probes. - Monitoring of TLD DNS responses and behavior via known large recursive providers. Please see Attachment DNS.3.3. – DNS Resiliency.

Does or will this RSP have at least two Tier III (as defined here: https://uptimeinstitute.com/tiers) or equivalent data centers having no inter-dependencies for DNS zone distribution?

Yes

Does or will this RSP have at least two Tier III or equivalent data centers having no inter-dependencies for global DNS anycast service?

Yes

Does or will this RSP have enough coverage of DNS service to accommodate failures of any DNS point-of-presence to maintain minimum Service Level Requirements?

Yes

Does or will this RSP implement RFC 1034 (“DOMAIN NAMES - CONCEPTS AND FACILITIES”)?

Yes

Does or will this RSP implement RFC 1035 (“DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION”)?

Yes

Does or will this RSP implement RFC 1123 (“Requirements for Internet Hosts -- Application and Support”)?

Yes

Does or will this RSP implement RFC 1982 (“Serial Number Arithmetic”)?

Yes

Does or will this RSP implement RFC 2181 (“Clarifications to the DNS Specification”)?

Yes

Does or will this RSP implement RFC 3226 (“DNSSEC and IPv6 A6 aware server/resolver message size requirements”)?

Yes

Does or will this RSP implement RFC 3596 (“DNS Extensions to Support IP Version 6”)?

Yes

Does or will this RSP implement RFC 3597 (“Handling of Unknown DNS Resource Record (RR) Types”)?

Yes

Does or will this RSP implement RFC 4343 (“Domain Name System (DNS) Case Insensitivity Clarification”)?

Yes

Does or will this RSP implement RFC 6891 (“Extension Mechanisms for DNS (EDNS(0)))”?

Yes

Does or will this RSP implement RFC 7766 (“DNS Transport over TCP - Implementation Requirements”)?

Yes

Does or will this RSP implement RFC 5001 (“DNS Name Server Identifier (NSID) Option”)?

Yes

Does or will this RSP operate DNS service according to RFC 6168 (“Requirements for Management of Name Servers for the DNS”)?

Yes

Does or will this RSP operate DNS service according to RFC 8906 (“A Common Operational Problem in DNS Servers: Failure to Communicate”)?

Yes

Does or will this RSP operate DNS service according to RFC 9199 (“Considerations for Large Authoritative DNS Server Operators”)?

Yes

Does or will this RSP operate DNS service according to RFC 9210 (“DNS Transport over TCP - Operational Requirements”)?

Yes

Does or will this RSP meet the standards established in the Service Level Agreements defined in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to DNS?

Yes

Does or will this RSP compartmentalize (e.g. virtualization) the DNS service in such a manner that each compartment (e.g. containers, virtual machines, physical machines) is dedicated to DNS (excluding system services such as monitoring, remote access and NTP)?

Yes

Does or will this RSP monitor all unique DNS servers of all anycast nodes?

Yes

Does or will this RSP operate authoritative DNS servers according to the IANA Technical Requirements for Authoritative Name Servers (https://www.iana.org/help/nameserver-requirements)?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to DNS and IPv4?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to DNS and IPv6?

Yes

Does or will this RSP regularly exercise DNS Service continuity actions?

Yes

Does or will this RSP be capable of transferring all applicable operations to another RSP as defined by the Material Subcontracting Arrangement Technical Questions?

Yes

Does or will this RSP participate in coordinated Emergency Back-end Registry Operator (EBERO) transitions, including but not limited to maintaining the DNSSEC chain of trust, of hosted gTLDs when the business relationship of this RSP and the Registry Operator is not in good standing?

Yes

Does or will this RSP monitor for faults inside its own network?

Yes

Does or will this RSP monitor for faults from a point outside any of its own networks?

Yes

Does or will this RSP have documented processes for aggregation and triage of faults?

Yes

Does or will this RSP have documented processes to mitigate faults once detected?

Yes

Does or will this RSP have processes to minimize faults during maintenance of systems, including both automated processes and manual change control processes?

Yes

Does or will this RSP have personnel capable of reacting to and mitigating faults 24 hours per day of every day of every year of service?

Yes

Provide documentation regarding any RSP functions currently being served for any gTLD, the domain names of the gTLDs, and all service disruptions for each gTLD in the past six months, where a service disruption is defined by Specification 10 of the ICANN Registry Agreement (2024).

The GoDaddy Registry currently provides the following RSP functions. - EPP - WHOIS - RDAP - DNS - DNSSEC - Registry Data Escrow These RSP functions serve all our TLDs. In the past six months we have had no service disruptions. Where possible, code updates are done with services remaining online. These upgrades were made on the following dates: - 2024-11-19 – Registry Software Upgrade - 2024-10-22 – Registry Software Upgrade - 2024-09-24 – Registry Software Upgrade - 2024-07-16 – Registry Software Upgrade A summary of these functions can be found below, please see the attached documents for detailed technical information. EPP The EPP application server is a proprietary GoDaddy Registry daemon and business logic engine, which receives XML requests, parses them, and passes data access and change requests to the PostGreSQL database. This daemon is a proprietary GoDaddy Registry Java daemon and uses an event-driven, threaded architecture. EPP application servers also run a host-based firewall and only accepts EPP requests from a predetermined list of IP Addresses that provide valid credentials and SSL keys. EPP is also restricted to accredited Registrars only, enforced by allowlisting and firewalls at the front-end. Upon de-accreditation, the Registrar and associated client IP Addresses are removed from the active configuration, and EPP becomes uncontactable for that Registrar. WHOIS The WHOIS application servers consist of a proprietary GoDaddy Registry Java daemon and business logic engine that converts standard WHOIS protocol requests over port 43 into data access requests to the database. WHOIS service is available at both the Active and Standby Registry Regions and interacts with the read-only standby database. WHOIS is also a public service and runs on a heavily protected demilitarized zone (DMZ), independent of the EPP and Registry Web-based Interface front-ends, providing a read-only connection into the Registry database. RDAP The F5 web application firewall locks down access to specific URLs provided for this service, which is also protected by a ‘captcha’ and query limits to prevent abuse. This service is limited in access to the database, and is provided a read-only application account, restricted to key tables and columns. The data is queried and displayed on the reply web page. DNS Our DNS service provides the ultimate in stability, security and availability, utilizing a total of 30 sites distributed across the globe. The DNS service provides a high degree of robustness and diversity through a platform that is scaled for the demands of the Internet core. The DNS service is deployed in redundant sites throughout the globe, across all continents except Antarctica. It has strong manageability through automated build processes and configuration management, as well as fully automated monitoring for DDoS mitigation. The DNS platform’s capabilities and capacity are continually assessed to ensure that it evolves with the needs of our customers and the changing Internet landscape.