If your domain is “connected” but the site still does not load, the problem is usually not your hosting account. It is DNS. More specifically, it is almost always nameservers.
Nameservers are the control plane for your domain. They decide where every DNS record comes from: A, AAAA, CNAME, MX, TXT, and anything else you need. If they point to the wrong place, nothing downstream matters. Your web server can be fine and your SSL can be ready, but the world will never ask the right DNS.
This guide stays focused on one job: getting turbohost nameservers set correctly, proving they are actually in effect, and fixing the common failure modes that waste the most time.
What nameservers actually do (and what they do not)
Nameservers do one simple thing: they tell resolvers which DNS provider is authoritative for your domain. When you set nameservers at your registrar, you are not adding a single DNS record. You are delegating the entire zone to another system.
That is why changing nameservers can “erase” your DNS from the perspective of the internet. Your old DNS records might still exist at the old provider, but they are no longer consulted once delegation changes.
This also means you need to decide which model you are using:
If you use nameservers from your host, you typically manage DNS inside the hosting control panel. If you keep nameservers at a DNS provider like your registrar or a separate DNS platform, you manage records there and point A or CNAME records to your hosting.
Neither approach is universally better. Host-managed DNS is faster to set up and reduces moving parts. External DNS can be cleaner if you operate multiple services, need advanced routing, or want strict separation between hosting and DNS.
When to use turbohost nameservers vs. editing records
Use turbohost nameservers when you want the hosting platform to be the source of truth for your DNS. This is the simplest route if you are launching a new site, migrating a small business site, or you want one place to manage web and email records.
Do not switch nameservers if you already have complex DNS you cannot disrupt, like third-party email, subdomain routing for apps, custom SPF/DKIM/DMARC policies, or multiple environments behind different records. In that case, keep your current nameservers and change only the needed records (usually A, AAAA, or CNAME) to point to your hosting.
The trade-off is operational: nameserver changes are an all-or-nothing delegation. Record edits are precise but require you to know exactly what needs to point where.
How to set turbohost nameservers (the registrar side)
Nameservers are set at the domain registrar, not at your host. The UI varies, but the flow is consistent.
First, locate the nameserver values provided by your hosting account. You will typically see two or more nameservers, in the form of ns1.example.tld and ns2.example.tld. You must enter them exactly as provided.
Then, in your registrar:
Go to the domain management page for the domain.
Find a section labeled Nameservers, DNS, or Domain Name Server.
Switch from “Default” or “Registrar nameservers” to “Custom nameservers.”
Enter the provided nameserver hostnames. Save.
If the registrar asks for a “nameserver set,” enter all of them. If the registrar accepts only two, use the first two in the order provided.
Do not add IP addresses in the nameserver fields unless your registrar explicitly supports that and your host instructed you to. Nameservers are almost always set as hostnames.
What to expect after changing nameservers
There are two different timelines people mix up:
Registrar publication: the delegation change has to be published to the TLD registry. This is usually fast, but not instant.
DNS caching: once the delegation changes, resolvers still cache old information for a while.
In practical terms, you can see partial behavior during the transition. One device hits the new DNS, another still sees the old one. One location gets the new site, another gets nothing.
If you are migrating an active site, this is the part where downtime happens if the new DNS zone is not ready. The right sequence is to prepare all required records at the destination nameservers before you switch delegation.
Verify delegation first (before chasing records)
Most DNS troubleshooting fails because people start editing A records without proving the nameserver change took.
You want to confirm: “What nameservers does the internet think my domain uses right now?”
You can do that with command-line tools.
Check current authoritative nameservers
On macOS or Linux:
Use:
`dig NS yourdomain.com`
Look at the NS answers. If they match the turbohost nameservers you set, delegation is active.
On Windows PowerShell:
Use:
`nslookup -type=NS yourdomain.com`
If the output still shows your registrar or previous DNS provider, your nameserver change has not propagated yet, or you saved it incorrectly.
Confirm you are querying the right layer
A common mistake is checking a DNS record and seeing old data because your local resolver cached it.
To bypass local caching, query a public resolver directly, for example:
`dig NS yourdomain.com @1.1.1.1`
If public resolvers show the new nameservers but your local machine does not, you are dealing with caching at your ISP, your router, or your OS.
After delegation: verify the records that matter
Once turbohost nameservers are authoritative, the next failure mode is simple: the DNS zone on the new nameservers does not contain the records you expected.
For a basic website, you typically need either:
An A record for the root domain (yourdomain.com) pointing to an IPv4 address, plus optionally an AAAA record for IPv6.
A CNAME record for www pointing to the root domain or to a host-provided target.
If you are using email, you also need MX records and usually TXT records for SPF and DKIM.
The key operational point: if you switched nameservers, these records must exist on the new authoritative DNS. Records at the old provider no longer apply.
Common problems and fast fixes
You changed nameservers and email broke
That is expected if email was configured at the old DNS provider. Nameserver delegation moved the DNS zone, so MX and TXT records did not come along.
Fix: recreate MX, SPF, DKIM, and DMARC records at the new DNS source. If you cannot do that safely, revert nameservers and use record-level changes instead.
The root works but www does not (or vice versa)
This is usually a missing CNAME for www, or a missing A record for the apex.
Fix: ensure both names resolve to the intended destination. For most setups, www should CNAME to the apex, or both should point to the same target.
You see the old site on some networks
This is caching. Nameserver and record TTL values control how long resolvers keep old answers.
Fix: wait for caches to expire, and verify you are querying authoritative DNS. Avoid making repeated changes every few minutes. Each change resets the waiting game.
You pointed nameservers but the zone is empty
Some hosting platforms only create DNS zones after you add the domain inside the hosting panel.
Fix: confirm the domain is added to the hosting account and that DNS is enabled. Then recheck `dig NS` and `dig A`.
Registrar says “invalid nameserver”
This happens when the nameserver hostname does not exist in DNS, is typed incorrectly, or is missing a trailing dot in systems that require it.
Fix: copy/paste the nameserver values exactly as provided. If the registrar UI is strict, try without any trailing dot. If the host provided four nameservers and the registrar validates only two, use the first two.
DNSSEC is enabled and now nothing resolves
If DNSSEC was enabled at the registrar for the old DNS provider, switching nameservers without updating DS records can break resolution.
Fix: either disable DNSSEC at the registrar before switching nameservers, or update the DS records to match the new provider’s DNSSEC parameters. If you do not actively manage DNSSEC, keep it off rather than half-configured.
A clean workflow for migrations (minimal downtime)
If you are moving an existing domain, the order matters.
Lower TTL on key records at the current DNS provider a day in advance if possible.
Build the complete DNS zone at the destination nameservers first, including email and verification TXT records.
Only then switch nameservers at the registrar.
Verify delegation with NS lookups, then verify A/CNAME/MX records, then test HTTP and SSL.
If you cannot lower TTL in advance, you can still migrate, but you are accepting a longer mixed-state window.
Where turbo.host fits in a low-friction setup
If you prefer a utility-first flow where the domain routes quickly to the place you manage hosting, aligning nameservers and DNS management under one roof can reduce context switching. That is the same design philosophy behind turbo.host: get you to the next step fast, with fewer pages and fewer handoffs.
The practical test is simple. If you want one console to own the zone, use turbohost nameservers. If you need DNS to stay independent, keep your existing nameservers and only change the records required for hosting.
A nameserver change is a lever. Pull it only when you want to move the whole DNS authority, not when you just need to nudge one record.
Keep your changes deliberate, verify delegation before you edit records, and let caches expire instead of fighting them. That is how you get back to shipping the site instead of staring at DNS tools.
