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

Amendment No. 4 to the .COM Registry Agreement

ICANN | Amendment No. 4 to the .COM Registry Agreement
  ICANN Logo

Amendment No. 4 to the .COM Registry Agreement
(22 September 2010)


ICANN and VeriSign, Inc. agree that the following modifications are made to the 1 March 2006 .COM Registry Agreement:

I. The Parties agree to the following modifications to Section 3.1(c)(i):

[old text]

3.1(c)(i) Data Escrow. Registry Operator shall establish at its expense a data escrow or mirror site policy for the Registry Data compiled by Registry Operator. Registry Data, as used in this Agreement, shall mean the following: (1) data for domains sponsored by all registrars, consisting of domain name, server name for each nameserver, registrar id, updated date, creation date, expiration date, status information, and DNSSEC related key material (if Registry Operator implements DNSSEC); (2) data for nameservers sponsored by all registrars consisting of server name, each IP address, registrar id, updated date, creation date, expiration date, and status information; (3) data for registrars sponsoring registered domains and nameservers, consisting of registrar id, registrar address, registrar telephone number, registrar e-mail address, whois server, referral URL, updated date and the name, telephone number, and e-mail address of all the registrar's administrative, billing, and technical contacts; (4) domain name registrant data collected by the Registry Operator from registrars as part of or following registration of a domain name; and (5) the DNSSEC-related material necessary to sign the .com zone (e.g., public and private portions of .com zone key-signing keys and zone-signing keys)(if Registry Operator implements DNSSEC). The escrow agent or mirror-site manager, and the obligations thereof, shall be mutually agreed upon by ICANN and Registry Operator on commercially reasonable standards that are technically and practically sufficient to allow a successor registry operator to assume management of the TLD. To this end, Registry Operator shall periodically deposit into escrow all Registry Data on a schedule (not more frequently than weekly for a complete set of Registry Data, and daily for incremental updates) and in an electronic format mutually approved from time to time by Registry Operator and ICANN, such approval not to be unreasonably withheld by either party. In addition, Registry Operator will deposit into escrow that data collected from registrars as part of offering Registry Services introduced after the Effective Date of this Agreement. The schedule, content, format, and procedure for escrow deposits shall be as reasonably established by ICANN from time to time, and as set forth in Appendix 1 hereto. Changes to the schedule, content, format, and procedure may be made only with the mutual written consent of ICANN and Registry Operator (which neither party shall unreasonably withhold) or through the establishment of a Consensus Policy as outlined in Section 3.1(b) above. The escrow shall be held under an agreement, substantially in the form of Appendix 2, as the same may be revised from time to time, among ICANN, Registry Operator, and the escrow agent.

[new text]

3.1(c)(i) Data Escrow. Registry Operator shall establish at its expense a data escrow or mirror site policy for the Registry Data compiled by Registry Operator. Registry Data, as used in this Agreement, shall mean the following: (1) data for domains sponsored by all registrars, consisting of domain name, server name for each nameserver, registrar id, updated date, creation date, expiration date, status information, and DNSSEC  delegation signer (“DS”) data (if Registry Operator implements DNSSEC); (2) data for nameservers sponsored by all registrars consisting of server name, each IP address, registrar id, updated date, creation date, expiration date, and status information; (3) data for registrars sponsoring registered domains and nameservers, consisting of registrar id, registrar address, registrar telephone number, registrar e-mail address, whois server, referral URL, updated date and the name, telephone number, and e-mail address of all the registrar's administrative, billing, and technical contacts; and, (4) domain name registrant data collected by the Registry Operator from registrars as part of or following registration of a domain name. The escrow agent or mirror-site manager, and the obligations thereof, shall be mutually agreed upon by ICANN and Registry Operator on commercially reasonable standards that are technically and practically sufficient to allow a successor registry operator to assume management of the TLD. To this end, Registry Operator shall periodically deposit into escrow all Registry Data on a schedule (not more frequently than weekly for a complete set of Registry Data, and daily for incremental updates) and in an electronic format mutually approved from time to time by Registry Operator and ICANN, such approval not to be unreasonably withheld by either party. In addition, Registry Operator will deposit into escrow that data collected from registrars as part of offering Registry Services introduced after the Effective Date of this Agreement. The schedule, content, format, and procedure for escrow deposits shall be as reasonably established by ICANN from time to time, and as set forth in Appendix 1 hereto. Changes to the schedule, content, format, and procedure may be made only with the mutual written consent of ICANN and Registry Operator (which neither party shall unreasonably withhold) or through the establishment of a Consensus Policy as outlined in Section 3.1(b) above. The escrow shall be held under an agreement, substantially in the form of Appendix 2, as the same may be revised from time to time, among ICANN, Registry Operator, and the escrow agent.

II.      The Parties agree that Appendix 1 to the Agreement is hereby deleted in its entirety and replaced with a new Appendix 1, in the form attached hereto.

The Parties have duly executed this Amendment as of the first date written below.


THE INTERNET CORPORATION FOR ASSIGNED NAMES
AND NUMBERS

VERISIGN, INC.

By:____________________________

By:_____________________________

Name: Kurt J. Pritz

Name: Raynor Dahlquist

Title: Senior Vice President, Services

Title: Senior Vice President & General Manager

Date:

Date:

 

.COM Agreement Appendix 1
Data Escrow Specification
(22 September 2010)


Data Escrow Specification

This Appendix 1 to the .com Registry Agreement consists of four of the five exhibits to the Data Escrow Agreement that constitutes Appendix 2 to the TLD Registry Agreement:

Exhibit A-Schedule for Escrow Deposits

Exhibit B-Escrow Deposit Format Specification

Exhibit C-Escrow Transfer Process

Exhibit D-Escrow Verification Procedures

The fifth exhibit (Exhibit E), which sets forth Escrow Agent's fees, is subject to negotiation between Registry Operator and Escrow Agent.

EXHIBIT A
Schedule for Escrow Deposits

Weekly and daily deposits will include records/transactions generated just before 00:00:00 (EST/EDT) of the next day they relate, e.g., report related to Sunday will include all transactions generated just before 00:00:00 of the following Monday.  Date fields will be date-time data expressed in Eastern Standard Time / Eastern Daylight Time using the Gregorian calendar, e.g. “2010-03-29T18.04.32” until a future time, to be mutually agreed by the Parties, when the date fields will include a time zone indicator specifically corresponding to the Eastern Standard Time / Eastern Daylight Time, as appropriate, e.g. “2010-03-29T18.04.32-04:00”. Data fields in the specified reports will be colon delimited until a future time, to be mutually agreed by the parties, when the delimiter will be changed to a tilde "~" or other agreed delimiter.  Further, the Registrar Whois Report from the Weekly Deposit Materials will be provided in XML.

 Weekly Escrow Deposits:                                           

VNDS will deposit a complete set of Data into escrow on a weekly basis by electronically and securely transmitting a snapshot of each operational Registrar's data (the "Deposit Materials"). The snapshot captures the state of each Registrar's data at the time the snapshot was created. Specific data elements contained in the Deposit Materials are identified in Table 1 of Exhibit B.

Daily Escrow Deposits:

VNDS will securely and electronically deposit a transaction log for each operational Registrar representing transactions that occurred over the previous 24-hour period (the "Additional Deposit"). The logs will be escrowed daily, being in the form of Additional Deposit each Tuesday through Sunday, and being in the form of the Weekly Deposit Materials each Monday, which shall capture that Sunday's data. The Daily Additional Deposit will act as incremental updates to the Weekly Deposit Materials and will include all Registrar activity, such as add, delete, and transfer of a domain name. Specific data elements contained in the Additional Deposit are identified in Table 2 of Exhibit B.

Electronic Delivery Service Escrow Deposit Method:

The transmitted data will be made available to Data Escrow Provider as follows:

Daily Deposits:

Daily transactional data will be made available no later than 18:00 (EDT/EST) each Tuesday through Sunday for the previous calendar day. For example, transactional data related to Monday would be available to the escrow company on Tuesday no later than 18:00 (EDT/EST). The results of transactions completed on Sunday will be made available in the Weekly Deposit Materials, thus no separate Daily Additional Deposit will be made for Sunday activity.

Weekly Deposits:

Weekly database snapshots taken at midnight on Sundays will be available not later than 18:00 (EDT/EST) each Monday.

EXHIBIT B
ESCROW DEPOSIT FORMAT SPECIFICATION

Each Weekly and Daily Deposit consists of a series of reports that are concatenated in the escrow process.

Table 1: Weekly Deposit Materials Format

Weekly Reports

1. Registrar Domain Report - com

Title: Registrar Domain Report - com
Report name: rgr_domain_com
Description: This report contains data for domains sponsored by all registrars. Status Information will use Status Values from RFC 5731, Section 2.3. Since a domain may have more than one status, each domain will have separate lines for each domain/nameserver/status combination.

Fields:

Domain Name (domainname)
Server names for all nameservers (servername)
IANA Registrar ID (registrarid)
Updated Date (updatedate)
Creation Date (createdate)
Expiration Date (expirationdate)
Status Information (statusname)
Domain ROID (roid)






2. Registrar Nameserver Report

Title: Registrar Nameserver Report
Report name: rgr_nameserver
Description: This report contains data for all nameservers sponsored by all registrars. The nameserver is listed once with all associated information. Since a nameserver may have more than one IP address, each nameserver will have separate lines for each nameserver/IP address/status combination. Status Information will use Status Values from RFC 5732, Section 2.3.

Fields:

Server Name (servername)
IP Address (ipaddress)
IANA Registrar ID (registrarid)
Updated Date (updatedate)
Creation Date (createdate)
Expiration Date (expirationdate)
Status Information (statusname)
Nameserver ROID  (nsroid)






3. Registrar Whois Report

Title: Registrar Whois Report
Report name: registrar_whois
Description: This report contains data for registrars sponsoring registered domains and nameservers and will consist of one record for each registrar.

Fields:

IANA Registrar ID (REGISTRARID)
Registrar Name (REGISTRARNAME)
Address 1 (ADDRESSLINE1)
Address 2 (ADDRESSLINE2)
Address 3 (ADDRESSLINE3)
City (CITY)
State / Province (STATEPROVINCE)
Postal Code (POSTALCODE)
Country (COUNTRYCODE)
Telephone Number (PHONENUMBER)
Fax Number (FAXNUMBER)
E-Mail Address (EMAIL)
Whois Server (WHOISSERVER)
Web URL (URL)
Updated Date (UPDATEDATE)
Administrative Contact First Name(ADMINFNAME)
Administrative Contact Last Name (ADMINLNAME)
Administrative Contact Telephone Number (ADMINPHONE)
Administrative Contact E-Mail (ADMINEMAIL)
Billing Contact First Name (BILLINGFNAME)
Billing Contact Last Name (BILLINGLNAME)
Billing Contact Telephone Number (BILLINGPHONE)
Billing Contact E-Mail (BILLINGEMAIL)
Technical Contact First Name (TECHFNAME)
Technical Contact Last Name (TECHLNAME)
Technical Contact Telephone Number (TECHPHONE)
Technical Contact E-Mail (TECHEMAIL)

























4. Domain Name Registrant Data

If VNDS requires registrars to provide it with registrant domain name registration data, VNDS shall escrow such registrant domain name registration data that is collected from registrars.

5. DNSSEC-Related Data

At such time that VNDS implements DNSSEC and collects DS records, VNDS shall escrow such DS records.

Title: DS Report
Report name: ds_domain_report_com
Description: This report contains delegation signer (DS) records associated with domains sponsored by all registrars. Each DS record is listed once.

Fields:

Domain Name (domainname)
Domain ROID (roid)
Key Tag (keytag)
Algorithm (algorithm)
Digest Type (digesttype)
Digest  (digest)




DS records will be escrowed in DS RR Presentation Format as defined in section 5.3 of RFC 4034.

6. Registry Services Data

VNDS shall escrow data collected from registrars as part of offering Registry Services introduced after the Effective Date of its Registry Agreement with ICANN, if any.

Table 2: Daily Additional Deposit Format

Registrar Daily Additional Deposits

1. Registrar Transaction Report

Title: Registrar Transaction Report
Report name: rgr_transaction
Description: This report contains transactions associated with a specific registrar. Domain operations produce one row for each associated nameserver. Nameserver operations produce one row for each associated ipaddress. If multiple DS records are associated with a transacton, those records will be comma separated and included on a single line with that transaction.  A transactionid is included to allow unique identification of transactions. Operations of type “MOD” (e.g., MOD_DOMAIN, MOD_NAMESERVER, itc.) will include all the associated objects even if they were not affected by the transaction, i.e., a MOD_DOMAIN operation will include a row for each nameserver even for those that were not modified.  The content of columns 3 and 4 is dependent on the operation in the following ways:
operation Π(ADD_DOMAIN, MOD_DOMAIN, DEL_DOMAIN) => [domainname][servername]
operation Π(ADD_NAMESERVER, MOD_ NAMESERVER, DEL_ NAMESERVER) => [ipaddress][servername]
operation Π(TRANSFER_DOMAIN) => [domainname][null]
operation Oe (ADD_DS, MOD_ DS, DEL_ DS) => [domainname][dsdata]
Only the seven (7) operation types above are included in the report.
The dsdata column will have the following fields in DS RR Presentation Format as defined in section 5.3 of RFC 4033 with pipe delimiter for - <KeyTag>|<Algorithm>|<DigestType>|<Digest>







Fields:
transactionid
operationname
domainname | ipaddress
servername | null
transactiondate
roid
dsdata | null






EXHIBIT C
Escrow Transfer Process
Effective:  To Be Mutually Agreed Between VNDS and Data Escrow Provider

Deposit Transfer Process. Registry Operator shall prepare and transfer the Deposit file by the following steps, in sequence:

1. The Reports making up the Deposit will first be created according to the format specification. (See Exhibit B above, "Escrow Deposit Format Specification").

2. The Reports making up the Deposit will be concatenated. The resulting file shall be named according to the following format: "com-SEQN-YYYYMMDD", where “SEQN” is a four digit decimal number that is incremented as each report is prepared and "YYYY" represents the year, “MM” the month, and “DD” the day of the date to which the file relates.

3. Next, the Deposit files will be processed by a program (provided by ICANN) that will verify that it complies with the format specification and contains reports of the same date/time (for a Full Deposit), count the number of objects of the various types in the Deposit, and append to the file a report of the program's results.

4. Registry Operator may optionally split the resulting file using the Unix SPLIT command (or equivalent) to produce files no less than 1 GB each (except the final file). If Deposit files are split, a .MD5 file (produced with MD5SUM or equivalent) must be included with the split files to isolate errors in case of transfer fault.

5. The Deposit file(s) will then be encrypted using Escrow Agent's public key for GPG or PGP and signed using Registry Operator's private key for GPG or PGP, both version 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note that GPG or PGP compresses the Deposit file(s) in addition to encrypting it (them).)

The formatted, encrypted and signed Deposit file(s) will be sent, by anonymous file transfer, to Escrow Agent's SFTP server within the specified time window.

Significant changes to the escrow transfer process require extensive integration between the parties.  To ensure the registry data is always protected via the escrow process, Registry Operator will continue to run the legacy escrow transfer process and the new escrow transfer process in parallel until such time as all parties agree to retire the legacy escrow transfer process.  The legacy escrow process will escrow all data listed in Exhibit B.

EXHIBIT D
Escrow Verification Procedures
Effective:  To Be Mutually Agreed Between VNDS and Data Escrow Provider

Verification Procedures. Escrow Agent will verify the format and completeness of each Deposit by the following steps:

1. At the conclusion of the deposit window, all Deposit files will be moved to a not-publicly-accessible directory and the existence and size of each will be noted.

2. Each Deposit file will be decrypted using Escrow Agent's private key for GPG or PGP and authenticated using Registry Operator's public key for GPG or PGP. (In this step, GPG or PGP will also automatically decompress the escrow file).

3. If there are multiple files, they will be concatenated in sequence.

4. Escrow Agent will run a program (to be supplied by ICANN) on the Deposit files (without report) that will split it in to its constituent reports (including the format report prepared by the Registry Operator and appended to the Deposit) check its format, count the number of objects of each type, and verify that the data set is internally consistent. This program will compare its results with the results of the Registry-generated format report, and will generate a Deposit format and completeness report. The program will encrypt the report using ICANN's public key for GPG or PGP and signed using Escrow Agent's private key for GPG or PGP, both versions 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note that GPG or PGP compresses the Deposit file(s) in addition to encrypting it (them). Escrow Agent will send the encrypted and signed report to ICANN by email.

5. The decrypted Deposit files will be destroyed to reduce likelihood of data loss to intruders in case of partial security failure.

Distribution of Public Keys. Each of Registry Operator and Escrow Agent will distribute its public key to the other party (Registry Operator or Escrow Agent, as the case may be) via email to an email address to be specified. Each party will confirm receipt of the other party's public key with a reply email, and the distributing party will subsequently reconfirm the authenticity of the key transmitted. In this way, public key transmission is authenticated to a user able to send and receive mail via a mail server operated by the distributing party. Escrow Agent, Sponsor and ICANN shall exchange keys by the same procedure.

 

Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.

© 2010  The Internet Corporation for Assigned Names and Numbers. All rights reserved.