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

All registry data is continuously replicated to two standby database instances.  Registry Advantage also stores backups at off-site locations, including a Data Escrow provider.

Backup 

The .org registry will be protected by a variety of data backup and escrow mechanisms, ranging from the real-time replication of critical data to a comprehensive traditional tape backup scheme, and also including full third party data escrow.

Registry Advantage will replicate most important data in real time.  Using Veritas Global Cluster Manager and the Global Application Data Synchronization Framework, the Oracle database will be replicated from the active site (see the definition in C17.3) to the backup site.  Application data will be copied to both the active and backup sites before moving from development to production systems.  This duplication of data allows for failover procedures to provide a mechanism to resume the operation of the registry at the alternate site in the event of a failure at the active site.

At the primary site in New York, a secondary storage array will also back up the active database.  As described in C17.3, redo logs will be copied from the active database server to the separate storage array used by the standby database server.  These logs are used to bring the standby database instance up-to-date at one-minute intervals.  In the event of a failure of the active storage array, the standby database server can become active and resume all database functions.

Two additional mechanisms will be employed to back up database information to tape, using AIT3 tape libraries as described in Attachment M2.  First, logical backups will be made of the complete database daily.  Second, complete physical backups of all .org database information will be performed on a daily basis at the primary site; at the secondary site in Asia, complete physical backups will be performed on a weekly basis complimented by incremental backups on a daily basis.

Application and log data will be stored to tape on a similar schedule to physical data backups for the database.  This information will be completely backed up to tape on a daily basis at the primary site.  At the secondary site, complete weekly backups will be complimented by daily incremental backups.  Registry Advantage will use Veritas Net Backup software to facilitate the restoration of data in accordance with disaster recovery procedures.  Sets of tapes will be rotated to secure off-site locations on a regular basis.

Escrow Services

As required by the Registry Data Escrow Agreement (Appendix S of the Unsponsored TLD Agreement (“model registry agreement”)), Registry Advantage shall deposit into escrow all registry data on a schedule to be agreed with ICANN ((i) full data sets for one day of each week (the day to be designated by ICANN) and (ii) incremental data sets for all seven days of each week) and in an electronic format mutually approved by Registry Advantage and ICANN.  The escrow shall be maintained by a reputable independent escrow agent.  Registry Advantage shall not charge the DotOrg Foundation any additional fee for escrow services.  Registry Advantage has already identified an independent escrow agent to provide similar services for the .pro TLD; this same escrow agent can also be used for the .org data.  

Per the Escrow Agreement, the use of the escrow data will be limited to verification that the deposited data is complete and in proper format to protect the privacy of the data.  The data would be released to ICANN upon the occurrence of one of the events and per the terms described in Section 9 of the Escrow Agreement, termination of the registry agreement or in the event of an applicable court order or subpoena.  Further details about data escrow would be modeled on Appendices R and S to the model registry agreement.

C17.8. Publicly accessible look up/Whois service. Address software and hardware, connection speed, search capabilities, coordination with other Whois systems, etc. 

Figure C17.8.1 Peak Requirements

Registry Advantage will make available a centralized, shared and publicly available Whois service at its site in New York as well as at the secondary location, with access to the Internet connectivity and infrastructure built to support all of the .org registry functions.   This service will utilize a custom Whois server application based on the Whois application developed by Register.com.  This robust application provides Whois service for over three million domain names and answers approximately 500,000 queries each day.  Registry Advantage will deploy load-balanced clusters of Intel x86-based hardware (described in C17.1) able to handle tens of millions of queries per day.  While only a small number of servers are needed to accommodate anticipated load, Registry Advantage will deploy additional hardware to insure complete fault-tolerance within the system. Updates will be propagated from the database to the Whois service in near real time when domains are registered or modified.

Initially the registry will operate in a “thin” mode, meaning that only a limited set of data will be stored in the registry’s database and made available through the Whois.  The DotOrg Foundation proposes a gradual transition to a “thick” registry in which a complete set of Whois data is stored by the registry in one central location, allowing for more effective and efficient search capability.  For further details regarding the transition from thin to thick registry operations, please refer to section C22.

For queries relating to domain names, the publicly available .org Whois service will respond to requests for a single domain name and will generally provide back the following information:

• Domain name
• Registrar information
• Name servers (if any)
• Registrant information*
• Administrative and technical contact information*
• Date of registration, date of last modification, date of expiration
• Optional link to optional DotOrg Directory (see Questions C25 and C27)*

* These fields are only available in the “thick” Whois mode.

Queries may also be performed on name server, registrar and contact (when applicable) objects.  Details regarding these queries are provided below.

Once the transition from thin to thick registry operations has been completed, data can be presented in a standard format for domains registered by any registrar.  However, in order to accommodate local privacy laws, the registry will provide a mechanism for certain data from individual domains, or possibly across entire registrars, to be “masked” and made unavailable to the public.  The specific fields that can be masked will be determined by the DotOrg Foundation and Registry Advantage in collaboration with ICANN, based on current ICANN policy.

Protocol

The DotOrg Foundation’s Whois service is made available through the port 43 Whois protocol.  The Whois protocol is defined in RFC 954 [1] and the DotOrg Foundation will ensure that its Whois server operates according to the protocol defined therein.  RFC 954 describes the Whois protocol as follows (note that while the protocol specification references SRI-NIC specifically, it may be applied to other registries, such as the .org:).

To access the NICNAME/WHOIS server:    

Connect to the SRI-NIC service host at TCP service port 43  
(decimal).    

Send a single "command line", ending with <CRLF> (ASCII CR and   LF).     Receive information in response to the command line.  The server closes its connection as soon as the output is finished.

 Query Syntax

The command line transmitted by the client must be in the following format:

[type =] query

In the syntax above, arguments indicated in italics are keywords that must be replaced by particular values as described below.  Portions of the syntax contained within [square brackets] are optional.

The following type keywords are used to indicate that the query applies to a specific object type:

If the optional type keyword is not provided, the default behavior is to search only domain objects as if the “Domain” keyword had been specified.

The query provided must be an exact match for the Name (fully qualified), ID, or IP address field of the object being searched for (as specified above).  The query is considered to be case insensitive.  All queries will return at most a single result, except nameserver queries based on IP address, which may return multiple results if the same IP address is associated with multiple name server names. 

The server will return two varieties of responses:  errors, and successful query results.  All lines in an error result will be preceded by the string “%%”.  The rest of the line will contain freeform text describing the error condition.  Each line will be terminated by <CRLF>.  The number of lines and length of each line is variable.

An example of an error result is below:

%% No match.

The other type of response is a successful query result.  Three types of lines may be contained within a query result:  comment lines, blank lines, and data lines.  The first character in a comment line is the character “#”.  These lines contain information that is not intended to be parsed by machines and may contain statements of registry policy, status information regarding the Whois service, or other freeform messages.  These lines should always be displayed by Whois client software.  Blank lines contain no data or only white space and are presented only for visual formatting purposes; they should also be ignored by parsers.  Data lines are formatted in key/value pairs to facilitate machine readability.  The format of data lines is the key, followed by the character “:”, followed by a space, followed by the data.  All lines are terminated by <CRLF>.

Responses

Domain Queries

Domain queries will return different types of responses based on whether a thin or thick set of data is stored for that domain name.  Fields in boldface below may appear more than once.  Fields in italics are optional and may not appear. 

For those domain names with only a thin set of data, the following fields will be returned in response to a Whois query:

Domain Name
Sponsor ID
Sponsor Whois Server
Sponsor URL
Nameserver
Updated Date

For those domain names with a thick set of data, additional fields will be returned in response to a Whois query, and the “Sponsor Whois Server” field will not be returned.  The total fields present in a response to a domain with a thick set of registry data are as follows:

Domain Name
Sponsor ID
Sponsor URL
Registrant ID
Registrant Name
Registrant Organization
Registrant Address 
Registrant City
Registrant State/Province 
Registrant Country
Registrant Postal Code 
Registrant Phone Number
Registrant Fax Number
Registrant Email
Admin ID
Admin Name
Admin Organization
Admin Address
Admin City
Admin State/Province
Admin Country
Admin Postal Code
Admin Phone Number 
Admin Fax Number 
Admin Email
Tech ID
Tech Name
Tech Organization
Tech Address  
Tech City
Tech State/Province  
Tech Country
Tech Postal Code 
Tech Phone Number
Tech Fax Number  
Tech Email
Nameserver  
Link to DotOrg Directory
Updated Date

Sample input and output for a successful query for each type of domain is provided below.  The first example is a domain with a thin set of registry data

The second example demonstrates sample output for a successful query on a domain with a thick set of registry data:

The following lines may be present in the response to a query for a contact object:

Contact ID
Sponsor ID
Sponsor URL
Name
Organization 
Address 
City
State/Province 
Country
Postal Code 
Phone Number
Fax Number
Email
Updated Date

Sample input and output for a successful query is provided below:

Name Server Queries

The following lines may be present in the response to a query for a name server object:

Nameserver ID
Sponsor ID
Registrar URL
Server Name
IP address 
Updated Date

Sample input and output for a successful query is provided below:

Registrar Queries

The following lines will be present in the response to a query for a Registrar object:

Registrar ID
Registrar URL
Registrar Whois Server (2)
Address (1)
City
State/Province
Country
Postal Code
Phone Number
Fax Number
Email
Updated Date

Fields marked with (1) above may appear more than once.  Fields marked with (2) are optional and may not appear.  The “Registrar Whois Server” field will be phased out once the registry includes only domains that have a thick set of registry data.

Sample input and output for a successful query is provided below:

Abuse Prevention

To prevent the abuse of the Whois database, the IP addresses of incoming requests will be logged.  In the event that an excessive number of requests from a specific IP or network are made, the Whois servers will temporarily block additional requests from the same IP address or range.

Bulk Access

In addition to the publicly available Whois information, the .org registry will provide bulk access to a limited subset of this information to individuals or organizations that agree to specific terms of use.  This bulk access is governed by the Registry Agreement.  Bulk access at the registry level will include only the following information:

Domain name

Sponsor ID

Associated nameservers (if any)

Bulk access to additional information may be provided by individual registrars, as per ICANN policies and in accordance with applicable law. 

C17.9. System security. Technical and physical capabilities and procedures to prevent system hacks, break-ins, data tampering, and other disruptions to operations. Physical security.

Robust security is an element in every part of the registry design.  Each user’s access to the system is strictly limited.

Due to the critical nature of the .org registry’s data, Registry Advantage will conduct all of its operations with significant attention to security, in conjunction with existing security practices.  All Registry Advantage systems are designed to provide the .org registry with world-class security at every level.

Physical Security

All registry database and shared registration services are operated in extremely secure hosting facilities.  The following physical protections are used throughout data center facilities:  use of 24/7 guard service, alarm systems, several layers of physical barriers, and use of biometric identification devices.

Generally, positive identification is required of all personnel entering and exiting the facility.  Data center floors are isolated from areas in which visitors are commonly allowed.  Each data center tenant is separated from others by steel cages, and movements within the data centers are carefully monitored.

In addition to preventing unauthorized persons from accessing the registry systems, the robust infrastructure has significant fire suppression, flood, earthquake and even radiation resistance.  The robust physical plant is intended to minimize the chance of unexpected events from impacting the registry’s operations.

Network Security

Registry Advantage employs a number of measures to prevent unauthorized access to its network and internal systems.  Before reaching the registry’s internal network, all traffic passes through a firewall system.  Packets passing to or from the Internet are inspected, and unauthorized or unexpected attempts to connect to the registry’s servers are denied and logged.  The registry’s routers also act as the first line of defense against any denial of service attacks, with the ability to instantly deny traffic from a specific host, network, or even an entire Internet Service Provider. Refer to the network diagrams (currently figure 28 on p39) for details of Registry Advantage’s network infrastructure.

Front-end registry servers (such as the SRS, Whois and name servers) sit behind a second layer of network security provided by load balancing equipment.  The hosts use RFC 1918 reserved address space that is not routable on the public Internet. Packets destined for specific services such as DNS or the registry’s SSL-protected applications are translated only after being subjected to additional security checks; suspicious traffic is dropped before being translated and will not reach the servers.  Additionally, front-end systems are arranged into load balanced clusters; even if an attack is successful on an individual host, subsequent requests by the attacker will reach other servers, making it extremely difficult to take advantage of any weakness. Critical internal systems, such as database and file servers, also have non-routable IP addresses, and absolutely no traffic is permitted to reach them from the public Internet.

Registry Advantage also operates a network-based intrusion detection system (NIDS) at both the primary and secondary site.  The NIDS monitors the network for suspicious activity.  If possible malicious activity is detected, appropriate personnel will be notified immediately.

In addition to traditional stateful inspection and border ACL levels of security, Registry Advantage utilizes state-of-the-art Denial of Service (DoS) and Distributed Denial of Service (DDoS) prevention techniques, including advanced flow setup throttling and aggressive session table management.  Especially susceptible to DDoS attacks are UDP based services such as DNS.  However, Registry Advantage has worked extensively with its firewall vendor, NetScreen, to provide unprecedented protection against these attacks on DNS services specifically by helping to design UDP state building rules using layer 7 DNS information.  With the NetScreen advanced state building rules, DDoS attack packets targeting the Registry Advantage DNS UDP service are dropped at the firewall, before they reach the internal access network.

Server Security

Registry Advantage employs a set of security precautions to ensure maximum security on each of its servers.  Although specific procedures vary based on operating system, specific function of the host, and other factors, minimum standards on each server include:

• Disabling all unnecessary services and processes
• Regular application of security-related patches to the operating system or critical system applications
• Installation of tools such as SYN cookies to prevent denial of service attacks
• Use of host based intrusion detection tools and log file analysis to ensure the ongoing integrity of each system
• Accounts on all production systems are only assigned to a limited set of administrative personnel.  Developers, customer service employees, and others will not have login accounts on these servers.

Application Security

In addition to following commonly accepted security standards for application design and operation, Registry Advantage subjects its code to rigorous internal security audits on a periodic basis.   Additional security for the infrastructure as a whole is increased by Registry Advantage's custom DNS and WHOIS server implementations.  These remove the possibility of being susceptible to security problems that may exist in the freely-available software products.   The IETF has already noted that heterogeneity within the global DNS architecture is a benefit - RFC 2870, section 2.1 states, "It would be short-sighted of this document to specify particular hardware, operating systems, or name serving software.  Variations in these areas would actually add overall robustness".

Protocol Security

The security mechanisms used to protect registry-registrar functions are discussed in Question C17.2.  These measures are intended to prevent unauthorized access, and in the future, Registry Advantage may also introduce a unique digital signature for each database object, making it extremely difficult for an attacker to tamper with the registry’s data.

Access to Systems

Registry Advantage will provide highly differentiated system access to different classes of users.  Each user will be provided with access to only those functions and portions of the registry data that are required by that user.  Although specific policies will be implemented for each class of user and each service or machine, a general outline of access restrictions follows.

• Registrars – Read/write access through both the SRS and Account Management Interface to all domains and other objects sponsored by the registrar.  A limited set of information (similar to that provided to the general public) will also be accessible for those domains sponsored by other registrars.
  
• Registry Advantage employees
  
  • Customer Service representatives – Read-only access to the entire registry database; ability to perform certain pre-defined functions such as undeleting domains that are within the delete pending period.
  • Software developers – Access only to development and staging environments.  No access to production systems.
  • System administrators – These are the only employees with logins directly on the registry’s production servers.
  • Accounting and other business functions – Access to reporting capabilities similar to those provided to registrars, but with the ability to access the data for the entire registry.
• DotOrg Foundation employees – Access to reporting capabilities similar to those provided to registrars, but with the ability to access the data for the entire registry.
  
• Zone file and Bulk Whois agreement signees – Access only to the appropriate distribution server.  The only function that these users will be able to perform will be to initiate the download of the appropriate file.

C17.10. Peak capacities. 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.

Figure C17.10.1  Peak Requirements

Registry Advantage has taken a number of steps and precautions to ensure that its systems are capable of dealing with larger than expected surges in demand, even though it is unlikely the transition of the .org registry will be accompanied by the same kind of initial surge in demand that became commonplace with the opening of new gTLDs.

Registry Advantage has already designed and built systems to accommodate a registry of the size and importance of the .org TLD. To validate the current capabilities of its systems, Registry Advantage performed a series of load tests on its SRS, DNS and Whois services. With the goal of enhancing the external validity of the tests, the entire .org dataset was loaded into the registry database and test queries were generated from this dataset. The hardware, network and software configurations used for the testing matched those already in place at Registry Advantage’s primary data center, and the configurations also matched those proposed for the .org registry.

Expected test results were established prior to running the tests, based on several triangulated inputs. The purpose of this was to extrapolate and predict the expected typical and expected peak loads on the SRS, DNS and Whois services for the .org registry.  Information from ICANN advisories, SnapNames’ State of the Domain reports and data supplied by VeriSign to the North American Network Operator's Group were combined with data drawn from Registry Advantage’s experience as a registry outsourcing provider to analyze and predict the expected volumes.  For example, the expected peak for SRS checks per second was estimated using data from the ICANN “add storm” advisory [2] , which related to the full com/net/org dataset. These numbers were scaled based on the portion estimated by Registry Advantage as related to the .org domain. A full description of the test results and methodology is provided in Attachment I.

The SRS tests included queries of all the major types (adds, checks, infos, deletes) combined into test sets that were representative of ‘typical’ loads as well as atypical ‘add storm’ loads.  The Whois and DNS tests covered a range of .org query mixes (successful queries, failed queries, malformed packets, etc.) conducted in a random order to determine maximum queries per second.

The table below summarizes the major results attained in the testing. It is important to note that the number of servers in the SRS test cluster were actually fewer than the number proposed for .org (3 servers instead of 6 servers), yet the performance of the 3 servers alone exceeded expected peak capacity in all cases. Across all parameters and tests, performance significantly exceeded both the expected typical and expected peak levels as determined from the publicly available data about the .org TLD.

Translating the SRS performance capability numbers into hourly peaks, Registry Advantage’s SRS servers are capable of up over 3 million checks per hour, in addition to the successful registration of over 655,000 new domain names in the same one-hour period.

These levels of capacity and redundancy mean that, even in a scenario where one or more components fail at the same time as increased registration volume, the systems will continue to process expected peak registration volumes.  In the unlikely event that additional hardware is needed, Registry Advantage can re-deploy hardware on an emergency basis to accommodate larger-than-expected demands on the system during the initial months of operations.  For example, if database resources are under strain, processors and memory can be moved from the standby Sun E-6500 to the active database server.  This configuration leaves the primary site with only active and backup database servers, but given the other layers of system redundancy described in Sections C17.1 and C17.3, this is an acceptable contingency for a short period of time.  In the event that the SRS front-end systems become a bottleneck, servers from Whois and name server clusters can be moved to the SRS cluster, as these other services will be under relatively lower load during the initial months of the .org registry’s operation.

To monitor and manage peak loads in real-time, Registry Advantage will utilize state-of-the-art performance management and profiling tools.  These tools are capable of modeling performance and correlating application work loads with specific infrastructure components and component sets.  Peaks in various application workloads can be modeled and their impact anticipated with operational responses, including adding hardware in key areas of the infrastructure and modifications to logical storage layouts to avoid disk I/O bottlenecks.

Registry Advantage will use its performance monitoring tools to carefully manage the transition during the first few weeks of registry operation.  As described in section C18.1, the DotOrg Foundation plans to pursue a cautious approach with the transition.  The proposal is to gradually ramp up the operation of the SRS over the course of a week in order to prevent the system from being overloaded by pent-up demand at the time of launch.

It is also worthwhile to note that Registry Advantage plans to use extremely common Intel x86-based servers in all of its front-end systems.  This hardware is nearly ubiquitous within the market and it would be extremely straightforward to obtain additional servers if needed.  The use of layer 4 load balancing techniques as described in Section C17.1 makes it simple to rapidly move additional servers into a cluster.  Although the Sun Enterprise hardware used for database servers is not as common, it is widely available and additional hardware could be readily obtained if necessary.  The initial database server configurations allow for significant additions of CPUs and memory within the E-6500 systems that Registry Advantage will deploy.

As mentioned above, the full .org dataset was loaded into the database to test the DNS, Whois and SRS applications using real data. Loading the full dataset also provided the opportunity to confirm that other parts of the registry system, such as the database, storage, back-up and escrow functions can handle this size of dataset. These systems are more than adequate for the 2.7 million names in the .org dataset. Indeed these systems can support at least 20 million names using the proposed hardware configurations. Considering potential growth, it is worth noting that these systems are taxed by a large number of total domains registered, and not by high day-to-day or hour-to-hour volumes.  Short-term surges in registration volume should not affect these systems.  If long-term registration projections do not adequately anticipate the growth of the .org TLD, these components can be upgraded well in advance of their limits being reached.  Whois and name servers use a clustered approach, which allows the easy addition of inexpensive new hardware as the capacities of the system are reached.  Once again, storage and backup systems have been engineered to accommodate expected volumes for over twenty million active domain names, with the Whois servers capable of handling millions of queries per day and the name service infrastructure capable of handling over 100,000 queries per second.

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

Overview

The DotOrg Foundation intends to outsource most billing, customer and technical support for the .org registry to Registry Advantage.  Problems and questions from registrars will be initially handled by the Registry Advantage Customer Support Center.  The Center staff will attempt to identify and diagnose the cause of any problems and rectify them.  Registry Advantage anticipates that the customer support team will be able to address any billing and customer support issues, as well as many technical issues.  Some technical problems may be beyond the capabilities of the Center’s staff to resolve directly. In these cases, they will promptly escalate the issue to specialized technical staff (for example, network engineers or database administrators) for resolution.  Any problems reported by the DotOrg Foundation or any .org registrars will be tracked through a ticketing system so that Registry Advantage can monitor issue resolution and timing. 

Certain problems or questions from registrars related to the registry-registrar agreement or DotOrg Foundation initiatives outside the Registry Function for and with registrars may be more appropriately addressed directly by the Foundation.  If such questions come in through the Service Center, they will be referred to the Foundation.  Similarly, calls related to the validation process or the Dot Org Directory will be routed appropriately. 

Ticketing System

In order to track customer service issues, Registry Advantage would operate a trouble ticket system.  A ticket would be created at the time of each new contact between registrars and the registry.  This system would provide customer service representatives with the ability to categorize, assign priorities to, and update trouble tickets to ensure that issues are routed to the appropriate personnel. 

Major capabilities of the ticketing system include:

• Automatic assignment of tickets to specific personnel based on problem type;
• Notifications generated when tickets are opened, modified or closed;
• Notifications to registry personnel generated when open tickets approach their expected service resolution times;
• Tracking of outages for Service Level Agreement purposes; and
• Generation of reports on the status of all open tickets as well as trouble ticket histories.

Notifications

Registry Advantage will seek to proactively notify customers of problems as they occur.  Contact would generally be made through e-mail; however, if the scope of a technical problem affects the registry’s capacity to send e-mail messages, an attempt would be made to contact registrars by telephone or facsimile.  Registrars would be notified well in advance of planned maintenance events and invited to provide feedback regarding the registry’s technical operations on a regular basis.

Registry Advantage will provide urgent notice of any catastrophic outage or disaster recovery involving critical operations to the registry, and will follow up with regular reports by a senior registry systems engineer as long as needed.  Systems outage involving non-critical operations to the registry shall receive similar regular, but less frequent, reports as long as needed.

Hours of Support

Technical support services will be provided on a 24/7 basis, 365 days per year in order to equally accommodate registrars around the world.  Although English will be the primary support language, Registry Advantage has staff that can communicate in several common languages, and will continue to seek diverse language capabilities among the additional staff hired to manage .org operations. 

Customer and billing support services for non-critical issues will be provided Monday through Friday during regular business hours (Monday through Friday, 9am to 5pm EST, excluding holidays).

Access to Sensitive Data

Access by Registry Advantage or the DotOrg Foundation to sensitive registrar critical data will be limited.  Read only status will be available to help desk entry level employees or outsource employees for such data in order to prevent inadvertent changes to registrar records. Support staff will be prohibited from providing information about other registrar’s operations.  For further details, please see the security description in C17.9.

Customer Service Issue Resolution Process

Registry Advantage has developed a complete issue resolution process for registrars - from ticket opening to ticket closure.  The Registry Advantage Customer Support Center has established the following process to respond to inquiries most effectively and efficiently.

When the registrar contacts the Center to report a problem or make a request, a service request is opened and a ticket number assigned.  The Center has an internal ticketing process to track progress toward resolution. 

The first contact with the Customer Support Center is with a member of the Registry Support Team.  To help expedite the customer ticket, the Team asks for account and contact information along with a description of the problem or service request.  If required, additional technical information may be requested and security procedures used to verify the identity of the caller. 

Average Call Back Times

When Registry Advantage receives an email or fax service request, the Center contacts the customer, based on the initial incident priority.

Priority             Call Back Time

1                      20 minutes

2                      1-business hours

3                      6-business hours

4                      24-business hours

Average Resolution Time

The goal is to provide each customer with a rapid response and resolution to the inquiry, however the following guidelines may be useful:

Priority             Average Resolution Time

1                      2-business hours

2                      1-business day

3                      2-business days

4                      3-business days

Ticket Prioritization – All incoming tickets will receive prioritization based on the reported problem.  Registry Advantage reserves the right to adjust the severity of an issue.

Priority 1 – A priority 1 ticket is the highest priority within the Support Center system.  The Center makes every reasonable effort to ensure that the customer is operational as soon as possible.  Registry Advantage is in continuous contact with the customer until the problem is resolved.  Typical Priority 1 issues include:

• System inoperative
• Domain Name resolution impacted
• Registration activities impaired
• Letter of credit limit has been reached
• Registrar access to registry service is limited
• Serious installation or upgrade issues (installation and upgrade issues may be considered Priority 1 issues if they seriously impact progress towards completion and/or production dates)

Priority 2 – Typically a Priority 2 ticket is for a problem that prevents the registrar from completing non-registration business but does not cause the registry or a registrar’s use of the registry to become completely inoperable.  The Center makes every reasonable effort to resolve the reported problem as soon as possible.  Typical Priority 2 issues include:

• Reports will not run
• Performance problems
• Functionality issues

Priority 3 – A priority 3 ticket is for a problem that causes a feature or system failure that can be avoided by the customer applying alternative methods.  Typical Priority 3 issues include the following:

• Receiving error messages in the reports
• Receiving console error messages
• Exporting/Importing data files failing
• Upgrade or installation planning

Priority 4 – A priority 4 ticket is for a minor problem having only a minimal impact on the customer’s business.  Typical Priority 4 issues include:

• General registration questions
• Changes to contact information
• General billing inquiries

Support for Registrants and Internet Users

Primary support for registrants will be provided by registrars.  Inquiries made by registrants directly to the registry, either by phone or email, will be referred to the appropriate registrar or possibly ICANN if the complaint is against the registrar.  Similarly, neither phone nor e-mail support will be provided for Internet users.

The DotOrg Foundation will, however, provide a publicly available website with useful information for both registrants and Internet users.  Information on the public website will include:

Registration policies

A listing of ICANN-accredited registrars who offer .org registrations

A web-based interface to the Whois service

Frequently asked questions about the .org domain name

The DotOrg Foundation website will be designed to provide maximum utility to a broad spectrum of registrars, registrants and Internet users, including those with visual handicaps.  In order to make the site broadly accessible, simple design concepts will be employed and text will be emphasized over graphics, flash, and other visual elements.

C17.12. Compliance with specifications. Describe the extent of proposed compliance with technical specifications, including compliance with at least the following RFCs: 954, 1034, 1035, 1101, 2181, 2182. Registry Advantage services comply with all relevant RFCs.  In addition, Registry Advantage is an active participant in the standards-setting process.

All Registry Advantage systems will comply with the relevant specifications from IETF RFCs.  The compliance of various services is summarized in the table below:

It is important to note that Internet standards are continuously evolving, and Registry Advantage intends to be an active participant within the IETF and to track the changes of relevant working groups.  For example, the IETF’s provreg working group is currently in the process of defining a generic registry/registrar protocol, which would be of considerable interest to both Registry Advantage and the registrar community.  Registry Advantage intends to participate in this process and to implement the standard protocols that may emerge from this group’s work.  Similarly, the DotOrg Foundation and Registry Advantage expect to be active participants in current and existing IETF working groups, such as provreg, dnsop and dnsext.  Registry Advantage currently actively participates in IETF standards-setting activities, both through mailing lists such as NAMEDROPPERS, as well as through regular attendance at IETF meetings.  As new standards that affect .org registry services are developed, Registry Advantage and the DotOrg Foundation will work closely with ICANN to ensure compliance with all relevant standards.

<< Previous Question