How a lookup works in plain language
When someone visits your domain, their device asks recursive resolvers for directions. Those resolvers check caches, then ask authoritative nameservers for your zone. The answer returns as records: addresses, mail routes, aliases, and text policies. If any hop is wrong, websites or email fail even when hosting itself is healthy.
Nameservers come first
Nameservers tell the internet where your DNS settings live. After registration you either keep registrar defaults or point nameservers to your host or DNS provider. Until nameservers are correct, individual record edits at the old provider may never be seen by the public internet.
- Change nameservers only when the destination zone is ready
- Copy critical records before switching providers
- Expect nameserver changes to take longer than a single A-record edit
Core record types you will use
A records map a host to an IPv4 address. AAAA maps to IPv6. CNAME aliases one hostname to another. MX routes email. TXT stores verification strings and security policies such as SPF. SRV and CAA appear for advanced services and certificate authority control.
- Use A/AAAA for apex site traffic in most classic setups
- Use CNAME for www or vendor-hosted subdomains when instructed
- Never point MX to a CNAME; follow your email provider exactly
TTL and propagation strategy
TTL controls how long resolvers cache answers. Before a planned move, lower TTL to 300–600 seconds at least a day ahead. Make the change during a quiet window, verify, then raise TTL again for stability and fewer lookups.
Common mistakes that cause downtime
Leaving old MX records beside new ones, creating CNAME-at-apex conflicts, forgetting www, and editing the wrong DNS account are frequent failures. Document every change with timestamp, previous value, and new value so rollbacks are fast.
Test before you celebrate
Verify with dig/nslookup and public checkers from more than one network. Confirm apex, www, API hosts, and email independently. Keep the previous values for at least 48 hours after a successful cutover.
- Check authoritative answers, not only local cache
- Send and receive a real test email after MX changes
- Watch SSL issuance if certificates depend on DNS validation
Key takeaways
- Fix nameservers before obsessing over individual records
- Lower TTL ahead of migrations, then raise it afterward
- Test website and email as separate success criteria
Ready to put this into practice?
Search available names, transfer an existing domain, or review security settings in your portfolio.