Record Types
DNS carries far more than addresses. A zone is a set of resource records, each a tuple of name, type, TTL, and data, and the type field decides what the data means. A and AAAA hold addresses, CNAME aliases one name to another, MX routes mail, TXT holds free-form text used for verification and policy, SRV advertises a service's host and port, NS delegates, and PTR does the reverse lookup from address to name.
Knowing which record a job needs is half of operating DNS. The other half is knowing the rules that constrain them — chief among them that a CNAME cannot coexist with other records at the same name, which is why it is illegal at a zone apex. Get the record type wrong and the symptom is rarely a clean error; it is mail that silently bounces, a certificate that won't validate, or a name that resolves but to the wrong place.
Address Records: A and AAAA
The two address records are the workhorses. An A record maps a name to a 32-bit IPv4 address; an AAAA record (four A's, for four times the bits) maps it to a 128-bit IPv6 address. A single name can carry several of each — multiple A records for the same name is the simplest form of round-robin load distribution, the resolver handing clients different addresses in rotation.
A dual-stack name publishes both an A and an AAAA, and the client picks per its own preference — most modern clients try IPv6 first and fall back. The records are independent: an AAAA pointing at an address with no listening service produces a connection that hangs then retries on IPv4, a failure mode that looks like "the site is slow" rather than "DNS is wrong."
# a dual-stack name with round-robin IPv4 — name, TTL, class, type, data www 300 IN A 93.184.216.34 www 300 IN A 93.184.216.35 www 300 IN AAAA 2606:2800:220:1:248:1893:25c8:1946
Aliases: CNAME and the Apex Rule
A CNAME (canonical name) makes one name an alias for another: a lookup of the alias is restarted against the target. Point www.example.com at myapp.cdn-provider.net with a CNAME and you inherit whatever addresses the provider publishes, without ever copying their IPs into your zone. The catch is the defining rule: a name with a CNAME can have no other records — no MX, no TXT, nothing.
That rule is why a CNAME at the zone apex (the bare example.com) is illegal: the apex must carry SOA and NS records, and a CNAME cannot share a name with them. The workaround is a provider-specific ALIAS or ANAME record — not a real DNS type, but a server-side trick that resolves the target at query time and answers with its A/AAAA, so the apex behaves like an alias while still publishing real address records.
Mail and Policy: MX and TXT
An MX record names the mail server for a domain and a preference number — lower is tried first, equal values share load. The MX target must be a hostname with its own A/AAAA, not an IP and not a CNAME; pointing an MX at a CNAME is forbidden by the spec and rejected by strict mail servers. The domain in an email address is resolved via MX, which is why example.com can receive mail on entirely different servers than its website.
TXT records hold arbitrary text, and mail authentication has colonized them. SPF lists which servers may send for your domain, DKIM publishes a public key to verify signatures, and DMARC ties the two together with a policy. A missing or wrong SPF TXT record is the most common reason legitimate mail lands in spam — the receiver can't confirm the sender is authorized.
Service and Reverse: SRV, NS, and PTR
An SRV record advertises where a named service runs, carrying priority, weight, port, and target host — so a client can discover that _sip._tcp.example.com lives on a specific host and port without that being hardcoded. NS records, covered in the namespace topic, delegate a zone to its authoritative servers and appear both at the apex and at any delegation point.
PTR records run DNS backwards: they map an address to a name, living in the special in-addr.arpa (IPv4) and ip6.arpa (IPv6) zones. The big consumer is mail — receiving servers do a reverse lookup on the connecting IP and distrust or reject senders whose PTR is missing or doesn't match, so a mail server with no PTR sees its delivery rate collapse.
A maps a name directly to an IP address and can sit anywhere, including the apex. Use it when you control the address or want round-robin across several. It is the only one of the three that publishes a real address from your own zone.
CNAME aliases a name to another name and inherits its addresses, but forbids any other record at the same name — so it works for subdomains like www but is illegal at the apex. Use it to point at a provider's hostname.
ALIAS / ANAME is a provider-side flattening trick that lets the apex behave like a CNAME: the server resolves the target and answers with its A/AAAA. Use it when you must alias the bare domain to a provider hostname.
- Putting a CNAME at the zone apex. The apex already carries SOA and NS records and a CNAME cannot coexist with them, so the zone is rejected or breaks — use an ALIAS/ANAME or address flattening instead.
- Pointing an MX record at a CNAME. The spec forbids it and strict receivers reject it, causing intermittent mail failures that depend on which server is delivering — point MX at a hostname with its own A/AAAA.
- Omitting a PTR record for a sending mail server. Receivers reverse-lookup the connecting IP and downgrade or reject senders with no matching PTR, so your outbound mail quietly lands in spam or bounces.
- Chaining CNAMEs several deep. Each hop is a separate restarted lookup, so a CNAME pointing to a CNAME pointing to a CNAME adds round trips and latency to every resolution and multiplies the chance one link breaks.
- Treating a wrong or missing SPF TXT record as harmless. Without it, receivers cannot confirm your servers are authorized to send, and legitimate mail is filtered to spam even though DNS "resolves fine."
- Use an ALIAS/ANAME record (or a provider that flattens) for the apex domain, and reserve plain CNAME for subdomains where no other record needs to coexist.
- Point every MX record at a hostname that has its own A/AAAA record, never at a CNAME or a bare IP, so strict mail servers accept the delivery path.
- Publish a PTR record matching the forward name for any IP that sends mail, so receiving servers' reverse-lookup checks pass and your mail is trusted.
- Keep CNAME chains to a single hop, pointing the alias straight at the final target, so resolution stays fast and one broken link cannot cascade.
- Publish SPF, DKIM, and DMARC as TXT records together when you set up sending, so receivers can authenticate the source and you are not debugging spam-foldering after launch.
Knowledge Check
You need the bare domain example.com to point at a CDN's hostname. A plain CNAME at the apex is rejected. Why, and what do you use?
- The apex carries SOA and NS, which a CNAME cannot share — use an ALIAS/ANAME instead
- The apex is too slow to resolve a CNAME, so an A record is required
- CNAMEs are not allowed to point at other CNAMEs at all, so the chain to the CDN provider fails outright
- The apex only accepts IPv4, so the CDN's IPv6 CNAME is refused
A domain's website works but inbound mail intermittently bounces from some senders. Which record is the prime suspect?
- An MX record pointing at a CNAME, which strict receivers reject
- The A record for the website, which also controls mail routing
- The NS record, since zone delegation is what governs where a domain's mail gets delivered
- The PTR record, because inbound mail needs a reverse lookup
Your mail server's outbound delivery rate is poor and receivers cite reverse-lookup failures. Which record fixes it?
- A PTR record mapping the sending IP back to its name
- An MX record, since it defines the server that sends mail
- A second A record so the server has a backup address
- A CNAME aliasing the mail name to the reverse zone
You got correct