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.

Technical plan introduction

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:

• Have experience operating a stable, well-functioning, and highly secure global registry infrastructure;

• Have detailed, practical experience in the transition of a TLD between operating registry platforms to ensure a seamless transition with no interruption in DNS resolution of the existing registered names; and

• Have in place working and tested mechanisms for the integration of, and continued compliance with, the often complex daily technical, business, contractual, and policy requirements associated with the operation of the .org TLD.

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:

• The implementation of a stable, scalable and secure architecture designed to ensure that the .org community receives world-class reliable service;

• The development of open standard protocol solutions and customer support systems in compliance with registry specifications and industry best practices;

• The development and implementation of processes and mechanisms to minimize system outages, maximize response and recovery capability, and ensure future integrity of the system and data as a whole.

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:

• SRS service availability is guaranteed at 99.9% per calendar month.

• Whois service availability is guaranteed at 99.95% per calendar month. 

• Nameserver service availability is guaranteed at 99.999% per calendar year

Environmental description
NeuStar maintains high-security, world-class facilities globally.  Each of these facilities share similar environmental and security attributes, which have been chosen to meet exacting service level requirements.  NeuStar’s SRS data centers in Chicago and Sterling are operated and maintained on a full-time basis by dedicated NeuStar personnel.  In addition, the nameserver sites located in San Jose, London and Singapore are maintained in world-class co-location facilities.  All of the nameserver equipment in the nameserver sites is owned, engineered, implemented, and maintained by NeuStar personnel. 

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.

Building security
NeuStar vigilantly controls physical access to our facilities.  Physical security mechanisms include security guards, closed circuit TV surveillance video cameras, and intrusion detection systems.  Our network operations center (NOC) monitors access to all locations on a 24 x 7 x 365 basis.

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. 

Network connectivity

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
NeuStar has deployed two ISP links at each SRS data center to serve registry needs.  Each link is provided by a different ISP for a total of four separate ISP interfaces.  Exhibit C17-2 for a diagram of the SRS data center connectivity.  Each link has available capacity of 45MB for a total of 90MB at each data center.  For cost efficiency reasons, we have committed to using 10MB on each of the links. However, we can utilize the entire 45MB if demand requires. If demand were to consistently exceed 10MB, we would adjust our agreements for more “committed” bandwidth.  

Internet connectivity—nameserver site
Nameservers sites located at the SRS data centers share Internet bandwidth with the SRS data center.  Bandwidth engineering for those sites is covered in the previous section.  For co-location sites, the co-location facility provider provisions Internet bandwidth at the co-located sites.  The facility provider has provisioned a highly diverse and redundant network.  NeuStar has provisioned at least 2MB of capacity into each nameserver location.  For security purposes, the NeuStar routers will be configured to only allow DNS UDP/TCP traffic.  The router is connected to a load balancer that distributes the query load among the nameservers in that site’s cluster.  A firewall protects the whole system in each location to provide the highest level of packet filtering from a TLD system today. We also use intrusion detection systems to proactively detect and deter security incidents. 

VPN registry management network
Each SRS data center is connected to each of the nameserver sites over a secure VPN.  Two ATM links connect the two SRS data centers.  Refer to Exhibit C17-2 for a diagram of the data center connectivity.  These links comprise NeuStar’s Secure Registry Management Network. 

The links between the data centers are used for:

• Alternate access to the internet in the event of an outage;

• Providing zone file updates for nameserver site #2;

• System maintenance and monitoring;

• Updating the back-up registry database; and

• Updating the Whois databases in the backup data centers. 

The VPN between the data centers and the nameserver sites is used for:

Zone file updates;

• System maintenance and monitoring, and

• Remote Administration of nameservers.

Building LAN backbone
Within NeuStar’s data centers, a redundant switched 100 MB Ethernet building LAN backbone maintains high network availability via redundant Ethernet switches. Devices are dual attached to each of the Ethernet switches to provide a redundant LAN architecture. The building LAN is protected from the Internet via a firewall that provides IP filtering and network-based intrusion detection services. This protects the system from hacking and denial of service attacks.

Registry system architecture and infrastructure

NeuStar has deployed a world-class registry architecture to support its current registry service.  The NeuStar architecture was designed:

• With near military-grade security,

• To be highly stable under extreme loads,

• To be easily and efficiently scaled for higher demand, and

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:

1. External network layer;

2. Protocol server layer (herein referred to as protocol layer);

3. Internal network layer;

4. Application server layer (herein referred to as application layer); and

5. Database layer

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
The external network layer, as shown in Exhibit C17-4, is NeuStar’s Internet interconnection point.  This layer is dedicated to security and traffic management, thus ensuring a secure and robust connection between the registrars and the protocol servers at the second layer.  The external network layer consists of four redundant servers each performing its own security function or traffic management and security function: 

• Edge router—The edge router provides Internet connectivity and performs IP-packet filtering. 

• Traffic shaper—The traffic shaper is an intelligent bandwidth management device.  It has the ability to manage bandwidth in multiple ways, including on an aggregate basis, on an individual port basis, and on an individual registrar basis.  The traffic shaper also performs IP-packet filtering. 

• Firewall—The firewall is dedicated to perimeter security.  It provides policy-based IP filtering to protect against system hacks, break-ins, and denial of service attacks. The firewall also includes network-based intrusion detection to protect against Internet hackers.

• Load balancer—The load balancers distribute traffic among the clusters of protocol servers (RRP, EPP, Whois, and Web) in the second layer of the SRS data center.  Load balancing protects our protocol layer from common denial-of-service attacks; e.g., SYN floods, ping floods, and “smurf” attacks. Security policies can be based on any combination of source address, destination address, and protocol type or content.  Load balancing is also a critical element for providing scalability at the protocol layer.  It provides the ability to easily add additional protocol servers without re-engineering the protocol software and network equipment. 

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. 

Protocol layer
The protocol layer, as depicted in Exhibit C17-5, consists of servers that provide the interface with our customers.  All servers are deployed in a cluster configuration to provide scalability.  Packets coming from the load balancers in the external network layer are distributed among the different servers in the cluster to provide load sharing.  In a cluster configuration, no one server gets more traffic than any other server.  Additional capacity is added at the protocol layer by adding additional servers.  Adding capacity does not require any re-engineering of the protocol server software or network configuration.  Servers at the protocol layer include:

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, as depicted in Exhibit C17-6 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 the first two layers do not prevent a given breach.  The internal network layer consists of redundant firewalls and load balancers.  These serve the same security functions identified in the external network layer.  In addition the load balancers provide scalability at the application layer.  Specifically they provide the ability to easily add additional application servers without re-engineering the application software and network equipment. 

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. 

Application layer
The application layer, as depicted in Exhibit C17-7 consists of servers that provide an interface between the RRP servers in the protocol layer with the .org database in the database layer.  (It also includes EPP application servers for our existing EPP based registry services.)  The application servers contain the business logic required to interface commands originated by the registrars, through the protocol servers, with the .org database. 

For example a registrar may perform a “check domain” on neustar.org.  The protocol server receives that request and sends it to the application server.  The application service will format a query to the .org database to seek exactly the information necessary to respond to a “check domain” on the name neustar.org.  It receives the response from the database and forwards it to the protocol server that then forwards it to the registrar in the RRP format. 

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. 

Database layer
The database layer, as depicted in Exhibit C17-8 stores the .org database as well as administrative servers that perform update functions for the zone file and Whois.  These servers include:

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

Nameserver sites

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. 

System descriptions

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

Database size, throughput, scalability, procedures for object creation, editing, and deletion, change notifications, registrar transfer procedures, grace period implementation, reporting capabilities, etc.

NeuStar will provide an enterprise-strength, fault-tolerant database system capable of managing large databases and high transaction-processing loads reliably and with scalable growth to accommodate change. The database system supports data synchronization from the primary data center to the back-up SRS data center that is geographically dispersed.  The proposed database system is shown to be a stable and operational system as it has been successfully deployed for NeuStar’s existing registry systems.

The heart of the SRS is its database systems, which provide not only simple data storage-and-retrieval capabilities, but also the following attributes:

• Persistence—Storage and random retrieval of data to enable rapid response times;

• Concurrency—Ability to support multiple users simultaneously to provide consistent support for each registrar;

• Distribution (data replication)—Maintenance of relationships across multiple databases for redundancy and data security;

• Integrity—Methods to ensure data is not lost or corrupted (e.g., automatic two-phase commit, physical and logical log files, roll-forward recovery) to ensure data accuracy as well as redundancy and security;

• Availability—Support for 24 x 7x 365 operations to support the registrars around the clock and around the world;

• Scalability—Unimpaired performance as the number of users, workload volume, or database size increases to meet the increasing needs of the .org community.

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

• .org database—This database’s primary function is to provide highly reliable persistent storage for all of the registry information required to provide domain-registration services.  The .org database is highly secure, with access limited to authenticated registrars, trusted application-server processes, and highly restricted access by the registry’s database administrators. 

• Billing and collection (B&C) database—This database will provide the information required for NeuStar to render B&C services to the registrars. Access to its data is restricted to the trusted B&C system processes and to registry database administrators. Registrars can view billing data through a secure Web portal.

• Whois database—The Whois database is a searchable database that any Internet user can access to view details of the domain name stored in the .org database. The Whois database maintains data about registrars, domain names, nameservers, and IP addresses. The Whois database will be updated from the .org database via a dynamic and incremental replication process.

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:

• Multiple logical data models that will be optimized for the different types of information that each system needs to serve registrars efficiently;

• Content that will include data related not only to domain names and domain name registration, but also to registrars, registrants, nameservers, Whois servers, and the B&C system;

• Differing volumes of database transactions and database sizes;

• Differing business needs;

• Differing performance and availability requirements; and

• Replication of databases to achieve high availability and facilitate backup/recovery. 

Database size, throughput, and scalability
The following table lists design parameters for the initial design of the three major .org databases.  The parameters are based on projected volumes in the next two years.  The term “scalability” in the table refers to the database’s ultimate capacity expressed as a multiple of the initial design capacity in terms of size and transaction processing power.

Attributes of all database servers are:

• RISC 400 Mhz CPU;

• 64bit, 2 to3 2-way crossbar SMS, with 8x8 non-blocking multi-ported cross bar;

• 32GB ECC RAM;

• 240 MB/sec channel bandwidth;

• Maximum internal storage 288 GB

• Maximum external RAID 10TB

• Redundant hot-swappable, power supplies;

• Dual-attach 100BaseTX/FX Ethernet Adapters;

• Event management software for remote management; and

• 64-bit Unix operating system.

Database procedures and functions
The database system is critical to the processing of SRS business transactions.  The .org database is accessed during most registrar/registry transactions. If a transaction is completed successfully, the system updates these two databases. The .org database will update B&C database and the Whois database if appropriate. The following registry functions are supported by the .org database:

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
Operations on domain name objects refer to the first six functions in the list above, namely creation, modification, deletion, query, transfer, and auto-renewal. In addition, nameserver information can be created, associated with, disassociated with, and deleted with respect to domain name objects. Whether nameserver information is treated as attributes of the domain object or as a separate object is an implementation detail internal to the .org database.

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
NeuStar’s registry supports grace periods for several registry functions and will support those for .org.  They include:

• Add grace period;

• Renew grace period;

• Auto-renew grace period; and

• Transfers grace period.

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 administration
Registrar administration refers to adding or deleting registrars, and providing each registrar with secure access to the system and to that registrar’s data. The .org database manages most registrar data; the B&C database contains the B&C profile and contacts.  Any “Add/Delete Registrar” or “Change Registrar Profile” request will generate the appropriate changes in the .org and B&C databases.

Registrar transfer procedures
Registrants may transfer their domain name from one sponsoring registrar to another after the first 60 days of the initial registration of the domain name.  NeuStar currently performs registrar transfers in its existing registry service over an EPP (extensible provisioning protocol) interface.  In the .org registry the transfer process is done over an RRP (registry-registrar protocol) interface.  The process is very similar except for the fact that once the registry receives the “transfer” request from the gaining registrar, the registry will notify the both gaining and losing registrar via an e-mail.  Then when the transfer has been completed it again notifies both registrars via e-mail.  In the EPP protocol both of these notifications are done over the EPP interface. 

The transfer steps are as follows:

• The registry receives a transfer request from the gaining registrar.

• The registry transmits an e-mail to both the gaining and losing registrars notifying them of the transfer.

• The transfer will be completed if:

  • The losing registrar expressly "acknowledges" the request, or

  • VGRS does not receive a response from the losing registrar within five days.

• When the registry’s database has been updated to reflect the change to the gaining registrar the registry will transmit an e-mail notification to both registrars. 

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. 

Billing notifications
NeuStar’s B&C system will monitor the registrars’ accounts for insufficient funds.  If it determines that the balance is below the required minimum, the registrar will be notified by the registry’s customer-service personnel.

Reporting capabilities
To support a detailed, usage-based accounting and billing structure, the B&C database and the .org database generates a substantial amount of highly detailed resource accounting data.  This includes:

Monthly account statements—NeuStar will send a detailed monthly transaction statement to each registrar via e-mail.  The statement will include the following:

• An account summary, including payments received, balance forward, and credits and adjustments; and

• A detailed list of all fee-incurring charges; e.g., new registrations, registration renewals, registrar transfers.

Online B&C reports—The B&C system will generate a variety of reports for internal and external users.

• Using the Internet, registrars will be able to access their account statements and detailed transaction reports, but not those of other registrars.

• Registrars will be able to request custom reports. The system will generate these reports in a batch process, and will store them in the FTP directory for the requesting registrar to download.

Audit reports—NeuStar will create audit reports for internal and external purposes. Audit reports will include:

• Policy implementation;

• Access privileges;

• Capacity handling; and

• Accountability.

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:

• Manage large quantities of data;

• Support applications that use data models with complex relationships;

• Perform complex operations on managed objects; and

• Process large volumes of transactions from users.

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.

.org Database
The .org database will support and provide information for primary domain-registration services. The following table lists the data stored in the .org database.

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.

B&C database
The B&C database provides information for B&C services. Its contents include:

• Registrar billing profile—accessed and modified by the registrar administration function;

• Registrar account—queried, credited, and debited while processing transactions from registrars; and

• Catalog—Pricing information for different transactions queried in the charging process.

Whois database
Anyone can query the Whois database. Each database entity includes the following information for all second-level Internet domain names registered in the TLD:

• Domain name;

• Nameserver;

• IP address; and

• Registrar.

Database administration
NeuStar personnel who administer and maintain the databases will perform their tasks at times and intervals scheduled to ensure maximum system availability. Typical database administration tasks include the following:

• Monitoring and tuning;

• Backing up and recover;

• Adding additional data volumes;

• Implementation clustering strategies;

• Reorganizing;

• Adding and removing indexes;

• Evolving the schema;

• Granting access;

• Browsing and querying; and

• Configuring fault tolerance.

Database backup/restore
Proposal Sections C17.7 (Data Escrow and Backup) and C17.15 (System Recovery Procedures) describe our proven backup/restore processes, which we will employ for the SRS operations.  Backup frequency and logging processes will minimize data loss in case of system outage.

Disaster recovery
The active SRS data center will synchronize its database with that at the back-up SRS data center in near real time.  As Proposal Sections C17.7 (Data Escrow and Backup) and C17.15 (System Recovery Procedures) explain, in the unlikely event of a catastrophic outage at one data center, the SRS operations will fail-over to the replicate database.

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:

• Server operating system level access control provides protection against unauthorized access.  It employs userID and password, along with and file-access-control lists.

• Database security with user profiles enables NeuStar to grant or deny access privileges to registrars, database users, and database administrators.  The controllable level of granularity extends down to the individual data field.

• NeuStar will establish security policies and routine logging/auditing/monitoring functions to ensure there is no unauthorized access. We will periodically review security to ensure that the system is functioning as needed.

• Registrar access to the database is via trusted processes on both the application server, and the B&C server.

• NeuStar will establish routine auditing and monitoring features to ensure there is no unauthorized activity, and will periodically review our security features to ensure that the system is functioning as needed

Zone file generation.

Procedures for changes, editing by registrars, updates. Address frequency, security, process, interface, user authentication, logging, data back-up.

NeuStar will implement its proven methodology for generating incremental zone file updates, which allows for propagation of the zone file on a near real-time basis.  This will improve the service to the .org community by allowing them to rely on rapid implementation of zone file updates and changes.  

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 zone file is a flat database file consisting of the technical information that the DNS requires to function correctly: the domain name, nameserver hostname, and IP addresses (as necessary).  Traditionally, a TLD registry would update the zone file by generating a completely new zone file.  This zone file would be propagated to the nameservers, and would write over the existing zone file.  The size of the zone file and the fact that it was a complete replacement for the existing zone file dictated that the process be done infrequently, resulting in a process that could update zone files at most once or twice a day.  This is the process used currently for .org. 

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:

• Zone file generation (and propagation) is a batch process performed twice a day.

  • Because updates occur infrequently, registrants have an additional delay before their domain names become “live.”  This delay confuses the registrants, who believe that a problem exists and contact their registrar.  The registrars must, in turn, respond by deploying unnecessary customer support resources.

  • Currently, websites can easily go down when a registrant transfers a domain name to a new hosting provider.  Because of the current delay in zone file generation, the original hosting provider removes the web site before the DNS is updated with the new delegation information.  This adversely affects the general stability of the Internet.

• Zone file information does not match Whois information because the two files are often updated at different times.

  • Currently, registrants can update zone information, and then check the Whois server to verify it.  Because the zone file and Whois service are not synchronized, the registrants become confused.  As with delayed zone file updates, this information mismatch causes additional and unnecessary customer support demands on registrars.

Improved zone file generation process: the NeuStar solution
To eliminate these deficiencies, NeuStar has implemented an incremental zone file generation process.  Zone file updates are keyed off of changes in the .org database.  The registrars initiate changes to the .org database on behalf of their registrants.  For example, a registrar may add a new domain name through the RRP interface to the registry.  Once the name is added, the appropriate information (i.e., a DNS resource record) must be added to the zone file. 

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. 

Security
The .org database stores all data used to generate and distribute the zone file updates.  For security reasons, registrars cannot access this database directly; the application layer controls all database access.  Registrars access the database (through the application servers) using the RRP protocol via the protocol layer.  The following procedures govern creation and modification of database information:

• Registrars are solely responsible for creating, modifying, and deleting information that is updated in the zone file.  The RRP protocol is the only gateway available to registrars for zone file editing.  This protocol is accessed using the NeuStar RRP servers.

• A registrar gains access to a domain name (and associated nameserver) when it registers that domain name or when the appropriate “transfer of registrar” is enacted.  In the case of a “transfer of registrar”, access control is revoked from the losing registrar after the transfer. 

• Access control to zone file data for RRP “Delete/Modify Domain Name” commands is granted only to the registrar that has management rights over the domain name. 

• In the case of an RRP “Create/Modify/Delete Nameserver” command, access control is granted only to the registrar that has management rights over the nameserver’s parent domain name (i.e., ns1.icann.org has a parent domain name icann.org).

Logging and data back-up
All zone files and updates are generated using information from the .org database.  All updates are recorded as database transaction logs.  Proposal sections C17.7, C17.14, and C17.15 contain information about the primary database backup and escrow systems, data center replication, and data recovery procedures.

Standards compliance
Each nameserver will run software that correctly implements the IETF standards for the DNS (RFC1035, RFC1995, RFC2136, RFC2181).  Further, NeuStar has implemented all applicable best-practice recommendations contained in RFC2870 (Root Nameserver Operational Requirements) for its existing registry business, and will implement them for the .org TLD.

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.

NeuStar’s existing near real-time zone file update capability will provide a significant improvement in the registry service provided to the .org community. 

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
As discussed in Proposal Section C17.4, the zone file distribution administrator frequently polls the .org database for events that would generate a change in the zone file.  Once certain conditions are met (i.e., quantity of updates or expiration of a time interval), the administrator will push out an incremental file to a master nameserver located within the SRS data center.  The master nameserver compiles those changes since the last zone file update into a new incremental zone file update. Triggered by predefined conditions, the master nameserver provides the incremental update to the constellation of nameserver clusters.  Zone file updates are engineered to occur in intervals no longer than fifteen minutes.  As previously shown, Exhibit C17-10 depicts the nameserver generation, distribution and publication architecture. 

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.

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:

• Debiting and crediting registrars accounts;

• Initiating low-balance notifications;

• Enabling registrars to view their accounts; and

• Tracking and reporting historical information.

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:

• Generating the large amount of detailed resource-accounting information needed to support detailed usage-based charging of registrars;

• Supporting flexible queries of the .org B&C database through an API; and

• Tracking and reporting historical information.

B&C system description
Exhibit C17-13 illustrates the following key components of the B&C system and its interfaces with other SRS subsystems.

• Registrar profile administrator—This component responds to the registrar administration component of the application server; and

• B&C processor—This component processes all domain registration-related requests and other billable events from external servers.

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.

B&C procedures
The B&C system processes data that is generated during the following types of procedures:

• Registrar administration—The B&C system will manage the B&C profile for registrars, along with the account and contact information.

• Transactional services—Actions that trigger a B&C event.  Registrar’s requests result in “transactions” at the application level and “events” in the B&C process. 

• Non-transactional services—Actions including balance forecasting, account balances.

The following tables provide details of each type of process flow.