HIGHLIGHTS u Flexible, scalable, high availability system architecture to virtually eliminate SRS downtime while providing for smooth growth u Coactive, redundant Shared Registration System Data Centers for high service availability u Geographically dispersed Zone nameservers for DNS query workload distribution |
JVTeam brings together the experience and technical capabilities to implement a TLD Registry that will provide significant benefits to the Internet community.
The NeuStar/Melbourne IT Joint Venture’s (henceforth the JVTeam) proposed technical solution provides two co-active data centers in Sterling, Virginia and Chicago, Illinois—each of which is capable of processing the full SRS data-center workload—plus multiple nameserver sites dispersed globally to protect against natural or man-made disasters. The benefit to ICANN and the Internet community is a solid architecture designed to maintain the stability of the Internet and promote user confidence.
Section III is organized in three subsections as required in the ICANN RFP:
· III.1 describes JVTeam technical capabilities and expertise.
· III.2 and subparagraphs III.2.1 through III.2.14 is our detailed plan for providing the SRS data-center operator’s technical services. This plan builds on the resources and successful experience described in Paragraph III.1.
· Since no significant amount of work will be performed by subcontractors, no response is necessary for III.3.
ICANN’s criteria for accessing TLD Proposals considers several technical issues that will be extensively reviewed. The following table summarizes ICANN’s technical issues and JVTeam’s response.
TECHNICAL COMPONENTS OF SUCCESS |
||
Issue |
JVTeam Response |
Benefit to ICANN |
Maintain the Internet’s Stability |
||
Continued and Unimpaired Operation throughout the delegation period worldwide |
· A world-class SRS system architecture with co-active redundant data centers and nameserver data centers located worldwide |
The architecture provides the flexibility, scalability, and reliability to meet stringent service levels and workloads. |
Minimize unscheduled outages for registry or registration systems due to technical failures or malicious activity of hackers |
· Co-active redundant data centers with two-way replication and dual-homed telecommunications links to nameserver data centers · High-availability cluster architecture in each center · Internet firewall with intrusion detection, and stringent security authentication processes |
Architecture seamlessly handles hardware failures and natural and man-made disasters with near zero downtime and zero impact on Registrars |
Ensure consistent compliance with technical requirements in TLD registry operation. |
· Institute stringent Service Level Agreements (SLAs) covering performance. · Network and cluster-management software monitors and reports on these service levels. |
ICANN and the Internet community are kept continuously informed of our status in meeting the SLAs. |
Effects of the new TLD on the operation and performance of the DNS in general and the root-server system in particular. |
· Multiple new nameserver data centers dispersed globally and implemented with high-availability clusters, load balancers, and redundant components for “lights-out” operation. |
· Provides the Internet community additional DNS assets. · Enhances acceptance of the new TLD. · Provides resilience and disaster recovery. |
Rapid correction of technical difficulties and expansion of Whois information. |
· The Whois database is configured as a data mart off the master database with a high-availability cluster of Whois servers with load balancers to handle high query volumes. |
· Whois data is replicated from the master database to ensure accurate, consistent, and helpful domain-name information consistent with privacy rights. |
Protection of domain-name holders from the effects of registry or registration-system failure. |
· The co-active Shared Registry System data centers and the DNS nameserver data centers are configured to eliminate any possible single point of failure. · The database is two-way replicated between the SRS data centers. |
· Recovery from outages and disasters with near zero downtime and therefore zero impact on users. |
Provisions for orderly and reliable assignment of domain names during the initial period of the TLD registry’s operations. |
· Via FTP, each registrar submits a file of domain-name-registration transactions to the SRS data center each day for a 12-hour round-robin batch-processing cycle. At the end of the 12-hour period, the system informs each registrar of the status of the submitted domain names. The following day, the registrar submits a new list with resubmitted and new domain names. |
· Enables the SRS data center to manage the vast volume of domain-name registrations during the “Land Rush” phase. · Ensures fairness. |
The Enhancement of the Utility of the DNS |
||
Different operational models for registry – registrar functions. |
JVTeam proposes: · A new “fat registry” (thin registrar) model. · A new registry-registrar-protocol called eXtensible Registry Protocol (XRP) that offers expanded functionality and improved security and authentication services. |
Provides a greater level of functionality than the current Registry Registrar Protocol (RRP). |
Appropriateness of adding new TLDs to the existing DNS hierarchy. |
· Technical impact is minimal since new nameserver data centers are added to handle the increased workload. |
· Expands the utility of the Internet · Encourages competition · Provides consumers with alternatives to .com. |