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.

I. Infrastructure and Architecture Optimization 1. Distributed Architecture Design Multi-node Deployment: Deploy DNS services on server nodes in multiple geographical locations to avoid single-point failures. Balance traffic through load balancers to reduce the pressure on single nodes. Elastic Expansion Mechanism: Dynamically adjust resources by monitoring server resource usage and predicting traffic peaks to respond to sudden attacks. 2. Network Layer Protection Reinforcement BGP Anycast: Map IP addresses of multiple data centers to the same prefix through Anycast technology, disperse attack traffic to multiple nodes, and shorten response time while improving availability. Dedicated Network Isolation: Isolate DNS services from other business systems, deploy them in independent VPCs or subnets, and restrict unnecessary network access. II. Traffic Cleaning and Filtering 1. Hierarchical Traffic Cleaning Scheme Edge-layer Cleaning: Deploy DDoS cleaning devices at network entrances to detect and filter abnormal traffic in real time. Core-layer Cleaning: Deploy deep packet inspection devices inside data centers to further analyze traffic cleaned at the edge, identify, and block application-layer attacks. 2. Filtering Strategies Based on Protocol Characteristics DNS Protocol Protection: Restrict unauthenticated large-scale query requests and rate-limit high-frequency IPs. Verify the legitimacy of query parameters and reject requests containing illegal characters or exceeding field length limits. III. Real-time Monitoring and Automated Response 1. Threat Monitoring and Analysis Multi-dimensional Monitoring: Deploy tools such as Prometheus and Grafana to monitor key indicators of DNS services. Use NetFlow or sFlow to analyze network traffic patterns and identify abnormal traffic surges. Threat Intelligence Integration: Connect to external threat intelligence sources to block traffic from known attack source IPs or malicious AS numbers in real time. 2. Automated Response Mechanisms Dynamic Blacklist: Automatically identify attack sources through machine learning models, add their IPs to a temporary blacklist, and block continuous attack traffic. Traffic Tunneling and Cleaning: When a large-scale attack is detected, tunnel traffic to a cleaning center for processing to ensure business continuity. IV. Access Control 1. Fine-grained Access Control Restrict DNS service access through NAC systems. Implement role-based access control to assign minimum privileges to different users. V. Disaster Tolerance and Business Continuity 1. Data Backup and Recovery Regularly back up DNS resolution data and transaction logs, store them in off-site disaster recovery centers, and prevent data loss or service interruptions caused by attacks. Establish a fast recovery process to restore services in minutes through snapshots or image files. 2. Disaster Recovery Switchover Drills Conduct regular failure transfer drills to verify whether the backup data center can seamlessly take over services when the primary node is paralyzed, ensuring that RTO and RPO meet business requirements. VI. Security Policy and Compliance Management 1. Formulate Special Protection Policies Define the security baseline for DNS services, including protocol version requirements, encryption standards, log retention periods,stem rules, and timely adjust protection strategies for new DDoS attack methods. 2. Compliance and Auditing Comply with industry standards and regulatory requirements to ensure that protection measures meet data privacy and security compliance. Regularly carry out security audits and penetration tests, and simulate DDoS attack scenarios to verify the effectiveness of the protection system. VII. Collaborative Protection with Ecosystems ISP Cooperation: Sign DDoS protection service agreements with network service providers and use the cleaning capabilities of their backbone networks to deal with ultra-large-scale attacks.

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.

I. Core Design of DNS Resiliency Architecture Adopts a three-layer resiliency model of "Anycast Traffic Layer + Distributed Authoritative Layer + Hidden Management Layer" to ensure service availability ≥ 99.99%: [Anycast VIP] ← Global user access entry | [Geographically Dispersed Nodes (≥3 data centers)] ← Traffic localization and fault isolation | [Authoritative Primary/Secondary Clusters] ↔ [Hidden Master Server] ← Data synchronization and secure transmission II. Detailed Resiliency Methods 1.Anycast Routing for Global Load Balancing Technical Principle: Each global node advertises the same Anycast IP prefix (e.g., IPv6 2402:7D80::/48) to ISPs via eBGP. User queries are automatically routed to the topologically nearest node, with BGP path selection based on AS-PATH length and local priority. Fault Recovery: When a node fails, border routers automatically withdraw BGP routes (convergence time < 90 seconds), seamlessly switching traffic to other nodes. Combined with real-time health checks (ICMP/TCP port 53 probing), failed nodes are taken out of service until recovery. 2.Redundant Architecture of Authoritative Servers Role Deployment Location Quantity Requirement Disaster Recovery Mechanism Primary Authoritative Server Hidden network segment 2 (active-standby) Real-time status synchronization (<1s latency) Secondary Servers Each Anycast node ≥3 per node Cross-data center distribution Hidden Master Server Isolated security zone 1 Access restricted to secondary server IPs Workflow: Zone file updates are completed offline on the hidden master server (isolated from public access). Primary servers push updates to global secondary servers via IPsec VPN tunnels (AXFR/IXFR protocol + TSIG authentication). Secondary servers respond to Anycast queries, with direct external updates disabled (NSUPDATE port closed). 3.Protected Hidden Zone Transfers Secure Channels: Dedicated MPLS/VPN links or IPsec tunnels (AES-256 encryption) between master and secondary servers. Transmission ports use non-standard ports hidden by firewall policies. Access Control: Hidden master server IPs are excluded from NS records, with access limited to secondary servers via whitelist (ACL-restricted source IPs). Zone transfers require mandatory TSIG key authentication (HMAC-SHA256), rejecting unsigned requests. III. Resiliency Enhancement Measures Risk Scenario Mitigation Strategy Compliance Standard Node-level failure BGP automatic switching + ≥3 geographically dispersed Anycast nodes RFC 4786 DDoS attack ISP cleaning center integration + UDP rate limiting (500 pps/source IP) SSAC 102 Data corruption Daily automatic snapshots + cross-site backups (3 copies) ICANN BCP DNSSEC key compromise HSM hosting + offline signing + automated rotation RFC 8649 IV. Monitoring and Recovery Metrics Real-time Monitoring: Healthy node RTT < 50ms, packet loss rate < 0.1%. IXFR transmission synchronization delay between primary and secondary servers < 100ms (Zabbix alert threshold). Disaster Recovery: RPO < 5 minutes, RTO < 90 seconds, full zone outage < 15 minutes. V. Architecture Compliance 1.Anycast Deployment: Meets ICANN's resiliency requirements for root name servers (SSAC Recommendation 101). 2.Hidden Master: Complies with RFC 5936 secure zone transfer specifications to prevent unauthorized zone scraping. 3.DNSSEC: Supports RFC 6781 automated key management to ensure signing service continuity. Logical Topology Elements User → Anycast VIP → Nearest secondary server Secondary server → IPsec tunnel → Hidden master server (isolated security zone) Master server → HSM (offline signing) → Backup storage cluster Please see further details attached.

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).

As defined by Specification 10 of the ICANN Registry Agreement (2024 Edition), a service outage refers to the unavailability of critical functions provided by the registry, such as DNS resolution, registration data access, and DNSSEC management. The following summarizes relevant information on gTLD service outages: 1.Current gTLD Functions Teleinfo provides the following core functions for gTLDs: DNS resolution services: Ensuring global domain name resolvability. Registration data management: Maintaining WHOIS/RDAP data for public query. DNSSEC support: Providing Domain Name System Security Extensions. EPP (Extensible Provisioning Protocol) services: Supporting domain registration, renewal, transfer, etc. Data escrow：Periodically backing up registration data to independent third parties as required by Specification 2. 2.No Service Outages Recorded in the Past Six Months No service outages affecting the above functions have been recorded for any gTLD managed by the RSP during this period.