Onboarding Information Request

This article needs attention. Please help improve it by revising the article in accordance with ICANNWiki's content guidelines. In particular, ensure a neutral point of view and proper sourcing of information.

back to New TLD contracting

Below is an example of further provisioning for delegation, sent by ICANN after RA execution and to be provided before delegation, and concurrently with PDT. Applicant specific information and IP Addresses and similar information have been omitted.

Dear Registry Operator,

As you proceed towards the transition to delegation phase for the above referenced string, there are items that must be completed. The outstanding items are listed in the below table and the following pages provide instructions for each item. These items may be completed concurrently with the pre-delegation testing phase but must be completed prior to entering the transition to delegation phase. If offering IDNs, please submit your documentation to IANA according to the instructions below upon delegation of your TLD in the public DNS root zone.

Please provide the requested information directly in this document. To ensure the requested data is securely transmitted to ICANN, once you have filled in all of the requested information please respond to the same customer portal case and attach this document.

The requested information should be provided after the ":" or in a new line. The file should be a saved as a text file, ICANN will use an automated software to process your request.

Please know, ICANN is prepared to support you as you finalize the below list of items. If you have questions or require assistance, please do not hesitate to directly contact one of the Registry Services team members listed below.

Registry Services Team Members

Krista Papac Director, Registry Services [Information Omitted]

Wendy Profit Product Manager, Registry Services [Information Omitted]

GENERAL

Please, specify if this is the initial request after delegation or if you want to update the information.

00. Type of request (initial or update):

If the "Type of request" is "update", please specify which sections are updated.

01. ZFA (yes or no): 02. BRDA (yes or no): 03. Data Escrow (yes or no): 04. URS (yes or no): 05. SLA Monitoring (yes or no):

ZFA

Zone File Access for <tld>

Pursuant to Section 2 "Zone File Access" of Specification 4 of your Registry Agreement, please follow the steps below.

Step 1. The Registry Operator's designated Centralized Zone Data System Point of Contact (CZDS POC) (requested and provided during initial on-boarding) must create a user profile at https://czds.icann.org.

Registry Operator hereby requests that CZDS grant the following user "Super Manager" permissions. Registry Operator hereby acknowledges that the person identified below has authority to enter into the “Terms & Conditions Centralized Zone Data Service agreement on behalf of the Registry Operator.

Username and email (as registered in CZDS):
06. Username:
07. Email:

Note: Super Manager is the Registry Operator's CZDS Administrator for the TLD and is able to approve or deny requests for zone data and set up other Registry Operator users for the TLD. The Super Manager will need to accept the standard service terms for the CZDS. ICANN will then promote your designated CZDS POC to "Super Manager" and associate them with your TLD. ICANN will email notification to the CZDS POC that s/he has been promoted to Super Manager.

Step 2. Registry Operator will use the following method for zone data delivery (choose one):

08. Please specify the method for zone data delivery (AXFR or SFTP):

If you specified AXFR, please complete 09 and 10, continue on 13.
If you specified SFTP, please complete 11 and 12, continue on 13.

Choice 1: Direct Download (CZDS provider performs zone file transfer and converts to required data format). Registry Operator allows ICANN to use the zone file downloaded with this method for the purposes pursuant to Section 2 " Zone File Access" of Specification 4 of your Registry Agreement.

09. TSIG Key:

10. DNS server from which the zone transfer will originate:

Or

Choice 2: Registry Operator provides access to its zone files itself to the CZDS users

11. SFTP Server Name:

Note: Per Section 2.1.3 of Specification 4 of your Registry Agreement, ICANN is going to add a CNAME record "<tld>.zda.icann.org" pointing to your SFTP server above, if choice 2 was selected.

Step 3. If Choice 1 "Direct Download" was selected above, Registry Operator must whitelist the following ICANN IP addresses for the zone file transfer: [Information Omitted]. When "Direct Download" is selected ICANN will run a zone transfer

(AXFR) test and notify Registry Operator once the test transfer of zone data was successful and ready for use.

Zone File Access for <tld> Continued

Step 4. If Choice 2 was selected above, please provide access to the SFTP URI ICANN will periodically access to download your registry Zone Files for the purposes pursuant to Sections 2.3 and 2.4 of Specification 4 of your Registry Agreement. The SSH public key for authenticating ICANN can be found at https://zfa.icann.org/icann-zfa-key.pub and at the end of this section. Please, provide the URI that ICANN will use for accessing the zone file.

12. SFTP URI:

Finally, once your TLD has been delegated in the public DNS root zone, you may begin receiving zone data requests in CZDS. You may opt to receive email notifications from CZDS. If you choose this option, you will be notified by email every time there is a request from an end user for your TLD's zone data. If you opt out of email notifications, it is the responsibility of the Registry Operator to periodically login and check for new requests.

icann-zfa-key.pub:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAgEA1X6PPYjNKNyyEFVY0LUhYuDqXp5YlVV8xWhcvA+8L0EMkD6rwdapfVHl0QWm2Wns9ltBBS1pfZlZblhQwD/h5ux+KlFLbrRWXmCXXzUZwPaLW6WEvxYTvC5T63MI0z0+YvOYcvk6ImAYEs5sgtlYjs79s/yvsmqXN7Sy33A3RLseAIumSdrKvv11brbAdcPTtmflsOrZdlKieHIkMTli5xu3blIa9JVnZHU8HDM5LUnyhB56hl6utYNKXvqtunw9KKChC06Di4cVvh36D0uZH55pWPPH+fG0h9Q7UA++in1Z+AxPwKKuzRykUyyjaGgVxleQsEsODCapccYAkxcmXWKVnU/fID7cJwMZRzl7VxvtHS7UJ54NzRwNoeAGdruugzNdZ68ckMe9gO7Kkvfzi+SfMbqLg58WHwu2mKuVW1X0hgQJobSLL1QO8pni4GK0wksi/fkMFwIOyV/VG2/Nxpr727kJb5AjMP7TxWOv71C5964GtSP199IPVlJSY71Fnz/ucIusik5w9cj4Y2J3rVY/xI0VTWHPBo3VLtXVDutu1lvnzAFACW/8W6zzxsL+FfpPY7191NJc8Veb8r1ZRGwIoBBxhqmG8yX5wymNxcMkA5MH6AgsdVpRB/aV6WNhD8o0+B39Z8G4iLdCFvOa2e6M7Jfh/fs+nJDALC5PJVs= ICANN-zfa-key

BRDA

Bulk Thin Registration Data Access to ICANN for <tld>

Pursuant to Section 3 "Bulk Registration Data Access to ICANN" of Specification 4 of your Registry Agreement, please provide access to the SFTP server to be used by ICANN to periodically download bulk Thin Registration Data. The SSH public key for authenticating ICANN can be found at https://brda.icann.org/icann-brda-key.pub and at the end of this section. Registry Operator must whitelist the ICANN IP addresses listed in the zone file transfer section above.

Please, provide the URL for periodic download of data.

13. SFTP URI:

The bulk Thin Registration Data file must be encrypted and compressed as described in Specification 2. The PGP public key that you must use to encrypt the bulk Thin Registration Data file can be found at https://brda.icann.org/icann-brda-gpg.pub and at the end of this section. Registry Operator must provide the PGP public key used to sign the bulk Thin Registration Data file.

38. PGP public key used to sign the bulk Thin Registration Data file:

Please provide the day of the week (Mo=Monday, Tu=Tuesday, We=Wednesday, or Th=Thursday) that ICANN should retrieve the bulk Thin Registration Data (BRDA) file from the SFTP URI specified in question 13.

39. Day of the week that ICANN should retrieve the BRDA file:

icann-brda-key.pub:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAgEAu/fLUtokqBNDwc1G+MEe0LEEAmgllNEMwE84qXR+AfSBvF4iwcFoIi0KH92L5QJ2ZRqbf6OoMkxsaTLQx92JxCvahRW4rT2P8EQJ5J28fDmPVsEXEjEw59hwE3raPmJfkV7G6M5D/llUM1gVuOLBtkpwxN1mLE1DBn8ns9SAUkRD+epwt1THpwlI7V20mK/Iefu31mzIyjI/UDFPwXhM4+OwdIinqNrB1thbXi1UfU/TH1RM+jVAg0ouHm5NgCQnSDLDTe8uyzyTINJKtihb+E0lXvZ+FMwWoHgsvumCFwql1yo4jQctcqjTrV5a/HGVJ/yC/07QyH0/NeRq0aHSq/GdmgI14A9sN8UKest7RLUtbAxRHyOtRxg1TLNF4K13aUI+RkFRYsKGije/kj++ldd/PryC6CzMq8+7QfcZrWD8FIjEbxCMnEYyrPsCioHcDxsxRNAFTnTEj8wGnRPblY2rlIvxbrWSyCSKITi9QgtUV62UefowQXE5+w13o4r7JX8Vqxx+CpO4PGl331amwkLHanuMuErVhUjnTmK8ntn3AncYn4nRfKTMF247Ul7S1mJCQla2CIGdNIWZI4IkODH/b+YdR51xFTn2jJZsYP+qWpRoGy0UXsh4/EJzeFMZxQw9skaS6HdgiAhKthrJ8tMtT0p+z0fNEiJJZaiCgI0= ICANN-brda-key

icann-brda-gpg.pub:

BEGIN PGP PUBLIC KEY BLOCK

Version: GnuPG v1.4.5 (GNU/Linux)

mQMqBFKNO4gRCACaYBK8tozD6Sz0jtR/iqTSgPs9hdRtVqhOyAmMcXLpwEUTUp5c 1ldO/YSPl+bQgotrMhFylYNmpVAM+/FpXw0VwTi+Lh0JvMwrKcOn2YU8tVO3Oq4U 0eAdXZcfxaW095e+sOS+yUUkianNo0sKa68Ae3IS7vd/MYpZcEvVEKPPIn2sOdnZ FUrJQ5kz7Hyak3D1+bRMXo0TU1xcoMl38trLiCTvD/pKgt/2te/3DiWj+Eu5aRMd /9k14YBeEGqVi12OlCIN2vlyX3XH21tH9FjCadDvBcPkavCWfgGA+3xI5I0mW/B3 tWQIHe3O8nafUyolCGkw7d3xAfzhHUK192H3AOCJI58rb1qiwZ+5FMvGjn+o8iCw KWOSxQfT1Gw9CACNpAjFwkvxgeRb5KFiDLcPFwIWdGSh4SLNhFwn7Ga/8Sc26WQh OkL+j0xeKDKS30j07MDJJFxhykWLqLNySpFt+E/g9wDP6JhG7qkT3rDR79D83bD3 CMH3pGhIkGtQewlhQOyBLu16djtquMijrmoim8VfsRWLJJnAK0oTkY2UZDpqCe3J 6B3gdfowB98FCbFa5A2coIfOvkhB892zeYM5Gb5twyVmO5jWK4AtowEnFkItfJz5 0Q2KEH/KX6aoLP4llvRWBEixmdSmRN7HIKIYIh+fMHAimuijer2isJYsqWmPkEz4 KTmGhzU1B8kQzyiI+s2fAj+LUQaOQLkb8GW8B/9dtTfvEbMXmhp5+KzEfvFFlzhB bxA3+kTLE/kf4ty0Fs+BQAypvXL52N1x44h7cecFRwf8M49tII2RlW3fAQmGQTVO ovFpuQyoC2TkPWkRkpqnEaBHk6ZqxbRgnWwKwFgxJ6+rHL3b1RxVKmwYp/pb9hYh G4ikMWvSsekc4+52nTIKXZuFRDnc0whLaE41UeXbQ5MqqnFJjUMp8oLSJ6isjkV5 JsVdSt1zi8nQeXNFi+oVz8neP9yxJpLl5LM1BDta0+A6BtpG5fB1xCk3m1SQbTqf Xxf3rdM0qWuNcM1fTkSd4dtHSiq3MZQsgGJDHS2jwMhvz4Fey/QIcv20bS3YtC9J Q0FOTi1CUkRBIEVuY3J5cHRpb24gS2V5IDxicmRhQGJyZGEuaWNhbm4ub3JnPohw BBMRCwAgBQJSjTuIAhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQbM2k+XaS EHMnCQDfQ6zQ6Erpr3ScvLfaDp1NIjbeuJH7xNC5oPKyxgDcD+Kv8PPvkJDxYJcj UcCsBp1vblXO79H2O+n+DbkCDQRSjTuLEAgAtbDSzagHYUKjj5VgxhgXtxdHoY2z aFJTjErGnB8pTKBbqqXt0Km9BkTCrUXqlFtbick+LH+g9PZfbVD7w6hg2TWkHGrP H+nltwQY1oKso2VDov89CkcRJzGuoAvEIpcG1vGyCk1juBtLMLgLcPLhYbBPAc7d B5p3RwU1Ms6oBjTmLH7kC6uwURUeT+D03RoHfvZ3dh4r2L3KmJ7b3ocPlA52azsg ysbiCa3+ynIT+DwS+Mdkbh5RhnColkS2dtq2GgZChUdzBtm6WgWTwXoq5gk/SWVf Tluc0ShxJYC2wkGIKdoWtF/Xj5a/ft7/O/lcC6ZXBJ/ztdLo0+nRPsA8ewADBQf+ N1ANVTuuh48YJfZhupWLoT4TiAMQ65FRjhjGwzHFep4qEcwZ570BTjx+03+wgYlS yeHYz5BtmHLXEHvlOpjH9M+xHsPfeWwoMad53I96qO4rFUoTzighMwlAYSn9Evv2 FURtJgyf4ts4jjP5mxMP2bnOu737RVatspEzpCkrOOwvl35/kJy0uOcgpO06AgCH hoGVo0nsJUJCSFHKNFK5saff/EOP5OC2OD1Keqpz+oFu12VzzrjbTyjoSDzTMsgP v8exlQgVNprEjnj0nhKKdR72lXF4lEV6k384sGjxyHuJiobgTDNmztnEhIahJQNG 1OB7uIagdKe5+BLpRNQoBIhZBBgRCwAJBQJSjTuLAhsMAAoJEGzNpPl2khBz76sA 3iFkKDsWDTLG11rb0MwvHiimVSm0AJTEJxGGnsQA3iuzATIDymzTjE6cHq10xEbN uExx/MXxH1WuDeU= =/KZN

---

END PGP PUBLIC KEY BLOCK-----

RRI

Data Escrow Registry Reporting Interface for <tld>

Pursuant to Specification 2 of the Registry Agreement, you are required to send data escrow reports and your data escrow agent is required to send data escrow notifications related to your periodic data escrow deposits.

Please provide (below) ICANN with the password for the registry account and a password for your data escrow agent. Please note that credentials for data escrow agents and registries are defined by TLD. Additionally, note that the usernames are provided below.

You also need to provide the IP addresses of the Registry Operator and Data Escrow Agent that will originate connections to the ICANN Registry Interfaces.

Please fill in the information below in order to have access to the production environment of the ICANN Registry Interface.

Registry Operator:
Username:
14. Password:
15. IP 1:
16. IP 2:
17. IP 3:
18. IP 4:
19. IP 5:

Data Escrow Agent:
Username:
20. Password:
21. IP 1:
22. IP 2:
23. IP 3:
24. IP 4:
25. IP 5:

URS

Uniform Rapid Suspension (URS) for <tld>

Pursuant to the URS Technical Requirements, please provide the PGP Key for the URS point of contact (Registry Operator or Back-end Registry Operator if applicable) related to the email address that will communicate with URS Providers. Per the URS Technical Requirements, emails sent to URS Providers must be signed with this PGP key.

The PGP key size must be of at least 2048 bits. The PGP public key must be provided in ASCII-armored format (for example, in order to generate an ASCII-armored file in GnuPG, the following command could be used: gpg --armor --export <email address>).

Only one PGP public key must be provided per TLD, if you are the Registry Operator or Registry Service Provider for several TLDs, you may provide the same PGP public key for several TLDs.

26. PGP public key of URS point of contact:

Please fill in the information below in order to have access to the URS Provider PGP keyring file and the list of Registrar's contacts.

Username:
27. Password:

EPP

EPP Extensions for <tld>

36. Have you implemented EPP extensions for this TLD (Y/N):

If Registry Operator requires the use of functionality outside the base EPP RFCs, pursuant to section 1.2 of Specification 6 of your registry agreement, Registry Operator must document EPP extensions in Internet-Draft format, i.e., plain text (see, http://www.rfc-editor.org/formatting.html) following the guidelines described in RFC 3735. If that is the case, please provide the relevant documentation of all the EPP Objects and Extensions as a SEPARATE attachment to this customer portal case.

Each EPP extension should be in a separate text file named using the following convention: <tld>_<registry-operator>_epp-extension_<extension-name>_v<dd>.txt, for example, xn--91btfiec_acme-inc_epp-extension_auctions_v01.txt

37. Are you going to use draft-tan-epp-launchphase in order to comply with the RPM requirements of new gTLDs (Y/N)?:

Note: If your response was affirmative for question 37, there is no need to include the documentation of draft-tan-epp-launchphase.

IDN

IDN Tables for <tld>

Pursuant to section 1.4 of Specification 6 of your registry agreement, if Registry Operator offers IDN registrations, Registry Operator shall publish and keep updated its IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices as specified in the ICANN IDN Guidelines. If offering IDNs, upon delegation of your TLD in the public DNS root zone, please submit your documentation to IANA by following the instructions at: http://www.iana.org/procedures/idn-repository.html

SLA MONITORING

EPP SLA Monitoring <tld>

Pursuant to Specification 10 of your registry agreement, ICANN requests Registry Operator to provide access to its EPP system for the purposes described in said specification. Please fill in the access data required by your EPP system below. If Registry Operator has other access requirements (e.g., digital certificate from a specific CA, EPP extensions that are required by default to execute, info, create and update commands on domain names), please describe in the other requirements section below.

ICANN's SLA monitoring system EPP client will use registrar id [Information Omitted], and will connect from the following IP addresses: http://www.icann.org/registries/ry-sla/ry-sla-monitoring-nodes-epp.txt (also listed at the end of the document). Transactions reported for registrar id [Information Omitted] will not be considered billable transactions.

Note: if you don't support EPP over IPv6, you can ignore the IPv6 addresses.

ICANN will use a x509 certificate for establishing TLS with the EPP server, the default certificate is signed by a well-known public CA. The common name (CN) in the x509 certificate is: eppclient.tld-monitor.icann.org. If you use a private CA, please tell us about in the "Other requirements" section, in order to send you the CSR for eppclient.tld-monitor.icann.org.

28. Registry Operator's EPP Server 1 (FQDN):
29. Registry Operator's EPP Server 2 (FQDN):
30. Registry Operator's EPP Server 3 (FQDN):
31. Registry Operator's EPP Server 4 (FQDN):
32. Registry Operator's EPP Server 5 (FQDN):


33. EPP Username:
34. EPP Password:

35. Other requirements:

List of IP Addresses:

[Information Omitted]

--- EOF ---

Internet Assigned Numbers Authority

Top-Level Domain

Request For Comments

Internationalized Domain Name