Re-delegating (transferring) an AC.ZA domain

No transfers in AC.ZA

In DNS terminology, the term “transfer” usually refers to moving a domain from one domain name registrar to another. Most commercial or unrestricted domains (such as co.za, org.za) support multiple registrars, and these registrars interact with an underlying registry operator on your behalf. These registrars or their resellers typically also offer DNS hosting services . They may also offer web and/or email hosting services and it is common for these services to be bundled together into a single package. Thus organisations often buy their domain, DNS hosting, website hosting, and email all from one place and do not appreciate the different hats their service provider wears.

As with many moderated domains, AC.ZA operates under a different model. The AC.ZA registry operator is also the sole registrar and does not provide DNS hosting services. It is not possible to transfer an AC.ZA domain to another registrar, and the registry does not support common transfer protocols such as EPP. There are no authorisation codes, domain transfer locking, or anything related to transfers between registrars.

However, it is possible to change the DNS hosting provider. This is what people usually mean when they ask to “transfer” an AC.ZA domain to another provider.

Changing DNS hosting providers (re-delegation)

The DNS hosting provider operates the nameservers that are required to make a domain function. They may also provide a web-based or other control panel allowing individual DNS records to be created, updated or deleted. Many commercial registrars and DNS resellers offer DNS hosting as a separate package (often referred to as “own domain” or “custom domain” hosting). It is usually possible to host an AC.ZA domain with one of these providers by means of re-delegation. That changes the records within AC.ZA tell the Internet who hosts a particular domain .

We sometimes see people make silly mistakes when requesting re-delegation that result in their website or email temporarily stopping working. For this reason, we’ve documented the safest procedure for changing the delegation below.

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 uninterupted while the transition occurs and is especially important if you use e.g. 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 to reflect the correct nameservers for the new hosting provider. This will cause the new hosting provider’s nameservers to start answering some requests, which is why it is important that both old and new are in sync. It also shortens the time both sets of nameservers need to concurrently operate.
  3. Get the domain’s technical contact (as recorded in WHOIS to email a request to TENET asking that the domain be re-delegated from the old DNS hosting provider to the new. The request will need to provide the full domain name as well as the full names (FQDN) and IP addresses of the new hosting provider’s nameservers, together with any relevant DNSSEC changes. Note that this 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.
  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 the DNS changes to propagate (the exact timing depends on your TTLs and may be longer if the NS records don’t match).
  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 artificial limits on what DNS records may be created. For instance, they may require that only their own mail servers be listed in MX records. It is important that to understand the implications of these limitations before commencing re-delegation. There’s no “undo” button; DNS changes take time, and reverting a change takes as long as making it in the first place.