In January 2023, #Cloudflare replaced #Verisign in providing #DNS #registry services for the .gov #TLD. Besides the registry, they also run the authoritative #nameservers.

Verisign ran it for 12 years, and cost the #US #government apparently just half as much as Cloudflare charges ($7.2M).

Verisign loses prestive .gov contract to Cloudflare

Verisign loses prestige .gov contract to Cloudflare - Domain Incite

Cloudflare is to take over registry services for the US government's .gov domain, ending Verisign's 12-year run. It seems .gov manager CISA, the Cybersecurity and Infrastructure Security Agency, opened the contract up for bidding last August and awarded it to Cloudflare in mid-December. The deal is worth $7.2 million, Cloudflare said in a press release

Domain Incite - Domain Name Industry News, Analysis & Opinion

I am just wondering, and this is a question to the #infosec community:

Can't you migrate a #TLD from one server to another including #DNSSEC by first testing your setup with a #canary zone? #Cloudflare speaks about challenges in having RSA/SHA256 on #Verisign's end, but ECDSA P-256 on their end.

I am just thinking, can't you kick this off by constructing a canary zone with similar parameters and test the migration & key-roll-over prior to touching any relevant zones?

Alternatively, sample the zone into chunks and migrate chunk by chunk?

Just a few thoughts on how to reduce risk of #DNSSEC during the migration from zones.

@resingm The whole zone is one unit, the delegation of the whole zone changes and the signing of the whole zone changes.

I suppose the fundamental issue here is that:
* Cloudflare has their own proprietary setup that only supports ECDSA P-256
* Verisign uses RSA/SHA256

Now, of course you can (should) do trial runs with test zone(s), but you can't really migrate only parts of the real zone.

Could either party adapt? Surely if they really wanted to. Idk if Verisign has a reason to, anymore?

@hlindqvist - It was a matter from 2023. It was resolved perfectly fine, Cloudflare claims no disruptions due to the migration.

Of course, I don't know the operational impact for it.

@resingm Oh right, I missed the context of when the change was happening.
It would be interesting to see if the approach that was eventually chosen was elaborated on somewhere.
@hlindqvist - Yes it was, it is in one of the links I posted earlier. The DNS-OARC link. Hope that helps!
@resingm "Can't you migrate a #TLD from one server to another including #DNSSEC by first testing your setup with a #canary zone? " Totally. Any good DNS testing tool (ex: DNSViz) allows you to test by providing DS content also (which won't be yet published by parent, as current one points to current zone, not new one), and that way you can double check that all DNSSEC operations are ok. Various DNS software allow to specify trust anchors too. Then you can run linters (ex: are NSEC chains ok?)
@resingm Also moving a signed zone is similar to maintaining a signed zone with two separate providers, and as such is documented in details in RFC8901 "Multi-Signer DNSSEC Models" document.
@pmevzek - IIRC, this was also in Cloudflares slides at DNS OARC