Why transferring domain to CF Registrar requires changing NS first?

I’ve got a similar question to the one here:

That and in some other questions, many people are saying that it isn’t allowed to use a custom NS provider for a Cloudflare domain. That makes sense to me, but the following doesn’t make sense (example):

  1. I have example.com at registrar.com with NS records pointing to ns[1|2].ns.com
  2. I want to move example.com to cloudflare registrar
  3. I cancel the contract with registrar.com and get a domain transfer auth code
  4. cloudflare (as I understand it) waits for me to change NS records of registrar.com to point to cloudflare’s (instead of .ns.com)

My question:
Why is Point 4 needed when cloudflare is going to take over the domain anyway?

What I expected:
Cloudflare would transfer the domain and submit changes to the domain registry to point NS to itself(cloudflare).
As far as I remember, this is how I did it in the past (with other registrars).

Why it matters:
At the moment I have two manual steps: changing the NS records of the old provider and transfer the domain. With the other (hypothetical) approach, I would just need to transfer the domain.

In terms of risk, both cases risk downtime if the rest of the DNS records aren’t set correctly in cloudflare, however theoretically there’s still a higher risk that someone tries taking over the domain, (since I started the domain transfer without waiting for the dns update).
So at best, it would make sense to show a warning somewhere (e.g. in domain transfer) not to cancel the domain before the DNS update finishes.

Thoughts?

Because in order to transfer the domain, it already has to be active on Cloudflare, which means it already needs to have the Cloudflare nameservers before you even transfer.

I am not entirely sure what you mean here. You should not start any transfer before the domain is not fully active on Cloudflare. At that point, there is no propagation or hijacking issue as you simply initiate the transfer for a domain which is DNS-wise already fully controlled by Cloudflare.

One typically does not cancel a domain in the first place. You simply do not renew it with your current registrar. Should your registrar actually offer such an option (which is effectively a deletion), then that would be an issue with your scenario as well, as the user would get the authorisation code, delete the domain at the current registrar, and attempt a transfer (with said code) at Cloudflare for an already deleted domain.

This would be a general issue (and people should not delete their domains) and not related to how the exact transfer workflow at Cloudflare was designed.

Because in order to transfer the domain, it already has to be active on Cloudflare, which means it already needs to have the Cloudflare nameservers before you even transfer.

As far as I am aware, there is no technical why. Whichever registrar becomes responsible for the domain is free to also set the the primary NS server. Think of it like this: once the transfer is complete, the account (and primary NS server settings) on the old registrar will/can be gone.

You should not start any transfer before the domain is not fully active on Cloudflare.

Right… in my opinion that part wasn’t sufficiently clear on the CF dashboard. After seeing the empty “Domain Transfers” table I didn’t think it would still be waiting on the DNS update (in the beginning I didn’t even change the NS records, thinking that it would be useless when I’m actually going to transfer it).

One typically does not cancel a domain in the first place.

Apologies, I meant “transfer a domain” - my registrar does have those two options separate options.
But imagine a different scenario on this point - the registrar (and/or through their UI) might have decided to refuse an NS record update after a domain was scheduled for transfer.

Technically no, it was simply a product decision to base the registrar service on Cloudflare’s core service.

But you wouldn’t be able to initiate a transfer if the nameservers are not already in place.

In doing so, Cloudflare ensures users have correct nameservers when the domain eventually transfers. Imagine you transfer a domain which is not configured for Cloudflare and Cloudflare forces new nameservers upon the transfer. The user would have no way to guarantee all DNS entries are correct.

1 Like

I meant from the “other” registrar’s point of view (the “unlock domain for transfer” stage). To be fair, typically they offer some sort of reverse process (“cancel transfer” or “lock domain for transfer”).
It’s not big problem per se, the registrar needs to be a pretty crappy one to force domain transfers as a one-way process.

The approach I would have expected it to take:

  • the user starts the domain transfer flow from cloudflare
  • show warning/info that a domain transfer entails switching primary NS servers to cloudflare’s
  • cloudflare checks the provided domain’s dns records and…
    • if there is already a cloudflare “website” with dns entries defined, then nothing to do (or maybe just some verification)
    • if not, copy and import the current dns entries into the existing cloudflare “website” (or create a new one)
  • cloudflare flow asks the user to start the transfer from their current registrar
  • user enters the provided auth code
  • cloudflare transfers domain and overrides primary NS records

But anyway, I was just curious (and a bit confused) - not a big deal.

Unlocking is not a transfer, a registrar won’t impose any nameserver restrictions here.

What you described is essentially what happens, with the difference, that these steps are implicitly performed by configuring the domain beforehand.

There definitely could be also other ways to handle that, but I would still say the way Cloudflare implemented it is pretty straightforward, especially considering it is not a primary service for Cloudflare but rather an add-on.

Sure, no worries. Happy New Year.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.