Skip to content

Commit ed2ed7d

Browse files
committed
Started to add information on all the limitations of the current sandbox environment
1 parent 43d2245 commit ed2ed7d

File tree

1 file changed

+116
-2
lines changed

1 file changed

+116
-2
lines changed

README.md

Lines changed: 116 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,11 @@
1-
![DK Hostmaster Logo](https://www.dk-hostmaster.dk/sites/default/files/dk-logo_0.png)
1+
![DK Hostmaster Logo][DKHMLOGO]
22

33
# DK Hostmaster Sandbox Environment Specification
44

55
![Markdownlint Action](https://github.com/DK-Hostmaster/sandbox-environment-specification/workflows/Markdownlint%20Action/badge.svg)
66
![Spellcheck Action](https://github.com/DK-Hostmaster/sandbox-environment-specification/workflows/Spellcheck%20Action/badge.svg)
77

8-
2019-07-30 Revision 2.2
8+
2021-05-07 Revision 2.3
99

1010
## Table of Contents
1111

@@ -27,6 +27,12 @@
2727
- [Additional Facilities](#additional-facilities)
2828
- [Domain Application Processing](#domain-application-processing)
2929
- [Implementation Requirements](#implementation-requirements)
30+
- [Sandbox Limitations](#sandbox-limitations)
31+
- [Self-service Portal](self-service-portal)
32+
- [Domain Creation and Order Confirmation](domain-creation-and-order-confirmation)
33+
- [Privilege Grants](privilege-grants)
34+
- [Role Acceptance For Domain Applications](#role-acceptance-for-domain-applications)
35+
- [Host and Role Acceptance For Name Server Applications](#host-and-role-acceptance-for-name-applications)
3036

3137
<!-- /MarkdownTOC -->
3238

@@ -56,6 +62,10 @@ This document is copyright by DK Hostmaster A/S and is licensed under the MIT Li
5662
<a id="document-history"></a>
5763
### Document History
5864

65+
2.3 2021-05-07
66+
67+
- Added new section on sandbox limitations
68+
5969
2.2 2019-07-30
6070

6171
- Added more test data
@@ -155,3 +165,107 @@ Please see the specific service specification for details:
155165
- For details on the service version etc. please see [the EPP Service Wiki](https://github.com/DK-Hostmaster/epp-service-specification/wiki)
156166
- [DK Hostmaster RP Service Specification](https://github.com/DK-Hostmaster/rp-service-specification)
157167
- For details on the service version etc. please see [the RP Service Wiki](https://github.com/DK-Hostmaster/rp-service-specification/wiki)
168+
169+
<a id="sandbox-limitations"></a>
170+
## Sandbox Limitations
171+
172+
<a id="self-service-portal"></a>
173+
### Self-service Portal
174+
175+
As listed under the available services, a self-service portal aimed at end-users, meaning non-registrars is not available.
176+
177+
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.
178+
179+
<a id="domain-creation-and-order-confirmation"></a>
180+
### Domain Creation and Order Confirmation
181+
182+
As described in the ["Implementation guide for registration of .dk"][IMPLGUIDE] there are two methods for registration of domain names.
183+
184+
1. Method 1: Requires that the accept of terms and conditions is done at the registrar and this is communicated via the application
185+
1. Method 2: Requires that the accept of terms and conditions is done at the registry (with DK Hostmaster)
186+
187+
Method 2 can at this time not be simulated, as described in the section on the self-service portal.
188+
189+
The recommended way to a bypass this is by using method 1, eventhough this might not match you final implementation.
190+
191+
The bypass can be accomplished by adding a time stamp to the application, whether it is via: EPP or the registrar portal (RP)
192+
193+
Please see the below references for details:
194+
195+
- [DK Hostmaster EPP Service Specification: create domain](https://github.com/DK-Hostmaster/epp-service-specification#create-domain)
196+
- [DK Hostmaster RP Service Specification: Domain Application](https://github.com/DK-Hostmaster/rp-service-specification#domain-application)
197+
198+
<a id="privilege-grants"></a>
199+
### Privilege Grants
200+
201+
When operations are being completed in the sandbox services, privileges might change and privileges are granted and revoked based on business rules.
202+
203+
The privileges and business rules implemented in the sandbox environment are unchanged from the production environment and hence this can be quite strict.
204+
205+
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.
206+
207+
When an application is approved and a domain is created, it requires an acknowledgement from our finance syste. 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.
208+
209+
<a id="sandbox-limitations"></a>
210+
### Role Acceptance For Domain Applications
211+
212+
When an application is processed and the contacts assigned to the roles of:
213+
214+
- Proxy/admin
215+
- Billing
216+
217+
Are pointing to user entities:
218+
219+
- not equal to the registrant
220+
- not equal to the applicant (registrar)
221+
- not a member of the registrar account group
222+
223+
An accept of the role is required.
224+
225+
In production this is accomplished using the self-service portal.
226+
227+
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.
228+
229+
Currently the acceptance is not simulated either.
230+
231+
The recommendation is to point to users associated with the registrar account group, so the collection is not required.
232+
233+
For details on registrar account groups, please see - [DK Hostmaster RP Service Specification: registrar account group](https://github.com/DK-Hostmaster/rp-service-specification#registrar-account-group)
234+
235+
<a id="sandbox-limitations"></a>
236+
### Host and Role Acceptance For Name Server Applications
237+
238+
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.
239+
240+
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.
241+
242+
This approval has to be accomplished in our self-service platform. So this is currently not possible.
243+
244+
For domain names under registrar managment, this approval is not necessary.
245+
246+
To bypass this step, it is recommended to create name servers for domain names under registrar management and in own portfolio.
247+
248+
See additional references:
249+
250+
- [DK Hostmaster EPP Service Specification: create host](https://github.com/DK-Hostmaster/epp-service-specification#create-domain)
251+
- [DK Hostmaster RP Service Specification: Name Server Application](https://github.com/DK-Hostmaster/rp-service-specification#name-server-application)
252+
253+
Next up is the evaluation of the designated name server administrator (NSA).
254+
255+
1. If the designated user is the same as the requestor, approval of the role should not required (it is implicit)
256+
1. If the requester and the designated user is in the same registrar account group the same rule apply
257+
1. 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
258+
- 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
259+
- 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
260+
261+
To bypass this step, it is recommended to appoint name server adminstrators in own registrar account group.
262+
263+
For details on registrar account groups, please see - [DK Hostmaster RP Service Specification: registrar account group](https://github.com/DK-Hostmaster/rp-service-specification#registrar-account-group)
264+
265+
See the same additional references for details on name server/host creation:
266+
267+
- [DK Hostmaster EPP Service Specification: create host](https://github.com/DK-Hostmaster/epp-service-specification#create-domain)
268+
- [DK Hostmaster RP Service Specification: Name Server Application](https://github.com/DK-Hostmaster/rp-service-specification#name-server-application)
269+
270+
[DKHMLOGO]: https://www.dk-hostmaster.dk/sites/default/files/dk-logo_0.png
271+
[IMPLGUIDE]: https://www.dk-hostmaster.dk/en/implementation-guide-registration-dk

0 commit comments

Comments
 (0)