Nameservers: Choosing Between Host, Registrar, or Cloud

The site opens, but every few hours you get "DNS_PROBE_FINISHED_NXDOMAIN" for ten minutes. Or worse: a customer calls from another city saying they can't see the site, while from your own office everything looks fine. These symptoms almost always have one root cause: your nameserver is somewhere it wasn't built for. And the real decision isn't "which option is better"; the decision is which option is right for your traffic pattern and access level.

What exactly does a nameserver control

The nameserver (Authoritative Nameserver) gives the final answer to DNS queries. When someone types your site's address, the resolver starts from the root, reaches the TLD, and finally asks your nameserver "what is the A record for the domain?". The slower or more unstable this loop is, the longer the user waits before even seeing a single byte of your site.

You can delegate this role in three places: the domain registrar's panel, the hosting control panel, or an independent cloud DNS service. The difference between these three shows up in response speed, in record control, and in what happens when your server goes down.

Three options, three different behaviors in a crisis

The table above doesn't make the decision. What makes the decision is this: if your primary server goes offline, what can your nameserver do? The registrar nameserver does nothing. The host nameserver usually returns the same IP until someone manually changes the record. Only the third option can decide on its own.

Why your TTFB goes up and what it has to do with the nameserver

A common mistake is blaming everything on the server. If your site's TTFB is 800 milliseconds, first check with dig how long the nameserver response time is:

dig @1.1.1.1 example.com A +stats
dig +trace example.com

In the output, look at the Query time field. Under 50 milliseconds is normal. If it's hovering around 300 to 600 milliseconds, the problem is before your web server and any PHP optimization is useless. To find out where the slowness is coming from, ServerNet's free tools run DNS and TTFB tests from several geographic points and show the difference.

A point that's rarely mentioned: record TTL. If you've set TTL to 300 seconds and then want to change servers, your migration is inconsistent for up to 5 minutes. If you've set it to 86400, up to a day. Before any migration, reduce TTL to 300, wait a day, migrate, then revert it.

Where people really go wrong

Here's where they go wrong: they put the nameserver on the host and then change hosts, without thinking that the nameserver goes with it. The result is that the site becomes unreachable for everyone, not just those who cached the old IP. The symptom is exactly this: dig from your own server responds, but from outside you get SERVFAIL. If the nameserver is on the host, before any move, transfer the NS records to an independent service.

Second mistake: putting both NS on the same provider. If that provider has a problem, both of your nameservers go down together and you have no redundancy. You need at least two nameservers on two different networks.

Selection criteria for each scenario

Personal site or low-traffic blog

The host nameserver is enough. It's simple, you have one panel, and extra complexity gives you nothing. Just make sure the control panel allows editing MX and TXT records; some cheap panels hide this.

Store or revenue-generating site

Here I'd choose cloud DNS. The reason isn't speed, it's failover capability. If the primary server goes offline, the record moves to the backup server and your customer doesn't notice. The cost is that an extra layer of complexity is added and you have to learn to manage records via API. For a team where only one person understands it, this complexity can itself be a risk.

Service with domestic users

If your users are all in Iran, a foreign cloud nameserver isn't always the best option. Network routing and sanctions can make DNS responses from inside slower than a domestic nameserver. Test here, don't assume. A single dig from two points inside Iran is enough to change the decision.

Migrating nameservers without downtime

1. Fully extract the current records: dig example.com ANY +noall +answer and also dig example.com MX and dig example.com TXT.
2. Create all records in the new service in advance, including email verification and SPF records.
3. Reduce TTL to 300 and wait at least one full cycle.
4. Change the NS records in the registrar panel. This is the only irreversible step, so make sure everything is ready beforehand.
5. Verify with dig +trace from several points that propagation is complete.

If you work with WordPress, after migration you'll likely run into issues like cron not running or old addresses in the database. The guide on migrating WordPress without a plugin covers exactly this stage after the DNS change.

When the nameserver is fine but the site stays slow

If Query time is under 50 milliseconds and the site is still slow, the problem is elsewhere. In WordPress, the internal cron is one of the usual suspects; replace WordPress wp-cron with a real system cron. If the number of plugins has passed 30, do a plugin audit before anything else. And if you're on shared hosting, check whether you have I/O limits or CPU limits.

For WordPress sites with moderate traffic, a Linux host with full control over cron and resources usually costs less than cheap shared hosting, because it frees up your time from repetitive troubleshooting. If you have a WordPress site and want to get going without wrestling with server settings, ServerNet's WordPress hosting takes this layer off your shoulders.

Frequently asked questions

Does changing the nameserver cause site downtime?

If done correctly, no. Downtime happens when you haven't created the records in the new service or haven't reduced TTL before migration. With TTL at 300 seconds, the inconsistency window is at most a few minutes.

How many nameservers are needed?

At least two nameservers, and preferably on two different networks. If both are on the same provider, that provider's failure takes both down together and you don't have real redundancy.

Does cloud DNS speed up the site?

Only a small portion of loading time is related to DNS. If your TTFB is 800 milliseconds and DNS response time is 40 milliseconds, changing the nameserver makes almost no difference. Measure with dig first, then decide.

How do I find out which nameserver I'm currently using?

Run the command dig NS example.com +short. If the output shows the registrar's or host's server names, that's where it is. If you see a cloud service name, you've already migrated.

Before any decision, run dig +trace once and look at the time of each step. The number you see will change your decision more than any comparison.