DNS Record Types
debt(d3/e3/b5/t5)
Closest to 'default linter catches the common case' (d3). The term's detection_hints.tools list includes dig, dnschecker, mxtoolbox, and mail-tester — all readily available DNS checking tools that catch common misconfigurations like missing SPF/DKIM/DMARC or CNAME-at-apex issues. These aren't specialist SAST tools but standard operational tools that most teams use during deployment.
Closest to 'simple parameterised fix' (e3). The quick_fix indicates adding CAA, SPF, DKIM, DMARC records — each is a single DNS record addition/modification. However, fixing mistakes like CNAME-at-apex requires understanding your hosting setup and may involve coordinating with DNS provider (ALIAS/ANAME support varies). Not a one-line patch but not a major refactor either.
Closest to 'persistent productivity tax' (b5). DNS record types apply to web contexts per applies_to, affecting email delivery, domain resolution, and certificate issuance. Incorrect choices create ongoing issues: emails land in spam (missing SPF/DKIM), root domain fails to resolve (CNAME at apex), or certificate renewals fail (CAA restrictions). The tax persists until fixed and affects multiple work streams (ops, security, email).
Closest to 'notable trap' (t5). The misconception field explicitly states the trap: 'A CNAME at the domain apex (@) is valid' — this contradicts intuition since CNAME works everywhere else. Common_mistakes reinforce this with MX-pointing-to-CNAME and forgetting CAA records. These are documented gotchas that developers eventually learn, but initially guess wrong about.
Also Known As
TL;DR
Explanation
Key record types: A (domain → IPv4 address), AAAA (domain → IPv6 address), CNAME (alias → another domain name, cannot coexist with other records at apex), MX (mail server + priority), TXT (arbitrary text — SPF, DKIM, domain verification), SRV (service location with port and protocol), NS (authoritative nameservers), SOA (zone authority), CAA (which CAs may issue certificates). ALIAS/ANAME records (provider-specific) solve the CNAME-at-apex limitation for load balancers. TTL controls caching duration.
Diagram
flowchart TD
DOMAIN[example.com] --> TYPES{DNS Record Types}
TYPES -->|A| A_REC[A Record<br/>domain to IPv4<br/>93.184.216.34]
TYPES -->|AAAA| AAAA_REC[AAAA Record<br/>domain to IPv6]
TYPES -->|CNAME| CNAME_REC[CNAME<br/>alias to another domain<br/>NOT at apex]
TYPES -->|MX| MX_REC[MX Record<br/>mail server + priority]
TYPES -->|TXT| TXT_REC[TXT Record<br/>SPF DKIM verification]
TYPES -->|NS| NS_REC[NS Record<br/>authoritative nameservers]
subgraph Common_Mistakes
APEX[CNAME at apex invalid<br/>use ALIAS or A record]
MX_C[MX pointing to CNAME<br/>RFC violation]
end
style A_REC fill:#238636,color:#fff
style MX_REC fill:#1f6feb,color:#fff
style TXT_REC fill:#d29922,color:#fff
style APEX fill:#f85149,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- CNAME at the apex — use ALIAS/ANAME or A records for the root domain.
- MX record pointing to a CNAME — MX must point directly to an A record, not a CNAME.
- Forgetting CAA records — without CAA, any CA can issue certificates for your domain.
- TTL too high before a planned change — set TTL to 300 (5 min) days before the change, not minutes before.
Code Examples
# Invalid CNAME at apex — breaks entire domain:
example.com. IN CNAME myapp.elb.amazonaws.com.
# This is invalid — CNAME at apex prevents SOA and NS records
# Result: entire domain stops resolving
# MX pointing to CNAME — RFC violation:
example.com. IN MX 10 mail.example.com.
mail.example.com. IN CNAME alias.mailprovider.com. # Invalid!# Correct record usage:
# Apex: use A record or ALIAS (Route 53):
example.com. IN ALIAS myapp.elb.amazonaws.com. # Route 53 ALIAS
# Subdomain: CNAME is fine:
www.example.com. IN CNAME myapp.elb.amazonaws.com.
# MX with direct A record:
example.com. IN MX 10 mail.sendgrid.net. # Points directly, no CNAME chain
# TXT for SPF + domain verification:
example.com. IN TXT 'v=spf1 include:sendgrid.net ~all'
example.com. IN TXT 'google-site-verification=abc123'