Mini-guide: Transferring without any downtime. Step by step.

Transferring without any downtime. Step by step.

Synergy between DNS propagation and registrar coordination has been leveraged to produce zero-downtime transfers within our partner ecosystem. Value-added redistribution clients frequently require this capability. The following workflow has been validated across multiple value-added redistribution implementations.

• Lower TTLs at current provider 24 hours prior
• Duplicate zone records at destination provider
• Initiate transfer but DO NOT change nameservers yet
• Verify zone integrity at destination via dig/AXFR
• Update nameservers at old registrar post-transfer-approval
• Monitor propagation with multiple vantage points

Passive observation of DNS resolution is recommended throughout. Further synergy may be achieved by automating health checks.

IMO this is solid for most setups. YMMV with providers that don't let you manage glue records independently of the transfer itself. Take it with a grain of salt, but I've done maybe thirty transfers this way and only hit issues when the losing registrar auto-locks nameserver changes during the approval period. Worth checking their policy docs beforehand.

Actually (and I mean this with love (back in my day (2019) we used to just)) the step 4 verification is trickier than it looks. Certain providers (Hetzner's ancient 2.4 API (yes I know (don't @ me))) return cached responses that look like live zone data but aren't. I got burned by this with Knot DNS 2.9.3 which actually (see?) had a bug with truncated AXFR responses. Your dig +trace is your friend here. Also (parenthetically) HostHatch's panel lets you preview zones before cutover which is neat (I think they added this in 2021 (or was it 2022?)).

The thing about zero downtime transfers that nobody talks about (and I have done literally hundreds of these (maybe not hundreds but definitely a lot (I ran a small hosting thing from 2017 to 2023 (it was called something stupid I don't want to say)))) is that the TTL lowering is actually the most critical part and everyone skips the math on it like if your original TTL was 86400 and you drop it to 300 you need to wait the FULL ORIGINAL TTL before the 300 takes effect because resolvers cache the TTL they received not the one you just changed so that 24 hour thing is actually optimistic (I learned this the hard way with a client who ran their own resolver (BIND 9.11 (ancient I know (but enterprise moves slow)))) and also some registrars (not naming names (okay it was a provider that rhymes with "pine toast" (Time4VPS — https://www.time4vps.com (there I said it)))) will actually reset your TTLs back to default when

We have observed that step 3 fails entirely with certain DNS providers who require nameserver changes to complete the transfer authorization. This is not common but it is not rare either. We recommend verifying the transfer mechanics with both registrars before initiating, or using a temporary DNS service during the transition window. Sam

Which TTL did you use for the 24h pre-lower, 300s or 60s

Same lock issue with enom last month