2021-09-08 Revision 2.9
- Introduction
- The .dk Registry in Brief
- Sandbox Environment in Brief
- Sandbox Environment
- Implementation Requirements
- Sandbox Limitations
This document describes the sandbox environment offered by DK Hostmaster.
The document is targeted at registrars as audience.
This specification describes the consolidated DK Hostmaster Sandbox environment.
Changes to the document are listed Document History and changes to the sandbox environment are described here.
Any future additions and changes to the implementation are not within the scope of this document and will not be discussed or mentioned throughout this document.
This document is owned and maintained by DK Hostmaster A/S and must not be distributed without this information.
This document is copyright by DK Hostmaster A/S and is licensed under the MIT License, please see the separate LICENSE file for details.
2.9 2021-09-08
2.8 2021-09-02
- Added information on WHOIS service
2.7 2021-08-23
- Updated information on simulation of 3rd. party interaction for ID-control
2.6 2021-05-26
- Added more information on the limitations on ID-control
2.5 2021-05-14
- Added two more limitations to the section on sandbox limitations
2.4 2021-05-13
- Added mention of tech-announce and linked to page in mailing list for subscription details
2.3 2021-05-07
- Added new section on sandbox limitations
2.2 2019-07-30
- Added more test data
- Improved description on test data
2.1 2019-07-30
- Added section on test data
2.0 2018-11-29
- DSU Service added to consolidated sandbox environment
1.0 2018-11-28
- Initial revision
DK Hostmaster is the registry for the ccTLD for Denmark (dk). The current model used in Denmark is based on a sole registry, with DK Hostmaster maintaining the central DNS registry.
The consolidated sandbox environment supports several of the services offered by DK Hostmaster and in addition some of the facilities required to support the services.
The sandbox environment is isolated from production and does not support all features and assets of the production environment. The environment is planned to be extended and information on these extensions will be described here as the modifications are scheduled.
Limitations and special circumstances are documented in the specifications for the separate services.
The services and components deployed to the sandbox environment are listed in the Wiki with versions and other relevant information.
Updates are announced via our tech-announce mailing list.
Please see the information page for details on subscribing etc.
DK Hostmaster offers the following services on the sandbox environment:
https://das-sandbox.dk-hostmaster.dk/
https://dsu-sandbox.dk-hostmaster.dk/
epp-sandbox.dk-hostmaster.dkport700
https://rp-sandbox.dk-hostmaster.dk/
whois-sandbox.dk-hostmaster.dkport43
The general test data available in the sandbox environment are currently:
| Domain | Status |
|---|---|
| dk-hostmaster.dk | Active |
| eksempel.dk | Active |
| æøåöäüé.dk | Active |
The different services listed above might specify if the test data are put to special use, specific to the service in question and hence only documented per service in the relevant service specification.
The sandbox environment also holds a back-end service component for domain processing, which processes domain applications.
Please see the specific service specification for details:
- DK Hostmaster DAS Service Specification
- For details on the service version etc. please see the DAS Service Wiki
- DK Hostmaster DSU Service Specification
- For details on the service version etc. please see the DSU Service Wiki
- DK Hostmaster EPP Service Specification
- For details on the service version etc. please see the EPP Service Wiki
- DK Hostmaster RP Service Specification
- For details on the service version etc. please see the RP Service Wiki
- DK Hostmaster WHOIS Service Specification
- For details on the service version etc. please see the WHOIS Service Wiki
As listed under the available services, a self-service portal aimed at end-users, meaning non-registrars is not available.
This mean that processes relying on registrant interaction are not possible, simulation can be implemented where this is possible, please see the list of specific limitations below.
As described in the "Implementation guide for registration of .dk" there are two methods for registration of domain names.
- Method 1: Requires that the accept of terms and conditions is done at the registrar and this is communicated via the application
- Method 2: Requires that the accept of terms and conditions is done at the registry (with DK Hostmaster)
Method 2 can at this time not be simulated, as described in the section on the self-service portal.
The recommended way to a bypass this is by using method 1, even though this might not match you final implementation.
The bypass can be accomplished by adding a time stamp to the application, whether it is via: EPP or the registrar portal (RP)
Please see the below references for details:
- DK Hostmaster EPP Service Specification: create domain
- DK Hostmaster RP Service Specification: Domain Application
When operations are being completed in the sandbox services, privileges might change and privileges are granted and revoked based on business rules.
The privileges and business rules implemented in the sandbox environment are unchanged from the production environment and hence this can be quite strict.
We aim to implement simulated interactions with external components or user entities where possible to simulate a production like flow and to avoid any blocking process steps.
When an application is approved and a domain is created, it requires an acknowledgement from our finance system. A finance system is not available in our sandbox environment so this is simulated. This mean that the initial privileges granted to registrant, registrar etc. are activated.
When an application is processed and the contacts assigned to the roles of:
- Proxy/admin
- Billing
Are pointing to user entities:
- not equal to the registrant
- not equal to the applicant (registrar)
- not a member of the registrar account group
An accept of the role is required.
In production this is accomplished using the self-service portal.
As stated in the section on the self-service portal, a instance of this portal is not available in the sandbox environment, so this accept cannot be collected.
Currently the acceptance is not simulated either.
The recommendation is to point to users associated with the registrar account group, so the collection is not required.
For details on registrar account groups, please see - DK Hostmaster RP Service Specification: registrar account group
When an application for creation of a name server is processed there are a number of possible scenarios depending on the data submitted with the application.
If the hostname of the name server is a subordinate to to a .dk domain name and the domain name is under registrant management the application require the approval of the registrant.
This approval has to be accomplished in our self-service platform. So this is currently not possible.
For domain names under registrar management, this approval is not necessary.
To bypass this step, it is recommended to create name servers for domain names under registrar management and in own portfolio.
See additional references:
- DK Hostmaster EPP Service Specification: create host
- DK Hostmaster RP Service Specification: Name Server Application
Next up is the evaluation of the designated name server administrator (NSA).
- If the designated user is the same as the requestor, approval of the role should not required (it is implicit)
- If the requester and the designated user is in the same registrar account group the same rule apply
- If the designated user is not the same as the requester and they are not related by group, the role has to be accepted by the designed name server administrator
- If the user is not in a registrar group, the user has to accept the role via the self-service portal, which is currently not available in the sandbox environment
- If the user is in another registrar group, this has to be accomplished in the registrar portal. Do note that this is a somewhat constructed scenario, since it would mean that name server administrators are appointed across registrar groups, there is however no reason not to support this, since it comes with the implementation, which handles the above scenario
To bypass this step, it is recommended to appoint name server administrators in own registrar account group.
For details on registrar account groups, please see - DK Hostmaster RP Service Specification: registrar account group
See the same additional references for details on name server/host creation:
- DK Hostmaster EPP Service Specification: create host
- DK Hostmaster RP Service Specification: Name Server Application
The requirement for ID-control cannot currently by bypassed.
We have implemented a sandbox feature, simulating the interaction with 3rd. parties, meaning designated registrants, which have been selected for manual ID-control all pass an ID-control check.
Over all the scenarios can be divided as follows:
- all users requiring ID-control using NemID, are kept in the state requiring this. The criteria is currently users with an address in Denmark
- users not requiring ID-control using NemID, are altered and pass the ID-control check. The criteria is currently users with an address outside Denmark
The capabilities and granularity of testing different use-cases and scenarios is expected to be extended in the future, but this first simulation, makes it it more predictable and makes it easier to test additional operations.
Currently it is possible to change roles on domain names for the roles of billing contact and proxy, required that the initiating user holds the right privileges.
The accept of the role, concluding the process cannot be completed currently.
To bypass this, it is recommended to appoint from own registrar account group.
The sandbox environment is not shielded completely off from the live Internet for DNS and does currently not offer it's own DNS service, which influences some of the operations you can perform in the sandbox environment, even though these do not influence the production environment.
The most prominent example is that an attempt at changing name servers might fail, when the receiving name servers do not answer for the domain name in question.
A work around is to register a domain name on name servers, which do not respond for the domain name live (in production) and then update the domain name to the servers, which respond in production.
Currently name servers listed on a domain name application are not checked at the application processing stage, since by currently policy and process, domain name applications are not guaranteed to be fulfilled, so it is not required by the applicant (registrar) to have these settings in place until it makes sense. Having DNS working however is recommended for a better end-to-end user experience.
To test a name server change, one can turn the scenario around and register a domain name, which is also in production and has active DNS.
The application should point to name servers, which you already have access to (see: Passwords). This is required if you need to generate the AuthInfo token.
The you request the change of name servers to the name servers already responding for the domain name and you can simulate the real operation.
The environment does not support sending out emails, the reason for this was to not confuse sandbox operations with production operations. Proper annotations or embedded warning or the like could open up for this, but for now no emails are sent.
When a user is created it is not possible to obtain the password of the newly created user. Due to the lack of email communication it is not possible to obtain a password using the "forgotten password" feature. This applies to both regular users for domain and name server roles and portal users for the registrar portal.
If need be and you require the password of a given user in the sandbox environment, please contact DK Hostmaster