III283 Network Speed and Proposed Service Levels

By Todd Tucker,2014-09-12 12:17
8 views 0
III283 Network Speed and Proposed Service LevelsAND,and,speed,Speed

Application for .geo Sponsored TLD

    Registry Operator's Proposal Section III.2

III.2.7 Data Escrow and Backup (RFP Section D15.2.7)

    JVTeam will back up the databases in our data centers in Sterling, VA and Chicago, IL, and will regularly place escrow copies of the backups in secure off-site locations. These procedures are essential elements of our realistic plans for continuity of operations in the event of system failures and natural or man-made disasters. 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


    The conventional strategy for guarding against loss of the 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 oc-currence of the disaster. Users are subject to denial 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 backups often is done only weekly, meaning that a disaster could result in substantial loss of both services and data.

    JVTeam’s backup solution goes a step further. We propose two co-active SRS data centers, each capable of handling the

    entire workload should a major system failure or natural or man-made disaster occur at the other. The transactions from each data center are replicated in real time to the other over a redundant high-speed Virtual Private Network (VPN) tele-communications links. Each SRS data center also conducts independent backups, as described in the following paragraph. Since the two SRS data centers are co-active, our backup strategy maintains continuity of operations and enables full recov-ery of all transactions, even in the event of multiple hardware failures.

    III.2.7.1 Frequency and Procedures for Backup of Data

    Each co-active data center independently implements a zero-downtime/zero-impact incremental data backup each day, and a full data backup weekly. We place escrow copies of the backup tapes in a secure off-site storage facility operated by a third

    party whose business is data escrow. 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 DLT tape 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 III.2.3 (SRS DB, Whois, Billing). Each data center uses on-line zero-downtime/zero-impact, backup procedures that include the following 4 steps: 1. The database is put into backup mode to guarantee a consistent version of the data on the snapshot copy that is written

    to a RAID disk array for subsequent (slower-speed) copying to tape. While the database is in backup mode, the XRP,

    Whois, and Billing applications continue to function and to access the data. The database normally is in backup mode

    for only about 5 to 10 minutes.

    2. The backup software writes the data to the RAID disk array.

    3. The backup software, which is located on a backup server independent from the application servers, creates the backup

    DLT Tape copy from the snap shot copy on the RAID disk array.

    4. When the backup is finished, the DLT Tapes are transported to the secure escrow facility.

JVTeam III.2-67

Application for .geo Sponsored TLD

    Registry Operator's Proposal Section III.2

III.2.7.2 Backup Hardware and Software Systems

    Exhibit III.2-19 depicts the SRS data centers’ backup and recovery hardware and software. Each data center’s system in-

    cludes two backup servers with DLT robotic tape libraries. The data backup system uses the DLT IV data cartridge and the DLT 5 data format. To achieve zero-downtime/zero-impact backup, we use a RAID disk array and a high-speed-fibre, channel-bridge interconnect to the robotic tape libraries. The backup server copies not only the database-server’s backup

    files to the disk array, as discussed in the 4-step process already described, 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 can meet our Service Level Agreements (SLAs).

    Due to the criticality of the database, the JVTeam proposes a fully redundant, fault-tolerant database management system. We will configure the database system as two independent database servers primary and backup with synchronous rep-

    lication using two-way commits to maintain database synchronization. If one database server fails, the database system is sized so that the second server can process the entire load without degradation while the primary server is restored to ser-vice.

    We will transport both daily incremental backups of dynamically changing data and the weekly full backup to a secure es-crow agent to be selected with the concurrence of ICANN.

    III.2.7.3 Procedures for Retrieval of Data and Rebuild of the Database.

    We maintain copies of the DLT tapes holding incremental data backups in a three tape rotation:

     One DLT backup tape is in transit to the secure escrow facility.

     A second DLT tape is in storage in the secure escrow facility

     The third DLT tape is in the data center for reuse.

    The full backup tapes are maintained in a 2-tape rotation, with one tape at the secure escrow facility and one at the data center for reuse. A copy of the static-data CD ROMs for the operating systems and applications are also maintained at the escrow facility.

    Should the primary database server experience a catastrophic crash that necessitates a lengthy recovery process, data-center operations continue seamlessly on the backup database server that replicates all the data in the primary. After the failed database server is repaired, we recover its data using the full backup tape and incremental backup tape that is retrieved from the escrow facility. We first restore the full backup files; then, the incremental files. We then synchronize the recovered da-tabase to the primary database. This procedure recovers the database to the last complete transaction processed by the pri-mary database.

    This backup procedure enables JVTeam to meet the service level agreements required for continuous availability and near-zero unplanned downtime, thereby improving the stability of the Internet, enhancing public confidence, and improving customer satisfaction.

JVTeam III.2-68

Application for .geo Sponsored TLD

    Registry Operator's Proposal Section III.2

III.2.8 Publicly Accessible Look Up/Whois Service (RFP Section D15.2.8)

    JVTeam proposes a Whois service that will eliminate problems associated with the current multiple Whois sys-tems. The most serious of these problems is a genuine threat to the stability of the Internet: the possibility that relying on Whois information that can be at least 12 hours out of date could result in an erroneous change relating to the domain name of a large Internet site that performs millions of dollars worth of e-commerce transactions


    Whois is a database of information about Internet domain names. JVTeam’s proposed registry will maintain a state-of-the-

    art, real-time Whois service that will make this information available on the common Whois port (Port 43). Our registry will store all information relating to Whois data entities, including contact and authentication data. The Whois service is intended as a directory service for registrants, as well as for any other individuals and businesses that want to query details of domain names or related data stored in the registry. Our Whois data will be available in both con-ventional and machine-readable format, facilitating automation. Further, the level of information displayed will be confi-gurable.

    Registrars will provide the front-end web interface to the Whois directory. Because this interface will be a simple wrapper around the registry’s Whois service, the registrars will have complete control over the service’s look and feel and branding.

    With this control, registrars will be able to comply with the privacy restrictions enacted by the countries where they operate.

    Problems with Current TLD Whois Service

    The current .com/.net/.org Whois service has caused many problems for both registrars and registrants. The system has confused registrants, and its inherent problems have increased costs (and risk) to registrars, who had to provide manual processing or recovery from failures in automated processes. Inherent system problems include the following: Different protocols used (i.e., not all registrars use Whois on Port 43)

JVTeam III.2-69

Application for .geo Sponsored TLD

    Registry Operator's Proposal Section III.2

Different fields exposed

     Different formatting of data

     Timing inconsistencies (regarding adding, deleting, transfer of registrar, etc) Not real time (Whois is updated only every 12 hours)

     No standard machine-readable format

    As a result of these system problems, records in a registrar’s Whois can contradict those in the registry’s Whois, or records

    in two registrars’ Whois services can contradict each other. The most serious problem with the current system and an issue of serious concern relating to the stability of the Internet is that a gaining registrar uses the Whois service to determine if a

    Transfer of Registrar request is authentic. If a mistake is made in the transfer of registrar, an incorrect owner could redele-

    gate a domain name (or change ownership), potentially bringing down a large Internet site performing millions of dollars of

    e-commerce transactions per day.

    Benefits of Proposed Solution

    The system problems cited in the preceding paragraph could theoretically be solved with stronger enforcement of technical

    standards, such as protocols, fields, and data formatting. JVTeam’s proposed solution centralizing the Whois data and pro-

    viding access via registrars is more pragmatic and will solve all current problems. Our solution would provide:

     Central location for all authoritative TLD data

     Standard protocol accessible over port 43

     Consistent format (fields, formatting, etc) for all registrars Machine-readable format (promotes automation)

     Elimination of ―timing‖ problems when modifying entities

     Real-time update

     Extensible field capability.

JVTeam III.2-70

Application for .geo Sponsored TLD

    Registry Operator's Proposal Section III.2

III.2.8.1 Whois Service Functional Description

    The Whois service will accommodate queries regarding the data entities listed in the following table.

    Entities Fields

    Domain names Attributes (Status)

    Associated nameservers

    Associated registrar

    Associated registrant data

    Nameserver Attributes (Status)

    Associated IP addresses

    Associated registrar

    Associated registrant data

    IP Address Attributes (Status)

    Associated nameserver

    Associated registrar

    Associated registrant data

    Registrar List Registrar name

    Registrars Registrar name

    Registrar contact details

    Registrar URL (Home page)

    Registrar Whois URL (Web Port 80)

    Registrar Whois URL (Port 43, if applicable)

    Attributes (Status)

    Machine-Readable Format

    JVTeam’s standardized Whois format will facilitate automated parsing of Whois information

    Because the viewable data could be modified over time (e.g., new fields could be added), a more robust and formalized en-coding mechanism is needed to provide the non-Registrar community reliable automated access to Whois data. For example, an organization tracking trademark infringement might want to acquire the Whois data, automatically parse it, and store it in a tracking system. To accommodate such organizations, which will not have access to the XRP protocol, the Whois information must be presented in a formal, extensible way that is compatible with automated processing. To ac-complish this, we will present the Whois data in an open, standard, XML-based, machine-readable format that we designate as the XWP (eXtensible Whois Protocol). The information accessible via the XWP is inherently tied to the XRP (eXtensi-ble Registry Protocol) data requirements, and thus, will be part of the same standardization process. Just as we will do with the XRP, JVTeam commits to submitting the XWP to an industry standards body for adoption and future modification according to that body’s normal procedures.

JVTeam III.2-71

Application for .geo Sponsored TLD

    Registry Operator's Proposal Section III.2

Extensible-Field Capability

    In the spirit of providing advanced services to the registrar community, JVTeam will introduce the ability for registrars to use XRP to add customized fields to a record in the registry database. These fields will appear in an ―additional informa-

    tion‖ section of the Whois data. The maximum number of custom fields allowed per record is yet to be determined.

    The extensible-field capability will eliminate the need for registrars to store additional information in their own local data-base, then combine it with the registry Whois information when they present it to end users. The proposed capability will also ensure that end users will view the same information no matter which registrar they use to retrieve Whois data. All custom fields would appear in a special additional information section at the end of the uniform Whois data. In human-readable form, the customized fields could appear as follows:

    Additional Information:




    In XWP format, the customized fields could appear as follows:





    JVTeam intends to provide extensible-field functionality during any Sunrise period to support publishing of trademark (and associated) information.

    Bulk-Access Program

    Much of the load placed on the current .com/.net/.org Whois service is caused by automated programs mining for data. Because Whois data is publicly accessible, this will always occur; however, JVTeam proposes to provide a data mart. that limits the recipient’s conditions of use.

    The proposed data mart bulk-access program would:

     Reduce the load that data mining currently imposes on the core Whois service

     Contractually limit subscribers in the ways they can use the data

     Provide a source of revenue to fund advanced service levels

     Reduce the incentive to download entire database without legitimate purpose

JVTeam III.2-72

Application for .geo Sponsored TLD

    Registry Operator's Proposal Section III.2

     Provide the entire database in a format that facilitates such data mining as conducting trademark searches, compiling

    industry statistics, and providing directory services.

    The registry will make the Whois data available to registrars, who will conduct the actual bulk-access program. Data will be exposed only within the privacy restrictions described in the following subsection.

    Privacy Restrictions

    A number of countries have enacted privacy laws (e.g., the European Union Privacy Directive) that restrict the information that can be presented in the Whois service. Under the terms of its licensing agreement, JVTeam will bind registrars to comply with all applicable privacy laws while providing Whois services.

    Each registrant account will have a privacy attribute that can be set to one of the following levels: UnrestrictedComplete registrant details displayed

     RestrictedRegistrant name and address displayed

     PrivateNo Registrant details displayed

    Registrants in countries that have enacted privacy laws can select the privacy level permitted under law. No matter which level they select, such details as the delegated nameservers and associated registrar will still be visible. Private information will be released only under court order or the direction of some other authority that has legal jurisdic-tion to demand such release.

    Restricting private data will not create problems for registrars’ ―Transfers of Change of Ownership‖ transactions because

    these operations will be conducted using the centralized authentication mechanism.

    III.2.8.2 Whois System Architecture

    JVTeam will deliver a Whois service that incorporates semi-real-time update, scalable infrastructure, and multiple layers of redundancy. We will initially deploy the Whois servers at the two co-active SRS data centers shown previously in Exhibit III.2-1. The software architecture will enable us to deploy Whois infrastructure to any number of additional JVTeam data centers. As the registry grows, we will deploy additional Whois infrastructure as appropriate to increase geographic disper-sion, enhance the level of service in particularly geographic regions, and reduce the load on the SRS data centers. We are willing to negotiate with ICANN about adding and siting additional Whois services.

    Exhibit III.2-20 illustrates the Whois architecture. At each Whois site, incoming queries are distributed by a load balancer to a cluster of Whois servers, which are, in turn, connected to a backend database cluster. This configuration will provide both redundancy and scalability through the addition of servers to either cluster.

    Each Whois server will cache common requests in memory and query the back-end database cluster only on a cache miss. We can configure the duration that Whois information is cached before being deleted (e.g., 10 minutes); after deletion, the server must query the database for the information. Each Whois server will be configured with at least 2 GB of high-speed memory, sufficient to hold at least one million of the most commonly queried Whois records.

    Exhibit III.2-21 depicts the update of the Whois databases. As the SRS database is updated, the system will also update the Whois distribution database server in real time. This database will be replicated to the Whois databases within defined ser-vice levels (e.g., 10 minutes). Replication between data centers always occurs over a VPN or a dedicated link, and the regi-stry will digitally sign update packages.

JVTeam III.2-73

Application for .geo Sponsored TLD

Registry Operator's Proposal Section III.2

JVTeam III.2-74

Application for .geo Sponsored TLD

Registry Operator's Proposal Section III.2

JVTeam III.2-75

Application for .geo Sponsored TLD

    Registry Operator's Proposal Section III.2

The proposed Whois service offers the following benefits:

     Service can be scaled by adding servers to each Whois cluster

     Databases can be scaled by adding machines to each database cluster

     Service can be scaled by deploying Whois infrastructure to additional data centers

     Inherent redundancy ensures high availability

     Update process ensures near-real-time availability of the latest information

     Caching of common queries provides superb response time.

    III.2.8.3 Network Speed and Proposed Service Levels

    The large volume of Whois queries places a significant network-connectivity burden on the registry. Based on the assump-tion that each Whois query will generate approximately 10 Kbits of network traffic, we will use the following engineering guidelines for provisioning bandwidth:

     Initially, we will provide 25 Mbits per data center. The total of 50 Mbits will support approximately 5,000 queries per

    second (approximately 430 million requests per day).

     As the volume of registrations grows, we will extend the service at a rate of 10 Mbits per one million domain-name

    registration records under our management. For example: when the registry manages 20 million domain names, we will

    dedicate 200 Mbits of Whois bandwidth, which will support nearly two billion Whois queries per day.

    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, and are willing to negotiate service levels:

     400 million queries per day (90% cache hits, 10% cache misses, which must be forwarded to database file). We will

    increase this query-service demand based on the total number of domain name registrations managed by the registry, as

    previously discussed.

     200-millisecond latency for cache hits (after the request reaches the data center).

     500-millisecond latency for cache misses (after the request reaches data center).

    We will configure the Whois service to limit connections based on the following criteria:

     1000 queries per minute from any single IP address

     20,000 queries per minute for requests originating from designated registrar subnets

     An ―acceptable use‖ policy that we will negotiate with ICANN and the registrar community.

JVTeam III.2-76

Report this document

For any questions or suggestions please email