Fr Technical Integration Guide - Afnic
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 1
.fr Technical
Integration Guide
- Version 4.0 -
December 12, 2016
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 2
Contents
1. Preface ............................................................................................... 6
1.1. About this document .....................................................................................6
1.2. Target audience .............................................................................................6
1.3. Typographic conventions .............................................................................6
1.4. Change record ...............................................................................................6
2. IDN ...................................................................................................... 7
2.1. Reference documents ...................................................................................7
2.2. Brief backgrounder on IDN technology ......................................................7
2.3. Warning ..........................................................................................................7
2.4. Some vocabulary ...........................................................................................8
2.5. Table of accepted characters .......................................................................9
2.6. Unicode use vs LDH use ............................................................................. 11
3. Connection settings to the interfaces ............................................ 11
3.1. EPP configuration and parameters ............................................................ 11
3.2. Extranet ........................................................................................................ 12
3.3. Certificates ................................................................................................... 12
4. Main integration principles of the EPP protocol ........................... 13
4.1. RFCs ............................................................................................................. 13
4.1.1. No integration of "host" objects (RFC 5732) .............................................................................. 13
4.1.2. Case of operations with result code 1000 and server behavior in case of problems .................... 13
4.1.3. integration choices from the list of notification messages ........................................................... 13
4.1.4. DNSSEC support......................................................................................................................... 14
5. Limitations of the EPP server and Extranet .................................. 14
6. FR Rush Service .............................................................................. 17
7. Session management commands .................................................. 18
7.1.1. ................................................................................................................................... 18
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 3
7.1.2. The command ................................................................................................................ 19
7.1.3. Session management commands ................................................................................................. 19
8. Extension frnic-1.4 .......................................................................... 21
9. Launch Phase extension................................................................. 23
10. Management of domain names .................................................. 23
10.1.Multi-year and expiry date calculation ....................................................... 23
10.1.1. Number of years available ...................................................................................................... 23
10.1.2. Rule on maximum registration period .................................................................................... 23
10.1.3. Rule for calculating expiry dates ............................................................................................ 24
10.2.Grace periods............................................................................................... 24
10.2.1. General description ................................................................................................................. 24
10.2.2. List, duration and description ................................................................................................. 24
10.2.3. Cancellation of a grace period ................................................................................................ 24
10.2.4. Credit note limit for creation .................................................................................................. 25
10.3.Qualification process (verification and substantiation) ........................... 26
10.4.Settings of a domain name ......................................................................... 26
10.5.Domain:check .............................................................................................. 27
10.6.Domain:info .................................................................................................. 29
10.7.Domain:create .............................................................................................. 31
10.8.Domain:create with authorization code ..................................................... 33
10.9.domain:update ............................................................................................. 34
10.10. Domain:transfer ................................................................................... 37
10.10.1. Request a transfer ................................................................................................................. 37
10.10.2. Approve / Reject a transfer (only for the outgoing registrar) ................................................ 39
10.10.3. Cancel the transfer (only for the incoming registrar) ............................................................ 41
10.10.4. Monitoring of operations for 2 registrars .............................................................................. 42
10.11. frnic:recover - transmission forcée .................................................... 42
10.12. domain:renew ...................................................................................... 43
10.13. domain:delete ...................................................................................... 44
10.14. rgp:restore............................................................................................ 45
9. Contact management ...................................................................... 46
9.1. Description ................................................................................................... 46
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 4
9.2. Parameters of a contact .............................................................................. 46
9.3. Contact:info .................................................................................................. 46
9.4. Contact:create .............................................................................................. 49
9.5. Contact:Update ............................................................................................ 61
10. Notifications ................................................................................ 64
10.1.Management of the notification file ............................................................ 64
10.2.Asynchronous notifications ....................................................................... 64
10.3.Exogenous notifications ............................................................................. 69
11. Result codes and error messages ............................................. 79
11.1.Result codes ................................................................................................ 80
11.2.Error messages ............................................................................................ 82
12. Operations manageable only by mail/fax .................................. 84
12.1.Notification of monitoring of the eligibility verification procedure ......... 84
12.2.Notification of suspension, blocking and deletion of domain name
portfolio ........................................................................................................... 85
12.3.Substantiation email .................................................................................... 85
13. DAS (Domain Availability Service) ............................................ 85
13.1.Settings to query the service ...................................................................... 86
13.2.Available information .................................................................................. 86
13.2.1. Domain name validity ............................................................................................................ 86
13.2.2. Availability of the domain name ............................................................................................ 86
13.2.3. Status of DNS publishing ....................................................................................................... 86
13.2.4. Information on restrictions on the domain name .................................................................... 86
13.2.5. Key dates for existing domain names ..................................................................................... 87
13.3.DAS and IDN ................................................................................................. 87
13.4.Examples ...................................................................................................... 88
13.4.1. Domain name that does not exist and is not subject to any restrictions .................................. 88
13.4.2. Domain name subject to prior review ..................................................................................... 88
13.4.3. Domain name incorrect .......................................................................................................... 89
13.4.4. Domain name does not exist and is not subject to any restrictions ......................................... 89
13.4.5. Domain name is deleted and in redemption period ................................................................ 90
13.4.6. Domain name exists but is also a term subject to prior review............................................... 90
13.4.7. Query on different domain names with different properties ................................................... 91
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 5
13.4.8. Query of an IDN in its Unicode form ..................................................................................... 92
13.4.9. Query of an IDN in its ACE form .......................................................................................... 92
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 6
Technical Integration Guide
1. Preface
1.1. About this document
This integration guide compiles all the information needed to integrate the the
application interface to manage Afnic domain names.
This interface provides two access methods:
The web interface
EPP (Extensible Provisioning Protocol): a standard protocol for exchanges
between registries and registrars.
All the operations available in the EPP are also available on the web interface.
Regarding EPP, Afnic complies with the standard described in the RFCs (cf. § 5.1
RFCs.). This document therefore merely describes the items specific to Afnic's
integration of the protocol.
1.2. Target audience
This document is a technical document for developers wishing to obtain a detailed
description of the interface and looking for examples facilitating their integration. It
does not re-detail the procedures (cf. Procedures Guide
https://www.afnic.fr/en/resources/reference/technical-guidebooks/procedures-
guide-for-registrars-1.html) or the Naming Policy
(https://www.afnic.fr/en/resources/reference/charters/) which will be considered
as known.
1.3. Typographic conventions
Throughout the document we use the following conventions:
Between < > the xml tags describing the EPP frames
In a frame on a blue background, examples of EPP frames.
1.4. Change record
24/11/2009 - V1.0
08/04/2010 - V1.1
08/06/2010 - V1.2 - Addition of missing EPP notifications
31/08/2010 - V1.3 - Addition of EPP portfolio deletion notification
19/11/2010 - v1.35 - lines 5b and 5c in § 5.3.1 Semantics of form 2.5.0: Optional instead of Mandatory
04/02/2011 - V 1.5 - Addition of DNSSEC support for EPP in server version 1.1
03/03/2011 - V1.55 - Correction of the greeting example §4.3.1
06/12/2011 - V2.0 - Deletion of email interface, upgrade of EPP interface following the opening to Europe and
the French Overseas Territories - stop of identification - opening of qualification.
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 7
03/07/2012 - V2.5 - Addition of § about IDN and DAS.
17/12/2012 - V2.6 - Deletion of ZoneCheck
25/02/2013 - V2.7 - Deletion of serverRestoreProhibited and update of address epp.sandbox.nic.fr
27/02/2015 - V3.0 - Change of domain:create, addition of domain:renew, change of domain:info
12/12/2016 - V4.0 - Redesign of the technical guide, addition of documentation on TLD extension frnic-1.4, on
certificate, on rate-limiting, on FR Rush Service, on domain:update
2. IDN
2.1. Reference documents
The implementation of IDNs at Afnic is based on the IDN 2008 standard
(IDNA2008), as per the following reference documents.
Definitions and protocol:
RFC 5890 (08/2010 23 pages): Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework
RFC 5891 (08/2010 17 pages): Internationalized Domain Names in
Applications (IDNA): Protocol
RFC 5892 (08/2010 70 pages): The Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)
RFC 5894 (08/2010 43 pages): Internationalized Domain Names for
Applications (IDNA): Background, Explanation, and Rationale
Punycode encoding algorithm:
RFC 3492 (03/2003 35 pages): Punycode: A Bootstring encoding of
Unicode for Internationalized Domain Names in Applications (IDNA)
2.2.Brief backgrounder on IDN technology
The DNS protocol was not originally defined to be restricted to a set of characters.
It is its use and other limitations of "the age" (the protocol is 30 years old) that have
resulted in the definition of the syntactic rules we know today. The purpose of the
IDNA2008 standard is to reconcile human needs and technical constraints by
allowing the use of all forms of writing in domain names. All these forms of writing
and the characters they use are defined and grouped together under a standard called
Unicode. Since the syntactic rules for domain names require the use of single letters
of the Latin alphabet ("a" to "z"), as well as numbers, hyphens, and periods to
separate labels, a mechanism for the canonical formation of Unicode domain names
and for encoding them has been developed to create names consistent with these
rules. While in applications such as web browsers, Unicode names will be
displayed, their DNS resolution will be performed using their encoded form (this is
normally transparent to the user who should not have to handle this type of domain
name).
2.3.Warning
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 8
Although the impact may seem limited, it is important to note that Afnic
implements the IDNA2008 standard, which differs slightly from the IDNA2003
standard. With regard to the treatment of characters taken into account, the German
eszett (ß) is encoded, not transformed into "ss" as in the previous version of the IDN
standard. In addition, the canonicalization step (nameprep) has been deleted, which
will have some impact on the use of our interfaces.
Each Afnic application is now free to apply its own rules on the matter, besides the
fact that Unicode domain names must be in Normal Form C, we have chosen to
allow the input of uppercase characters (but it is better to enter lowercase characters
to anticipate any changes in our IDN policy) but it is their lowercase character
equivalents that will actually be taken into account by the system (note the eszett is
only accepted in his lowercase version).
For example, the domain name "Thé-ou-Café.fr" is not legal according to the
IDNA2008 standard. However, we will accept it once it has been standardized as
"thé-ou-café.fr".
With more "exotic" alphabets than Latin, the problem will no doubt be more
complex, but as long as Afnic continues to use the characters indicated in the list
below in this document, their canonical form will continue to apply.
2.4.Some vocabulary
Unicode: Standard enabling any character in any form of writing to be
encoded in a unique fashion (Unicode on wikipedia).
UTF-8: One of the encoding formats used to encode Unicode characters.
ISO-8859-15: One of the ISO 8-bit encoding standards of the Latin
alphabet. Also known as latin9.
LatinX: Other names of certain ISO standards. Unlike Latin1, Latin9
includes the ligation "e in o".
LDH: "LETTER-DIGIT-HYPHEN" the only ASCII characters authorized
for the composition of a label in a domain name.
ASCII: "American Standard Code for Information Interchange", the oldest
computer standard for encoding characters. Strictly speaking based on 7 bits
(short for BInary digITS), it can only encode 128 characters.
ACE: "ASCII Compatible Encoding", the encoded version of a Unicode
domain name in its LDH form (xn--caf--dma in Punycode, i.e. its "A-label
form").
IDN: "Internationalized Domain Name" containing characters other than
ASCII characters alone.
Canonicalization: The canonical formation of a string of characters. For
example, in Latin, putting a string of characters in their lowercase form is
one of the operations that can be involved in a canonicalization process.
Normal Form C:: Normal form requiring that the characters be
(pre)composed. A character corresponds to a unique code point. This
exclude characters obtained by using diacritical marks combined with base
characters.
Code point: Single number associated with a character.
Glyph: Graphical representation of a character
NAMEPREP: Defines the version in canonical form of a Unicode domain
name (was part of IDNA2003, no longer exists in IDNA2008).
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 9
Punycode: Reversible and unique algorithm, used to transform a
canonicalized IDN into its ACE form.
2.5. Table of accepted characters
The following table represents the set of characters may be used to compose the
label of a domain name.
Code ASCII
Glyph Name
point equivalent
U+002D - HYPHEN-MINUS SIGN
U+0030 0 DIGIT ZERO
U+0031 1 DIGIT ONE
U+0032 2 DIGIT TWO
U+0033 3 DIGIT THREE
U+0034 4 DIGIT FOUR
U+0035 5 DIGIT FIVE
U+0036 6 DIGIT SIX
U+0037 7 DIGIT SEVEN
U+0038 8 DIGIT EIGHT
U+0039 9 DIGIT NINE
U+0061 In LATIN SMALL LETTER A
U+0062 b LATIN SMALL LETTER B
U+0063 c LATIN SMALL LETTER C
U+0064 d LATIN SMALL LETTER D
U+0065 e LATIN SMALL LETTER E
U+0066 f LATIN SMALL LETTER F
U+0067 g LATIN SMALL LETTER G
U+0068 h LATIN SMALL LETTER H
U+0069 i LATIN SMALL LETTER I
U+006A j LATIN SMALL LETTER J
U+006B k LATIN SMALL LETTER K
U+006C l LATIN SMALL LETTER L
U+006D m LATIN SMALL LETTER M
U+006E n LATIN SMALL LETTER N
U+006F o LATIN SMALL LETTER O
U+0070 p LATIN SMALL LETTER P
U+0071 q LATIN SMALL LETTER Q
U+0072 r LATIN SMALL LETTER R
U+0073 s LATIN SMALL LETTER S
U+0074 t LATIN SMALL LETTER T
U+0075 u LATIN SMALL LETTER U
U+0076 v LATIN SMALL LETTER V
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 10
U+0077 w LATIN SMALL LETTER W
U+0078 x LATIN SMALL LETTER X
U+0079 y LATIN SMALL LETTER Y
U+007A z LATIN SMALL LETTER Z
U+00DF ß LATIN SMALL LETTER SHARP S ss
U+00E0 à LATIN SMALL LETTER A WITH GRAVE In
U+00E1 á LATIN SMALL LETTER A WITH ACUTE a
U+00E2 â LATIN SMALL LETTER A WITH CIRCUMFLEX a
U+00E3 ã LATIN SMALL LETTER A WITH TILDE a
U+00E4 ä LATIN SMALL LETTER A WITH DIAERESIS a
U+00E5 å LATIN SMALL LETTER A WITH RING ABOVE a
U+00E6 æ LATIN SMALL LETTER AE ae
U+00E7 ç LATIN SMALL LETTER C WITH CEDILLA c
U+00E8 è LATIN SMALL LETTER E WITH GRAVE e
U+00E9 é LATIN SMALL LETTER E WITH ACUTE e
U+00EA ê LATIN SMALL LETTER E WITH CIRCUMFLEX e
U+00EB ë LATIN SMALL LETTER E WITH DIAERESIS e
U+00EC ì LATIN SMALL LETTER I WITH GRAVE i
U+00ED í LATIN SMALL LETTER I WITH ACUTE i
U+00EE î LATIN SMALL LETTER I WITH CIRCUMFLEX i
U+00EF ï LATIN SMALL LETTER I WITH DIAERESIS i
U+00F1 ñ LATIN SMALL LETTER N WITH TILDE n
U+00F2 ò LATIN SMALL LETTER O WITH GRAVE o
U+00F3 ó LATIN SMALL LETTER O WITH ACUTE o
U+00F4 ô LATIN SMALL LETTER O WITH CIRCUMFLEX o
U+00F5 õ LATIN SMALL LETTER O WITH TILDE o
U+00F6 ö LATIN SMALL LETTER O WITH DIAERESIS o
U+00F9 ù LATIN SMALL LETTER U WITH GRAVE u
U+00FA ú LATIN SMALL LETTER U WITH ACUTE u
U+00FB û LATIN SMALL LETTER U WITH CIRCUMFLEX u
U+00FC ü LATIN SMALL LETTER U WITH DIAERESIS u
U+00FD ý LATIN SMALL LETTER Y WITH ACUTE y
U+00FF ÿ LATIN SMALL LETTER Y WITH DIAERESIS y
U+0153 œ LATIN SMALL LIGATURE OE oe
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 11
2.6.Unicode use vs LDH use
Domain names are present in server names, in the URL, and in email addresses:
here are the forms accepted by Afnic interfaces. Detailed error messages will be
returned in cases of non-compliance with these rules.
Domain name:
EPP interface: the only acceptable form for domain names is the
LDH form, i.e. the ACE version for IDNs.
Web interface: Unicode and LDH forms are accepted
Server name: ONLY the LDH version is acceptable..
URL: ONLY the LDH version is acceptable.
E-Mail: ONLY the LDH version is acceptable.
3. Connection settings to the interfaces
3.1. EPP configuration and parameters
EPP production bench:
• epp.nic.fr
• port: 700
• access authenticated by certificate and login / password
• number of connections available: 3
• account available: 1
• timeout: 20 min
EPP test bench:
• epp.sandbox.nic.fr
• port: 700
• access authenticated by certificate and login / password
• number of connections available: 2
• account(s) available: 2
• timeout: 20 min
FR Rush production service:
epprush.nic.fr
port: 700
access authenticated by certificate and login / password
number of connections available: number of connection(s) purchased
account available: 1 (the same as epp.nic.fr)
timeout: 20 min
FR Rush test service:
epprush.sandbox.nic.fr
port: 700
access authenticated by certificate and login / password
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 12
number of connections available: number of connection(s) purchased
account(s) available: 2 (the same as epp.sandbox.nic.fr)
timeout: 20 min
3.2. Extranet
Production bench:
• https://extranet.nic.fr/
• authenticated access with login / password specific to the Extranet
• account(s) available: 1
Test bench:
• https://extranet.sandbox.nic.fr/
• authenticated access with login / password specific to the Extranet
• account(s) available: 2
3.3. Certificates
According to RFC 5734, EPP TCP Transport, the authentication of the connection
to the EPP server is made with a certificate that you will need to provide to your
customer relationship officer.
Here are the rules for your certificate:
It does not matter which entity issues the certificate (Issuer). This means in
particular that a self-signed certificate is sufficient.
The holder (Subject) of the certificate is verified: we want to see the name of the
registrar in the subject
We do not check certificate revocation lists.
The certificate file must be in PEM format
The client certificate must have the purpose "sslclient" in its structure
The complete certificate chain must be provided in the PEM file
Our recommendations:
Do not put the private key in the file sent to Afnic
SHA256 signature algorithm (MD5 and SHA1 are not recommended)
Public key size 2048 bits minimum
If you suspect / confirm that your private key has been compromised, revoke the
certificate as soon as possible and re-generate a new key and certificate.
The validity period should be at least 1 year
You find the Afnic certificates for EPP servers (among others) here:
https://www.afnic.fr/en/certificates/
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 13
4. Main integration principles of the EPP
protocol
4.1. RFCs
As a reminder, here are the RFCs on which our EPP implementation is based, and
which must be read:
RFC 3375 - Generic Registry-Registrar Protocol Requirements :
http://www.ietf.org/rfc/rfc3375.txt
RFC 5730 – Extensible Provisioning Protocol (EPP):
http://www.ietf.org/rfc/rfc5730.txt
RFC 5731 - Domain Name Mapping: http://www.ietf.org/rfc/rfc5731.txt
RFC 5733 – Contact Mapping: http://www.ietf.org/rfc/rfc5733.txt
RFC 5734 - EPP over TCP: http://www.ietf.org/rfc/rfc5734.txt
RFC 3915 - Domain Registry Grace Period Mapping:
http://www.ietf.org/rfc/rfc3915.txt
RFC 5910 - Domain Name System (DNS) Security Extensions Mapping:
http://www.ietf.org/rfc/rfc5910.txt
Beyond the standard EPP as described in RFCs, Afnic has posed a number of
integration principles that you need to know before embarking on the development
of an EPP client.
4.1.1. No integration of "host" objects (RFC 5732)
We chose to adopt the method where the name servers are domain name
attributes.
4.1.2. Case of operations with result code 1000 and server behavior
in case of problems
One precaution is necessary when developing clients connecting to our EPP
server. At several times in the rest of the document we mention operations
returning a result code 1000. This is the expected behavior under normal
operating conditions of the registration chain.
In the case of a blocking problem, the server reacts more radically and no
operation of the "transform" type on domain names can be taken into account.
An error message "command failed" (code 2400/2500) is then returned for a
new command.
4.1.3. integration choices from the list of notification messages
In the case of any response from the server, we have chosen to specify the
number of messages in the queue (unless there is no message, in which case,
this information should not be provided). RFC 5730 does not require this
information in the case of responses to the command, whereas it is
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 14
optional for other types of commands. In practice this means that when a
message is to be notified to a registrar, the latter is notified by the presence of
the element in the responses to all the commands sent to the main EPP
server (The EPP server for the FR Rush service does not have this information).
It is strongly recommended to consult these messages as and when they arrive
because in the middle of follow-up messages involving technical change
operations there may well be transfer requests to which it may worth replying.
4.1.4. DNSSEC support
The EPP server manages the secDNS-1.1 extension as described in RFC 5910,
excluding any other version. The implementation specifics are as follows:
The server only supports the "DS data interface" (),
section 4.1 of RFC 5910, without any information on the associated key
(no ); element); the inclusion of information on the
key will generate a 2102 error.
A domain name can have multiple associated DS records: the number of
elements included in the section in
an update operation is therefore limited so that the final status of the
domain name has no more than 6 DS records.
The maxSigLife element is not supported, its inclusion in the client
request will generate a 2102 error.
The "urgent" attribute is not supported; its inclusion in the client request
with value 1 will generate a 2102 error.
During a transfer operation the Afnic extension part frnic-1.4 must
include a keepDS flag which is a Boolean: it is 1, the current DS records
of the domain name are retained after the transfer if they are already
present, whereas if it is 0, if the transfer is successful, all the existing DS
records will be deleted.
The recover operation functions identically to the transfer operation
described above.
5.Limitations of the EPP server and
Extranet
For the EPP server:
1/ Initial rate limiting:
Any command following a command is executed immediately, but the
following command cannot be taken into account before a period of 2 seconds. The
following commands are not penalized (unless they fall within the scope of one of
the limitation rules).
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 15
For a given domain name, commands cannot be concatenated at a
rate greater than 2 every 4 seconds. Over that limit, a penalty of 2 seconds is
applied to the next command (for the same domain name).
For example, it is possible to concatenate a command to check the
availability of a domain name with a , command and then another
command on the same name domain without any penalty being
applied.
On the other hand, a client which concatenates a series of commands
for the same domain name, must allow up to 4 seconds between the first and the third
call in order not to be penalized.
Any command concerning an already existing domain induces an
extra response time of 2 seconds on the command.
Any command concerning a domain name that is not in the holder's
portfolio and for which the authInfo is unknown induces an additional response
time of 1 second on this command.
2 / Second rate limiting:
This is based on the number of domain:create occurrences on a domain name that
already exists, is not purged yet or with a specific status which block the registration.
You have the right to 49 domain:create commands 24 rolling hours without being
penalized. If you ever reach 50 occurrences:
You will not be able to authenticate yourself for new connections
You will be disconnected from the EPP servers (including the FR Rush Service)
as soon as you send an action operation on a domain name (excluding querying
operations of the check and info type) on the servers
You can use the registration interfaces again 24 hours after your fiftieth penalty.
Error generating a penalty via EPP:
Object exists
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
testpremiumparis3.next
domain name in use
Your current counter of penalties is available 49
8190fe46d7fc129d45a9a166a357e8f216eea4bc
NEXT-PREPROD-epp01-27564-117-
1472480974.71986
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 16
Error received when disconnecting from the EPP servers:
Command failed; server closing connection
test-tri-epp.fr
1
ns1.test.net
ns2.test.net
TEST21
TEST21
TEST21
test
maximum number of penalty points reached,
command refused
c5a6b8e4e3152adf7f379b8dde0b41d83e5e4419
FR-PREPROD-epp01-23327-10-
1479391033.35172
Error during an authentication attempt when access is blocked:
Authentication error; server closing connection
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 17
Access currently blocked due to too many penalties;
will be allowed again after 2016-11-11T09:07:19Z
93df384343d8c93573a4df24607c4fe5ba1a8fbb
FR-PREPROD-epp01-22808-4-1478769666.7097
6. FR Rush Service
This service is dedicated to registrars and especially those having a "snapping" activity.
It is a second EPP server with the following characteristics:
- Operations allowed:
- login
- logout
- domain:check
- domain:create
- Ability to purchase as many connections as necessary
- Login and password identical to the main EPP server
- Fewer limitations than on the main EPP server:
The rate limiting is as follows:
Any command following a command is executed immediately, but the
following command cannot be taken into account before a period of 2 seconds. The
following commands are not penalized (unless they fall within the scope of one of
the limitation rules).
For a given domain name, commands cannot be concatenated at a
rate greater than 2 every 4 seconds. Over that limit, a penalty of 2 seconds is
applied to the next command (for the same domain name).
For example, it is possible to concatenate a command to check the
availability of a domain name with a , command and then another
command on the same name domain without any penalty being
applied.
On the other hand, a client which concatenates a series of commands
for the same domain name, must allow up to 4 seconds between the first and the third
call in order not to be penalized.
Any command concerning an already existing domain induces an
extra response time of 0,5 seconds on the command.
Any command concerning a domain name that is not in the holder's
portfolio and for which the authInfo is unknown induces an additional response
time of 1 second on this command.
This rate-limiting may harden if any registrar disrupt the .fr Rush service.
To subscribe, go to your Extranet or contact your customer relationship officer.
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 18
7. Session management commands
7.1.1.
The is not a command that the client can send to the EPP server but
the welcome banner that it will send when the connection is made. It is also the
reply that will be sent in response to a command (the command is
discussed in the next section).
Why dwell on this banner if it is not a command? Simply because the
information it provides is important and necessary, among other things, for the
command.
Although the which is reproduced below is given as an example and
that the details of what it may contain can be found in the RFC 5730 you have to
be particularly attentive to at least two elements of information, i.e. the versions
of the supported protocols ( element) and the languages supported
( element). Only one of these values will be accepted when the session
starts with the command (See §7.1.3 on the login)
Example of that can be sent by the Afnic EPP server:
S:
S:
S:
S: EPP PROD Server on nergal.nic.fr (V1.1.0)
S: 2010-04-01T12:34:56.0Z
S:
S: 1.0
S: en
S: urn:ietf:params:xml:ns:contact-1.0
S: urn:ietf:params:xml:ns:domain-1.0
S:
S: urn:ietf:params:xml:ns:rgp-1.0
S: http://www.afnic.fr/xml/epp/frnic-1.4
S: urn:ietf:params:xml:ns:secDNS-1.1
S: urn:ietf:params:xml:ns:launch-1.0
S:
S:
S:
S:
S:
S:
S:
S:
S:
S:
S:
S:
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 19
7.1.2. The command
Although it is not an EPP command in itself, this command is particularly
important and useful because it will allow an EPP client to verify that the
connection to the server has been properly established. Indeed, once a
connection is established with the server, it is possible at any time to send this
command to which the server will respond by sending the EPP ,
even if the () authentication phase has not yet been completed.
To the extent that the time-out mechanisms should be enabled to close the
"inactive" sessions, it is quite possible to make a "heartbeat" by regularly
executing this command to keep limited use sessions open (of course, the
frequency of this "heartbeat" should remain reasonable, given the "time-out"
and rate limiting parameters eventually established). For example, one can well
imagine this command being executed every 2 minutes to keep a connection
open and ensure that the server is always listening, which is an acceptable
frequency.
Example of a request sent by the client:
C:
C:
C:
C:
7.1.3. Session management commands
The EPP protocol provides two commands to establish () and end a
session with the server (). Once the session is established, it will only
terminate on the client request () or if the server, for internal reasons,
has to close it ("time-out" during an idle session, technical problems, etc.), or if
the client interrupts the TCP connection (if the interrupt is during the normal
course of use of the client, it is strongly recommended to send a
before cutting the TCP connection).
Since the number of simultaneous sessions can be limited, their management
must be rigorous.
7.1.3.1.The command
When connecting to the server, it sends a () banner to the client,
thereby indicating that it is ready to receive a session start command. This
command requires knowing the EPP identifier generated by Afnic and the
password associated with it (for security reasons and to "segregate" the
various interfaces offered by Afnic, we have chosen to have a different
identifier between the EPP interface and the Extranet). If they are properly
input and the number of currently established sessions has not reached the
maximum number allowed, the session must normally be established.
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 20
The command can also be used to change the password associated
with this identifier; there is no limitation to this use and is even strongly
advised to change it at the first logon to the EPP server.
Example of command sent by a client:
C:
C:
C:
C:
C: -kiffucol911-.fr
C: toto1
C: toto2
C:
C: 1.0
C: en
C:
C:
C: urn:ietf:params:xml:ns:contact-1.0
C: urn:ietf:params:xml:ns:domain-1.0
C:
C: urn:ietf:params:xml:ns:rgp-1.0
C: http://www.afnic.fr/xml/epp/frnic-1.4
C:
C:
C:
C: une-reference-client-par-exemple
C:
C:
The result of this command will be the opening of a session for the registrar
whose EPP identifier is "-kiffucol911-.fr", the password is "foo1" and who
for security reasons decides change it to "toto2" (of course it is the new
password that must be used at the next session start, since the effect of this
change is immediate).
7.1.3.2.SSL authentication
For any command after the login, a strict check is made to ensure the EPP
extensions (XML namespaces) used or defined have been actually
announced by the client previously during the login.
If a new extension appears in a command, it will be rejected.
This means that you must at least explicitly announce:
the frnic-1.4 extension for operations on contacts and certain
operations on domain names such as transfer, recover, etc.
the rgp-1.0 extension in order to restore a domain name,
and possibly secDNS-1.1 extension if you want to manage DNSSEC.
Furthermore, a strict check is made to ensure that the EPP extensions chosen
by the client at the time of authentication are among the EPP extensions
announced by the server. The presence of any other "exotic" extension will
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 21
result in a failed authentication, as will the absence of any mandatory
extension.
The combination of these two tests thus requires authenticate yourself with
one of the following two combinations:
domain-1.0, contact-1.0, frnic-1.4, rgp-1.0
or
domain-1.0, contact-1.0, frnic-1.4, rgp-1.0, secDNS-1.1
7.1.3.3.The command
We have already indicated, a client wishing to manage EPP sessions must
send a session end command () (and, ideally, wait for the response
from the server) before switching off the TCP connection with the server.
Although the server is able to detect "wild" disconnections from EPP
clients, this type of disconnection may not release the limited resources
allocated to each registrar as quickly as they want.
To be absolutely clear, if, for example, we only allow N concurrent sessions
per registrar on the EPP server (see section 3.1. Configuration and
parameters), and they are all used at a given time, disconnecting a client
without a phase could have the effect of not taking this
disconnection immediately into account. At the same time this prevents any
new connection and so sends back a result code 2502 until the system
detects and properly handles the disconnection.
Example of a command sent by a client:
C:
C:
C:
C:
C: une-reference-client-par-exemple
C:
C:
8. Extension frnic-1.4
Schéma XSD: https://www.afnic.fr/medias/frnic-1.4.xsd.xml
Namespace XML: http://www.afnic.fr/xml/epp/frnic-1.4
Prefix used: frnic
Various operations require the use of the frnic extension, and we will briefly
describe its usefulness (descriptions of elements and examples of commands in
more detail in the sections on the operations)
The frnic extension is required for the following:
- contact:create (creation of contact)
- domain:transfer (transfer of a domain name)
- frnic:recover (compulsory transfer)
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 22
Creating a contact:
Individual (PP):
Element name Number of occurrences
0-1
0-1
1
0-1
0-1
1
1
Legal entity (PM):
Element name Number of occurrences
1
1
0-1
0-1
0-1
0-1
0-1
1 si est
absent
1 si est
absent
0-1
0-1
Transfer:
Element name Number of occurrences
1
1
1-3
• Recover:
Element name Number of occurrences
1
1
1
1
1
1-3
The frnic extension can also be used optionally in the contact update to change
the attributes related to the qualification process.
It is also used in response by the EPP server for the domain:check and certain
EPP notifications.
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 23
9. Launch Phase extension
We have integrated the Launch Phase extension. It has been used for the
opening of 1 and 2 characters under .fr TLD and from the end of this phase is
not used.
Here is the integrated version of the EPP server:
https://tools.ietf.org/html/draft-ietf-eppext-launchphase-02
10. Management of domain names
10.1. Multi-year and expiry date calculation
10.1.1. Number of years available
Domain names can be registered and renewed for a period of 1 to 10 years.
10.1.2. Rule on maximum registration period
The maximum registration period for a .fr domain name has been set to 10 years.
- The "renew" operation will block any attempt to exceed 10 years between the renewal date
and the initial expiry date + the requisite number of additional years.
Example:
Date of renew operation: 15/11/2015
Initial expiry date: 14/12/2016
Number of additional years requested: 9
The new expiry date requested should be 14/12/2025. By calculating the number of years
between the operation date and the new expiry date, the result is greater than 10 years; renewal
is therefore denied by the registration chain.
- Special case of Transfer, Recover and Restore operations: if a Transfer, Recover and Restore
operation involves a domain name for which the registration time is over 9 years between the
date of the operation and its expiry date, the operation will not add 1 year but will change the
expiry date so that it corresponds to 10 years of registration. Transfer, trade, recover and restore
operations therefore are not blocked in this specific case.
Example:
Date of operation: 17 October 2014
Domain name expiry date 9 september 2024
If the operation is completed successfully, the new expiry date will be: 17 October
2024
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 24
10.1.3. Rule for calculating expiry dates
The impact of fee-paying operations on the life cycle of the domain name remains unchanged.
It adapts naturally to the multi-year registrationas well as the appearance of the year in the
expiry date.
Example 1 Example 2 Example 3 Example 4
Domain name 20/06/2015 Domain 02/01/2016 Domain 20/06/2015 Domain 20/06/2020
expiry date name name name
expiry expiry expiry
date date date
End of transfer 08/05/2015 End of 08/05/2015 End of 20/06/2015 End of 04/04/2015
transfer transfer transfer
New expiry date 08/05/2016 New 08/05/2016 New 20/06/2016 New 04/04/2021
expiry expiry expiry
date date date
10.2. Grace periods
10.2.1. General description
Following creation, transfer and explicit renewal (renew) operations, you have a 5-
day grace period.
If the domain name is deleted during the grace period, the operation is charged and
a credit note will be issued.
10.2.2. List, duration and description
List of grace periods activated for the .fr TLD and the ccTLDs for the French
Overseas Territories (as per RFC 3915):
Grace period Duration (days) Description
addPeriod 5 After any creation of a
domain name
transferPeriod 5 After any transfer of a
domain name
renewPeriod 5 After any renewal of a
domain name
redemptionPeriod 30 After any deletion of a
domain name
10.2.3. Cancellation of a grace period
When a domain name is in the grace period and it subject to a new fee-paying operation,
the grace period corresponding to the initial operation having been canceled. If the new fee-
paying operation entitles the holder to a grace period, it is activated at the end of the new
operation.
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 25
There is a special case, as indicated in the table below, that of the deletion of a domain
name during an "addPeriod": this does not trigger a redemption period, the domain is
completely deleted and available again for registration.
The possible cases are summarized in the following table:
Initial operation / Operation Cancellation New Grace Billing of Credit
grace period performed of the Grace Period activated the initial note
activated during the Period (yes operation (yes /
Grace Period / no) no)
Creation / Transfer Yes transferPeriod Yes No
addPeriod
Creation / Recover Yes - Yes No
addPeriod
Creation / Renew Yes renewPeriod Yes No
addPeriod
Creation / Deletion - - Yes Yes
addPeriod
Creation / Update No - Yes No
addPeriod
Renew / Transfer Yes transferPeriod Yes No
renewPeriod
Renew / Recover Yes - Yes No
renewPeriod
Renew / Renew Yes renewPeriod Yes No
renewPeriod
Renew / Deletion - redemptionPeriod Yes Yes
renewPeriod
Renew / Update No - Yes No
renewPeriod
Transfer / Transfer Yes transferPeriod Yes No
transferPeriod
Transfer / Recover Yes - Yes No
transferPeriod
Transfer / Renew Yes renewPeriod Yes No
transferPeriod (explicit
renewal)
Transfer / Deletion - redemptionPeriod Yes Yes
transferPeriod
Transfer / Update No - Yes No
transferPeriod
Delete / Restore - - No No
redemptionPeriod
10.2.4. Credit note limit for creation
In the case of grace periods related to creation operations, we want to limit "domain
tasting" and apply the same rule as ICANN. The amount of the monthly credit note per
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 26
registrar cannot exceed 50 domain names i.e. 10% of the number of net creations per
month. Afnic retains the higher value of the two to set the amount of credit.
10.3. Qualification process (verification and
substantiation)
The qualification process (cf. Qualification specifications and Procedures Guide) concerns
the holder of a domain name, but the procedure can impact the status of the domain name
once it is created.
If the holder is in the substantiation procedure, the domain will switch from suspended to
blocking status, which will modify the EPP status.
Summary table of the operations accepted according to the status of the eligibility
verification procedure:
Status of the
Whois: Whois:
eligibility validation Operations refused Status of the domain name
reachstatus eligstatus
procedure
Start Pending Pending contact:update -
contact:update
domain: update
problem (suspension) ok/- ok/- (registrant) serverTransferProhibited
domain:transfer
contact:update
domain:transfer
serverHold +
domain:restore serverUpdateProhibited +
problem (blocked) ok/- ok/- serverDeleteProhibited +
domain:delete serverTransferProhibited
domain:update
domain:create
Finished ok/- ok/- none -
For more details, please refer to the Eligibility validation procedures and specifications
Guide (document 26/09/2011).
10.4. Settings of a domain name
Minimum / maximum size of the domain name: 1 to 63 characters
Minimum / maximum number of holder contacts: 1
Minimum / maximum number of administrative contacts: 1
Minimum / maximum number of technical contacts: 1 to 3
Minimum / maximum number of billing contacts: 0
Minimum / maximum number of name servers: 0 to 8
Minimum / maximum number of DS records: 0 to 6
Minimum / maximum size of authInfo: 1 to 32
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 27
10.5. Domain:check
The domain:check operation is used to verify the availability of a domain name and
determine the reasons for its unavailability.
The availability in the domain:check is immediate availability, if you are told that
the domain name is available you can immediately register it with a domain:create
command.
Unavailability does not mean that the domain cannot be registered, but it is
sometimes necessary to go through the preliminary stages. (cf. the Procedure
Guide)
Availability is indicated via a boolean (0 or 1) in the response to the domain:check.
This response, in the case of an unavailable domain name contains the reason for
the unavailability.
Here are the messages in the domain:reason element in response to the
domain:check:
Message Details:
The domain name already exists (whatever
In use its status. A domain name being deleted, for
example, is not free).
The domain name is free, but belongs to a
Zone not opened zone managed by Afnic which is not open
for registration.
The domain name is not in a zone managed
Zone unknown
by Afnic.
The argument used as a parameter is not a
Bad syntax
domain name.
An "equivalent" domain name already exists
Equivalent name in use and prevents the domain name from being
filed.
The domain name is part of a list of terms
Forbidden name
which are subject to prior review.
The frnic extension provides additional information as to whether there is a
"forbidden" or "reserved" term (terms subject to prior review).
There are 3 elements:
- frnic:name with reserved and forbidden attributes i.e. Boolean value
0 or 1
- frnic:rsvReason if reserved = 1 and provides the reason for the term
being reserved
- frnic:fbdReason if forbidden = 1 and provides the reason for the term
being forbidden
It is possible to query up to 7 domain names, the response of the command will
include the results for each domain name.
Example of the domain:check command:
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 28
afnic.fr
0f0720ef36b65e9de57a9c84e37e2513d8f104e0
The response:
Command completed successfully
afnic.fr
In use
afnic.fr
0f0720ef36b65e9de57a9c84e37e2513d8f104e0
FR-PREPROD-epp01-26725-74-
1471964339.92461
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.fr.FR TECHNICAL INTEGRATION GUIDE - December 12, 2016 29
10.6. Domain:info
The domain:info operation retrieves some information about a domain name. The operation
requires the provision of the authInfo if you are not the registrar in charge of the domain
name in question.
The response that the server returns does not contain all the elements described in RFC
5731:
The first notable difference is the element. Although we have
unique identifiers for domain names in our database, they do not quite meet the
"specifications" defined in RFC. A "roid" should be created which each object
created in the base; a domain name once created, deleted and re-created should,
logically, be awarded a different "roid" for each creation operation. At Afnic, a
unique ID is associated with a domain on its first insertion in the database, and
follows it, if it is deleted in the meantime (it is never re-assigned). To this unique ID
we concatenate the "-FRNIC" suffix, as we do for all contact objects.
The status of a domain name can be specified either in the part the
response or in the extensions. However, unlike the RFC, this information is not
optional. A domain name that does not have a specific status necessarily has the
element present in the part of the response.
Similarly, the absence of this element necessarily implies that information on the
status of the domain name is in the part of the response.
The elements (the ID for the registrar that created the domain name
the first time) (the ID for the registrar that that last updated the
domain name) and (the date of the last completed transfer) are not
present.
Example of the domain:info command for a domain name belonging to the registrar's
portfolio:
test-tri-epp.fr
e5384d4eca810dd75d68abe3bc9fc1b81e9ec217
La réponse du serveur:
Command completed successfully
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | contact@afnic.fr
Twitter: @AFNIC | Facebook: afnic.frYou can also read
