DNS Cheat Sheet: A Quick Guide for Developers and Administrators

DNS rarely gets attention until something breaks. A deploy goes out, the app is running fine on its own IP, but the domain still points nowhere — and suddenly everyone on the team is retyping the same lookup commands and guessing at TTL values. This DNS cheat sheet exists for exactly that moment: no protocol history, no RFC deep-dive, just the records, commands, and scenarios that come up when you're launching a server, chasing an outage, or reviewing someone else's zone file.

It's written for two overlapping groups: developers who touch DNS a few times per project and need something fast to reference, and administrators who manage it daily and want a shared vocabulary for the team. Whether you're pointing a fresh domain at a new host or trying to figure out why email keeps landing in spam, the same handful of record types and tools cover most of it. Keep this open in a tab; it's built to be scanned, not read cover to cover.

Most of what follows sorts into three buckets: what the common DNS records actually mean, how a DNS lookup travels from a browser to an answer and back, and what tends to go wrong along the way. None of it requires memorizing a spec — it's closer to muscle memory once you've run through a migration or two, and this page is meant to shortcut that learning curve for anyone who hasn't yet.

DNS Basics: Terms You'll Actually Use

A few definitions before the record table, since most DNS confusion comes from mixing these up. A resolver is the service — run by your ISP, or a public option like 1.1.1.1 or 8.8.8.8 — that looks up records on your behalf and caches the results. An authoritative server is the one that actually holds the zone file for a domain and gives the final answer. A zone file is the list of all DNS records for a given domain, and TTL (time to live) is how long, in seconds, a resolver is allowed to cache a record before asking again.

Those four pieces interact more than people expect. The resolver only asks the authoritative server once per record, then leans on its cached copy for as long as the TTL allows — which means a change you make in the zone file is correct the instant you save it, but invisible to anyone holding a cached answer until that cache expires. That gap is behind most "I already changed it, why isn't it working" questions.

With that out of the way, here's the DNS records reference most people actually need:

How a DNS Lookup Actually Works

Every DNS lookup follows roughly the same chain, whether it's triggered by a browser, a curl command, or an app server resolving an internal hostname. Knowing the order matters, because half of DNS troubleshooting is figuring out which link in this chain is holding a stale or wrong answer — the fix is different depending on whether the problem is sitting in a browser cache, a resolver, or the authoritative server itself.

1. The client checks its own local cache first — the browser, then the operating system.
2. If nothing is cached, the query goes to a configured recursive resolver, usually your ISP's or a public one.
3. The resolver checks its cache; if it's empty, it asks a root server where to find the answer.
4. The root server doesn't know the answer either, but it points the resolver to the right TLD nameserver (for example, the servers handling .com).
5. The TLD nameserver points the resolver to the authoritative nameserver for the specific domain.
6. The authoritative nameserver returns the actual record — an A, MX, or whatever was requested.
7. The resolver caches that answer for the record's TTL and hands it back to the client.

That last step is why changing a record doesn't take effect everywhere instantly. Every resolver that already cached the old value keeps serving it until its TTL runs out, which is the whole reason DNS propagation feels unpredictable even when the change itself was applied correctly. It's also worth knowing that a missing record gets cached too — a failed DNS lookup produces a negative response that resolvers hold onto for a shorter period, which is why a typo you just fixed can still fail for a few minutes after the correction goes live.

Advantages and Trade-offs of DNS-Based Design

Relying on DNS to route traffic is convenient, but it comes with trade-offs that are worth knowing before you lean on it for anything critical.

Limitations and Risks Worth Knowing

DNS wasn't designed with security as a first concern, and some of that shows up decades later. Standard queries travel over unencrypted UDP, which leaves them open to on-path inspection and, in rarer cases, cache poisoning — where a resolver is tricked into storing a fake record. DNSSEC, along with encrypted transport options like DNS over HTTPS and DNS over TLS, address most of this, though plenty of setups still run without them.

There's also the single-point-of-failure problem. A domain that relies on only one nameserver, or only one DNS provider, goes dark the moment that one thing has an outage — no matter how solid the actual application infrastructure is. Running a secondary nameserver, or splitting DNS across two providers, removes that risk at a fairly low cost.

TTL misconfiguration causes its own category of pain. Set it too high and a migration drags on for hours or days longer than it needs to, since cached resolvers keep sending traffic to the old server. Set it too low, and every resolver has to re-query constantly, adding unnecessary load and, on some providers, unnecessary billing for lookups.

There's a subtler risk in how much trust gets placed in a DNS provider by default. Moving DNS hosting to a third party means every future change to your DNS records — a new subdomain, an emergency failover, a corrected typo — depends on that provider's dashboard and API staying available and honest. Larger teams sometimes work around this with split-horizon DNS, where internal and external resolvers return different answers for the same hostname, keeping internal service names out of public zone files entirely. It solves a real problem, but it also doubles the number of places a record has to be updated correctly.

Practical Scenarios: DNS Cheat Sheet in Action

Pointing a Domain to a New VPS

This is the one almost everyone does at some point: moving a domain to a new host. The safe order is to lower the TTL a day ahead of the move, create or update the A record (and AAAA if the server has an IPv6 address), then confirm the new server is answering correctly before touching anything else. A quick check from the command line:

Providers like Falconcloud VPS hosting hand you the server's IP address as soon as the instance is deployed, which is really the only piece of information the A record needs — everything after that is just waiting out the old TTL.

Setting Up Mail Delivery

Mail routing depends on an MX record plus a set of TXT records — SPF, DKIM, and DMARC — that tell receiving mail servers your domain actually authorized the message. Miss one and messages either bounce or land in spam.

SPF lists which servers are allowed to send on your behalf, DKIM signs outgoing messages so receivers can verify they weren't altered in transit, and DMARC tells receivers what to do when a message fails either check. All three together are what most mailbox providers expect before they'll trust a domain.

Verifying Domain Ownership

Third-party tools — email platforms, CDNs, certificate authorities — often ask for a TXT record containing a specific token before they'll act on a domain's behalf. The logic is straightforward: anyone can claim to own a domain, but only the person who controls the zone file can actually add a record to it, so the token doubles as proof.

Using CNAME for Subdomains and CDN Endpoints

CNAME records point one hostname at another, which is the usual setup for a subdomain served by a CDN or a SaaS platform — blog.example.com pointing at a hosted blogging platform, for instance. The common gotcha: a name can't have a CNAME and any other record type at the same time, so adding one to the root domain instead of a subdomain often breaks things in ways that aren't obvious at first glance.

Migrating Between DNS Providers

Switching who hosts your zone — moving off a registrar's default DNS onto a dedicated provider, for instance — is riskier than editing a single record, because every record has to survive the move intact. The safe sequence: export or manually copy every existing DNS record into the new provider first, double-check each one against the original zone, and only then update the nameserver records at the registrar to point at the new provider. Keep the old zone active and untouched for a few days after the cutover; if anything was missed, you can still compare against it instead of guessing what the original values were.

Running that command against both the old and new nameservers before and after the switch is the fastest way to confirm the registrar-level change actually took, rather than assuming it did because the dashboard said so.

Diagnosing "The Site Won't Load"

When a domain won't resolve, or resolves to the wrong place, nslookup and dig are the first tools to reach for.

The +trace flag walks the entire resolution chain from the root servers down, which is genuinely useful when the problem sits somewhere between the registrar and the authoritative nameserver rather than in the record itself. A plain lookup only shows you the final answer; a trace shows you exactly where that answer came from.

Common Mistakes That Break DNS Setups

Most DNS incidents trace back to a small set of repeat offenders. None of them are exotic — they're the kind of mistake that's obvious in hindsight and invisible while you're mid-deploy.

• Leaving TTL high right before a migration, which stretches out downtime for anyone whose resolver already cached the old record
• Forgetting to update the nameserver records at the registrar after switching DNS providers, so every other change quietly never takes effect
• Typos in record values — an extra digit in an IP address, or a missing trailing dot on a CNAME target
• Skipping reverse DNS (PTR) on a mail server, which gets outgoing messages flagged as spam by stricter receivers
• Adding a wildcard record that silently overrides subdomains someone else already configured on purpose
• Cutting over to a new server before confirming propagation, then debugging what looks like random behavior but is really just a mix of old and new cached answers
• Not saving a copy of the old DNS records before making changes, which turns a rollback into guesswork instead of a two-minute fix
• Testing changes only from one device or network, then assuming the result holds everywhere — a local resolver cache can hide a problem that's very much still live for other visitors

Conclusion

DNS looks simple right up until an incident forces you to relearn six tools and three acronyms at once, usually at the least convenient time. Keeping a DNS cheat sheet like this one within reach — record types, the lookup chain, the commands, the usual failure points — turns that scramble into a five-minute lookup instead. For deeper coverage of related topics, from DNSSEC to multi-region failover, the Falconcloud blog is a reasonable next stop once the basics here feel routine.

FAQ