Generic Top-Level Domain (gTLD) Registry Agreements

gTLD Registry Agreements establish the rights, duties, liabilities, and obligations ICANN requires of registry operators to run gTLDs.

本内容仅提供以下语言版本

  • English

.COM Registry Agreement | Functional and Performance Specifications

.COM Registry Agreement | Functional and Performance Specifications

  ICANN Logo

.COM Agreement Appendix 7
Functional and Performance Specifications


(1 March 2006)


These functional specifications for the Registry TLD consist of the following parts:

1. Verisign Registry Operator Registrar Protocol;

2. Supported initial and renewal registration periods;

3. Grace period policy;

4. Nameserver functional specifications;

5. Patch, update, and upgrade policy; and

6. Migration to Extensible Provisioning Protocol Plan.

7. Performance Specifications

1. Registry Operator Registrar Protocol

1.1 Extensible Provisioning Protocol

Registry Operator intends to implement the Extensible Provisioning Protocol (“EPP”) in conformance with the Proposed Standard and Informational RFCs 3730, 3731, 3732, 3733, 3734, 3735, and 3915 published by the Internet Engineering Task Force (“IETF”) and/or any successor standards, versions, modifications or additions thereto as Registry Operator deems reasonably necessary. Subject to the Migration to Extensible Provisioning Protocol Plan described in Section 6 below, Registry Operator will support EPP in conformance with the aforementioned standards. Implementation of EPP is subject to Registry Operator reasonably determining that (i) the standard can be implemented in a way that minimizes disruption to customers; and (ii) the standard provides a solution for which the potential advantages are reasonably justifiable when weighed against the costs that Registry Operator and its registrar customers would incur in implementing the new standard.

1.2 Registry Registrar Protocol

Subject to the Migration to Extensible Provisioning Protocol Plan described in Section 6 below, Registry Operator will support Registry Registrar Protocol (“RRP”) Version 2.1.2 in accordance with the patch, update, and upgrade policy below, or any successor standards, versions, upgrades, modifications or additions thereto as it deems reasonably necessary. Registry Operator will provide the current version of the protocol for download on its website by registrars.

2. Supported initial and renewal registration periods

a. Initial registrations of Registered Names (where available according to functional specifications and other requirements) may be made in the registry for terms of up to ten years.

b. Renewal registrations of Registered Names (where available according to functional specifications and other requirements) may be made in the registry for terms not to exceed a total of ten years.

c. Upon change of sponsorship of the registration of a Registered Name from one registrar to another, according to Part A of the ICANN Policy on Transfer of Registrations between Registrars, the term of registration of the Registered Name shall be extended by one year, provided that the maximum term of the registration as of the effective date of sponsorship change shall not exceed ten years.

d. The change of sponsorship of registration of Registered Names from one registrar to another, according to Part B of the ICANN Policy on Transfer of Registrations between Registrars shall not result in the extension of the term of the registrations and Registry Operator may assist in such change of sponsorship.

3. Grace period policy

This section describes Registry Operator’s practices for operational "Grace" and "Pending" periods, including relationships among sequential operations that occur within given time frames. A Grace Period refers to a specified number of calendar days following a Registry operation in which a domain action may be reversed and a credit may be issued to a registrar. Relevant registry operations in this context are:

  • Registration of a new domain,
  • Extension of an existing domain,
  • Auto-Renew of an existing domain;
  • Transfer of an existing domain; and
  • Deletion of an existing domain.

Extension of a registration period is accomplished using the RRP or EPP RENEW command or by auto-renewal; registration is accomplished using the RRP ADD command or the EPP CREATE command; deletion/removal is accomplished using the RRP DEL command or the EPP DELETE command; transfer is accomplished using the RRP or EPP TRANSFER command or, where ICANN approves a bulk transfer under Part B of the ICANN Policy on Transfer of Registrations between Registrars, using the procedures specified in that Part. Restore is accomplished using the RRP RESTORE command or EPP UPDATE command.

There are five grace periods provided by Registry Operator's Shared Registration System: Add Grace Period, Renew/Extend Grace Period, Auto-Renew Grace Period,Transfer Grace Period, and Redemption Grace Period.

A Pending Period refers to a specified number of calendar days following a Registry operation in which final Registry action is deferred before the operation may be completed. Relevant Registry operations in this context are:

  • Transfer of an existing domain,
  • Deletion of an existing domain, and
  • Restore of a domain name in Redemption Grace Period.

3.1 Grace Periods

3.1.1 Add Grace Period

The Add Grace Period is a specified number of calendar days following the initial registration of a domain. The current value of the Add Grace Period for all registrars is five calendar days. If a Delete, Extend (RRP or EPP Renew command), or Transfer operation occurs within the five calendar days, the following rules apply:

Delete. If a domain is deleted within the Add Grace Period, the sponsoring Registrar at the time of the deletion is credited for the amount of the registration; provided, however, that Registry Operator shall have the right to charge Registrars a fee as may be set forth in its Registry-Registrar Agreement for disproportionate deletes during the Add Grace Period. The domain is deleted from the Registry database and is immediately available for registration by any Registrar. See Section 3.2 for a description of overlapping grace period exceptions.

Extend (RRP or EPP Renew command). If a domain is extended within the Add Grace Period, there is no credit for the add. The expiration date of the domain registration is extended by the number of years, up to a total of ten years, as specified by the registrar's requested Extend operation.

Transfer (other than ICANN-approved bulk transfer). Transfers under Part A of the ICANN Policy on Transfer of Registrations between Registrars may not occur during the Add Grace Period or at any other time within the first 60 days after the initial registration. Enforcement is the responsibility of the Registrar sponsoring the domain name registration and is enforced by the SRS.

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Add Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the initial add.

3.1.2 Renew/Extend Grace Period

The Renew/Extend Grace Period is a specified number of calendar days following the renewal/extension of a domain name registration period through an RRP Command Renew. The current value of the Renew/Extend Grace Period is five calendar days. If a Delete, Extend, or Transfer occurs within that five calendar days, the following rules apply:

Delete. If a domain is deleted within the Renew/Extend Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the renew/extend fee. The domain immediately goes into the Redemption Grace Period. See Section 3.2 for a description of overlapping grace period exceptions.

Extend (RRP Command "Renew"). A domain can be extended within the Renew/Extend Grace Period for up to a total of ten years. The account of the sponsoring Registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.

Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Renew/Extend Grace Period, there is no credit. The expiration date of the domain registration is extended by one year and the years added as a result of the Extend remain on the domain name up to a total of 10 years.

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Renew/Extend Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the Renew/Extend operation.

3.1.3 Auto-Renew Grace Period

The Auto-Renew Grace Period is a specified number of calendar days following an auto-renewal. An auto-renewal occurs if a domain name registration is not renewed by the expiration date; in this circumstance the registration will be automatically renewed by the system the first day after the expiration date. The current value of the Auto-Renew Grace Period is 45 calendar days. If a Delete, Extend, or Transfer occurs within the Auto-Renew Grace Period, the following rules apply:

Delete. If a domain is deleted within the Auto-Renew Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the Auto-Renew fee. The domain immediately goes into the Redemption Grace Period. See Section 3.2 for a description of overlapping grace period exceptions.

Extend. A domain can be extended within the Auto-Renew Grace Period for up to a total of ten years. The account of the sponsoring Registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.

Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Auto-Renew Grace Period, the losing Registrar is credited with the Auto-Renew charge and the year added by the Auto-Renew operation is cancelled. The expiration date of the domain is extended by one year up to a total maximum of ten and the gaining Registrar is charged for that additional year, even in cases where a full year is not added because of the 10-year registration term maximum limitation.

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Auto-Renew Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the Auto-Renew.

3.1.4 Transfer Grace Period

The Transfer Grace Period is a specified number of calendar days following the transfer of a domain according to Part A of the ICANN Policy on Transfer of Registrations between Registrars. The current value of the Transfer Grace Period is five calendar days. If a Delete, Extend, or Transfer occurs within that five calendar days, the following rules apply:

Delete. If a domain is deleted within the Transfer Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the transfer fee. The domain immediately goes into the Redemption Grace Period. See Section 3.2 for a description of overlapping grace period exceptions.

Extend. If a domain registration is extended within the Transfer Grace Period, there is no credit for the transfer. The Registrar's account will be charged for the number of years the registration is extended. The expiration date of the domain registration is extended by the number of years, up to a maximum of ten years, as specified by the registrar's requested Extend operation.

Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Transfer Grace Period, there is no credit. The expiration date of the domain registration is extended by one year up to a maximum term of ten years. The ICANN Policy on Transfer of Registrations between Registrars does not allow transfers within the first 60 days after another transfer has occurred; it is registrars’ responsibility to enforce this restriction.

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Transfer Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the Transfer operation that occurred prior to the Bulk Transfer.

3.1.5 Bulk Transfer Grace Period

There is no grace period associated with Bulk Transfer operations. Upon completion of the Bulk Transfer, any associated fee is not refundable.

3.1.6 Redemption Grace Period

A domain name is placed in REDEMPTIONPERIOD status when a registrar requests the deletion of a domain that is not within the Add Grace Period. A name that is in REDEMPTIONPERIOD status will not be included in the zone file. A registrar can not modify or purge a domain in REDEMPTIONPERIOD status. The only action a registrar can take on a domain in REDEMPTIONPERIOD is to request that it be restored. Any other registrar requests to modify or otherwise update the domain will be rejected. Unless restored, the domain will be held in REDEMPTIONPERIOD status for a specified number of calendar days. The current length of this Redemption Period is 30 calendar days.

3.2 Overlapping Grace Periods

If an operation is performed that falls into more that one grace period, the actions appropriate for each grace period apply (with some exceptions as noted below).

  • If a domain is deleted within the Add Grace Period and the Extend Grace Period, then the Registrar is credited the registration and extend amounts, taking into account the number of years for which the registration and extend were done.
  • If a domain is auto-renewed, then extended, and then deleted within the Extend Grace Period, the registrar will be credited for any Auto-Renew fee charged and the number of years for the extension.

3.2.1 Overlap Exception

  • If a domain registration is extended within the Transfer Grace Period, then the current Registrar's account is charged for the number of years the registration is extended.

Note: If several billable operations, including a transfer, are performed on a domain and the domain is deleted within the grace periods of each of those operations, only those operations that were performed after the latest transfer, including the latest transfer, are credited to the current Registrar.

3.3 Pending Periods

3.3.1 Transfer Pending Period

The Transfer Pending Period is a specified number of calendar days following a request from a registrar (registrar A) to transfer a domain in which the current registrar of the domain (registrar B) may explicitly approve or reject the transfer request. The current value of the Transfer Pending Period is five calendar days for all registrars. The transfer will be finalized upon receipt of explicit approval or rejection from the current registrar (registrar B). If the current registrar (registrar B) does not explicitly approve or reject the request initiated by registrar A, the registry will approve the request automatically after the end of the Transfer Pending Period. During the Transfer Pending Period:

a. RRP or EPP TRANSFER request or RRP or EPP RENEW request is denied.
b. SYNC is not allowed.
c. RRP DEL or EPP DELETE request is denied.
d. Bulk Transfer operations are allowed.


e. RRP MOD or EPP UPDATE request is denied.

After a transfer of a domain, the RRP or EPP TRANSFER request may be denied for 60 days.

3.3.2 Pending Delete Period

A domain name is placed in PENDING DELETE status if it has not been restored during the Redemption Grace Period. A name that is in PENDING DELETE status will not be included in the zone file. All registrar requests to modify or otherwise update a domain in PENDING DELETE status will be rejected. A domain name is purged from the registry database a specified number of calendar days after it is placed in PENDING DELETE status. The current length of this Pending Delete Period is five calendar days.

4. Nameserver functional specifications

Nameserver operations for the Registry TLD shall comply with RFCs 1034, 1035, and 2182.

5. Patch, update, and upgrade policy

Registry Operator may issue periodic patches, updates or upgrades to the Software, RRP/EPP or APIs ("Licensed Product") licensed under the Registry-Registrar Agreement (the "Agreement") that will enhance functionality or otherwise improve the Shared Registration System under the Agreement. For the purposes of this Part 5 of Appendix 7, the following terms have the associated meanings set forth herein.   1. A "Patch" means minor modifications to the Licensed Product made by Registry Operator during the performance of error correction services. A Patch does not constitute a Version.   2. An "Update" means a new release of the Licensed Product which may contain error corrections, minor enhancements, and, in certain circumstances, major enhancements, and which is indicated by a change in the digit to right of the decimal point in the version number of the Licensed Product.   3. An "Upgrade" means a new release of the Licensed Product which involves the addition of substantial or substantially enhanced functionality and which is indicated by a change in the digit to the left of the decimal point in the version of the Licensed Product.   4. A "Version" means the Licensed Product identified by any single version number.   Each Update and Upgrade causes a change in version. * Patches do not require corresponding changes to client applications developed, implemented, and maintained by each registrar. * Updates may require changes to client applications by each registrar in order to take advantage of the new features and/or capabilities and continue to have access to the Shared Registration System. * Upgrades require changes to client applications by each registrar in order to take advantage of the new features and/or capabilities and continue to have access to the Shared Registration System.   Registry Operator, in its sole discretion, will deploy Patches during scheduled and announced Shared Registration System maintenance periods.   For Updates and Upgrades, Registry Operator will give each registrar notice prior to deploying the Updates and Upgrades into the production environment. The notice shall be at least ninety (90) days. Such notice will include an initial notice before deploying the Update that requires changes to client applications or the Upgrade into the Operational Test and Evaluation ("OT&E") environment to which all registrars have access. Registry Operator will maintain the Update or Upgrade in the OT&E environment for at least thirty (30) days, to allow each registrar the opportunity to modify its client applications and complete testing, before implementing the new code in the production environment.   This notice period shall not apply in the event Registry Operator's system is subject to the imminent threat of a failure or a material security threat, the discovery of a major security vulnerability, or a Denial of Service (DoS) attack where the Registry Operator's systems are rendered inaccessible by being subject to: excessive levels of data traffic unauthorized traffic data traffic not conforming to the protocols used by the Registry

6. Migration to Extensible Provisioning Protocol Plan

Support of RRP and EPP: Subject to this Section 6, Registry Operator will support the RRP as a "thin" registry. Registry Operator will continue to support RRP until all impacted registrars have migrated to EPP, but in no event later than 18 months after the deployment date of EPP unless otherwise agreed upon in writing by Registry Operator.

Dual RRP and EPP Operations:

  1. Registry Operator will provide an extended period for impacted registrars to transition from RRP to EPP on a timeframe acceptable to registrars, but in no event later than18 months after the deployment date of EPP unless otherwise agreed upon in writing by Registry Operator.
  2. Registry Operator’s RRP implementation will be completely replaced by EPP on a date determined jointly by Registry Operator, ICANN, and the registrar community, which date shall not be later than 18 months after the deployment date of EPP unless otherwise agreed upon in writing by Registry Operator.
  3. Registry Operator’s EPP implementation will not support the use of authinfo codes to verify transfers until all registrars have migrated to EPP.

7. Performance Specifications

For purposes of this Section 7, “DNS Name Server” means the service complying with RFC 1034 made available on TCP/UDP port 53 on Registry Operator’s selected servers; “Round-trip” means the amount of time that it takes for a remote nameserver to respond to queries; “Core Internet Service Failure” means extraordinary and identifiable events beyond the control of Registry Operator affecting the Internet services to be measured pursuant to this section, including but not limited, to congestion collapse, partitioning, power grid failures, and routing failures; DNS Name Server unavailability shall mean less than four (4) sites on the Registry Operator’s constellation are returning answers to queries with less than 2% packet loss averaged over a Monthly Timeframe; and "Monthly Timeframe" means each single calendar month beginning and ending at 0000 Coordinated Universal Time (UTC). The requirements in this Section 7 set forth below are not matters subject to SLA Credits under the Service Level Agreement set forth on Appendix 10 or obligations upon which a breach by Registry Operator of the Registry Agreement may be asserted.

A. Cross-Network Name Server Performance Requirements. The committed performance specification for cross-network name server performance is a measured Round-trip of under 300 milliseconds and measured packet loss of under 10% over the course of a Monthly Timeframe. Cross-network name server performance measurements may be conducted by ICANN, pursuant to the terms of confidentiality agreements executed both by ICANN and its employee or consultant conducting the testing, in the following manner:

1. The measurements may be conducted by sending strings of DNS request packets from each of four measuring locations to each of the .com DNS Name Servers and observing the responses from the .com DNS Name Servers. (These strings of requests and responses are referred to as a "CNNP Test".) The measuring locations will be four root name server locations on the US East Coast, US West Coast, Asia, and Europe.

2. Each string of request packets will consist of 100 UDP packets at 10 second intervals requesting nameserver records for arbitrarily selected .com second-level domains, preselected to ensure that the names exist in the Registry TLD and are resolvable. The packet loss (i.e. the percentage of response packets not received) and the average Round-trip time for response packets received may be noted.

3. To meet the packet loss and Round-trip requirements for a particular CNNP Test, all three of the following must be true:

(a) The Round-trip and packet loss from each measurement location to at least one .com name server must not exceed the required values;

(b) The packet loss to each of the .com name servers from at least one of the measurement locations must not exceed the required value; and

(c) Any failing CNNP Test result obtained during an identified Core Internet Service Failure shall not be considered.

4. To ensure a properly diverse testing sample, ICANN will conduct the CNNP Tests at varying times (i.e. at different times of the day, as well as on different days of the week). Registry Operator may only be deemed to have persistently failed to meet the cross-network name server performance requirement only if the .com DNS Name Servers fail the CNNP Tests (see Section 7.3 above) with no less than three consecutive failed CNNP Tests.

5. In the event of persistent failure ( defined as failure of three consecutive tests) of the CNNP Tests, ICANN will give Registry Operator written notice of the failures (with backup data) and Registry Operator will have sixty days to cure the failure.

6. Sixty days prior to the commencement of testing under this provision, ICANN will provide Registry Operator with the opportunity to evaluate the testing tools, root name server locations and procedures to be used by ICANN. In the event that Registry Operator does not approve of such tools and procedures, ICANN will work directly with Registry Operator to make necessary modifications.

7. ICANN will provide written notification to Registry Operator of the results of any testing within 5 days of completion of testing, including the method used for testing, administrator used to conduct the test and the location of testing. Within 30 days of receipt of notice the testing results, Registry Operator may request that the test be re-administered in the presence of a Registry Operator employee. This second test must be administered within 30 days of Registry Operator’s request.

B. Service Availability—DNS Name Server = 100% per Monthly Timeframe.

Service Availability as it applies to the DNS Name Server refers to the ability of the DNS Name Server to resolve a DNS query from an Internet user. DNS Name Server unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. Registry Operator will log DNS Name Server unavailability when such unavailability is detected by VeriSign monitoring tools. Any DNS Name Server unavailability occurring during an identified Core Internet Service Failure shall not be considered.

Monthly Metric

Requirement

Total outage

8 hours

Unplanned outage

4 hours

Major upgrade outage

12 hours (two allowed per year)

Check domain average

3 seconds

Add domain average

5 seconds