Skip to content

Punktum-dk/epp-service-specification

BranchesTags

Repository files navigation

Punktum dk Logo

Punktum dk EPP Service Specification

Markdownlint Action Spellcheck Action

2021-12-06 Revision: 4.4

Table of Contents

Introduction

This document describes and specifies the implementation offered by Punktum dk for interaction with the central registry for the ccTLD dk using the Extensible Provisioning Protocol (EPP). It is primarily aimed at a technical audience, and the reader is required to have prior knowledge of DNS registration and administration and EPP.

About this Document

This specification describes version 4.X.X of the Punktum dk EPP Implementation. Future releases will be reflected in updates to this specification, please see the Document History section below.

The document describes the current Punktum dk EPP implementation, for more general documentation on the EPP protocol, EPP client development or configuration, please refer to the RFCs and additional resources in the References and Resources chapters below.

Do note that the specification aims to describes the latest release of the service. Service version is listed in the Document History, so given changes implemented in the service are reflected in the specification. Do note that a service might be released to the sandbox environment prior to being released to production after a grace period.

This document is not the authoritative source for business and policy rules and possible discrepancies between this an any authoritative sources are regarded as errors in this document. This document is aimed at being the external technical specification and describes the implementation facing the users and is an interpretation of authoritative sources and can therefor be erroneous.

The actively used XSD file is indicated in the EPP service specification, the EPP XSD file repository might contain changes not actively used by the service.

The current service version can be obtained from the Greeting message, from the service.

Any future extensions and possible additions and changes to the implementation are not within the scope of this document and will not be discussed or mentioned throughout this document.

The specification mentions the Registrar Portal service (RP), which complements the EPP service for consistency between services.

This document is owned and maintained by Punktum dk A/S and must not be distributed without this information.

All examples provided in the document are fabricated/modified from real data to demonstrate commands etc. any resemblance to actual data are coincidental.

Diagrams to support feature descriptions can be seen by clicking the 👁️‍🗨️ icon, where made available.

License

This document is copyright by Punktum dk A/S and is licensed under the MIT License, please see the separate LICENSE file for details.

Document History

  • 4.4 2021-12-06

  • 4.3 2021-10-25

  • 4.2 2021-10-21

  • 4.1 2021-09-24

    • Added documentation for new error scenario for create domain for a registrar managed domain name, specifying other contacts than the registrant will result in an error 2306
    • Added a description of possible challenge with auto matching user for create contact, since ID-control can alter data as part of the validation
    • This revision of the specification describes version 4.0.2 of the EPP service

  • 4.0 2021-09-19

    • Introduction of support for registrar/registrant administration
    • Outlined business rules for dkhm:orderconfirmationToken
    • The procedures for renewal and application/creation are not being changed, in regard to use and protocol, however
      • The business policies in relation to these operations, do however change, since the billing operation changes, please see the create domain and renew domain commands
      • The introduction of registrar support influences the business rules for create domain
    • Added information on setting/unsetting autorizations using AuthInfo tokens, see setting AuthInfo and unsetting AuthInfo
    • Added information on dkhm:management extension for create domain and create contact, which overrides account default
    • Added description of new and improved change name server process, both using authorisation and under registrar administration
    • Added documentation on the extension to info domain with information on the AuthInfo expiration date using the dkhm:authInfoExDate extension
    • Added description of the changed create contact process, handling registrar administration
    • Introduction of support for delete domain command
    • Introduction of support for restore domain via update domain command
    • Introduction of support for balance command
    • Introduction of support for transfer domain command
    • Added clarifications on status codes for domains, contacts and hosts
    • Removed XSD Version History, referencing original source in EPP XSD repository, so there is a single source for this information
    • This version of the specification is based on the Punktum dk EPP XSD version 4.3
    • Addition of disclaimer, setting the scope and frame for this specification
    • Addition of Feature and Meta-role Matrix
    • This revision of the specification describes version 4.0.0 of the EPP service

  • 3.9 2020-10-19

    • Added some details on sessions in the section on login

  • 3.8 2020-04-21

    • Aligned XSD versions in all examples to version 3.0

  • 3.7 2020-04-04

    • Revised information on IP whitelisting

  • 3.6 2020-01-23

    • Cleaned and aligned XSD versions in all examples, currently using version 2.6
    • Added clarifications and examples on advisories extension, used in info domain

  • 3.5 2020-01-09

    • Updated with information on XSD version 3.0
    • Introduced in release 3.4.0 of the EPP service

  • 3.4 2019-10-18

  • 3.3 2019-09-09

    • Update to info domain, example response updated, it now contains DNSSEC data
    • Added clarifications on DNSSEC data availability, even though it is limited currently
    • Added information on the EPP Service Specification Wiki for operation reference information
    • Corrected spelling errors and other minor issues

  • 3.2 2019-07-29

    • Clarification to create contact, removed obsolete description of attention field rule for registrants

  • 3.1 2019-05-07

    • Minor update documenting changes introduced in release 3.2.X of the EPP service
    • Update to info domain extended with registrant validation status
    • Update to info contact extended with e-mail address for the contact object, where applicable
    • Update to info domain extended with DNSSEC information
    • Update to create contact more strict handling of VAT numbers, see table specifying the use of the field in: CVR / Vat Number Indication
    • Update to update domain documentation on deletion and addition of DNSSEC records

  • 3.0 2019-04-30

    • Major update based on the changes with major release 3.X.X of the EPP service
    • Documenting removal of public access to information on non-registrant users for contact objects (users)
    • Documenting removal of public access to information on name server contacts for host objects (name servers)

  • 2.16 2019-01-11

    • Updated info domain to capability to provide information on the billing contact, when applicable

  • 2.15 2018-12-03

    • Added information on the new consolidated sandbox environment
    • Corrected some spelling and grammatical errors

  • 2.14 2018-11-21

    • Updated information on sandbox environment, latest changes to domain creation emulation had not been added

  • 2.13 2018-11-08

  • 2.12 2018-10-29

  • 2.11 2018-10-23

    • Added more information on the rules and errors codes related to renew domain

  • 2.10 2018-10-08

    • Added more information on create host command and the use of extension versus authentication for specification of name server administrator.

  • 2.9 2018-10-03

    • Added diagram for contact creation revision 1.0, please see the create contact command section

  • 2.8 2018-09-18

    • Removed pointers to the decommissioned pre-activation service and pre-activation service specification

  • 2.7 2018-09-11

    • Minor correction, to the reason (status) for domains offered from waiting list, since the reason did not comply with the XSD definition. The reason is corrected in EPP service version: EPP 2.4.2

  • 2.6 2018-08-22

    • Describes EPP service 2.4.X
    • Added information on reason (status) enqueued for check domain command
    • Added information on silenced out of band communication for change of billing contact for a domain

  • 2.5 2018-06-22

    • Updated XSD history and information on XSD version 2.4
    • Added information on service and specification versions and retrieving of version information from the service
    • Added examples of poll messages related to domain creation

  • 2.4 2018-05-25

    • Added information on format of the orderconfirmation Token, this is implemented with EPP release 2.3.0 currently only available in sandbox and introduces the new extension: dkhm:url
    • Addition of risk assessment for create domain command poll response. The XSD files revision 2.2 describes the changes to the XSD and supports the new extension: dkhm:risk_assessment

  • 2.3 2018-05-01

  • 2.2 2017-12-19

    • Removed information on status blocked, which has been deprecated

  • 2.1 2017-06-08

    • Removed information on waiting list handling, since this is being revisited

  • 2.0 2016-10-24

    • Describes EPP service 2.X.X
    • Added renew domain description
    • Added update domain description
    • Added create/update/delete host descriptions
    • Added update contact description
    • Added XSD 2.0 description

  • 1.10 2016-06-08

    • Added information on IP whitelisting

  • 1.9 2016-01-30

    • Information on new waiting list handling
    • Information on new DNSSEC key handling

  • 1.8 2015-09-03

    • Minor corrections
    • More information on extensions for possible registration of the Punktum dk extensions with IANA in relation to RFC:7451
    • Added RFC:7451 compliant descriptions in subdirectory: rfc7451/

  • 1.7 2015-05-12

    • This revision of the specification is describing EPP service release 1.3.X
    • This release also updates the XSD specification to revision 1.4, introducing the extension pnumber for transport of production unit numbers for validation of Danish companies as part of the create contact command

  • 1.6 2015-01-06

    • This revision of the specification is describing EPP service release 1.2.X
    • This release also updates the XSD specification to revision 1.3
    • The document has with this revision been ported from a proprietary format to markdown and is being hosted on GitHub for easier maintenance and distribution, this has resulted in a lot of minor corrections and clarifications.
    • Extended the section about this document, due to the migration to GitHub, so copyright is now explicitly mentioned
    • info contact command extended with validation information
    • create domain command extended with validation information for registrant
    • create domain command extended with information on confirmation status for domain

  • 1.5 2014-06-18

    • This revision of the specification is describing EPP service release 1.1.X
    • The test environment is no longer active
    • Examples updated to latest XSD revision (1.2)
    • Pre-activation token (orderconfirmationToken) can be transported via extension for create domain command

  • 1.4 2013-11-19

    • Corrected links in resources
    • Emphasized the use of the auto keyword for contact creation, this has also been listed in the implementation limitations section
    • Added information on the restrictive use of clTRID in new section entitled: Implementation Requirements

  • 1.3 2013-10-29

    • This revision of the specification is describing EPP service release 1.0.9
    • Added information on use of clTRID in context of create domain command
    • Added more information on the domain check command, which has been extended with EPP service release 1.0.9.
    • This release also updates the XSD specification to revision 1.1

  • 1.2 2013-08-07

    • This revision of the specification is describing EPP service release 1.0.8
    • Added note on domain check

  • 1.1 2013-05-31

    • Added paragraph on passwords in section on the login command
    • Added mention of standard port 700
    • Corrected some of the XML examples, which had not been updated to reflect the correct use of XSDs
    • Added important note on contact creation

  • 1.0 2013-02-25

    • Initial revision
    • Describes EPP service 1.X.X
    • Introduces XSD specification revision 1.0

The .dk Registry in Brief

Punktum dk is the registry for the ccTLD for Denmark (dk), with Punktum dk maintaining the central DNS registry.

The legislation and registry model utilized in Denmark imposes some limitations compared to the general scope of the EPP protocol. These limitations are described in detail below in the chapter entitled Implementation Limitations, and these are explained further in the command descriptions where the single commands deviate from the EPP standard specification. In addition to limitations and deviations in the mentioned sections, a few others have been implemented to support DNS registration under Danish legislation, these are described in detail under the individual commands where relevant.

Punktum dk offer two administration models, please see the complete description of the concept of the administration models offered by Punktum dk A/S for details.

In brief the two models are:

  • Registrar managed, where the registrar takes the administrative role of the domain name and administers the assets with Punktum dk "registrar management"
  • Registrant managed, where the registrant administers the assets directly with Punktum dk, also referred to as: "registrant management"

The EPP service is the same, but the capabilities and business roles vary depending on choice of administrative model. This is described in detail under the different commands and outlined in:

Our EPP extensions are registered with the IANA EPP Extension Repository as by RFC:7451.

EPP in Brief

EPP is an XML-based protocol aimed at provisioning data between registries. The protocol is intended for machine-to-machine communication in a client-server setup. Please see the References chapter for more information on specifications and references for EPP.

Please note that the service does not support XML entity expansion on the server side, due to security implications related to this feature.

EPP Service

The Punktum dk’s EPP Service implementation is regarded as a service offered to external parties requiring provisioning actions towards Punktum dk.

The EPP service requires the use of and possible development of EPP client software. This is beyond the scope of this specification as the API and other assets for assisting in this are the primary object of this document.

In addition to the assets, Punktum dk aims to assist users and developers of EPP client software with integration towards Punktum dk and therefore provide facilities to ease this integration. This is primarily centered around a sandbox environment and related documentation.

The service is implemented under the following principles:

1 Adhere to the standard to the extent possible or use non-intrusive extensions to support the requirements or finally use mandatory extensions to adhere to service requirements 1 Use in-band communication, meaning requests made via EPP will be responded to via EPP unless the end-user have specified differently 1 Use standard error codes to the extent possible, communicating state more clearly and unambiguously

SSL/TLS Support

The EPP service supports the following protocols for transport security:

  • TLSv1.2

Available Environments

Punktum dk offers the following two environments:

  • production
  • sandbox

Updates to both environments are announced via the tech-announce mailing list.

Please see the information page for details on subscribing etc.

Production

  • Please see EPP service specification Wiki for up to date information for the production environment accessible at: epp.dk-hostmaster.dk on port: 700

  • This environment is the production environment

  • info and check requests made to this environment will reflect live production data

  • create requests made to this environment will be carried out provided that they comply with business rules and general terms

  • Approved domains will be processed for possible activation and propagation into the zone

  • Contacts (users) will be created and will be available in other systems like the self-service system etc.

  • Hosts (name servers) will be processed for possible activation

  • The Change Password operation is available in this environment

  • Please note that this operation will change the password and this change will be reflected in other production systems

  • This is environment is using IP Whitelisting

  • This environment is only available to registrars

Sandbox

  • Please see EPP service specification Wiki for up to date information for the production environment accessible at : epp-sandbox.dk-hostmaster.dk on port: 700

  • This environment is intended for client development towards the Punktum dk EPP service

  • info and check requests made to this environment will reflect sandbox data. For host objects, some static content synched in by Punktum dk, in addition to sandbox data

  • create requests made to this environment will be serialized in the sandbox environment, provided that syntax and data are valid

  • Domains will be enqueued and are processed for possible activation, responses are reflected in messages available for polling, propagation into a zone file is not supported

  • Contacts (users) can be created and will only be available in the sandbox system

  • The Change Password operation will only change the password in the sandbox environment

  • This environment is available to both registrars and name server administrators

Please note that when you first start to use the EPP sandbox environment, the access credentials are matching your production credentials. If these do not work as expected (e.g. error 2200). please contact: Punktum dk to get the credentials synchronized.

For more information on the consolidated sandbox environment please see the specification.

Implementation Requirements

This section outlines the overall requirements in regard to implementing an EPP client to work with the Punktum dk EPP service.

Client Transaction ID (clTRID)

In order to ensure transactional integrity and due to the asynchronous nature of some of the EPP commands, we rely on the client transaction id to be unique. This is unique as per client id. The assists in ensuring that a delayed response can be easily identified by simple means.

The clTRID is recommended to be unique for all transactions and is required to be unique for the create domain command.

IP Whitelisting

Access to the EPP service production environment requires IP whitelisting of IP addresses.

Maintenance of IP addresses is done in the Registrar Portal (RP) and requires an active registrar account for access.

Please see the Registrar Portal Service Specification for details.

Service Users

Access to the EPP service production environment requires IP whitelisting of IP addresses.

Creation and maintenance of service users has to be done in the Registrar Portal (RP) and requires an active registrar account for access.

Please see the Registrar Portal Service Specification for details.

Registrar Account Settings

The EPP service can not work directly the registrar account, only directly on objects such as:

  • domain names
  • contacts
  • name servers (hosts)

Many of the object related commands are working indirectly with the registrar account for:

  • billable operations
  • change of relations between objects

The EPP does not have any commands that work on the account level, except for the balance command, please see the section: "Balance and Prepaid Account" for details.

create domain, create contact and create host are reacting to the the setting of the default management model. Settings can be overwritten using extension:

create domain is reacting to the the setting of the default renewal model. Settings can be changed used extension:

Specification and setting if registrar account settings are reserved to the Registrar Portal (RP) and requires an active registrar account for access.

Please see the Registrar Portal Service Specification for details.

Implementation Extensions

The EPP service implemented by Punktum dk holds several extensions, these are documented where appropriate for the specific commands etc. This section serves to give an overview of the extensions as a whole.

Please refer to the EPP XSD file repository for implementation details.

Here follows a list of the extensions in alphabetical order. All are described separately and in detail below.

  • dkhm:authInfoExDate
  • dkhm:autoRenew
  • dkhm:delDate
  • dkhm:contact_validated
  • dkhm:CVR
  • dkhm:domain_confirmed
  • dkhm:domainAdvisory
  • dkhm:EAN
  • dkhm:management
  • dkhm:mobilephone
  • dkhm:orderconfirmationToken
  • dkhm:pnumber
  • dkhm:registrant_validated
  • dkhm:requestedNsAdmin
  • dkhm:risk_assessment
  • dkhm:secondaryEmail
  • dkhm:trackingNo
  • dkhm:url
  • dkhm:userType

dkhm:authInfoExDate

This extension is used to expose the expiration date for a AuthInfo token if set for a domain name.

Please see:

dkhm:autoRenew

This extension is used to expose the auto-renewal flag for a domain name.

Please see:

The choice of renewal policy is based on the registrar account default for the specific registrar account. The default can be overridden per request or application using the extension: dkhm:autoRenew, which support two values:

  • true, indicating auto-renewal
  • false, indicating auto-expire

The default for a registrar account is auto-renewal. A new default can be set in the registrar portal.

dkhm:contact_validated

Contact objects related to the role of registrant has to be validated, this field is used to indicate the status of a validation of a contact object via the info contact command.

dkhm:CVR

The CVR extension is for transporting VAT registration numbers. The number is used for validation and VAT accounting. More information is available under the create contact command.

dkhm:delDate

<extension>
    <dkhm:delDate xmlns:dkhm="urn:dkhm:xml:ns:dkhm-4.3">2021-01-31T00:00:00.0Z</dkhm:delDate>
</extension>

Please see:

dkhm:domain_confirmed

Domain names registered with Punktum dk, has to be confirmed by the registrant, this is can either be done using pre-application agreement to Punktum dk's Terms and Conditions, see the dkhm:orderconfirmationToken extension or other systems with Punktum dk. The domain confirmation process is handled via via the create domain command using this extension.

dkhm:domainAdvisory

Any special circumstances in relation to a domain name, can be communicated using this special field. Please see info domain.

Currently two advisories are communicated:

  • pendingDeletionDate, indicating that a given domain name is scheduled for deletion
  • offeredOnWaitingList, indicating that a given domain name has been offered to a designated registrant

Domain names pending deletion are in a 30 day redemption period. This period can be initiated by:

  • Automatic expiration, see dkhm:autoRenew
  • Manual cancellation, for EPP via the delete domain command
  • Deletion from suspension due lack of payment

Through out the redemption period it is possible to restore the domain using the restore domain.

Domain names offered on waiting list, has to be registered using create domain as for regular domain name applications.

dkhm:EAN

The EAN extension, holds the EAN number associated with public organizations in Denmark. The field is mandatory for this type of contact objects and is required for electronic invoicing, more information is available under the create contact command.

dkhm:management

The choice of administration model is based on the registrar account default for the specific registrar account. The default can be overridden per request or application using the extension: dkhm:management, which support two values:

  • registrar, indicating registrar management
  • registrant, indicating registrant management

The extension can be used with the commands:

If not specified the default of the registrar account will be used. The default can be set in the registrar portal, see: Registrar Account Settings.

To change the management model for an existing domain, please see the transfer domain command.

dkhm:mobilephone

Contact objects can have a mobile phone number in addition to voice and fax.

dkhm:orderconfirmationToken

This is a special field for supporting the business flow where the agreement for a domain name is accepted by the registrant with the registrar. More information is available under the create domain command.

See also: dkhm:domain_confirmed

dkhm:pnumber

The p-number extension is for holding production-unit numbers, used for validation for Danish companies, with more physical addresses related to a single VAT number. More information is available under the create contact command.

See also: dkhm:CVR

dkhm:registrant_validated

Contact objects related to the role of registrant has to be validated and possibly ID-controlled, this field is used to indicate the status of a validation object via the create domain command.

See also contact_validated.

The procedures for ID-control are described on the Punktum dk DK website.

dkhm:requestedNsAdmin

The extension is used for update host and create host, where it is possible to request another name server administrator than the authenticated user.

dkhm:risk_assessment

This extension is used in the poll response in relation to domain creation. The extension provides information on the risk assessment made by Punktum dk.

Please see the create domain command.

dkhm:secondaryEmail

Contact objects can have a secondary email address in addition to email.

dkhm:trackingNo

A unique tracking number for a domain registration for uniformity with RP. EPP it not the only channel of domain registration and in order to handle registrations via multiple channels, a unique tracking-id is assigned to every request. More information is available under the create domain command.

dkhm:url

This extension can be used to redirect an end-user to the next step. For now it is used in relation to domain creation, where the user can be directed to the next step if this is handled by Punktum dk. More information is available under the create domain command.

dkhm:userType

The userType extension is used to categorize a contact type, since the requirements for data differs between the different user types, we need to be able to differentiate between:

  • company
  • individual
  • public organization
  • association

More information is available under the create contact command.

Related extensions are dkhm:EAN, dkhm:CVR and dkhm:pnumber.

Implementation Limitations

As mentioned the Punktum dk EPP service implementation comes with some limitations. Please see the Compatibility Matrix in the appendices for a high-level overview.

In general the service is not localized and all EPP related errors and messages are provided in English.

Authentication

The Punktum dk EPP service, only support username/password authentication.

See also the login command for details and the section on Service Users.

AuthInfo

AuthInfo in limited to providing authorizations for 3rd. parties.

It is currently supported for the following commands:

Please see the individual command descriptions for more details.

For registration of domain names offered from a waiting list, the AuthInfo field is utilized for the create domain, the format of the token is however in this context is simpler.

Specifying AuthInfo for a contact create has no effect and it is not recommended to disclose this information in this command.

From RFC:5733:

A contact:authInfo element that contains authorization information to be associated with the contact object. This mapping includes a password-based authentication mechanism, but the schema allows new mechanisms to be defined in new schemas.

The element is not optional, but mandatory, it should not be populated with sensitive information.

Contact Creation

This command does not support the feature of providing a predefined contact-id. The contact-id has to be specified as auto and the contact-id is assigned by Punktum dk. See also information on the create contact command.

Due to a limitation in the AAA system implemented by Punktum dk, it is currently not possible to see contact objects using info contact, if these are not registrants. This is regarded as a temporarily limitation, which will be addressed at some point in the future. The recommendation is to use check contact.

REF: issue #34

Contact Info

The command info contact will only supply the registrant information. For other contact objects, only if the requesting user and authenticated has a relationship to the designated contact object, either via a host or domain role or registrar group.

Contact Update

This command does not support the setting and removal of status using the XML element: contact:status. The status is assigned by Punktum dk. See also information on the update contact command and the appendix with Contact Status Codes.

Disclosure of Client ID

As specified in RFC:5731, RFC:5732 and RFC:5733 the info commands all display a reference sponsoring entity.

The same scheme will be implemented in the Registrar Portal (SB) and the end-user self-service portal (SB) the data presentation is consistent across all portals.

The public facing interface is expected to present the registrar relation as well. Meaning that the information on registrar relation will be made available in:

The following commands for more details:

DNSSEC

I accordance with RFC:5910. We support DS only and not DNSKEY. In addition the maximum signature lifetime (secDNS:maxSigLife) is disregarded. See section 3.3) in the referenced RFC.

Not all algorithms are supported, please refer to the Punktum dk Name Service specification for a complete list of supported algorithms.

Change of name servers using update domain, removes all current DSRECORDS as part of the operation.

Domain Info

The command info domain will only supply the registrant information for relevant contact objects. For other contact objects assigned to the domain name, the requesting user has to have a relationship to the domain or contact object, either via a host or domain role or registrar group.

Availability of DNSSEC information and status is currently limited to public available data.

Domain Transfer

In RFC:5731 section 3.2.4 is it described that an optional period can be specified. Punktum dk does not support the extension of a period via a transfer.

Domain Update

This command does not support the setting and removal of status using the XML element: domain:status. The status is assigned by Punktum dk. See also information on the update domain command and the appendix with Domain Status Codes.

Encoding and IDN domains

Punktum dk supports IDN domain names and the EPP commands support Punycode notation for this in requests. Punktum dk does not support Punycode notation in responses at this time.

For details on supported characters, please see: the Punktum dk Name Service specification.

Host Info

The command info host will only supply the name server administrator/zone contact information if the requesting and authenticated user has a relationship to the user, either via a domain role or registrar group, which provides authorization to access the information.

Host Update

This command does not support the setting and removal of status using the XML element: host:status. The status is assigned by Punktum dk. See also information on the update host command and the appendix with Host Status Codes.

Information Disclosure

Please note that some information is not disclosed when using Object Query Commands. See the specific commands for more information.

Additionally Punktum dk does not implement the optional contact:disclose element.

An OPTIONAL contact:disclose element that allows a client to identify elements that require exceptional server-operator handling to allow or restrict disclosure to third parties. See Section 2.9 for a description of the child elements contained within the contact:disclose element.

From RFC:5733.

Unimplemented Commands

Unimplemented Command: Delete Contact

The delete contact command is not implemented by Punktum dk, unlinked contacts are automatically deleted by Punktum dk.

Unimplemented Command: Transfer Contact

The transfer contact command is not implemented by Punktum dk, Contacts are transferred with their domain name, please see the transfer domain command.

Unsupported Contact Status Codes

Several of the host status codes described in RFC:5733 are not supported.

All of the client* status codes are note supported:

  • clientDeleteProhibited
  • clientUpdateProhibited
  • clientTransferProhibited

Since the administrative model does not support user enforced restraints.

  • pendingCreate
  • pendingDelete
  • pendingTransfer

The operation to create a contact is instantaneous.

The listed pending-states for delete contact and transfer contact are not supported in the Punktum dk registry system.

Unsupported Domain Status Codes

Several of the domain status codes described in RFC:5731 and the ICANN status code description are not supported.

All of the client* status codes are not supported:

  • clientDeleteProhibited
  • clientHold
  • clientRenewProhibited
  • clientTransferProhibited
  • clientUpdateProhibited

Since the administrative model does not support user enforced restraints.

  • addPeriod
  • autoRenewPeriod
  • renewPeriod
  • transferPeriod

Are all ICANN statuses and are not regarded as standard and they do not map to business rules used in the Punktum dk registry system, based on the descriptions in the ICANN status code description.

  • pendingRenew
  • pendingRestore
  • pendingTransfer

The operations for renew domain, restore domain and transfer domain are instantaneous and the listed pending-states do therefor not map to business processes used in the Punktum dk registry system.

  • inactive

This state is unsupported, since domain names in the Punktum dk registry must have associated name servers, please see the Name Service Specification.

The domain status codes listing holds a complete listing of all the status codes.

Unsupported Host Status Codes

Several of the host status codes described in RFC:5732 are not supported.

All of the client* status codes are note supported:

  • clientDeleteProhibited
  • clientUpdateProhibited

The administrative model does not support user enforced restraints.

  • pendingTransfer

The transfers for of hosts are a part of the domain transfer operation, which is instantaneous and as outlined in RFC:5732 transfer of host objects is does not really apply.

From RFC:5732:

Transfer semantics do not directly apply to host objects, so there is no mapping defined for the EPP command. Host objects are subordinate to an existing superordinate domain object and, as such, they are subject to transfer when a domain object is transferred.

Waiting List

Punktum dk offers a waiting list service for domain names, when a domain name becomes available to the first position on a waiting list, it should be registered using the standard registration process either via the Registrar Portal or EPP.

This utilized the create domain command, which should either be populated with the token issued by Punktum dk authorizing registration. Alternatively the user-id of the waiting list user which has been pre-approved for registration of the domain name with Punktum dk.

The state that a domain name is offered to a waiting list can be inspected via the info domain via the dkhm:domainAdvisory extension.

No other information is available on waiting lists via EPP at this time.

Please refer to the Punktum dk website for more information.

Supported Object Transform and Query Commands

The following section describes the supported EPP commands. As mentioned previously, some of the commands have been extended beyond the basic capabilities of EPP. These extensions are described separately under each command and are included in the DKHMXSD listed in the Resources chapter. An alphabetical list is also available in the Implementation Extensions section.

The supported commands are:

  • hello
  • login, including change password
  • logout
  • create (contact/domain/host)
  • check (contact/domain/host)
  • info (contact/domain/host)
  • update (contact/domain/host)
  • renew (domain)
  • transfer (domain)
  • delete (host/domain)
  • poll, including acknowledgement of messages
  • balance command extension
  • restore extension to update domain command

Commands that have not been extended are not described in much detail, please refer to the general EPP documentation from IETF via the RFCs listed in References.

hello and greeting

This part of the EPP protocol is described in RFC:5730. This command adheres to the standard. For a more detailed explanation of the data collection policy announced via the greeting, please see the Data Collection Policy section.

As announced in the greeting, the following objects are available:

With regard to extensions, the following are available:

Please see the greeting response included in the appendices for illustration of the actual announcement.

login

This part of the EPP protocol is described in RFC:5730. This command adheres to the standard.

The login uses the general Authentication Authorization and Access (AAA) framework in Punktum dk. This mean that in addition to the validation of username and password specified as part of the login request, an attempt is made to authorize the authenticated user for access to the actual EPP service and subsequent operations.

Service Users is an alternative to using regular WHOIS handles. They are reserved to a specific service, like for example EPP and can only be created by the administrator of a registrar group.

Punktum dk supports the change of passwords via EPP. Please refer to the chapter Available Environments for any special circumstances.

Password should adhere to the following requirements:

EPP supports a password with at least 6 and a maximum 16 characters, where Punktum dk supports 8 - 64 characters. The password must include at least three of these four character types:

  • Lower-case letters
  • Upper-case letters
  • Numbers
  • Special Characters

The following characters are legal special characters in passwords:

% ` ' ( ) * + - , . / : ; < > = ! _ & ~ { } | ^ ? $ # @ " [ ]

Successful authentication established a session with a life span of 700 seconds (5 minutes), it can be kept alive by sending additional hello commands or similar.

The overall life span is 28800 seconds (8 hours) after this the session is terminated and should be reestablished with a new authentication (login).

A connection can be prematurely terminated if the service gets in a unstable state.

login request

<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<command>
		<login>
			<clID>REG-999999</clID>
			<pw>*********</pw>
			<options>
				<version>1.0</version>
				<lang>en</lang>
			</options>
			<svcs>
                <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
                <objURI>urn:ietf:params:xml:ns:host-1.0</objURI>
                <objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
			</svcs>
		</login>
		<clTRID>d52eaf8995d2b679fe9dc53ee5bc3ad9</clTRID>
	</command>
</epp>

login response

<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1000">
			<msg>User REG-999999 logged in.</msg>
		</result>
		<trID>
			<clTRID>d52eaf8995d2b679fe9dc53ee5bc3ad9</clTRID>
			<svTRID>63BE4FAE-F6F9-11E3-867F-A6B052036DCB</svTRID>
		</trID>
	</response>
</epp>

logout

This part of the EPP protocol is described in RFC:5730. This command adheres to the standard.

There are no special additions or alterations to the specification or use of this command.

logout request

<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<command>
		<logout />
		<clTRID>9450488c8280671c051f273285d7bec7</clTRID>
	</command>
</epp>

logout response

<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1500">
			<msg>User logged out. Closing Connection.</msg>
		</result>
		<trID>
			<clTRID>9450488c8280671c051f273285d7bec7</clTRID>
			<svTRID>370F8F46-F6F3-11E3-867F-A6B052036DCB</svTRID>
		</trID>
	</response>
</epp>

Poll and Message Queue

This part of the EPP protocol is described in RFC:5730. This command adheres to the standard.

There are no special additions or alterations to the specification or use of this command.

For clarification 2303 is returned in case a provided message-id (msgID) point to a non-existing message.

Return Code Description
1000 A messages was successfully dequeued using ack
1301 Command completed successfully; ack to dequeue
2303 In case a requested message no longer exist

poll req request

<?xml version="1.0" encoding="UTF-8"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<poll op="req"/>
		<clTRID>09ed6c730e5c4c671c69ea8a4325ac06</clTRID>
	</command>
</epp>

poll req response

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1301">
			<msg>Command completed successfully; ack to dequeue</msg>
		</result>
		<msgQ count="10" id="1">
			<msg>Create domain pending for eksempel.dk</msg>    </msgQ>
		<resData>
			<domain:creData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
				<domain:name>eksempel.dk</domain:name>
				<domain:crDate>2013-02-13T13:43:24.0Z</domain:crDate>
			</domain:creData>
		</resData>
		<trID>
			<clTRID>bb96ddfcbe2becbe1e7d974a5b22e29a</clTRID>
			<svTRID>EFE89190-CC4B-11E6-B51D-4F7D3A107CA1</svTRID>
		</trID>
	</response>
</epp>

poll ack request

<?xml version="1.0" encoding="UTF-8"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<poll msgID="1" op="ack"/>
		<clTRID>a05bd42e77b26fe18801cbf5216ee199</clTRID>
	</command>
</epp>

poll ack response

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1000">
			<msg>Command completed successfully</msg>
		</result>
		<msgQ count="9" id="2">
		</msgQ>
		<trID>
			<clTRID>770e65ed92827c810421faf709b5523c</clTRID>
			<svTRID>4ECFA0E0-CC4C-11E6-A3CB-78843A107CA1</svTRID>
		</trID></response>
</epp>

poll ack response for non-existent message (or previously acknowledged message)

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="2303">
			<msg>Object does not exist</msg>
		</result>
		<msgQ count="8" id="5">
		</msgQ>
		<trID>
			<clTRID>9bee91be9f7d15808ce3425af406ddc4</clTRID>
			<svTRID>A615AEDA-CC4C-11E6-9191-4F7D3A107CA1</svTRID>
		</trID>
	</response>
</epp>

Balance and Prepaid Account

With the introduction of administrative model registrar management, a prepaid model for registrars is exchanging the previous invoice driven process and interaction.

This mean that EPP commands relating to billable operations are evaluated in context of the registrar account and accounting is completed as part of the execution of the operation.

The operations currently classified as billable are:

  • Domain name application/creation, this is described in detail in the create domain section
  • Domain name renewal. this is described in detail in the renew domain section
  • Restoration from deletion (cancellation), this is described in detail in the restore domain section
  • Restoration from suspension due to automatic expiration, also described in detail in the restore domain section

This mean that a new error scenario is introduced with version 4.0.0 of the service for creation/application, where an application/create request will be declined, in case of insufficient funds. The manual renewal operation via renew domain and the option of automatic renewal is not subjected to this policy, please refer to the registrar contract for specific details as this is a technical document and not the authoritative source for business and policy rules.

All prices and amounts relating to currencies are provided in DKK, converted to the EPP currency type, using decimal point (.) and not decimal comma (,), which is the definition for the Danish locale.

The balance command implementation is based on the extension developed by Verisign, please see: Verisign: "Balance Mapping for the Extensible Provisioning Protocol (EPP)", see also References

balance request

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <command>
        <info>
            <balance:info xmlns:balance="http://www.verisign.com/epp/balance-1.0"/>
        </info>
        <clTRID>ABC-12345</clTRID>
    </command>
</epp>

Example lifted from "Balance Mapping for the Extensible Provisioning Protocol (EPP)". see References.

balance response

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <response>
        <result code="1000">
            <msg>Command completed successfully</msg>
        </result>
        <resData>
            <balance:infData xmlns:balance="http://www.verisign.com/epp/balance-1.0">
                <balance:creditLimit>1000.00</balance:creditLimit>
                <balance:balance>200.00</balance:balance>
                <balance:availableCredit>800.00</balance:availableCredit>
                <balance:creditThreshold>
                    <balance:fixed>500.00</balance:fixed>
                </balance:creditThreshold>
            </balance:infData>
        </resData>
        <trID>
            <clTRID>ABC-12345</clTRID>
            <svTRID>54322-XYZ</svTRID>
        </trID>
    </response>
</epp>

Example lifted from "Balance Mapping for the Extensible Provisioning Protocol (EPP)", see References.

Return Code Description
1000 Request was responded to successfully
2201 No authorization to view the balance of the requested account
2303 The account for which balance was requested does not exist

Domain

The default behavior of the EPP create domain command as described in RFC:5731, will attach the client-ID (CLID) of the authenticated party to the object created.

Having the client-ID specified at this time indicates that the domain name is under registrar management from creation. To change the registrar and discontinue the registrar management will require a transfer.

For more information on the disclose of the Client ID

If the registrar does not want to create domains under registrar management the default behaviour can be configured in RP, where the available are:

  • registrar management
  • registrant management

The setting will be global and will influence the behaviour in both:

  • EPP
  • RP

These Registrar Account Settings are controlling the account as a whole for all relevant commands.

create domain

This part of the EPP protocol is described in RFC:5730. This command adheres to the standard. Punktum dk, however, is based on an asynchronous domain creation workflow.

All domain requests are enqueued for further processing and their creation will be in a state of pending (1001).

Please note:

Domains offered from a waiting list can be registered using the create domain command. It requires the authorization token issued by Punktum dk to the designated registrant. The token has to be transported via the AuthInfo field.

The AuthInfo token used for registration of domain names offered from a waiting list are a 8 digit hexadecimal case insensitive string. The token is offered to the designated registrant out of band and is valid for 14 days.

As described in the section on waiting lists the token is not necessary if the designated registrant for the application use the user-id of the waiting list customer and designated registrant.

A well-formed request for domain creation will always result in:

1001, “Command completed successfully; action pending”

The extension in response will provide a unique tracking number, in EPP the svTRID, which can be used to identify the creation request across provisioning channels offered by Punktum dk. The result of the further processing will be relayed back via EPP, see Poll and Messages below.

The customized response for a domain creation request looks as follows:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
    xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
    <response>
        <result code="1301">
            <msg>Command completed successfully; ack to dequeue</msg>
        </result>
        <msgQ count="1" id="1630296">
            <msg>Create domain pending for eksempel.dk</msg>
        </msgQ>
        <resData>
            <domain:creData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
                <domain:name>eksempel.dk</domain:name>
                <domain:crDate>2021-10-03T13:30:47.0Z</domain:crDate>
            </domain:creData>
        </resData>
        <extension>
            <dkhm:risk_assessment xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">N/A</dkhm:risk_assessment>
        </extension>
        <trID>
            <clTRID>92724843f12a3e958588679551aa988d</clTRID>
            <svTRID>6118C396-243D-11EC-9746-E6CC5F504B00</svTRID>
        </trID>
    </response>
</epp>

The create domain command has been extended with a field (orderconfirmationToken) making it possible to assign a token indicating that the registrant has agreed to the terms and conditions for Punktum dk with the registrar.

<extension>
	<dkhm:orderconfirmationToken xmlns:dkhm=“urn:dkhm:params:xml:ns:dkhm-4.3”>
		1522744544
	</dkhm:orderconfirmationToken>
</extension>

The token is a timestamp in EPOCH format, indicating when the agreement was accepted. The EPOCH timestamp has to be specify adhering to the POSIX/UNIX standard and has to be specified in seconds. We do not support milliseconds or nanoseconds.

The EPOCH timestamp must not exceed 24 hours into the future compared to local time resolution. In case this exception occurs error code 2004 and a descriptive message.

The token is handled the following way:

  • If absent Punktum dk will require the agreement for the terms and conditions be accepted with Punktum dk, this process is handled by Punktum dk

  • If present. The token will be validated by Punktum dk

  • if not valid the request with result in an error and the request will be dismissed

  • if valid the request will be accepted and processed

The requirement for the registrant to be valid is communicated via the response, using the extension: dkhm:registrant_validated.

Please see the command info contact for more information.

The state is communicated in this response in order to provide information on the further flow and process of the create domain request.

An additional URL is specified in the response via the extension dkhm:url, this URL can be presented to the end-user for further processing and for the following scenarios in particular:

  1. End-user has not agreed to the terms and conditions
  2. End-user has agreed to the terms and conditions, but ID-control is required
  3. End-user has agreed to the terms and conditions and ID-control has been completed - no further actions are necessary, self-service access is available and active

As part of the process the final response to a create domain is communicated via the message queue. In this response the Punktum dk A/S risk assessment is included, it can hold one of the following values:

  • RED - the registrant is requested to complete successful ID-control before the domain name can become active
  • YELLOW - the registrant is requested to complete successful ID-control, the domain name becomes active immediately. If ID-control is not completed within the communicated timeframe the domain is made inactive
  • BLUE - the registrant is requested to complete successful ID-control before the domain name can become active
  • GREEN - the domain name becomes active immediately
  • N/A - the risk assessment could not be performed, the registrant is requested to complete successful ID-control before the domain name can become active

The procedures for ID-control are described on the Punktum dk DK website.

Upon approval of the application, meaning the pending operation is processed, the domain name will still reflect: pendingCreate. The pendingCreate is not removed until the back-end system serving the EPP service indicates that the operation is completed. The domain name can however be active and it is published to the zone, but some operations are prohibited until finalization of the provisioning towards all systems is completed.

The status codes applying to domain are described in the addendum: Domain Status Codes.

Domain name Application/Creation Failure

As described in the introduction, the existing commands, which are categorized as billable are not changed. Due to the change to the billing procedure however, the application/create operation is extended with a error scenario, for when the prepaid account does not have sufficient funds.

The proposed error message is the following, quoted from RFC:5730.

2104 "Billing failure"

This response code MUST be returned when a server attempts to execute a billable operation and the command cannot be completed due to a client-billing failure.

The choice of administration model is based on the default set for the registrar account. This can be set in the registrar portal. It can be overwritten per application using the dkhm:management extension, which can have one of two values:

  • registrar, indicating registrar management
  • registrant, indicating registrant management

The designated registrant (contact) has to be under the same management model or the application will be rejected.

The creation of contacts (registrants) is covered under create contact.

See diagram: 👁️‍🗨️

Return Code Description
1001 Command completed successfully; action pending
2001 Invalid period [period]. Must be within range
2201 Registrant has previously failed ID-control and cannot become registrant
2201 Registrar handle is not permitted for registrant role.
2004 dkhm:orderconfirmationToken: >token< exceeds allowed threshold
2004 Too few users for contact type
2004 Too many users for contact type
2005 Bad value for dkhm:orderconfirmationToken: >token<
2104 Insufficient credit. Domain cannot be created.
2305 Specified user handle not permitted when handled by registrar
2305 Specified user handle not permitted without handling by registrar
2306 Specifying contacts for registrar handled domains is not allowed
2400 Internal error. No connection to ECDS service.
2500 Internal error. ECDS operation not found in the configuration
2500 Internal error. Can't get prices from ECDS.
2500 Internal error.

create domain request
<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<command>
		<create>
			<domain:create xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd">
				<domain:name>eksempel.dk</domain:name>
				<domain:period unit="y">1</domain:period>
				<domain:ns>
					<domain:hostObj>ns1.dk-hostmaster.dk</domain:hostObj>
					<domain:hostObj>ns2.dk-hostmaster.dk</domain:hostObj>
				</domain:ns>
				<domain:registrant>DKHM1-DK</domain:registrant>
				<domain:authInfo>
					<domain:pw />
				</domain:authInfo>
			</domain:create>
		</create>
		<extension>
			<dkhm:orderconfirmationToken xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">testtoken</dkhm:orderconfirmationToken>
		</extension>
		<clTRID>92724843f12a3e958588679551aa988d</clTRID>
	</command>
</epp>

create domain response
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1001">
			<msg>Create domain pending for eksempel.dk</msg>
		</result>
		<msgQ count="1" id="1"/>
		<extension>
			<dkhm:trackingNo xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">2013010100030</dkhm:trackingNo>
			<dkhm:domain_confirmed xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">1</dkhm:domain_confirmed>
			<dkhm:registrant_validated xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">1</dkhm:registrant_validated>
			<dkhm:url xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">https://selfservice-dk-hostmaster.dk/6102505a2e8d0cfbe8c3c99ea49977f36e2d4ee3</dkhm:url>
		</extension>
		<trID>
			<clTRID>92724843f12a3e958588679551aa988d</clTRID>
			<svTRID>EDF4F436-9CC9-11E4-AC57-51CB2AC2711D-2013010100030</svTRID>
		</trID>
	</response>
</epp>

This tracking number (trackingNo), listed as an extension and does not replace or interfere with the normal use of the EPP transaction keys, clTRID and svTRID, but are EPP specific, whereas the tracking number is considered global in Punktum dk. The tracking number is also appended to the svTRID in addition to the listing in the extension part. Please see the last digits following the last dash.

<svTRID>9917BE58-3D53-11E2-A5BD-C532BF0DC46A-1234</svTRID>

An important note is that the clTRID is mandatory for this command. Since we use the clTRID to report back via the message polling functionality, when the domain creation request changes state. See the Client Transaction ID (clTRID) section under Implementation Requirements.

The default value for domain value, if not specified, is one year.

Poll and Messages

As described above the creation of domain names is not synchronous, after the creation of a domain request, resulting in a pending state, will have to be probed using the poll command.

The outcome can be one of two, please see the examples below:

create domain poll message for successful creation
<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1301">
			<msg>Command completed successfully; ack to dequeue</msg>
		</result>
		<msgQ count="1" id="2">
			<msg>Created domain for eksempel.dk has been approved</msg>
		</msgQ>
		<resData>
			<domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
				<domain:name paResult="1">eksempel.dk</domain:name>
				<domain:paTRID>
					<clTRID>916e2f64ca0956a1bfc24140b23b8fb3</clTRID>
					<svTRID>001C6E66-761D-11E8-8775-F5EABB5937F7-2018062200008</svTRID>
				</domain:paTRID>
				<domain:paDate>2018-06-22T15:07:00.0Z</domain:paDate></domain:panData>
		</resData>
		<extension>
			<dkhm:risk_assessment xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">N/A</dkhm:risk_assessment>    </extension>
		<trID>
			<clTRID>92724843f12a3e958588679551aa988d</clTRID>
			<svTRID>7F3D4CD8-761D-11E8-8775-F5EABB5937F7</svTRID>    </trID></response>
</epp>

create domain poll message for unsuccessful creation, existing domain
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1301">
			<msg>Command completed successfully; ack to dequeue</msg>
		</result>
		<msgQ count="1" id="1">
			<msg>Object exists</msg>
		</msgQ>
		<resData>
			<domain:creData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
				<domain:name>dk-hostmaster.dk</domain:name>
				<domain:crDate>2018-06-22T14:08:08.0Z</domain:crDate>
				<domain:exDate>2022-03-31T00:00:00.0Z</domain:exDate>
			</domain:creData>
		</resData>
		<extension>
			<dkhm:risk_assessment xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">N/A</dkhm:risk_assessment>
		</extension>
		<trID>
			<clTRID>71a61d8181fce08fc1c087f409a6168b</clTRID>
			<svTRID>DD118802-761C-11E8-8775-F5EABB5937F7</svTRID>
		</trID>
	</response>
</epp>
Return Code Description
1000 Command completed successfully, messages has been successfully acked, there are more messages
1300 Command completed successfully, there are no more messages
1301 Command completed successfully, ack to dequeue
2303 If the specified message does not exist

Role Mapping

As for the user entities some mappings are made so all relevant roles are specified.

EPP DKHM Fallback Note
admin proxy registrant optional, will use fallback
billing billing registrant optional, will use fallback
tech keyholder optional, will be ignored if keyholder is specified in EPP
registrant registrant mandatory
registrar registrar mandatory

Please note that the command supports Punycode notation for specifying IDN domain names, but responses are in the specified UTF-8 character set.

See the diagram of role resolution for EPP create domain for a graphical representation 👁️‍🗨️

check domain

Return Code Description
1000 If the check domain command is successful
2303 If the specified domain object does not exist

check domain request
<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<command>
		<check>
			<domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd">
				<domain:name>dk-hostmaster.dk</domain:name>
			</domain:check>
		</check>
		<clTRID>82d73f4f441bcc5fa50952196bb19de5</clTRID>
	</command>
</epp>

check domain response
<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1000">
			<msg>Check result</msg>
		</result>
		<resData>
			<domain:chkData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
				<domain:cd>
					<domain:name avail="0">dk-hostmaster.dk</domain:name>
					<domain:reason>In use</domain:reason>
				</domain:cd>
			</domain:chkData>
		</resData>
		<trID>
			<clTRID>82d73f4f441bcc5fa50952196bb19de5</clTRID>
			<svTRID>36FB99DC-F6F3-11E3-867F-A6B052036DCB</svTRID>
		</trID>
	</response>
</epp>

In general this part of the EPP protocol is described in RFC:5731 and this command adheres to the standard.

The available values for the reason field are:

  • In use for domain names registered with the Punktum dk registry
  • Enqueued for domain names awaiting domain name application processing, This can last a few seconds to a few days if the application require accept of terms and conditions from the designated registrant
  • Offered for pos. on waiting list, for when the domain name has been offered to a designated registrant from a waiting list position

An example for a waiting list position offering would look as follows:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
    <response>
        <result code="1000">
            <msg>Command completed successfully</msg>
        </result>
        <resData>
            <domain:chkData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
                <domain:cd>
                    <domain:name avail="0">waiting-list.dk</domain:name>
                    <domain:reason>Offered for pos. on waiting list</domain:reason>
                </domain:cd>
            </domain:chkData>
        </resData>
        <trID>
            <clTRID>24234ad07890f6961184fd58268904dd</clTRID>
            <svTRID>B8D178A4-097A-11EC-A97C-5241511D3588</svTRID>
        </trID>
    </response>
</epp>

info domain

This part of the EPP protocol is described in RFC:5731. This command adheres to the standard. In addition the command has been extended with two of the Punktum dk extensions:

  • dkhm:domainAdvisory
  • dkhm:registrant_validated
  • dkhm:authInfoExDate

Do note that the response only contains the registrant contact object, if the authenticated user has a relationship via the domain name, which provides access to more information.

The below example could shows the public available information. It could be extended with the following data:

<domain:contact type="admin">DKHM1-DK</domain:contact>

and additionally:

<domain:contact type="billing">DKHM1-DK</domain:contact>

Do note that the billing contact and proxy is displayed if the authenticated user has user has authorization to see this information. The registrant role information for the domain is public available. The authorization requires a relationship via a role on the domain name or a registrar group association

For DNSSEC data the availability is limited to only displaying if the information is public available.

The domain:clID field communicates portfolio information about the given domain:

  • For registrant managed domain names: <domain:clID>DKHM1-DK<domain:clID>, indicating Punktum dk A/S
  • For registrar managed domain names:
    • <domain:clID>REG-123456</domain:clID>, as seen by users associated with the registrar account
    • <domain:clID>Example Registry Name</domain:clID>, as seen by users not associated with the registrar account

Please see the addendum on domain status codes.

Return Code Description
1000 If the info domain command is successful
2303 If the specified domain object does not exist

info domain request
<?xml version="1.0" encoding="UTF-8"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<info>
			<domain:info xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
				<domain:name>dk-hostmaster.dk</domain:name>
			</domain:info>
		</info>
		<clTRID>e007d4d21ec089623bd71b65f33f2865</clTRID>
	</command>
</epp>

info domain response
<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
  <response>
    <result code="1000">
      <msg>Info result</msg>
    </result>
    <resData>
      <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>dk-hostmaster.dk</domain:name>
        <domain:roid>DK_HOSTMASTER_DK-DK</domain:roid>
        <domain:status s="serverUpdateProhibited"/>
        <domain:status s="serverTransferProhibited"/>
        <domain:status s="serverDeleteProhibited"/>
        <domain:registrant>DKHM1-DK</domain:registrant>
        <domain:ns>
          <domain:hostObj>auth01.ns.dk-hostmaster.dk</domain:hostObj>
          <domain:hostObj>auth02.ns.dk-hostmaster.dk</domain:hostObj>
          <domain:hostObj>p.nic.dk</domain:hostObj>
        </domain:ns>
		<domain:host>auth01.ns.dk-hostmaster.dk</domain:host>
		<domain:host>auth02.ns.dk-hostmaster.dk</domain:host>
		<domain:host>venteliste1.dk-hostmaster.dk</domain:host>
		<domain:host>venteliste2.dk-hostmaster.dk</domain:host>
		<domain:host>blocked1.ns.dk-hostmaster.dk</domain:host>
		<domain:host>blocked2.ns.dk-hostmaster.dk</domain:host>
        <domain:clID>DKHM1-DK</domain:clID>
        <domain:crID>DKHM1-DK</domain:crID>
        <domain:crDate>1998-01-19T00:00:00.0Z</domain:crDate>
        <domain:exDate>2022-03-31T00:00:00.0Z</domain:exDate>
      </domain:infData>
    </resData>
    <extension>
      <dkhm:registrant_validated xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">1</dkhm:registrant_validated>
      <secDNS:infData xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
        <secDNS:dsData>
          <secDNS:keyTag>25591</secDNS:keyTag>
          <secDNS:alg>8</secDNS:alg>
          <secDNS:digestType>2</secDNS:digestType>
          <secDNS:digest>d4323bf6717060bda3a537d6c43ed2719d2656f21ae53f85028ed78ae18afcf6</secDNS:digest>
        </secDNS:dsData>
        <secDNS:dsData>
          <secDNS:keyTag>25591</secDNS:keyTag>
          <secDNS:alg>8</secDNS:alg>
          <secDNS:digestType>4</secDNS:digestType>
          <secDNS:digest>c72da309c49d2e468298cb04498bce9879eb40e1a486c16cbe73f6c95a1f9ff31ff35efb7d8d74625935a18b4e64fb15</secDNS:digest>
        </secDNS:dsData>
        <secDNS:dsData>
          <secDNS:keyTag>30491</secDNS:keyTag>
          <secDNS:alg>8</secDNS:alg>
          <secDNS:digestType>2</secDNS:digestType>
          <secDNS:digest>6159b7ab1d087360fffb8d75ea394a6533012562291b94a03bd813c7cd2bf68c</secDNS:digest>
        </secDNS:dsData>
        <secDNS:dsData>
          <secDNS:keyTag>30491</secDNS:keyTag>
          <secDNS:alg>8</secDNS:alg>
          <secDNS:digestType>4</secDNS:digestType>
          <secDNS:digest>434f4f1b37cb408ee9337acd36d26871066e17177d38b2f7070fd0088ce8df289641ac2a2e62e860fa91f210d39c883a</secDNS:digest>
        </secDNS:dsData>
      </secDNS:infData>
    </extension>
    <trID>
      <clTRID>fee9352765ab62fefc69558d3f4e0eed</clTRID>
      <svTRID>CF056EB6-D2CA-11E9-8DAB-C853983F0358</svTRID>
    </trID>
  </response>
</epp>

info domain response with domain advisory

A info domain response can be annotated with information using the extension dkhm:domainAdvisory.

The advisory can currently communicate two advisories:

  • pendingDeletionDate, indicating that a given domain name is scheduled for deletion
  • offeredOnWaitingList, indicating that a given domain name has been offered to a designated registrant

If a domain name is marked for pending deletion, this special status is communicated via the dkhm:domainAdvisory extension.

<extension>
    <dkhm:domainAdvisory advisory="pendingDeletionDate" date="2020-10-14T00:00:00.0Z" domain="eksempel.dk" xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3"/>
</extension>

The field advisory indicates a pending delete date with the string: pendingDeletionDate followed by a field containing the actual date.

Do note the date is only guiding, since the actual operation of deletion is handled by an external process and operational circumstances might vary and are executed under the discretion of the registry.

If a domain name is offered to a position on a waiting list, the advisory offeredOnWaitingList is used.

<extension>
    <dkhm:domainAdvisory advisory="offeredOnWaitingList" domain="eksempel.dk" xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3"/>
</extension>

Do note that the waiting list status is also used in the check domain command, using the reason field.

Since a waiting list offering is not a complete domain name registration the data in the response is limited compared to a registered domain name..

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
    <response>
        <result code="1000">
            <msg>Command completed successfully</msg>
        </result>
        <resData>
            <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
                <domain:name>eksempel.dk</domain:name>
                <domain:roid>EKSEMPEL_DK-DK</domain:roid>
                <domain:status s="ok"/>
                <domain:registrant>UNKNOWN-DK</domain:registrant>
                <domain:clID>DKHM1-DK</domain:clID>
                <domain:crID>UNKNOWN-DK</domain:crID>
            </domain:infData>
        </resData>
        <extension>
            <dkhm:domainAdvisory advisory="offeredOnWaitingList" domain="eksempel.dk"
                xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3"/>
        </extension>
        <trID>
            <clTRID>733a8410c40f76de6b41c9fa51d48f81</clTRID>
            <svTRID>4B1EF7E6-00E2-11EC-AEDE-C9E35F504B00</svTRID>
        </trID>
    </response>
</epp>

info domain response with AuthInfo token

When the AuthInfo token has been set it can be retrieved via the EPP command: info domain, do note that the retrieval requires authorization and therefor authentication, which can be used the authorization to include the AuthInfo token in the response, it is only visible to users with the privilege to see it.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
    xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
    <response>
        <result code="1000">
            <msg>Command completed successfully</msg>
        </result>
        <resData>
            <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
                <domain:name>eksempel.dk</domain:name>
                <domain:roid>EKSEMPEL_DK-DK</domain:roid>
                <domain:status s="ok"/>
                <domain:registrant>DKHM1-DK</domain:registrant>
                <domain:ns>
                    <domain:hostObj>auth01.ns.dk-hostmaster.dk</domain:hostObj>
                    <domain:hostObj>auth02.ns.dk-hostmaster.dk</domain:hostObj>
                    <domain:hostObj>auth03.ns.dk-hostmaster.dk</domain:hostObj>
                </domain:ns>
                <domain:clID>REG-123456</domain:clID>
                <domain:crID>DKHM1-DK</domain:crID>
                <domain:crDate>1999-05-17T00:00:00.0Z</domain:crDate>
                <domain:exDate>2022-06-30T00:00:00.0Z</domain:exDate>
            </domain:infData>
        </resData>
        <extension>
            <dkhm:registrant_validated xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">1</dkhm:registrant_validated>
            <dkhm:authInfo expdate="2021-10-17T14:16:35.0Z" op="transfer"
                xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">REG-0-d5288a8aa482bcf2fb5152bfbb7d877d</dkhm:authInfo>
            <dkhm:autoRenew xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">true</dkhm:autoRenew>
        </extension>
        <trID>
            <clTRID>b53dcd043c802e860ad39d9ac852543c</clTRID>
            <svTRID>C39E4576-2443-11EC-A2F7-E1CC5F504B00</svTRID>
        </trID>
    </response>
</epp>

The response is further extended with the dkhm:authInfoExDate extension, communicating the expiration date of the current AuthInfo for the domain, again only visible if privileges permit.

<extension>
    <dkhm:authInfoExDate xmlns:dkhm="urn:dkhm:xml:ns:dkhm-4.3">2018-11-14T09:00:00.0Z</dkhm:authInfoExDate>
</extension>

renew domain

This part of the EPP protocol is described in RFC:5731. This command adheres to the standard.

Domain name subscriptions can be renewed manually via the EPP service. The feature applies to both:

  • Registrant managed domain names, where the registrar is appointed as the billing contact
  • Registrar managed domain names

Manual renewal can be done up to the expiration date of the specific domain name. It does not influence automatic renewal or automatic expiration apart from delaying there effective execution and automatic change to the domain name lifespan, please see the below matrices outlining the different scenarios for manual renewal.

Registrar Management Billing contact is registrar Billing contact is non-registrar
Automatic renewal < expiration date N/A
Automatic expiration < expiration date N/A
Registrant Management Billing contact is registrar Billing contact is non-registrar
Automatic renewal < expiration date < expiration date - X days 🔖 *1
Automatic expiration < expiration date N/A

📑 *1 When an invoice is generated for a registrant managed domain name where the billing contact is a non-registrar, the domain names with expiration in a given calendar month are collected on a single invoice for the month as a whole. This mean that a given domain name can be marked for collection between 45 to 77 days prior to expiration. The 45 days are due to the constraints involving requirements for automatic payment via Betalings Service (BS) and since a domain name can have expiration by the end of the month, the length of the month has to be taken into account, extending the period with 30 days, giving a total of 77 days.

Do note the constraints on when you can change the billing contact, since might limit window of opportunity for manual renewal and being the billing contact for the domain is a explicit requirement.

See current prices at the Punktum dk website: Products and Prices. Insufficient funds in the registrar account will not prohibit this operation.

Do note that for period specification, only the unit y indicating year is accepted.

The following values for the period specification are accepted:

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

Not specifying acceptable parameters will result in error code 2005 with a message indicating the error.

Not specifying the period parameters will result in the unit: y and the value: 1.

See diagram of EPP process for EPP renew domain: 👁️‍🗨️

Return Code Description
1000 If the renew domain command is successful
2005 Syntax of the command is not correct
2105 If the domain object is not eligible for renewal. The domain name has to be in the state ‘Active’ and the expiration date has to be a at least month into the future from the current date. This will also be reflected in status value serverRenewProhibited. See also ICANN description of status
2201 If the authenticated user does not hold the privilege to renew the specified domain object. This privilege is given to the billing contact for the domain name (see also the login command)
2303 If the specified domain object does not exist
2306 If the specified expiry date is not valid. The provided expiration date has to be equal to the current expiration date or we return 2306
2306 If the calculated expiry date is not allowed. The new expiration date has to be lower than the current expiration date + 10 years. The maximum period to which the expiration date can be extended is 10 years and 3 months. The current expiration date is available via the info domain command as domain:exDate
2400 In case of an exception

This complete process is atomic and might throw an unrecoverable exception: 2400 either due to unforeseen circumstances or a change in the state of the domain name.

On success we emit the return code 1000. No further communication is made via the EPP service. The billable transaction is deducted from the Prepaid Account.

The sub-process called, can be depicted as in this diagram of Punktum dk sub-process for EPP renew domain 👁️‍🗨️

The status code serverRenewProhibited is set:

  • If the status pendingCreate is set, see domain create
  • If the status pendingDelete is set
  • If the registrant has not accepted the Terms and Conditions of Punktum dk
  • If the domain name period renewal will exceed the maximum period of 10 years and 3 months
  • If the domain name is not settled/paid
  • If the domain name is suspended due to automatic expiration
  • If the domain name is on hold or blocked, meaning it has been suspended by Punktum dk

renew domain request
<?xml version="1.0" encoding="UTF-8"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<renew>
			<domain:renew xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
				<domain:name>dk-hostmaster.dk</domain:name>
				<domain:curExpDate>2017-03-31</domain:curExpDate>
				<domain:period unit="y">1</domain:period>
			</domain:renew>
		</renew>
		<clTRID>541b6801ab3cecdda7da5f735e4f1473</clTRID>
	</command>
</epp>

renew domain response
<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1000">
			<msg>OK</msg>
		</result>
		<msgQ count="10" id="1">
		</msgQ>
		<trID>
			<clTRID>be781a6d19d320867d06e6e80a84a614</clTRID>
			<svTRID>64278BDE-CC4B-11E6-8068-487D3A107CA1</svTRID>
		</trID>
	</response>
</epp>

update domain

This part of the EPP protocol is described in RFC:5731. This command does not adhere to the standard

  • authInfo is used to handle AuthInfo tokens and cannot be used for and is not recommended for transport of end-user passwords
  • contact object in the ns section is ignored

This command covers a lot of functionality, it can complete operations such as:

  • change registrant for domain
  • add name server to domain
  • remove name server from domain
  • add admin contact
  • remove admin contact
  • add billing contact
  • remove billing contact
  • remove DSRECORDS
  • add DSRECORDS
  • set/generate AuthInfo token
  • unset/clear AuthInfo token

In addition it supports DNSSEC management capabilities as specified in RFC:5910.

The command will be evaluated as an atomic command, even though it is dispatched to several sub-commands.

Diagram of EPP process for EPP update domain 👁️‍🗨️

The requirements for the command to commence with processing it that the following data are available:

  • a valid domain name
  • a sub-command, consisting of either
    • add (add)
    • change (chg)
    • remove (rem)

If the request is not valid the service responds with a 2005.

If the command is valid, the command is separated into one of more of the following sub-commands (by order of precedence):

  1. change registrant

  2. remove name server

  3. remove admin contact

  4. remove billing contact

  5. add name server

  6. add admin contact

  7. add billing contact

  8. remove DSRECORDS

  9. add DSRECORDS

  10. setting authinfo

  11. unsetting authinfo

The commands are then executed sequentially (order is dictates the precedence) as a single transaction. If a single sub-command fails, the transaction is rolled-back and the relevant error code is returned (2XXX).

The command might be stopped if the sub-commands cannot be executed. For example if one of the sub-commands is a: change registrant, none of the other commands can be executed, since role changes will be implicit.

Do note that the change of billing contact, if inserting a registrar-user, will be silent, meaning no e-mails will be sent to the registrant or existing billing contact or other contacts.

When the command succeeds either 1000 or 1001 is returned the latter if one of the operations initiated by the sub-command require additional actions to be taken, 1001 will have precedence over 1000. If a 1001 is returned the status code pendingUpdate might be set if an additional update domain command is issued.

Diagram of EPP process for EPP update domain command evaluation 👁️‍🗨️

Return Code Description
1000 If the update domain command is successful
1001 If the update domain command awaits acknowledgement by 3rd. party
2005 Syntax of the command is not correct
2102 Change of status for host object is not supported
2201 If the authenticated user does not hold the privilege to update the specified domain object
2303 If the specified domain name does not exist
2303 If the specified host name does not exist, for when adding a new name server
2303 If the specified host name does not exist, for when removing a name server
2303 If the specified contact-id does not exist, for when adding a new billing contact
2304 If the specified host name does not link with the specified domain name, for when removing a name server
2307 Unimplemented object service, the service does not support change of registrant on a domain
2308 The number of name servers are below the required limit

Please see the below sections for details on the different sub-commands.

The command might be blocked and the status code: serverUpdateProhibited is returned indicating that an update is not possible. The status code clientUpdateProhibited will be returned if the issued update request cannot be fulfilled due to a domain lock with the registry. See also ICANN description of status codes.

update domain request
<?xml version="1.0" encoding="UTF-8"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<update>
			<domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
				<domain:name>eksempel.dk</domain:name>
				<domain:add/>
				<domain:rem/>
				<domain:chg/>
			</domain:update>
		</update>
		<clTRID>c6a678333c526109dea562b42a678398</clTRID>
	</command>
</epp>

REF: issue #9

update domain response
<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1000">
			<msg>Command completed successfully</msg>
		</result>
		<msgQ count="10" id="1">
		</msgQ>
		<trID>
			<clTRID>16465c9766e24e1d1d92d5254a3f3717</clTRID>
			<svTRID>B9B4777A-CC4A-11E6-84D4-467D3A107CA1</svTRID>
		</trID>
	</response>
</epp>

change registrant

The change of registrant operation results in all privileges and rights being transferred to another entity. A registrar only holds the privileges to complete such an operation for domains in own portfolio.

This mean the following prerequisites have to be met:

  • The domain name has to be in the portfolio of the registrar requesting the change

  • The registrant on the domain name has to be in the portfolio of the registrar requesting the change

  • The domain name has to be in a state where it can have the registrant changed

  • The contact designated to be appointed as the new registrant are in the portfolio of the registrar requesting the change

  • The contact designated to be appointed as the new registrant has to be in a state where it can be assigned the role of registrant

The command can be issued in two variations:

  1. With the use of the dkhm:orderconfirmationToken, where the designated registrant has approved Terms and Condition for Punktum dk with the registrar.

  2. As standard without any use of extensions

The two above methods reflect the same usage as for domain name application using domain create.

Here follows an example of a request to change the registrant using the seconds method.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <command>
        <update>
            <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
                <domain:name>eksempel.dk</domain:name>
                <domain:chg>
                    <domain:registrant>DKHM1-DK</domain:registrant>
                </domain:chg>
            </domain:update>
        </update>
        <clTRID>ABC-12345</clTRID>
    </command>
</epp>

The response indicates that the operation has one or more pending actions

  1. Punktum dk require that the designated registrant accepts terms and conditions

  2. Punktum dk require that ID-control is successfully completed

If the registrant already has completed ID-control, the second action will not be required.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <response>
        <result code="1001">
	        <msg>Command completed successfully; action pending</msg>
        </result>
        <trID>
            <clTRID>ABC-12345</clTRID>
            <svTRID>54321-XYZ</svTRID>
        </trID>
    </response>
</epp>

To assist the registrant the registrar can offer collect the accept of terms and conditions for Punktum dk and indicate the accept of these via the extension: dkhm:orderconfirmationToken.

Then the request would have to be extended with the use of the mentioned extension:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <command>
        <update>
            <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
                <domain:name>eksempel.dk</domain:name>
                <domain:chg>
                    <domain:registrant>DKHM1-DK</domain:registrant>
                </domain:chg>
            </domain:update>
        </update>
		<extension>
			<dkhm:orderconfirmationToken xmlns:dkhm=“urn:dkhm:params:xml:ns:dkhm-4.3”>
				1522744544
			</dkhm:orderconfirmationToken>
		</extension>
        <clTRID>ABC-12345</clTRID>
    </command>
</epp>

The below example of a response, when the accept of terms and conditions has been collected and ID-control has been completed beforehand.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <response>
        <result code="1000">
            <msg>Command completed successfully</msg>
        </result>
        <trID>
            <clTRID>ABC-12345</clTRID>
            <svTRID>54321-XYZ</svTRID>
        </trID>
    </response>
</epp>
Return Code Description
1000 If the update domain command is successful
1001 If the update domain command is successful, but an action is pending
2005 Syntax of the command is not correct
2201 If the authenticated user does not hold the privilege to update the specified domain object
2303 If the specified domain name does not exist

add name server

The addition of a new name server to a domain name or a re-delegation requires that the new name server must offer resolution for the domain name in question.

Note as of version of 4.X.X the commands to change name servers (addition and removal) require AuthInfo token. The AuthInfo token is either provided out of band or can be obtained using the info domain command. It can also be generated using the update domain command, please see the section on setting AuthInfo.

With this process change, the change of name servers operation using update domain, also delete all DSRECORDS.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<update>
			<domain:update
			 xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
				<domain:name>eksempel.dk</domain:name>
				<domain:add>
					<domain:ns>
						<domain:hostObj>ns2.example.com</domain:hostObj>
					</domain:ns>
				</domain:add>
			</domain:update>
		</update>
		<clTRID>ABC-12345</clTRID>
	</command>
</epp>

Diagram: Update domain - Add name server 👁️‍🗨️

Return Code Description
1000 If the update domain command is successful
2005 Syntax of the command is not correct
2201 If the authenticated user does not hold the privilege to update the specified domain object
2303 If the specified domain name does not exist
2303 If the specified host name does not exist, for when adding a new name server

remove name server

The removal of a existing name server from a domain name requires that at least two other name servers are offering resolution for the domain in question, else the command will fail.

Since the update domain command can contain several sub-commands, this could be accompanied by an add name server (see above), so the policy requirement is met and resolution is kept.

As noted under "add name server", since version of 4.X.X the commands to change name servers (addition) require AuthInfo token. The AuthInfo token is either provided out of band or can be obtained using the info domain command. It can also be generated using the update domain command, please see the section on setting AuthInfo.

With this process change, the change of name servers operation using update domain, also delete all DSRECORDS.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<update>
			<domain:update
			 xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
				<domain:name>eksempel.dk</domain:name>
				<domain:rem>
					<domain:ns>
						<domain:hostObj>ns1.example.com</domain:hostObj>
					</domain:ns>
					<domain:contact type="tech">sh8013</domain:contact>
				</domain:rem>
			</domain:update>
		</update>
		<clTRID>ABC-12345</clTRID>
	</command>
</epp>

Diagram Update domain - Remove name server 👁️‍🗨️

Return Code Description
1000 If the update domain command is successful
2005 Syntax of the command is not correct
2201 If the authenticated user does not hold the privilege to update the specified domain object
2303 If the specified domain name does not exist
2303 If the specified host name does not exist, for when removing a name server
2304 If the specified host name does not link with the specified domain name, for when removing a name server
2308 The number of name servers are below the required limit

add contact

The addition of a new contact to a domain name has to adhere to some policies. Do note that the change of roles only applies to registrant managed domain names, since the roles on a registrar managed domain name are implicitly the registrar managing the domain name.

  1. If the contact is the admin, only the billing role can be added
  2. If the authenticated user is a registrar only billing can be added
  3. The new contact is requested to accept the role, so the operation is asynchronous

Adding new users require special privileges, only with the registrant, apart from the policy listed above.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<update>
			<domain:update
			 xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
				<domain:name>eksempel.dk</domain:name>
				<domain:add>
					<domain:contact type="tech">mak21</domain:contact>
				</domain:add>
			</domain:update>
		</update>
		<clTRID>ABC-12345</clTRID>
	</command>
</epp>

Diagram: Update domain - Add billing/admin contact 👁️‍🗨️

Diagram: Update domain - Add billing/admin contact sub-process 👁️‍🗨️

Return Code Description
1000 If the update domain command is successful
2005 Syntax of the command is not correct
2201 If the authenticated user does not hold the privilege to update the specified domain object
2303 If the specified domain name does not exist

remove contact

The removal of a existing contact is possible for both billing and admin contacts.

  1. If the contact is the admin, both billing and admin roles can be removed
  2. The admin can add a new billing role (see above)
  3. If no addition the role defaults to the registrant becoming the inhabitant of the role, no request is made, the registrant is only informed of the change out of band

When a contact is removed from a given the registrant is instated in the role.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<update>
			<domain:update
			 xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
				<domain:name>eksempel.dk</domain:name>
				<domain:rem>
					<domain:contact type="tech">sh8013</domain:contact>
				</domain:rem>
			</domain:update>
		</update>
		<clTRID>ABC-12345</clTRID>
	</command>
</epp>

Diagram: Update domain - Remove billing/admin contact 👁️‍🗨️

Diagram: Update domain - Remove billing/admin contact sub-process 👁️‍🗨️

Return Code Description
1000 If the update domain command is successful
2005 Syntax of the command is not correct
2201 If the authenticated user does not hold the privilege to update the specified domain object
2303 If the specified domain name does not exist

Remove DSRECORDS

Example with removal of existing DSRECORDS and adding a new DSRECORD.

<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <command>
        <update>
            <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
                <domain:name>eksempel.dk</domain:name>
                <domain:add/>
                <domain:rem/>
                <domain:chg/>
            </domain:update>
        </update>
        <extension>
            <secDNS:update xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
                <secDNS:rem>
                    <secDNS:all>true</secDNS:all>
                </secDNS:rem>
                <secDNS:add>
                    <secDNS:dsData>
                        <secDNS:keyTag>52378</secDNS:keyTag>
                        <secDNS:alg>13</secDNS:alg>
                        <secDNS:digestType>4</secDNS:digestType>
                        <secDNS:digest>ed3ef3e1787f797a538abf130fd90d7499713976f7da7c05e51826554560fd42bba5e66dbd2f573a75d77eb0b05124c4</secDNS:digest>
                    </secDNS:dsData>
                </secDNS:add>
            </secDNS:update>
        </extension>
        <clTRID>a84e346d7b5b1242f8e0d28fa8fde565</clTRID>
    </command>
</epp>
Return Code Description
1000 If the update domain command is successful
2005 Syntax of the command is not correct
2201 If the authenticated user does not hold the privilege to update the specified domain object
2303 If the specified domain name does not exist
2303 If DSRECORDS do not exist, when removing DSRECORDS

Add DSRECORDS

Example with removal of existing DSRECORDS and adding a new DSRECORD.

<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <command>
        <update>
            <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
                <domain:name>eksempel.dk</domain:name>
                <domain:add/>
                <domain:rem/>
                <domain:chg/>
            </domain:update>
        </update>
        <extension>
            <secDNS:update xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
                <secDNS:rem>
                    <secDNS:all>true</secDNS:all>
                </secDNS:rem>
                <secDNS:add>
                    <secDNS:dsData>
                        <secDNS:keyTag>52378</secDNS:keyTag>
                        <secDNS:alg>13</secDNS:alg>
                        <secDNS:digestType>4</secDNS:digestType>
                        <secDNS:digest>ed3ef3e1787f797a538abf130fd90d7499713976f7da7c05e51826554560fd42bba5e66dbd2f573a75d77eb0b05124c4</secDNS:digest>
                    </secDNS:dsData>
                </secDNS:add>
            </secDNS:update>
        </extension>
        <clTRID>a84e346d7b5b1242f8e0d28fa8fde565</clTRID>
    </command>
</epp>

Setting AuthInfo

Setting the AuthInfo is done using the update domain command. The AuthInfo token is not set as such, but is generated using a keyword indicating the authorization scope, currently supported keywords are:

  • autoredel
  • autotransfer

The AuthInfo token and hence the authorization holds a lifespan of 14 days. It can be ended prematurely by unsetting it, please see below.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <update>
      <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.com</domain:name>
        <domain:chg>
          <domain:authInfo>
            <domain:pw>autoredel</domain:pw>
          </domain:authInfo>
        </domain:chg>
      </domain:update>
    </update>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

The generation of an AuthInfo token can be accomplished by all users with privileges to do so.

When the authorisation has been created it is visible to the users with the privilege to generate it, not just the requester.

The token is accessible in:

  • The service portal in the domain detail page
  • The registrar portal in the domain detail page
  • Via EPP using the domain info command

Unsetting AuthInfo

The requester (setter) of a an AuthInfo authorization might have an interest in ending the life of a AuthInfo token prematurely

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <update>
      <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.com</domain:name>
        <domain:chg>
          <domain:authInfo>
            <domain:null>
          </domain:authInfo>
        </domain:chg>
      </domain:update>
    </update>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

Do note that this can be accomplished by all users with privileges to accomplish this. It adheres to RFC:5731, which states:

A domain:null element can be used within the domain:authInfo element to remove authorization information.

The command simply unsets (removes/clears) an AuthInfo token if it exists.

AuthInfo Token Format

AuthInfo tokens are keys to delegate authorization for a single one-time operation. AuthInfo tokens are limited to work on a single object and perform a single operation, they expire after a specified time, or when used or if they are retracted.

The overall requirements are:

  • Unpredictable (is secure to the extent possible and for the given TTL time frame)
  • Human pronounceable (can be communicated over telephone call)
  • Usable (constrained on length and format)

The AuthInfo token is generated upon request by Punktum dk and will adhere to the following proposed format:

<role>-<operation>-<unique token>

The AuthInfo tokens currently support the operations:

  • Change of registrar via the transfer domain command, by using the keyword TRANSFER
  • Change of name servers via the update domain command, , by using the keyword REDEL

E.g.

A transfer example: REG-TRANSFER-098f6bcd4621d373cade4e832627b4f6

  • The authorization is generated/issued by a registrar (REG, for registrar)
  • The authorization is for a transfer operation (TRANSFER)
  • and finally a unique key

Since an authorization could also be issue by the registrant, that example would resemble the following: OWN-TRANSFER-098f6bcd4621d373cade4e832627b4f6

  • The authorization is generated/issued by a registrant (OWN, for registrant/owner)
  • The authorization is for a transfer operation (TRANSFER)
  • and finally a unique key

An change of name servers example: NSA-REDEL-098f6bcd4621d373cade4e832627b4f6

  • The authorization is for a transfer operation (REDEL, for redelegation)
  • The authorization is generated/issued by a registrar (NSA, for name server administrator)
  • and finally a unique key

Since an authorization could also be issue by the registrant or proxy, those example would resemble the following:

As registrant: OWN-REDEL-098f6bcd4621d373cade4e832627b4f6

  • The authorization is generated/issued by a registrant (OWN, for registrant/owner)
  • The authorization is for a transfer operation (REDEL)
  • and finally a unique key

As proxy PXY-REDEL-098f6bcd4621d373cade4e832627b4f6

  • The authorization is generated/issued by a registrant (PXY, for proxy)
  • The authorization is for a transfer operation (REDEL)
  • and finally a unique key

The authorizations expires after 14 days or by use. It can be retracted via the registrar portal, the self-service portal or EPP by deletion of the authorization.

For registration of domain names offered from a waiting list, the authorization is using AuthInfo, the token here is however simpler and is currently formatted as a 8 character string of case insensitive hexadecimal characters.

delete domain

The default delete domain command behaviour is to deactivate immediately, which complies with RFC:5731. Not being able to complete the request will result in a error, also in compliance with RFC:5731. Please see below for more information on the business process for deletion.

The current expiration date can be obtained using the info domain command and is specified in the domain:exDate field. The date conforms with the required format. The status code, pendingDelete delete is set and can be removed either by the execution of the process after the redemption period or a restore operation.

The alternative approach to deletion is to set auto expire, which will cancel the domain name subscription automatically at expiration.

Do note that it is not possible to delete a domain name on the or after the expiration date of a domain name. Domain name deletion is not prohibited on the expiration date, but due to technical constraints it is recommended to set automatic expiration instead, which will have the same result.

The deletion of a domain name results in a 30 day suspension, which is regarded as a redemption period where it is possible to restore the suspended domain name using the restore domain command.

The status code serverDeleteProhibited is set:

  • If the status pendingCreate is set, see domain create
  • If the status pendingDelete is set
  • If the domain name is on hold or blocked, meaning it has been suspended by Punktum dk
  • If the domain name is superordinate to a name server, which has active name service
  • If the domain completed ID-control unsuccessfully

delete domain request

The complete command will look as follows (example lifted from RFC:5731):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <command>
      <delete>
        <domain:delete xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
          <domain:name>eksempel.dk</domain:name>
          </domain:delete>
      </delete>
      <clTRID>ABC-12345</clTRID>
    </command>
  </epp>

delete domain response

Domain names are not deleted immediately, but are flagged as scheduled for deletion. This of the delete command is successful, the domain name will be flagged for deletion within the timeframe specified by the business rules implemented by Punktum dk.

The response for a delete domain command will be 1001.

Response example (example lifted from RFC:5731 and modified):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <response>
      <result code="1001">
        <msg>Command completed successfully; action pending</msg>
      </result>
      <trID>
        <clTRID>ABC-12345</clTRID>
        <svTRID>54321-XYZ</svTRID>
      </trID>
    </response>
  </epp>

The expiration date will be adjusted accordingly and a status pendingDelete with an advisory date will be applied and made available via the response to the info domain command, via the Punktum dk extension: domainAdvisory.

Example:

<extension>
    <dkhm:domainAdvisory advisory="pendingDeletionDate" date="2021-01-31T00:00:00.0Z" domain="eksempel.dk" xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3"/>
</extension>

Do note that a delete domain command will disable auto renewal if enabled.

Do note that if subordinates exist these will block for a delete and the request will result in an error: 2305.

restore domain

As described in RFC:3915, with a support for grace periods, it is possible to restore a domain name scheduled for deletion, (in the state pendingDelete).

Punktum dk will support the ability to restore for two use-cases:

  1. Get a domain name back to the state active from a pending deletion specified by an explicit deletion request (delete command) or a automatic expiration
  2. Get a domain name back to state active from a pending deletion, caused by missing financial settlement

Domain names might be suspended for other reasons, these will no be recoverable using the described restore facility, this will be indicated using the serverUpdateProhibited status.

Restoration has to take place during the redemption period and will not be possible after the grace period has expired.

The restoration is requested using the update domain command.

restored domain request

Based on feedback from our users, we have decided to not implement the request operation part of the restoration process, so you have to skip directly to the report part of the process.

This mean we will not support the state of pendingRestore for the restore process.

The step to actually complete the restoration is the report operation, which look as follows:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
    <command>
        <update>
            <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd">
                <domain:name>example.com</domain:name>
                <domain:chg/>
            </domain:update>
        </update>
        <extension>
            <rgp:update xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0 rgp-1.0.xsd">
                <rgp:restore op="report">
                    <rgp:report>
                        <rgp:preData></rgp:preData>
                        <rgp:postData></rgp:postData>
                        <rgp:delTime>2003-07-10T22:00:00.0Z</rgp:delTime>
                        <rgp:resTime>2003-07-20T22:00:00.0Z</rgp:resTime>
                        <rgp:resReason></rgp:resReason>
                        <rgp:statement></rgp:statement>
                    </rgp:report>
                </rgp:restore>
            </rgp:update>
        </extension>
        <clTRID>ABC-12345</clTRID>
    </command>
</epp>

Example is lifted from RFC:3915.

The proposal is to the the report part act as an acknowledgement. The domain name is restored as-is if possible, so the mandatory fields:

  • rgp:preData
  • rgp:postData
  • rgp:resReason
  • rgp:statement

Have to be specified, but values are ignored. As are the optional field, which however is optional and does not have to be specified:

  • rgp:other

The mandatory fields:

  • rgp:delTime
  • rgp:resTime

Have to be specified and will be evaluated according to RFC:3915.

  • The rgp:delTime value has to match the deletion date and time.
  • The rgp:resTime value will be ignored since, we do not handle the request operation.

As described in RFC:3915, multiple report requests can be submitted, until success and within the allowed timeframe of possible restoration.

restore domain response

A response indicating unsuccessful restoration attempt will look as follows:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <response>
        <result code="2004">
            <msg>Delete date is incorrect</msg>
        </result>
        <trID>
            <clTRID>ABC-12345</clTRID>
            <svTRID>54321-XYZ</svTRID>
        </trID>
    </response>
</epp>

Example lifted from RFC:5730 and modified.

A response indicating successful restoration attempt will look as follows:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
    <response>
        <result code="1000">
            <msg lang="en">Command completed successfully</msg>
        </result>
        <extension>
            <rgp:upData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0 rgp-1.0.xsd">
                <rgp:rgpStatus s="pendingRestore"/>
            </rgp:upData>
        </extension>
        <trID>
            <clTRID>ABC-12345</clTRID>
            <svTRID>54321-XYZ</svTRID>
        </trID>
    </response>
</epp>

Example is lifted from RFC:3915.

XSD Definition

The restore command is an extension to update domain. All is described in RFC:3915. The XSD has been included in our EPP XSD repository as rgs-1.0.xsd all lifted from RFC:3915, please see the repository for details.

transfer domain

The transfer command is only available to registrars. The command should used in the following use-cases.

  • Transfer from Punktum dk to a future registrar
  • Transfer from the current registrar to a future registrar

The implementation is based on a pull model and both operations require authorization via the use of an AuthInfo token and designated domain name. The operation has to be initiated by the future registrar. who has acquired the authorization (AuthInfo token) from the current registrar or the registrant.

The transfer from Punktum dk to a new registrar implies a change of administrative model from "registrant management" to "registrar management". Whereas the transfer from registrar to registrar is only a change of administrative party not the administrative model.

The registrar always have the option to withdraw from the role of registrar for a given domain name, this change does not require an authorization. The operation is implemented using the withdraw command, described below in details. This command set the registrar to be the registry (Punktum dk) and the administrative model changes from "registrar management" to "registrant management".

Also the registrant has the option to exchange the current registrar. This operation implies a change of administrative model from "registrar management" to "registrant management" and is limited to change of model. A change of registrar, requires authorization of a third party by the registrant and that the designated registrar executes the operation of taking the role of administrator as described initially in this section.

The administration of authorizations is described in detail under the update-domain command.

Do also see the general description of the AuthInfo implementation.

The transfer process differs from the one outlined in the RFC:5731, the following status codes should only be the ones observed:

  • serverApproved

The following should not be observed (ref: domain:trStatus), since the process does not implement the same transactional model:

  • clientApproved
  • clientCancelled
  • clientRejected
  • pending
  • serverCancelled

Upon transfer, the contact object referring to the registrant role, is being cloned to avoid issues with disappearing data and sponsorship in cross-portfolio operations. Do note that Punktum dk does not implement direct transfer of contact objects as described in the "Implementation Limitations" section.

A contact object (registrant) is cloned without additional relations bound to other objects within the registry or another portfolio, only the key object, the domain name is transferred, together with potential subordinate objects such as name servers.

The cloning is a best-effort cloning, since the ID-control status cannot be guaranteed to be consistent in the case where a contact object is locked to a register, but has limitations in access to data due to policies in regard to disclosure etc.

The clone might be deleted if these relations are terminated or removed, please see the description of the contact object deletion policy described in the section on the delete contact command for details.

The status code serverTransferProhibited is set:

  • If the status pendingCreate is set, see domain create
  • If the domain name is not settled/paid
  • If the domain name is registrant managed and has VID service
  • If the registrant has an active or declined ID-control request
  • If the domain name is on hold or blocked, meaning it has been suspended by Punktum dk

Transition Period

The transition period is a special period following the introduction of the transfer command with version 4.0.0 of the EPP service.

During the transition period, registrars can do a transfer without providing the else mandatory AuthInfo token with the transfer domain command.

The following prerequisites has to be in place for this operation to be possible:

  • The designated domain name has to be linked to a name server belonging to the requesting registrar
  • This ownership is identified as the name server administrator for the specific name server is linked to the registrar group of the requesting registrar
  • The transfer has to be completed by a user with the registrar role, which can be appointed in the registrar portal
  • The registrar will have to have collected a consent from the registrant of the designated domain name

The moment a transfer from registrant management is completed, it is no longer viable for this transfer, even if the name servers are administered by others that the registrar

If a domain name is transferred back to the registry, it will become eligible for the transfer again, of course the mentioned conditions will have to be met and the consent will have to be collected again.

transfer domain request
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <transfer op="request">
      <domain:transfer xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>eksempel.dk</domain:name>
        <domain:period unit="y">1</domain:period>
        <domain:authInfo>
          <domain:pw>DKHM1-DK-098f6bcd4621d373cade4e832627b4f6</domain:pw>
        </domain:authInfo>
      </domain:transfer>
    </transfer>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

Example is lifted from RFC:5731 and modified.

transfer domain response
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <domain:trnData xmlndomain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>eksempel.dk</domain:name>
        <domain:trStatus>serverApproved</domain:trStatus>
        <domain:reID>ClientX</domain:reID>
        <domain:reDate>2000-06-08T22:00:00.0Z</domain:reDate>
        <domain:acID>ClientY</domain:acID>
        <domain:acDate>2000-06-13T22:00:00.0Z</domain:acDate>
        <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>
      </domain:trnData>
    </resData>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>

Example is lifted from RFC:5731 and modified.

Return Code Description
1000 If the transfer domain command is successful
2005 Syntax of the command is not correct
2201 If the authenticated user does not hold the privilege to transfer the specified domain object or the AuthInfo token does not exist
2303 If the specified domain name does not exist
2304 If the requesting user does not have the privilege and is not authorized to transfer the domain
2400 The operation failed

Withdraw

Punktum dk support the option for registrars of transferring out, so where the regular transfer command (described above) is a pull operation. The registrar can push a domain name from it's portfolio to Punktum dk, when and if a registrar requires so.

The process resembles the transfer, but with the receiving account being Punktum dk.

The implementation is based on the extension developed by Norid, the registry for the ccTLD for Norway (.no). The specification is listed in the references section below.

Since this extension is at a higher level than the other extensions defined by Punktum dk. The definition look as follows:

<!-- dkhm-4.3.xsd -->
<element name="withdraw" type="dkhm:withdrawType"/>
<complexType name="withdrawType">
  <sequence>
    <element name="name" type="eppcom:labelType"/>
  </sequence>
</complexType>

Ref: dkhm-4.3.xsd

<?xml version="1.0" encoding="UTF-8"?>

<schema targetNamespace="urn:dkhm:params:xml:ns:dkhm-domain-4.3"
        xmlns:dkhm-domain="urn:dkhm:params:xml:ns:dkhm-domain-4.3"
        xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
        xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
        xmlns="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified">

  <import namespace="urn:ietf:params:xml:ns:eppcom-1.0" schemaLocation="eppcom-1.0.xsd"/>
  <import namespace="urn:ietf:params:xml:ns:epp-1.0" schemaLocation="epp-1.0.xsd"/>

  <annotation>
    <documentation>Extensible Provisioning Protocol v1.0 provisioning schema. DKHM extension v4.3 for domain</documentation>
  </annotation>

  <element name="withdraw" type="dkhm-domain:withdrawType"/>

  <complexType name="withdrawType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
    </sequence>
  </complexType>
</schema>

Ref: dkhm-domain-4.3.xsd

withdraw request

An example of a withdraw XML request would look as follows (example lifted from Norid specification and modified):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
  <extension>
    <command xmlns="urn:dkhm:params:xml:ns:dkhm-4.3">
      <withdraw>
        <domain:withdraw xmlns:domain="urn:dkhm:params:xml:ns:dkhm-domain-4.3">
          <domain:name>eksempel.dk</domain:name>
        </domain:withdraw>
      </withdraw>
      <clTRID>ABC-12345</clTRID>
    </command>
  </extension>
</epp>

withdraw response
<epp xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"
    xmlns="urn:ietf:params:xml:ns:epp-1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <response>
        <result code="1000">
            <msg>Command completed successfully</msg>
        </result>
        <resData>
            <domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
                <domain:name>eksempel.dk</domain:name>
                <domain:trStatus>serverApproved</domain:trStatus>
                <domain:reID>REG-12345</domain:reID>
                <domain:reDate>2021-10-08T06:35:28Z</domain:reDate>
                <domain:acID>DKHM1-DK</domain:acID>
                <domain:acDate>2021-10-08T06:35:28Z</domain:acDate>
                <domain:exDate>2021-10-08T06:35:28Z</domain:exDate>
            </domain:trnData>
        </resData>
        <trID>
            <clTRID>ABC-12345</clTRID>
            <svTRID>ED213B80-2801-11EC-AA6C-3E865F504B00</svTRID>
        </trID>
    </response>
</epp>

Contact

The default behavior of the EPP create contact command as described in RFC:5733, will attach the client-ID (CLID) of the authenticated party to the object created, just as for the domain creation described above.

The contact object will be under the sponsoring party throughout it's life-cycle and transfer of contact objects will not be explicitly supported, see Unimplemented commands section.

As for the create domain command (above) the default behaviour can be defined in RP. Where the option "registrant management", will create contact objects sponsored by Punktum dk instead instead of the registrar.

Deletion will not be supported and will work as it currently is implemented in the Punktum dk EPP service and described in the specification. See the section: Unimplemented commands for details. Contact objects are automatically deleted, under the following policy:

  • The contact object is not in use
  • It holds not roles/association with other objects
  • The associated financial account holds a balance of 0
  • It has been inactive for 45 days

The maintenance, meaning changes and updates to data, will also be limited. Punktum dk locks contact objects for changes if these have been matched to a register for name and address information, this applies to:

  • Danish citizens of the type individual, bound to the CPR register
  • Danish companies, public organizations and associations of the types, bound to the CVR register

The following contact types are also limited, due to the VAT number validation:

  • EU companies, public organizations and associations of the types, bound to the EU Vies register

All other types has to be maintained by the sponsoring client, with the exception of the name attribute.

A contact object consist of the following data.

Data Can be locked Note
User type ✅ The is communicated via the extension: dkhm:userType
Name ✅ The is included in the standard, see: RFC:5733 (contact:name) / (contact:org), see: Address Handling
Address ✅ The is included in the standard, see: RFC:5733 (contact:addr)
Country ✅ The is included in the standard, see: RFC:5733 (contact:voice)
Attention The is included in the standard, see: RFC:5733 (contact:name) / (contact:org), see: Address Handling
Phone The is included in the standard, see: RFC:5733 (contact:voice)
Mobile phone The is communicated via the extension: dkhm:mobilephone
Fax The is included in the standard, see: RFC:5733 (contact:fax)
Email The is included in the standard, see: RFC:5733 (contact:email)
Secondary email The is communicated via the extension: dkhm:secondaryEmail
VAT number ✅ The is communicated via the extension: dkhm:CVR
P-number The is communicated via the extension: dkhm:pnumber
EAN ✅ The is communicated via the extension: dkhm:EAN

The locking of data is towards an authoritative register, like CPR (Central Person Register, Danish individuals) or CVR (Dansk Virksomheds Register, Danish companies, associations and public organisations).

Locking is applied in conjunction with

  • Successful ID-control
  • For Danish companies, associations and public organisations if a CVR number is matched towards the CVR register
  • For European companies, associations and public organisations if a VAT number is matched towards the VIES service
  • For contact object appointed as registrants and waiting list position owners, the name is locked in order to prevent change of ownership of these

create contact

This part of the EPP protocol is described in RFC:5733.

This command has been extended with the following fields:

  • dkhm:usertype, which has to be one of:
    • company, indicating a company
    • public_organization, indicating a public organization
    • association, indicating an association
    • individual, indicating an individual

The user type will result in context-specific interpretation of the following fields:

  • EAN - this number is only supported for user types: company, public_organization and association. It is only mandatory for public_organization and optional for company and association. EAN is used by the public sector in Denmark for electronic invoicing, private companies can also be assigned EAN, but this it not so widespread at this time. EAN is required by law for public sector organizations, so this field has to be completed and it has to validate for this type.
  • CVR - (VAT number) this is only supported for user types: company, public_organization and association. The number is required for handling VAT correctly, The rules for indication of the field is specified in the table below.
  • p-number - (production unit number) this is only supported for user types: company, public_organization and association. The number is used for handling validation correctly and it relates to the CVR (Vat number field) the field is optional.

This field is validated on the server side, it is however recommended to perform a check contact on the requested contact-id prior to the create domain request if a contact-id is already known from a contact create or previous domain creation/application.

The contact-id field is auto-generated and assigned by Punktum dk. EPP do however open for providing a contact-id in the context of the create contact command, this is not supported by Punktum dk at this point, see also: Implementation Limitations.

The choice of administration model is based on the default set for the registrar account, this influences domain application and contact creation and this can be set in the registrar portal. It can be overwritten per request using the dkhm:management extension, which can have one of two values:

  • registrar, indicating registrar management
  • registrant, indicating registrant management

CVR / Vat Number Indication
Mandatory Note
company/public_organization/association with address in Denmark and EU/EØS Yes Has to be specified
company/public_organization/association with address EU/EØS No Can be specified if VAT handling is required
company/public_organization/association with address outside Denmark and EU/EØS No Can be specified
individual with address in Denmark and EU/EØS No Not supported
individual with address outside Denmark and EU/EØS No Not supported

Forced and Smart Contact Creation

For contact creation Punktum dk supports two ways:

  1. Smart creation, where the data provided is used to inquire if an existing user with the same data is present. If no user is found a new contact is created. This is accomplished using the keyword: auto
  2. Forced creation, where a new contact is created. This is accomplished using the keyword: force

Specification of a user-id / handle for the contact creation is not supported. The user-id / handle is auto-generated and assigned by Punktum dk.

For smart creation:

<contact:id>auto</contact:id>

For forced creation:

<contact:id>force</contact:id>

Please note that the auto and force keywords are in lower-case.

The match for the smart creation are applicable for the following data:

  • <dkhm:userType>
  • <dkhm:CVR>
  • <contact:name>
  • <contact:street>
  • <contact:email>
  • <contact:pc>
  • <contact:cc>

The match has to be exact in order for the command to return an existing user-id / handle.

Since created users might be selected for ID-control and ID-control can alter the data an [contact info](#info-contact), can be useful to validate customer data. Prior to attempted match.

Diagram for contact creation 👁️‍🗨️

Address Handling

Contact creation under EPP opens for the ability to represent postal information in both local and international representations. Due to the representation in Punktum dk's system for handling contacts the following rules are applied to postal information.

For Denmark the local representation is chosen and the international representation is discarded. For other countries the international representation is chosen and the local representation is discarded. Please see the table below.

Denmark Other country
Local representation Local representation
International representation International representation

This is a diagram depicting the general algorithm used for resolving the address data. The algorithm presupposes that at least one address is present.

Diagram of address resolution for contact creation 👁️‍🗨️

It is important to note that if the international representation is specified, but data are provided in local representation or only local representation is provided for an international address, communication to the specified address might prove unreliable.

The handling of name and organization is also a special case. Where the following mapping is made based on the user type.

Name and Organization ProvidedOnly name provided
User typeName (mandatory)organization (optional)Name (mandatory)
C (Company)attentionnamename
P (Public organization)attentionnamename
A (Association)attentionnamename
I (Individual)name-name

The data is collected as required by Danish legislation. See also the data collection policy section below.

Please note:

  • authInfo section is ignored is not recommended for transport of end-user passwords, see also AuthInfo.
  • Contact creation is silent and the designated contact object is not notified about the the creation, unless this is a part of the process of associating the user with other objects

create contact request
<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<command>
		<create>
			<contact:create xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsd">
				<contact:id>auto</contact:id>
				<contact:postalInfo type="loc">
					<contact:name>Johnny Login</contact:name>
					<contact:org>Punktum dk A/S</contact:org>
					<contact:addr>
						<contact:street>Kalvebod brygge 45, 3. sal</contact:street>
						<contact:city>København V</contact:city>
						<contact:pc>1560</contact:pc>
						<contact:cc>DK</contact:cc>
					</contact:addr>
				</contact:postalInfo>
				<contact:postalInfo type="int">
					<contact:name>Johnny Login</contact:name>
					<contact:org>Punktum dk A/S</contact:org>
					<contact:addr>
						<contact:street>Kalvebod brygge 45, 3.</contact:street>
						<contact:city>Copenhagen V</contact:city>
						<contact:pc>1560</contact:pc>
						<contact:cc>DK</contact:cc>
					</contact:addr>
				</contact:postalInfo>
				<contact:voice>+45.33646060</contact:voice>
				<contact:fax />
				<contact:email>[email protected]</contact:email>
				<contact:authInfo>
					<contact:pw />
				</contact:authInfo>
			</contact:create>
		</create>
		<extension>
			<dkhm:userType xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">company</dkhm:userType>
			<dkhm:CVR xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">1234567891231</dkhm:CVR>
		</extension>
		<clTRID>8cced469f2bfdbb0dcad16b875d87c99</clTRID>
	</command>
</epp>

Do note that the authInfo part is ignored, but cannot be omitted, since it is specified as mandatory by the EPP protocol in RFC:5733.

create contact response
<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1000">
			<msg>Contact created.</msg>
		</result>
		<msgQ count="1" id="400">    </msgQ>
		<resData>
			<contact:creData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
				<contact:id>DHA484-DK</contact:id>
				<contact:crDate>2015-03-25T17:08:25.0Z</contact:crDate>
			</contact:creData>
		</resData>
		<trID>
			<clTRID>8cced469f2bfdbb0dcad16b875d87c99</clTRID>
			<svTRID>8B9461A4-D311-11E4-B79D-DB67C33995C9</svTRID>
		</trID>
	</response>
</epp>

check contact

This part of the EPP protocol is described in RFC:5733. This command adheres to the standard.

check contact request
<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<command>
		<check>
			<contact:check xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsd">
				<contact:id>DKHM1-DK</contact:id>
			</contact:check>
		</check>
		<clTRID>d4d94d2e1d6f613cb276865c49c3d0b7</clTRID>
	</command>
</epp>

check contact response
<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1000">
			<msg>Check result</msg>
		</result>
		<msgQ count="6" id="884">
			<msg>Create domain pending for domain2xyz.dk</msg>
		</msgQ>
		<resData>
			<contact:chkData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
				<contact:cd>
					<contact:id avail="0">DKHM1-DK</contact:id>
					<contact:reason>In use</contact:reason>
				</contact:cd>
			</contact:chkData>
		</resData>
		<trID>
			<clTRID>d4d94d2e1d6f613cb276865c49c3d0b7</clTRID>
			<svTRID>3268EB00-F6F7-11E3-867F-A6B052036DCB</svTRID>
		</trID>
	</response>
</epp>

info contact

This part of the EPP protocol is described in RFC:5733. This command has been extended with information on whether the contact in queried has been validated according to requirements and policies with Punktum dk.

See the extension: dkhm:contact_validated extension used in the response.

Please note that the email address (contact:email) is masked and the value: [email protected] is always returned for this field, Unless the authenticated user has a relationship via the domain name or a registrar group association, which provides access to more information.

The info contact command response is only available for the registrant contact object, unless the authenticated user has a relationship via the domain name or a registrar group association, which provides access to more information or additional contact objects.

info contact request
<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<command>
		<info>
			<contact:info xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsd">
				<contact:id>DKHM1-DK</contact:id>
			</contact:info>
		</info>
		<clTRID>3d65841027692e64c24118ac5988e03c</clTRID>
	</command>
</epp>

info contact response
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1000">
			<msg>Info result</msg>
		</result>
		<resData>
			<contact:infData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
				<contact:id>DKHM1-DK</contact:id>
				<contact:roid>DKHM1-DK</contact:roid>
				<contact:status s="serverUpdateProhibited"/>
				<contact:status s="serverTransferProhibited"/>
				<contact:status s="linked"/>
				<contact:status s="serverDeleteProhibited"/>
				<contact:postalInfo type="loc">
					<contact:name>Punktum dk A/S</contact:name>
					<contact:addr>
						<contact:street>Kalvebod Brygge 45,3</contact:street>
						<contact:city>København V</contact:city>
						<contact:pc>1560</contact:pc>
						<contact:cc>DK</contact:cc>
					</contact:addr>
				</contact:postalInfo>
				<contact:voice>+45.33646060</contact:voice>
				<contact:email>[email protected]</contact:email>
				<contact:clID>DKHM1-DK</contact:clID>
				<contact:crID>n/a</contact:crID>
				<contact:crDate>2013-01-24T15:40:37.0Z</contact:crDate>
			</contact:infData>
		</resData>
		<extension>
			<dkhm:contact_validated xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">1</dkhm:contact_validated>
		</extension>
		<trID>
			<clTRID>76edfef5b78cdaefe8fb426eb8d74b75</clTRID>
			<svTRID>C8C5E496-9CC8-11E4-9F91-D0BF2AC2711D</svTRID>
		</trID>
	</response>
</epp>

update contact

This part of the EPP protocol is described in RFC:5733. This command adheres to the standard. In addition to the standard the command allows for manipulation of the extensions associated with contact objects, meaning that it is possible to update the following fields:

These of course all controlled by relevant privileges.

  • Name / organization
  • Address
  • Country
  • Phone (voice)
  • Fax
  • Email
  • Secondary email
  • Mobile phone

Diagram of EPP update contact 👁️‍🗨️

Please note:

  • authInfo section is ignored is not recommended for transport of end-user passwords, see also AuthInfo.

update contact request
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<update>
			<contact:update
			 xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
				<contact:id>sh8013</contact:id>
				<contact:add>
					<contact:status s="clientDeleteProhibited"/>
				</contact:add>
				<contact:chg>
					<contact:postalInfo type="int">
						<contact:org/>
						<contact:addr>
							<contact:street>124 Example Dr.</contact:street>
							<contact:street>Suite 200</contact:street>
							<contact:city>Dulles</contact:city>
							<contact:sp>VA</contact:sp>
							<contact:pc>20166-6503</contact:pc>
							<contact:cc>US</contact:cc>
						</contact:addr>
					</contact:postalInfo>
					<contact:voice>+1.7034444444</contact:voice>
					<contact:fax/>
					<contact:authInfo>
						<contact:pw>2fooBAR</contact:pw>
					</contact:authInfo>
					<contact:disclose flag="1">
						<contact:voice/>
						<contact:email/>
					</contact:disclose>
				</contact:chg>
			</contact:update>
		</update>
		<extension>
				<dkhm:secondaryEmail xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">[email protected]</dkhm:secondaryEmail>
				<dkhm:mobilephone xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">+1.7034444445</dkhm:mobilephone>
		</extension>
		<clTRID>ABC-12345</clTRID>
	</command>
</epp>

Do note that the authInfo part is ignored, but cannot be omitted, since it is specified as mandatory by the EPP protocol in RFC:5733.

update contact response
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<response>
		<result code="1000">
			<msg>Command completed successfully</msg>
		</result>
		<trID>
			<clTRID>ABC-12345</clTRID>
			<svTRID>54321-XYZ</svTRID>
		</trID>
	</response>
</epp>

delete contact

This command is not supported.

This command will always return: 2101, indicating unimplemented command.

The deletion of contact objects is handled automatically by Punktum dk. The following status flags will be set:

  • clientDeleteProhibited
  • serverDeleteProhibited

The later will only be lifted when the contact object is not linked to any other objects and automatic deletion is scheduled.

delete contact request
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<delete>
			<contact:delete
			 xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
				<contact:id>sh8013</contact:id>
			</contact:delete>
		</delete>
		<clTRID>ABC-12345</clTRID>
	</command>
</epp>

delete contact response
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<response>
		<result code="2101">
			<msg>Unimplemented command</msg>
		</result>
		<trID>
			<clTRID>ABC-12345</clTRID>
			<svTRID>54321-XYZ</svTRID>
		</trID>
	</response>
</epp>

transfer contact

Transfer of contacts is not supported in the .dk registry.

When a transfer domain or withdraw operation is done. The contact object appointed to the registrar role is cloned and the clone is allocated to the new portfolio and the original contact object is left intact in the original portfolio.

Host

The default behavior of the EPP create host command as described in RFC:5732, will attach the client-ID (CLID) of the authenticated party to the created host object.

The create host command will be limited in that sense that it will not be possible to create a host object, which is subordinate to a domain name (superordinate), which is sponsored by another registrar.

This mean that the association with the registrar is based on the administrative model.

This limitation will only be enforced for domain names under the .dk TLD. Domain names under other TLDs will not be subject to this limitation.

As for the create domain and create contact commands (above) the default behaviour can be defined in RP. Where the option "registrant management", will create host objects sponsored by Punktum dk instead of the registrar.

Responsibility and privileges for maintenance (update host) of the host object is assigned to the name server administrator as described in the create host section section.

If the name server responsible is allocated to the registrar account (group), this can be handled via RP and EPP.

The deletion of host objects are under a similar regime, as specified in the delete host section.

create host

This part of the EPP protocol is described in RFC:5732. This command adheres to the standard. The command can be extended to specify another name server administrator than the authenticated user.

👉 Please note that IP addresses are required for domain names ending in '.dk', please refer to the glue record policy.

⚠️ By default the authenticated user is attempted used as designated name server administrator, It is however not possible to assign a registrar account as name server administrator, so a regular WHOIS handle pointing to a contact object has to be specified using the extension dkhm:requestedNsAdmin, alternatively you can authenticate using a WHOIS handle and the use of the extension can be avoided.

Diagram of EPP create host 👁️‍🗨️

The command can be used in two scenarios:

  1. The command is used as described in the RFC and the authenticated user is appointed as administrator for the name server created
  2. The command is extended with a contact object pointing to an existing user, which is requested to take the role as name server administrator for the host object requested created
Return Code Description
1000 If the create host command is successful
1001 If the create host command awaits acknowledgement by the contact-id specified in dkhm:requestedNsAdmin
2003 If required IP address is not specified
2004 If the specified IP addresses are non-public addresses
2005 Syntax of the command is not correct
2201 If the authenticated user does not hold the privilege to update the specified host object
2302 If the specified host object already exist
2303 If the contact-id pointed to in dkhm:requestedNsAdmin points to a non-existing contact object
2303 If the domain name for the host is not registered
2306 If the specified name server administrator is a registrar account

As for update domain 1001 holds higher precedence than 1000, so if any of the sub-commands require additional review and are pending, the return code will be 1001.

Diagram of DKH create host 👁️‍🗨️

create host request

Request to create a host object, using both IPv4 and IPv6 addresses and the authenticated user is the registrant of the specified domain name and requested administrator of the host object.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<create>
			<host:create
			 xmlns:host="urn:ietf:params:xml:ns:host-1.0">
				<host:name>ns1.eksempel.dk</host:name>
				<host:addr ip="v4">192.0.2.2</host:addr>
				<host:addr ip="v4">192.0.2.29</host:addr>
				<host:addr ip="v6">1080:0:0:0:8:800:200417A</host:addr>
			</host:create>
		</create>
		<clTRID>ABC-12345</clTRID>
	</command>
</epp>

create host response

Response to the above request. The response indicates a successful creation, since the operation could be completed successfully without requiring offline evaluation.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<response>
		<result code="1000">
			<msg>Command completed successfully</msg>
		</result>
		<resData>
			<host:creData
			 xmlnhost="urn:ietf:params:xml:ns:host-1.0">
				<host:name>ns1.eksempel.dk</host:name>
				<host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
			</host:creData>
		</resData>
		<trID>
			<clTRID>ABC-12345</clTRID>
			<svTRID>54322-XYZ</svTRID>
		</trID>
	</response>
</epp>

create host request with request to new administrator

Request to create a host object, requesting a different administrator of the host object, hence requiring offline evaluation.

Any pending administrator requests are terminated upon creating a new administrator request.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<create>
			<host:create
			 xmlns:host="urn:ietf:params:xml:ns:host-1.0">
				<host:name>ns1.eksempel.dk</host:name>
				<host:addr ip="v4">192.0.2.2</host:addr>
				<host:addr ip="v4">192.0.2.29</host:addr>
				<host:addr ip="v6">1080:0:0:0:8:800:200417A</host:addr>
			</host:create>
		</create>
		<extension>
			<dkhm:requestedNsAdmin xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">ADMIN2-DK</dkhm:requestedNsAdmin>
		</extension>
		<clTRID>ABC-12345</clTRID>
	</command>
</epp>

create host response from request to new administrator

Response to the above request. The response indicates a successful accept of the request, but requires offline evaluation by the designated administrator of the host object, so the response indicates that the operation is pending.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<response>
		<result code="1001">
			<msg>Command completed successfully; action pending</msg>
		</result>
		<resData>
			<host:creData
			 xmlnhost="urn:ietf:params:xml:ns:host-1.0">
				<host:name>ns1.eksempel.dk</host:name>
				<host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
			</host:creData>
		</resData>
		<trID>
			<clTRID>ABC-12345</clTRID>
			<svTRID>54322-XYZ</svTRID>
		</trID>
	</response>
</epp>

Delayed create host response, from request to new administrator

If the creation of the host has resulting in a delayed operation, pending the designated name server administrator, the below example shows what a poll message for the final state of the operation would look like.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<response>
		<result code="1301">
			<msg>Command completed successfully; ack to dequeue</msg>
		</result>
		<msgQ count="5" id="12345">
			<qDate>1999-04-04T22:01:00.0Z</qDate>
			<msg>Pending action completed successfully.</msg>
		</msgQ>
		<resData>
			<host:panData
			 xmlns:host="urn:ietf:params:xml:ns:host-1.0">
				<host:name paResult="1">ns1.eksempel.dk</host:name>
				<host:paTRID>
					<clTRID>ABC-12345</clTRID>
					<svTRID>54322-XYZ</svTRID>
				</host:paTRID>
				<host:paDate>1999-04-04T22:00:00.0Z</host:paDate>
			</host:panData>
		</resData>
		<trID>
			<clTRID>BCD-23456</clTRID>
			<svTRID>65432-WXY</svTRID>
		</trID>
	</response>
</epp>

Please note the paResult, where 1 indicates an accept and 0 would indicate a decline.

create host request, with request to registrant of host domain name

Request to create a host object, where the authenticated use is not the registrant of the domain name naming the host object, hence requiring offline evaluation.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<create>
			<host:create
			 xmlns:host="urn:ietf:params:xml:ns:host-1.0">
				<host:name>ns1.eksempel.dk</host:name>
				<host:addr ip="v4">192.0.2.2</host:addr>
				<host:addr ip="v4">192.0.2.29</host:addr>
				<host:addr ip="v6">1080:0:0:0:8:800:200417A</host:addr>
			</host:create>
		</create>
		<clTRID>ABC-12345</clTRID>
	</command>
</epp>

create host response, from request to registrant of domain name

Response to the above request. The response indicates a successful accept of the request, but requires offline evaluation by the registrant of the specified domain name, so the response indicates that the operation is pending.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<response>
		<result code="1001">
			<msg>Command completed successfully; action pending</msg>
		</result>
		<resData>
			<host:creData
			 xmlnhost="urn:ietf:params:xml:ns:host-1.0">
				<host:name>ns1.eksempel.dk</host:name>
				<host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
			</host:creData>
		</resData>
		<trID>
			<clTRID>ABC-12345</clTRID>
			<svTRID>54322-XYZ</svTRID>
		</trID>
	</response>
</epp>

Delayed create host response, from request to registrant of domain name

If the creation of the host has resulting in a delayed operation, pending the designated name server administrator, the below example shows what a poll message for the final state of the operation would look like.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<response>
		<result code="1301">
			<msg>Command completed successfully; ack to dequeue</msg>
		</result>
		<msgQ count="5" id="12345">
			<qDate>1999-04-04T22:01:00.0Z</qDate>
			<msg>Pending action completed successfully.</msg>
		</msgQ>
		<resData>
			<host:panData
			 xmlns:host="urn:ietf:params:xml:ns:host-1.0">
				<host:name paResult="1">ns1.eksempel.dk</host:name>
				<host:paTRID>
					<clTRID>ABC-12345</clTRID>
					<svTRID>54322-XYZ</svTRID>
				</host:paTRID>
				<host:paDate>1999-04-04T22:00:00.0Z</host:paDate>
			</host:panData>
		</resData>
		<trID>
			<clTRID>BCD-23456</clTRID>
			<svTRID>65432-WXY</svTRID>
		</trID>
	</response>
</epp>

Please note the paResult, where 1 indicates an accept and 0 would indicate a decline.

check host

This part of the EPP protocol is described in RFC:5732. This command adheres to the standard.

check host request

<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<command>
		<check>
			<host:check xmlns:host="urn:ietf:params:xml:ns:host-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 host-1.0.xsd">
				<host:name>ns1.dk-hostmaster.dk</host:name>
			</host:check>
		</check>
		<clTRID>7ede02eed2113c5fe82b404876f2c35f</clTRID>
	</command>
</epp>

check host response

<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1000">
			<msg>Check result</msg>
		</result>
		<resData>
			<host:chkData xmlns:host="urn:ietf:params:xml:ns:host-1.0">
				<host:cd>
					<host:name avail="0">ns1.dk-hostmaster.dk</host:name>
					<host:reason>In use</host:reason>
				</host:cd>
			</host:chkData>
		</resData>
		<trID>
			<clTRID>7ede02eed2113c5fe82b404876f2c35f</clTRID>
			<svTRID>5FD9F3BE-F6F6-11E3-867F-A6B052036DCB</svTRID>
		</trID>
	</response>
</epp>

info host

This part of the EPP protocol is described in RFC:5732. This command adheres to the standard.

Please note that according to the RFC section 3.1.2, the CLID points to the sponsoring client.

This field supports the two administrative models as follows:

  • For registrar managed host object, the CLID points to the registrar, see also Disclosure of Client ID
  • For registrar managed host objects, Punktum dk interprets this as the technical contact for the name server identified by the host object

info host request

<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<command>
		<info>
			<host:info xmlns:host="urn:ietf:params:xml:ns:host-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 host-1.0.xsd">
				<host:name>ns1.dk-hostmaster.dk</host:name>
			</host:info>
		</info>
		<clTRID>c109ef580c81dfca17b4680ddcde72c9</clTRID>
	</command>
</epp>

info host response

<?xml version="1.0" encoding="utf-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1000">
			<msg>Info result</msg>
		</result>
		<resData>
			<host:infData xmlns:host="urn:ietf:params:xml:ns:host-1.0">
				<host:name>ns1.dk-hostmaster.dk</host:name>
				<host:roid>NS1_DK-HOSTMASTER_DK-DK</host:roid>
				<host:status s="linked" />
				<host:status s="serverDeleteProhibited" />
				<host:addr ip=“v4”>4.3.2.1</host:addr>
				<host:clID>DKHM1-DK</host:clID>
				<host:crID>n/a</host:crID>
				<host:crDate>2003-07-07T13:47:47.0Z</host:crDate>
			</host:infData>
		</resData>
		<trID>
			<clTRID>c109ef580c81dfca17b4680ddcde72c9</clTRID>
			<svTRID>0C96C812-F6F6-11E3-867F-A6B052036DCB</svTRID>
		</trID>
	</response>
</epp>

update host

This part of the EPP protocol is described in RFC:5732. This command adheres to the standard, but is extended to service one special usage scenario.

process

This is the overall process, the process is divided into sub-processes, please see the processes below for details.

Diagram of EPP update host 👁️‍🗨️

Change hostname sub-process

The process of changing a host name is unsupported by Punktum dk and will always result in an error code: 2102.

Diagram of EPP update host change hostname 👁️‍🗨️

Return Code Description
2102 Change of hostname is not supported

Add IP Address sub-process

Addition of IP addressed supports the additional of IPv4 and IPv6 addresses. These might be required as part of our glue record policy. If additional status elements are added to this command it will fail.

Return Code Description
1000 If the update host command is successful
2004 If the specified IP addresses are non-public addresses
2005 Syntax of the command is not correct
2102 Change of status for host object is not supported

Diagram of EPP update host add IP 👁️‍🗨️

Remove IP Address sub-process

Addition of IP addressed supports the additional of IPv4 and IPv6 addresses. These might be required as part of our glue record policy. If additional status elements are added to this command it will fail.

Return Code Description
1000 If the update host command is successful
2005 Syntax of the command is not correct
2102 The command contains status elements
2304 The number of IP addresses are below the required limit

Diagram of EPP update host remove IP 👁️‍🗨️

Change admin sub-process

Diagram of EPP update host change admin 👁️‍🗨️

The command can be used in two scenarios:

  1. The command is used as described in the RFC and IP addresses can be administered
  2. The command is extended with a contact object pointing to an existing user, which is requested to takeover the role as name server administrator for the host object requested updated

The update of a host object can only be requested by the administrator of the given host.

Return Code Description
1000 If the update host command is successful
1001 If the update host command awaits acknowledgement by the contact-id specified in dkhm:requestedNsAdmin
2004 If the specified IP addresses are non-public addresses
2005 Syntax of the command is not correct
2102 The command contains status elements
2201 If the authenticated user does not hold the privilege to update the specified host object
2303 If the specified host object does not exist
2303 If the contact-id pointed to in dkhm:requestedNsAdmin points to a non-existing contact object
2304 The number of IP addresses are below the required limit

As for update host 1001 holds higher precedence than 1000, so if any of the sub-commands require additional review and are pending, the return code will be 1001.

As described in Implementation Limitations, the service does not support setting of status via update host.

Diagram of DKH update host 👁️‍🗨️

update host request with request to new administrator

Request to update a host object, requesting a different administrator of the host object, hence requiring offline evaluation.

<?xml version="1.0" encoding="UTF-8"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<update>
			<host:update xmlns:host="urn:ietf:params:xml:ns:host-1.0">
				<host:name>ns1.eksempel.dk</host:name>
			</host:update>
		</update>
		<extension>
			<dkhm:requestedNsAdmin xmlns:dkhm="urn:dkhm:params:xml:ns:dkhm-4.3">DKHM1-DK</dkhm:requestedNsAdmin>
		</extension>
		<clTRID>7a4ac69d335ae661e29fc2c262c5800e</clTRID>
	</command>
</epp>

update host response with request to new administrator

Response to the above request. The response indicates a successful accept of the request, but requires offline evaluation by the designated administrator of the host object, so the response indicates that the operation is pending.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
	<response>
		<result code="1001">
			<msg>Command completed successfully; action pending</msg>
		</result>
		<trID>
			<clTRID>6e95dc191e922be727fd5af4c2d20bc5</clTRID>
			<svTRID>631DABC6-CC49-11E6-A165-4F7D3A107CA1</svTRID>
		</trID>
	</response>
</epp>

Delayed update host response from request to new administrator

If the creation of the host has resulting in a delayed operation, pending the designated name server administrator, the below example shows what a poll message for the final state of the operation looks like.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<response>
		<result code="1301">
			<msg>Command completed successfully; ack to dequeue</msg>
		</result>
		<msgQ count="5" id="12345">
			<qDate>1999-04-04T22:01:00.0Z</qDate>
			<msg>Pending action completed successfully.</msg>
		</msgQ>
		<resData>
			<host:panData
			 xmlns:host="urn:ietf:params:xml:ns:host-1.0">
				<host:name paResult="1">ns1.example.com</host:name>
				<host:paTRID>
					<clTRID>ABC-12345</clTRID>
					<svTRID>54322-XYZ</svTRID>
				</host:paTRID>
				<host:paDate>1999-04-04T22:00:00.0Z</host:paDate>
			</host:panData>
		</resData>
		<trID>
			<clTRID>BCD-23456</clTRID>
			<svTRID>65432-WXY</svTRID>
		</trID>
	</response>
</epp>

Please note the paResult, where 1 indicates an accept and 0 would indicate a decline.

delete host

This part of the EPP protocol is described in RFC:5732. This command adheres to the standard.

Diagram of EPP delete host 👁️‍🗨️

The deletion of a host object can only be requested by the administrator.

Return Code Description
1000 If the delete host command is successful
2201 If the authenticated user does not hold the privilege to delete the specified host object
2303 If the specified host object does not exist
2305 If the specified host object links to domain name objects

delete host request

Request to delete a host object, the authenticated user is the current administrator of the specified host object.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<delete>
			<host:delete
			 xmlns:host="urn:ietf:params:xml:ns:host-1.0">
				<host:name>ns1.eksempel.dk</host:name>
			</host:delete>
		</delete>
		<clTRID>ABC-12345</clTRID>
	</command>
</epp>

delete host response

Response to the above request. Since the authenticated user is the current administrator and all requirements are met the command completes successfully.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<response>
		<result code="1000">
			<msg>Command completed successfully</msg>
		</result>
		<trID>
			<clTRID>ABC-12345</clTRID>
			<svTRID>54321-XYZ</svTRID>
		</trID>
	</response>
</epp>

Data Collection Policy

This chapter describes the data collection policy announced via the greeting available using the hello command.

Please refer to the greeting response example included in the Appendices.

Access

The EPP service provides access to identified data relating to all available entities (personal and organizational) under the terms and conditions that anonymity will be applied as specified by the entities in question, and in accordance with General Terms and Conditions and legislation.

Purpose Statement

The collected data will be used solely for provisioning and administrative purposes. As specified under access above, and in the recipient statement below, some data are required to be publicly available and therefore some data will be accessible to the public under the circumstances specified in the referred sections.

Address data and contact information is collected as required by Danish legislation.

Recipient Statement

Recipients of data are specified as other and unrelated. As specified in the purpose statement section and under access, identified data is made publicly available, therefore Punktum dk will not be able to control how the publicly available information is used.

Retention Statement

Data will be retained with Punktum dk as required by Danish legislation.

References

List of references used in this document in alphabetical order.

  1. Punktum dk: "Terms and conditions for the right of use to a .dk domain name"
  2. Punktum dk: "New basis for collaboration between registrars and Punktum dk"
  3. Punktum dk: EPP General Information
  4. Punktum dk: ID-control General Information
  5. Punktum dk: Waiting list General Information
  6. Punktum dk: Name Service Specification
  7. Punktum dk: RESTful WHOIS Service Specification
  8. Punktum dk: WHOIS Service Specification
  9. Punktum dk: Registrar Portal Service Specification
  10. Punktum dk: Sandbox Environment Specification
  11. Punktum dk: EPP XSD File Repository
  12. ICANN: "EPP Status Codes | What Do They Mean, and Why Should I Know?"
  13. IANA: "Extensions for the Extensible Provisioning Protocol (EPP)"
  14. RFC:3339: "Date and Time on the Internet: Timestamps"
  15. RFC:3735: "Guidelines for Extending Extensible Provisioning Protocol"
  16. RFC:3915: "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)"
  17. RFC:5730: "EPP Basic Protocol"
  18. RFC:5731: "EPP Domain Name Mapping"
  19. RFC:5732: "EPP Host Mapping"
  20. RFC:5733: "EPP Contact Mapping"
  21. RFC:5910: "Domain Name System (DNS) Security Extensions for the Extensible Provisioning Protocol"
  22. RFC:7451: "Extension Registry for the Extensible Provisioning Protocol"
  23. RFC:8748: "Registry Fee Extension for the Extensible Provisioning Protocol (EPP)"
  24. Verisign: "Balance Mapping for the Extensible Provisioning Protocol (EPP)"

Resources

A list of resources for Punktum dk EPP service support is located below.

XSD/XML Schemas

This is a list in alphabetical order of the schemas currently used in the DKHM EPP Service described in this document. Please note that the XSD implementation preserves the original namespace and does not make alterations to this apart from adding the already described XML elements.

  • balance-1.0.xsd
  • contact-1.0.xsd
  • dkhm-3.0.xsd
  • domain-1.0.xsd
  • epp-1.0.xsd
  • eppcom-1.0.xsd
  • host-1.0.xsd
  • rgp-1.0.xsd
  • secDNS-1.1.xsd

The files are all available for download. Details on version history is available in the EPP XSD Repository

Mailing list

Punktum dk operates a mailing list for discussion and inquiries about the Punktum dk EPP implementation. To subscribe to this list, write to the address below and follow the instructions. Please note that the list is for technical discussion only, any issues beyond the technical scope will not be responded to, please send these to the contact issue reporting address below and they will be passed on to the appropriate entities within Punktum dk.

Issue Reporting

For issue reporting related to this specification, the EPP implementation or test, sandbox or production environments, please contact us. You are of course welcome to post these to the mailing list mentioned above, otherwise use the regular support channels.

Demo/Test Client

We have developed a demo/test client, which is freely available and open sourced under a MIT license.

The client is available on GitHub.

Additional Information

More generic information on EPP is available at the Punktum dk website.

Appendices

Greeting

Do note the service version is available in the svID tag, meaning you can see what given version of the EPP service is running in the environment queried.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <greeting>
        <svID>Punktum dk EPP Service: 2.2.3</svID>
        <svDate>2016-12-27T15:19:26.0Z</svDate>
        <svcMenu>
            <version>1.0</version>
            <lang>en</lang>
            <objURI>urn:ietf:params:xml:ns:host-1.0</objURI>
            <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
            <objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
            <svcExtension>
                <extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI>
                <extURI>urn:dkhm:params:xml:ns:dkhm-4.3</extURI>
            </svcExtension>
        </svcMenu>
        <dcp>
            <access>
                <personalAndOther/>
            </access>
            <statement>
                <purpose>
                    <admin/>
                    <prov/>
                </purpose>
                <recipient>
                    <other/>
                    <unrelated/>
                </recipient>
                <retention>
                    <legal/>
                </retention>
            </statement>
        </dcp>
    </greeting>
</epp>

Status Codes

Domain Status Codes

This list of EPP domain status codes is based on information from RFC:5731 and the ICANN status code interpretation: "EPP Status Codes | What Do They Mean, and Why Should I Know?".

The description is the status, use and interpretation by Punktum dk.

As a general business rule, Punktum dk does not support the client* statuses, see also: Unsupported Domain Status Codes in the Implementation Limitations section.

Status Code Description
addPeriod unsupported the status is not described in RFC:5731 only in ICANN resource, see: Unsupported Domain Status Codes
autoRenewPeriod unsupported the status is not described in RFC:5731 only in ICANN resource, see: Unsupported Domain Status Codes
clientDeleteProhibited unsupported, see: Unsupported Domain Status Codes
clientHold unsupported, see: Unsupported Domain Status Codes
clientRenewProhibited unsupported, see: Unsupported Domain Status Codes
clientTransferProhibited unsupported, see: Unsupported Domain Status Codes
clientUpdateProhibited unsupported, see: Unsupported Domain Status Codes
inactive unsupported domain names in the Punktum dk registry must have associated name servers, , see: Unsupported Domain Status Codes
ok Exclusive for all other status codes
pendingCreate Indication that a the given domain is enqueue for possible creation, see domain create or is awaiting allocation with Punktum dk
pendingDelete Deletion is pending, see delete domain. An advisory date is applicable via the extension dkhm:delDate
pendingRenew unsupported as renewal is instantaneous, see: Unsupported Domain Status Codes
pendingRestore unsupported as restoration is instantaneous, see: Unsupported Domain Status Codes
pendingTransfer unsupported as transfer is instantaneous, see: Unsupported Domain Status Codes
pendingUpdate The domain has active asynchronous requests, see update domain
redemptionPeriod This status is applied when a domain name has pendingDelete and the delete operation can be redeemed using restore domain
renewPeriod unsupported the status is not described in RFC:5731 only in ICANN resource, see: Unsupported Domain Status Codes
serverDeleteProhibited Indicates whether the registrant or registrar can delete the domain
serverHold Given domain name is not active, it can hold a number of different internal states rendering it on hold
serverRenewProhibited Indicates a transient status where the billing or registrar contact is not able to renew the domain
serverTransferProhibited Indicates status where the registrant or registrar contact is not able to transfer the domain
serverUpdateProhibited Indicates whether the registrant or registrar for a given domain can have ownership transferred, can appoint new proxy/admin contact, can appoint new billing contact, change name servers and can associate DS Records
transferPeriod unsupported the status is not described in RFC:5731 only in ICANN resource

Contact Status Codes

This list of EPP contact status codes is based on information from RFC:5733.

The description is the status, use and interpretation by Punktum dk.

As a general business rule, Punktum dk does not support the client* statuses, see also: Unsupported Contact Status Codes in the Implementation Limitations section.

Status Code Description
clientDeleteProhibited unsupported, see: Unsupported Contact Status Codes
clientTransferProhibited unsupported, see: Unsupported Contact Status Codes
clientUpdateProhibited unsupported, see: Unsupported Contact Status Codes
linked Object is linked to other objects
ok Exclusive for all other status codes, except linked
pendingCreate unsupported as creation is instantaneous, see: Unsupported Contact Status Codes
pendingDelete unsupported, see: Unsupported Contact Status Codes
pendingTransfer unsupported as transfer is instantaneous, see: Unsupported Contact Status Codes
pendingUpdate unsupported at this time
serverDeleteProhibited Always set deletions are an automated process and the delete command is not supported, see Unimplemented Command: Delete Contact
serverTransferProhibited Always set as users cannot be transferred, see: Unsupported Contact Status Codes and Unimplemented Command: Transfer Contact
serverUpdateProhibited unsupported at this time

Host Status Codes

This list of EPP host status codes is based on information from RFC:5732.

The description is the status, use and interpretation by Punktum dk.

As a general business rule, Punktum dk does not support the client* statuses, see also: Unsupported Host Status Codes in the Implementation Limitations section.

Status Code Description
clientDeleteProhibited unsupported, see: Unsupported Host Status Codes
clientUpdateProhibited unsupported, see: Unsupported Host Status Codes
linked Object is linked to other objects
ok No pending or prohibited operations. Exclusive for all other status codes, except linked
pendingCreate Awaiting accept from registrant if required and awaiting accept from appointed name server administrator if required
pendingDelete Host object has been marked for deletion via deletion of superordinate domain name
pendingTransfer unsupported as transfer is instantaneous, see: Unsupported Host Status Codes and RFC:5732
pendingUpdate Awaiting accept from appointed name server administrator if required
serverDeleteProhibited If the host is linked is it not eligible for deletion
serverTransferProhibited unsupported as transfer for hosts is not defined, see: Unsupported Host Status Codes and RFC:5732
serverUpdateProhibited If the host is marked for deletion (see pendingDelete this status will be set

Privilege Matrix for Registrant Managed Objects

Command Sub-command Registrar Domain name admin Domain name billing Name server admin
login ✅ ✅ *1 ✅ *1 ✅ *1
create domain ✅
update domain ✅ *2 ✅ *2
add billing contact ✅ *8 ✅ *3
remove billing contact ✅ *4 ✅ *4 ✅ *4
add admin contact ✅ *5
remove admin contact ✅ *4
change registrant ✅ *6
add name server ✅ *6 ✅ *6/*10
remove name server ✅ *6 ✅ *6/*10
add DSRECORDS ✅ ✅ *10
remove DSRECORDS ✅ ✅ *10
set AuthInfo for change of name servers ✅ ✅
unset AuthInfo change of name servers ✅ ✅
set AuthInfo for transfer ✅
unset AuthInfo for transfer ✅
renew domain ✅
delete domain ✅ *6
restore domain ✅
info domain ✅ *9 ✅ *9 ✅ *9 ✅ *9
check domain ✅ ✅ ✅ ✅
transfer domain
withdraw ✅
create contact ✅ ✅ ✅ ✅
update contact ✅ *7 ✅ *7
info contact ✅ *9 ✅ *9 ✅ *9 ✅ *9
check contact ✅ ✅ ✅ ✅
create host ✅ ✅
update host ✅
delete host ✅
info host ✅ ✅
check host ✅ ✅
poll ✅ ✅ ✅ ✅
balance ✅ ✅ ✅
  • *1 as registrar, meaning a user associated with a registrar group
  • *2 see sub-commands
  • *3 request to new billing contact
  • *4 defaults to registrant
  • *5 request to to registrant and new admin contact
  • *6 request to registrant
  • *7 only own profile
  • *8 can only assign self
  • *9 can only see contact information for authorized objects, access to registrant is authorized as public other roles require authorization via relation
  • *10 changes status of existing DSRECORDS

Privilege Matrix for Registrar Managed Objects

Command Sub-command Registrar Name server admin
login ✅ ✅
create domain ✅
update domain ✅ *1 ✅ *1
add billing contact
remove billing contact
add admin contact
remove admin contact
change registrant ✅
add name server ✅ ✅
remove name server ✅ *2 ✅ *2
add DSRECORDS ✅ ✅
remove DSRECORDS ✅ ✅
set AuthInfo for change of name servers ✅ ✅
unset AuthInfo change of name servers ✅ ✅
set AuthInfo for transfer ✅
unset AuthInfo for transfer ✅
renew domain ✅
delete domain ✅
restore domain ✅
info domain ✅ *3 ✅ *3
check domain ✅ ✅
transfer domain ✅ *4
withdraw ✅
create contact ✅ ✅
update contact ✅ *5 ✅ *6
info contact ✅ *3 ✅ *3
check contact ✅ ✅
create host ✅
update host ✅ *7 ✅
delete host ✅ *7 ✅
info host ✅ ✅
check host ✅ ✅
poll ✅ ✅
balance ✅ ✅
  • *1 see sub-commands
  • *2 changes status of existing DSRECORDS
  • *3 can only see contact information for authorized objects, access to registrant is authorized as public other roles require authorization via relation
  • *4 requires authorization
  • *5 only data not locked by business rules and under external registry administration such as CPR, CVR and VIES registers
  • *6 only own profile
  • *7 only subordinate host names

Feature and Meta-role Matrix

Command Sub-command Meta-role
login All
create domain Registrar
update domain Proxy
add billing contact Proxy
remove billing contact Proxy
add admin contact Proxy
remove admin contact Proxy
change registrant Proxy
add name server Name Server Administrator
remove name server Name Server Administrator
add DSRECORDS Name Server Administrator
remove DSRECORDS Name Server Administrator
set AuthInfo for change of name servers Name Server Administrator
unset AuthInfo change of name servers Name Server Administrator
set AuthInfo for transfer Proxy
unset AuthInfo for transfer Proxy
renew domain Payer
delete domain Proxy
restore domain Proxy
info domain All
check domain All
transfer domain Proxy
withdraw Proxy
create contact All
update contact Proxy
info contact All
check contact All
create host Name Server Administrator
update host Name Server Administrator
delete host Name Server Administrator
info host All
check host All
poll All
balance Payer

Compatibility Matrix

This is a high level overview of the EPP commands offered by the Punktum dk EPP service, please see the specific commands for details.

The version numbers used in the matrix are major numbers only, e.g. 1 for 1.X.X.

EPP Command Available since version Exceptions and notes
Log in 1 Only password authentication is supported
Log out 1
Create domain 1 Asynchronous *1
Check Domain 1
Info Domain 1 / 3 Billing contact not disclosed. Proxy contact not disclosed since version 3
Update Domain 2 Asynchronous *2
Renew Domain 2
Transfer Domain 4
Withdraw 4
Delete Domain 4
Restore Domain 4
Create Contact 1 Supplying handle/user-id is not supported
Check Contact 1 / 3 Only registrants disclosed, other contacts requires relation to authenticated user
Info Contact 1 / 3 Only registrants disclosed, other contacts requires relation to authenticated user
Update Contact 2 Asynchronous *3
Transfer Contact N/A Contact objects cannot be transferred only domain names. Contact objects are cloned upon transfer
Delete Contact N/A Deletion of contacts is an automated process
Create Host 2 Asynchronous *4
Check Host 1
Info Host 1
Update Host 2 Asynchronous *5
Delete Host 2
Poll 1
Balance 4
  • *1 Requires order confirmation by the registrant. VID product not supported, PO numbers not supported
  • *2 Change of name server is asynchronous, requires approval by the registrant
  • *3 Updating email is asynchronous and is regarded as non-atomic due to the email validation process
  • *4 Requires accept of the registrant of the domain name if the domain is under the .dk TLD and requires that the requesting user accepts the responsibility as name server administrator
  • *5 Requires that the requested administrator accepts the responsibility as name server administrator

About

Public specification for the Punktum dk EPP service

Topics

registry service rfc specification epp dk-hostmaster dk-registry epp-protocol epp-service

Resources

Readme

License

MIT license
Activity
Custom properties

Stars

13 stars

Watchers

9 watching

Forks

10 forks
Report repository

Releases 37

4.4 Latest
Dec 6, 2021
+ 36 releases

Contributors 7