Do Cloudflare support the new process for .dk domains? (administrator of .dk TLD) has changed procedures and does not allow domain owners (registrant) to change name servers anymore. It now has to be done by name server managers (i.e. Cloudflare) using a AuthInfo token provided by the domain owners.
The new process is described here: New process for changing name server for .dk domain names | DK Hostmaster

Do Cloudflare support this new process?
If yes, what is the procedure with Cloudflare for providing the AuthInfo token?
If no, does that mean that new .dk domains would no longer be supported by Cloudflare?

Can you elaborate on this? The link you posted did not exactly say that registrants can’t change nameservers of their own domains any more.

I’d be surprised if the Danish registry actually imposed such a requirement as I’d find it hard to believe that every single provider worldwide will implement such a rather unique approach of a registry and that would probably lock out .dk domains from lots of services.

DK-Hostmaster has written some more about it here:

We have changed it so that in future it is the registrant or proxy of the .dk domain name who must download a unique code, authorization code, via our self-service. The code must be passed on to the new registrar, which starts the change of name servers.

…If you are not the name server manager for the domain name, the registrant for the domain name must log in to our self-service and issue an authorization by requesting an authorization code, which the registrant passes on to the name server manager who will handle the name server in the future.
Subsequently, the name server manager can log in to the self-service with his name server user ID, enter the domain name and the authorization code and make the change

When I log in to DK-Hostmaster’s self-service it also reflects that I can no longer manually enter the new name servers. I have to issue an authorization token (see image).

Hi, @ReneDK!

Fellow dane here :slightly_smiling_face:

From what I can understand, name servers now have to be specified at your registrar (e.g. Simply) instead of the registry (DK Hostmaster) - not by your name servers (Cloudflare).

Ændring af navneservere
OBS! DK Hostmaster har netop foretaget markante ændringer i deres system, hvorfor der kan være problemer med ovenstående. Du kan kontakte DK Hostmaster for nærmere hjælp til at skifte navneservere. Opdateres… (2021-09-20)

The above paragraph is from Simply’s support article, but I expect the same is true for other .dk registrars. You’ll have to contact DK Hostmaster if you want to change name servers.

That is only if you have a registrar. The entire registrar management system is part of the new update at DK-Hostmaster.

All previously registrered .dk domains and all domains transfered to you doesn’t have a registrar attached.

As I understand the registrar will only be able to change the name server, if they themselves are the name server managers for the specific name server (from my previous linked article)

So you have registered your domain directly through the registry? I’d probably really contact them and clarify what the exact new system is. If they really require what you said earlier, they’ll lock out lots of .dk domains from lots of services.

No. My domain is transfered from another owner, which is done entirely within the registry’s self-service solution.

You can’t by domains directly through the registry (DK-Hostmaster). You have to use a registrar and then verify your identity with the registry.
But previously when you wanted to change to another DNS management system (like Cloudflare) you would log into DK-Hostmaster and change the name server to a name server approved by DK-Hostmaster (Cloudflares name server are approved in most cases).
There is no information attached to a .dk domain regarding what registrar it was bought through.

I have contacted DK-Hostmaster now and looking forward to what their reply is.

Hi fellow danes

I have jsut spoken to DK-hostmaster - Cloudflare (any many others) does not support the new medhod that DK-hostmaster implemented.

I as told that for now we can use the anonymous redelegation interface when redelegating to Cloudflare. It is found here:

1 Like


Did you succed in changing nameservers for your .dk domain using the anonymous redelegation interface? Also can you only specificy a primary nameserver and not a secondary?

I contacted DK-hostmaster support and they told me the only way to change nameserver was to use the generated AuthInfo token, which is apparently not supported by Cloudflare?

Yes i redelegated the domain to Cloudflare without any problems using the anonymous redelegation interface. You only have to input the primary ns and the secondary will be added automatically. The redelegation confirmation email was rather delayed but the redelegation worked.

Thank you! The mail was just a bit delayed, but it worked.

So, as the original assumption went, you actually can do this yourself and Cloudflare does not need to do anything?

Not entirely.

Based on the responses from DK-Hostmaster, from people in this thread, it seems that only some people are informed of the NSU URL (that @ogdahl posted) while others are told that the only way to change nameservers is to use the AuthInfo token and then contact Cloudflare.

The original link I posted also states:

The reorganization of the process means that our services NSU (name server change via HTTP) and ID (name server change via e-mail) will be phased out, as the new process is considered more secure.

So for now only some people with .dk domains are able to move to Cloudflare (the ones who know about the NSU url). And at some point no .dk domains will be able to do so unless Cloudflare starts supporting DK-Hostmasters AuthInfo token

Though that would be just a communication issue, as long as everyone can use that approach.

Now, the question is whether the sentence you quoted is accurate and the mentioned approach won’t be possible any more.

IMHO it will be best to really clarify this with the registry and also ask them how they imagine that to actually work as I’d rather doubt that every service provider will adopt their approach and they will essentially bar Danish domains from many services and that might just include Cloudflare.

1 Like

The mail was just a bit delayed, but it worked.

How long did it take? I tried to do an anonymous redelegation last night (9-10 hours ago), and it still did not go through. I plan to contact DK-Hostmaster at 9:00 when their phone support is open.

About an hour or so. Check your spam folder as well. I’m using a hotmail and it ended up in the spam folder.

A quick update on the name server change I made 24 hours ago. I changed the name servers for two .dk domains via NSU and the confirmation email arrived after 10-15 minutues. I confirmed the name server change and the change was confirmed my DK-hostmaster - when logging in to self service i could confirm that DK-hostmaster changed the name servers on their end - so far so good.

BUT - after 24 hours the two domains was still pending name server change on Cloudflare. When checking the domains with the name server change was only propagated to about half of the global name servers. So changing the name servers via NSU seems to have some issues.

I hope that this issue will be resolved fast as of now it’s not possible to redelgate .dk domains to name servers that do not yet support the new auth method - and I think that is i big problem

Which domains are they? Domain propagation can always take several days. If the registry announces them correctly, that is neither a registry nor a Cloudflare issue.

I changed nameservers for my .dk domain ~16 hours ago and can confirm the nameservers have been updated by DK-Hostmaster when checking using their self-service.

Edit: Still pending name server update on Cloudflares end tho.

Edit1: Clicked the check nameservers button on Cloudflare and almost instantly received a confirmation email, that my domain is now active on Cloudflare and it also shows as active on Cloudflares control panel.

1 Like

This was a standard propagation issue in that case.