Migration Guide

Move your DNS zones to hiddenprimary.ch from another provider with zero downtime.

Overview

Migrating to a hidden-primary setup means your current authoritative DNS server becomes the hidden primary, and hiddenprimary.ch serves as the public-facing secondary. The only record you change in the zone itself is the apex NS RRset in step 4. We take the rest of your zone as it is.

Step 1: Prepare Your Primary

Ensure your current DNS server allows zone transfers (AXFR) from our transfer addresses. Two hosts can connect: the transfer node and the standby that takes over when it is unavailable. Allow all four, or the zone stops updating during a failover.

allow-transfer
159.69.29.118 // IPv4
2a01:4f8:1c0c:63c4::118 // IPv6
45.131.252.44 // standby, IPv4
2a11:8b80:1000:1::18 // standby, IPv6

For added security, configure TSIG authentication.

Step 2: Add Zones

Add each zone in the hiddenprimary.ch portal or via the API. Point them at your current server IP. The initial zone transfer happens automatically.

Step 3: Verify Transfers

Check the zone status in the portal dashboard. Each zone should show active with a matching serial number. You can also verify with dig:

terminal
$ dig @ns1.hiddenprimary.ch example.ch SOA +short
ns1.hiddenprimary.ch. admin.example.ch. 2026031801 ...

Step 4: Switch NS Records

Your NS records exist in two separate places, and both have to name us. Change your own zone first, then the delegation at your registrar.

4a. In your zone, on your hidden primary

Replace the NS records at the apex of the zone with ours:

example.ch zone file
example.ch. IN NS ns1.hiddenprimary.ch.
example.ch. IN NS ns2.hiddenprimary.ch.
example.ch. IN NS ns3.hiddenprimary.ch.
example.ch. IN NS ns4.hiddenprimary.ch.

This is the step migrations most often skip, and skipping it is the single most common reason a migration appears not to work. Once a resolver has seen your zone, it prefers the NS records inside the zone over the ones the registry hands out (RFC 2181, section 5.4.1). A zone that still names your old provider keeps directing queries there, however correct the delegation at your registrar is.

We check this for you after every transfer. If your apex NS records name none of our nameservers you get NS_MISSING_OURS, and if they name only some of them you get NS_INCOMPLETE_OURS, which also tells you which are missing. Both are warnings, because multi-provider setups are legitimate — but if you did not intend one, this is what to fix. See the validation guide.

4b. At your registrar

Update the delegation for the domain to the same nameservers. This is a form in your registrar's control panel, not a record in your zone file.

Leave your old NS records in place for 48 hours while DNS caches expire. During this period, both old and new nameservers will answer queries.

Step 5: Enable DNSSEC (Optional)

Once the migration is stable, you can enable DNSSEC signing. Make sure your zone is fully synced before enabling DNSSEC.

Step 6: Remove Old NS

After 48 hours, remove the old nameservers from the delegation at your registrar. Check first that your zone's own apex NS records name only our nameservers — if the old provider is still listed there, removing it at the registrar alone changes nothing for any resolver that has already seen your zone.

Your hidden primary continues to serve as the source of truth — all zone changes are made there and automatically synced to hiddenprimary.ch.

Rollback

If anything goes wrong, put your original nameservers back in both places: the apex NS records in your own zone, and the delegation at your registrar. Reverting only the registrar does not roll the migration back — a resolver that has already seen your zone keeps using the NS records inside it (RFC 2181, section 5.4.1). Your hidden primary still has the authoritative data.

Next Steps