Re-delegating (transferring) an AC.ZA domain

No transfers in AC.ZA

In DNS language, “transfer” usually means moving a domain from one domain name registrar to another.

For most unrestricted domains (for example co.za or org.za), there are multiple registrars that work with a registry on your behalf¹. Those registrars (or their resellers) often also sell DNS hosting , website hosting, and email hosting in one bundle. This is why many organisations treat it as one service, even though it is technically several different services.

As a moderated domain, AC.ZA works differently: the AC.ZA registry operator is effectively the sole registrar, and TENET does not provide DNS hosting for registrants. So, an AC.ZA domain cannot be “transferred” between registrars in the usual industry sense. The AC.ZA registry also does not use registrar transfer features such as EPP auth codes or transfer locks.

You can, however, change your DNS hosting provider. In practice, this is what most people mean when they ask to “transfer” an AC.ZA domain.

Changing DNS hosting providers (re-delegation)

Your DNS hosting provider runs the nameservers that make your domain work. This may be your own IT team, or an external provider (for example an ISP, web host, or specialist DNS host). If you don’t host your own domain, your provider would usually have a control panel or API where DNS records can be created, changed, or removed.

Re-delegation changes who is listed as the authoritative nameserver provider for your domain. In other words, it changes which nameservers AC.ZA points to for your domain .

A well-managed delegation change does not require tight coordination and poses very little risk. You do not need to synchronise our changes with yours at a specific time, and changes can (and should²) be made during office hours. What matters is the order of the steps, not the timing. To reduce downtime risk, follow the procedure below carefully. If you are not the DNS administrator, you can forward this section directly to the team or provider that manages your DNS.

Procedure for re-delegating a domain:

1. Configure the domain at the new hosting provider to exactly match what is at the old hosting provider. There are a number of ways to do this, for example:
   1. Demote the old nameservers to secondaries of the new. This allows DNS updates to continue uninterrupted during the transition and is especially important if you use dynamic DNS or DNSSEC;
   2. Export the domain’s zone file from the old provider and import it into the new provider. Then institute a change freeze until the transition is complete; or
   3. If the domain is small, you can manually copy each DNS record from the old system to the new one. You will need to ensure they remain in sync (i.e. manually update both sides) until the transition is complete.
2. Update the NS (nameserver) records at both the old and new hosting providers so they reflect the correct nameservers for the new hosting provider. This causes the new hosting provider’s nameservers to start answering some requests, which is why it is important that old and new remain in sync. It also shortens the period where both nameserver sets must run in parallel.
3. Ask the domain’s technical contact (as recorded in WHOIS ) to email a request to TENET asking for re-delegation from the old DNS hosting provider to the new one. The request must include the full domain name, plus the full names (FQDN) and IP addresses of the new hosting provider’s nameservers, together with any relevant DNSSEC changes³. This step can only be done once the new provider is fully functional.
4. TENET may perform a limited number of sanity checks, and may query things if the two sets of nameservers appear out-of-sync. However, the onus remains on you to ensure that both sets of nameservers serve correct records⁴. You may find our redelegation check and/or an undelegated domain check tool useful.
5. Once TENET has confirmed that the domain has been re-delegated, verify the change is correctly reflected under the Nameserver entries in WHOIS.
6. Wait at least twenty-six (26) hours for DNS changes to propagate. The exact timing depends on time-to-live (TTL) values and may be longer if NS records do not match. You can shorten this period (and recovery time if mistakes happen) by lowering TTLs before you start this process. With short TTLs, the practical minimum is a little over two hours.
7. Commence decommissioning the old hosting provider.

Unless there is a mechanism for keeping the old and new hosting providers in sync during this process, it is a good idea to initiate a change freeze at the beginning of the process. It can take a couple of days for a re-delegation to completely take effect, and if the two are out-of-sync during this time it can lead to inconsistent behaviour.

Some DNS hosting providers have limits on what DNS records may be created. For example, they may require that only their own mail servers appear in MX records. Make sure you understand these limitations before you start re-delegation. There is no instant “undo” button in DNS; reversing a change takes time, just like making the change.