Diagnosing a .sg domain DNS failure after a registrar migration
Diagnosing a .sg domain DNS failure after a registrar migration
The domain stopped resolving on a Tuesday. Not dramatically — no error page, no browser warning. Just a slow, patient refusal: the site loaded halfway, then stalled, then returned nothing. The kind of failure that looks like a network problem until you check three different resolvers and get the same result each time.
A .sg domain had been transferred from one registrar to another four days earlier. The transfer itself had completed. The registry confirmed it. The new registrar confirmed it. Both could see the domain sitting in its new home. But the DNS records — the A record, the MX record, the whole set — had not followed. They had simply stopped being served.
The first instinct is to assume the new registrar handles DNS automatically. Most do. But the middle of a migration is exactly the kind of moment where assumptions become expensive. The DNS zone had been cut over, but the glue records — the NS records pointing to the namerservers — had not updated at the registry level. The domain was parked on empty land.
The whois showed old namerservers
Before touching anything else, check whether the domain actually points to the right namerservers at the registry. This is not the same as checking what your registrar says. The registrar can show any namerservers it wants in its control panel. What matters is what the .sg registry — the Singapore Network Information Centre (SGNIC) — has recorded.
A whois lookup against the registry directly (not a cached whois service) reveals the delegation. The relevant line reads something like:
Name Servers: ns1.old-registrar.com
ns2.old-registrar.com
If the namerservers still point to the old registrar, DNS will not resolve at the new one, regardless of what the new registrar’s control panel displays. In this case, the whois showed exactly that — the old namerservers, still live, still authoritative, but no longer carrying the zone because the old registrar had deactivated it upon transfer.
This is the trap. The old registrar removes the zone because the domain is no longer theirs to manage. The new registrar assumes the zone is live because they imported the records. Neither side reconciles the NS delegation at the registry. The domain enters a state where everyone agrees it has moved, but no one is actually serving DNS for it.
The draft form that sat untouched
Two places hold NS records for a domain. The first is at the registry — this tells the internet which servers to ask. The second is within the zone itself — this confirms the delegation. Both must match. If only one changes, resolution breaks.
During a transfer, some registrars automatically update the registry NS records to their own namerservers. Others leave whatever was there, assuming the domain owner will handle it. Still others update the registry but forget to include the corresponding NS records inside the zone they set up, which causes a different kind of failure: the registrar tells the internet to ask Server A, but Server A has no zone file saying it’s authoritative for the domain.
In this case, the new registrar had imported the zone records — A, MX, CNAME, TXT — but had not created a zone that included proper NS records. The registry still pointed to the old servers.
The fix requires access to the new registrar’s ability to update the registry NS records. Not all registrars expose this directly. Some handle it as part of the transfer process and do not offer a manual override. Others surface it in an advanced DNS settings panel, sometimes under a label like “Nameserver Management” or “Delegation.”
The new registrar’s support interface had a section labeled “Change Auth Nameservers.” Inside, a simple form asked for two namerserver hostnames. The old registrar’s namerservers were entered incorrectly here during a previous configuration attempt — the first attempt had used the old servers’ IP addresses instead of their hostnames, which the registry rejected. The second attempt used the correct hostnames but was never submitted. It sat as a draft, visible only inside the control panel, not pushed to SGNIC.
The third attempt required entering the new registrar’s namerservers exactly as they appear in the new zone. A common mistake is to enter a vanity namerserver — ns1.yourdomain.sg — without first registering that vanity server with the registry. The .sg registry requires namerservers that are not registered as hosts to be accompanied by glue records. Without glue, the delegation fails silently. The namerserver field shows an update. The registry does nothing with it.
Raw zone view revealed the old servers
Once the registry delegation points to the new namerservers, the zone itself must confirm it. The zone’s NS records should list the same servers the registry points to. If they differ, some resolvers follow the delegation while others follow the zone, producing intermittent resolution failures that are nearly impossible to reproduce on demand.
The new registrar’s DNS editor included a hidden set of NS records at the top of the zone — not editable in the visual editor, but visible in the raw zone view. These showed the old registrar’s servers. The registrar’s import process had copied the A records but had not replaced the zone-level NS records. The resolution was to delete the old NS records from the raw zone and add the new ones, then apply the change.
The registry update takes effect within minutes for the .sg namespace, though TTL values on the old NS records can cause caching delays of up to 48 hours. The zone-level change propagates immediately for anyone querying the new servers directly.
Three networks, one result
After both changes are live, the domain should resolve from the new servers. But local caches — your own computer’s resolver, your ISP’s DNS cache, public resolvers like Google or Cloudflare — may still hold the old negative cache, the record that the domain did not exist at the old servers. Clearing these caches manually speeds up the process.
A quick test from three different networks (home broadband, a mobile hotspot, and a VPS in a different country) confirmed the domain was resolving. The A record returned the correct IP. The MX record returned the correct mail server. The NS lookup returned the correct servers from both the registry and the zone.
The migration had taken four days. The actual fix took twenty minutes, spread across three support interactions and a lot of waiting for whois updates that were already complete but appeared stale due to local caching.
What to check before initiating any .sg domain transfer
Three things should be confirmed before the transfer request is submitted:
- The domain’s current namerservers at the registry — run a whois against SGNIC directly, not a third-party lookup tool
- Whether the destination registrar updates registry NS records automatically during transfer, or whether manual delegation is required afterward
- Whether the destination registrar allows editing zone-level NS records, or only A, MX, and CNAME records
The third point is the one most commonly missed. A registrar that does not expose zone-level NS records cannot properly host the domain unless it handles delegation changes automatically. If neither condition is met, the domain ends up in the same limbo: transferred, paid for, visible in the control panel, and completely unresolvable.
A nameserver change at the registry does not require the domain to be transferred first. It can be done while the domain remains at the old registrar, and the zone can be hosted anywhere. The migration becomes simpler if the delegation is updated to the new servers before the transfer, so that when the domain arrives, the new registrar’s servers are already authoritative and the zone records propagate without interruption.
The domain took another two days to show up reliably in all locations. Not because anything was broken — the delegation and zone were correct by Wednesday afternoon — but because TTL values on the old negative cache had been set to 86400 seconds, and some resolvers simply refused to re-query sooner. Waiting was the only remaining step. The site loaded fine from Singapore within an hour. From Europe, it took until Friday morning.
📷 Photos: KATRIN BOLOVTSOVA (Pexels), Ann H (Pexels)
