Transferring DNS to CF: Not a great experience

Posting this feedback here since it has a chance of helping improve things in the future:

Transferring my domain over was kind of obnoxious.

Firstly, the auto-import of records didn’t pick up anything other than domain.tld and www.domain.tld. That’s no big deal, but I can’t specify other entries and ask for them to be auto-imported. I have to either manually type them in or generate a zone file with dig and import that.

Secondly, the procedures for transferring a DNSSEC-protected domain are broken. Right now they go like this:

  1. Disable DNSSEC on the original provider. (!!!)
  2. Wait for the DS record to disappear.
  3. Change NS records.
  4. Enable DNSSEC on the new system.

This is obnoxious, honestly. Here’s how it should go:

  1. Add DS record for new provider.
  2. Change NS records.
  3. Wait for NS TTL.
  4. Remove old DS record.

You can’t do this, because “DNSSEC cannot be enabled until the zone is active (Code: 1008)”. This is a strange restriction, kind of like the “no subdomains” restriction.

I get that I’m not paying for anything, so I don’t really have much space to complain, but it is a poor experience. Please consider fixing it.

Oh, and also disabling DNSSEC can take days, delaying the ability for me to use the service. So much for trying out workers today…

FWIW…

Between those two steps, you also have to wait for all of the old records to have expired.

There are more steps than that. And they require the cooperation and coordination of the old and new DNS providers. (Cloudflare doesn’t support it through the dashboard. I don’t know if support can take care of it.)

You often also have the additional complication of an algorithm rollover.

There are lengthy RFCs and Internet drafts about key and algorithm rollovers and managing DNSSEC across multiple DNS services.

1 Like

Can you link me to these RFCs? Based on my understanding, the dual-DS solution should work.

FWIW, here’s a guide that basically says the same thing I said: https://help.dyn.com/transfer-a-dnssec-signed-zone/

The Dyn article also mentions transferring an active ZSK.

(Which is one option, though not the only one.)

The problem is that, if the DNSKEY record set doesn’t include every ZSK, if a resolver gets some signed record set from Service A and the DNSKEY record set from Service B, it would be bogus.

1 Like

Hey @taralx,

Appreciate the feedback. Some improvements to the on-boarding process are in development, though not the option type in a hostname and have us import the result of a DNS lookup. That’s an interesting option I will pass along. I know this is going to sound jerkish, but it is an honest query I promise… is there another DNS transfer system you’ve used which you liked more or was easier to use? I ask because I’ve only used so many… and I’m not above suggesting we borrow from better design paradigms if they exist.

As for the DNSSEC portion, I agree the current system is sub-optimal. As @mnordhoff indicates it’s a non-trivial problem. I have had a couple of larger deals where the current process has been an issue. Often the DNS team will crank out a new feature or fix to smooth over an impediment to a large deal. That we didn’t for DNSSEC / ZSK support indicates to me (at least) that it is a non-trivial issue to address. The team has been actively discussing some of the challenges though and I hope that translates to new functionality (heck of a backlog they maintain, so /when/ is an open question to be sure).

FWIW with a host file edit you can likely test out workers today (and we’re working on workers.dev a domainless way to try out workers in the future). Really do appreciate the feedback, sucking less tomorrow than we do today is always the goal. :smiley:

1 Like

Oh, the DNSKEY thing. Okay, let me think about this…

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