Registrar Manual: EPP - Version February Registrar Manual EPP. Release 3.0. Copyright 2015 DNS Belgium vzw

Transcription

1 Registrar Manual: EPP - Version February 2016 Registrar Manual EPP Release 3.0 Copyright 2015 DNS Belgium vzw 1

2 Table of Contents 1 Technical SETUP IP Addresses Login EPP password Session Management Session Timeout OBJECT TYPES Domain object OBJECT ATTRIBUTES DOMAIN NAMES AUTH INFO DOMAIN STATUS VALUES Contact Object OBJECT ATTRIBUTES CONTACT STATUS VALUES DISCLOSE POLICY Host Object OBJECT ATTRIBUTES OBJECT STATUS VALUES DNSSEC RELATIONS BETWEEN OBJECT INSTANCES Basic Object Relations Object usage constraints Additional Constraints TRANSACTIONS Protocol Transactions HELLO LOGIN LOGOUT POLL Domain transactions CHECK DOMAIN INFO DOMAIN CREATE DOMAIN DELETE DOMAIN Copyright 2015 DNS Belgium vzw 2

3 4.2.5 RENEW DOMAIN UPDATE DOMAIN RESTORE DOMAIN TRANSFER DOMAIN Host transactions CHECK HOST INFO HOST CREATE HOST DELETE HOST UPDATE HOST Contact transactions CHECK CONTACT INFO CONTACT CREATE CONTACT DELETE CONTACT UPDATE CONTACT Grace Periods Pending Periods Appendix: gtld Domain Lifecycle Appendix: Host Lifecycle Internal Host External Hosts Appendix: EPP queue messages Appendix: Standard EPP Error codes Reason of error codes Copyright 2015 DNS Belgium vzw 3

4 1 Technical SETUP The EPP interface for the registry uses the structures specified in the RFCs 1288, 3110, 3755, 3915, 5730 to 5733, 5155, 5702, 5910 and The specification is based on the respective EPP RFCs. The EPP interface is solely accessible via SLL protocol via hostname epp.nic.vlaanderen and epp.nic.brussels TCP Port 700. The corresponding test system is located on the host test-epp.nic.vlaanderen and test-epp.nic.brussels TCP Port 700 (SSLprotocol). 1.1 IP Addresses You will need to enter your IP addresses to connect with the EPP server via the web interface. 1.2 Login Before connecting to EPP, you will need to enter your EPP password via the web interface. 1.3 EPP password The EPP password must follow the following password policy. Four categories of characters are allowed: Lower case letters (a-z) Upper case letters (A-Z) Numbers (0-9) Special characters are shown in chapter Auth Info No other characters are allowed in the EPP password and the password must contain characters from at least three of the four categories above to be accepted by the server. The minimum password length is 8, the maximum 16. Be aware that it is also possible to change EPP passwords during the login. Hence, when planning to use the registrar web, it is essential to also change the password in the registrar web. Otherwise the registrar web is unable to submit applications to the registry. Whenever changing the EPP password via EPP, also set it to the same password on the registrar web or only change passwords via the registrar web and configure your EPP client accordingly. 1.4 Session Management A certain number of sessions (typically 2) are provided to each registrar. If this maximum amount of sessions is reached, no further EPP-connection can be opened and the return code Copyright 2015 DNS Belgium vzw 4

5 2502 Session limit exceeded;; server closing connection is returned. The bandwidth is 64 Kb/s and session. 1.5 Session Timeout The registry will close an open EPP session automatically, if no transactions have been sent for 120 seconds, or transactions have been sent though a session. 2 OBJECT TYPES The following section provides the specification of objects supported by the EPP system, and describes the specification of the individual object attributes (and their relation amongst each other) authinfo can only be associated with the domain itself, contact authinfo is not supported, and hence cannot be used (i.e. the respective element has to be empty). 2.1 Domain object The Domain object is the primary object of the Registry. It contains registration data of the domain name, and links the domain to contacts and host objects. Note that usage of foreign host and contact objects is allowed (foreign objects are objects sponsored by a registrar that s different from the registrar sponsoring the domain). When extending the expiration time of the domain (via renew or transfer transactions), this can only be done in multiples of one year. The base specification of the EPP domain object / transactions is contained in RFC OBJECT ATTRIBUTES The Domain Object contains the following data elements / attributes: name (1): the fully qualified name of the domain object, without the trailing dot. roid (1): The repository object id of the domain object. The roid is auto-generated by the server. registrant (1): The roid element of the registrant contact. Required attribute. contact (2.. 10): identifies additional contacts for the domain. At least one contact of type admin and one contact of type tech is required. The contacts are referred using the id attribute of the contact object. hostobj (0.. 13): links the domain name to host objects. At least 2 host objects are recommended, the minimum number of 0 is intended for business process implications rather than for reservation. clid (1): the identifier of the currently sponsoring registrar. crid (1): the identifier of the registrar who created that element. crdate (1): the date and time of creation of the domain object. Copyright 2015 DNS Belgium vzw 5

6 exdate (1): the expiration time / date of the domain object. upid (0.. 1): identifier of the registrar who did the last update on the object. Does not exist if the object has never been updated. update (0.. 1): date/time of the most recent update. Does only exist if the domain has been updated since creation. trdate (0.. 1): date/time of the most recent successful domain object transfer. Does not exist if domain has never been transferred. authinfo (1): authorization information. This field is required during object creation. Various status elements, see below DOMAIN NAMES This section describes allowed domain names. Only second level registrations are allowed. The maximum length for a label is 63 characters. The minimum length for a label is 2 characters. Allowed non-idn characters: letters A-Z, digits and hyphens -. A label may not commence or end with a hyphen and may not contain two hyphens at the third and fourth position, except for the ACE-string of an IDN AUTH INFO AuthInfo is required for domain objects. This sensitive information is necessary in order to allow the process of a domain transfer. The registry system requires that the authinfo is at least 8 characters long, the maximum length is 32 characters. Furthermore, at least one alphanumeric character ( A to Z ;; both lower and uppercase letters), and at least one numeric character ( 0 9 ) as well as or one special character (see Table ) is required for each authinfo. These constraints are checked by the registry for each create and update transaction. The set of allowed special characters is: Character Code Point! U+0021 U+0022 # U+0023 $ U+0024 % U+0025 & U+0026 U+0027 ( U+0028 ) U+0029 * U+002A + U+002B, U+002C - U+002D. U+002E / U+002F : U+003A ;; U+003B Copyright 2015 DNS Belgium vzw 6

7 < U+003C = U+003D > U+003E? U+0040 [ U+005B \ U+005C ] U+005D ^ U+005E _ U+005F ` U+0060 { U+007B U+007C } U+007D ~ U+007E Table : Allowed special character for Auth Info (uppercase and lowercase alphanumeric characters as well as numeric characters are also allowed) DOMAIN STATUS VALUES The domain object supports the following status values (as described in Section 2.3 of RFC 5731): inactive (to indicate that no hosts are associated with the object). This status is set automatically by the server. ok (default status) set automatically by the server, when at least one host is linked. pendingtransfer is set by the server when the domain name is subject to a pending transfer. pendingdelete is set by the server when the domain name is subject to deletion. serverhold/clienthold set when the domain object is not to appear in the zone, for example in case of legal problems with the domain, or when the domain is in REDEMPTION or PENDING DELETE state. serverupdateprohibited/clientupdateprohibited set when the domain name cannot be updated due to server or client policy (e.g. for server policy: in the REDEMPTION or PENDING DELETE state). servertransferprohibited/clienttransferprohibited set when the domain name cannot be transferred due to server or client policy. serverdeleteprohibited/clientdeleteprohibited set when the domain name cannot be deleted due to server policy, or client provisions. serverrenewprohibited/clientrenewprohibited set when the domain name is not eligible for renewal, for example because the maximal renewal period is reached. Note that setting the client/serverrenewprohibited status has no effect on autorenewals on the object. Note that some of the above status values restrict the set of allowed transactions on the Copyright 2015 DNS Belgium vzw 7

8 domain object. More details about which transaction is affected by which status is contained in RFC Additionally, the domain objects supports the following states values related to the grace period mapping RFC 3915, Section 3.1: addperiod: this period is provided after the successful initial registration of a domain and indicates that a domain is in the addgraceperiod (description and duration of the period is contained in Chapter 5). autorenewperiod: this period is provided when the registry automatically renews the domain, description and duration of this period is contained in Chapter 5). This period does not apply when the domain is manually renewed by a registrar by the renew transaction. renewperiod: this period is provided when a registrar successfully renews a domain, for description and duration see Chapter 5. transferperiod: this period is provided after a successful transfer of a domain, for description and duration see Chapter 5. redemptionperiod: This period may be provided for domains when a delete transaction is received from the registrar. Note that not all domains enter redemptionperiod. For a description of the redepemtion period refer to Chapter 6 as well as the description of the delete domain transaction. pendingrestore: this period is provided for domains that were previously in redemptionperiod and are going to be restored (refer to Chapter 6 for further description). pendingdelete: this period is provided for domains that cannot be restored any more and are going to be purged by the registry system (refer to the delete domain transaction section and Chapter 6 for further details). Also note that a server may always override status values set by a registrar. A description of the grace periods is contained in Chapter 5 of this document. 2.2 Contact Object The contact object is used for provisioning and handling of personal or organizational identifier social information identifiers known as contacts. The description of the EPP contact mapping is contained in RFC OBJECT ATTRIBUTES The contacts Object contains the following data elements / attributes: id (1): registrar desired server unique identifier of the contact object. This attribute is used to link other objects to this contact. Allowed characters: A-Z and 0-9, allowed length: 3 to 16 characters. Note that characters are normalized to uppercase by the registry system and stored uppercase in the database. registrars may use the id case insensitive and do not receive an error message when using lower case letters. roid (1): Repository Object ID assigned by the server to the contact object. Copyright 2015 DNS Belgium vzw 8

9 postalinfo (1): postal address with several sub-elements as described below. Note that only the internationalized postal address is supported, transactions trying to create a local address section are rejected by the Registry. For the basic description of the fields, please refer to Section of RFC Length restrictions of the fields are as specified in the RFC, allowed characters are \x20 - \x7e (except for country code). o o name (1): name of individual. org (0.. 1): name of organization. o addr (1) street (1.. 3): street information (note that a minimum of 1 street element is required although in RFC 5733 all street elements are optional). city (1): city. sp (0.. 1): state or province. pc (0.. 1): postal code. cc (1): country code. voice (0.. 1): voice telephone number (with optional extension, max. 9 digits, extension alone cannot be present without voice telephone number). fax (0.. 1): fax telephone number (with optional extension, max. 9 digits, extension alone cannot be present without fax telephone number). (1): address (max. length 254 characters, user part max. length 64 characters, host part must be in existing TLD). clid (1): identifier of sponsoring registrar. crid (1): identifier of the registrar that created the contact object. crdate (1): timestamp of object creation. upid (0.. 1): identifier of registrar that last updated the object. Does not exist if object has never been updated. update (0..1): timestamp of most recent object modification. Does not exist if object has never been updated. trdate (0.. 1): timestamp of most recent object transfer. Does not exist if the object was never transferred. authinfo (1): authorization information not supported. Disclose (0.. x): identifies elements that require exceptional disclosure handling. Implemented for future feature, do not use for risk of being audited by ICANN. Status (1.. 7): status of the contact object CONTACT STATUS VALUES The Registry allows for the following Contact status values: linked: when the object is used in at least one domain name object. Ok: default status. Copyright 2015 DNS Belgium vzw 9

10 serverupdateprohibited/clientupdateprohibited: when for server or client policy reasons, modifications to the object are currently not allowed. serverdeleteprohibited/clientdeleteprohibited: when for server or client policy reasons removal of the object from the registry is not allowed DISCLOSE POLICY EPP allows for a specification of the disclose policy of some of the individual attributes. Implemented for future use, do not use for risk of being audited by ICANN. When used, all values should resolve to true. 2.3 Host Object The Registry system uses host objects as described in RFC 5732 exclusively. Host attributes as described in RFC 5731 (for example, in Section 3.2.1) are not supported OBJECT ATTRIBUTES The host object supports the following attributes. The numbers in parentheses indicates how often the attribute may occur in an object instance: name (1): Fully qualified name of the host object (the hostname of the nameserver), without trailing dot. addr (0.. 13): IP addresses of the host, either of type IPv4 or IPv6. Hosts that are not subordinate to the Registry s TLD (external hosts) must not include IP addresses. Hosts that are subordinate to the TLD of the Registry (internal hosts) require at least one IP address. roid (1): The repository object identifier assigned by the Registry to the object. clid (1): The identifier (registrar-id) of the currently sponsoring (owning) registrar. crid (1): The identifier of the registrar that created the host object. crdate (1): The date/time of the object creation. upid (0.. 1): The identifier of the registrar who last updated the host object. This attribute exists only if the object has been updated since its creation. update (0.. 1): Date/time of the last update to the object. This attribute does not exist if the object has not been updated yet. trdate (0.. 1): Date/time of the last transfer of this object. one of more status values (see below) OBJECT STATUS VALUES At each time, the host object is associated with at least one status value. The registry supports the following status values: linked: Set by the registry when a host is in use with a domain. ok (default status) pendingtransfer: Set by the registry on internal host objects when the superordinate domain is pending for transfer. Copyright 2015 DNS Belgium vzw 10

11 pendingdelete: set by the registry on internal host objects when the superordinate domain is in pendingdelete. serverdeleteprohibited/clientdeleteprohibited can be set if the server or client policy reasons removal of the object from the registry is not allowed. serverupdateprohibited/clientupdateprohibited e.g., when for server or client policy reasons, modifications to the object are currently not allowed. 2.4 DNSSEC For the provisioning of DNSSEC trust chains, the EPP interface supports the extension described in RFC 5910 for accepting DS data (key data interface is not supported). The DNSSEC extension can be used for the following transactions: Info domain (response only) Create domain Update domain The following elements related to DNSSEC are accepted: keytag alg digesttype digest Note that the status clientupdateprohibited and serverupdateprohibited also prohibits that DNSSEC information is updated. A domain transfer leaves DNSSEC information unaffected and unmodified. Only the currently sponsoring registrar is allowed to update DNSSEC information. The registry supports DNSSEC with the following as outlined below: Provision of DNSSEC Key Material for registered names is optional (choice of Registrar on behalf of Registrant). The registry supports provisioning of DS records only, via the extension s <secdns:dsdata> element. Provisioning of Key data elements ( <secdns:keydata> is not supported). DS records will be included in the published zone if at least one DS record exists for a provisioned name. A maximum of 6 DS records can be provisioned per domain. To be accepted, each DS record provided in a <secdns:dsdata> element must pass the following syntactical checks: o The keytag element must contain an integer in the range of 16bit o The alg element must contain an integer in the 8 bit range o o o The digesttype element must contain an 8bit integer digesttype is additionally restricted to the currently registered values 1 or 2. If more values are added to the respective IANA registry, this policy will be adopted accordingly If the "digesttype" element is "1", the "digest" must be a hexadecimal string of 40 characters length. o If the "digesttype" element is "2", the "digest" must be a hexadecimal string Copyright 2015 DNS Belgium vzw 11

12 o on 64 characters length. The alg element must specify one of the following currently supported algorithms: 3: DSA/SHA1 (RFC 3755) 5: RSA/SHA-1 (RFC 3755, RFC 3110) 6: DSA-NSEC3-SHA1 (RFC 5155) 7: RSASHA1-NSEC3-SHA1 (RFC 5155) 8: RSA/SHA-256 (RFC 5702) 10: RSA/SHA-512 (RFC 5702) 12: GOST R (RFC 5933) 13: ECDSA Curve P-256 with SHA-256 (RFC 6605) 14: ECDSA Curve P-384 with SHA-384 (RFC 6605) EPP transform transactions containing dsdata not complying with the syntactical checks above are rejected (will fail). Hexadecimal numbers will be normalized to lower case when stored in the SRS database. 3 RELATIONS BETWEEN OBJECT INSTANCES 3.1 Basic Object Relations Objects are related to each other on the object model / interface level via their handles. Specifically, objects in the registry are related to each other as follows: A domain type object is related to exactly one contact object that is listed as registrant for this domain. The element used to link the objects is the roid element in the contact, which has to be put into the registrant element of the domain instance. The relations are between the following object/attributes o domain/registrant contact/id A domain type object is related to 2 10 additional contacts. Both admin and tech are required each at least once. A total of 10 admins and techs can be added. The bill contact type is not supported. Each contact can only be listed once per domain and type (but the same contact can be used as admin and tech). The relations are as follows: o o domain/contact (type=tech) contact/id domain/contact (type=admin) contact/id A domain type object is related to 0 13 existing host objects. A minimum number of host objects of 2 is recommended. The minimum number of 0 nameservers is primarily intended to allow for the sequence create domain, create subordinate nameservers, update domain (adding nameservers). The relation is expressed in the following object/attributes: o domain/hostobj host/name 3.2 Object usage constraints Copyright 2015 DNS Belgium vzw 12

13 Objects can be linked together (as specified in the section above). However, there are additional restrictions based on ownership ( sponsoring registrar ) of the individual objects. Those restrictions are as follows: Contact Objects: The registry does not limit the use of foreign contacts in domains however, the use of own contacts is encouraged, because otherwise another registrar could update e.g. a registrant of a domain without his knowledge. Host Objects: host objects can be used by any registrar, even if they are owned by a different registrar. Each nameserver is identified by its full qualified domain name, and hence can only exist once in the registry. Updates (or other transformation transactions) on nameservers are, however, limited to the sponsoring registrar (There are no interesting attributes to update on nameservers, however besides the name itself, status and the IP addresses which are only relevant for internal hosts). 3.3 Additional Constraints Besides the basic Object Relations described above, the following additional constraints regarding relation of objects exists: Internal Host Objects: Internal hosts are always transferred with the superordinate domain. Furthermore, if the superordinate domain is deleted the corresponding internal host will be deleted too. This implicates, that the superordinate domain must be registered before the creation of an internal host object. 4 TRANSACTIONS 4.1 Protocol Transactions The following protocol transactions are offered. These transactions do not trigger changes, except the modification of the password if induced HELLO The client can initiate a Hello transaction anytime, the server will reply with a Greeting LOGIN A login transaction is always the first transaction and has to be performed in order to establish a session with the EPP server. During an active session, a login transaction is rejected by the server. If the login was processed successfully, the EPP code 1000 is returned. A session should be terminated with the logout transaction. The transaction is described in Section of RFC 5730 and the following input data are used: clid, assigned by the registry (registrar handle). pw, the password. Copyright 2015 DNS Belgium vzw 13

14 newpw, optionally for changing the password (password changing is only possible at login). options, for indicating version and lang. svcs, for indicating namespace URIs representing objects to be managed during the session LOGOUT Issuing a logout transaction terminates a session. Server policy reasons for the termination of a session are mentioned at Session Timeout. The transaction is described in Section of RFC 5730 and no input data are needed. The EPP result code 1000 is returned if the transaction was completed successfully POLL This EPP transaction is used to discover and retrieve server-generated service messages. Message polling consists of two parts the query (message polling) and the deletion (message acknowledge) of the message on the server. Only the oldest message stored on the system is displayed. This means that the acknowledgement is required in order to view the next message. The transaction is described in Section of RFC 5730.and object specific information is contained in a resdata element. For detailed specification of the resdata element see Internet draft Domain transactions The registry allows domains without a single linked host object. This is necessary in order to allow a domain to be created and after that subordinate host objects get provisioned to the registry and the domain can be updated to use these host objects. This is necessary since internal host objects can only be created when the domain already exists and the create domain transaction does not auto-create subordinate host objects. Restrictions on the name of a domain are mentioned in the Registry s policy CHECK DOMAIN The check domain transaction allows a registrar to check whether or not a domain object can be provisioned in the Registry. The transaction is described in Section of RFC The maximum number of domain names to be checked in a single transaction is 5. In case of an IDN domain name, the A-label must be used. For each of the given name attributes in the transaction, a response section chkdata as described in the RFC is returned to the registrar. The server specific reason text for domain names that cannot be provisioned in the registry can be one or more of the following: not a second (or third) level domain of <TLD> below minimum length of <length> above maximum length of <length> Copyright 2015 DNS Belgium vzw 14

15 invalid characters <character list> (Note: depending on the IDN characters, more reason texts may be available) already exists reserved For the case when the number of domain names to be checked for is not between 1 and 5, the following response is to be returned: number of names to be checked not between 1 and 5 If the domain name is AVAILABLE, the reason element is not included in the chkdata element INFO DOMAIN This transaction is used to display a domain name s delegation date and is specified in Section of RFC5731. The response contains the following attributes: status values associated with the domain object. registrant and contact's host, listing the subordinate host objects of this domain. crid / crdate. exdate. upid / update / trdate (if existent). When the performing registrar is the sponsoring registrar or when valid authinfo is provided, the authinfo is also returned. When invalid authinfo is provided, the server responds with a 2202 response code, and no normal info response message is provided CREATE DOMAIN This transaction is used for a new domain delegation and is specified in section of RFC The transaction requires the following attributes: name : mandatory registrant : mandatory at least one admin and at least one tech contact: mandatory authinfo : mandatory host objects : optional period : optional o o DELETE DOMAIN only years are supported default value: one year This transaction puts an active domain name into the redemption period, or if deleted while in add grace period the domain is deleted immediately. The same applies for subordinate hosts. The transaction is specified in Section of RFC Copyright 2015 DNS Belgium vzw 15

16 DNS updates for the domain and host updates for subordinate nameservers are queued. In case the subordinate nameservers are used for other domain names, the corresponding registrars receive a poll message RENEW DOMAIN This transaction extends the validity period of a domain object. The transaction is specified in Section of RFC If one of the following conditions occurs, the transaction will fail: domain does not exist. Transaction was performed by a non-sponsoring registrar. Check if curexpdate is set to the current validity period. The renew period would extend the validity period beyond the maximum validity period of 10 years. client/serverrenewprohibited is set. insufficient credit UPDATE DOMAIN This transaction modifies the attributes of a domain object. The transaction is specified in Section of RFC The modification can be stated in add, rem or chg elements for adding, removing or changing attribute values. Add and remove is allowed for name servers, contacts and status elements. Changing is allowed for registrant and authinfo. Ignoring the order of declaration the rem element is accomplished before the add element. (Note that it is impossible to remove authorization information with the <domain:null> element.) If one of the following conditions occurs, the transaction will fail: domain does not exist. Transaction was performed by a non-sponsoring registrar. client/serverupdateprohibited is set. add/rem/chg restrictions are not enforced. minimum number of contacts, nameservers etc. is not warranted after the update RESTORE DOMAIN For restoring a domain a restore request and a restore report is required as described in RFC The extension affects the request as well as the response. The full specification is contained in RFC 3915, Section The request contains an extension element with a rgp:update element, which contains a single restore element and optionally a report element. It is allowed that the update transaction only includes an empty add, rem or chg element. The attribute op of the restore element indicates the operation: request and report. Only when a report is submitted, the report element must be used. In case a correction of the report is necessary, multiple reports can be submitted. The report contains the following subelements: Copyright 2015 DNS Belgium vzw 16

17 predata (1): copy of the registration data of the domain to be restored prior to the domain being deleted. postdata (1): copy of the registration data of the domain at the time the restore report is submitted. deltime (1): date and time the delete request was sent to the server. restime (1): date and time when the restore request was sent to the server. resreason (1): explanation of the reason for restoring the domain. statement (2): first statement contains a text statement that the registrar has not restored the domain in order to assume the rights to use or sell the domain for itself or for any third party. The second statement contains a text statement that the information in the report is factual to the best of the registrar s knowledge. (may optionally contain lang attributes). other (0..1): any other information to support the statements provided by the registrar. The rgp-update extension is able to modify the grace period status of a domain. When a restore is requested, the domain is placed into pendingrestore. When a restore report is submitted for a domain in pendingrestore, it is placed in ok status immediately meaning that the domain is restored and will not be deleted. Note that when no restore report for a domain in pendingrestore is received within 7 calendar days, the redemption period starts over. When a domain is successfully restored and its expiry date is in the past, the expiration date is extended by 1 year by the registry. Please note, that the restore (request and report) will fail, if the domain is in pendingdelete TRANSFER DOMAIN The transfer of a domain name includes a set of transactions which are specified in sections and of RFC Note that neither linked contact nor linked host objects are transferred with the domain. However, subordinate host objects are transferred with the domain. It is recommended that the gaining registrar updates contact and host objects for the domain immediately after a successful transfer. Transfer Domain Lifecycle The following diagram illustrates the lifecycle of the domain object with regards to transfers. Note that only one transfer request can be pending at a time. Transfer requests on a domain name object that is already in transferpending status are rejected. Only domains older than 60 days can be transferred (counted form the day of the initial registration). Pending transfers that have neither been approved nor rejected within 5 days are autoapproved by the Registry. Transfer requests require valid authinfo. Copyright 2015 DNS Belgium vzw 17

18 op=reject (by X) REGISTERED (clid=x) op=request (by Y) REGISTERED [PENDING TRANSFER] (clid=x) op=request (any client) op=cancel (by Y) REGISTERED (clid=y) op=approve (by X) Auto-approve (by registry after 5 days of no action by X) Figure : Domain Transfer States In the pending Transfer state, the following transactions on the domain name are not allowed: transfer (op=request) delete (update, renew, and all other transfer sub-transactions are allowed) Transfer and the maximum validity period A transfer request contains an optional period element that indicates how long the domain s validity period is extended for upon approval of the transfer. However, ICANN requires a maximum validity period of 10 years. In order to ensure that transfers are always possible (even when the domain is renewed up to the maximum number of years in advance) and also to not safeguard registrars, the following rules apply: o transfer requests are rejected when the given period could result in a validity period exceeding 10 years, unless the transfer is requested with a period of 1 year (also the default value if no period given). In the latter case the validity period is capped at 10 years. (reason: otherwise registrars could block transfers by renewing domains for 10 years). Note this check is only performed at the initial transfer request. Manual renew transactions do not affect pending transfers, so the losing registrar may still issue a manual renew transaction during pendingtransfer state that would result in an exceedance of the maximum registration period for the requested period after the successful transfer. In this case the transfer still proceeds and the maximum validity period is simply capped at 10 years if necessary. Examples: Usual case: At the time of the transfer request, a domain name is still valid for 3.5 years. The transfer request indicates a period of 5 years. The transfer request is granted, since <= 10. Reject case: At the time of the transfer request, a domain name is still valid for 7.1 years. The Transfer request indicates a period of 4 years. The transfer is rejected, since > 10, and given period <> 1. Copyright 2015 DNS Belgium vzw 18

19 Exception case: At the time of the transfer request, a domain name is still valid for 9.5 years. The transfer request indicates a period of one year (or is absent, so that the default of one year applies). The transfer request is granted, even though > 10, but the domain name s validity period is capped at 10 years at the time of the approval. Special renewal case: At the time of the transfer request, a domain name is valid for 6.5 years. The transfer request indicates two years, and is granted, since < 10. However, while the transfer is pending, the losing registrar renews the domain name by three years, resulting in a validity period of 9.5 years. Therefore, when the transfer is approved, the validity period of the domain would be 11.5 years. In this case, the period also MUST be capped at 10 years. Transfer Request The transfer request op=request is initiated when a domain should be transferred. The correct authinfo is required. Furthermore the period element can be used to indicate the extension of the validity period of the domain in case of a successful transfer (only years are supported). When the request is successful, the domain enters the pendingtransfer period max. 5 days. The same applies for existing subordinate hosts. If one of the following conditions occurs, the transaction will fail: domain does not exist. wrong authinfo. the domain is already managed by the registrar. domain is already in pendingtransfer. domain is younger than 60 days. not enough credit. if the resulting validity period would exceed 10 years. Exception: when period is set to 1 year. Transfer approve The transfer can be approved by the losing registrar by indicating op=approve or the registry will auto-approve in case the losing registrar does not approve or reject within 5 days. The authinfo is not required for this transaction but can be supplied. If one of the following conditions occurs, the transaction will fail. domain does not exist. domain is not in pending Transfer. transaction was not sent by the current sponsoring registrar. if the given authinfo (optional) is incorrect. When the transaction was successful the domain object is transferred from a losing registrar to a gaining registrar. All subordinate host objects are transferred as well. However, contacts are not transferred. Hence, the gaining registrar is encouraged to update the contact objects immediately after the successful domain transfer. The pendingtransfer state is removed. Furthermore, the validity period is extended by 1 year or as indicated in the optional period element in the initial transfer request. In case the domain was auto-renewed while in pendingtransfer state, the validity period is extended by 1 year less (since the auto renew already added 1 year and the losing registrar who paid for the auto-renew gets a refund for the auto-renew! E.g. when no period was indicated in the initial transfer request and the Copyright 2015 DNS Belgium vzw 19

20 domain was auto renewed during pendingtransfer, validity period must not be changed;; or when the period was indicated with 3 years, another 2 years are added). Also note that the expiry date is extended from the expiration date even in case the expiry date is the past (in case when the domain would have expired during pendingtransfer!) and not starting from the day of the successful transfer. Validity period is always capped at the maximum of 10 years. Thus, the new expiration date is set to the lower value of: current expiration date. current timestamp plus 10 years. Transfer reject With this transaction the losing registrar is able to prohibit the transfer of the domain by indicating op=reject (the losing registrar has to give a reason to the gaining registrar and registrant for this action if requested according to ICANN rules). The authinfo is not required for this transaction but can be supplied. If one of the following conditions occurs, the transaction will fail. domain does not exist. domain is not in pendingtransfer. transaction was not sent by the current sponsoring registrar. if the given authinfo (optional) is incorrect. When the transaction was successful, no domain transfer takes place and the pendingtransfer state is removed. Please note that when a domain has already expired or expires on that day, it is either auto-renewed or enters redemption period. Transfer cancel With this transaction the potential gaining registrar is able to cancel the desired domain transfer by indicating op=cancel. The authinfo is not required for this transaction but can be supplied. If one of the following conditions occurs, the transaction will fail: domain does not exist. domain is not in pendingtransfer. transaction was not sent by the current sponsoring registrar. if the given authinfo (optional) is incorrect. When the transaction was successful, no domain transfer takes place and the pendingtransfer state is removed. When domain is already expired or expires today, the autorenew/expiry job is immediately performed for the domain. Transfer query With this transaction information about the currently pending transfer or the last completed transfer request can be obtained by indicating op=query. Registrars involved in the latest transfer (either as losing or gaining registrar) receive all information (authinfo not mandatory). Other registrars must supply valid authinfo to receive the same information. In case authinfo is invalid, error code 2202 is returned (this applies also in case a client involved in the latest transfer supplies invalid authinfo even though it is not required to supply authinfo at all). In case the domain is currently not in pendingtransfer state and there was also no completed Copyright 2015 DNS Belgium vzw 20

21 transfer request in the past, the response is Host transactions For host, the following restrictions on IP addresses for internal host apply: at least one IP address must be provided. There is no restriction on the usage of IPv4 and IPv6 addresses (in particular a host with an IPv6 address only is allowed). The maximum total number of IP addresses is 13. Host names may contain multiple labels, each up to 63 characters;; the minimum length of a label is 1 character. Labels may consist of letters, numbers and hyphens, but labels must not start or end with a hyphen ( - ). The maximum total length of a fully qualified host name is 80 characters. These definitions are referenced in the following subsections for creating and updating hosts as restrictions on usage of IP v4 and v6, minimum and maximum number of IP addresses and naming policy CHECK HOST This transaction allows to verify whether a host is available or registered and the EPP result code 1000 is returned. The transaction is specified in Section of RFC The maximum number of host names to be checked in a single transaction is 5. For each of the given name attributes in the transaction, a response section chkdata as described in the RFC is returned. The server specific reason text for host names that cannot be provisioned in the registry can be one of the following: below minimum length of <length> above maximum length of <length> invalid characters <character list> already exists In case the number of hosts is not between 1 and 5, the following response is returned: number of names to be checked not between 1 and INFO HOST This transaction gives information about a registered host object. The transaction is specified in Section of RFC In case the transaction was successful, the response contains an infdata element with the following child elements: (1) name (1) roid (0..x) status (0..x) addr (1) clid (1) crid (1) crdate Copyright 2015 DNS Belgium vzw 21

22 (1) upid (1) update (1) trdate CREATE HOST This transaction allows creating a new host object. The transaction is specified in Section of RFC For creation, a fully qualified name of the host object is required and the host name must be available. Furthermore, IP addresses are required for internal hosts and these host objects can only be created by the sponsoring registrar of the corresponding domain name. If one of the following conditions occurs, the transaction will fail: External host: The transaction contains IP address(es). Internal host: the transaction contains no IP address/es. the transaction contains more than 13 IP addresses. superordinate domain is either in redemption or in pending delete. requestor is not the sponsoring registrar of the corresponding domain DELETE HOST This transaction deletes a host from the registry and is specified in section of RFC Please note, that external host cannot be deleted as long as they are linked with a domain. However, internal hosts are deleted when the respective domain is deleted. If one of the following conditions occurs, the transaction will fail. the host is linked with a domain name. client/serverdeleteprohibited is set. the transaction was sent by a non-sponsoring registrar UPDATE HOST This transaction updates an existing host object in the registry and is specified in the section of RFC Please note that changing the name of the host object is not allowed and therefore, the chg element must be empty. The elements add and rem are supported and used for medication of addr (only for internal hosts) and the status (status values). If one of the following conditions occurs, the transaction will fail: Client/serverUpdateProhibited. the transaction contains no IP address/es, in case of internal host objects. the transaction contains more than 13 IP addresses, in case of internal host objects. the transaction contains IP address/es, in case of external host objects. requestor is not the sponsoring registrar of the corresponding domain. 4.4 Contact transactions Copyright 2015 DNS Belgium vzw 22

23 4.4.1 CHECK CONTACT The check transaction can be used to determine if a contact object can be provisioned in the registry. The transaction is specified in Section of RFC The maximum number of contact IDs to be checked in a single transaction is 5. When the number of contact IDs to be checked is not between 1 and 5, the following response is returned: Number of names to be checked not between 1 and INFO CONTACT This transaction gives information about a registered contact object. The transaction is specified in Section of RFC Note that only one ID is allowed per request. In case the transaction was successful, the response contains an infdata element with information about the contact CREATE CONTACT This transaction allows creating a new contact. The transaction is specified in Section of RFC Please note the auth info element must be empty, because authinfo for contacts is not supported. The following data are required: contact ID. postalinfo element (internationalized format only). o element. contains several sub elements (country code,street, city, ). Optionally, the following elements can be used: voice. fax. disclose element. Implemented for future use, do not use for risk of being audited by ICANN DELETE CONTACT This transaction deletes a contact object from the registry. The transaction is specified in Section of RFC If one of the following conditions occurs, the transaction will fail: the contact object is linked with a domain name. the transaction was sent by a non-sponsoring registrar. server/clientdeleteprohibited status is set UPDATE CONTACT This transaction updates an existing contact object in the registry. The transaction is specified in Section of RFC Add and rem only apply to status elements (one or more subelements). Chg contains the Copyright 2015 DNS Belgium vzw 23

24 following subelements: postalinfo (the Registry supports only international address type) voice fax authinfo disclose. Implemented for future use, do not use for risk of being audited by ICANN. If one of the following conditions occurs, the transaction will fail: the transaction was sent by a non-sponsoring registrar. server/clientupdateprohibited state set. The authinfo element is not empty. Violation of policy concerning required elements and naming conventions. 5 Grace Periods The Registry System supports grace periods as listed below. Each domain can only be in one grace period at a given time, consequently grace periods do not overlap. When a domain enters a grace period, the previous grace period ends. A delete transaction always ends the current grace period (and may result in a refund). A subsequent domain restore never puts the domain in any previous grace period. add grace period: the add grace period lasts 5 calendar days from the date of initial registration. Upon deletion in this period, the domain is immediately purged and thus available for re-registration. The registrar is credited for an amount corresponding to the registration fee (unless the registrar is already over its monthly allowance of add grace transactions). Note that the refund for the add grace period is performed at the end of each month and not immediately after each individual delete transaction. Calculation of the refund is performed outside the registry core. A renew transaction ends the add grace period. Note that it is impossible to perform a domain transfer in the add grace period (in fact, the first transfer is only allowed after 60 days of registration). To prevent misuse and domain tasting in particular, ICANN s Add Grace Period Limits Policy, available at: 17dec08-en.htm (including implementation notes) applies. Deletions in the add grace period exceeding the monthly allowance are not refunded. Information on how many domains were deleted in this grace period is be included in the monthly reports. renew grace period: after each renew transaction, a 5 calendar day long renew grace period starts. When the domain is deleted in this timeframe, the registrar is credited for the corresponding fee and the domain enters a Redemption Grace Period. A deletion or approved transfer of a domain immediately ends the renew grace period. transfer grace period: the transfer grace period is 5 calendar days following a successfully completed domain transfer. If a domain is deleted in this timeframe, the sponsoring registrar is credited for the amount billed during the domain transfer. The transfer grace period is terminated when a delete, renew or subsequent domain transfer is performed. Copyright 2015 DNS Belgium vzw 24

25 auto-renew grace period: every auto-renew is followed by an auto-renew grace period (45 calendar days). If a domain is deleted or transferred within this period the fee for the renewal is refunded to the registrar. However, when a renew transaction is performed the auto-renew grace period is terminated (and the domain may enter the renew grace period instead). Grace Period Mapping is described in RFC The following subsections give an overview of the functionality. The grace period of the domain is returned via an extension of the info transaction. 6 Pending Periods In pending periods certain operations are not allowed. Redemption Grace Period: consists of o o o Redemption Period: within the 30 days of this period, the domain can be restored after a delete (if domain outside add grace period). Pending Restore: in order to successfully restore a domain in the redemption period, a restore report is required. This report has to be submitted within 7 days of this pending restore period. In case no restore report is submitted, a new 30 day long redemption period begins. Pending Delete: If a domain is deleted and not restored, it is placed in the pending delete period at the end of the redemption period. After 5 days of this period, the domain is finally available for registration. Pending Transfer Period: last for 5 days after the initial transfer transaction. The losing registrar has 5 days to approve or reject the request. In case there is no answer from the losing registrar, the registry auto-approves the transfer. Copyright 2015 DNS Belgium vzw 25