DNS Record Types
A, AAAA, CNAME, MX & More
LinkedIn Hook
Your DNS zone file is a contacts app — and every record type is a different kind of entry.
Most developers know
Arecords exist. Fewer know why you can't use aCNAMEat your root domain. Almost none can explain whyMXrecords have a priority number — or what happens when you forget them entirely.Here is a quick map of the records that make the internet work:
- A — your domain → an IPv4 address (the most common record)
- AAAA — your domain → an IPv6 address (four times the A, four times the address size)
- CNAME — one domain name → another domain name (alias, not IP)
- MX — your domain → a mail server (with priority for redundancy)
- TXT — arbitrary text (SPF, DKIM, domain verification, DMARC)
- NS — which nameservers are authoritative for your domain
- PTR — reverse DNS — IP address → domain name
- SOA — zone metadata, the first record in every zone file
The one rule that trips everyone up: you cannot put a CNAME at your apex domain (
example.com). Ever. DNS forbids it. Most cloud providers work around this with a proprietary ALIAS/ANAME record.Full lesson → [link]
#DNS #Networking #SystemDesign #BackendEngineering #InterviewPrep #WebDevelopment
What You'll Learn
- What each DNS record type does and when to use it
- The critical CNAME restriction at the apex domain and how cloud providers work around it
- How MX record priority numbers control mail server failover
- What TXT records are actually used for in production (SPF, DKIM, DMARC, verification)
- How to read and write a real DNS zone file
- How to query each record type with
dig - How TTL affects DNS propagation speed and caching behavior
The Contacts App Analogy
Think of a DNS zone file as a smartphone contacts app. Your domain is the contact. But one contact can have many types of entries:
- Phone number (home, work, mobile) — like an A record: where to reach the server directly
- "Same as..." note — like a CNAME record: "call John's office, same as the main line"
- Email address — like an MX record: where to send mail for this domain
- Note / bio field — like a TXT record: arbitrary text (SPF policy, verification tokens)
- Address — like an NS record: where the authoritative information lives
Each record type answers a different question about the domain. The DNS resolver figures out which type to ask for based on what the client needs.
Record Types — Complete Reference
A Record — Domain to IPv4
The most common DNS record. Maps a hostname to an IPv4 address. When your browser resolves example.com, it is almost always fetching an A record.
; Syntax: <name> <ttl> <class> <type> <value>
example.com. 3600 IN A 93.184.216.34
www.example.com. 3600 IN A 93.184.216.34Multiple A records = round-robin load balancing. You can have the same name map to several IPs. DNS returns all of them in rotating order; clients typically use the first one.
; Round-robin: each query rotates the order of IPs returned
api.example.com. 60 IN A 10.0.0.1
api.example.com. 60 IN A 10.0.0.2
api.example.com. 60 IN A 10.0.0.3Note the low TTL (60 seconds) — when doing load balancing this way, you want changes to propagate quickly.
Query with dig:
dig A example.com
dig example.com # A record is the default typeAAAA Record — Domain to IPv6
Same as A, but for IPv6 addresses. The name "AAAA" (Quad-A) is a nod to IPv6 being four times the address size of IPv4 (128 bits vs 32 bits).
example.com. 3600 IN AAAA 2606:2800:220:1:248:1893:25c8:1946Most modern domains publish both A and AAAA records. Clients that support IPv6 (most do now) will prefer AAAA via a mechanism called Happy Eyeballs, which races IPv4 and IPv6 connections and uses whichever connects first.
Query with dig:
dig AAAA example.comCNAME Record — Alias to Another Name
CNAME stands for "Canonical Name." It creates an alias: one domain name points to another domain name, not directly to an IP. The resolver follows the chain until it hits an A or AAAA record.
; www is an alias for the root domain
www.example.com. 3600 IN CNAME example.com.
; CDN alias — static assets served via CloudFront
static.example.com. 3600 IN CNAME example.cloudfront.net.
; The chain: static.example.com → example.cloudfront.net → (CloudFront's A record)Why use CNAME? When a service (CDN, SaaS tool, load balancer) gives you a hostname instead of an IP, you alias your subdomain to that hostname. If they change their IP, your CNAME still works — you never stored the IP directly.
The critical CNAME rule: no CNAME at the apex domain.
The apex (or root) domain is example.com. — the bare domain, no subdomain. RFC 1034 forbids a CNAME record at the apex when other record types (like NS or SOA) also exist for that name. And NS and SOA records must exist at the apex — without them, the zone is invalid.
This means you cannot do:
; INVALID — breaks the zone
example.com. 3600 IN CNAME myapp.herokuapp.com. ; WRONG — do not do thisThe workaround: Cloud DNS providers (Cloudflare, Route 53, NS1) offer proprietary record types called ALIAS or ANAME. These behave like a CNAME conceptually but are resolved server-side by the nameserver itself, so externally they look like A records. Internally:
- Route 53:
ALIASrecord - Cloudflare: automatically flattens CNAME at apex ("CNAME flattening")
- DNS Made Easy:
ANAME
Query with dig:
dig CNAME www.example.comMX Record — Mail Exchanger
MX records tell the world which mail server handles email for your domain. When someone sends email to user@example.com, their mail server queries for the MX records of example.com to find where to deliver the message.
; Syntax: <name> <ttl> IN MX <priority> <mail-server>
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
example.com. 3600 IN MX 30 mail3.example.com.The priority number: Lower number = higher priority. The sending mail server always tries the lowest priority number first. If it fails (server down, connection refused), it tries the next lowest, and so on. This is how you get mail redundancy without any active load balancing — the secondary server just sits there waiting for the primary to fail.
Common setups:
- Single mail server:
MX 10 mail.example.com. - Google Workspace: multiple MX records, all pointing to Google's servers with different priorities
- Fallback: primary at priority 10, backup SMTP relay at priority 50
Key detail: The value of an MX record must be a hostname that itself has an A or AAAA record — not a CNAME, and not an IP address. This is enforced by DNS.
Query with dig:
dig MX example.comNS Record — Nameserver
NS records declare which nameservers are authoritative for a domain. These are the servers that hold the actual DNS records and answer queries for the zone.
example.com. 86400 IN NS ns1.example.com.
example.com. 86400 IN NS ns2.example.com.Note the high TTL (86400 = 24 hours). Nameserver records change rarely — when they do (during a DNS migration), the long TTL means changes take up to 24 hours to propagate globally. This is expected and normal.
You typically have 2–4 NS records for redundancy. If one nameserver is unreachable, resolvers try the others. The NS records shown in your zone file must match what your domain registrar has on file (the "glue records") — a mismatch breaks DNS resolution entirely.
Query with dig:
dig NS example.comTXT Record — Text Data
TXT records store arbitrary human-readable or machine-readable text. They have become the standard mechanism for domain ownership verification and email authentication.
SPF (Sender Policy Framework) — declares which servers are authorized to send email as your domain. Receiving mail servers check this to detect spoofing.
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"The ~all means "soft fail" — other servers may send, but receiving servers can flag it. −all (hard fail) would reject all other senders.
DKIM (DomainKeys Identified Mail) — a public key that receiving servers use to verify the cryptographic signature on your outgoing emails.
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."DMARC (Domain-based Message Authentication) — a policy that tells receiving servers what to do with emails that fail SPF and DKIM checks.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"p=quarantine means put suspicious mail in spam. p=reject means reject it outright.
Domain ownership verification — services like Google Search Console, AWS SES, and GitHub Pages ask you to add a TXT record to prove you control the domain.
example.com. 3600 IN TXT "google-site-verification=abc123def456ghi789"
example.com. 3600 IN TXT "MS=ms12345678" ; Microsoft 365 verificationQuery with dig:
dig TXT example.com
dig TXT _dmarc.example.com
dig TXT google._domainkey.example.comSOA Record — Start of Authority
Every DNS zone begins with exactly one SOA record. It contains metadata about the zone itself. You rarely configure this manually — your DNS provider manages it — but you will see it in zone files and dig output.
example.com. 86400 IN SOA ns1.example.com. admin.example.com. (
2024042201 ; Serial number (often YYYYMMDDNN — date + increment)
3600 ; Refresh — how often secondary nameservers check for updates (seconds)
900 ; Retry — how long to wait before retrying a failed refresh
604800 ; Expire — how long secondaries serve the zone if they can't reach primary
300 ; Minimum TTL — minimum TTL for negative responses (NXDOMAIN caching)
)The serial number is critical for zone transfers: secondary nameservers compare their serial to the primary's serial. If the primary's serial is higher, the secondary pulls a fresh copy of the zone. If you update records but forget to increment the serial, secondaries will not sync.
Query with dig:
dig SOA example.comPTR Record — Reverse DNS
PTR (Pointer) records are the reverse of A records: they map an IP address to a domain name. They live in a special zone called in-addr.arpa (for IPv4) or ip6.arpa (for IPv6).
; Forward: example.com → 93.184.216.34 (A record)
; Reverse: 93.184.216.34 → example.com (PTR record)
; The IP is written in reverse in the arpa zone
34.216.184.93.in-addr.arpa. 3600 IN PTR example.com.Why PTR records matter for email: Receiving mail servers often check that the sending IP has a PTR record that matches the sending domain. If your mail server's IP (mail.example.com → 93.184.216.34) has no PTR record — or the PTR points to something unrelated — many spam filters will reject or flag your email. PTR records for IP space are managed by the IP owner (usually your hosting provider or ISP), not by your domain registrar.
Query with dig:
dig -x 93.184.216.34 # reverse lookup shorthand
dig PTR 34.216.184.93.in-addr.arpa.SRV Record — Service Location
SRV records specify the hostname and port for a specific service under a domain. They are used by protocols that need to discover service endpoints dynamically — SIP (VoIP), XMPP (chat), some game servers, and internal microservice discovery.
; Syntax: _service._proto.name TTL IN SRV priority weight port target
_sip._tcp.example.com. 3600 IN SRV 10 20 5060 sip1.example.com.
_xmpp-client._tcp.example.com. 3600 IN SRV 5 0 5222 xmpp.example.com.Fields: priority (lower = preferred), weight (load-balance between same-priority records), port, target hostname.
Query with dig:
dig SRV _sip._tcp.example.comTTL — Time To Live
Every DNS record has a TTL value measured in seconds. It controls how long resolvers and browsers cache the record before asking again.
example.com. 300 IN A 93.184.216.34 ; TTL = 300 seconds (5 minutes)
example.com. 3600 IN A 93.184.216.34 ; TTL = 3600 seconds (1 hour)
example.com. 86400 IN A 93.184.216.34 ; TTL = 86400 seconds (24 hours)| TTL | Propagation Speed | DNS Query Load | Best For |
|---|---|---|---|
| 60–300s | Fast (minutes) | High | Active deployments, migrations, testing |
| 3600s | Medium (1 hour) | Medium | Most production records |
| 86400s | Slow (24 hours) | Low | Stable records (NS, MX, rarely changing A) |
The migration strategy: Before changing an IP address, lower the TTL to 300 seconds at least 24 hours in advance. This ensures old cached entries expire before you flip the IP. After the migration completes and is stable, raise the TTL back.
If you change an IP when the TTL is 86400, some users will hit the old IP for up to 24 hours — and you cannot speed it up retroactively.
Realistic Zone File
A complete zone file for example.com showing all record types together:
; Zone file for example.com
; Last updated: 2024-04-22
; Serial: 2024042201
$ORIGIN example.com.
$TTL 3600
; SOA — Start of Authority (required, must be first)
@ IN SOA ns1.example.com. admin.example.com. (
2024042201 ; serial
3600 ; refresh (1 hour)
900 ; retry (15 minutes)
604800 ; expire (7 days)
300 ; minimum TTL (5 minutes)
)
; NS — Authoritative nameservers (required)
@ 86400 IN NS ns1.example.com.
@ 86400 IN NS ns2.example.com.
; Glue records — A records for the nameservers themselves
ns1 86400 IN A 198.51.100.1
ns2 86400 IN A 198.51.100.2
; A records — Main site and subdomains
@ 3600 IN A 93.184.216.34 ; apex domain
www 3600 IN A 93.184.216.34
api 60 IN A 10.0.1.10 ; low TTL — changes often
api 60 IN A 10.0.1.11 ; round-robin load balancing
api 60 IN A 10.0.1.12
; AAAA records — IPv6
@ 3600 IN AAAA 2606:2800:220:1:248:1893:25c8:1946
www 3600 IN AAAA 2606:2800:220:1:248:1893:25c8:1946
; CNAME records — Aliases
static 3600 IN CNAME example.cloudfront.net. ; CDN for static assets
docs 3600 IN CNAME example.github.io. ; GitHub Pages docs site
blog 3600 IN CNAME example.wpengine.com. ; WordPress hosting
; MX records — Mail
@ 3600 IN MX 10 mail1.example.com. ; primary mail server
@ 3600 IN MX 20 mail2.example.com. ; secondary (failover)
@ 3600 IN MX 50 smtp-relay.sendgrid.net. ; emergency backup relay
; A records for mail servers
mail1 3600 IN A 203.0.113.10
mail2 3600 IN A 203.0.113.11
; TXT records — Email authentication and verification
@ 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
@ 3600 IN TXT "google-site-verification=abc123def456"
@ 3600 IN TXT "MS=ms98765432"
google._domainkey 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w..."
_dmarc 3600 IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com"
; SRV records — Service discovery
_sip._tcp 3600 IN SRV 10 20 5060 sip.example.com.
_xmpp-client._tcp 3600 IN SRV 5 0 5222 xmpp.example.com.
sip 3600 IN A 203.0.113.20
xmpp 3600 IN A 203.0.113.21Querying Records with dig
dig (Domain Information Groper) is the command-line tool for querying DNS records. Every backend engineer should be comfortable with it.
# Basic A record lookup
dig example.com
# Specify record type explicitly
dig A example.com
dig AAAA example.com
dig CNAME www.example.com
dig MX example.com
dig NS example.com
dig TXT example.com
dig SOA example.com
dig SRV _sip._tcp.example.com
# Reverse DNS (PTR)
dig -x 93.184.216.34
# Query a specific nameserver (bypass your local resolver)
dig @8.8.8.8 example.com # query Google's resolver
dig @ns1.example.com example.com # query the authoritative nameserver directly
# Short output — just the answer section
dig +short example.com
dig +short MX example.com
# Trace the full resolution chain (root → TLD → authoritative)
dig +trace example.com
# Show TTL values clearly
dig +noall +answer example.com
# Query all records (not all types — just returns what the server volunteers)
dig ANY example.comReading dig output:
; <<>> DiG 9.18.1 <<>> A example.com
;; ANSWER SECTION:
example.com. 3600 IN A 93.184.216.34
^TTL ^Type ^ValueThe columns are: name, TTL (seconds remaining), class (always IN = Internet), type, value.
Common Mistakes
Mistake 1 — Using CNAME at the apex domain
Putting a CNAME at example.com. (no subdomain prefix) is a DNS protocol violation. DNS forbids it because the apex must also have NS and SOA records, and RFC 1034 states that a CNAME record cannot coexist with any other record type for the same name. The zone will appear to work in some tools but will fail unpredictably in others. If you need to alias your root domain to a hostname (common with Heroku, Netlify, Render), use your DNS provider's ALIAS or ANAME record, or Cloudflare's CNAME flattening. Alternatively, put the real A record at the apex and CNAME the www to it — not the reverse.
Mistake 2 — Leaving TTL too high before a planned IP migration
If your A record has a TTL of 86400 (24 hours) and you change the IP, users with cached entries will hit the old IP for up to 24 hours. You cannot fix this retroactively — the TTL already propagated. The correct procedure: 24+ hours before the migration, lower the TTL to 300 seconds and wait for the old high-TTL entries to expire. Make the IP change. After confirming stability, raise the TTL back. Skipping this step is one of the most common causes of prolonged downtime during deployments.
Mistake 3 — Forgetting MX records when setting up a custom domain email
When you add a custom domain to Google Workspace, Microsoft 365, or any email provider, you must add MX records pointing to that provider's mail servers. Without MX records, DNS defaults to delivering mail to... nowhere. Email to user@yourcustomdomain.com will silently bounce. The failure is often not obvious because the bounce may be logged on the sending server, not the receiving end. Always verify MX records are in place before announcing a new custom-domain email address, and test by sending a message from an external account.
Interview Questions
Q1: What is the difference between an A record and a CNAME record?
An A record maps a domain name directly to an IPv4 address. A CNAME maps a domain name to another domain name — it is an alias. When a resolver follows a CNAME, it then looks up the A record for the target hostname. The key tradeoff: A records are one hop and always resolve to an IP, while CNAME records are flexible aliases — useful when a service gives you a hostname rather than a stable IP (CDNs, cloud providers). The important restriction is that CNAME records cannot coexist with other record types for the same name, which is why they cannot be used at the apex domain.
Q2: Why can't you use a CNAME at the root/apex domain?
RFC 1034 forbids it. Every DNS zone must have NS and SOA records at the apex (the bare domain with no subdomain). A CNAME record cannot coexist with any other record type for the same name — that is a DNS protocol constraint, not an arbitrary restriction. Since NS and SOA are required at the apex, a CNAME there would violate the spec. Cloud DNS providers work around this with proprietary ALIAS or ANAME record types that behave like CNAMEs conceptually but are resolved server-side (the nameserver resolves the target hostname itself and returns the resulting IP as if it were an A record).
Q3: What are MX records and what does the priority number mean?
MX (Mail Exchanger) records identify the mail server responsible for receiving email on behalf of a domain. When a sending mail server wants to deliver an email to user@example.com, it queries the MX records for example.com and connects to the server listed. The priority number controls the order of preference — a lower number means higher priority. The sending server always tries the lowest priority (highest preference) server first. If that server is unreachable, it tries the next lowest, and so on. Multiple MX records with different priorities provide mail delivery redundancy automatically, with no active load balancer required.
Q4: What are TXT records used for?
TXT records store arbitrary text data associated with a domain. In practice they are used almost exclusively for three things: email authentication and security (SPF declares which servers may send email as your domain; DKIM holds the public key to verify email signatures; DMARC defines the policy for handling failures), domain ownership verification (services like Google Search Console, AWS, GitHub, and Microsoft 365 ask you to add a specific TXT record to prove you control the domain), and occasionally application-specific configuration (some services publish metadata or API keys in TXT records).
Q5: What is reverse DNS (PTR record) and why does it matter for email?
Reverse DNS is the mapping from an IP address to a domain name, stored as PTR records in the in-addr.arpa zone (for IPv4). Forward DNS maps name → IP; reverse DNS maps IP → name. For email, receiving mail servers perform a reverse DNS lookup on the connecting IP to verify that it resolves to a hostname matching the sending domain. If your mail server at 93.184.216.34 claims to be mail.example.com, the receiving server checks that 93.184.216.34 resolves to mail.example.com via PTR. A missing or mismatched PTR record is a strong spam signal — many mail servers will reject or heavily penalize email from IPs without proper reverse DNS. PTR records are controlled by the IP address owner (your hosting provider or ISP), not your domain registrar.
Quick Reference — Cheat Sheet
| Record | Maps | Example Value | Common Use |
|---|---|---|---|
| A | Domain → IPv4 | 93.184.216.34 | Primary web server, any IPv4 host |
| AAAA | Domain → IPv6 | 2606:2800:220:1::1946 | IPv6-enabled hosts, dual-stack sites |
| CNAME | Domain → Domain | example.cloudfront.net. | CDN aliases, subdomains pointing to hosted services |
| MX | Domain → Mail host + priority | 10 mail.example.com. | Email delivery routing and failover |
| NS | Domain → Nameserver | ns1.example.com. | Declaring authoritative nameservers |
| TXT | Domain → Text string | "v=spf1 include:... ~all" | SPF, DKIM, DMARC, domain verification |
| SOA | Domain → Zone metadata | ns1 admin serial refresh... | Zone administration (auto-managed) |
| PTR | IP → Domain | example.com. | Reverse DNS, email sender verification |
| SRV | Service → Host + port | 10 20 5060 sip.example.com. | VoIP (SIP), XMPP, service discovery |
Key rules to remember:
- CNAME cannot coexist with other record types for the same name — especially forbidden at the apex domain
- MX values must be hostnames, not IP addresses, and not CNAMEs
- NS values must be hostnames with their own A/AAAA records (glue records)
- Lower MX priority number = higher preference
- Lower TTL = faster propagation but more DNS queries (more load on your nameserver)
- PTR records are managed by the IP owner (hosting provider), not the domain registrar
dig quick reference:
dig A example.com # IPv4 address
dig AAAA example.com # IPv6 address
dig CNAME www.example.com # alias target
dig MX example.com # mail servers
dig TXT example.com # text records (SPF, verification)
dig NS example.com # nameservers
dig SOA example.com # zone metadata
dig -x 93.184.216.34 # reverse lookup (PTR)
dig +trace example.com # full resolution chain
dig +short example.com # answer only, no decorationPrevious: Lesson 6.2 — DNS Resolution → Next: Lesson 6.4 — DNS in Practice →
This is Lesson 6.3 of the Networking Interview Prep Course — 8 chapters, 32 lessons.