Migrating an existing domain to CNX DNS

Moving a domain that's already live somewhere else onto CNX doesn't require any downtime. CNX's part of the setup — provisioning your zone repository and confirming the platform is ready — happens before you start. From there, you control the timeline entirely: build and validate the zone at your own pace, and only the final cutover step is time-sensitive.

Prerequisites

Commands below assume a Linux or macOS workstation with git, dig, and named-checkzone available.

macOS — dig ships with the OS; git usually comes with the Xcode Command Line Tools (xcode-select --install if not). named-checkzone needs BIND:

brew install bind

Debian/Ubuntu — none of the three ship by default:

sudo apt install git dnsutils bind9utils

Package names for the BIND utilities have shifted across releases (dnsutils → bind9-dnsutils, bind9utils → bind9-utils on newer releases) — confirm against what's actually available on your system.

Pull the existing zone

Get your current provider to allow a zone transfer (AXFR) out to your workstation — this is a setting on the current provider's side, not CNX's — then pull it:

dig axfr example.com @<current-provider-ns> > example.com.axfr

Validate and canonicalize it:

named-checkzone -D example.com example.com.axfr > example.com.formatted

This checks syntax and re-emits the zone in canonical form. It doesn't touch the SOA/NS header — that's still the old provider's, and needs replacing next.

Replace the SOA/NS header

Edit the top of the file, replacing the pulled SOA/NS block with CNX's. The serial starts at 1; CNX owns it from here. Use in-bailiwick nameserver names if you want (see Using your own nameserver names), or CNX's shared ns01.cnx.net.kh. / ns02.cnx.net.kh.:

@ IN SOA ns01.cnx.net.kh. hostmaster.example.com. (
    1          ; serial — fixed, not customer-managed
    3600 900 1209600 300 )

    IN NS ns01.cnx.net.kh.
    IN NS ns02.cnx.net.kh.

Everything after the header — the actual A/CNAME/MX/TXT records pulled from the old provider — stays as-is.

Commit it

Clone the zones repository, using the exact URL CNX gave you during onboarding (it follows the shape shown in Getting started):

git clone git@git.cnx.net.kh:customers/example-org/dns/zones.git
cd zones
git switch -c add-example-com-initial-zone
mkdir example.com
mv ../example.com.formatted example.com/zone.conf
git add example.com/zone.conf
git commit -m "add example.com initial zone, pulled from previous provider"
git push origin add-example-com-initial-zone

Open the merge request as described in Managing zone changes.

Keeping records routed through a CDN or WAF

If some hostnames need to keep resolving to a downstream CDN or WAF you don't control — proxying and security services generally only ever give you a CNAME target, never a fixed IP — that's exactly what Setting up aliases.yml solves. Many CDNs document their own CNAME target for this purpose; Cloudflare's Partial (CNAME) Setup, for example, uses {hostname}.cdn.cloudflare.net. Put that target in aliases.yml instead of zone.conf, for the zone apex or any other name that needs it — see CNAME flattening for why this is necessary at all.

Cutover

Once the zone is fully built and shaped on CNX — including any CDN-routed records — you can query it directly against CNX's nameservers to verify before anything is public. Cutover is switching your domain's published delegation at the registrar to CNX's nameservers; that's the one step that changes what's live.

If you're using in-bailiwick nameserver names, register their glue records at your registrar alongside the delegation change — see Using your own nameserver names.

Once the zone deploys, its DNSSEC key is generated automatically and its first DS record will be waiting in the reports repository (where your subscription includes it) — see Publishing and updating DS records.

Verification

CNX validates the DNS layer it operates directly — authoritative responses, record correctness, delegation, and DNSSEC where applicable. End-to-end validation of anything downstream — a CDN or WAF's own behavior, connectivity to your origin infrastructure — is your own testing responsibility, together with whatever other providers are involved.

Rollback

Revert your domain's published delegation back to the old provider's nameservers, provided its configuration there wasn't decommissioned during the changeover. Timing is bound by your parent zone's own delegation TTL — confirm it with dig at the time you execute the change.