DNS is something most sysadmins interact with constantly without necessarily understanding the full picture. Setting up an A record and MX record is easy enough, but when things break or you need to configure something more complex, knowing what each record type does and how it works becomes important.
Here’s the DNS record types I actually use, with practical context for each.
A and AAAA Records
A record — maps a hostname to an IPv4 address.
example.com. 3600 IN A 93.184.216.34
www.example.com. 3600 IN A 93.184.216.34AAAA record — same but for IPv6.
example.com. 3600 IN AAAA 2606:2800:220:1:248:1893:25c8:1946These are the most fundamental DNS records. If you can’t reach a server, A/AAAA record problems are the first thing to check.
Check from command line:
dig example.com A
dig example.com AAAA
# or using host
host example.comThe TTL (3600 in the examples above) is in seconds — 3600 = 1 hour. During a migration, lower TTLs to 300 or 60 so changes propagate quickly. Restore to 3600 after the migration.
CNAME Records
CNAME creates an alias. Instead of pointing to an IP, it points to another hostname.
www.example.com. 3600 IN CNAME example.com.
blog.example.com. 3600 IN CNAME myblog.wordpress.com.The critical rule: never use CNAME at the apex (root) domain. example.com cannot be a CNAME — only subdomains can. This is a common source of confusion. The apex must use A/AAAA records (or the non-standard ALIAS/ANAME records some DNS providers support).
CNAME resolution can add latency because it requires multiple lookups: resolve the CNAME, then resolve what it points to. For high-traffic services, A records pointing directly to IPs are faster.
MX Records
Mail exchanger records direct email for a domain:
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.The number (10, 20) is priority — lower is preferred. If mail1 is unavailable, senders try mail2. Having two MX records with different priorities is standard for redundancy.
Don’t mix CNAME with MX targets. The MX record value must be a hostname with an A/AAAA record, not itself a CNAME.
TXT Records
Text records store arbitrary string data. Originally for human-readable information, now heavily used for:
SPF (Sender Policy Framework) — specifies which mail servers can send email for your domain:
example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all"DKIM (DomainKeys Identified Mail) — stores the public key for email signature verification:
mail._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."DMARC — policy for handling emails that fail SPF/DKIM:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"Domain verification — Google Search Console, various SaaS services ask you to add a TXT record to prove domain ownership:
example.com. 3600 IN TXT "google-site-verification=abc123..."Let’s Encrypt DNS challenge — temporary record for domain validation:
_acme-challenge.example.com. 60 IN TXT "randomvalue..."NS Records
Name server records specify which DNS servers are authoritative for a domain:
example.com. 3600 IN NS ns1.example.com.
example.com. 3600 IN NS ns2.example.com.These are set at your domain registrar. When you delegate a subdomain to a different DNS provider or nameserver, you add NS records for that subdomain.
Changing NS records is a major operation — propagation can take 24–48 hours globally. Lower the TTL well in advance if possible.
SOA Record
Start of Authority — contains administrative information about a DNS zone:
example.com. 3600 IN SOA ns1.example.com. admin.example.com. (
2024011501 ; Serial
3600 ; Refresh
900 ; Retry
604800 ; Expire
300 ; Minimum TTL
)The serial number should increment every time the zone is updated (convention is YYYYMMDDNN format). DNS secondaries use this to know when to pull zone updates.
Most managed DNS providers handle SOA automatically. You only deal with it directly when running your own BIND nameservers.
PTR Records
Reverse DNS — maps an IP address back to a hostname.
34.216.184.93.in-addr.arpa. 3600 IN PTR example.com.PTR records live in a special zone owned by whoever owns the IP block — usually your hosting provider or ISP. You configure them through your hosting provider’s control panel, not your domain registrar.
PTR records matter for email delivery. Many mail servers check that the sending IP’s PTR record matches the hostname in the HELO/EHLO, and reject or penalize mail where it doesn’t.
Check PTR:
dig -x 93.184.216.34
# or
host 93.184.216.34SRV Records
Service location records — specify the hostname and port for a specific service:
_sip._tcp.example.com. 3600 IN SRV 10 20 5060 sipserver.example.com.
_xmpp-server._tcp.example.com. 3600 IN SRV 5 0 5269 xmpp.example.com.Format: _service._protocol TTL IN SRV priority weight port target
Applications that support SRV records discover the correct server and port automatically. Kubernetes and other service discovery systems use SRV records internally. For most web applications you don’t use SRV directly, but it’s important for VoIP, messaging protocols, and some database clients.
CAA Records
Certification Authority Authorization — controls which CAs can issue certificates for your domain:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"Setting this is a good security practice. If an attacker tries to fraudulently obtain a certificate from a different CA, the CA should check your CAA records and refuse. The DNS CAA records guide covers this in detail.
Checking DNS Propagation
When you make changes, check propagation from different locations:
# Check from specific DNS servers
dig @8.8.8.8 example.com A # Google DNS
dig @1.1.1.1 example.com A # Cloudflare DNS
dig @9.9.9.9 example.com A # Quad9 DNS
# Check TTL of a record (to know when changes will propagate)
dig +ttl example.com AOnline tools like dnschecker.org check from multiple global locations simultaneously.
Common DNS Debugging Workflow
When something isn’t working:
# 1. Check what your local resolver thinks
nslookup example.com
# 2. Check the authoritative nameservers directly
dig +authority example.com NS
dig @ns1.example.com example.com A
# 3. Check for propagation issues
dig @8.8.8.8 example.com A
# 4. Trace the full resolution path
dig +trace example.com A
# 5. Check for DNSSEC issues
dig example.com A +dnssecMost DNS problems are one of: wrong record type, CNAME at apex, TTL cached the old value, or the change was made to the wrong zone. dig +trace is the most powerful diagnostic — it follows the full delegation chain from root servers down.
TTL Strategy
Short TTLs (60–300 seconds) mean faster propagation for changes but more DNS queries to your nameservers. Long TTLs (3600–86400 seconds) reduce DNS query volume but slow down changes.
My approach: keep TTLs at 3600 normally. Before any planned change (migration, IP change), lower TTL to 300 or 60 a few hours before. Make the change. Wait for the old TTL to expire. Raise TTL back to 3600.
During incidents, having a short TTL means you can redirect traffic within minutes. With a 24-hour TTL, you’re stuck for up to 24 hours after making a change.