ICANN | Registrar Data Escrow
 
  ICANN Logo

Registrar Data Escrow

Posted: 8 November 2001

These draft documents were not implemented and are provided for historical purposes. Details of the implementation of the Registrar Data Escrow program are posted at http://www.icann.org/en/news/announcements/announcement-2-09nov07-en.htm.

Registrar Data Escrow

 

Table of Contents

Introduction

After consultation with a committee of registrars, plans are moving forward for implementing periodic escrow of gTLD registrar data as soon as possible. When operational, the escrow program will enhance the stability of customers' domain name registrations in gTLDs. In particular, it will preserve domain registration information to permit continuing registrar services even in the case of total failure of a registrar's data storage systems -- thereby increasing consumer confidence in the gTLD shared registry architecture.

Prior to a full rollout of the escrow system to all accredited registrars, implementation will begin with a testbed consisting of a small number of volunteer registrars. Several major registrars have already agreed to participate in this testbed. Additional accredited registrars interested in volunteering for early participation in the escrow system should e-mail <data-escrow@icann.org>, or contact Chief Registrar Liaison Dan Halloran.

The current version of the ICANN Registrar Accreditation Agreement ("RAA") obliges registrars to periodically submit a copy of their registration database to ICANN or a mutually-approved third-party escrow agent. This escrowed data could be used by another registrar assigned by ICANN (or even temporarily by ICANN itself) to continue the provision of registrar services to the customers of a registrar whose accreditation is terminated or expires without renewal.

The Data Escrow provision is set forth in RAA subsection 3.6, which provides as follows:

"During the Term of this Agreement, on a schedule, under the terms, and in the format specified by ICANN, Registrar shall submit an electronic copy of the database described in Subsection 3.4.1 to ICANN or, at Registrar's election and at its expense, to a reputable escrow agent mutually approved by Registrar and ICANN, such approval also not to be unreasonably withheld by either party. The data shall be held under an agreement among Registrar, ICANN, and the escrow agent (if any) providing that (1) the data shall be received and held in escrow, with no use other than verification that the deposited data is complete, consistent, and in proper format, until released to ICANN; (2) the data shall be released from escrow upon expiration without renewal or termination of this Agreement; and (3) ICANN's rights under the escrow agreement shall be assigned with any assignment of this Agreement. The escrow shall provide that in the event the escrow is released under this Subsection, ICANN (or its assignee) shall have a non-exclusive, irrevocable, royalty-free license to exercise (only for transitional purposes) or have exercised all rights necessary to provide Registrar Services."

 

Under the testbed escrow program:

  • Full escrow will take place weekly.

  • Escrow will follow one of two formats specified by ICANN: "text-delimited" or XML.

  • Escrow data will be encrypted and transmitted via FTP from registrar to the designated escrow agent.

  • Each registrar may choose to escrow its data with either a third-party escrow agent (at the registrar's own expense) or with ICANN. Third-party escrow agents will process data received with validation scripts (to be provided by ICANN), and will send script output to ICANN for verification.

  • Third-party escrow agents and ICANN will maintain escrow data in secure facilities, and escrow data will only be used in case of registrar de-accreditation.

  • ICANN will publish registrar escrow deposit success statistics.

  • Registrars in compliance with the data escrow program will be entitled to display the logo above.

 

ICANN seeks advice from the Internet community (including registrars) on several additional details:

  • How should the testbed voluntary program be broadened to other registrars, and under what schedule?

  • Should a list of approved third-party escrow agents be established, or should they be selected and approved on a case-by-case basis?

  • Should other options for deposit transmission (such as by mailed tape/CD-R) be opened in a further rollout of the program?

  • Should registrar escrow success results be published to the public? If so, on what level of granularity and with what frequency?

  • What disaster recovery procedures should be established to enable the use of the escrowed data in the event it becomes necessary?

  • Should customers of a failed registrar all be allocated to one registrar, or be split among several registrars, or should customers choose?

 

A task force including technical experts from the Registrars Constituency created the specification for the format of the escrowed data. The committee created two recommended data format specifications: "text-delimited" and XML. (*We extend our sincere thanks to Rick Wesson of Alice's Registry, CTO of ICANN's Registrar Constituency, who authored the DTD for the XML format. Also, we are grateful to Ben Edelman for his coordination of the Registrar Data Escrow Task Force.) These draft specifications have been incorporated as an exhibit to a new "Registrar Data Escrow Appendix" (to the Registrar Accreditation Agreement) that is being discussed with the testbed participants. This appendix also sets forth the deposit procedures, data security provisions, release conditions, right-to-use terms, and the license for a new ICANN Data Escrow Program logo.

Registrars and other interested parties are invited to suggest improvements that might be made as the escrow program expands beyond the initial testbed, and to offer advice on the questions raised above. Technical corrections are also invited. A Public Comment Forum on Registrar Data Escrow has been established for this purpose at <http://forum.icann.org/escrow/>.

 


 

Registrar Data Escrow Appendix

 

This Registrar Data Escrow Appendix ("Escrow Appendix") is made and entered into by and between [Registrar Name] ("Registrar") and the Internet Corporation for Assigned Names and Numbers ("ICANN"). ICANN and Registrar have entered into a Registrar Accreditation Agreement ("Accreditation Agreement"), which shall govern this Escrow Appendix and of which this Escrow Appendix is a part. All capitalized terms not defined in this Escrow Appendix shall have the meanings set forth in the Accreditation Agreement.

In accordance with the Accreditation Agreement, Registrar intends to deliver periodically to ICANN or a third-party escrow agent an electronic copy of its current database containing data for each active Registered Name sponsored by Registrar within each TLD for which Registrar is accredited, as detailed in Subsection 3.4.1 of the Accreditation Agreement (each such delivery referred to as a "Deposit"). Pursuant to and subject to the Accreditation Agreement, Registrar and ICANN hereby agree as follows:

1. Escrow Agent. Unless Registrar indicates otherwise in writing prior to or simultaneous with the execution and delivery of this Escrow Appendix, Registrar shall deliver the Deposits to be held in escrow to ICANN as the escrow agent according to the terms and conditions in this Escrow Appendix, which refers to ICANN as both "ICANN" and "Escrow Agent." ICANN may, as the Escrow Agent, engage third parties to furnish the escrow services hereunder, provided that such engagement will not relieve ICANN from any of its obligations under this Escrow Appendix. Registrar may elect at any time to have a third-party escrow agent hold the Deposits, in which case:

1.1. Registrar shall notify ICANN of such election in writing;

1.2. Any third-party escrow agent shall be mutually approved by Registrar and ICANN, such approval not to be unreasonably withheld by either party;

1.3. Registrar shall use its best efforts to negotiate a written escrow agreement with such mutually approved third-party escrow agent that includes any provisions or language provided by ICANN and Exhibits A and B attached hereto, and Registrar shall present to ICANN, for ICANN's approval not to be unreasonably withheld, an unexecuted draft(s) of such escrow agreement;

1.4. Such escrow agreement between Registrar and the third-party escrow agent, once approved by ICANN and executed, shall govern the delivery, holding, release, and other aspects of such Deposits, subject to this Escrow Appendix and the Accreditation Agreement; and

1.5. During any period when Deposits are not being made by Registrar pursuant to such an escrow agreement with a third-party escrow agent (due to termination of the escrow agreement, unsuccessful negotiation and/or approval of such an agreement, or otherwise) Registrar agrees to deliver such Deposits to ICANN pursuant to the sections of this Escrow Appendix that follow.

2. Deposit Content and Procedure.

2.1. Content of Deposits. Each Deposit will consist of data that reflects the current and complete database containing data for each active Registered Name sponsored by Registrar within each TLD for which Registrar is accredited, as detailed in Subsection 3.4.1 of the Accreditation Agreement.

2.2. Format of Deposits. The data in each Deposit shall follow the data format(s) specified in the Data Format Specification (the "Format Specification"), attached hereto as Exhibit B, which may be amended from time to time by ICANN.

2.3. Schedule for Deposits. Registrar must create and deliver to Escrow Agent a new, updated Deposit once per week, according to the schedule specified in Exhibit A, which may be amended from time to time by ICANN. In the interests of openness and transparency, the parties agree that ICANN may disclose statistics indicating Registrar's timely deposit rate for Deposits made pursuant to this Escrow Appendix.

2.4. Procedure for Deposits. Each properly formatted Deposit shall be processed and electronically delivered in encrypted form to Escrow Agent according to the transfer process described in Exhibit A.

2.5. Notification of Deposits. Simultaneously with the delivery to Escrow Agent of any Deposit, Registrar shall deliver to ICANN a written delivery report (as described in Exhibit A) which states that the Deposit has been inspected by Registrar according to the procedures described in Exhibit A and is complete and accurate.

2.6. Verification. After receiving any Deposit, Escrow Agent shall verify the format and completeness of each such Deposit by performing the verification procedures in Exhibit A. Upon notification that any Deposit has failed the verification procedures, Registrar shall begin developing modifications, updates, corrections, and other fixes of the Deposit necessary for the Deposit to pass the verification procedures and shall deliver the remediated Deposit to Escrow Agent as promptly as possible. The failure of any Deposit to meet the verification procedures and any efforts by Registrar to remedy such failure shall not delay the delivery of any subsequent scheduled Deposits pursuant to the schedule in Exhibit A.

3. Data Security.

3.1. Retention. Escrow Agent shall hold and maintain the Deposits in a secure, locked, and environmentally safe facility which is accessible only to authorized representatives. The Deposits shall be received and held in escrow, with no use other than verification that the Deposits are complete, consistent, and in proper format, until released to ICANN.

3.2. Confidentiality. Escrow Agent shall use commercially reasonable efforts to protect the integrity and confidentiality of the Deposits. Escrow Agent shall not disclose or use any Deposit except as provided in this Escrow Appendix. Escrow Agent shall not be held liable for any disclosure required by governmental, legislative, judicial, or arbitral order, statute, or rule.

3.3. Destruction and Duplication. At all times, Escrow Agent shall retain the four (4) most recent Deposits, all of which must have passed the verification procedures specified in Exhibit A. Escrow Agent may destroy any Deposits prior to these four (4) most recent Deposits. Escrow Agent may duplicate any Deposit by any commercially reasonable means in order to comply with the terms and provisions of this Escrow Appendix.

4. Release of Deposit to ICANN.

4.1. Release Conditions. All Deposits in Escrow Agent's possession (in decrypted form and/or along with all necessary decryption keys) shall be released to ICANN, at ICANN's discretion, request, and instruction, upon the occurrence of any of the following:

4.1.1. Expiration of the Accreditation Agreement without renewal;

4.1.2. Termination of the Accreditation Agreement; or

4.1.3. Written notice by Registrar requesting the release of the Deposits to ICANN.

4.2. Right to Use Deposits. Upon release of the Deposits to ICANN, ICANN (or its assignee) shall immediately have a non-exclusive, irrevocable, royalty-free license to exercise (only for transitional purposes) or have exercised all rights necessary to provide Registrar Services, as detailed in the Accreditation Agreement. Any claims or disputes relating to or arising out of this Escrow Appendix shall be resolved pursuant to Section 5.6 of the Accreditation Agreement. The parties agree that any election to resolve a dispute pursuant to Section 5.6 of the Accreditation Agreement shall not delay release of any Deposits to ICANN pursuant to Section 4.1.

5. ICANN Data Escrow Program Logo License.

5.1. Grant of License. ICANN grants to Registrar a non-exclusive, worldwide right and license to use the ICANN Data Escrow Program Logo attached as Exhibit C hereto (the "Logo"), during the term of this Escrow Appendix and solely in connection with the provision and marketing of Registrar Services in order to indicate that Registrar is accredited as a registrar of domain names by ICANN and has been and is depositing its registration data in accordance with this Escrow Appendix. Except as provided in this subsection, Registrar shall not use the Logo, any term, phrase, or design which is confusingly similar to the Logo or any portion of the Logo in any manner whatsoever. Registrar shall not sublicense any of its rights under this Section 5 to any other person or entity (including any of Registrar's resellers) without the prior written approval of ICANN.

5.2. Ownership of Logo. Any and all rights in the Logo that may be acquired by Registrar shall inure to the benefit of, and are hereby assigned to, ICANN. Registrar shall not assert ownership of the Logo or any associated goodwill. Registration and any other form of protection for the Logo shall only be obtained by ICANN in its name and at its expense.

5.3. Enforcement. Registrar shall promptly notify ICANN of any actual or suspected infringement of the Logo by third parties, including Registrar's resellers or affiliates. ICANN shall have the sole discretion to initiate and maintain any legal proceedings against such third parties; Registrar shall not take any such actions without the prior written approval of ICANN; and ICANN shall retain any and all recoveries from such actions.

5.4. Further Assurances. Registrar agrees to execute such other documents and to take all such actions as ICANN may request to effect the terms of this Section 5, including providing such materials (for example URLs and samples of any promotional materials bearing the Logo), cooperation, and assistance as may be reasonably required to assist ICANN in obtaining, maintaining, and enforcing trademark registration(s) and any other form of protection for the Logo.

6. Term and Termination. This Escrow Appendix shall be effective from the date it is signed below by both parties until the Expiration Date, unless and until the Accreditation Agreement is earlier terminated. Sections 3.2, 4, and 6 shall survive any termination of this Escrow Appendix.

IN WITNESS WHEREOF each of the parties has caused its duly authorized officer to execute this Escrow Appendix as of the date and year written below.

INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS
4676 Admiralty Way, Suite 330
Marina del Rey, California 90292 USA
Telephone: 1/310/823-9358
Facsimile: 1/310/823-8649

By:__________________________
Name:
Title:

Dated:_________________, 200___

[Registrar Name]
[registrar street address]
[registrar city and state]
Telephone:
Facsimile:

By:__________________________
Name:
Title:

Dated:_________________, 200___

 


EXHIBIT A

ESCROW PROCEDURE AND DETAILS

 

1. DEPOSIT FILE CREATION SCHEDULE

[No less than once per week; day(s) to be specified by Escrow Agent].

2. DEPOSIT DELIVERY SCHEDULE

[Within 24 hours of Deposit creation; at a time window specified by Escrow Agent from time to time].

3. DEPOSIT TRANSFER PROCESS

Registrar shall prepare and transfer the Deposit file by the following steps, in sequence:

A. The Deposit file will first be created according to the selected format specification. (See Exhibit B - "Format of Deposit"). Filenames will follow a naming convention to be specified by ICANN.

B. Next, the Deposit file will be processed by a program (provided by ICANN) that will verify that it complies with the format specification, count the number of domain objects in the file, and append to the file a report of the program's results.

C. Registrar may optionally split the resulting file using the Unix SPLIT command (or equivalent) to produce files no less than 1GB 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.

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

E. The formatted, encrypted and signed Deposit file will be sent, by anonymous file transfer, to Escrow Agent's ftp server <ftp://_______________> within the specified time window.

4. VERIFICATION OF TRANSFER

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

A. At the conclusion of the deposit window, the Deposit will be moved to a not-publicly-accessible directory and its existence and size will be noted.

B. The Deposit file will be decrypted using Escrow Agent's private key for PGP and authenticated using Registrar's public key for PGP. (In this step, PGP will also automatically decompress the escrow file).

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

D. The format report generated by Registrar will be detached from the file and stored.

E. Escrow Agent will run a program on the Deposit file (without report) that will check its format, count the number of objects, and verify that the data set is internally consistent. This program will compare its results with the results of the Registrar-generated format report, and will generate a Deposit format and completeness report. Escrow Agent will use the escrow completeness and format report to verify that Deposits are being made in proper format and with complete data. Escrow Agent may compare object counts in the reports with other data to further verify completeness.

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

G. Escrow Agent shall retain the encrypted Deposit as well as the decryption keys necessary to decrypt the Deposit in the event of release to ICANN.

5. DISTRIBUTION OF PUBLIC KEYS

Each of Registrar and Escrow Agent will distribute its public key to the other party (Registrar or Escrow Agent, as the case may be) via e-mail to an e-mail address to be specified. Each party will confirm receipt of the other party's public key with a reply e-mail, 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.

6. FEE SCHEDULE

Fees to be paid by Registrar shall be as follows: [________________]



EXHIBIT B

DATA FORMAT SPECIFICATION

 

This document defines the formats in which ICANN-accredited registrars make escrow Deposits. There are two alternative formats, from which the registrar may choose: text-delimited and XML.

The text-delimited format is designed to be a simple format that supports flat-file export of domain objects (records). The XML format is more complex, but can support additional features. For example, in the XML format domain objects may be written with server and contact objects contained within the domain objects (i.e. a flat-file model), or they written as separate objects and referenced in domain objects (i.e. a relational model).

ESCAPE-CHARACTER AND FORMATTING REQUIREMENTS

In compliance with the XML 1.0 specification, data escrowed using the XML format the following characters in any data elements must be replaced with the corresponding delimiters listed here:

Character Delimiters
"
&quot;
& &amp;
' &apos;
< &lt;
> &gt;

In the text-delimited format, only the right angle-bracket ("<") and ampersand must be replaced with their corresponding delimiters. The carriage return may not be used in the text-delimited format except for record termination and in the header.

Throughout both text-delimited and XML format escrow files, dates will be specified in format day-month-year hour:minutes:seconds AM/PM, with [_____________________]

 

XML FORMAT

The escrow file may also be formatted in XML format. The XML format offers all the features of the text-delimited format as well additional flexibility to represent data in a related-object model. The required escrow information is the same for XML as for text-delimited, but it often can be represented in a shorter file in XML format. The XML format is also more flexible, as described in the following discussion of the schema of the XML data format specification.

The Escrow Container. At its highest level, the XML format consists of an escrow container with header attributes followed by escrow data:

o The header attributes are required and include the version of escrow (1.0), registrar number, and date and time of escrow. The registrar number will be uniquely assigned in coordination with Network Solutions Registry and the IANA (http://www.iana.org/numbers.htm). The date and time of escrow will be specified in UTC.

o The remainder of the escrow file contains the actual data being escrowed. It contains one domain element for each domain name sponsored by the registrar in the registry. It may also include other elements (such as server and contact elements), as described below.

The Domain Container. The domain element has the property "fqdn" (the fully qualified name of the domain) and is a container consisting of the following elements:

o Zero to thirteen ns elements, representing the nameservers configured for the domain. NS elements give the name, IP address(es) of the nameserver(s) (via one or more IP elements), and dates of creation and modification of nameservers. They may be specified inline, as follows:

<ns name="ns.isi.edu">
  <ip>128.9.128.127</ip>
  <created>3-Mar-1994</created>
  <modified>4-Mar-1995</modified>
</ns>

Alternatively, the ns object may point to a nameserver object directly under the escrow container, with the following syntax:

<ns handle="ns.isi.edu" />

The nameserver element would then have the following format:

<ns name="ns.isi.edu">
  <ip>128.9.128.127</ip>
  <created>3-Mar-1994</created>
  <modified>4-Mar-1995</modified>
</ns>

o Created element. There should be exactly one created element for each domain. This element gives the date of the domain-name's original registration. Times are specified as stored by the registry, in the local date and time used by NSI Registry. This element has the following format:

<created date="04-Jul-1995" />

o Expires element. There should be exactly one expires element for each domain. This element gives the date of the registration's expiration. Times are specified as stored by the NSI Registry, in the local date and time used by registry. This element has the following format:

<expires date="05-Jul-2005" />

o Modified element. There should be exactly one modified element for each domain. This element gives the date of the registration's expiration date. Times are specified as stored by the NSI Registry, in the local date and time used by registry. This element has the following format:

<modified date="16-Sep-2000" />

o Organization element. There should be exactly one organization element for each domain. This gives the organization that registered the domain name. It must give name and address data. This can be done inline by including a name element and an address element in the container formed by the organization element. This is one format for doing that:

<organization>
  <name>Internet Assigned Numbers Authority</name>
  <address>
    <line>4676 Admiralty Way, Suite 330</line>
    <line>Marina del Rey, CA 90292</line>
    <line>US</line>
  </address>
</organization>

It should be noted that the elements within the address container may be modified by the registrar. Thus, the following would also be valid:

<organization>
  <name>Internet Assigned Numbers Authority</name>
  <address>
    <street>4676 Admiralty Way</street>
    <room>Suite 330</room>
    <city>Marina del Rey</city>
    <state>CA</state>
    <postalcode>90292</postalcode>
    <country>US</country>
  </address>
</organization>

o Contact element. There must at least three contact elements within the domain container. Each contact element has a type attribute; within each domain container there must be at least one contact element of type "admin", one of type "tech", and one of type "billing." There may be more than one of each of these types.

Contact elements must give name, address, e-mail, voice, and fax information as well as dates of creation and last modification. They optionally can also give title information. This can be done inline (i.e. within the domain element) as follows:

<contact type="admin">
  <name>Karrenberg, Daniel</name>
  <address>
    <line>RIPE NCC</line>
    <line>Singel 258</line>
    <line>Amsterdam</line>
    <line>NH</line>
    <line>1016 AB</line5>
    <line>NL</line6>
  </address>
  <e-mail>dfk@ripe.net</e-mail>
  <voice>+31-20-535-4444</voice>
  <fax>+31-20-535-4445</fax>
  <created>15-Aug-1993</created>
  <modified>16-Aug-1994</modified>
</contact>

(Note that the remarks above about flexible format within address elements apply here as well.)

Alternatively, the contact element within the domain container can simply give a reference to the handle of a contact element contained directly under the escrow container. Under this approach, the following contact element might appear within the domain element:

<contact type="admin" handle="DK58" />

The following contact element would then appear directly within the escrow container:

<contact type="admin" handle="DK58">
  <name>Karrenberg, Daniel</name>
  <address>
    <line>RIPE NCC</line>
    <line>Singel 258</line>
    <line>Amsterdam</line>
    <line>NH</line>
    <line>1016 AB</line5>
    <line>NL</line6>
  </address>
  <e-mail>dfk@ripe.net</e-mail>
  <voice>+31-20-535-4444</voice>
  <fax>+31-20-535-4445</fax>
  <created>15-Aug-1993</created>
  <modified>16-Aug-1994</modified>
</contact>

o Language element. The language element is included to support multilingual domain names within the registry. It has a single attribute, named "tag". This element is optional and may be omitted.

o Extensions element. The extensions element is a container in which remarks inserted by the registrar, in UTF-8 format, may be included. It is the only portion of the escrowed data that need not be in 7-bit ASCII, non-control characters. (However, the five characters listed above must still be escaped.) It may be used, for example, to escrow the non-ASCII equivalents of domain names, organization names, addresses, etc. As these features evolve, this element will be better defined. Until then, registrars may optionally use it at their discretion.

Document Type Definition. (Authored by Rick Wesson of Alice's Registry.)

<!ELEMENT escrow (domain|contact|ns)*>

<!ATTLIST escrow
  version CDATA #FIXED "1.0"
  registrar CDATA #REQUIRED
  date CDATA #REQUIRED >

<!ELEMENT ns ((ip)*, contact?)?>

<!-- ns Name Server
  this container must be either be primary or secondary
-->
<!ATTLIST ns
  id ID #IMPLIED
  ref IDREF #IMPLIED
  handle CDATA #IMPLIED
  name CDATA #IMPLIED
  created CDATA #IMPLIED
  modified CDATA #IMPLIED>

<!ELEMENT ip (#PCDATA) >

<!ELEMENT created (#PCDATA) >
<!ATTLIST created date CDATA #REQUIRED >

<!ELEMENT expires (#PCDATA) >
<!ATTLIST expires date CDATA #REQUIRED >

<!ELEMENT modified (#PCDATA) >
<!ATTLIST modified date CDATA #REQUIRED >


<!-- the line syntax is an alternate method of specifying an unformatted address listing. -->
<!ELEMENT line (#PCDATA) >

<!ELEMENT address (line*| (street*,(city,(state)?)?, postalcode,country))?>

<!ELEMENT contact (name,title?,organization?,address?,voice?,fax?,e-mail?)?>
<!ATTLIST contact
  id ID #IMPLIED
  ref IDREF #IMPLIED
  handle CDATA #IMPLIED
  type (admin |    tech |    billing |    zone ) #IMPLIED>

<!ELEMENT name (#PCDATA) >
<!ELEMENT title (#PCDATA) >
<!ELEMENT organization (name,address) >
<!ELEMENT street (#PCDATA) >
<!ELEMENT city (#PCDATA) >
<!ELEMENT state (#PCDATA) >
<!ELEMENT postalcode (#PCDATA) >
<!ELEMENT country (#PCDATA) >
<!ELEMENT voice (#PCDATA) >
<!ELEMENT fax (#PCDATA) >
<!ELEMENT created (#PCDATA) >
<!ELEMENT modified (#PCDATA) >
<!ELEMENT e-mail (#PCDATA) >
<!ELEMENT extensions (#PCDATA) >
<!ELEMENT lang (#PCDATA) >

<!ELEMENT domain ((organization?)?, (ns*)?, contact*, created?, expires?, modified?, extentions?)>
<!ATTLIST domain
  fqdn CDATA #REQUIRED
  lang CDATA #IMPLIED "ascii">

 

Example of XML Format Escrow File (flatfile XML format)

<?xml version="1.0" encoding='UTF-8' ?>
<!DOCTYPE escrow SYSTEM "whois-export.dtd" >
<escrow version="1.0" registrar="51" date="26-Aug-2000 3:15:00AM">

  <domain fqdn="example.com">
    <organization>
      <name>Internet Assigned Numbers Authority</name>
      <address>
        <line>4676 Admiralty Way, Suite 330</line>
        <line>Marina del Rey, CA 90292</line>
        <line>US</line>
      </address>
    </organization>

    <ns name="venera.isi.edu">
      <ip>128.9.176.32</ip>
      <created>3-Feb-1994</created>
      <modified>4-Feb-1995</modified>
    </ns>
    <ns name="ns.isi.edu">
      <ip>128.9.128.127</ip>
      <created>13-Feb-1994</created>
      <modified>14-Feb-1995</modified>
    </ns>

  <contact type="admin">
    <name>Internet Assigned Numbers Authority</name>
    <address>
      <line>IANA</line>
      <line>4676 Admiralty Way, Suite 330</line>
      <line>Marina del Rey, CA 90292</line>
      <line>US</line>
    </address>
    <voice>+1-310-823-9358</voice>
    <fax>+1-310-823-8649</fax>
    <email>iana@iana.org</email>
    <created>15-Aug-1995</created>
    <modified>16-Aug-1996</modified>
  </contact>

  <contact type="tech">
    <name>Internet Assigned Numbers Authority</name>
    <address>
      <line>IANA</line>
      <line>4676 Admiralty Way, Suite 330</line>
      <line>Marina del Rey, CA 90292</line>
      <line>US</line>
    </address>
    <voice>+1-310-823-9358</voice>
    <fax>+1-310-823-8649</fax>
    <email>iana@iana.org</email>
    <created>15-Aug-1995</created>
    <modified>16-Aug-1996</modified>
  </contact>

  <contact type="billing">
    <name>Internet Assigned Numbers Authority</name>
    <address>
      <line>IANA</line>
      <line>4676 Admiralty Way, Suite 330</line>
      <line>Marina del Rey, CA 90292</line>
      <line>US</line>
    </address>
    <voice>+1-310-823-9358</voice>
    <fax>+1-310-823-8649</fax>
    <email>iana@iana.org</email>
    <created>15-Aug-1995</created>
    <modified>16-Aug-1996</modified>
  </contact>

  <created date="14-Aug-1995" />
  <expires date="15-Aug-2010" />
  <modified date="16-Sep-2000" />

</domain>

<domain fqdn="root-servers.net">
    <organization>
      <name>NSI Registry</name>
      <address>
        <line>505 Huntmar Park Drive</line>
        <line>Herndon, VA 20170</line>
        <line>US</line>
      </address>
    </organization>

    <ns name="a.root-servers.net">
      <ip>198.41.0.4</ip>
      <created>3-Mar-1994</created>
      <modified>4-Mar-1995</modified>
    </ns>
    <ns name="f.root-servers.net">
      <ip>192.5.5.241</ip>
      <created>13-Mar-1994</created>
      <modified>14-Mar-1995</modified>
    </ns>
    <ns name="j.root-servers.net">
      <ip>198.41.0.10</ip>
      <created>23-Mar-1994</created>
      <modified>24-Mar-1995</modified>
    </ns>
    <ns name="k.root-servers.net">
      <ip>193.0.14.129</ip>
      <created>29-Mar-1994</created>
      <modified>30-Mar-1995</modified>
    </ns>

    <contact type="admin">
      <name>Internet Assigned Numbers Authority</name>
      <address>
        <line>IANA</line>
        <line>4676 Admiralty Way, Suite 330</line>
        <line>Marina del Rey, CA 90292</line>
        <line>US</line>
      </address>
      <voice>+1-310-823-9358</voice>
      <fax>+1-310-823-8649</fax>
      <email>iana@iana.org</email>
      <created>15-Aug-1995</created>
      <modified>16-Aug-1996</modified>
    </contact>

    <contact type="tech">
       <name>NSI Registry</name>
       <address>
         <line>Network Solutions, Inc.</line>
         <line>505 Huntmar Park Drive</line>
         <line>Herndon, VA 20170</line>
         <line>US</line>
       </address>
       <voice>+1-703-742-0400</voice>
       <fax>+1-703-742-5427</fax>
       <email>hostmaster@nsiregistry.net</email>
       <created>15-Aug-1993</created>
       <modified>16-Aug-1994</modified>
    </contact>

    <contact type="billing">
      <name>idNames, Accounting</name>
      <address>
          <line>idNames from Network Solutions, Inc.</line>
          <line>440 Benmar</line>
          <line>Suite #3325</line>
          <line>Houston, TX 77060</line>
          <line>US</line>
      </address>
      <voice>+1-703-742-4777</voice>
      <fax>+1-281-447-1160</fax>
      <email>accounting@idnames.com</email>
      <created>15-Aug-1993</created>
      <modified>16-Aug-1994</modified>
    </contact>

    <created date="04-Jul-1995" />
    <expires date="05-Jul-2005" />
    <modified date="16-Sep-2000" />

  </domain>

</escrow>

 

Example of XML Format Escrow File (relational XML format)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE escrow SYSTEM "whois-export.dtd" >
<escrow version="1.0" registrar="51" date="26-Aug-2000 3:15:00AM" >
   <contact handle="IANA" >
      <name>Internet Assigned Numbers Authority</name>
      <address>
         <line>IANA</line>
         <line>4676 Admiralty Way, Suite 330</line>
         <line>Marina del Rey, CA 90292</line>
         <line>US</line>
      </address>
      <voice>+1-310-823-9358</voice>
      <fax>+1-310-823-8649</fax>
      <email>iana@iana.org</email>
      <created>15-Aug-1995</created>
      <modified>16-Aug-1996</modified>
   </contact>

   <contact handle="NSIRegistry">
      <name>NSI Registry</name>
      <address>
         <line>Network Solutions, Inc.</line>
         <line>505 Huntmar Park Drive</line>
         <line>Herndon, VA 20170</line>
         <line>US</line>
         </address>
         <voice>+1-703-742-0400</voice>
         <fax>+1-703-742-5427</fax>
         <email>hostmaster@nsiregistry.net</email>
         <created>15-Aug-1993</created>
         <modified>16-Aug-1994</modified>
   </contact>

   <contact handle="IDNames">
      <name>idNames, Accounting</name>
      <address>
         <line>idNames from Network Solutions, Inc.</line>
         <line>440 Benmar</line>
         <line>Suite #3325</line>
         <line>Houston, TX 77060</line>
         <line>US</line>
      </address>
      <voice>+1-703-742-4777</voice>
      <fax>+1-281-447-1160</fax>
      <email>accounting@idnames.com</email>
      <created>15-Aug-1993</created>
      <modified>16-Aug-1994</modified>
   </contact>

<ns name="venera.isi.edu">
   <ip>128.9.176.32</ip>
   <created>3-Feb-1994</created>
   <modified>4-Feb-1995</modified>
</ns>
<ns name="ns.isi.edu">
   <ip>128.9.128.127</ip>
   <created>13-Feb-1994</created>
   <modified>14-Feb-1995</modified>
</ns>
<ns name="a.root-servers.net">
   <ip>198.41.0.4</ip>
   <created>3-Mar-1994</created>
   <modified>4-Mar-1995</modified>
</ns>
<ns name="f.root-servers.net">
   <ip>192.5.5.241</ip>
   <created>13-Mar-1994</created>
   <modified>14-Mar-1995</modified>
</ns>
<ns name="j.root-servers.net">
   <ip>198.41.0.10</ip>
   <created>23-Mar-1994</created>
   <modified>24-Mar-1995</modified>
</ns>
<ns name="k.root-servers.net">
   <ip>193.0.14.129</ip>
   <created>29-Mar-1994</created>
   <modified>30-Mar-1995</modified>
</ns>
<domain fqdn="example.com">
   <organization>
      <name>Internet Assigned Numbers Authority</name>
      <address>
         <line>4676 Admiralty Way, Suite 330</line>
         <line>Marina del Rey, CA 90292</line>
         <line>US</line>
       </address>
    </organization>

   <ns handle="venera.isi.edu" />
   <ns handle="ns.isi.edu" />

   <contact handle="IANA" type="billing" />
   <contact handle="IANA" type="tech" />
   <contact handle="IANA" type="admin" />

   <created date="14-Aug-1995" />
   <expires date="15-Aug-2010" />
   <modified date="16-Sep-2000" />

</domain>

<domain fqdn="root-servers.net">
   <organization>
      <name>NSI Registry</name>
      <address>
         <line>505 Huntmar Park Drive</line>
         <line>Herndon, VA 20170</line>
         <line>US</line>
      </address>
   </organization>
   <ns handle="a.root-servers.net" />
   <ns handle="f.root-servers.net" />
   <ns handle="j.root-servers.net" />
   <ns handle="k.root-servers.net" />

   <contact handle="IANA" type="admin" />
   <contact handle="NSIRegistry" type="tech" />
   <contact handle="IDNames" type="billing" />

   <created date="04-Jul-1995" />
   <expires date="05-Jul-2005" />
   <modified date="16-Sep-2000" />

   </domain>

</escrow>

TEXT-DELIMITED FORMAT

The escrow file may be formatted in delimited text as specified below. This format offers easier implementation for some back-end registrar implementations. In contrast, the XML format offers all the features of the text-delimited format as well additional flexibility to represent data in a related-object model. The required escrow information is the same for XML as for text-delimited, but in many cases it can be represented in a shorter file in XML format.

Except within the ExtensibilityFields (see below), all text within the text-delimited format must be 7-bit ASCII. The text-delimited format uses the right angle-bracket ("<") as a field separator, while a standard carriage return terminates each record.


Header

A file in text delimited format begins with a header giving basic information about the information to follow. The first line of the header gives the registrar code (to be uniquely assigned in coordination with Network Solutions Registry and the IANA (http://www.iana.org/numbers.htm). The second line notes the date and time of escrow (specified in UTC). The third line states the version of the escrow format (currently 1.0 and subject to change by ICANN from time to time). The fourth line consists of the field list, a list of field names (selected from the list below, not case sensitive) separated by the field delimiter ("<").

The presence of each field in the data section must be declared via a corresponding entry in the header, but if a field is empty in all records in the data section, the field may be omitted both from the header and from all records in the data section. This allows registrars to omit fields not used by any of their customers.

Each of the four lines of the header is followed by a carriage return.


Data Section

For each record in the escrow file, the data section contains a series of field data elements, separated by the field delimiter ("<"), followed by a carriage return. Fields must follow the order of fields specified in the field list (header line four).

For each domain in the escrow, the following data must be included: SLDName, CreationDate, ExpirationDate, ModifiedDate, SLDHName, SLDHStreet, SLDHCity, SLDHState, SLDHPostalCode, SLDHCountry, TechName, TechStreet, TechCity, TechState, TechPostalCode, TechCountry, TechEmail, TechVoiceTel, TechFax, TechCreated, TechModified, AdminName, AdminStreet, AdminCity, AdminState, AdminPostalCode, AdminCountry, AdminEmail, AdminVoiceTel, AdminFax, AdminCreated, AdminModified, BillingName, BillingStreet, BillingCity, BillingState, BillingPostalCode, BillingCountry, BillingEmail, BillingVoiceTel, BillingFax, AdminCreated, AdminModified.

For each domain in the escrow, the following data may optionally be included (but must be included if present in the domain registration as stored in a registrar's internal databases): NS1, IPAddress1-1,..., IPAddress1-13, ... NS13, IPAddress13-1, ...IPAddress13-13, NS1Created, ..NS13Created, …NS1Modified, …NS13Modified. NS1 gives the fully-qualified domain name of the domain's first (primary) name server, while NS2 through NS13 give names of secondary name servers. IPAddress1-1 gives the first IP address of the first name server, while additional addresses of the same server can be given in IPAddress1-2 through IPAddress1-13 if needed. IP addresses for other name servers are given in similar format. Dates of creation and most recent modification of the corresponding name servers follow.

Registrars may choose to use an alternative address format via fields of name [addresstype]Address1 through [addresstype]Address6, where [addresstype] is replaced with SLDH, Tech, Admin, or Billing as needed for the four addresses. If these fields are used, they replace the Street, City, State, PostalCode, and Country fields described above. As for other fields, registrars may omit unneeded fields to the extent possible (i.e. use only Address1 through Address4 if all addresses have four or fewer lines).

Registrars may optionally escrow non-ASCII data in a field called ExtensibilityFields (but in no other field). In addition, registrars participating in the NSI Registry multilingual program may use the optional LanguageTag field to escrow the language of a domain name registration.

Registrars may optionally add additional fields to enable the escrow of additional data as needed. Such fields of the registrar's own creation must be declared in the header with names beginning OPT.

If a field is empty in all records in the data section, the field may be omitted both from the header and from all records in the data section.


Example of Text-Delimited Format Escrow File

Here is an example escrow file in text-delimited format for the domain example.com (Note: this example has been modified for display in a web browser --the spaces before and after the brackets would not be included in the actual data files.)

51
26-Aug-2000 3:15:00AM
1.0
SLDName < CreationDate < ExpirationDate < ModifiedDate < SLDHName < SLDHStreet < SLDHCity < SLDHState < SLDHPostalCode < SLDHCountry < TechName < TechStreet < TechCity < TechState < TechPostalCode < TechCountry < TechEmail < TechVoiceTel < TechFax < TechCreated < TechModified < AdminName < AdminStreet < AdminCity < AdminState < AdminPostalCode < AdminCountry < AdminEmail < AdminVoiceTel < AdminFax < AdminCreated < AdminModifiedBillingName < BillingStreet < BillingCity < BillingState < BillingPostalCode < BillingCountry < BillingEmail < BillingVoiceTel < BillingFax < BillingCreated < BillingModified < NS1 < IPAddress1-1 < NS2 < IPaddress2-1 < NS1Created < NS2Created < NS1Modified < NS2Modified
Example.com < 14-Aug-1995 < 15-Aug-2010 < 16-Sep-2000 < Internet Assigned Numbers Authority < 4676 Admiralty Way < Suite 330 < Marina del Rey < CA < 90292 < US < Internet Assigned Numbers Authority < 4676 Admiralty Way < Suite 330 < Marina del Rey < CA < 90292 < US < iana@iana.org < +1-310-823-9358 < +1-310-823-8649 < 10-Aug-1993 < 11-Aug-1994 < Internet Assigned Numbers Authority < 4676 Admiralty Way < Suite 330 < Marina del Rey < CA < 90292 < US < iana@iana.org < +1-310-823-9358 < +1-310-823-8649 < 10-Aug-1993 < 11-Aug-1994 < Internet Assigned Numbers Authority < 4676 Admiralty Way < Suite 330 < Marina del Rey < CA < 90292 < US < iana@iana.org < +1-310-823-9358 < +1-310-823-8649 < 10-Aug-1993 < 11-Aug-1994 < venera.isi.edu < 128.9.176.32 < ns.isi.edu < 128.9.128.127 < 3-Mar-1994 < 4-Mar-1994 < 4-Apr-1995 < 5-Apr-1995

 


EXHIBIT C

ICANN DATA ESCROW PROGRAM LOGO

 


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

Page Updated 08-Nov-2001
(c) 2001  The Internet Corporation for Assigned Names and Numbers. All rights reserved.