registrar manual epp

Registrar Manual: EPP - Version 3.1

Copyright © 2015 DNS Belgium vzw 1

Registrar Manual EPP

5 February 2016

Release 3.0



Table of Contents 1 Technical SETUP ................................................................................................... 4

1.1 IP Addresses .................................................................................................... 4 1.2 Login ................................................................................................................. 4 1.3 EPP password .................................................................................................. 4 1.4 Session Management ....................................................................................... 4 1.5 Session Timeout ............................................................................................... 5

2 OBJECT TYPES .................................................................................................... 5 2.1 Domain object .................................................................................................. 5

2.1.1 OBJECT ATTRIBUTES .............................................................................. 5 2.1.2 DOMAIN NAMES ....................................................................................... 6 2.1.3 AUTH INFO ............................................................................................... 6 2.1.4 DOMAIN STATUS VALUES ....................................................................... 7

2.2 Contact Object .................................................................................................. 8 2.2.1 OBJECT ATTRIBUTES .............................................................................. 8 2.2.2 CONTACT STATUS VALUES .................................................................... 9 2.2.3 DISCLOSE POLICY ................................................................................ 10

2.3 Host Object ..................................................................................................... 10 2.3.1 OBJECT ATTRIBUTES ............................................................................ 10 2.3.2 OBJECT STATUS VALUES ..................................................................... 10

2.4 DNSSEC ........................................................................................................ 11 3 RELATIONS BETWEEN OBJECT INSTANCES .................................................. 12

3.1 Basic Object Relations ................................................................................... 12 3.2 Object usage constraints ................................................................................ 12 3.3 Additional Constraints .................................................................................... 13

4 TRANSACTIONS ................................................................................................. 13 4.1 Protocol Transactions ..................................................................................... 13

4.1.1 HELLO ..................................................................................................... 13 4.1.2 LOGIN ...................................................................................................... 13 4.1.3 LOGOUT .................................................................................................. 14 4.1.4 POLL ........................................................................................................ 14

4.2 Domain transactions ....................................................................................... 14 4.2.1 CHECK DOMAIN ..................................................................................... 14 4.2.2 INFO DOMAIN ......................................................................................... 15 4.2.3 CREATE DOMAIN ................................................................................... 15 4.2.4 DELETE DOMAIN ................................................................................... 15



4.2.5 RENEW DOMAIN .................................................................................... 16 4.2.6 UPDATE DOMAIN ................................................................................... 16 4.2.7 RESTORE DOMAIN ................................................................................ 16 4.2.8 TRANSFER DOMAIN .............................................................................. 17

4.3 Host transactions ............................................................................................ 21 4.3.1 CHECK HOST ......................................................................................... 21 4.3.2 INFO HOST ............................................................................................. 21 4.3.3 CREATE HOST ....................................................................................... 22 4.3.4 DELETE HOST ........................................................................................ 22 4.3.5 UPDATE HOST ....................................................................................... 22

4.4 Contact transactions ....................................................................................... 22 4.4.1 CHECK CONTACT .................................................................................. 23 4.4.2 INFO CONTACT ...................................................................................... 23 4.4.3 CREATE CONTACT ................................................................................ 23 4.4.4 DELETE CONTACT ................................................................................. 23 4.4.5 UPDATE CONTACT ................................................................................ 23

5 Grace Periods ...................................................................................................... 24 6 Pending Periods ................................................................................................... 25 7 Appendix: gTLD Domain Lifecycle ....................................................................... 26 8 Appendix: Host Lifecycle ...................................................................................... 27

8.1 Internal Host ................................................................................................... 27 8.2 External Hosts ................................................................................................ 29

9 Appendix: EPP queue messages ......................................................................... 29 10 Appendix: Standard EPP Error codes .................................................................. 30

10.1 Reason of error codes ................................................................................ 32



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 5933. 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 (SSL-protocol).

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



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 15.000 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 5731. 2.1.1 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.



§ “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.

2.1.2 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. 2.1.3 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



< U+003C = U+003D > U+003E ? U+003F @ 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).

2.1.4 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 auto-renewals on the object.

Note that some of the above status values restrict the set of allowed transactions on the



domain object. More details about which transaction is affected by which status is contained in RFC 5731. 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 5733. 2.2.1 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.



§ “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 3.1.2 of RFC 5733. Length restrictions of the fields are as specified in the RFC, allowed characters are \x20 - \x7E (except for country code).

o “name” (1): name of individual. o “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).

§ “email” (1): e-mail 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.

2.2.2 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.



§ 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.

2.2.3 DISCLOSE POLICY

EPP allows for a specification of the disclose policy of some of the individual attributes. Im-plemented 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. 2.3.1 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)

2.3.2 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.



§ 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 The “digestType” element must contain an 8bit integer o “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

o 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



on 64 characters length.

o 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 34.10-2001 (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 domain/contact (type=tech) – contact/id

o 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



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 regis-tered 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. 4.1.1 HELLO The client can initiate a Hello transaction anytime, the server will reply with a Greeting. 4.1.2 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 2.9.1.1 of RFC 5730 and the following input data are used:

• clID, assigned by the registry (registrar handle).

• pw, the password.



• 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. 4.1.3 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 2.9.1.2 of RFC 5730 and no input data are needed. The EPP result code 1000 is returned if the transaction was completed successfully. 4.1.4 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 2.9.2.3 of RFC 5730.and object specific information is contained in a resData element. For detailed specification of the resData element see Internet draft https://tools.ietf.org/html/draft-mayrhofer-eppext-servicemessage-00.

4.2 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. 4.2.1 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 3.1.1 of RFC 5731. 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>



§ 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. 4.2.2 INFO DOMAIN

This transaction is used to display a domain name’s delegation date and is specified in Section 3.1.2 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.

4.2.3 CREATE DOMAIN

This transaction is used for a new domain delegation and is specified in section 3.2.1 of RFC 5731. 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 only years are supported

o default value: one year 4.2.4 DELETE DOMAIN

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 3.2.2 of RFC 5731.



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.

4.2.5 RENEW DOMAIN

This transaction extends the validity period of a domain object. The transaction is specified in Section 3.2.3 of RFC 5731. 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.

4.2.6 UPDATE DOMAIN This transaction modifies the attributes of a domain object. The transaction is specified in Section 3.2.5 of RFC 5731. 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:


• 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. 4.2.7 RESTORE DOMAIN For restoring a domain a restore request and a restore report is required as described in RFC 3915. The extension affects the request as well as the response. The full specification is contained in RFC 3915, Section 4.2.5. 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:



• 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. 4.2.8 TRANSFER DOMAIN

The transfer of a domain name includes a set of transactions which are specified in sections 3.1.3 and 3.2.4 of RFC 5731. 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 auto-approved by the Registry. Transfer requests require valid authInfo.



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 3.5+5 <= 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 7.1+4 > 10, and given period <> 1.

REGISTERED(clID=X)

REGISTERED[PENDING TRANSFER](clID=X)

op=request(by Y)

op=reject(by X)

op=cancel(by Y)

op=request(any client)

REGISTERED(clID=Y) op=approve

(by X) Auto-approve(by registry after 5 days of

no action by X)



• “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 9.5 + 1 > 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 6.5+2 < 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:


• 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 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



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 is not in pendingTransfer.



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 is not in pendingTransfer.



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 auto-renew/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



transfer request in the past, the response is 2301.

4.3 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. 4.3.1 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 3.1.1 of RFC 5732. 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 5

4.3.2 INFO HOST This transaction gives information about a registered host object. The transaction is specified in Section 3.1.2 of RFC 5732. 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



• (1) upID

• (1) update

• (1) trDate

4.3.3 CREATE HOST This transaction allows creating a new host object. The transaction is specified in Section 3.2.1 of RFC 5732. 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.

4.3.4 DELETE HOST This transaction deletes a host from the registry and is specified in section 3.2.2 of RFC 5732. 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.

4.3.5 UPDATE HOST This transaction updates an existing host object in the registry and is specified in the section 3.2.5 of RFC 5732. 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



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 3.1.1 of RFC 5733. 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 5.

4.4.2 INFO CONTACT This transaction gives information about a registered contact object. The transaction is specified in Section 3.1.2 of RFC 5733. 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. 4.4.3 CREATE CONTACT This transaction allows creating a new contact. The transaction is specified in Section 3.2.1 of RFC 5733. 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 contains several sub elements (country code ,street, city, …).

• email element.

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.

4.4.4 DELETE CONTACT This transaction deletes a contact object from the registry. The transaction is specified in Section 3.2.2 of RFC 5733. If one of the following conditions occurs, the transaction will fail:

• the contact object is linked with a domain name.


• server/clientDeleteProhibited status is set.

4.4.5 UPDATE CONTACT This transaction updates an existing contact object in the registry. The transaction is specified in Section 3.2.5 of RFC 5733. “Add” and “rem” only apply to status elements (one or more subelements). “Chg” contains the



following subelements: • postalInfo (the Registry supports only “international” address type)

• voice

• fax

• email

• 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:


• 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: http://www.icann.org/en/tlds/agp-policy-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.



• 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 3915. 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 Redemption Period: within the 30 days of this period, the domain can be restored after a delete (if domain outside add grace period).

o 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.

o 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.



7 Appendix: gTLD Domain Lifecycle Figure shows the lifecycle of a domain. Table gives an overview of the different states of a domain, their associated DNS status, typical transactions in the respective state as well as if whois information is available and information on the finger request.

AVAILABLE

REGISTERED

Create domain

Renew domain

REDEMPTION

Delete domain/Expiration

PENDINGDELETE

Domain not restoredwithin 30 days

after 5 days

Restoredomain

PENDING RESTORE

RestoreReport received

Restore Reportnot received

LOCKED

Disputeopened/removed



Delete domain duringadd grace period

Delete locked domain by registry

Figure : Domain Lifecycle

Domain state DNS (NS

records and DS records for delegation)

Allowed Transactions (domain check and domain info are always allowed)

WHOIS info Finger

AVAILABLE No Create domain No Available



REGISTERED Yes* Update domain Transfer domain Delete domain Renew domain

Yes Unavailable

REDEMPTION No Restore domain Yes Unavailable PENDING DELETE

No - Yes Unavailable

PENDING TRANSFER

Yes* Update domain Renew domain

Yes Unavailable

PENDING RESTORE

Yes* Update domain Transfer domain Delete domain Renew domain

Yes Unavailable

Table : Domain state overview (*) Records are only contained in zonefiles if domain is not on serverHold/clientHold and the minimum requirement on linked host objects is met. 8 Appendix: Host Lifecycle

The following figures outline the lifecycle of „host“ objects in the registry. Because the lifecycle of “external” and “internal” hosts are fundamentally different, two figures are provided.

8.1 Internal Host

Internal hosts are affected by transactions on the superordinate domain. In the following figure, bold solid lines indicate states and transactions created by transactions on the host object itself, while dotted lines indicate states created by transactions on the superordinate domain of the host object. When the superordinate domain is deleted within the add grace period, the internal host is immediately deleted.



AVAILABLE

REGISTERED

Create host(superordinate domain must exist)

REGISTERED[PENDINGTRANSFER]

Transfer requested forsuperordinate domain

Transfer of superordinatedomain rejected, cancelled or

accepted

REDEMPTION

Delete ofsuperordinate domain

DeleteHost

Restore ofsuperordinate domain

PENDINGDELETE

30days

5 days

Figure : States of Internal host objects

State of superordinate domain

Glue Records in Zonefile

NS records for domains linked to this host in Zonefile (except for superordinate domain itself)

In Registry Database

Host can be linked to delegations

Allowed Host Transactions (host check and host info are always allowed)

REGISTERED (also pending review for registries with review)

Yes

Yes Yes Yes Update host Delete host*

REDEMPTION Yes Yes Yes Yes Update host Delete host*

PENDING DELETE

No Yes Yes Yes

PENDING RESTORE

Yes Yes Yes Yes Update host Delete host*

PENDING TRANSFER

Yes Yes Yes Yes Update host Delete host*

Table : Allowed Host-Transactions on existing host objects by state of superordinate domain



* Note that delete host is only allowed for unlinked hosts. New internal hosts can only be created when the parent domain is in one of the following states:

• Registered

• Pending Transfer

• Pending Restore

Note that new internal hosts cannot be created when the superordinate domain is in redemption or pending delete.

8.2 External Hosts

External hosts have a much simpler lifecycle, since no transfers are possible on such objects. The lifecycle is outlined below:

AVAILABLE

REGISTERED

Create hostdeletehost

Figure : States of External host objects Note that delete host is only allowed for unlinked hosts. For external hosts, the states AVAILABLE and REGISTERED apply as for internal hosts. 9 Appendix: EPP queue messages

The registry uses the standard EPP poll mechanism as described in RFC 5730 in section 2.9.2.3. This is an example for a queue message: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <pollmsg:content xmlns:pollmsg="pollmsg" xmlns="pollmsg" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <pollmsg:resData> <message xmlns="http://tld-box.at/xmlns/resdata-1.1"



xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" type="DelegationStatusUnset"> <desc>Status(es) removed from domain [nic.TLD]: serverTransferProhibited (additional comment text)</desc> <data> <entry name="domain">nic.TLD</entry> <entry name="status">serverTransferProhibited</entry> <entry name="comment">additional comment text (2014-06-25T10:17:22.000000Z)</entry> </data> </message> </pollmsg:resData> <pollmsg:extension/> <pollmsg:other/> </pollmsg:content> This is a list of possible custom messages:

• Pending action completed %ssuccessfully. %s • URS lock set on domain [%s]: %s • URS suspension set on domain [%s]: %s • URS lock removed from domain [%s]: %s • URS suspension removed from domain [%s]: %s • Status(es) %s %s [%s]: %s • Domain [%s] was deleted. • Pending action completed %ssuccessfully. %s • The following domain%s expired as of %s: %s • Low credit watermark reached, you have only %s credit left. • Deletion of domain %s (name server%s %s) will affect your domain%s: %s • Overdraft! You overdraw your account: %s credit. • Your funds are depleted, you have only %s credit left. • EPP response to a transaction executed on your behalf: <%s> objectname [%s] • EPP response to transaction with client-id [%s] and server-id [%s] • Inbound transfer of %s was APPROVED. • Inbound transfer of %s was AUTO-APPROVED. • Outbound transfer of %s was AUTO-APPROVED. • Outbound transfer of %s was CANCELLED. • Inbound transfer of %s was REJECTED. • Outbound transfer of %s was REQUESTED.

The following domain%s will expire on %s (in %s): %s In addition to those custom messages the registry uses standard TR result messages for transfers and PA result messages when applications are allocated or rejected. 10 Appendix: Standard EPP Error codes

code message 1000 Command completed successfully

1001 Command completed successfully action pending

1300 Command completed successfully no



messages

1301 Command completed successfully ack to dequeue

1500 Command completed successfully ending session

2000 Unknown command 2001 Command syntax error 2002 Command use error 2003 Required parameter missing 2004 Parameter value range error 2005 Parameter value syntax error 2100 Unimplemented protocol version 2101 Unimplemented command 2102 Unimplemented option 2103 Unimplemented extension 2104 Billing failure 2105 Object is not eligible for renewal 2106 Object is not eligible for transfer 2200 Authentication error 2201 Authorization error 2202 Invalid authorization information 2300 Object pending transfer 2301 Object not pending transfer 2302 Object exists 2303 Object does not exist 2304 Object status prohibits operation 2305 Object association prohibits operation 2306 Parameter value policy error 2307 Unimplemented object service 2308 Data management policy violation 2400 Command failed 2500 Command failed server closing connection

2501 Authentication error server closing connection

2502 Session limit exceeded server closing connection



10.1 Reason of error codes

A <REASON> ELEMENT CONTAINING A HUMAN-READABLE MESSAGE THAT DESCRIBES THE REASON FOR THE ERROR.

• Registry::Box::Exception::CannotDeleteLinkedContact: Cannot delete contact [%s] while it is being used. - (code => 2305, message => "Object association prohibits operation");;

• Registry::Box::Exception::CannotDeleteLinkedHost: Cannot delete host [%s] while it is being used. - (code => 2305, message => "Object association prohibits operation");;

• Registry::Box::Exception::CannotExtendExpirationDate: Expiration date cannot be extended by %s years because of %s-year maximum limitation. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::CommandProhibited: Command prohibited because of status [%s]. - (code => 2304, message => "Object status prohibits operation");;

• Registry::Box::Exception::ContactAlreadyExists: Contact with handle [%s] already exists. - (code => 2302, message => "Object exists");;

• Registry::Box::Exception::ContactNameNotWellformed: Name [%s] is not well-formed. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::DNSSECRecordTooLong: DNSSEC RR DS too long [%s], max length is 4000 characters. - (code => 2005, message => "Parameter value syntax error");;

• Registry::Box::Exception::DatabaseAsyncExecuteTimeout: asynchronous execute timeout (%.6fs) for statement [%s] - (code => 2500, message => "Command failed;; server closing connection");;

• Registry::Box::Exception::DatabaseConnect: Cannot connect to database [%s] on host [%s] as user [%s]: %s. - (code => 2500, message => "Command failed;; server closing connection");;

• Registry::Box::Exception::DatabaseConnectionFailure: database connection failed while executing statement [%s]: %s - (code => 2500, message => "Command failed;; server closing connection");;

• Registry::Box::Exception::DomainAlreadyExists: Domain [%s]: Cannot create already existing domain. - (code => 2302, message => "Object exists");;

• Registry::Box::Exception::DomainIsReserved: Domain name [%s] is reserved - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::DomainIsReservedWithAuthInfo: Domain name [%s] is reserved, valid authInfo required - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::DomainNameProhibited: Domain name [%s] is blacklisted - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::DomainNotInPendingRestore: Domain [%s] is not in pendingRestore. - (code => 2002, message => "Command use error");;

• Registry::Box::Exception::DomainNotInRedemption: Domain [%s] is not in redemption. - (code => 2002, message => "Command use error");;

• Registry::Box::Exception::EPP::AdmCtl::AccessSuspended: Access temporarily suspended - administrative limit exceeded. Command/transaction [%s] / timeframe [%s] / limit [%s]. Penalty expires [%s]. - (code => 2201, message => "Authorization error");;

• Registry::Box::Exception::EPP::AdmCtl::CommandLimitExceeded: Command limit exceeded. Command [%s] / timeframe [%s] / limit [%s]. Penalty expires [%s]. - (code => 2201, message => "Authorization error");;

• Registry::Box::Exception::EPP::AdmCtl::IdleSession: Your session appears to be largely idle. Please help preserve server resources by terminating unused sessions. - (code => 2201, message => "Authorization error");;

• Registry::Box::Exception::EPP::Auth::AccountDisabled: Authentication Error. Client [%s]: Account administratively disabled. - (code => 2501, message => "Authentication error;; server closing connection");;



• Registry::Box::Exception::EPP::Auth::NoSuchClient: Authentication Error.Client [%s] is unknown to the Registry. - (code => 2501, message => "Authentication error;; server closing connection");;

• Registry::Box::Exception::EPP::Auth::WrongPassword: Authentication Error. Client [%s]: Password could not be verified. - (code => 2501, message => "Authentication error;; server closing connection");;

• Registry::Box::Exception::EPP::CantOpenLogfile: Died. - (code => 2500, message => "Command failed;; server closing connection");;

• Registry::Box::Exception::EPP::MessageNotOnTop: Message with id [%s] not first in queue. First message has id [%s]. - (code => 2004, message => "Parameter value range error");;

• Registry::Box::Exception::EPP::MessageNotPolledYet: Message with id [%s] has not been polled. - (code => 2002, message => "Command use error");;

• Registry::Box::Exception::EPP::Net::ClientOutOfSync: EPP client is out of sync at network level: %s. - (code => 2500, message => "Command failed;; server closing connection");;

• Registry::Box::Exception::EPP::Net::InvalidHeader: EPP header is invalid: %s. - (code => 2500, message => "Command failed;; server closing connection");;

• Registry::Box::Exception::EPP::Net::ReadTimeout: EPP ReadTimeout: %s. - (code => 2500, message => "Command failed;; server closing connection");;

• Registry::Box::Exception::EPP::NoSuchMessage: Message with id [%s] not found. - (code => 2303, message => "Object does not exist");;

• Registry::Box::Exception::EPP::NoSuchQueuedMessage: No Queued Message with id [%s]. - (code => 2303, message => "Object does not exist");;

• Registry::Box::Exception::EPP::NotLoggedIn: Authorization Error. Not Logged In. - (code => 2501, message => "Authentication error;; server closing connection");;

• Registry::Box::Exception::EPP::Parser::BadXSDLocation: Bad schema location [%s] - (code => 2500, message => "Command failed;; server closing connection");;

• Registry::Box::Exception::EPP::Parser::Error: Parser error at line [%s], column [%s]: %s. - (code => 2001, message => "Command syntax error");;

• Registry::Box::Exception::EPP::Parser::FatalError: Fatal parser error at line [%s], column [%s]: %s. - (code => 2001, message => "Command syntax error");;

• Registry::Box::Exception::EPP::Protocol::BadCmd: Protocol error. "%s"(need command, hello or extension) - (code => 2001, message => "Command syntax error");;

• Registry::Box::Exception::EPP::Protocol::CmdAttributeError: Protocol error. Attribute [%s] missing or invalid. - (code => 2001, message => "Command syntax error");;

• Registry::Box::Exception::EPP::Protocol::CmdAttributeIllegal: Protocol error. Illegal Attribute [%s]. - (code => 2001, message => "Command syntax error");;

• Registry::Box::Exception::EPP::Protocol::DoublePostalInfo: Protocol error. Only one "postalInfo" section is allowed. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::EPP::Protocol::EmptyDiscloseSection: Disclose section does not contain any elements. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::EPP::Protocol::HostAttrNotSupported: Protocol error. Host attributes are not supported. - (code => 2307, message => "Unimplemented object service");;

• Registry::Box::Exception::EPP::Protocol::IllegalStatus: Protocol error. Illegal status value [%s]. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::EPP::Protocol::IllegalUpdateCombination: Protocol error. Attempted combination of mutually exclusive update operations. - (code => 2001, message => "Command syntax error");;

• Registry::Box::Exception::EPP::Protocol::InvalidAuthInfo: Invalid authorization information. - (code => 2202, message => "Invalid authorization information");;

• Registry::Box::Exception::EPP::Protocol::InvalidCharacter: Invalid character(s) in field [%s]. - (code => 2005, message => "Parameter value syntax error");;

• Registry::Box::Exception::EPP::Protocol::MissingRGPReport: Protocol error. Restore report missing. - (code => 2001, message => "Command syntax error");;

• Registry::Box::Exception::EPP::Protocol::NoAuthInfoExtSupport: Protocol error. AuthInfo extension is not supported. - (code => 2103, message => "Unimplemented extension");;



• Registry::Box::Exception::EPP::Protocol::NoAuthInfoNullSupport: Protocol error. AuthInfo reset is not supported. - (code => 2307, message => "Unimplemented object service");;

• Registry::Box::Exception::EPP::Protocol::NoAuthInfoSupport: Protocol error. Authorization information is not supported for this command. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::EPP::Protocol::NoUpdateOperation: Protocol error. Frame contains no update operation. - (code => 2001, message => "Command syntax error");;

• Registry::Box::Exception::EPP::Protocol::PostalInfoNotInt: Protocol error. "postalInfo" must be of type "int". - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::EPP::Protocol::UnmatchedCmd: Protocol error.Command mismatch: [%s] vs. [%s (%s)]. - (code => 2001, message => "Command syntax error");;

• Registry::Box::Exception::EPP::Protocol::UnsupportedChg: Protocol error.Unsupported 'chg' operation. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::EPP::Protocol::UnsupportedCmd: Protocol error.Command "%s" is not supported. - (code => 2000, message => "Unknown command");;

• Registry::Box::Exception::EPP::Protocol::UnsupportedCmdOptValue:Protocol error. Value [%s] on option [%s] for command [%s (%s)] is not supported. - (code => 2102, message => "Unimplemented option");;

• Registry::Box::Exception::EPP::Protocol::UnsupportedContactAuthInfo:Contact authorization information is not supported. - (code => 2307, message => "Unimplemented object service");;

• Registry::Box::Exception::EPP::Protocol::UnsupportedContactType: Contact type [%s] is not supported. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::EPP::Protocol::UnsupportedDisclose: Protocol error. Setting the disclosure policy for field %s is not supported. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::EPP::Protocol::UnsupportedExtension: Protocol error. Unsupported extension for command "%s": "%s %s". - (code => 2001, message => "Command syntax error");;

• Registry::Box::Exception::EPP::Protocol::UnsupportedNS: Protocol error. Unknown/unsupported object namespace "%s". - (code => 2103, message => "Unimplemented extension");;

• Registry::Box::Exception::EPP::Protocol::UnsupportedObjCmd: Protocol error. Command [%s] for object [%s] is not supported. - (code => 2101, message => "Unimplemented command");;

• Registry::Box::Exception::EPP::Protocol::UnsupportedRGPReport: Protocol error. Operation 'report' is not supported with rgp:restore. - (code => 2103, message => "Unimplemented extension");;

• Registry::Box::Exception::EPP::RedundantLogin: Already Logged In. - (code => 2002, message => "Command use error");;

• Registry::Box::Exception::EPP::SuExtFormatError: Reserved Extension Format Error: [%s]. - (code => 2500, message => "Command failed;; server closing connection");;

• Registry::Box::Exception::EPP::TooManySessions: Session Limit Exceeded [%s]. %s. - (code => 2502, message => "Session limit exceeded;; server closing connection");;

• Registry::Box::Exception::EmptyMandatoryField: Field [%s] is mandatory. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::ExtensionWithoutBaseNumber: Field [%s] has an extension, but no base number. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::HostAlreadyExists: Host [%s]: Cannot create already existing host. - (code => 2302, message => "Object exists");;

• Registry::Box::Exception::InsufficientCredit: This [%s] ticket would cost [%s] but [%s] does not have enough credit - (code => 2104, message => "Billing failure");;

• Registry::Box::Exception::InvalidCharacter: Invalid character(s) in field [%s]. - (code => 2005, message => "Parameter value syntax error");;

• Registry::Box::Exception::InvalidContactName: Invalid name [%s]. - (code => 2005, message => "Parameter value syntax error");;

• Registry::Box::Exception::InvalidCountry: Invalid country [%s]. - (code => 2306, message => "Parameter value policy error");;



• Registry::Box::Exception::InvalidDNSSECAlg: Invalid Algorithm [%s]. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::InvalidDNSSECDigest: Invalid Digest [%s]. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::InvalidDNSSECDigestLength: DNSSEC RR Digest length for type [%s] is invalid, should have a length of [%s] characters. - (code => 2005, message => "Parameter value syntax error");;

• Registry::Box::Exception::InvalidDNSSECDigestType: Invalid Digest Type [%s]. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::InvalidDNSSECKeyTag: Invalid Key Tag [%s]. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::InvalidIPAddress: Invalid IP address [%s]. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::InvalidParameters: %s - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::LockResourceBusy: Locking resource [%s] failed. - (code => 2304, message => "Object status prohibits operation");;

• Registry::Box::Exception::MalformedAmount: Malformed amount [%s] - (code => 2004, message => "Parameter value range error");;

• Registry::Box::Exception::MalformedHandle: Malformed handle [%s]. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::Misconfiguration: Misconfiguration: %s. - (code => 2500, message => "Command failed;; server closing connection");;

• Registry::Box::Exception::NoBillFound: Did not find a bill for ticket [%s], details %s - (code => 2303, message => "Object does not exist");;

• Registry::Box::Exception::NoEmptyAuthInfo: Authorization information cannot be empty. - (code => 2202, message => "Invalid authorization information");;

• Registry::Box::Exception::NoSuchSubCommand: No such subcommand [%s]. - (code => 2500, message => "Command failed;; server closing connection");;

• Registry::Box::Exception::ObjectCannotBeProvisioned: The object [%s] cannot be provisioned. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::ObjectExists: %s [%s] already exists. - (code => 2302, message => "Object exists");;

• Registry::Box::Exception::ObjectNotFound: %s [%s] not found. - (code => 2303, message => "Object does not exist");;

• Registry::Box::Exception::OnlyRequestingRegistrarCanCancelTransfer: Only the requesting registrar can cancel a transfer. - (code => 2201, message => "Authorization error");;

• Registry::Box::Exception::OnlySponsoringRegistrarCanApproveTransfer: Only the sponsoring registrar can approve a transfer. - (code => 2201, message => "Authorization error");;

• Registry::Box::Exception::OnlySponsoringRegistrarCanRejectTransfer: Only the sponsoring registrar can reject a transfer. - (code => 2201, message => "Authorization error");;

• Registry::Box::Exception::PDOCannotBeProvisioned: Malformed parent domain [%s]. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::PDODenied: Registrar [%s] is not allowed to operate on parent domain [%s] - (code => 2201, message => "Authorization error");;

• Registry::Box::Exception::PeriodTooLong: A domain can only be registered for [%s] at most. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::PermissionDenied: Permission denied on object [%s] for registrar [%s], belongs to registrar [%s]. - (code => 2201, message => "Authorization error");;

• Registry::Box::Exception::PluginParameter: Plugin [%s]: Invalid value [%s] for parameter [%s]. - (code => 2500, message => "Command failed;; server closing connection");;

• Registry::Box::Exception::ReferencedContactNotFound: The referenced contact [%s] does not exist. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::ReferencedHostNotFound: The referenced host [%s] does not exist. - (code => 2306, message => "Parameter value policy error");;



• Registry::Box::Exception::RequiredParameterMissing: Required parameter(s) missing: [%s]. - (code => 2003, message => "Required parameter missing");;

• Registry::Box::Exception::Router::InvalidPhase: No such active phase [%s], phase_name [%s], received_date [%s]. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::Router::Refused: Command refused for phase [%s], phase_name [%s], received_date [%s]. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::StatusConflict: Status values [%s] and [%s] are in conflict. - (code => 2304, message => "Object status prohibits operation");;

• Registry::Box::Exception::SuperordinateDomainIsInRedemption: The host's superordinate domain [%s] is in redemption. - (code => 2304, message => "Object status prohibits operation");;

• Registry::Box::Exception::SuperordinateDomainIsInTransfer: The host's superordinate domain [%s] is in transfer. - (code => 2304, message => "Object status prohibits operation");;

• Registry::Box::Exception::SuperordinateDomainNotFound: The host's superordinate domain [%s] does not exist. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::TMCH::AllocationFailed: Application could not be allocated: %s - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::ApplicationNotPending: Application [%s] does not have the required status(es) [%s]. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::CheckClaimsNotActive: Claims check is currently disabled. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::CheckUnprovisionableDomain: Check command lists unprovisionable domain [%s]. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::CheckUnsupportedPhase: Unsupported check phase [%s], name [%s]. Only 'claims' is supported. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::CheckUnsupportedType: Unsupported check type [%s]. Only 'claims' is supported. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::ClaimsAcceptedDateInTheFuture: Claim acceptance date is in the future. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::ClaimsAcceptedDateTooLongAgo: Claim acceptance date is too long ago. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::ClaimsDisabled: Claims not active in route. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::ClaimsInvalidChecksum: Claims noticeID contains invalid checksum [%s]. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::ClaimsNoticeExpired: Claims notice was received on [%s], which is too late. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::ClaimsNoticeRequired: Claims notice is required for label [%s]. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::ClaimsUnknownLabel: Claimed label [%s] does not exist in DNL. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::InvalidEncodedSignedMarkContent: Encoded Signed Mark contains invalid data. - (code => 2005, message => "Parameter value syntax error");;

• Registry::Box::Exception::TMCH::LabelNotInSMD: Domain label [%s] not in SMD. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::LaunchCreateTypeMismatch: Command would not result in object type [%s]. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::MultipleSMDs: Only one SMD is supported. – (code => 2102, message => "Unimplemented option");;

• Registry::Box::Exception::TMCH::SMD::Expired: SMD has expired. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::SMD::Invalid: SMD is invalid: [%s] - (code => 2308, message => "Data management policy violation");;



• Registry::Box::Exception::TMCH::SMD::NotValidYet: SMD validity period has not started yet. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::SMD::Revoked: SMD [%s] is revoked. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::SMD::TMVrevoked: TMV is revoked - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::SMDDisallowed: SMDs are disallowed for phase. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::SMDOutsideJurisdiction: SMD is not valid for jurisdiction(s) [%s]. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::SMDRequired: Required SMD not found. - (code => 2308, message => "Data management policy violation");;

• Registry::Box::Exception::TMCH::UnsupportedCreateForm: Unsupported create form: %s - (code => 2102, message => "Unimplemented option");;

• Registry::Box::Exception::TransferAlreadyPending: A transfer for this domain is already pending. - (code => 2300, message => "Object pending transfer");;

• Registry::Box::Exception::TransferNotPending: There is no pending transfer for this domain. - (code => 2301, message => "Object not pending transfer");;

• Registry::Box::Exception::UnsupportedContactStatus: A contact cannot have the status [%s]. - (code => 2102, message => "Unimplemented option");;

• Registry::Box::Exception::UnsupportedDNSSECOption: Unsupported DNSSEC option [%s]. - (code => 2102, message => "Unimplemented option");;

• Registry::Box::Exception::UnsupportedDomainStatus: A domain cannot have the status [%s]. - (code => 2102, message => "Unimplemented option");;

• Registry::Box::Exception::UnsupportedHostStatus: A host cannot have the status [%s]. - (code => 2102, message => "Unimplemented option");;

• Registry::Box::Exception::UnsupportedPeriodUnit: Only the period unit 'y' is supported. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::UnsupportedTLD: The object [%s] has an unsupported TLD. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::UnsupportedTransferPeriod: The transfer period must be one year. - (code => 2004, message => "Parameter value range error");;

• Registry::Box::Exception::ValueNotWellformed: Value [%s] is not well-formed for field [%s]. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::ValueTooLong: Value is too long for field [%s]. - (code => 2306, message => "Parameter value policy error");;

• Registry::Box::Exception::WrongCurrentExpirationDate: The current expiration date is [%s]. - (code => 2306, message => "Parameter value policy error");;

registrar manual epp

Documents