DNS problems rarely look like DNS problems.
A checkout page times out, email stops arriving, or a new deploy “works on my machine” but nobody else can reach it. Most of the time, the fix is not in your app. It is in the records that decide where traffic goes and what systems are allowed to speak for your domain.
This turbohost dns records guide is written for operators who want the shortest path from “domain change” to “site is reachable.” No filler. Just the records that matter, why they matter, and the failure modes to avoid.
What DNS is doing in your stack
DNS is a distributed database that maps names to answers. Those answers are not only IP addresses. They are also instructions for mail routing, verification, and policy.
Two practical implications:
First, DNS changes do not apply instantly everywhere. Caches exist at multiple layers. Your “it still points to the old server” report might be a cache, not a bad record.
Second, DNS is often the boundary between systems you control and systems you do not. Hosting, email, CDNs, and verification providers all depend on DNS. A single wrong character can take down a site just as effectively as a bad deploy.
Before you change anything: collect constraints
Start with three decisions that drive everything else.
1) What should be the canonical hostname?
Pick whether the primary public address is `example.com` (apex) or `www.example.com`. Either choice works. What breaks things is trying to make both primary without a plan.
If you care about the cleanest routing, pick one canonical hostname and redirect the other at the HTTP layer. DNS does not do HTTP redirects.
2) Where is “web” actually hosted?
You might be pointing directly to an origin server (your VPS), or to a layer in front of it (a CDN, a load balancer, a platform edge). That determines whether you should use A/AAAA records or a CNAME.
3) What is your acceptable change window?
If you cannot tolerate downtime, you need to plan TTL and cutovers. If you can tolerate a few minutes of inconsistency, you can keep TTLs higher and reduce query load.
The core records you will touch
A record (IPv4)
An A record maps a hostname to an IPv4 address. Use it when you know the destination IP and expect it to remain stable.
Common use cases:
- `example.com` to a static server IP
- `api.example.com` to a fixed backend
Trade-off: if the IP changes, you must update DNS. If your provider expects you to point to a hostname instead (like a platform endpoint), an A record can be the wrong tool.
AAAA record (IPv6)
AAAA is the IPv6 equivalent of A.
If your hosting endpoint supports IPv6, publish AAAA. If it does not, do not guess. A wrong AAAA record can cause intermittent failures because some clients prefer IPv6 and will attempt it first.
A common pattern is: publish A now, add AAAA only when you have confirmed IPv6 is live end to end.
CNAME record (alias)
A CNAME maps one hostname to another hostname.
Use it when your destination is a provider-managed name that can change behind the scenes. This is common for CDNs, hosted platforms, and some load balancers.
Constraints that matter:
- You cannot put a CNAME at the zone apex (`example.com`) in standard DNS. Some DNS providers offer “ALIAS” or “ANAME” to simulate it, but that is provider-specific behavior.
- A hostname with a CNAME should not have other record types at the same name. If you stack records on the same label, different resolvers can behave differently.
MX record (mail routing)
MX records decide where email for your domain is delivered.
MX records point to hostnames, not IPs. Those hostnames then resolve via A/AAAA. Also, MX records have priority values. Lower number is higher priority.
Operational rule: if you are changing hosting but not changing email, do not touch MX. Web and mail are separate paths, and mixing them is a fast way to break business email.
TXT record (verification and policy)
TXT is the catch-all for text-based proofs and policies.
You will use TXT for:
- Domain verification (services proving you own the domain)
- SPF (who can send mail for your domain)
- DKIM (mail signing public key)
- DMARC (mail handling policy)
TXT record failure mode: multiple overlapping TXT records, especially for SPF.
SPF must be a single record at the root for the `v=spf1` policy. You can have multiple TXT records at the apex, but you should not have multiple SPF policies. Merge them.
NS record (authoritative nameservers)
NS records define which nameservers are authoritative for your zone.
Most of your daily work is editing records within a DNS provider, not changing NS. Changing NS is a migration step. It is high impact because it changes where the world asks questions.
If you switch nameservers, assume a longer propagation window. Old NS answers can remain in caches until TTLs expire.
A clean baseline setup (web + email)
Most small operators want two outcomes: the site resolves, and email continues to function.
A practical baseline is:
- Apex (`example.com`): A record (and AAAA if confirmed)
- `www`: CNAME to the apex or to your provider target, depending on platform
- MX: whatever your email provider requires
- TXT: SPF, DKIM, DMARC, plus any verification tokens
Which direction you choose for `www` depends on hosting.
If your host wants a CNAME target, set `www` as CNAME to that target and keep the apex on A/AAAA. Then use HTTP redirect rules to consolidate to the canonical host.
If your host provides a single fixed IP, you can point both apex and `www` to the same IPs. That is simple, but you still want one canonical URL for consistency.
TTL: speed vs stability
TTL is how long resolvers can cache an answer. Lower TTL means changes can roll out faster, but it increases query volume and can amplify the effect of mistakes.
A common operational approach:
If you are planning a cutover, drop TTL on the affected records (not the whole zone) to something like 300 seconds a day in advance. Make the change. After it stabilizes, raise TTL back up.
If you are not planning changes, a higher TTL (like 3600 or more) reduces churn and is easier on caches.
It depends on how often your endpoints move. Static origin IPs can tolerate higher TTLs. Provider-managed targets often do fine with higher TTLs as well, because the provider updates their side without you.
Avoid these DNS breakages
CNAME at the apex
If you try to put a CNAME at `example.com` and your provider does not support ALIAS/ANAME, you will break basic zone behavior. Use A/AAAA at the apex unless your DNS platform explicitly supports an apex alias.
Mixed records on the same name
Do not combine a CNAME with other record types on the same label. If you need multiple behaviors, use separate hostnames like `www`, `api`, `mail`, and keep each label clean.
SPF split across multiple TXT records
If you have multiple `v=spf1` records, receivers may treat SPF as permerror. Merge includes into one policy and keep it within the DNS lookup limits.
AAAA pointing to nowhere
Publishing IPv6 without a working IPv6 path causes “some users can’t reach the site” issues that are hard to reproduce. Only add AAAA when you have verified the endpoint.
How to verify changes quickly
Verification has two parts: authoritative answers and client experience.
First, confirm what your authoritative nameservers are serving. Use `dig` or `nslookup` from a terminal and query specific nameservers if you can. You are checking that the zone has the record you intended, with the TTL you intended.
Second, confirm what clients see. That means resolving from a few networks: your local machine, a mobile hotspot, and a cloud VM if you have one. If one network still sees the old record, that is a cache. If authoritative answers are wrong, that is your zone.
When checking web routing, test both `http` and `https`. DNS only gets you to an IP or hostname. TLS and HTTP routing can still fail if certificates or virtual host configs are wrong.
For email, validate that MX targets resolve and that your SPF/DKIM/DMARC TXT records are present exactly as provided. Mail systems are strict about formatting.
When you should change nameservers (and when you should not)
Change NS only when you are migrating DNS hosting or consolidating management. If your current DNS provider is stable and you only need to repoint an A record, there is no reason to move NS.
If you do migrate, copy the entire zone first, then cut NS. Missing TXT records are the top migration failure because they are easy to overlook and can silently break mail deliverability and verification.
If your domain is part of a performance-first routing setup, keep the DNS layer simple and predictable. That is the point of a gateway experience like turbo.host: fast path to the destination, minimal surface area.
A practical cutover plan that minimizes downtime
If you are moving a site from one server to another, plan for overlap.
Lower TTL in advance. Stand up the new endpoint and verify it works using a temporary hostname like `staging.example.com` or by editing your local hosts file for a one-off test. Then update the production A/AAAA (or CNAME) when you are ready.
Keep the old endpoint running long enough to catch stragglers. Some clients will hit the old IP until caches expire. If your app can tolerate it, keep both endpoints serving the same content during the transition.
If you cannot keep both live, your only real lever is TTL plus timing. Even then, assume some residual traffic will arrive at the old address.
Closing thought
Treat DNS like a change-controlled system, not a settings page: small edits, known TTLs, clean labels, and verification from more than one network. Speed comes from fewer surprises.
