ICANN's gTLD Registry Data Escrow Requirements
(5 March 2007)
All gTLD registries/sponsoring organizations ("registries") under contract with ICANN are required to deposit into escrow all registry data according to a format and schedule designated in the Registry/Sponsorship Agreement. Registry data escrow requirements are detailed in the Registry Data Escrow Agreement, an appendix to gTLD registry/sponsorship agreements with ICANN.
Registries are required to make Full Deposits on a weekly schedule. Full Deposits include the contents of all domain objects, host objects, contact objects, registrar objects, and when applicable, DNSSEC-related key material.
Registries are required to make Incremental Deposits on a daily schedule. Incremental Deposits contain all new data since the last Full Deposit, that is, transactions completed after the last Full Deposit was generated.
Upon receiving a deposit, the data escrow provider verifies the format and completeness of each deposit. The escrow provider moves the file to a non-public directory and notes the size and existence of the file. Files are decrypted and authenticated to verify that the files actually came from the Registry. The decrypted file is then destroyed so that the escrow agent cannot re-access the data.
All registry agreements (with the exception of .COM and .NET) provide that the Registry Operator should process its deposits using a program provided by ICANN to verify that the deposit 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.
The agreements also provide that as part of the escrow verification procedure, the escrow provider should run a program (to be supplied by ICANN) on each deposit file that will split it into its constituent reports, check its format, count the number of objects of each type, and verify that the data set is internally consistent. This program then compares its results with the results of the Registry-generated format report, and generates a deposit format and completeness report.
To date, this program has not been developed. This remains an open item for further development or discussion. Registries and their escrow providers have developed their own programs for performing the required tasks.
The deposit and verification process works as depicted in the Registry Sponsorship Agreements as shown theoretically below:
The purpose of data escrow is not defined in any ICANN documents or agreements. However, in the event that a registry suffers a long-term failure or is terminated, escrowed data could be used to help restore or continue operation of a registry until a successor is selected. Data escrow may be used to help ensure continuity of service in the event of a technical failure of a registry.
The original ICANN-NSI Registry Agreement contained the following provisions on data escrow:
NSI shall 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 NSI and ICANN, such approval not to be unreasonably withheld by either party. The escrow shall be maintained, at NSI's expense, by a reputable escrow agent mutually approved by NSI and ICANN, such approval also not to be unreasonably withheld by either party. The escrow shall be held under an agreement among ICANN, NSI, the United States Department of Commerce, and the escrow agent providing that (A) the data shall be received and held in escrow, with no use other than verification that the deposited data is complete and in proper format, until released to ICANN or to the United States Department of Commerce; (B) the data shall be released to ICANN upon termination of this Agreement by ICANN under Section 14 or upon the Expiration Date if (1) this Agreement has not sooner been terminated and (2) it has been finally determined by the ICANN Board (and no injunction obtained pursuant to Section 13 has been obtained) that NSI will not be designated as the successor registry under Section 22 of this Agreement; and (C), in the alternative, the data shall be released to the United States Department of Commerce according to the terms of the cooperative agreement between NSI and the United States Government.[1]
From 1999-2001, this provision covered data escrow by NSI (later VeriSign) for the .COM, .NET and .ORG gTLDs. In May 2001, ICANN entered into a new agreement with VeriSign for the .COM registry.[2] The agreement included expanded data escrow requirements in form of Appendix R (Data Escrow Specification) and Appendix S (Data Escrow Agreement). ICANN also entered into separate agreements with VeriSign for the .NET and .ORG gTLDs.[3]
In November 2000, ICANN selected seven new TLDs as part of a proof-of-concept round to expand the name space (.AERO, .BIZ, .COOP, .INFO, .MUSEUM, .NAME and .PRO).[4] At the ICANN meeting in Melbourne, Australia (9-13 March 2001), ICANN held a public forum on the new form of TLD agreements.[5] The new agreement forms contained language based on the data escrow provisions drafted for the 2001 .COM agreement with VeriSign.
Between 2001-2002, ICANN entered into agreements with seven new registries and sponsors, beginning with .BIZ and .INFO in May 2001.[6] Renewal agreements were completed with NeuStar and Afilias in December 2006, while the agreements for the other five proof-of-concept TLDs remain in effect.[7]
ICANN’s progress on new gTLD agreements was communicated in the Third Status Report under the Memorandum of Understanding between ICANN and the US Department of Commerce.[8] The Status Report noted that "the contracts have been designed to ensure that these TLDs are introduced in a sound manner that will maintain stable and reliable technical operation of the DNS. In particular, the contracts recite functional and performance specifications, data escrow requirements…"[9]
As part of the 2001 agreement with VeriSign, ICANN entered into a process to reassign the .ORG gTLD. After reviewing eleven applications throughout 2002, ICANN selected the bid from Public Interest Registry (PIR) to be the successor registry for .ORG. On 2 December 2002, ICANN and PIR executed an agreement for the .ORG registry.[10] This agreement remained in effect until ICANN and PIR executed a renewal agreement on 8 December 2006.[11]
Several of the ccTLD Sponsorship Agreements contain provisions on ccTLD registry data escrow. These provisions are described here for informational purposes.
.AU Sponsorship Agreement (25 October 2001), Section 4.3
The Sponsoring Organization shall ensure the safety and integrity of the registry database, including the establishment at its expense of a data escrow or mirror site policy for the registry data managed by the Sponsoring Organization. The escrow agent or mirror-site operator shall be mutually approved by the Governmental Authority and the Sponsoring Organization, and shall not be under the Sponsoring Organization's control. The escrowed or mirror-site data shall be held under an agreement (the "Escrow Agreement") among the Sponsoring Organization, the Governmental Authority, and the escrow agent or mirror-site operator providing that (1) the data will be maintained by the escrow agent or mirror-site operator according to business practices prevalent within the territory of the Governmental Authority; (2) the escrow agent or mirror-site operator will verify the data to be complete, consistent, and in proper format according to a schedule and procedures to be reasonably agreed by the parties; (3) upon termination of this Agreement, the data will be provided immediately to the successor manager for the Delegated ccTLD; and (4) in the event of such provision, the successor manager shall have all rights to use of the data necessary to operate the Delegated ccTLD and its registry.[12]
This provision also appears in the .KE (Kenya) Sponsorship Agreement (signed 20 December 2002), the .JP (Japan) Sponsorship Agreement (signed 27 February 2002), the .SD (Sudan) Sponsorship Agreement (signed 20 December 2002), and the .UZ (Uzbekistan) Sponsorship
Agreement (signed 27 March 2003). The .TW (Taiwan) Sponsorship Agreement (signed 26 March 2003) contains nearly identical language to these agreements.[13]
ccTLD registry data escrow requirements do not appear in the .BI (Burundi) ccTLD Memorandum of Understanding (16 May 2002), .MW (Malawi) ccTLD MOU (signed 28 June 2002), .LA (Laos) ccTLD MOU (20 December 2002), .PS (Palestinian Territories) ccTLD MOU (signed 19 April 2004) or .AF (Afghanistan) ccTLD MOU (signed 8 January 2003), but the provisions do appear in the .NG (Nigeria) ccTLD MOU (signed 19 April 2004).
An example of a ccTLD that has entered into a data escrow agreement with a third party provider is .JP. Japan Registry Services Co., Ltd. (JPRS), the registry operator for the .JP ccTLD, has a data escrow agreement in place with JPNIC.[14] The purpose of the agreement is to ensure continuity "if the registry (JPRS) should re-transfer its responsibilities and functions to other organizations, the organizations can start operations without delay, in order to serve the Internet community of Japan."
In February 2001, former ICANN Chief Policy Officer Andrew McLaughlin met with ccTLD managers in an informal meeting in Zurich, Switzerland to discuss the draft contract between ccTLDs and ICANN.[15] According to the notes of the meeting recorded by CENTR, data escrow was discussed for possible inclusion into the draft ccTLD agreement. Data escrow was viewed as: 1) technical data only, such as TLD zone files, and 2) registry data, which contains all data used to provide registry services.
It is useful to note the questions raised in that meeting for broader discussion on data escrow:
Beginning in 2004, ICANN, with the assistance of the Country Code Names Supporting Organization (ccNSO), moved away from the sponsorship agreement and MOU format for ccTLD agreements toward a lightweight document called the Accountability Framework (AF).[17] The AF does not contain detailed provisions on data escrow, but does state that ccTLDs shall use best efforts to "operate and maintain, the authoritative name servers for [the ccTLD] in a stable and secure manner…[following] applicable relevant standards are standards-track or best current practice RFCs sponsored by the Internet Engineering Task Force."[18]
Version 1 (example from .COM Registry Agreement, http://www.icann.org/tlds/agreements/verisign/registry-agmt-com-01mar06.htm).
"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;
(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).
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 escrow shall be maintained, at Registry Operator's expense, by a reputable escrow agent mutually approved by Registry Operator and ICANN, such approval also not to be unreasonably withheld by either party. 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."[19]
The announcement of the proposed registry agreements for .BIZ, .INFO and .ORG posted on 28 July 2006 highlighted the "expanded and clarified" data escrow provisions.[20] These agreements were approved in December 2006 (containing Version 1 of the data escrow requirements).
Version 2
The data escrow provision in Article 3.1(c)(i) of the current .TRAVEL Sponsored TLD Registry Agreement (http://www.icann.org/tlds/agreements/travel/travel-agreement-12apr06.htm) is similar to Version 1 above but does not contain references to DNSSEC, or subsection 5. .TRAVEL is also referred to as the "Registry" rather than the "Registry Operator."
Version 3
The data escrow provision appears in Article 3.12 of the current .AERO, .COOP and .MUSEUM sponsored TLD agreements. The requirements in the three sponsored agreements are less detailed than the data escrow requirements in Version 1 or 2.
"Sponsor shall ensure Registry Operator periodically deposits into escrow all Registry Data in an electronic format. The escrow shall be maintained, at Sponsor's or Registry Operator's expense, by a reputable escrow agent mutually approved by Sponsor and ICANN, such approval also not to be unreasonably withheld by either party. The schedule, content, format, and procedure for escrow deposits shall be as established by ICANN from time to time. The initial schedule, content, format, and procedure shall be as set forth in Attachment 18. Changes to the schedule, content, format, and procedure may be made only with the mutual written consent of ICANN and Sponsor (which neither party shall withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. The escrow shall be held under an agreement, substantially in the form of Attachment 19, among ICANN, Sponsor, Registry Operator and the escrow agent. In the event that, after a good-faith search by ICANN and Registry Operator, no mutually approved escrow agent agrees to the terms of Attachment 19, ICANN and Sponsor shall, in conjunction with a mutually approved escrow agent, negotiate in good faith for a substitute escrow agreement."[21]
Version 4
The data escrow provision appears in Article 3.11 of the current .NAME and .PRO registry agreements.
"Registry Operator shall periodically deposit into escrow all Registry Data in an electronic format. The escrow shall be maintained, at Registry Operator's expense, by a reputable escrow agent mutually approved by Registry Operator and ICANN, such approval also not to be unreasonably withheld by either party. The schedule, content, format, and procedure for escrow deposits shall be as established by ICANN from time to time. The initial schedule, content, format, and procedure shall be as set forth in Appendix R. 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 withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. The escrow shall be held under an agreement, substantially in the form of Appendix S, among ICANN, Registry Operator, and the escrow agent. In the event that, after a good-faith search by ICANN and Registry Operator, no mutually approved escrow agent agrees to the terms of Appendix S, ICANN and Registry Operator shall, in conjunction with a mutually approved escrow agent, negotiate in good faith for a substitute escrow agreement."[22]
[1] ICANN-NSI Agreement (4 November 1999), Section 7, http://www.icann.org/nsi/nsi-registry-agreement-04nov99.htm#7.
[2] 2001 .COM Registry Agreement, http://www.icann.org/tlds/agreements/verisign/com-index-25may01.htm. Appendix R for .COM/.NET/.ORG is available at http://www.icann.org/tlds/agreements/verisign/registry-agmt-appr-25may01.htm.
[3] 2001 .NET Registry Agreement, http://www.icann.org/tlds/agreements/verisign/net-index.htm, 2001 .ORG Registry Agreement, http://www.icann.org/tlds/agreements/verisign/org-index.htm.
[4] ICANN Board Resolution 00.89 (16 November 2000), http://www.icann.org/minutes/prelim-report-16nov00.htm#00.89.
[5] Background page on new TLD agreements for ICANN Melbourne meeting, posted 26 February 2001, http://www.icann.org/melbourne/new-tld-agreements-topic.htm.
[6] As examples, see 2001 .BIZ Registry Agreement, http://www.icann.org/tlds/agreements/biz/index-11may01.html and 2001 .INFO Registry Agreement, http://www.icann.org/tlds/agreements/info/index-11may01.html
[7] .AERO, .COOP, .MUSEUM and .NAME are in renewal negotiations.
[8] Third Status Report Under the MOU (3 July 2001), http://www.icann.org/general/statusreport-03jul01.htm.
[9] Data escrow was not referenced again until the 13[th] Status Report to the Department of Commerce, posted 7 April 2006, http://www.icann.org/general/mou-status-report-07apr06.pdf.
[10] Information on the .ORG reassignment is available at http://www.icann.org/tlds/org/. The December 2002 .ORG Registry Agreement is available at http://www.icann.org/tlds/agreements/org/index-02dec02.html.
[11] .ORG Registry Agreement (8 December 2006), http://www.icann.org/tlds/agreements/org/.
[12] .AU Sponsorship Agreement (25 October 2001), http://www.icann.org/cctlds/au/sponsorship-agmt-25oct01.htm#4.3.
[13] .TW Sponsorship Agreement (26 March 2003), http://www.icann.org/cctlds/tw/sponsorship-agmt-26mar03.htm#4.3.
4.3 ccTLD Registry Data Escrow. The Sponsoring Entity shall ensure the safety and integrity of the registry database, including the establishment at its expense of a data escrow or a mirror site policy for the registry data managed by the Sponsoring Entity. The escrow agent or mirror-site operator shall be approved by the Sponsoring Entity and the Governmental Authority, and shall not be under the Sponsoring Entity's control. The escrowed or mirror-site data shall be held under an agreement (the "Escrow Agreement") among the Sponsoring Entity, the said escrow agent or mirror-site operator, and the DGT, providing that (1) the data will be maintained by the escrow agent or mirror-site operator according to business practices prevalent within the territory of the Governmental Authority (the DGT); (2) the escrow agent or mirror-site operator will verify the data to be complete, consistent, and in proper format according to a schedule and procedures to be reasonably agreed by the parties; (3) upon termination of this Agreement, the data will be provided immediately to the successor manager for the Delegated ccTLD; and (4) in the event of such provision, the successor manager shall have all rights to use of the data necessary to operate the Delegated ccTLD and its registry.
[14] Announcement on JPRS-JPNIC Data Escrow Agreement (29 March 2002), http://jprs.co.jp/en/topics/020329a.html.
[15] Notes on Meeting posted 4 May 2001 on CENTR website, https://www.centr.org/docs/2001/05/centr-ga10-escrow.html.
[16] Id.
[17] ICANN Announcement on Accountability Frameworks (12 February 2006), http://www.icann.org/announcements/announcement-12feb06.htm.
[18] Draft Accountability Framework, http://www.icann.org/cctlds/accountability-framework-12feb06.pdf.
[19] Version 1 appears in the following agreements: .ASIA, .BIZ, .CAT, .COM, .INFO, .JOBS, .MOBI, .ORG and .TEL (minor variations appear in .BIZ, .INFO, and .ORG, "if Registry Operator implements DNSSEC", .MOBI "following such time as Registry Operator shall implement the relevant DNSSEC standards" and .TEL "after and to the extent DNSSEC is implemented by Registry Operator, DNSSEC-related key material").
[20] Announcement of Proposed .BIZ, .INFO, .ORG Registry Agreements (posted 28 July 2006), http://www.icann.org/announcements/announcement-2-28jul06.htm. "Data Escrow Provisions. The security and functionality of the registry data escrow has been a significant focus in the new forms of registry agreements negotiated by ICANN since 2005. Accordingly, the requirements for data escrow by each of the registries, as well as the requirements for the relationship between registry operator and data escrow agent, have been expanded and clarified in the proposed new registry agreements."
[21] .COOP Sponsored TLD Agreement, Article 3.12.
[22] .NAME Registry Agreement, Article 3.11.