PLAN (INCLUDING TRANSITION PLAN)
The third section of the .org Proposal is a description
of your technical plan. This section must include a comprehensive, professional-quality
technical plan that provides a full description of the proposed technical
solution for transitioning and operating all aspects of the Registry Function.
The topics listed below are representative of the type of subjects that
will be covered in the technical plan section of the .org Proposal.
Only NeuStar has the requisite combination of experience and skills in both the transition and the operation of a large registry system to ensure that the .org TLD is transitioned in a smooth and seamless fashion to a stable, robust, high-availability global registry infrastructure.
The transition of a large Internet TLD such as .org from one operator to another is not a trivial task. A successful transition and the continued operation consistent with technical, business, and policy mandates of the TLD requires that both the incumbent and the successor operator have an intimate understanding of the transition process and associated technical risks and requirements. Moreover, the new registry operator must have in place both stable, secure, high-availability registry infrastructure, as well as comprehensive, tested policy and business mechanisms to assume the complex day-to-day operations of a large TLD. Specifically, the new registry operator must:
Other applicants will offer solutions for one or more of these criteria based upon experience operating a registry. Only NeuStar, however, offers a solution that incorporates practical, non-theoretical experience in each of these criteria. All other proposals will include theoretical solutions based upon the applicant's experience in other aspects of registry operations, but lacking the important benefit of having been applied successfully in “real world” operations.
NeuStar's .org solution begins with a proven, high-availability, highly secure and stable existing registry platform. NeuStar's global registry infrastructure is home to the .biz and .us TLDs, and serves over 800,000 names of registered domain names in a near real-time robust environment. Added to this strong infrastructure is NeuStar's practical experience with the smooth transition of a multitude of live mission-critical registries. For example, NeuStar was responsible for the transition of critical numbering services. In particular, NeuStar successfully transitioned number pooling registries from vendors in multiple states in the U.S. in a timely and successful fashion. More importantly, however, NeuStar recently completed the highly successful transition of the existing .us ccTLD from VeriSign. This transition is directly analogous to the transition of .org, which will benefit from NeuStar's experience and lessons learned.
Finally, as the existing operator of registries governed by ICANN and the U.S. Department of Commerce, NeuStar has in place comprehensive, effective processes for the integration of important policy and contractual requirements. These processes will ensure continued compliance with the important requirements of the .org TLD, and ensure that the TLD continues to serve the global noncommercial community.
The following Proposal Sections—C17, C18, and C19—provide
complete discussions of the points summarized above.
Technical plan for performing the Registry Function.
This should present a comprehensive technical plan for performing the Registry Function. In addition to providing basic information concerning the proposed technical solution (with appropriate diagrams), this section offers the applicant an opportunity to demonstrate that it has carefully analyzed the technical requirements for performing the Registry Function. Factors that should be addressed in the technical plan include:
NeuStar’s proven registry architecture and technical plan for the .org TLD is the foundation for stability.
The ICANN correctly lists as its first criterion in the transition of the .org registry preservation of “the stability of the Internet, including the domain-name system (DNS).” Further, consideration will be given to “ICANN’s level of confidence that particular proposal will result in technically sound, high-quality services that meet the needs of .org registrants.” In developing a sound technical plan, there are a number of critical matters that the plan must address, including:
Although each of these requirements seems both obvious and seemingly easy to implement, the development of a comprehensive registry solution is a complex and resource-intensive undertaking. Not all applicants will be capable of addressing each of these matters in a comprehensive and efficient manner. NeuStar’s legacy is the development and provisioning of such highly complex systems within a reasonable timeframe and in a cost-effective manner.
NeuStar’s architecture comprises a comprehensive, next-generation
solution for critical Internet registry services. Detailed discussions
of each of these elements are contained in the following subsections.
General description of proposed facilities and systems.
Address all locations of systems. Provide diagrams of all of the systems operating at each location. Address the specific types of systems being used, their capacity, and their interoperability, general availability, and level of security. Describe buildings, hardware, software systems, environmental equipment, Internet connectivity, etc.
NeuStar has deployed a world-class registry infrastructure including redundant Shared Registration System (SRS) data centers in Sterling, Virginia and Chicago, Illinois USA and six nameserver sites geographically dispersed for diversity and global reach. Our facility locations were selected and engineered to provide diverse network connectivity and resilience against natural and man-made disaster scenarios. Our systems and hardware were selected to provide scalability, stability and security. ICANN and the .org community will benefit from the highly stable, secure, redundant, and scalable architecture of the NeuStar registry infrastructure.
In this section we will describe how NeuStar’s registry architecture
and infrastructure combine to meet the need of ICANN and the .org community
for a highly stable, secure, redundant and scalable solution. We will
address; registry facilities and locations, network connectivity, registry
system architecture and infrastructure, and system descriptions.
Registry facilities and locations
NeuStar’s registry architecture consists of redundant SRS data centers and six nameserver sites to provide a seamless, responsive, and reliable registry service to registrars and Internet users. As shown in Exhibit C17-1 our registry’s redundant SRS data center and nameserver sites are geographically dispersed worldwide and interconnected via a Virtual Private Network (VPN) to provide worldwide coverage and protect against natural and man-made disasters and other contingencies. In addition to the existing six nameserver sites, we will deploy two more nameserver sites—one in Europe and one in Asia—to provide additional global reach. The facility locations are provided in the following table.
The number and placement of our sites allows NeuStar to commit to the highest service levels in the industry. We believe these are the minimum service levels necessary for a registry such as .org with over two million names serving the critical needs of the global noncommercial community. Our substantial service level commitments include:
Each site is located in a modern, fire-resistant building that offers inherent structural protection from such natural and man-made disasters as hurricanes, earthquakes, and civil disorder. Facilities are protected by a public fire department, and have their internal fire-detection systems connected directly to the fire department. Data centers are additionally protected from fire by sprinkler systems, each equipment room is protected by a pre-action fire-suppression system that uses Inergen gas as an extinguishing agent. The important environmental factors at the SRS Data Center and nameserver sites are described below.
At NeuStar’s SRS data center locations employees must present badges to gain entrance, and must wear their badges at all times while in the facility. All visitors must register to gain entrance to any NeuStar facility. Visitors must display visitor badges at all times while they are in the facility, and must be escorted by a NeuStar employee. Visitor registration records are maintained for a period of one year.
NeuStar on-site security personnel are on duty 24 x 7 x 365 to monitor closed-circuit television cameras placed strategically throughout the facilities. Security personnel are stationed at each building-access point throughout normal working hours; at other times, employees must use authorized electronic key cards to gain access to the buildings. Further, any room housing sensitive data or equipment is equipped with a self-closing door that can be opened only upon activation of a hand geometry reader. Senior facility managers establish the rights of employees to access individual rooms, and ensure that each reader is programmed to pass only authorized individuals. The hand geometry readers compile and maintain an access record.
For co-located nameserver sites, NeuStar has leased a separate
room from all other tenants with its own access point to house its registry
infrastructure. Access to NeuStar’s room is as strictly enforced as it
is at NeuStar’s SRS data centers. The co-location facility provider is
given a limited list of authorized individuals granted access to NeuStar
facilities. NeuStar employees are responsible for accepting or denying
access. Visitors sign in and must wear a badge while on the premises.
They are escorted either by NeuStar personnel or personnel provided by
the co-location facility. Security personnel are located at each entrance
point to the building and individuals must present the proper credentials
to gain access. Each location is monitored on a 24 x 7 x 365 basis by
the facility provider’s NOC. In the event of an alarm associated with
NeuStar’s room, the facility provider’s NOC will contact NeuStar’s NOC
to seek further direction related to the event.
NeuStar uses the Internet to provide connectivity to the Registrars and a Virtual Private Network (VPN) to provide a secure Registry Management Network for communications between the SRS data centers and the nameserver sites. Each nameserver site will be connected to the Internet independently of the other sites.
Internet connectivity – SRS data center
Internet connectivity—nameserver site
VPN registry management network
The links between the data centers are used for:
The VPN between the data centers and the nameserver sites is used for:
Zone file updates;
Building LAN backbone
Registry system architecture and infrastructure
NeuStar has deployed a world-class registry architecture to support its current registry service. The NeuStar architecture was designed:
NeuStar’s registry architecture represents superior next generation
design among the best in the industry.
Shared registration system (SRS) data center
As depicted in Exhibit C17-3, NeuStar has created a highly robust five-layer SRS architecture for its registry solution. This architecture is duplicated in both data centers. The five layers are:
NeuStar’s SRS is the only registry system to ever have performed a first come first serve (FCFS) “landrush”. To address service failure concerns, all landrushes prior to NeuStar’s launch of the expanded .us, have been performed in an off-line batch mode. This is a different registration process than the real-time process to which registrars and consumers have become accustomed. Recognizing the needs of the domain name community NeuStar built its registry to be able to support a real-time landrush. NeuStar’s SRS operated during FCFS landrush exactly as it would during normal operations (with the exception of some additional network monitoring). The SRS was able to support a peak demand associated with 30,000 registrations in one hour during the FCFS landrush and a total transaction load of five million transactions in the first 24 hours.
This existing infrastructure will serve as the core for the .org registry. Upgrading the existing NeuStar registry to support .org is primarily a matter of adding RRP servers at the protocol and application layers.
External network layer
In addition to the security provided by each of these servers, there is an Intrusion Detection System (IDS) that works cooperatively with all of this equipment as well as the equipment at the internal network layer. The IDS monitors and logs every packet that enters and leaves the data center. Most IDSs simply monitor ingress; NeuStar’s also monitors egress. This is used to detect, among other things, the possibility of a hacker trying to use a NeuStar site to launch a denial of service attack. After logging the packets, the IDS performs sophisticated data analysis including, audits, statistical analysis, and checks against a negative list of known bad actors in an effort to detect a security breach. Once a breach is detected the IDS can work with any combination of the servers in the layer to isolate the attack and filter the packets.
RRP servers—RRP transactions received from registrars over the Internet undergo front-end processing by the RRP Server which manages the RRP session level dialog, performs session level security processing, and strips out the transaction records. These RRP transaction records are sent to the application server cluster for security authentication and business logic processing. These are the servers that will interface with the registrars for the purposes of managing their registrant’s domain names. This is the only functionality that needs to be added at this layer to support the .org domain.
EPP servers—These servers interface with the current registrars of NeuStar’s existing registry service for the purposes of processing EPP transactions. .Org registrars will be migrated to these servers when the .org registry is migrated from an RRP interface to an EPP interface.
Whois database servers—The Whois database provides information pertaining to the domain name holder.
Web servers—A high capacity secure Web Server cluster is provided to enable secure web services and information dissemination that is outside the scope of the RRP protocol. It contains a registry home page to enable registrars to sign in and inquire about account status, obtain downloads and whitepapers, access frequently asked questions, obtain self help support, or submit a trouble ticket to the .org registry help desk.
Internal network layer
The internal network layer, like the external network layer, also works in conjunction with the IDS. These two security and traffic management layers coupled with the IDS create a State-of-the-Art security architecture for data centers.
NeuStar will deploy the RRP application servers to support the .org domain. .Org service will be migrated to the EPP application servers in this layer when the .org registry migrates from an RRP interface to an EPP interface.
.org database—The database has been purposely designed to reside behind multiple levels of security. Each database server consists of two identical Fault-tolerant RISC systems that are designed for high volume on-line transaction-processing database applications. A multi-session, multi-threaded server and dual cache architecture (client/server) provides exceptionally high throughput and fast access to stored objects. The database enables transparent database failover without any changes to application code or the operating system. Updates at the primary data center are replicated to the database servers in the back-up data center.
Zone file distribution administrator—The zone file distribution administrator polls the .org database for updates. It then passes updates on to the master nameserver.
Master nameserver—The master nameserver receives updates from the zone file distribution administrator and then updates the clusters of nameservers in the six, soon to be eight, nameserver sites. This is not to be confused with a primary nameserver in DNS terminology. The master nameserver does not receive DNS queries from resolvers on the Internet. It is strictly for NeuStar’s internal administrative purposes. Updates are processed from the .org database to the nameserver sites in less than 15 minutes.
Whois distribution administrator—The Whois distribution
administrator polls the .org database for updates. It collects updates
and then distributes them to the Whois databases located at the primary
and back-up data centers.
There are six nameserver sites in NeuStar’s registry architecture. We plan to deploy two more sites, one in Europe and one in Asia, to provide additional diversity and global reach to the .org community.
Each nameserver site is equipped with a router, firewall, load balancer, and a cluster of nameservers. NeuStar’s nameserver architecture is one of the few TLD nameservers that includes a firewall. This provides an additional level of security above and beyond the basic level of security provided in the DNS protocol. The combination of a nameserver cluster behind a load balancer provides a highly scalable solution. Additional capacity can simply be added by adding another nameserver to the cluster. The nameserver architecture is depicted in Exhibit C17-9.
NeuStar utilizes moderate-level, mid-level, and high-end cluster server platforms for installation at each site. The servers are selected for applications depending on the requirements, storage capacity, throughput, interoperability, availability, and level of security. These server platform characteristics are summarized in the following table.
Registry-registrar model and protocol.
Please describe in detail, including a full (to the extent feasible) statement of the proposed RRP and EPP implementations. See also item C22 below.
To ensure the highest levels of stability and equal access for all .org registrars, NeuStar will implement a fully functional RRP implementation for the transition of .org and will migrate all registrars to the EPP protocol upon its adoption as an IETF Proposed Standard.
NeuStar is dedicated to the development and implementation of open industry standards. Common, well-documented interface protocols are critical to the overall stability of the Internet. Therefore, NeuStar is an active participant in and contributor to the IETF Provreg Working Group which is developing the open EPP protocol for registry-registrar interfaces. In fact, NeuStar’s registry has a truly EPP-04 compliant interface. Most other EPP implementations reflect either earlier versions of EPP or are incomplete EPP-04 implementations. Thus, implementation on the NeuStar platform of the most current version of the EPP protocol already is complete. The larger issues for .org are the appropriate timing of a migration from RRP to EPP, and the technical issues associated with such a migration, particularly for the registrars that must develop new registry interfaces. The details of NeuStar’s proposed migration to EPP for the .org registry is contained in Proposal Section C22 of this proposal.
To ensure the continuing stability of the .org registry for the existing .org registrars, NeuStar will implement a fully functional, standard implementation of the RRP protocol that will be used by all registrars prior to migration. This implementation will comply with both the standard and the RRP toolkit in use by the registrars at the time of transition. Even though RRP is a proprietary protocol, it is well documented and understood. It is documented as an IETF Informational RFC (RFC 2832) and VeriSign distributes copies of an RRP toolkit to its registrars. As of the writing of this proposal, VeriSign intends to update RRP to Version 2.0.0. NeuStar’s implementation of RRP will, of course, track such updates and any new tools used by the registrars.
Once IETF has issued EPP as a Proposed Standard, NeuStar
will begin the migration of registrars from RRP to EPP, as discussed in
Proposal Section C22. Of course, consistent with NeuStar’s practices,
the then most current version of the EPP protocol will be implemented.
Database size, throughput, scalability, procedures for object creation, editing, and deletion, change notifications, registrar transfer procedures, grace period implementation, reporting capabilities, etc.
The heart of the SRS is its database systems, which provide not only simple data storage-and-retrieval capabilities, but also the following attributes:
As application architectures, such as our SRS, become increasingly dependent on distributed client/server communications and processing, system designers must carefully architect data processing occurs whether it’s on the database server, applications server, or the client server. Our final design distributes the processing workload in a way that maximizes scalability and minimizes down time.
For purposes of clarity, NeuStar’s response to item C17.3 address each of the three core SRS databases; i.e., .org, billing and collection (B&C), and Whois; and includes:
C17.3.1 Database functional overviews—Describes the characteristics of the SRS databases (i.e., size, throughput, and scalability); database procedures and functions for object creation, editing, and deleting; change notifications; transfer procedures; grace-period functions; and reporting.
C17.3.2 Database system descriptions—Describes the database system components, server platforms, and scalability.
C17.3.3 Database security and access privileges—Describes the access controls for granting and denying users and administrators access to the databases.
Database functional overviews
NeuStar’s registry will include three major databases
In addition to these databases, the registry will maintain various internal databases to support various operations, e.g., authorizing login userIDs and passwords, authenticating digital certificates, and maintaining access control lists.
In implementing the .org database systems, our system designers will carefully analyze the differing requirements for the three major databases and select the optimum solution for each. Design techniques and considerations will include:
Database size, throughput, and
Attributes of all database servers are:
Database procedures and functions
Object creation—Domain name and nameserver registration;
Object editing—Modifying domain name or nameserver data and creating or modifying associations;
Object deletion—Domain name cancellations;
Object existence and information query—Obtain information on domain name or nameserver;
Object transfer—Transfer a domain name to a different registrar;
Automatic domain renewal—Extend a domain name registration for a year;
Grace period implementation—Allow various time periods before actions become final;
Registrar administration—Add, delete, or change to a registrar account or billing profile;
Account-related information—Billing information provided to registrars and designated registry staff;
Reporting—Account and billing information that can be viewed on line or via e-mail; and
Operations on objects
Since the .org registry will be a “thin” registry during the transition these object operations will be sufficient to ensure a seamless transition of the .org registry and to maintain the stability of the domain name systems for the Internet.
In terms of the registry-registrar interface, both RRP and EPP have corresponding commands to support these six object operations. RRP is the protocol currently used for the .org registry, while EPP is the upcoming IETF standard that is being used by a number of registries including NeuStar. Proposal Section C22 further discusses the migration strategy for the .org registry-registrar interface.
Grace period implementation
We also support ICANN’s policy on overlapping grace periods. We are participating in and following ICANN’s progression redemption grace period for delegated names and will implement the resulting solution.
Registrar transfer procedures
The transfer steps are as follows:
The losing registrar may deny the transfer request by replying to the “transfer” request with a negative acknowledgement (or NACK) within five days of the initial transfer request.
NeuStar has been active at ICANN with regard to efforts to modify this process or the policy related to this process. We commit to implementing whatever changes are required by the registry to meet the agreements reached at the conclusion of this effort.
Monthly account statements—NeuStar will send a detailed monthly transaction statement to each registrar via e-mail. The statement will include the following:
Online B&C reports—The B&C system will generate a variety of reports for internal and external users.
Audit reports—NeuStar will create audit reports for internal and external purposes. Audit reports will include:
Database system descriptions
Although the three primary SRS databases—.org, Whois, and B&C—will differ, depending upon the services they support, the SRS on the whole, will be structured to:
NeuStar forecasts that, as with most online transaction processing (OLTP) applications, the anticipated volume of SRS transactions will have a high ratio of “reads” to “writes.” We will design the databases and applications by partitioning the workload to improve response times and scalability.
NeuStar will configure the database system to provide appropriate response times for the transactions that registrars perform. We will do capacity planning to ensure that as business requirements increase and demand for domain names grows, the system will be able to easily handle the workload within agreed response times.
Database security and access privileges
Proposal Section C17.9 explains NeuStar’s security measures in detail. The major technical security related controls on the database platforms to ensure data integrity and security include the following:
Zone file generation.
Procedures for changes, editing by registrars, updates. Address frequency, security, process, interface, user authentication, logging, data back-up.
Zone file generation and distribution represents the core function of the registry. NeuStar developed an enhanced, near real-time zone file update process for .biz and .us that has greatly improved zone file service for both. .org will directly benefit from this next-generation registry capability. The remainder of this section compares and contrasts the traditional method with NeuStar’s dynamic, streamlined approach.
Traditional zone file generation process
The current file generation process has caused many problems for both registrars and registrants. Registrants, in particular, have been troubled by the long delay before their registered domain names “go live” (or are re-delegated). Common issues with the current process include:
Improved zone file generation process: the NeuStar solution
NeuStar has created a function within the registry called a zone file distribution administrator, as depicted in Exhibit C17-10. This administrator polls the .org database for updates on a regular basis. When it has accumulated a certain number of updates or a certain time limit has passed, it will create a file of incremental updates and initiate the process of incrementally updating the zone files hosted in the nameservers. The update process is explained in more detail in Proposal Section C17.5.
NeuStar will generate zone file updates at regular intervals within defined service levels. Any real-time zone file update procedure must not degrade the performance of the core registration system. NeuStar’s solution will enable us to agree to service levels that guarantee the frequency of zone file updates within defined intervals without adversely affecting standard registration operations.
Logging and data back-up
Zone file distribution and publication.
Locations of nameservers, procedures for and means of distributing zone files to them. If you propose to employ the VeriSign global resolution and distribution facilities described in subsection 5.1.5 of the current .org registry agreement, please provide details of this aspect of your proposal.
Traditionally, zone file updates in .org have been performed by writing-over the existing zone file with a new zone file that included any updates. The new zone file was updated in the primary nameserver; the primary nameserver would then update the secondary nameservers. Upon notification, a secondary nameserver would request the start of authority (SOA) record from the primary nameserver. If the serial number of the zone file was greater than that on the secondary nameserver, the secondary nameserver would initiate the zone transfer procedure. If a secondary nameserver has not received a notification from the primary nameserver for a predefined period, it would request the SOA record from the primary nameserver and follow the same procedure as just described.
The problem with this process is that it relies on a complete new file for an update. This approach is cumbersome and places a heavy load on the nameservers. For these reasons, zone file updates have been traditionally limited to once or twice a day. The current .org nameservers are only updated twice a day.
The .org community would benefit from more frequent updates of the zone file. This would reduce synchronization problems that occur between the Whois, the .org database (for check domain), and the zone file. It would also allow for less downtime for the registrant when transferring e-mail or web hosting services from one provider to another. The incremental zone file generation process defined in Proposal Section C17.4 is the first step required to allow more frequent updates to the zone file.
Locations of nameservers and process of distribution
The master nameserver performs only one function—it updates the constellation of NeuStar nameserver sites shown in Exhibit C17-11. The master nameserver does not receive and respond to DNS queries from the Internet. It is the interface between the zone file distribution administrator and the nameservers that do receive and respond to DNS queries from the Internet. We prefer not to call this the primary nameserver because we’ve designated a.gtld.biz to be the primary nameserver in our TLD start of authority (SOA) resource records.
Our central network management system will log all modifications to the .org database, all zone file-update actions, and all attempts at intrusion or other security-related events. The master nameserver interconnects to the other nameservers over a secure IPsec-compliant VPN, with the exception of one nameserver cluster that is co-located with the master nameserver at the SRS data center. That nameserver cluster is updated over the internal high-speed LAN. Access to the VPN requires userID and passwords. Passwords are rotated frequently.
NeuStar will not employ the VeriSign global resolution and distribution facilities described in subsection 5.15 of the current .org registry agreement.
Billing and collection systems.
Technical characteristics, system security, accessibility.
NeuStar’s proven experience in successfully selecting, implementing, and operating complex billing and collection (B&C) systems for communications and domain name registry services ensures our registry operator’s B&C services will be feature rich, accurate, secure, and accessible to all registrars.
The fundamental goal of the system is to maintain the B&C data and create reports which are accurate, accessible, secured, and scalable. B&C will enable detailed transaction-based charging to the customers, based on extensive resource accounting and usage data recording performed in the registry. The B&C system must produce timely and accurate account statements and billing reports that are accurate, easy to understand and contain only clearly defined charges for the services rendered. Such account statements are ultimately more economical because they are less likely to provoke costly billing disputes.
NeuStar’s simple B&C process, as depicted in Exhibit C17-12, is based on debit accounts established by each of our registrar clients. We will withdraw all domain registration service payments from the incurring registrar’s debit account on a per-transaction basis. We will provide fee-incurring services (e.g., domain registrations, registrar transfers, domain renewals) for a registrar only so long as that registrar’s account shows a positive balance. The B&C system will be sufficiently flexible to adapt to different billable events, grace-period implementations, and pricing structures, as the need arises.
NeuStar’s B&C system will be located at the two redundant SRS data centers in Sterling, VA, USA and Chicago, IL, USA. These systems will handle the key B&C functions, including:
B&C system technical capabilities and characteristics
NeuStar has developed a B&C solution to ensure data processing accuracy, accessibility, flexibility, and scalability to accommodate increasing transaction volumes and additional billable events. Our financial and technical experts are experienced in customizing systems to evolve smoothly from performing simple to more complex tasks, and from small-scale to large-scale operations. We selected this solution after conducting a detailed analysis of the options for administering the registry’s B&C system. The system will be operational in time for the transition and will meet all .org B&C requirements, including:
B&C system description
Transaction processor—This processor, which responds to inputs from the external application server and from the B&C operations GUI, is the only component that has access to update the B&C database. The transaction processor will process transactions in real time, responding to API calls from application servers, and will also process transaction log files obtained from external servers. The transaction processor has two main subcomponents:
B&C database—This database, which is separate from the .org database, contains the data shown in the following table. Proposal Section C17.3 discusses the capabilities, management, administration, and backup of all databases, including the B&C database. This subsection discusses only the design aspects of the B&C database.
Monitor and notifier—This component monitors the registrars’ accounts for sufficient funds and monitors domain name expirations and renewals. When it detects actionable items, it notifies the transaction processor and the registry’s customer service organization.
Report generator—This component will generate monthly account statements and various reports, including annual reports. This is also the component that customer service will use to generate custom reports requested by a registrar. After generating custom reports in a batch process, the report generator sends them to the FTP directory, where they are stored for the registrar to download.
The following tables provide details of each type of process flow.
B&C system security
Proposal Section C17.9 provides extensive details about security issues, including system, network, and physical security, including specific issues such as access control, authentication, and authorization. This subsection discusses only security provisions that are specific to B&C. Like the overall registry system, the B&C system will implement security at the network, system, and user levels, as follows:
Network-level security—The primary network-level communications technology underlying the B&C system is the IP protocol. The only interfaces that have access to the B&C system are the Secure Web GUI to monitor account status and the FTP server to download reports. A firewall forms the secure interface between NeuStar’s secure internal network and the public Internet. Firewalls use filters to permit or deny packet flow on the basis of the origin and/or destination of the packet’s addresses and ports.
Users who want to obtain access to the Secure Web portal that we provide to the registrars must first obtain access to the Secure Web server within the SRS. When the user’s Web browser attempts to establish an HTTPS (secure web application protocol) session with the registry, our system initiates the SSL (secure sockets layer). Part of the initialization sequence is a public key exchange or identification. Once the SSL initialization is complete, it establishes a secure, encrypted channel between the user’s web browser and the registry’s web server, and exchanges digital certificates to ensure the integrity and authenticity of the session. The use of a secure web browser/server ensures that no clear text, including passwords, is sent over the public or shared-data network.
System-level security—Secure user login facilities ensure that Secure Web Server users are fully authorized and authenticated. The SRS Secure Web Server presents a login menu on the user’s Web browser. The login menu includes 20 lines of warning message stating that this is a private computer system and authorization is required for access.
When users attempt to log into the Secure Web server, they must enter their userID and password. The login/password information forwarded back to NeuStar’s registry web server is encrypted through the secure SSL channel previously established.
User-level security—Every B&C system user (individual and application, external and internal) has a unique user login account on the system, with unique user-identification codes (userIDs) and passwords to authenticate the user and an access control list to control his/her access to system resources and applications. User profiles are set up and maintained in the database system so that user access to the B&C system is controlled by their user profile and the access privileges granted therein. NeuStar has established well-defined security procedures for adding and deleting users and modifying their logon account, access control lists, and user profile access privileges depending on the user’s functional role. The following subsection, “Access Privileges,” contains additional information about user roles and privileges.
B&C system access privileges
The B&C system and network employ multi-tiered access control to ensure that all B&C resources—transactions, data, etc.—are only accessed and used by authorized users. As previously discussed, access to the proposed B&C system via the network is fully secure behind a perimeter firewall and userID and password system, while physical access is controlled using electronic keys and palm readers. Once an authorized user gains access to the system, their privileges are controlled by the operating system access control lists and the database system user profile that determines what functions, system resources, and data the user is allowed to access and use. Access privileges are broadly defined and controlled and limited to registry employees and registrars. The following subparagraphs discuss the access privileges.
Each internal user of the B&C system is also associated with a user role that will permit or deny his access to different functions in the B&C system. The system administrator will create roles and allow them to access certain functionality. We have defined user roles within NeuStar’s B&C-operations organization as follows:
Adjustments—For billing issues or adjustments in profile or account statements, registrars must contact NeuStar’s customer service organization via e-mail, phone, or fax. The B&C manager has the capability of performing any billing adjustments or similar services requested by a registrar.
Notifications and statements—The registry will e-mail to each registrar a detailed monthly transaction statement, an account summary, and a detailed list of all fee-incurring charges. In addition, the B&C system will e-mail “Low Account Balance” and “Insufficient funds” notifications to any registrar when needed.
B&C system backup and recovery
NeuStar will employ the same backup and recovery procedures for the B&C system that is used for the overall registry system. Proposal Section C17.7 describes these procedures in detail. They include:
If the B&C system fails (i.e., the API interface to the application returns an “Error status”), a built-in recovery mechanism will ensure against loss of transactions and data as follows: the application server will log all undeliverable B&C transactions, with transaction identifiers, to an internal file. After the problem is corrected, the file will be transferred to the restored B&C system for processing.
NeuStar will provide the infrastructure to collect all data needed for accounting upon request and auditing reports that meet commercially accepted standards, and will provide this data to ICANN-designated auditors upon request. Data will be available for the current fiscal year and for an agreed number of preceding years. NeuStar will assist ICANN auditors by providing all required statements and reports. Annually, NeuStar’s internal auditors will audit the registry’s B&C system, records, and supporting documentation to verify the accuracy of billing for registry services.
Data escrow and backup.
Frequency and procedures for backup of data. Describe hardware and systems used, data format, identity of escrow agents, procedures for retrieval of data/rebuild of database, etc.
Given the potentially devastating effects of such a failure, NeuStar, of course, seeks to avoid ever having to utilize its recovery plans. NeuStar’s first line of defense against data loss is its highly secure, redundant registry infrastructure. Responsible operations, however require a recovery plan.
Data recovery procedures must address both small-scale failures as well as more serious total system failures. The goal of any data backup and recovery procedure is full recovery from failures without any loss of data. Data backup strategies handle system hardware failures (e.g. loss of a processor or one or more disk drives) by reinstalling the data from daily backups, supplemented by the information on the “before” and “after” image-journal backup files that the database creates. More serious failures require more aggressive solutions.
The conventional strategy for guarding against loss of an entire facility because of fire, flood, or other natural or man-made disaster is to provide off-site escrow of the registry data in a secure storage facility. Even when successful, this recovery strategy does not prevent the loss of a certain volume of transactions between the time the data was backed up and the occurrence of the disaster. Users are subject to loss of service during the time required to recover the data center database and/or reestablish operations at an alternate disaster-recovery site. Relocating the data center normally requires at least 24 hours, and the escrowing of full backups are done only weekly, meaning that a disaster could result in substantial loss of both services and data. The recovery from daily incremental backups requires additional recovery time. Reducing the risks for data loss.
NeuStar’s solution utilizes two SRS data centers operating in a primary/back-up failover mode. Each SRS data center is capable of handling the entire workload should a major system failure or natural or man-made disaster occur at the other. The transactions from the active data center are synchronized in near real-time with the hot-standby database over a redundant high-speed direct telecommunications links. The active SRS data center conducts full database snapshots from a third mirror of this data twice a day and back up all database transaction logs, as described in the following paragraph. Since the two SRS data centers are synchronized, our back-up strategy maintains continuity of operations and enables full recovery of all transactions, even in the event of multiple hardware failures.
Frequency and procedures for backup of data
The active SRS data center implements a zero-downtime/zero-impact incremental data backup each day, and a full data backup weekly. We copy static data (e.g., the operating systems, BIND software, applications software) to CD-ROMs for quick reload, should that become necessary. We back up to high capacity DLT storage tapes any dynamically changing files (e.g., log files vital to system maintenance and operation, database files, database-journal files, software configurations). Weekly, we perform full-system backups to DLT tape of all databases identified in Section C17.3 (.org DB, Whois, Billing). We will place escrow copies of the backup tapes in a secure off-site storage facility operated by a third party whose business is data escrow.
The backup procedures include the following 4 steps:
Backup hardware and software systems
Exhibit C17-14 depicts the SRS data centers’ backup process. Each data center’s system includes two backup servers with DLT robotic tape libraries. To achieve zero-downtime/zero-impact backup, we use a RAID disk array and a high-speed fiber, channel bridge interconnect to the robotic tape libraries. The backup server copies not only the database server’s backup files to the disk array, but also the backup files of the cluster servers. During the few minutes this process requires, applications still have access to the cluster servers and database server. Then the backup server copies the files to the DLT robotic tape device. This approach ensures that we meet our Service Level Commitments.
Procedures for retrieval of data/rebuild of the database
We maintain a three-tape rotation to maximize efficiency and effectiveness:
The full backup tapes are maintained in a 2-tape rotation,
with one tape at the secure escrow facility and one at the active data center
for reuse. A copy of the static-data
In the event of an outage at the primary data center service will failover to the back-up data center. The back-up data center will have a current copy of the .org database due to the data base synchronization process. The back-up data center will assume the primary data center’s role and continue SRS operations with the near-zero downtime. The following steps will be taken to restore the primary data centers:
This backup procedure enables NeuStar to meet the service-level agreements required for continuous availability and near-zero unplanned downtime, maintaining stability, enhancing public confidence, and improving customer satisfaction.
NeuStar has reached agreement with Iron Mountain for the third-party provision of data escrow services. Founded in 1951, Iron Mountain is an Industry leader in data storage and escrow services.
Publicly accessible look up/Whois service.
Address software and hardware, connection speed, search capabilities, coordination with other Whois systems, etc.
One of the critical functions of a registry is the Whois. Whois is an administrative tool that provides identifying information related to the domain name. The protocol is defined in RFC954. It will be available to anyone via the IANA-assigned port 43 or the .org registry website.
NeuStar’s current Whois supports a “thick” registry model and the .org Whois supports a “thin” registry model. The thick registry contains contact information associated with the registrant, whereas the thin model does not. NeuStar will have to modify its processes associated with Whois and its Whois database for this difference.
The Whois service will accommodate queries regarding the data sets listed in the following table.
Whois system architecture
Each Whois server is equipped with a full copy of the Whois database. At each SRS data center, a load balancer to a cluster of two Whois servers distributes incoming queries. The load balancer can also re-route the Whois traffic to its counterpart in the other SRS site if the Whois servers on its site are down. This configuration will provide both redundancy and scalability through the addition of servers to either cluster. Exhibit C17-16 depicts the update process for the Whois databases.
As the .org database is updated, the system will also update the Whois distribution administrator in real time. This happens on the active SRS site. Incremental changes made to the Whois distribution database will be propagated to the Whois databases in each Whois cluster in near real time (e.g., no greater than 15 minutes). Propagation of Whois information between data centers always occurs over the secure VPN.
The proposed Whois architecture and process offers the following benefits:
Attributes of the Whois servers are:
These guidelines will be compared with actual usage data and adjusted accordingly.
We will engineer the Whois service to provide the following average service levels:
We will scale the exact number of Whois and database servers deployed in each cluster and at each data center to maintain the specified service levels.
Coordination with other Whois
Full data sets would be provided on a weekly basis and incremental updates would be performed on a daily basis. NeuStar will deploy an FTP (file transfer protocol) server available for the purposes of exchanging the Whois data sets.
Technical and physical capabilities and procedures to prevent system hacks, break-ins, data tampering, and other disruptions to operations. Physical security.
High profile Internet operations such as Shared Registration System (SRS) and nameserver sites are subject to a wide range of security threats; including hacking, break-ins, data tampering, denial of service, and physical attacks against the facility. Further, because the registry will contain proprietary data from competing registrars, security procedures must incorporate user-authentication procedures that ensure each registrar’s files are available only to its own personnel. Failure to address these security threats creates the risks of unscheduled down time and the disruption or denial of services.
NeuStar’s registry solution incorporates comprehensive system security for our networks, servers, applications, and customer support services. Our security architecture is a policy-based, multi-tiered system based on proven industry standards. Our solution, highlighted in the following table, integrates the following security features to provide assurances that multiple security threats or attacks will be unsuccessful:
SRS data center
NeuStar operates highly secure redundant data centers to provide the highest levels of security and service availability.
Network security - two layers of security
Generally, data centers typically fit into one of the following three categories with regard to network connectivity:
An Internet registry fits into the third category because its nameservers receive and send traffic to the general public and its SRS data center connects to its registrars over the public Internet. Because the data center is connected to the public Internet, it is the hardest to protect from a security perspective. NeuStar has designed a state-of-the-art architecture when it comes to protecting the data center from attacks that can originate on the public Internet.
NeuStar has deployed a five-layer architecture at its SRS data centers as depicted in Exhibit C17-17. This architecture is duplicated in both the primary and back-up data center. The five layers of the architecture are:
The two Network Layers—external and internal—are dedicated to security and traffic management. The equipment at these layers work together with an Intrusion Detection System (IDS) to provide an even greater level of security.
The External Network Layer is the point where NeuStar interconnects to the Internet. Each SRS data center is served by two ISPs. The External Network Layer consists of four redundant servers each performing its own security or traffic management and security function:
After the Protocol Layer is the Internal Network Layer. The Internal Network Layer is in place specifically to manage traffic between the Protocol Layer and the Application Layer and to detect and deter any security breach in the unlikely event that it makes it past the first two layers (security at the Protocol Layer is addressed in the server and application security sections). The Internal Network Layer consists of redundant firewalls and load balancers. These serve the same security functions identified for the External Network Layer.
In addition to security provided by each of these servers, there is an Intrusion Detection System (IDS) that works cooperatively with all of this equipment. The IDS monitors and logs every packet that enters and leaves the data center. Most IDSs simply monitor ingress; NeuStar’s also monitors egress. This is used to detect, among other things, the possibility of a hacker trying to use a NeuStar site to launch a denial of service (DOS) attack. After logging the packets, the IDS performs audits, statistical analysis, checks against a negative list of known bad actors, etc. in an effort to detect a security breach. Once a breach is detected, the IDS can work with any one of the elements in the two layers to filter and cut off the attack.
These two layers, coupled with the IDS, create a state-of-the-art security architecture for data centers that interconnect to the public Internet.
The SRS operating systems provide access protection through a user login procedure and through file-level access-control lists. These access-control mechanisms perform the following functions:
The SRS operating systems will perform security-relevant logging functions, including:
The following provisions apply to passwords:
Each SRS application will have its own set of security processes and technical controls. The SRS applications that interface with the registrars (e.g., the RRP and the Secure Web Customer Service portal) employ the SSL (secure sockets layer) protocol element that uses public-key exchange and RC4 encryption. Public services (e.g., Whois, DNS queries, and the public Internet Web portal) rely on the previously discussed network perimeter-security devices—edge routers, firewalls, and load balancers—to protect the internal LAN and applications servers.
Security related to applications include:
Nameserver site security
NeuStar’s approach to nameserver security is a subset of the security mechanisms we employ at the SRS data centers. NeuStar’s nameserver sites are one of the only TLD nameservers that utilize a firewall for security. Most registries believe the inherent security of the DNS protocol provides sufficient security. NeuStar believes that the importance of the service being provided demands the utmost level of security. Like the SRS data center, the Nameserver site security also relies on multi-layer perimeter protection, controlled access, enforcement of applications security features, and strong physical security protection. Exhibit C17-18 depicts NeuStar’s nameserver architecture.
The same mechanisms used for the SRS data center are employed at the Nameserver sites. Edge routers and firewalls provide perimeter protection for the data-center network and applications systems, guarding against unauthorized access from the Internet.
The SRS data centers are connected to the nameservers over
an IPSec VPN to perform database updates at the nameservers, network-based
backup/restore, remote system/network management, and system administration.
Keys used to access the VPN are rotated frequently. VPN technology achieves
secure data transfer through encrypted data-communications links.
The nameserver operating systems provides access protection for remote system administration through a user login procedure and through file-level access-control lists. These access-control mechanisms perform the following functions:
User-account security—Establishes the access capabilities of a specific system administration authenticated user. After authenticating the user, the operating system’s access control lists control access to information.
System administrator level securityRestricts access to system administration tools, including the ability to change resource-access privileges. Nameserver system-administration staff use dedicated links on an internal LAN/WAN to access administrative functions that are off-limits to others. There is no external access to this LAN. All sessions require user identification by user name and password; access control lists determine what resources a user or user group is allowed to access and use.
The nameserver operating systems will perform security-relevant logging functions, including:
The nameserver essentially enables the public, via the
Internet, to make DNS queries. Public services, such as DNS queries, rely
on the previously discussed network perimeter-security devicesedge
routers, firewalls, and load balancersto protect the internal LAN
and application servers.
NeuStar vigorously enforces physical-security measures, controlling all access to our facilities. Throughout normal working hours, security personnel stationed at each building entrance verify that employees are displaying proper identification badges and control access by non-employees. Non-employees must sign in to gain entrance; the sign-in books are stored for a period of one year. If the purpose of his/her visit is found to be valid, the non-employee is issued a temporary badge; otherwise, he or she is denied entrance.
At all times while they are in the facility, visitors must display their badges and must be escorted by a NeuStar employee. We also strictly enforce the policy that employees must wear their badges prominently displayed at all times while in the facility.
During off-hours (6:30pm to 6:30am and all day on weekends and major holidays), individuals must use the proper-electronic key cards to gain access to the building. We issue electronic-key cards only to employees who need access for business purposes. Further, any room housing sensitive data or equipment is equipped with a self-closing door that can be opened only by individuals who activate a hand geometry reader. Senior managers establish the rights of employees to access individual rooms, and ensure that each reader is programmed to pass only those authorized individuals. We grant access rights only to individuals whose duties require them to have hands-on contact with the equipment housed in the controlled space; administrative and customer-service staffs normally do not require such access. The hand geometry readers compile and maintain a record of those individuals who enter controlled rooms.
Access in and out of the data centers is monitored 24x7x365
by the network operations center (NOC). All access is recorded and stored
for three days on digital video. There are audible alarms on doors in
the event of unauthorized entry or if the doors are kept open for more
than 30 seconds.
Technical capability for handling a larger-than-projected demand for registration. Effects on load on servers, databases, back-up systems, support systems, escrow systems, maintenance, personnel.
NeuStar has built capacity into our existing registry to support estimated peak traffic demand. Our network connectivity has been designed to automatically scale as demand increases and our servers (SRS and nameserver) have been designed in a cluster configuration to easily and seamlessly add capacity. Furthermore, we have implemented two layers in our registry architecture dedicated to security and traffic management to be able to manage highly volatile traffic demand. The peak load capacity and built-in scalability of the NeuStar registry ensures ICANN that adequate capacity is available to handle the current and future demand of the .org registry.
To avoid creating bottlenecks for SRS, Whois, and nameserver services, NeuStar will engineer for peak usage volumes, based on the most recent statistics published for the .org registry. In addition, NeuStar will deploy redundant SRS data centers and a network of nameserver sites that are sized to handle the current peak volumes. Subsequently, we will add additional nameservers to handle the anticipated growth. Our SRS, Whois, and nameserver architectures are designed with highly scalable server clusters and connected through networks that can be smoothly scaled up without disrupting the system. Expansion provisions include the following:
SRS peak capacity
Network—The RRP peak transaction load is projected
to be 350 transactions per second (tps), or a little more than 1.2M transactions
in a peak hour. Our registry’s network connectivity has enough capacity
to support transaction six times that volume or 2,100 tps. The average
transaction size is 5,000 bits, which translates to a required telecommunication
capacity of 10.5 MBPS. Our external communication network connectivity
to the Internet is two T-3 (45-MB)
Server clusters—The RRP server cluster and the associated application server clusters are front ended with load balancers that distribute the transaction processing workload across the servers in each cluster. Distribution algorithms include least connections, weighted least connections, round robin, and weighted round robin.
The RRP server and application server clusters are sized to handle six times the projected steady-state workload, or 2,100 peak transactions per second. The processing capacity can grow linearly by adding additional servers to the cluster. The total system capacity is a cluster size of 32 SMP 8-way RISC servers.
The Billing and Collection system is sized to handle 350 peak transactions per second, because not every RRP transaction results in a billable event.
Database system—The database system consists
of dual high-end RISC machines, each with 2- to 32-way SMP scalability. The
processing capacity of the database system is
The database system can grow to handle eight times the initial projected volume of transaction loads. NeuStar will closely monitor system usage, and will scale the database capacity correspondingly.
Whois peak capacity
Network—The peak Whois transaction rate is estimated to be 350 queries per second, with an estimated packet size of 10,000 bits. This produces a maximum load of 3.5 MBPS. Initially, we will provide communication-network connectivity for Whois queries between the Internet and each data center as two T-3 Internet Service Provider (ISP) local-access links (shared with the RRP traffic). Although these links initially will not be used at full capacity, they ultimately can carry 90 MBPS per data center before we upgrade to larger links.
Whois server cluster—Our Whois server cluster is front-ended with load balancers to distribute the transaction-processing workload across the servers in each cluster. Distribution algorithms include least connections, weighted least connections, round robin, and weighted round robin.
The Whois server cluster in each SRS data center consists of four Whois database servers, each of which has its own copy of the Whois database. The two load balancers in the two respective SRS data centers are also connected via internal network for failover purpose. If the Whois server cluster on one data center fails, the load balancer on that site can re-route the Whois traffic to the load balancer on the other site without Whois service interruption. To improve query response time and lighten the load on the database, the Whois servers cache frequently accessed domain names.
The processing capacity can grow linearly by adding additional servers to the cluster. The total system capacity is a cluster size of 32 SMP 6-way Intel servers. NeuStar will closely monitor Whois usage and will increase the system’s capacity to accommodate increasing demand.
Database system—The Whois database servers are dual mid-range RISC machines, each with 2-way SMP scalability. The total processing capacity will be 350 tps, scalable to 1000 tps.
DNSQuery peak capacity
Network—NeuStar has provisioned at least 2MB of bandwidth at each of our six nameserver sites. With an average DNS packet size of 1,600 bits this will accommodate 2MBs will accommodate over 1,200 queries per second at each nameserver site. Each namseserver site is equipped with additional bandwidth, so that growth can be implemented rapidly. In addition to the extensive bandwidth provisioned and the easy growth, NeuStar will deploy two more nameserver sites for .org, one in Europe and one in Asia.
Nameservers—Our DNS nameserver cluster will be front ended with load balancers to distribute the transaction processing workload across the nameservers in the cluster. Distribution algorithms including least connections, weighted least connections, round robin, and weighted round robin.
The nameserver cluster is sized to handle three times the projected steady state workload, or 5,000 queries per second. To improve query response, the entire zone will be held memory resident.
Processing power can grow linearly by adding additional servers to the cluster up to its total system capacity: a cluster size of 32 Intel 2-way SMP servers. NeuStar will closely monitor system usage, and will scale up as required.
Zone file update—All nameservers are Intel machines with 2-way SMP scalability. They are configured as secondary nameservers for zone file update. Zone file update is performed in near real-time by the master nameserver at the SRS data center. Proposal Sections C17.4 and C17.5 describe the zone file update and distribution process.
Miscellaneous servers and personnel
Technical and other support.
Support for registrars and for Internet users and registrants. Describe technical help systems, personnel accessibility, web-based, telephone and other support, support services to be offered, time availability of support, and language-availability of support.
NeuStar is committed to provide uninterrupted technical support
for registry services, as well as for continuous registry operations to
ensure seamless transition of the .org registry. Our technical support
will be made available to all ICANN-accredited .org registrars worldwide
on a 24x7x365 basis.
Technical help systems
Registrars have a great deal of internal technical capabilities because of their need to support an IT infrastructure for their marketing and sales efforts and for their customer-support and billing and collection services. NeuStar will enhance these registrar capabilities by providing the registrars with the following types of technical support:
To maximize a competitive market amongst registrars, all support will be available on a 24x7x365 basis. Further NeuStar currently provides support in French, German, Spanish, Italian, Korean and English. We will continue to support additional languages where possible.
The home page of the web portal will include a notice to registrars of planned outages for database maintenance or installation of software upgrades. This notification will be posted 30 days prior to the event in addition to active notification including phone calls and e-mail. We will also record outage notifications in the help desk database to facilitate compliance with the service-level agreement. Finally, seven days and again two days prior to the scheduled event, we will use both an e-mail and a Web-based notification to remind registrars of the outage.
Non-affiliated registrars, registrants, and the general Internet community may obtain generic information from NeuStar’s public Web site, which will describe our .org registry service offerings, list ICANN-certified registrars providing domain-name services, and access to the .org Whois. Please see Proposal Section C25 and C35 for more details.
Central help desk
Tier-1 Support—Telephone support to registrars who normally are calling for help with customer domain name problems and other issues such as RRP implementation or billing and collections. Problems that can not be resolved at Tier 1 are escalated to Tier 2.
Tier-2 Support—Support provided by members of the technical support team, who are functional experts in all aspects of domain name registration. In addition to resolving escalated Tier 1 problems with RRP implementation and billing and collection, Tier 2 staff provides technical support in system tuning and workload processing.
Tier-3 Support—Complex problem resolution provided by on-site maintenance technicians, third-party systems and software experts, and vendors, depending on the nature of the problem.
In turn, the Help Desk uses an automated system to collect call statistics and record service requests and trouble tickets in a help desk database. The help desk database documents the status of requests and tickets, and notifies the Help Desk when an SLA threshold is close to being breached. Each customer support and technical support specialist uses our problem management process to respond to trouble tickets that includes troubleshooting, diagnosis and resolution procedure, and a root-cause analysis.
Test and evaluation facility
NeuStar will establish an operational test-and-evaluation facility that will be available 24x7x365 for registrars to test their client RRP system. Our technical support team, which consists of functional experts in the processes and technologies for domain name registration, will support the registrars’ testing.
Once a registrar is satisfied that its system is compatible with the registry system, it will schedule a formal acceptance test that will be monitored by our system engineer. After a registrar has passed the acceptance test, we will issue its userID, passwords, and digital certificates, and the registrar can begin operations.
Compliance with specifications.
NeuStar’s registry operations are fully compliant with all applicable industry standards—a key component of registry stability.
The success of the Internet as a whole is largely due to the open nature of the standards that govern much of its operation. As NeuStar has noted elsewhere in the proposal, compliance with core industry standards related to registry operations is critical to the provision of stable and responsive services. Internet users rely on various aspects of a registry to act in well-defined ways. For example:
Industry standards ensure that the registry develops such capabilities in a consistent manner while providing guidelines on how users can expect the services to work. Also, the vast majority of devices that use the Internet for communications; routers, firewalls, e-mail servers, web browsers, instant message servers, and voice over IP servers (to name a very small subset) rely on consistent protocols to interoperate globally and route necessary messages regardless of geographic distribution and variations in hardware.
While some registries may decide, for various reasons such as cost or to gain a perceived competitive advantage, to deviate from accepted Internet standards, they may find that these savings or advantages are illusory as they ignore the collective learning of Internet operations experts embodied in those standards. For example, a registry could choose to deploy secondary nameservers in only one location to save real estate leasing cost. This decision would, of course, be in direct violation of RFC 2182 which states:
A major reason for having multiple servers for each zone is to allow information from the zone to be available widely and reliably to clients throughout the Internet, that is, throughout the world, even when one server is unavailable or unreachable.
In the event of some single disaster or other unforeseen event, that registry might lose its entire nameserver network. Following the standard would have avoided such an outcome. NeuStar has deployed a constellation of six nameserver sites at locations around the world including North America, Europe and Asia. We plan to add two new sites, one in Asia and one in Europe to support the .org community.
Similarly, a registry might choose to deviate from industry standards by creating new resource records or new resolution capabilities to provide what the registry believes is new or enhanced proprietary functionality. Unfortunately for such a registry operator, DNS resolver developers rely on the standards set forth in RFCs 1034, 1035, and 2181 to ensure proper resolution of domain names. Resource records that deviate from the precepts of these standards may simply not work, causing increased resolution failure and corresponding decreased reliability. This scenario actually occurred with respect to the provisioning of an internationalized domain name capability.
NeuStar has always relied on industry standards for the services it provides. In some cases, such as the local number portability administration system, NeuStar lead the industry in a very specific effort to develop these standards. In other cases, like the TLD registry, we can rely on a very significant and detailed set of standards existing in the industry.
NeuStar’s current registry is fully compatible with all of the industry standards identified by ICANN;
NeuStar’s .org registry will also be fully compatible with
all of these standards, as well as Informational RFC 2832 governing the
Define, analyze, and quantify quality of service.
NeuStar recognizes that ICANN requires that the .org registry go through a seamless transition without degraded performance and system reliability. Users of the .org community cannot afford to lose access to mission-critical applications, nor can they tolerate system failures that lead to excessive downtime and denial of service because of a new, possibly unqualified registry operator. They demand the same or better service quality when and after the .org registry is transitioned from the current operator to another operator.
NeuStar is fully committed to deliver unparalleled system reliability and availability for the .org registry using state-of-the-art technologies. We propose redundant data centers for the .org registry operations and a network of nameservers for DNS queries. These facilities are geographically dispersed to minimize the possibility of outages caused by natural or man-made disasters. The nameservers are interconnected to each data center via a Virtual Private network (VPN) backhaul link. As previously shown in Exhibit C17-2 indicates, the two data centers are interconnected by a redundant, high speed VPN.
The two .org databases are synchronized in near-real time. At any time, only the active .org database is processing transactions for the registry. All transactions are logged on the active site. The transaction log is periodically pushed to the backup data center via the VPN if either of the following two conditions is met:
Upon receipt of the log, the .org database on the backup site applies the log to synchronize with that of the primary site. So the .org databases on the two sites only differ in the latest transaction log on the active SRS site.
Each data center will have redundant network components, high-availability
server clusters, and fault-tolerant database servers to eliminate single
points of failure. All critical telecommunications access links and network
components – e.g., routers, firewalls, LAN switches, and server NIC cards
will be redundant. Anything less would be inadequate to provide the service
levels that ICANN and the industry require.
Defining and quantifying quality of service
NeuStar defines quality of service as high-availability of all registry functions as perceived by the registrars, registrants, and end users. In this context, system availability is a function of both reliability (hardware and software components) and performance (response time, throughput, etc.). Other related factors include system management, diagnostics, maintenance; quality certified software; and database backup and recovery procedures.
NeuStar currently commits to the following service levels for its existing registry services:
Service availability, SRS—The amount of time in a month that registrars are able to initiate sessions with the registry and perform standard daily functions such as adding a domain name, transferring a domain name, etc. NeuStar commits to SRS service availability of 99.9%.
Service availability, Nameserver—The amount of time in a month that Internet users are able to resolve DNS queries to the TLD nameserver network. NeuStar has engineered the nameserver service for 99.999% availability.
Service availability, Whois—The amount of time in a month that Internet users are able to initiate a Whois query to the .org Whois service and receive a successful response. NeuStar has engineered the Whois service for 99.95% availability.
Update frequency, Zone file—The amount of time it takes for a successful change to zone file data to be propagated throughout the .org nameserver network. NeuStar has engineered the updates to take place in near real-time and no longer than 10 minutes. Our committed service levels is 15 minutes or less for 95% of the updates.
Update frequency, Whois—The amount of time it takes for a successful change to Whois data to be propagated throughout the .org Whois Databases. NeuStar has engineered the updates to take place in near real-time and no longer than 10 minutes. Our committed service levels: 15 minutes or less for 95% of the updates.
Processing time; add, modify, delete—The time from when the registry receives an add, modify or delete action to when it acknowledges the action. NeuStar has engineered for 3 seconds or less for 95% of the time.
Processing time; query a name—The time from when a registry receives a query to when it returns a response. NeuStar has engineered for 1.5 seconds or less for 95% of the time.
Processing time; Whois—The time from when the registry receives a Whois query to when it returns a response. NeuStar has engineered for 1.5 seconds or less for 95% of the time.
In addition to these service level agreements (SLAs), there should also be SLAs for administrative functions such as scheduled service unavailability notification, unscheduled service unavailability notification, etc.
We are confident that our experience, engineering and operational
expertise will deliver the highest reasonable level of service attainable.
We will commit to the same high service level as our other registry services.
For more detail on our service levels please see Proposal Section C28.
Analyzing quality of service
NeuStar uses system/network-monitoring capabilities and cluster-management fault-detection services to gather systems and network performance statistics and to track device/process/interface availabilities. The system stores this data in a local database, then generates a wide variety of pre-programmed and custom reports that enable us to:
We generate detailed reports on component availability, circuit-utilization levels, and CPU loads at the servers and routers. We summarize performance data and compare it to SLAs. We will make performance statistics for the previous year available online; statistics from earlier years will be available from data backup files.
For the .org registry service, NeuStar will also employ the
statistics-generating and statistics-reporting capabilities inherent in
BIND version 8.3.1. BIND 8.3.1’s statistics-logging function reports,
at selected intervals, the number of queries processed by each server,
categorized by query type. We will automatically collect and generate
online reports, detailing DNS query/response loads both on individual
servers and the entire system. By deploying application-, systems-, and
network-level statistics-collection and capacity-planning tools, NeuStar
can provide comprehensive reporting and trending information to ICANN,
System outage prevention.
Procedures for problem detection, redundancy of all systems, back up power supply, facility security, technical security, availability of back up software, operating system, and hardware, system monitoring, technical maintenance staff, server locations.
The .org Internet community supporting over two million registrants and millions of DNS queries daily requires outage prevention measures specifically designed to minimize system downtime. Downtime can be categorized as either unplanned or planned:
In addition to employing the preceding measures for minimizing planned downtime, NeuStar has deployed redundancy and high-availability system architectures designed to minimize unplanned outages.
NeuStar’s existing service level commitments are designed for critical infrastructure registry services such as those required for .org. We have designed a high-availability architecture that combines the following approaches to satisfy the service level requirements:
Procedures for problem detection and resolution
At five minute intervals, the network management system “pings” network devices using the Simple Network Management Protocol (SNMP) for availability and for performance statistics. Event threshold violations or error conditions will initiate a sequence of alerting events, including visual notifications via a topology map, an entry into a log of event records, e-mails to a bulletin board, and notices to technical support staff. The goal is to detect and repair potential problems before services are disrupted.
An SNMP daemon is configured to periodically check the status and health of vital server processes. In the event of a critical process failure, the SNMP agent will send a trap to the network management system, initiating an alert to the technical support staff. Our network management software will include remote monitoring and management of operations, so technical support staff can easily diagnose and troubleshoot network faults, either from the Network Operations Center or remotely. Once a problem is detected, it is resolved using our proven problem management process. In conjunction with this problem management process, we will employ proactive performance management and trend analysis processes to conduct root cause analysis and discover performance and utilization trends that could lead to potential problems.
Our cluster management software, monitors the health of each node and quickly responds to failures to eliminate application downtime, in the following components:
Since high availability is a primary design goal, a cluster cannot have a single point of failure; accordingly, NeuStar employs RAID mirrored disk drives and multiple LAN connections. The cluster management software monitors these hardware and software components and responds by allocating new resources when necessary to support applications processing. The process of detecting failures and restoring the applications service is completely automated; no operator intervention is required.
Redundancy of data centers and systems
Within each data center, the system is redundantly configured so that failure of any system component will leave a configuration of surviving system components capable of executing the entire workload within 95 percent of the previous performance for 100 percent of users. To achieve “no single point-of-failure” architecture, NeuStar replicates all components and configures the system for automatic failover.
The following table describes system architecture redundancy employed at each SRS data center to meet 99.9% service availability.
Hot repair of system components
Backup power supply
In addition to being stationed at building entrances during normal working hours, on site security personnel are on duty 24x7x365 to monitor the images from closed-circuit television cameras placed strategically throughout the facilities. Further, any room housing sensitive data or equipment is equipped with a self-closing door that can be opened only by individuals who activate a hand geometry reader. Senior managers establish the rights of employees to access individual rooms, and ensure that each reader is programmed to pass only those authorized individuals. We grant access rights only to individuals whose duties require them to have hands-on contact with the equipment housed in the controlled space; administrative and customer-service staffs normally do not require such access. The hand geometry readers compile and maintain a record of those individuals who enter controlled rooms.
The following table lists our physical security mechanisms.
Availability of backup software, operating
system, and hardware
Technical maintenance staff
The Technical Support Group will operate out of the Help Desk Network Operations Center (NOC) within the data centers. The group will be comprised of system administrators, network administrators, database administrators, security managers, and functional experts in the .org registry IT systems and applications infrastructure. Registrars access the Technical Support Group through the Tier-1 Help Desk. This group will resolve trouble tickets and technical problems that have been escalated to them by the Help Desk Customer Service Agents. If the problem involves a hardware failure, the Technical Support Group will escalate the problem to our Tier-3 on-site maintenance technicians, third-party maintenance providers, or our hardware vendors, depending on the nature of the problem. For more detail, please see Proposal Section C17.11
System recovery procedures.
Procedures for restoring the system to operation in the event of a system outage, both expected and unexpected. Identify redundant/diverse systems for providing service in the event of an outage and describe the process for recovery from various types of failures, the training of technical staff who will perform these tasks, the availability and backup of software and operating systems needed to restore the system to operation, the availability of the hardware needed to restore and run the system, backup electrical power systems, the projected time for restoring the system, the procedures for testing the process of restoring the system to operation in the event of an outage, the documentation kept on system outages and on potential system problems that could result in outages.
To maintain public confidence in the Internet, ICANN requires a high level of system-recovery capabilities. Proven industry solutions to the problems of outages and disaster recovery incorporate high-availability system architectures and fast failover from the primary data center to a mirrored-backup. High-availability solutions minimize downtime, with availability of 99.9 percent or greater. Continuously available solutions go a step further, with virtually zero downtime creating an availability of approximately 99.999 percent (five nines).
Possible system-recovery architectures include:
NeuStar’s system-recovery solution is based on running mission-critical
SRS applications at two active/hot-standby data centers that are geographically
dispersed, with database replication technology that maintains database
synchronization between the two centers near real-time. To provide backup
for DNS queries, we are implementing multiple nameserver sites, also physically
separated by long distances. We recognize that system management and recovery
are more difficult when the system spreads over a large geographical area;
however, active/hot-standby SRS data centers will keep the registry master
databases synchronized up to the latest transaction log.
Restoring SRS operations in the event of a system outage
Believing that prevention of failure is better than restoring after failure, to maximize availability and eliminate the possibility that a single-point failure could shut down operations, we implemented each of the two SRS data centers and six nameservers with:
The recovery mechanisms we will implement include:
The remainder of this subsection describes how we would recover from a system-wide disaster (e.g., one that disables an entire data center). Proposal Subsection C17.15.3 discusses recovery from various types of component failures.
System-wide disaster recovery
The use of active/hot-standby data centers provides fast, simple disaster recovery that maintains continuity of operations with minimum to zero downtime–even in the event of a major disaster. The following are the procedures that are followed to restore operations if an SRS or nameserver site experiences a natural or man-made disaster:
Redundant/diverse systems for providing service in the
event of an outage
NeuStar is proposing two active/hot-standby SRS data centers and multiple nameserver sites with high availability clusters and cluster management software that enables multiple node processors, in conjunction with RAID storage arrays, to quickly recover from failures. The server load balancer and the cluster manager software monitor the health of system processors, system memory, RAID disk arrays, LAN media and adapters, system processes, and application processes. They detect failures and promptly respond by reallocating resources.
Dual fault-tolerant database servers are coupled to a primary
and a backup database and RAID configuration to ensure data integrity
and access to the database. The database system uses synchronous replication,
with two-way commits to replicate every transaction to the backup database.
The process of detecting failures and restoring service is completely
automated and occurs within 30 seconds with no operator intervention required.
Process for recovery from various types of failures
The following table lists the possible types of failures and describes the process for recovery. In all cases of component failure, system recovery is automatic, with zero downtime and zero impact on system users. The remainder of this subsection, C17.15.3, provides additional information about failure recovery considerations for individual components.
Recovery from a cluster processor failure
Database system recovery
NeuStar’s fault-tolerant database server software solution will provide distributed redundancy by implementing synchronous replication from a primary database server to a backup database server. This solution includes automatic and transparent database failover to the replicated database without any changes to application code or the operating system.
If a database system node experiences a hardware failure or database corruption, NeuStar technicians use the following recovery procedures:
Training of technical staff who will perform recovery procedures
NeuStar technical personnel have an average of five years of data center operations experience, encompassing the high-availability cluster technology, distributed database management systems, and LAN/WAN network management systems that are employed in the recovery process. New hires and transfers to NeuStar’s .org registry operations will be given the following training:
Software and operating systems for restoring system operations
NeuStar will use commercially available Unix operating systems, cluster management software, and backup/recovery software to restore the SRS and nameserver systems to operation. In addition to providing synchronous replication of registry transactions to the backup server, our database-management system will provide data recovery services using the DLT tape backup system. Backup/recovery hardware and software at the SRS data center will remotely back up and restore the nameservers over the VPN.
All static applications software and operating systems are
backed up to DLT tape volumes and converted to CD-ROM for quick restoration
in the event of operating system or application software failures. Backup
copies are maintained in the data center for quick access, with additional
copies in the secure escrow facility.
Hardware needed to restore and run the system
The two active/hot-standby data centers will house the
commercial off-the-shelf, fault-tolerant cluster servers and dedicated
backup/recovery servers that are needed to restore the system to operation.
Backup electrical power systems
Each of the two data centers is configured with a UPS
battery-backup system that provides sufficient power for 30 minutes of
operation. They also have a transfer switch connected to 1,000-KVA motor
generators that are capable of powering the entire data center for many
days without commercial power.
Projected time for restoring the system
Two active/hot-standby data centers, each with high-availability clusters sized to handle the full projected registry load, provide the SRS services.
If an individual cluster experiences a processor failure, that processor’s applications are transferred to another processor within approximately 30 seconds; however, the remaining processor nodes in the cluster continue applications processing without interruption.
Since the hot-standby database maintains synchronization with
the active one up to the current transaction log, even if a natural or
man-made disaster eliminates one data center, registry services can continue
with minimum downtime and minimum impact on users. The only impact is
transitional, with dropped sessions to the RP server, Whois Server, and
Name Servers, and potentially, those completed transactions on the current
transaction log if the log is also lost in the crash. Because the protocols
reinitiate a failed transaction, even these operations are fully restored
in less than 30 seconds with no loss of data or transactions.
Testing the system-restoration process
NeuStar will test disaster recovery plans and outage
restoration procedures annually to ensure that they can effectively restore
Documenting system outages
System-problem documentation includes the following:
Documenting system problems that could result in outages
NeuStar’s proactive systems management processes include performance management, trend analysis, and capacity planning. These processes analyze system performance and utilization data to detect bottlenecks and resource utilization issues that could develop into outages. Monthly reports on the three processes keep the data center manager appraised of our performance against service level agreements and raise awareness of potential problems that could result in outages.
In addition, NeuStar performs root cause analysis of hardware
and software failures to determine and analyze the reason for any failure.
Based on our findings, we work with vendors to generate hardware service
bulletins and software maintenance releases to prevent reoccurrence of
Registry failure provisions.
Please describe in detail your plans for dealing with the possibility of a registry failure due to insolvency or other factors that preclude restored operation.
Internet domain names are an important public resource. The functions provided by the registry; zone file, Whois, domain database, and the change management associated with those functions are critical to the effective and efficient operation of the .org domain. Domain name holders, registrars, and Internet users around the world have grown to expect, and depend upon, uninterrupted service. The existing registry providers and ICANN need to work together to minimize any disruption to the TLD in the event that a registry provider fails.
Registry services form the core of critical Internet functionality. Domain name holders, registrants, rely on a registry’s nameservers for name resolution. Without a reliably functioning nameserver infrastructure, e-mails would not be received, websites could not be viewed, systems that use domain names for addressing would not be able to interface with each other, etc. Registrars rely on the registry’s SRS to manage the domain names for their customer – the registrants. The registrars manage nameserver updates and changes, account renewals, name expirations, among other functions; through the registry. The Internet community relies on the registry Whois for maintenance and administration in the domain. Therefore, any disruption of a registry’s services can have catastrophic impacts on the users of a domain.
The critical functions that must be rapidly and accurately restored in the event of failure are:
One method of providing for restoration in the event of a catastrophic registry failure is to identify one or more entities to act as secondary nameservers for the domain and freeze all changes. It is likely that there would be volunteers, such as universities and existing registries, that would act as secondary nameservers for the failing domain’s zone file for some reasonable period of time. However, this solution would mean that Whois and change management would not be supported during the time that it takes to transition to a new registry. This could be a significant amount of time.
It has been NeuStar’s experience as a registry provider that change management is a very important function to the registrants. A significant number of nameserver changes are managed through the registry. That is, a person changing a nameserver address will port their applications; e-mail website, etc.; to a new nameserver and then change the nameserver address at the registry. When they do this they are expecting a short period of downtime. The downtime could be as short as fifteen minutes for a registry such as NeuStar’s internet registry that performs near real-time updates to the zone file. Or it could be as much as 12 hours for registries such as the current .org registry that performs updates twice a day. To add weeks if not months to nameserver changes would be completely unacceptable to registrants. Another problem exacerbating this situation is the fact that many companies in the business of hosting websites and e-mail are affected by the recent downturn in the economy. Registrants have to find a new host for their services quickly. A delay in changing the nameserver addresses could put them out of service for an unacceptable period of time. Such a scenario would effect the registrant’s own operations.
NeuStar believes that the transition plan we have detailed in Proposal Section C18 of this RFP can be used as a template for any transition of a domain from one registry to another. That is, this transition plan can be used in the event of a registry failure, as well as, in the event of an RFP award such as the one for .org.
Exhibit C17-19 summarizes the transition plan which lays out a six week timeline beginning with adding the successor registry’s nameservers as secondaries and ending when the last nameserver of the incumbent registry is removed as a secondary. This plan assumes that ICANN has selected a successor registry with a functioning SRS registry database, nameservers, and Whois. The second and third week of the plan places a moratorium on registrar transfers, and the third week places a moratorium on adds, modifies, and deletes. The third week is the only week that would affect the registrants trying to initiate nameserver changes. There is also an allowance for emergency modifications, but these are to be kept to a minimum to avoid the possibility of having the database, the zone file, and the Whois out of synch. Four of the six weeks are in place for a gradual ramp down of the incumbent registry provider’s nameservers.
Given the devastating effects of a registry failure on the users of a TLD and the Internet as a whole, NeuStar, of course, seeks to avoid ever having to execute a recovery plan. NeuStar’s first line of defense against failure is its highly secure, redundant registry infrastructure. Moreover, NeuStar’s strong financial health and significant investor support further ensures that failure due to insolvency or similar factors will never happen. Sound and responsible registry operations, however, require an effective failure recovery plan.
If NeuStar were to experience a failure we would propose the transition plan we have provided in Proposal Section C18 to transfer the .org domain to a successor. We would agree to follow all of the guidelines we are proposing in Proposal Section C18 for the incumbent operators of .org. A very important additional function of an operating registry in this regard is the data escrow requirement outlined in the ICANN contract. These escrow data requirements ensure that necessary data is available to support the proposal transition plan. We will also notify ICANN at the earliest time possible to provide sufficient time to transfer the zone files and other key data to a successor operator, and assist them with that transition. NeuStar would also stand ready, at ICANN’s request, to implement this transition for other ICANN sanctioned registries that may fail.
Transition Plan. This should present a detailed plan for the transition of the Registry Function from the current facilities and services provided by VeriSign, Inc., to the facilities and services you propose. Issues that should be discussed in this detailed plan include:
NeuStar’s transition approach, borne from unique experience successfully transitioning a TLD from VeriSign, ensures the highest levels of stability, service, and integrity.
Exchanging ownership of the .org registry must be done in a manner that secures a seamless transition into a proven, stable, and robust registry. A seamless transition entails meeting the needs of each .org stakeholder where:
The risks associated with transitioning an active, mission-critical resource like .org cannot be overemphasized. Imperfect navigation through the complexities of a TLD transition will lead to resolution outages, inaccurate or non-reconciled data in and between the .org zone, Whois, and SRS databases, and extended or costly interruptions to registrant and registrar activities. The impacts of these unacceptable risks reach far beyond the over two (2) million .org domain owners. Many noncommercial registrants rely upon their .org domains to offer essential communication services to their supporters. These services often represent the single information or administrative processing medium to conduct daily activities and would, therefore, halt critical activities in the .org community. If data transition is not effectively and aggressively managed, it is likely that in-flight or incomplete domain requests (such as registrar transfers or deletes) will be lost or processed in error, billing transactions will be inappropriately billed or applied, and active names will be sold to new parties. Further, when registrars are not provided the same and appropriate level of time and technical support to execute their transition activities, .org registrants with different registrars will be treated unfairly, calling into question the integrity of the .org TLD.
Whenever data and services are moved from one entity to another, there are a multitude of risks inherent in the transition. When that transition is between two different and unrelated entities, those risks, and their likelihood of occurring, are even greater based on differences in approach, expertise, culture, and agenda. Beyond the need to effectively manage these inter-registry complexities, there are many technical challenges that must be combated to avoid negatively impacting the .org space and its stakeholders. These technical challenges include:
To address the aforementioned transition challenges, eliminate success risks, and mitigate negative outcomes, a contractor must (1) intimately understand each risk and its impact on the various stakeholders, (2) have practical experience with the various approaches, (3) arrive at a sound and attainable plan, and (3) have direct control over a scalable infrastructure that can meet the demands of a data, service, and user transition.
NeuStar offers a comprehensive transition package based on practical, not theoretical, experience. Our detailed, technically sound, and attainable plan can be flawlessly executed because we already possess (1) the scalable registry infrastructure which has proven to accept a transitioned TLD, (2) an accomplished TLD transition team with successful TLD transition experience, (3) a technically sound data transition approach that guarantees no interruption in critical .org services, and (4) an effective program management approach that identifies and addresses obstacles and issues quickly. The following transition plan proposal sections clearly illustrate that NeuStar is proficient not only in registry management, but also in registry transitions These sections contain:
|C18.1.||Steps of the proposed transition, including sequencing and scheduling.|
NeuStar’s recent experience in transitioning the .us TLD was utilized to arrive at a detailed, practical, and proven transition plan for the .org TLD.
NeuStar has developed a comprehensive phased transition plan that will be initiated within weeks of contract award. We will immediately begin discussions with VeriSign regarding the details of our plan, coordinate meeting schedules and deliverables, and identify their internal resources. The transition period is scheduled for competition prior to the end of the year to ensure all resources will be available.
NeuStar has already achieved success in managing the complexity of creating, maintaining, and enhancing TLD spaces. Additionally, NeuStar has navigated through the intricacies of transitioning mission critical services between unrelated entities. NeuStar’s recent experience in transitioning the .us namespace was utilized to arrive at a detailed, practical, and proven transition plan for .org. This directly relevant experience, coupled with our unparalleled resources, makes NeuStar distinctly qualified to offer a seamless and stable transition.
Although the competition introduced by a separation of .org from the .com and net registries will benefit the Internet community at large, transitioning an existing, mission-critical public resource introduces concerns about degradations in service and availability. These concerns cannot be ignored and should not be underestimated, since they represent risks inherent in any service, data, and system migration. The complexity and probability of these risks are further exacerbated when the migration is between unrelated entities. Clearly a contractor’s ability to maintain the stability and security of the .org registry during and after the transition is of paramount importance in the selection of a new .org registry.
NeuStar will ensure stability and security with a well-balanced offering that includes experienced staff, an existing robust and scalable registry system, a proven program management methodology, and a comprehensive plan. Furthermore, contractors who need to (1) introduce new registry software, hardware, or network elements, (2) implement new competitive registrar relationships, or (3) solicit assistance from an external vendor will significantly increase the risk of interrupting or otherwise degrading this mission-critical resource as further outlined in Proposal Section C18.6.
NeuStar’s experienced staff has been leveraged in the creation of our .org transition and contingency plans and shall be further tasked during the actual service, data, and system transition. Details can be found throughout Proposal Section C18 and specific details about staff and transition experience can be found in Proposal Section C18.6.
NeuStar’s shared registry system, DNS, Whois, registrar extranet, informational websites, billing process, and reporting applications also have proven to be reliable, sustainable, stable, and scalable. Each supported the introduction of the .biz TLD in late 2001 and later in the unprecedented real-time “landrush” of .us in April of 2002. The .us launch proved that NeuStar’s systems were able to handle large concurrent volumes without any degradation in service or access. It is, in fact, the existence of a proven and scalable registry infrastructure that allows NeuStar to guarantee a stable and on-time transition. Specific details are further explained in Proposal Section C18.6.
NeuStar considered several different transition approaches. Each was evaluated against the stakeholder impacts discussed in Proposal Section C18.4 to arrive at a solution which best balanced the needs of all .org stakeholders including end users, registrants, registrars, and the Internet community at large. NeuStar’s plan was additionally evaluated against the risks defined in Proposal Section C18.3 to revise or augment activities where such risks could be mitigated or eliminated.
A transition plan can be successful only if complemented by a structured and effective program management approach. NeuStar employs a program management methodology built upon standards set forth by the Project Management Institute (PMI). This program methodology is far more than a documented process. NeuStar employees at every level participate in customized and certified project management training. The approach and its associated deliverables, processes, and documentation are considered the responsibility of every program team member. Program performance reviews are provided to executive management and program sponsors on a regular basis and are then shared with impacted stakeholders.
When NeuStar’s program management methodology is coupled with our unmatched resources and experience, plans become reality. The .org transition plan was created with involvement from all disciplines as listed below. Execution of the activities within NeuStar’s transition plan will leverage these world-class, on-staff resources.
NeuStar’s transition plan is divided into seven delivery categories (listed in the following table). Exhibit C18-1 depicts the timing of each of these transition items. The critical deliverables defined under each category are the criteria against which a flawless NeuStar execution will be managed and measured.
Each transition delivery category has an associated sequence of activities and schedules. Flawless execution requires activity and schedule adherence in each transition.
Domain name system transition
The .org community would be best served with a phased migration where problems are transparent to the .org stakeholders. Any proposed approach that does not support the following selection criteria is at risk of not protecting the security and stability of the .org domain space.
DNS transition selection criteria
NeuStar’s proposed transition plan, as depicted in Exhibit C18-2, guarantees a smooth transition without interruption to existing DNS resolution service. Our plan supports 100% availability of .org DNS resolution through the utilization of a phased DNS nameserver move between registries.
To begin the process, NeuStar will populate a nameserver using a current copy of the .org zone file provided by the incumbent. This nameserver will be configured to pull zone data as an authoritative secondary nameserver. Once the secondary nameserver is proven stable and accurate, the incumbent will remove a specified incumbent nameserver. This process will be repeated several days later for five incremental nameservers. VeriSign will need to maintain their removed nameservers for a period of two weeks (after removal) to allow for cache expiration. Having the removed nameservers updated and available for this two-week stability period will eliminate any delayed remote caching issues.
Once NeuStar’s six secondary nameservers have proven operational for a period of one week, the incumbent will replace the VeriSign primary nameserver with a NeuStar primary nameserver. Again, these removed Incumbent nameservers will be kept updated and available for a period of two weeks to support any cache expiration delays. NeuStar will then gradually replace all additional secondary incumbent nameservers with NeuStar nameservers over a period of four weeks.
Nameserver replacements and removals will be conducted in a geographically balanced sequence to maintain current geographic distribution to avoid location-based points of failure. Additionally, this sequencing supports removal of servers with lower volumes/loads early in the process to demonstrate the capacity and functionality of the NeuStar TLD cluster architecture.
NeuStar’s plan includes full testing and quality assurance checks before each DNS modification, as well as continuous monitoring after a DNS modification has been completed. This well-orchestrated, prudent approach allows for the identification of issues where immediate corrective action can take place, thus eliminating any end user or registrant interruptions. In the event any unforeseen capacity issues are identified during our quality assurance checks or post-implementation monitoring, NeuStar can leverage its horizontally scalable infrastructure to add more nameservers. We do not believe the NeuStar architecture requires more than six nameservers at the time of transition. After the transition, NeuStar plans to add two additional nameserver sites, one in Europe and one in Asia.
NeuStar will not implement its dynamic DNS updating feature (near real-time versus twice-daily updates) until all incumbent nameservers are decommissioned for a period of 90 days. Delay of this enhanced feature eliminates risks caused by synchronization issues for incumbent servers not prepared to accept dynamic updating.
To avoid any misunderstandings about sequence, deadlines, and required activities, NeuStar will present very clear requirements and documentation to include illustrations, such as Exhibit C18-3, which depicts the timing and relationship of DNS migration events.
The following calendar, depicted in Exhibit C18-4, lays out a list of activities required for a smooth transition of the zone file from VeriSign to NeuStar. The primary activities take place every Monday and Saturday beginning on Monday, November 11 and ending on Monday December 23, 2002. The activities include:
Modifications of the nameservers are first implemented in the .org SOA record on Saturday and then implemented in the root servers the following Monday. This will allow for time to monitor the nameserver performance and zone transfer functionality.
Shared registry system and .org database description
Transitioning the database from VeriSign to NeuStar will require a significant amount of scrutiny and data validation. During this transition it will be necessary to place a temporary moratorium on some services provided by the registry as depicted previously in Exhibit C18-3. The functions affected are:
An acceptable transition solution will weigh the registrants’ desire for administrative convenience against the registrars’ needs for testing and technical migration time. The right transition plan also will ensure fair, equitable, and truly competitive access (a level playing field) to all .org registrars, avoiding unfair burdens on smaller, less-resourced registrars.
The SRS acts as the authoritative hub or data source for the .org domain. The SRS database and network infrastructure feed the DNS nameservers and Whois servers with updated resolution and ownership information. It is the SRS that interacts with online registrar interfaces and back-office billing systems to support domain name requests, queries, adds, renewals, modifies, transfers, and deletes.
The situations that cause registrants to request transactions from the registrar that require interface with the SRS can be categorized in one of two ways:
The successor .org registry will require delivery of a frozen incumbent SRS database which must then be quality-checked, archived, scrubbed, audited, archived again, converted, audited, archived again, tested, and then stabilized before it should be used to generate the production DNS zone file and Whois query responses. These critical steps are necessary to ensure full database integrity and later .org zone file and Whois accuracy. In addition to the necessary database moratorium to support these critical database transition activities, .org registrars also require a pre-defined window of time to modify, reconfigure, and test their interfaces against the new registry. This pre-defined period of time must fairly support all registrars to ensure concurrent equal access at the exact time administrative services are restored.
NeuStar’s SRS transition plan calls for a conservative, yet necessary, seven-day moratorium on administrative SRS activities. This will impact registrar turnaround for the addition of registrant nameservers, registrar transfers, domain deletions, and new .org domain names However, weighed against the possibility of inconveniencing stakeholders with unplanned and extended outages, delayed response to critical “out of service” conditions, or supporting larger registrars while smaller registrars are attempting to modify their interface, it is clearly the most prudent and stable approach.
Although administrative services will be halted for a short period of time, the moratorium will not interrupt critical domain services such as DNS resolution, Whois queries, and emergency nameserver changes. The SRS, nameserver, and Whois server availability can be temporarily separated from their data source without any interruption in external zone file or Whois service. This means that a registry can upgrade or, in this case, transition the SRS and .org database without negatively impacting the zone file or Whois.
In doing so, however, provisions must be made to control changes in either the .org database or, more importantly, to the DNS and Whois services to avoid mismatches in data and subsequent data reconciliation issues. This means that stringent controls must be enforced to ensure data integrity to include restricting incumbent transactions that are not expected to be complete prior to the moratorium, such as registrar transfers. Additionally, the incumbent registry must be very careful to accurately reflect any and all domain renewals and payment processing prior to the moratorium to avoid deleting and or reallocating an incomplete domain name transfer or incorrectly debiting a registrar account.
NeuStar’s SRS transition plan calls for the full administrative moratorium to begin several hours before the .org zone file SOA record is modified to reflect the primary nameserver change from the incumbent to NeuStar which, if conducted as proposed in the DNS migration, will be on 30 November 2002. This moratorium will end seven days later on 7 December 2002. Although it is likely that the incumbent and NeuStar transition activities can be completed well before the December 8th moratorium end-date, early service return of the .org administrative activities would be unfair to registrars who are planning their resources and activities in the later part of this database stability and registrar transition window. The table below lists both the critical and administrative SRS service activities and their availability during the most critical database transition weeks.
NeuStar’s plan supports a transition that avoids any interruption to Whois service and, with the required moratorium of SRS non-emergency administrative functions, also mitigates risks to presented outdated information. Our plan calls for a transition where the incumbent registry continues to maintain pre-moratorium Whois service for one week until NeuStar certifies accurate completion of the .org database transition from the incumbent. That is, VeriSign will continue to provide Whois service from November 30, 2002 to December 7, 2002. NeuStar will begin providing Whois service on December 8, 2002 NeuStar and VeriSign will have to coordinate the cutover of Whois service to ensure no downtime.
NeuStar’s neutral business model, by its very nature, encourages registrar competition, globalization, and focus on service improvement. It is, in fact, this business model that keeps NeuStar aggressively committed, without distraction or conflicting agendas, to the following registry goals:
NeuStar has a solid reputation in the registrar community as an experienced registry. Our recent migration of the .us legacy space from VeriSign in November of 2002 proved our ability to successfully migrate an existing TLD while simultaneously improving service levels.
As an example of our improved service, many .us Delegated Managers were pleased to find VeriSign’s four- to five- week wait period for zone file changes, in many cases, immediately reduced to no more than 48 hours upon transition to NeuStar’s registry.
There were several lessons learned throughout the launch of .biz as well as during the transition and launch of .us These lessons were invaluable to NeuStar in creating the following registrar relations transition plan:
NeuStar will utilize the existing RRP.org registrar toolkit to avoid confusion and minimize preparation time to begin conducting transactions with NeuStar. NeuStar also shall offer an interactive test environment for those registrars who wish to confirm their interoperability with the new registry system. We will work with registrars to offer an additional launch connection period prior to launching service on December 8, 2002, when registrars can test credentials, digital certificate installation, and operational readiness of registrar systems and networks. This connectivity support period will take place during a pre-defined period of time where 24x7 technical support will be available to support all time zones and staffing levels. Such an approach proved valuable to registrars during NeuStar’s .us launch and supported universally, concurrent, equivalent access for the FCFS launch. NeuStar connections shall be allocated in a fair and equitable manner to avoid any registrar transactions delays. Our proprietary network grooming capabilities shall be leveraged to ensure fair and uninterrupted service across all .org registrars.
Moreover, NeuStar shall offer a full complement of registrar support services, including:
A successful .org transition will require system migration experts working in an open, constructive, and mission-focused manner with the incumbent A comprehensive plan without the oversight of focused and proven transition management will not lead the incumbent and new registry staff to a smooth, seamless, and successful transition.
NeuStar’s transition management approach is based on the assumption that things can go wrong without the proper planning and preparation. We have learned the best way to mitigate the negative impact of “things that possibly can go wrong” and navigate through complex activities is to clearly discern the most critical deliverables and impacts from the outset for ongoing focus and decision-making. NeuStar’s transition management approach places heavy emphasis on risk assessment and contingency planning to facilitate making (or at least mapping) decisions before an event happens. Since our technical staff will be managing the many concurrent issues that often arise with any large data, service, and user transition, NeuStar’s program managers shall regularly compare progress against the most critical deliverables to make daily decisions about priorities and issue resolution.
The critical transition deliverables introduced in Proposal Section C18.1 have been prioritized based on their immediate impact if compromised and their execution complexity. This list helps NeuStar understand which categories require heightened focus or stronger contingency plans.
Poor communication can easily doom a good transition plan to failure. This includes internal communication within teams, across project leads, and with other lines of business, but more importantly between the successor registry, the incumbent registry and the geographically dispersed registrars. NeuStar believes it is the successor operator’s primary mission to keep all stakeholders informed of upcoming events, educated on possible risks, and abreast of current progress. This is why our plan includes focus on transition management as an independent category with unique critical deliverables.
To help program team members and TLD transition experts appropriately focus their communication efforts, NeuStar’s .org program management communication model (please see Exhibit C18-5) helps to illustrate the relationship between various program efforts. This model includes activities beyond the initial .org transition (such as registry maintenance and EPP conversion) and helps to illustrate how our transition management approach offers focus and clarity to team members who are accountable for interdependent, complex, mission-critical activities.
Our plan additionally calls for dramatic improvements
in the offering of informational web sites focused exclusively on the
.org noncommercial space. These will include an enhanced, user-friendly
Whois interface to both end users and registrars, landing pages that describe
the intended purpose namespace, processes, planned .org events, and a
list of accredited registrars. Additionally, the website will be designed
to keep the noncommercial community informed and involved in .org-related
issues. Through membership, end users may elect to receive updates and
information about the .org domain name space and participate in .org discussion
for a. Furthermore, end users can use the websites to participate in and
follow the activities of the Global Policy Council (GPC) as described
in Section C.35 These web sites will be offered on November 30 when NeuStar
takes over as the .org registry.
|C18.2.||The duration and extent of any interruption of any part of the Registry Function.|
Based on our experience with the .us transition and our appreciation for the importance of maintaining stability while providing minimal service disruption, NeuStar will not require any type of outage for the DNS name service or Whois services during transition However, NeuStar does propose a brief interruption in service during the transition period of the .org TLD to ensure the integrity of all registry data and a seamless transition of registry services. The section describing SRS and .org database transition in Proposal Section C18.1 provides more detail about service interruptions.
This transition period will entail a moratorium lasting seven days, commencing the week prior to the final transition for the SRS on additions, deletions or modifications for domains and SRS-related data. During this period, NeuStar will provide customer service support for registrars Updates to domains for registrants will only be completed on an emergency basis through a manual process. Updates will not be able to take place through a provisioning protocol; instead, updates will be handled through our existing registry customer staff.
The purpose for the outage is to provide a smooth transition from the incumbent while maintaining data consistency. We believe that this interruption will provide ample time to migrate and verify data between the incumbent provider and NeuStar.
A detailed review of the transition impacts on each .org stakeholder
is contained in Proposal Section C18.4 and also includes details about
the duration and extent of the administrative moratorium.
|C18.3.||Contingency plans in the event any part of the proposed transition does not proceed as planned.|
As previously mentioned, the complexity of navigating through the intricacies of a mission-critical service migration between unrelated entities cannot be overlooked in the selection of the .org registry provider. To assure a seamless registry transition, the winning registry must not only understand the tasks involved in transitioning a TLD, but moreover, the problems they will likely encounter when doing so. A successful transition will require a plan that mitigates or eliminates risk where possible or at least, minimally supports quick fallback to a pre-planned contingency. Incorporating effective risk mitigation or elimination and contingency planning requires leveraging relevant experience.
NeuStar has direct, recent, and relevant experience upon which risks and contingency plans were built. We critically evaluate all programs subsequent to transition or launch completion to improve upon our systems, processes, education, and approach. The .biz launch supported dramatic changes and improvement in our registry implementation approach that were effectively employed in our .us transition this year.
The .org transition contingency matrix provides a record of
the iterative risk identification and mitigation items as well as contingency
criteria and plans. Any contingency plan and risk matrix, however, will
have to be flexible, and will be continuously evaluated and updated as
the transition progresses, new information is gleaned, or a new issue
|C18.4.||The effect of the transition on (a) .org registrants and (b) Internet users seeking to resolve .org domain names.|
NeuStar’s transition plan acknowledges the unique needs of each .org stakeholder and balances those needs in a manner that results in no interruption to critical registry services, full data integrity, and equal registrar access.
As previously stated in Proposal Section C18.1, there will be absolutely no interruption to DNS resolution or Whois during the transition of the .org registry to NeuStar. To assess other possible transition impacts, however, we have identified four distinct stakeholders, external to the registry operator, who could be impacted by the transition of the .org domain space. Each stakeholder has unique needs related to the stability of the space as well as the services offered, or not offered, during a transition.
NeuStar has built a comprehensive transition plan that identifies the elements of service requiring transition and then acknowledges the unique needs of each stakeholder against those elements. Before exploring the elements of a registry transition we have defined the stakeholder community and their high-level needs.
By extrapolating the needs of each stakeholder, six transition factors were identified in the transition of the zone file, Whois, and the .org database.
Although each stakeholder is indirectly impacted by the extent to which the needs of other stakeholders are met, the table below highlights the direct needs of each stakeholder community.
This matrix helped us arrive at the most stable and effective DNS transition solution by highlighting the most critical stakeholder requirements (reviewed in Proposal Section C18.1).
While evaluating the viability of other transition approaches, NeuStar added an additional success factor to consider. Although not exclusive to a particular stakeholder, we felt it was prudent and necessary to measure the likelihood of successfully executing the approach. We call this factor “risk”. In weighted scorecards, a high-risk approach reduced the positive score of other stakeholder factors.
Stakeholders will be impacted by the NeuStar transition approach in the following ways.
|C18.5.||The specifics of cooperation required from VeriSign, Inc.|
NeuStar knows that setting clear expectations, closely managing critical and interdependent deliverables, and promoting full disclosure of issues with the incumbent is necessary to combat inevitable disparities in systems, cultures, approaches, and agendas.
NeuStar understands the complexity of transitioning data, services, and users between unrelated entities and, therefore, knows that disparate systems, cultures, and agendas will undoubtedly introduce transition issues between the incumbent registry and any new registry. For that reason, NeuStar’s incumbent registry communication plan includes several planning exercises between registries soon after contract award to gain concurrence on plan details, risks, and dates.
Additionally, NeuStar’s program management approach shall be leveraged to clearly document exactly what activities are required of each entity and when such activities must begin and conclude. As with NeuStar’s internal approach, critical deliverables by transition category and stakeholder segment shall be regularly reviewed across unrelated entities to guide decision-making and issue resolution efforts.
Incumbent planning meeting
This list will undoubtedly grow and evolve before contract award, but provides an early indication of the types of incumbent activities required for a smooth and seamless transition.
More specifically, NeuStar and the incumbent must define exact migration times based on the high-level ownership and support plan, previously outlined in Exhibit C18-1.
Incumbent Deliverables & Requirements
|C18.6.||Any relevant experience of the applicant and the entities identified in item C13 in performing similar transitions.|
NeuStar’s transition plan is reinforced with an exceptional package of resources to include on-staff TLD transition experts, practiced mission-critical resource migration approaches, and a proven robust and ready scalable registry infrastructure.
NeuStar has an impeccable record of managing and transitioning mission critical public resources. NeuStar has proven able to manage the complexity of creating, maintaining, and enhancing TLDs by offering stable and reliable service to the .biz and us communities. In addition, the award of the .us TLD provided NeuStar with the unique experience of transitioning an existing domain space from the VeriSign registry to the NeuStar registry.
We learned many lessons about what is effective and what is not effective in the transition of an existing TLD. As a result of this experience, our staff has gained the ability and knowledge to:
It was the experience taken from the .biz launch that supported the unprecedented transition and launch of .us. NeuStar migrated the .us legacy space shortly after contract award. Since this award included the migration of an existing zone file between VeriSign and NeuStar, we were able to glean many lessons learned about how a larger, more expansive migration would be successful. We also learned the critical issues involved in an inter-company transition.
NeuStar launched the expanded .us space in less than six months after contract award, and realized several highly unique results.
First, NeuStar was able to successfully meet United States Department of Commerce requirements for a diverse registrar community by accrediting 58 registrars; 21 of who were not previous ICANN-accredited registrars. Additionally, NeuStar’s relationships and international presence helped to solicit the active participation of four European, three Asian-Pacific, and two Middle Eastern registrars. NeuStar offered the value-added services identified in the following table, to support a stable, smooth transition and launch.
Second, NeuStar was able to offer an unprecedented online first come first served (FCFS) “landrush” of the expanded .us space. Other Registries have supported such periods with a batch process to mitigate concerns about system capacity and general stability. NeuStar, however, gained enough experience testing the robustness of our system to comfortably offer a real-time launch without delay between the selection of Sunrise trademark owners and an open .us offering. NeuStar successfully supported this landrush with more than 100 concurrent connections where 5 million transactions were flawless executed in the first 24 hours.
NeuStar has implemented a TLD with and without an existing registry infrastructure—and we intimately understand the added complexity and real risks involved in executing a plan that includes the addition of new registry software, hardware, and or network components. Flawless execution can only be guaranteed by a contractor who is able to utilize an existing infrastructure—and NeuStar is that operator. The following table highlights certain risk scenarios and their respective possibilities.
Since NeuStar currently supports a very robust, scalable system with internal resources we are able to eliminate the significant program risks of introducing a new infrastructure. Without these risks identified in the above table, NeuStar can comfortably guarantee a timely, fair, and stable transition. The benefits of implementing a TLD atop an existing, proven infrastructure is clearly illustrated in the .us transition and launch summary included at the end of Proposal Section C18.
NeuStar is able to additionally leverage the experience of managing and transitioning other public resources in our other lines of business as highlighted in the following table.
In the final analysis, it is NeuStar’s ability to effectively
leverage our unmatched core competencies (registry expertise, seasoned
corporate infrastructure in mission-critical database businesses, matured
registrar relationships, stable and scalable technical architecture) that
will ensure a smooth and stable .org transition. The leaders of NeuStar’s
transition team are identified in section C15, but are complemented by
a host of seasoned staff who have all already proven able to flawlessly
|C18.7.||Any proposed criteria for the evaluation of the success of the transition.|
An effective plan includes clear and measurable success factors against which a smooth and seamless transition can be measured, and against which future migration or enhancement plans can be built.
NeuStar’s experience with mission-critical data migrations has been exploited to arrive at a solid transition plan. The plan was designed around key deliverable categories, priorities were built upon stakeholder needs, and risks were evaluated based on their probability and impact. This strong planning lays the foundation for clear definitions and measures of success.
Please describe in detail mechanisms that you propose to implement to ensure compliance with ICANN-developed policies and the requirements of the registry agreement.
Because of ICANN’s unique mandate to preserve the operational stability of the Internet, it is incumbent that the .org registry operator implement mechanisms for assuring compliance with the various policies and contractual requirements that arise by virtue of its unique relationship with ICANN. In proposing such mechanisms, a prospective registry operator cannot merely recite its intention to abide by the requirements of the registry agreement with ICANN. Instead, the successful applicant must identify discrete mechanisms that demonstrate to ICANN that, as the registry operator, it understands policy and contractual requirements, and can immediately comply with both on an ongoing basis.
NeuStar’s business, technical, and policy operations have successfully implemented mechanisms for ensuring compliance with ICANN-developed policies and requirements of registry agreements. These mechanisms, described below, include active participation in ICANN policy-making processes, as well as internal review of TLD business decisions for legal and policy compliance. NeuStar proposes to maintain and continue to refine such mechanisms. With these mechanisms in place, NeuStar ensures that policy compliance is fully integrated into all operations in an efficient and streamlined fashion.
Participation in ICANN policy-making process
NeuStar also commits to comply with the Consensus Policy procedures set forth in Section 4 of the draft registry agreement for the .org TLD. However, unlike many other applicants, NeuStar has successfully operated under the Consensus Policy procedures by virtue of its agreement with ICANN for the .biz TLD. By continuing such participation, NeuStar is positioned to understand and properly implement ICANN-developed policies.
Legal and policy review
With respect to ICANN, NeuStar has already successfully incorporated the above mechanisms under its registry agreement for the .biz TLD. For example, in accordance with Appendix H of the .biz Registry Agreement, there is a compliance officer that ensures that ICANN’s requirement of “Equal Access and Nondiscrimination” is followed and strictly enforced. NeuStar has demonstrated its ability to provide equal access to all ICANN-accredited registrars time and time again in its operation of .biz.
Moreover, unlike many other applicants, NeuStar manages both
Exhibit C19-1 shows the process for integration of new requirements from an oversight authority into NeuStar’s global registry operations. Exhibit C19-1 also shows NeuStar’s participation and continued compliance processes.