Most “domain setup” problems are not hosting problems. They are DNS problems, and DNS is slow to forgive small mistakes.
If you want your domain to load the site on TurboHost, you are doing one of two things: delegating DNS to TurboHost (nameservers) or keeping DNS where it is and pointing only the website records (A/AAAA/CNAME). The right choice depends on who you want to be authoritative for DNS and how much you want to manage in one place.
Open your registrar – the company where you bought the domain – and confirm you can edit either nameservers or DNS records. Some registrars lock these behind “Advanced DNS” or require domain verification.
Also confirm what you are pointing:
If you are pointing the root domain (example.com), you will usually use an A record (and possibly AAAA for IPv6). If you are pointing a subdomain (www.example.com), you may use a CNAME.
Finally, check if the domain is already in use for email. If you have active email (Google Workspace, Microsoft 365, or any SMTP provider), you must preserve MX records and related SPF/DKIM/DMARC records. Changing nameservers without migrating those records can break mail delivery.
This is the cleanest approach when you want TurboHost to manage DNS and you want one control surface for hosting and records.
Log into your hosting account and locate the domain or DNS section. You are looking for two or more nameserver hostnames that look like:
ns1.turbo.host ns2.turbo.host
Use the exact values shown in your account. Nameserver typos do not partially work – they fail.
In your registrar dashboard, find “Nameservers” or “DNS delegation.” Replace the existing nameservers with the TurboHost nameservers.
Some registrars ask whether to use “Default” or “Custom” nameservers. Choose Custom. Save changes.
If you had custom records at the old DNS host, you need to add them at TurboHost DNS after the delegation change.
This is where people get hit: switching nameservers does not copy records. You are effectively moving DNS zones. If you use email, add your MX records first, then SPF/DKIM/DMARC. If you use third-party services (verification TXT records, payment providers, analytics verification), re-add those TXT records.
Use nameservers if you want TurboHost to be the source of truth for DNS, you are fine migrating records once, and you want fewer split-brain setups where one vendor handles hosting and another handles DNS.
The trade-off is that you are committing to manage DNS in that same place. That is usually simpler, but it is still a decision.
This is the best option if you already manage DNS somewhere stable (often your registrar, Cloudflare, or a corporate DNS platform) and you do not want to move email or other records.
You need to know what to point to. Depending on your setup, TurboHost will provide one of these:
An IPv4 address for an A record (sometimes multiple) An IPv6 address for an AAAA record (optional) A target hostname for a CNAME (commonly for www)
Do not guess. Use the values provided in your hosting panel.
For the apex/root, create or update:
An A record for @ (or blank host) pointing to the TurboHost IPv4 address. If TurboHost provides IPv6, add an AAAA record for @ pointing to that IPv6 address.
If you already have A records for @ pointing elsewhere, replace them. Do not keep old addresses “just in case.” DNS does not do “maybe.”
For most sites, you want both example.com and www.example.com to work.
Common setups:
CNAME: www -> target hostname provided by TurboHost Or A record: www -> same IPv4 address as the root (only if your host instructs you to)
Prefer a CNAME for www when the host provides one. It gives the platform flexibility to move infrastructure without forcing you to chase IP changes.
DNS only gets traffic to the right server. You still need a decision about which hostname is “primary.” Many setups redirect one to the other (www to root, or root to www).
Pick one and stay consistent. It reduces certificate issues, duplicate content, and odd login/session behavior.
Plan for up to 24-48 hours for global propagation, even if you see changes locally in minutes.
Two details matter here:
TTL (time to live) controls how long resolvers cache old answers. If the previous TTL was high (like 1 day), you can wait a day even after you “fix” the record. Resolvers vary. Your phone on cellular may resolve differently than your office laptop on Wi-Fi.
If you have time before a migration, reduce TTL to 300 seconds (5 minutes) a day in advance, then make the cutover. That is one of the few easy wins in DNS work.
Do not rely on only your browser. Browsers cache and they follow redirects.
Use simple checks:
Query DNS directly using dig or nslookup to confirm the authoritative answer. Check both example.com and www.example.com. Confirm that the returned A/AAAA/CNAME matches what TurboHost provided. Test from more than one network if possible.
If you cannot use command line tools, use the DNS view inside your DNS provider to confirm what is published, then wait for propagation.
This is almost always propagation or caching.
If you just changed DNS, wait. If you changed DNS repeatedly, you may have created a longer tail of caches. Stop changing records and let it settle.
You cannot put a CNAME at the root domain on many DNS providers. If you try, it may be rejected or it may break other records.
Use an A record (and AAAA if provided) for the root unless your DNS provider supports an apex alias/ANAME feature and TurboHost explicitly instructs you to use it.
If you have multiple A records for @ and one of them is old, different resolvers may return different IPs in rotation.
Keep only the records you intend to serve the site. Same for www.
If you use a proxy layer (common with performance and security services), you might be pointing the domain at the proxy, not the origin host.
That can be fine, but then you must configure the origin inside the proxy platform. If the proxy is misconfigured, your DNS can be “correct” and your site still fails.
DNS changes can expose a certificate that does not cover the hostname.
Make sure your hosting account has a certificate for both example.com and www.example.com if you serve both. If your platform issues certificates automatically, give it time after DNS points correctly. Certificate issuance requires the domain to resolve to the host first.
You switched nameservers and did not recreate MX and TXT records. Fix that first.
Add the correct MX records. Add SPF (TXT), DKIM (TXT/CNAME depending on provider), and DMARC (TXT).
Mail systems are less forgiving than websites. You can lose messages during misconfiguration.
If you want the simplest operational model and you are comfortable moving DNS, nameservers are usually the cleanest. If you have existing DNS complexity (email, multiple subdomains, third-party verification records) and you do not want to migrate or risk omissions, keep DNS where it is and point only what is needed.
Either way, the goal is the same: one authoritative answer for each hostname, no conflicts, and enough patience for caches to expire.
If you need a single place to start, use the routing-first entry at turbo.host to get to the right destination quickly, then make the DNS change once and let it propagate.
Set it, verify it with direct DNS queries, and then leave it alone long enough for the internet to catch up. That last part is where most “DNS issues” disappear.
A practical guide to high uptime hosting architecture, covering redundancy, failover, DNS, databases, monitoring, and…
Learn how to fix redirect loop on hosting domain setups by checking SSL, DNS, CMS,…
Find the best web hosting for uptime monitoring with practical criteria on alerts, logs, regions,…
Dedicated server hosting gives you full server resources, tighter control, and steadier performance when shared…
Learn how to prevent open redirect vulnerabilities with safe redirect patterns, validation rules, allowlists, and…
Find the best web hosting for ecommerce stores based on speed, uptime, scaling, security, and…