Skip to navigation Skip to main content Skip to footer

Registry data escrow service FAQ

Contact Us Download PGP Key

Your Technical Questions Answered

Registry Data Escrow is a specialized data protection service. The service ensures that up-to-date copies of domain name ownership and contact details are held in escrow by a trusted, neutral third party, such as Iron Mountain. This data can only be accessed and released under predefined and controlled conditions, such as the failure of a registry.
Data escrow is one of the five critical registry functions and is a requirement for all new generic Top-Level Domains (gTLDs).

Q.Why do Registry Operators need Registry Data Escrow?

A. As the new generic Top-Level Domains (gTLDs) become a reality, Internet Corporation for Assigned Names and Numbers (ICANN) is working with Registry Operators to ensure all registry data is protected.

Escrow protects the data associated with your new gTLD. As a Registry Operator, you must comply with the Data Escrow provisions of ICANN’s Registry Agreement. Essentially, this means you must enter into a separate Registry Data Escrow agreement with an ICANN-approved data escrow provider. The Registry Data Escrow agreement requires registries to periodically transfer registry data for their gTLDs to be held securely in escrow by the escrow provider. The purpose of Registry Data Escrow is to help safeguard registrar and registrant interests in the event of a registry’s business or technical failure.

Data escrow is one of the five critical registry functions and is a requirement for all new gTLDs. Details are given in Specification 2 of the Registry Agreement.

Q. How does Registry Data Escrow work?

A. Here’s a high level overview of the escrow process, and then we’ll answer your more technical questions.

Registry Operators and ICANN rely on Iron Mountain to hold each deposit, and upon certain events, release any retained deposits to ICANN. This ensures that the data associated with registered domain names is never at risk of being lost or inaccessible.

Data to be deposited must be formatted as specified by ICANN, and then encrypted and uploaded via secure FTP (sFTP) transmission. Iron Mountain provides setup instructions to aid implementation.

Registries must make regular deposits to their escrow account that consists of data elements residing within their then-current complete registry database. One full deposit must be made per week, and daily differential deposits during other days are also required. Deposits include the necessary registry objects such as the domain names, registrant’s contact information (admin, technical & billing), name servers, IP addresses, registrar-specific information, dates and times of the object creation, etc. and compiled into a file constructed as described in the Registry Data Escrow Specification. This document describes some elements as optional; however, these elements should be included in the deposits if they are available.

Upon receiving a deposit, Iron Mountain validates its format and completeness by decrypting and authenticating files to verify that they actually came from the Registry Operator. Iron Mountain then moves the file to a non-public directory and notes the size and existence of the file. Once registries complete the initial setup and establish an automated process, data transmission can be completed with very little time or effort. For security purposes, digital signatures, data encryption, and sFTP technologies are used.

Q. What happens after I choose Iron Mountain?

A. After signing the user agreement, you will receive your Registry Data Escrow Setup Form. Once Iron Mountain has received the completed form, and the OpenPGP has been imported, an email will be sent to you that will include an encrypted file that contains your login information and Iron Mountain’s OpenPGP public key.

A public key and private key are generated together because data encrypted with the public key can only be decrypted with the private key, and a message signed with the private key can be validated with the public key.

The ICANN Data Escrow Specification states that the deposit must be signed using detached signatures. Therefore, a signature (.sig) file must accompany each deposit file.

Because you are sending data you want to keep private, you will need to both encrypt the message and digitally sign the message. When Iron Mountain receives this deposit using OpenPGP, we will decrypt the message and verify the signature.

Q. What is the Registry Data Escrow Setup Form?

A. The Registry Data Escrow Setup Form is used to create the sFTP account after the Registry Data Escrow Agreement with Iron Mountain is executed. The Setup Form will be sent to the Registry Operator with a copy of their executed agreement.

Q. Can I use any type of encryption?

A. Data must be encrypted using the current version of OpenPGP. The escrow contract specifies that the deposit will be encrypted using Iron Mountain’s public key.

Q. Do Registries need a new key for each deposit?

A. No, only one key pair is necessary per gTLD. You will not need to provide a new key with each deposit.

Q. How does the processing of deposit files work?

A. ICANN has published all of the details as part of the new gTLD Registry Agreement. Here is a summary from that agreement:

The use of compression is recommended in order to reduce electronic data transfer times, and storage capacity requirements. Data encryption will be used to ensure the privacy of registry escrow data. Files processed for compression and encryption will be in the binary OpenPGP format as per OpenPGP Message Format - RFC 4880.

Acceptable algorithms for Public-key cryptography, Symmetric-key cryptography, Hash, and Compression are those enumerated in RFC 4880, not marked as deprecated in OpenPGP IANA Registry, that are also royalty-free.

The process to follow for a data file in original text format is:

  1. The file should be compressed. The suggested algorithm for compression is ZIP as per RFC 4880.
  2. The compressed data will be encrypted using the escrow agent’s public key. The suggested algorithms for Public-key encryption are Elgamal and RSA as per RFC 4880. The suggested algorithms for Symmetric-key encryption are TripleDES, AES128 and CAST5 as per RFC 4880.
  3. The file may be split as necessary if, once compressed and encrypted it is larger than the file size limit agreed with the escrow agent. Every part of a split file, or the whole file if split is not used, will be called a processed file in this section. If files are split, a .sig file must accompany each data file. The file size limit is agreed upon during the contract process.
  4. A digital signature file will be generated for every processed file using the Registry’s private key. The digital signature file will be in binary OpenPGP format as per RFC 4880 and will not be compressed or encrypted. The suggested algorithms for Digital signatures are DSA and RSA as per RFC 4880. The suggested algorithm for Hashes in Digital signatures is SHA256.
  5. The processed files and digital signature files will then be transferred to the Escrow Agent through secure electronic mechanisms such as, SFTP, SCP, HTTPS file upload, etc., as agreed between the Escrow Agent and the Registry Operator. Nonelectronic delivery through a physical medium such as CD-ROMs, DVD-ROMs, or USB storage devices may be used if authorized by ICANN.
  6. The Escrow Agent will then validate every (processed) transferred data file.
    ICANN’s current Registry Data Escrow Spec can be viewed here: data-escrow-03 mapping-00

Q. How will I know that the escrow deposit was successfully received?

A. Within twenty-four hours after a deposit is received, Iron Mountain will validate that the data file set is complete, accurate, and delivered in the intended Extensible Mark-up Language (“XML”) format. The deposit receipt process will validate the integrity of the data using the private decryption keys to unlock and decompress the files, authenticate the digital signatures (i.e. that the data file set actually came from the registry operator) and measure the file sizes. Once this verification process is complete, Iron Mountain will then re-encrypt the file set and move the deposit materials to a back end server within the Iron Mountain private network. Following each successful deposit transmission, an email will be sent to both the registry operator and ICANN as confirmation of each deposit noting the existence of the deposit and the file size. In the case of ccTLDs, the email confirmation is only sent to the Registry Operator.

Q. How will I know if there is a problem with my escrow deposit? What happens then?

A. If there is a problem with the escrow deposit, a notification email is sent to the Registry Operator and ICANN noting the unsuccessful receipt. It will then be the Registry Operator’s responsibility to rectify the problem and retransmit a new deposit. In the case of ccTLDs, the email confirmation is only sent to the Registry Operator.

Q. How often will I receive a confirmation report?

A. Notices go out after each deposit is received. Since Registries are required to deposit daily, there is a confirmation email sent each day.

In addition, at the end of the month, a report is sent which includes a deposit summary for the previous month and a copy of each results file. The Registry Operator and ICANN receive both the daily emails and monthly reports for gTLDs. In the case of ccTLDs, the email and report are only sent to the Registry Operator.

Q. If a Registry Service Provider is managing the registry for a Registry Operator, are they involved in the process? Can both parties get the notifications?

A. Registry Service Providers would be responsible for uploading data for the Registry Operator and should be listed as an additional contact for sFTP-related activity. Registry contact information is provided using the Registry Data Escrow Setup Form, so the Registry Operator will be responsible for specifying the recipients of deposit-related notices.

Q. What happens if I miss escrow deposits?

A. Missing escrow deposits are considered a breach of the Registry Data Escrow Agreement as well as the Registry Agreement. As such, missing escrow deposits can invoke the remedies set forth under the Registry Agreement as well as the release process set forth under the Registry Data Escrow Agreement if corrective action is not taken immediately. Iron Mountain is required to log escrow deposit activity, and we will contact you if we do not receive your deposit as scheduled or if there are problems with the deposit. All deposits — including missed and failed deposits — are reported to ICANN. However, in the case of ccTLDs, ICANN is not notified.


NCC Group Software Resilience has acquired Iron Mountain’s Intellectual Property Management (IPM) business. For more information on the acquisition, please visit our dedicated information hub, or contact Iron Mountain IPM.

Get in touch

Skip to navigation Skip to main content Skip to footer