DNS breaks more mornings than any other piece of infrastructure I work with. A site goes down, an email stops arriving, an SSL certificate fails to issue — and nine times out of ten, the trail leads back to a misconfigured record or a stale cache. I put this cheat sheet together as the reference I actually keep open in a browser tab, not a theoretical overview. It covers the records, the commands, and the troubleshooting steps I reach for constantly, organized so you can scan and find what you need in seconds.
Bookmark this page. Whether you’re a sysadmin, a developer deploying your first app, or you’re studying for a networking interview, this is meant to save you the fifteen minutes of searching you’d otherwise lose every time DNS acts up.
Table of Contents
- What DNS Actually Does (Quick Refresher)
- DNS Record Types Reference Table
- DNS Record Syntax and Examples
- How a DNS Query Resolves (Step by Step)
- Essential DNS Commands by Platform
- dig Command Deep Dive
- nslookup and host Command Reference
- DNS Troubleshooting Playbook
- TTL and DNS Propagation Explained
- DNS Security Best Practices
- Real-World DNS Workflows
- Common DNS Mistakes to Avoid
- FAQs
- Interview Questions and Answers
- Printable Quick-Reference Summary
- Official Documentation Links
1. What DNS Actually Does (Quick Refresher)
DNS (Domain Name System) is the phonebook of the internet, but that description undersells it. It’s a distributed, hierarchical, heavily cached database that translates human-readable names into machine-usable data — IP addresses, mail server priorities, verification tokens, and more.
The hierarchy runs like this:
- Root servers — the starting point for every lookup, represented by a single dot (
.) - TLD servers — handle
.com,.org,.io, country codes like.pk, and so on - Authoritative name servers — hold the actual records for a specific domain
- Recursive resolvers — the servers your ISP or a public provider (like 1.1.1.1 or 8.8.8.8) runs to do the lookup work on your behalf
Every time you type a domain into a browser, this chain gets walked (or, more often, answered straight from cache).
2. DNS Record Types Reference Table
This is the table I refer back to constantly. Keep it handy.
| Record Type | Purpose | Example Value | Notes |
|---|---|---|---|
| A | Maps a hostname to an IPv4 address | 192.0.2.10 | Most common record type |
| AAAA | Maps a hostname to an IPv6 address | 2001:db8::1 | Required for IPv6 reachability |
| CNAME | Aliases one hostname to another | www.example.com. -> example.com. | Cannot coexist with other records on the same name |
| MX | Directs email to mail servers | 10 mail.example.com. | Lower priority number = higher preference |
| TXT | Stores arbitrary text data | "v=spf1 include:_spf.google.com ~all" | Used for SPF, DKIM, DMARC, domain verification |
| NS | Delegates a zone to name servers | ns1.example.com. | Defines which servers are authoritative |
| SOA | Start of Authority — zone metadata | serial, refresh, retry, expire, TTL | One per zone, defines zone-wide defaults |
| PTR | Reverse DNS — IP to hostname | 10.2.0.192.in-addr.arpa. -> host.example.com. | Critical for mail server reputation |
| SRV | Defines a service’s host and port | _sip._tcp.example.com. 5 0 5060 sip.example.com. | Used by VoIP, XMPP, Active Directory |
| CAA | Restricts which CAs can issue certs | 0 issue "letsencrypt.org" | Security control against mis-issuance |
| ALIAS/ANAME | CNAME-like behavior at the zone apex | Provider-specific | Not a standard DNS type, vendor feature |
| NAPTR | Regex-based rewriting rules | Used in ENUM, SIP routing | Rare outside telecom |
| DS / DNSKEY | DNSSEC chain of trust | Cryptographic hashes and keys | Covered more in the security section |
3. DNS Record Syntax and Examples
A standard zone file entry follows this pattern:
name TTL class type value
Real examples from a working zone file:
example.com. 3600 IN A 192.0.2.10
www.example.com. 3600 IN CNAME example.com.
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN TXT "v=spf1 mx include:_spf.google.com ~all"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
example.com. 3600 IN NS ns1.example.com.
example.com. 3600 IN NS ns2.example.com.
A few syntax habits that will save you debugging time:
- Always terminate fully-qualified domain names with a trailing dot (
example.com.) in raw zone files. Most DNS providers’ web UIs handle this for you, but if you’re editing zone files directly, forgetting the dot is one of the most common causes of broken records. - TXT record values longer than 255 characters need to be split into quoted strings.
- MX records always need a priority number before the mail server hostname.
4. How a DNS Query Resolves (Step by Step)
Here’s what happens, in order, when a browser looks up www.example.com with a cold cache:
- Browser cache check — has this domain been resolved recently?
- OS cache check — the local stub resolver checks its own cache.
- Recursive resolver query — the request goes to a configured resolver (ISP default, or a public one like 1.1.1.1, 8.8.8.8, 9.9.9.9).
- Root server query — the resolver asks a root server, which points to the TLD server for
.com. - TLD server query — the
.comserver responds with the authoritative name servers forexample.com. - Authoritative server query — the resolver asks that name server directly for the
Arecord. - Response returned and cached — the answer flows back to the browser and gets cached at every layer, honoring the record’s TTL.
This whole chain typically completes in under 100ms and is invisible unless something breaks.
5. Essential DNS Commands by Platform
| Task | Linux / macOS | Windows |
|---|---|---|
| Basic lookup | dig example.com | nslookup example.com |
| Lookup specific record type | dig example.com MX | nslookup -type=MX example.com |
| Reverse lookup | dig -x 192.0.2.10 | nslookup 192.0.2.10 |
| Trace full resolution path | dig +trace example.com | Not natively available |
| Query a specific DNS server | dig @8.8.8.8 example.com | nslookup example.com 8.8.8.8 |
| Flush DNS cache | sudo systemd-resolve --flush-caches (Linux) / sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder (macOS) | ipconfig /flushdns |
| Show current DNS config | resolvectl status or cat /etc/resolv.conf | ipconfig /all |
| PowerShell lookup | — | Resolve-DnsName example.com |
| Simple hostname lookup | host example.com | — |
| Check DNSSEC validation | dig +dnssec example.com | Resolve-DnsName -DnssecOk example.com |
6. dig Command Deep Dive
dig (Domain Information Groper) is the tool I default to for anything beyond a casual check — it’s more scriptable and detailed than nslookup.
Basic syntax:
dig [@server] [name] [type] [options]
Common real examples:
# Basic A record lookup
dig example.com
# Query MX records
dig example.com MX
# Query all record types (ANY is deprecated by many servers, use per-type queries instead)
dig example.com A AAAA MX TXT NS
# Short answer only, skips the verbose header
dig example.com +short
# Query against a specific resolver
dig @1.1.1.1 example.com
# Full trace from the root down
dig example.com +trace
# Reverse DNS lookup
dig -x 192.0.2.10
# Check TTL remaining
dig example.com +noall +answer
Sample expected output for dig example.com +short:
192.0.2.10
Sample expected output for a full dig example.com A:
;; ANSWER SECTION:
example.com. 3600 IN A 192.0.2.10
;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
The +short flag is what I use in scripts. The full output is what I use when I need to see TTL, query time, and which server actually answered.
7. nslookup and host Command Reference
nslookup ships on nearly every OS by default, which makes it the fastest tool to reach for when you’re on an unfamiliar machine.
# Basic lookup
nslookup example.com
# Query a specific record type
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com
# Query against a specific server
nslookup example.com 8.8.8.8
# Interactive mode
nslookup
> set type=MX
> example.com
> exit
host is the lightweight Linux/macOS alternative, good for quick one-liners:
host example.com
host -t MX example.com
host -a example.com # all records
8. DNS Troubleshooting Playbook
When something’s not resolving correctly, I work through this sequence rather than guessing:
- Confirm the record exists at the authoritative source.
dig @ns1.example.com example.com AIf it’s wrong here, the problem is at the registrar or DNS provider — fix it there first. - Check propagation across public resolvers.
dig @8.8.8.8 example.com dig @1.1.1.1 example.comInconsistent answers between resolvers usually just means TTL hasn’t expired everywhere yet. - Rule out local caching. Flush your OS DNS cache and browser cache, then retest.
- Verify the record type matches expectations. A surprisingly common issue: someone points a root domain (
example.com) at a CNAME, which most authoritative DNS specs disallow at the zone apex. Use an A/ALIAS record instead. - Check for typos in the value itself. Trailing dots, extra spaces in TXT records, or a transposed IP octet are the usual suspects.
- Confirm NS delegation matches at the registrar.
dig example.com NS whois example.comIf the registrar’s NS records don’t match what your DNS provider expects, nothing else will work correctly no matter how clean your zone file is. - For email issues specifically, verify MX, SPF, DKIM, and DMARC together — they’re interdependent, and a broken SPF record will cause deliverability issues even when MX is perfectly fine.
- For SSL/TLS issuance failures, check CAA records.
dig example.com CAAIf a CAA record restricts issuance to a CA other than the one you’re using, issuance will fail silently from the certificate provider’s side.
9. TTL and DNS Propagation Explained
TTL (Time To Live) is measured in seconds and tells every resolver how long it’s allowed to cache a record before re-querying the authoritative server.
| TTL Value | Human Readable | Common Use Case |
|---|---|---|
| 60 | 1 minute | Active migration, testing changes |
| 300 | 5 minutes | Pre-migration window |
| 3600 | 1 hour | Standard default for most records |
| 14400 | 4 hours | Stable records, low change frequency |
| 86400 | 24 hours | Long-term stable infrastructure |
A practical workflow I follow before any DNS migration: lower the TTL to 300 seconds at least 24–48 hours in advance. That way, when the actual cutover happens, cached copies expire quickly and the change propagates fast. After the migration settles, I raise the TTL back to a normal value to reduce query load on the authoritative servers.
“Propagation” isn’t really DNS data traveling anywhere — the authoritative record updates instantly. What you’re actually waiting on is every resolver’s cached copy expiring according to its TTL. That’s why full propagation can take anywhere from a few minutes to 48 hours.
10. DNS Security Best Practices
- Enable DNSSEC where your registrar and DNS provider support it. It cryptographically signs records so resolvers can verify authenticity and reject tampered responses.
- Set CAA records to restrict which Certificate Authorities can issue certs for your domain — this closes off a class of mis-issuance attacks.
- Use SPF, DKIM, and DMARC together, not in isolation. SPF alone is easily bypassed; DMARC is what actually enforces policy and gives you visibility through aggregate reports.
- Lock your registrar account with two-factor authentication and enable registry lock if your registrar offers it — domain hijacking usually starts at the registrar, not the DNS provider.
- Avoid wildcard DNS records unless you specifically need them. A wildcard (
*.example.com) can accidentally expose unintended subdomains to whatever the wildcard points to. - Monitor for DNS cache poisoning symptoms — unexpected redirects, SSL warnings on a domain that should have a valid cert, or resolution mismatches between resolvers.
- Use DNS over HTTPS (DoH) or DNS over TLS (DoT) on client devices where privacy from network-level snooping matters.
- Rotate and audit NS delegation periodically — orphaned or stale name server entries are a quiet security risk that rarely gets checked.
11. Real-World DNS Workflows
Verifying domain ownership for a third-party service (Google Workspace, AWS, etc.):
TXT record: example.com -> "google-site-verification=abc123..."
Add it, wait for propagation, then trigger verification on the provider’s side. If verification fails immediately, it’s almost always a caching delay — wait a few minutes and retry rather than re-adding the record.
Setting up email for a custom domain:
example.com. MX 10 mail.example.com.
example.com. TXT "v=spf1 include:_spf.provider.com ~all"
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:reports@example.com"
I always start DMARC at p=none to monitor reports before moving to p=quarantine or p=reject, so a misconfiguration doesn’t silently drop legitimate mail.
Debugging “site works for me but not for a colleague”: This is almost always a propagation or local caching difference. Run dig against the same public resolver (like 1.1.1.1) from both machines to compare directly, rather than relying on default ISP resolvers which may have cached different states.
Migrating DNS providers without downtime:
- Lower TTLs a day or two ahead.
- Recreate every record exactly at the new provider.
- Double-check MX, TXT, and CAA records specifically — these are the ones people forget to copy.
- Update the NS records at the registrar.
- Monitor both old and new authoritative servers for query traffic until it fully shifts.
12. Common DNS Mistakes to Avoid
- Forgetting the trailing dot in raw zone file entries, causing the value to be appended to the zone name.
- Setting a CNAME at the root/apex domain, which conflicts with the required SOA and NS records there.
- Leaving TTL high right before a planned migration, causing an unnecessarily long cutover window.
- Copying an old SPF record verbatim into a new provider setup without updating the
includemechanisms, breaking deliverability. - Assuming a DNS change is “not working” when it’s really just still propagating — always verify against a fresh resolver before troubleshooting further.
- Deleting old MX or A records too early during a migration, before confirming the new ones are live and consistent everywhere.
- Overlooking CAA records when a certificate suddenly stops renewing.
- Using
ANYqueries for troubleshooting — many resolvers now throttle or refuse them; query specific types instead.
13. FAQs
Q: Why does a DNS change take time to show up everywhere? Because of caching. Every resolver in the chain holds onto the old answer until its TTL expires — the origin record updates instantly, but the world catches up gradually.
Q: What’s the difference between A and CNAME records? An A record points a name directly to an IP address. A CNAME points a name to another name, which then gets resolved further. CNAMEs can’t coexist with other record types on the same name, and generally shouldn’t be used at the zone apex.
Q: Why is my email going to spam even though MX records are correct? MX only controls where mail is delivered, not deliverability. Check SPF, DKIM, and DMARC — missing or misaligned records here are the most common cause of spam placement.
Q: What’s the fastest public DNS resolver? Performance varies by location and network, but 1.1.1.1 (Cloudflare), 8.8.8.8 (Google), and 9.9.9.9 (Quad9) are all reliable, privacy-conscious options worth benchmarking against your ISP’s default.
Q: Can I have two MX records for redundancy? Yes — that’s standard practice. Give the backup a higher priority number (a higher number means lower preference), so it’s only used when the primary is unreachable.
Q: What is a glue record? A glue record is an A/AAAA record for a name server that itself lives inside the domain it serves (e.g., ns1.example.com handling DNS for example.com). It’s needed to avoid a circular lookup dependency and is managed at the registrar level.
Q: Does lowering TTL affect performance? Very slightly — lower TTLs mean more frequent queries to the authoritative server since caches expire faster. For most domains this is negligible; it only matters at very high query volumes.
14. Interview Questions and Answers
Q: Explain the DNS resolution process from browser to response. A: The resolver checks local caches first, then queries a recursive resolver, which walks the hierarchy from root → TLD → authoritative server, returning the final answer, which gets cached at each layer per the record’s TTL.
Q: What’s the difference between a recursive resolver and an authoritative name server? A: A recursive resolver does the work of tracking down an answer on behalf of a client and caches the result. An authoritative name server holds the actual source-of-truth records for a specific zone and doesn’t perform lookups on behalf of others.
Q: Why can’t you put a CNAME record at the zone apex? A: Because the apex must also hold SOA and NS records, and DNS specifications don’t allow a CNAME to coexist with other record types on the same name.
Q: What does a high MX priority number mean? A: Counter-intuitively, a higher number means lower priority. The mail server with the lowest number is tried first.
Q: What problem does DNSSEC solve? A: It adds cryptographic signing to DNS responses so resolvers can verify that a record hasn’t been tampered with in transit, protecting against cache poisoning and spoofing attacks.
Q: How would you troubleshoot a domain that resolves correctly from one location but not another? A: Query the same public resolver from both locations to rule out caching differences, confirm the authoritative server itself has the correct record, and check for any geo-based DNS routing or CDN configuration that might legitimately return different answers by region.
Q: What’s the purpose of a PTR record? A: It provides reverse DNS — mapping an IP address back to a hostname — which is commonly checked by mail servers as part of spam filtering and sender reputation checks.
15. Printable Quick-Reference Summary
RECORD TYPES
A -> hostname to IPv4
AAAA -> hostname to IPv6
CNAME -> alias to another hostname
MX -> mail server + priority
TXT -> text data (SPF/DKIM/DMARC/verification)
NS -> delegated name servers
SOA -> zone authority metadata
PTR -> IP to hostname (reverse DNS)
SRV -> service host + port
CAA -> allowed certificate authorities
CORE COMMANDS
dig example.com quick lookup
dig example.com MX +short specific type, short output
dig @8.8.8.8 example.com query specific resolver
dig example.com +trace full resolution path
nslookup -type=MX example.com Windows-friendly lookup
ipconfig /flushdns flush cache (Windows)
sudo systemd-resolve --flush-caches flush cache (Linux)
TROUBLESHOOTING ORDER
1. Check authoritative source
2. Check public resolvers (1.1.1.1, 8.8.8.8)
3. Flush local/browser cache
4. Verify record type and value syntax
5. Confirm NS delegation at registrar
6. Check SPF/DKIM/DMARC for email issues
7. Check CAA for certificate issues
16. Official Documentation Links
- IETF RFC 1035 (Domain Names — Implementation and Specification): https://www.rfc-editor.org/rfc/rfc1035
- IETF RFC 1034 (Domain Names — Concepts and Facilities): https://www.rfc-editor.org/rfc/rfc1034
- ICANN — DNS Resources: https://www.icann.org/resources/pages/dns-2012-02-25-en
- Cloudflare DNS Learning Center: https://www.cloudflare.com/learning/dns/what-is-dns/
- Google Public DNS Documentation: https://developers.google.com/speed/public-dns/docs
- DNSSEC information (ICANN): https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en
- IANA Root Zone Database: https://www.iana.org/domains/root/db
That’s the reference I keep coming back to. DNS problems are rarely mysterious once you approach them systematically — check the source of truth first, work outward through caching layers, and match the record type to what you’re actually trying to accomplish. Keep this page bookmarked; you’ll need it again sooner than you think.
