Onboarding guide for new gTLDs operated by Afnic - .fr · PDF fileONBOARDING GUIDE FOR NEW...

ONBOARDING GUIDE FOR NEW GTLDS OPERATED BY AFNIC – July 23rd, 2013 1

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Onboarding guide for new gTLDs

operated by Afnic

.alsace, .aquitaine, .bzh, .corsica, .paris

- Version 1 - July 23rd, 2013




C o n t e n t s

1. Integration background .................................................................... 4

2. The major multi-TLD technical options ............................................ 4

2.1. Dedicated automated access per TLD ......................................................... 4

2.2. Pooled access for easy management of all TLDs ....................................... 4

2.3. Additional services for each TLD ................................................................. 5

2.4. Everything is standard! ................................................................................. 7

3. EPP ..................................................................................................... 8

Operations possible for the domain object: ........................................................ 8

Operations on contacts ......................................................................................... 8

Operations on hosts .............................................................................................. 8

4. RDDS .................................................................................................. 9

4.1. Whois .............................................................................................................. 9

4.2. Zonefile access .............................................................................................. 9

5. DNS..................................................................................................... 9

6. IPv6 ................................................................................................... 10

7. Sunrise ............................................................................................. 10

8. Accreditation ................................................................................... 10

9. Invoicing .......................................................................................... 11

10. Naming policy ............................................................................. 11

10.1. Syntactic constraints................................................................................... 11

10.2. Semantic constraints................................................................................... 11

10.3. IDN Management .......................................................................................... 12




10.4. Management of authorization codes .......................................................... 12

11. Access to the .next integration platform ................................... 13

Appendix 1: Table of IDN characters .................................................. 14

Appendix 2: Glossary .......................................................................... 16




Onboarding Guide for new gTLDs operated by Afnic

.alsace, .aquitaine, .bzh, .corsica, .paris

1. Integration background Technical integration with Afnic allows users to register domain names with the .alsace, .aquitaine, .bzh, .corsica, and .paris gTLDs. Afnic has adopted a certain number of technical options described in this document for the similar and effective integration of all these gTLDs. In addition, to allow you to test your integrations, a generic platform has been implemented on the basis of a fictitious TLD: the .next. This platform is available for beta testing and already allows you to test all the services that will be available for each of the five new gTLDs managed by Afnic. This guide will therefore use the .next TLD in all the examples and URLs given; all you need to do is replace the .next with the ".tld" you want in order to have the appropriate example or parameters. In addition, the terms describing the operations and objects handled ensure an exact correspondence with the EPP commands described in the RFCs.

2. The major multi-TLD technical options

2.1. Dedicated automated access per TLD

In order to make your operations more secure and more reliable, the basic services for each TLD are dedicated except for DNS publishing. For example, for each TLD there is a dedicated epp.nic.next service, a dedicated whois.nic.next service, and a dedicated extranet.nic.next service.

2.2. Pooled access for easy management of all TLDs

For the web interfaces, a slightly different option was taken in order to simplify the work of operators. The extranet for each TLD will be available via its dedicated URL extranet.nic.next but a common portal will enable fast switching from one extranet to another.




In addition, a Single Sign On service (SSO) is being studied to avoid an agent with Afnic rights on several TLDs having to sign on again each time s/he changes namespaces. Finally, you can manage your Afnic customer account via the pooled extranet in order to simplify the management of some of your contacts.

2.3. Additional services for each TLD

Based on the positive feedback received for these services under the .fr TLD, for each gTLD Afnic is providing additional services that make TLD management easier:

• a complete set of sandboxes (epp.sandbox.nic.next, whois-sandbox.nic.next, extranet-sandbox.nic.next) to test your interfaces for each TLD

• a dedicated operational communication site for the Service Level Agreement (SLA), for the maintenance and future launches of new services.

• Web access to your bills and online payment system • access to the statistical data of your portfolio

Finally, a web-based whois with reverse lookup functions will also be available (and available to the general public) (www.nic.next/whois) with limitations to prevent any abuse of the service.

http://www.nic.tld/whois




2.4. Everything is standard!

Afnic has opted to deploy a standard EPP as simple as possible. No "exotic" TLD is to be expected. The only two extensions needed to operate are:

• the extension for DNSSEC management: DNSSEC EPP version 1.1 as defined in RFC 5910,

• the Launch Phase Mapping extension for Sunrise management in the standardization phase (currently v11 - http://tools.ietf.org/id/draft-tan-epp-launchphase-11.txt)

The life cycle of the domain name is also completely standard. It includes the management of all the existing EPP states and the management of Grace Periods.

http://tools.ietf.org/id/draft-tan-epp-launchphase-11.txt





3. EPP Access to EPP will therefore be available for each TLD at the following URLs:

• epp.nic.next for access during production • epp.sandbox.nic.next for access to the sandbox.

For a given TLD, two connections are available for each Registrar. For a given TLD, a dedicated certificate must be sent and installed by Afnic in order to log on. The same certificate can be used for each TLD. For a given TLD, two IP addresses will be allowed to connect to the server. All domain, contact and host objects are managed and all the operations typically available for gTLDs are available with the .next test TLD:

Operations possible for the domain object:

• create possible from 1 to 10 years, • renew possible from 1 to 10 years, • Grace Period of 5 days for create and renew operations; 45-day grace

period for auto-renew operations, 5-day grace period for transfers, • 30-day redemption period followed by a Pending Delete period of 5 days, • restore

The use of an auth_info is required for transfer operations. The same auth_info may be necessary during a create operation in the case of the creation of a reserved domain name. The management of authorization codes, similar to that for the .fr TLD, is explained later in this document.

Operations on contacts

• create, • update.

Operations on hosts

• create, • update, • delete.

A DNSSEC configuration can be entered during the update if the Registrar has chosen to implement the DNSSEC extension using the DS data interface (secDNS: dsData) of section 4.1 of RFC 5910.

Glues are authorized.




The monthly Service Level Agreement (SLA) on the EPP interface is the one specified by ICANN:

• EPP availability ≤ 864 min of downtime per month (≈ 98%), • performance of EPP commands of session type ≤ 4000 ms, for 90% of

commands • performance of EPP commands of query type ≤ 2000 ms, for 90% of

commands, • performance of EPP commands of transform type ≤ 4000 ms, for 90% of

commands.

4. RDDS

4.1. Whois

The whois will be available on port 43 at whois.nic.next during production and whois.sandbox.nic.next for the sandbox. The whois is subject to the following rate-limiting rules:

• 7,200 queries ⁄ 24 hour ⁄ IP. The use of the contact:disclose field is possible via the EPP interface. It is not enabled by default in the Whois publication even if the EPP interface can be used to retrieve this information. The Whois is updated in real time and the result of an EPP operation is immediately visible in the Whois. The monthly SLA commitment on the Whois interface is that specified by ICANN:

• availability of the whois on port 43 ≤ 864 min of downtime per month (≈ 98%)

• performance of a whois query on port 43 ≤ 2000 ms, for at least 95% of the queries

• update of the whois ≤ 60 min, for at least 95% of the probes

4.2. Zonefile access

The Zonefile access procedures are those specified by ICANN.

5. DNS DNS publishing will be on all three of the Anycast clouds already used for the .fr TLD: d.nic.fr, f.ext.nic.fr, g.ext.nic.fr.




DNS publishing occurs every 10 minutes.

The monthly SLA commitment on the DNS service is that specified by ICANN: • DNS service availability = 100%. • DNS service availability per server = 432 min of downtime per month (≈ 99%). • Performance of a DNS query on TCP ≤ 1500 ms, for at least 95% of the

queries. • Performance of a DNS query on UDP ≤ 500 ms, for at least 95% of the queries.

6. IPv6 All the services described above are fully available in IPv6 and enables the handling of IP IPv6 when the object allows.

7. Sunrise Sunrise policies are still being developed by each registry. They will be based on the Launch Phase Mapping EPP during the standardization phase (currently v11 http://tools.ietf.org/id/draft-tan-epp-launchphase-11.txt)

8. Accreditation Afnic will accompany you during the technical test stage of your accreditation. The technical tests for the "general availability" phase, once passed, will be validated for all the TLDs managed by Afnic. The registrars that are allowed to be accredited are registrars accredited by ICANN, having stated to ICANN their wish to be accredited for TLDs managed by Afnic. The detailed accreditation rules for each TLD managed by Afnic will be specified later, with particular regard to the sunrise period.





9. Invoicing No pre-payment is expected for TLDs managed by Afnic. Invoicing will be by Afnic or directly by the registry. Unit price and promotion information will be specified during the pre-launch phase for each TLD. In the case of TLDs for which Afnic does the billing, the invoices will be available on the extranet and payment may also be made via the extranet by bank card or bank transfer. All currencies are accepted.

10. Naming policy

10.1. Syntactic constraints

A certain number of syntactic tests are performed:

• test on the correct number of labels (maximum 2) • test to ensure that the character string "-" is not present in position 3 and 4 to

protect xn-- and the future ACE prefixes, • test to prevent the "-" character in the head or the tail of the domain name, • test to find ASCII characters that are neither letters nor digits, or the "-"

character, • test to find invalid IDN characters (see below). • validation test for the syntax of IP addresses, • ipv4-addr [1-255](\.[0-255]){3,3} • ipv6-addr [a-fA-F0-9:]+(:?ipv4-addr?) • validation test of telephone numbers and e-mail addresses, • Tel num \+[1-9][0-9]{0,3}?sp?[1-9]([?sp?\.-]?[0-9])+ • Fr tel num \+33?sp?[1-9]([?sp?\.-]?[0-9]){8} • e-mail

(([^\s\(\)\[\]\.\\??,;:?@]+(\.[^\s\(\)\[\]\.\\??,;:?@]+)*)|(?[^?@\\\r\n]+?))@?label?(\.?label?)*

10.2. Semantic constraints

Test to prevent the creation of a domain name reserved (by ICANN, the registry) without a specific authorization code.




10.3. IDN Management

The TLDs operated by Afnic make it possible to register accented domain names. For all of the TLDs there will be a table of common characters, a subset of the Latin script. The exact table is attached to this document. It should be noted that an additional character exist for the .bzh: the barred k from the Latin Extended-D corresponding to the identifiers U+A743, and U+A742.

10.4. Management of authorization codes

Creation requests with authorization code are made via the extranet. The outlines of the procedure are as follows: Entry via the extranet of a request for an authorization code for the Registrar:

• for the domain name in question, • for the required id of the holder that has been previously created.

Supporting documents are not required for the issuance of the initial request. Once the request has been made, a registration number is allocated to it and posted on the page as well as the requested domain name, the NIC handle of the future holder, the date and exact time of the request. Public information on requests received and their real-time tracking will be available The processing of applications is done in chronological order with the allocation of an authorization code usable for the next 15 days. If the code is not used, or if the request is rejected, the registry abandons the current request and examines the following request for the same term. After a reserved domain name has been deleted, it returns to the list of reserved terms.




11. Access to the .next integration platform All the technical access operations proposed in this document can already be tested on a generic integration platform for a fictitious TLD: the .next. You can access all of the EPP, extranet, and whois services, and perform tests on domain names with the .next TLD. For obvious reasons, this TLD is not announced in the root; access to the services cannot be performed using the .next and uses the following aliases: epp.next.nic.fr, whois.next.nic.fr, extranet.next.nic.fr The platform is open-ended. It is there in particular for you to test the services on offer and to feed back any bugs as well as your wishes for additional features. Use it and abuse it! Your customer service representatives are fully at your disposal to consolidate your feedback on the platform and answers about potential changes in the functional roadmap will be quickly provided.




Appendix 1: Table of IDN characters

# Code point Glyph Name ASCII

equivalent 1 U+002D - HYPHEN-MINUS SIGN - 2 U+0030 0 DIGIT ZERO 0 3 U+0031 1 DIGIT ONE 1 4 U+0032 2 DIGIT TWO 2 5 U+0033 3 DIGIT THREE 3 6 U+0034 4 DIGIT FOUR 4 7 U+0035 5 DIGIT FIVE 5 8 U+0036 6 DIGIT SIX 6 9 U+0037 7 DIGIT SEVEN 7 10 U+0038 8 DIGIT EIGHT 8 11 U+0039 9 DIGIT NINE 9 12 U+0061 a LATIN SMALL LETTER A a 13 U+0062 b LATIN SMALL LETTER B b 14 U+0063 c LATIN SMALL LETTER C c 15 U+0064 d LATIN SMALL LETTER D d 16 U+0065 e LATIN SMALL LETTER E e 17 U+0066 f LATIN SMALL LETTER F f 18 U+0067 g LATIN SMALL LETTER G g 19 U+0068 h LATIN SMALL LETTER H h 20 U+0069 i LATIN SMALL LETTER I i 21 U+006A j LATIN SMALL LETTER J j 22 U+006B k LATIN SMALL LETTER K k 23 U+006C l LATIN SMALL LETTER L l 24 U+006D m LATIN SMALL LETTER M m 25 U+006E n LATIN SMALL LETTER N n 26 U+006F o LATIN SMALL LETTER O o 27 U+0070 p LATIN SMALL LETTER P p 28 U+0071 q LATIN SMALL LETTER Q q 29 U+0072 r LATIN SMALL LETTER R r 30 U+0073 s LATIN SMALL LETTER S s 31 U+0074 t LATIN SMALL LETTER T t 32 U+0075 u LATIN SMALL LETTER U u 33 U+0076 v LATIN SMALL LETTER V v 34 U+0077 w LATIN SMALL LETTER W w 35 U+0078 x LATIN SMALL LETTER X x 36 U+0079 y LATIN SMALL LETTER Y y 37 U+007A z LATIN SMALL LETTER Z z




38 U+00DF ß LATIN SMALL LETTER SHARP S ss 39 U+00E0 à LATIN SMALL LETTER A WITH GRAVE a 40 U+00E1 á LATIN SMALL LETTER A WITH ACUTE a 41 U+00E2 â LATIN SMALL LETTER A WITH CIRCUMFLEX a 42 U+00E3 ã LATIN SMALL LETTER A WITH TILDE a 43 U+00E4 ä LATIN SMALL LETTER A WITH DIAERESIS a 44 U+00E5 å LATIN SMALL LETTER A WITH RING ABOVE a 45 U+00E6 æ LATIN SMALL LETTER AE ae 46 U+00E7 ç LATIN SMALL LETTER C WITH CEDILLA c 47 U+00E8 è LATIN SMALL LETTER E WITH GRAVE e 48 U+00E9 é LATIN SMALL LETTER E WITH ACUTE e 49 U+00EA ê LATIN SMALL LETTER E WITH CIRCUMFLEX e 50 U+00EB ë LATIN SMALL LETTER E WITH DIAERESIS e 51 U+00EC ì LATIN SMALL LETTER I WITH GRAVE i 52 U+00ED í LATIN SMALL LETTER I WITH ACUTE i 53 U+00EE î LATIN SMALL LETTER I WITH CIRCUMFLEX i 54 U+00EF ï LATIN SMALL LETTER I WITH DIAERESIS i 55 U+00F1 ñ LATIN SMALL LETTER N WITH TILDE n 56 U+00F2 ò LATIN SMALL LETTER O WITH GRAVE o 57 U+00F3 ó LATIN SMALL LETTER O WITH ACUTE o 58 U+00F4 ô LATIN SMALL LETTER O WITH CIRCUMFLEX o 59 U+00F5 õ LATIN SMALL LETTER O WITH TILDE o 60 U+00F6 ö LATIN SMALL LETTER O WITH DIAERESIS o 61 U+00F9 ù LATIN SMALL LETTER U WITH GRAVE u 62 U+00FA ú LATIN SMALL LETTER U WITH ACUTE u 63 U+00FB û LATIN SMALL LETTER U WITH CIRCUMFLEX u 64 U+00FC ü LATIN SMALL LETTER U WITH DIAERESIS u 65 U+00FD ý LATIN SMALL LETTER Y WITH ACUTE y 66 U+00FF ÿ LATIN SMALL LETTER Y WITH DIAERESIS y 67 U+0153 œ LATIN SMALL LIGATURE OE oe




Appendix 2: Glossary

• Sunrise: Priority registration period during which rights holders can register their domain names before the general opening of a top-level domain or second-level domain to the public.

• Grace period: period following a billable transaction on a domain name, during which a registrar may delete the domain name and obtain a refund.

• IDN: IDN means "Internationalized Domain Names". Originally, domain names (or to be more precise, machine names, since a domain name is generally reserved to declare machines) could only comprise a subset of ASCII characters. "International" or "internationalized" domain names are those containing characters other than ASCII characters (e.g. Arabic, Chinese, accented characters). The standard used at AFNIC is called IDNA2008.

• Sandbox: complete test environment for use by registrars, the operation of which is strictly identical to that after go-live.

• SLA: Service Level Agreement, a commitment on the service levels of availability, performance, etc.

Onboarding guide for new gTLDs operated by Afnic - .fr · PDF fileONBOARDING GUIDE FOR NEW...

Documents

Transcript of Onboarding guide for new gTLDs operated by Afnic - .fr · PDF fileONBOARDING GUIDE FOR NEW...