What DNS Records Actually Do
DNS records are the individual entries inside a zone file that tell resolvers how to handle requests for your domain. When someone types opscheck.tech into a browser, a chain of lookups begins — and each lookup returns a specific record type. Getting these records wrong is one of the most common causes of unexplained downtime, failed email delivery, and broken SSL certificates.
You can inspect any domain's records instantly with the OpsCheck DNS Lookup tool, which queries multiple record types in a single request. But understanding what each result means is a different skill. Here is the practical breakdown.
A Records: The Foundation
An A record maps a hostname to an IPv4 address. This is the most fundamental DNS record — without it, nobody reaches your server.
# Look up the A record for a domain
dig example.com A +short
93.184.215.14
# Query a specific nameserver
dig @ns1.example.com example.com A +short
Every public-facing hostname needs an A record or one of its alternatives. The value is always a dotted-quad IPv4 address. Multiple A records for the same name create round-robin load balancing — resolvers rotate through the list, spreading traffic across servers without any extra hardware.
Common failure mode: setting an A record to a private IP like 192.168.1.10. Your internal users might reach it, but the public internet routes that address to nowhere. Always verify with a tool like OpsCheck DNS Lookup that queries from an external resolver, not your local network.
AAAA Records: The IPv6 Counterpart
AAAA records work identically to A records but hold 128-bit IPv6 addresses. They use the same query mechanism — the difference is entirely in the address format returned.
# Look up the AAAA record
dig example.com AAAA +short
2606:2800:21f:cb07:6820:80da:af6b:8b2c
# Check if a domain has IPv6 at all
dig example.com AAAA | grep -c "ANSWER SECTION"
Many sites still run IPv4-only, but major providers increasingly require dual-stack configuration. If your users report timeouts from IPv6-only networks (common on mobile carriers and some ISPs), check that your AAAA records point to a server that actually listens on IPv6. A missing or misconfigured AAAA record paired with a working A record causes long fallback delays, not hard failures — which makes it painful to diagnose.
CNAME Records: Aliases, Not Redirects
A CNAME maps one name to another canonical name. The resolver then looks up the target name and returns its A or AAAA record. This is not an HTTP redirect — the browser never sees the CNAME; it happens entirely at the DNS level.
# Check what a CNAME points to
dig www.example.com CNAME +short
example.com.
# Trace the full resolution chain
dig www.example.com CNAME +short
dig www.example.com A +short
Critical rule: a CNAME cannot coexist with any other record at the same name. If you set a CNAME on example.com, you cannot also have MX or TXT records at the apex. This is why the root domain (apex) rarely uses CNAMEs — it needs SOA and NS records at minimum. Some providers offer "ANAME" or "ALIAS" pseudo-records that work around this limitation at the authoritative level, but they are not standard DNS.
A common mistake: pointing a CNAME at another CNAME, creating a chain. Each hop adds latency as resolvers chase the chain. Most resolvers stop after 10-16 hops. Keep CNAME chains flat — one hop is ideal.
MX Records: Where Email Goes
MX (Mail Exchanger) records tell other mail servers where to deliver messages for your domain. Each MX record has a priority value — lower numbers are tried first.
# View MX records with priorities
dig example.com MX +short
10 mail1.example.com.
20 mail2.example.com.
# Check SMTP connectivity to the MX
nc -zv mail1.example.com 25
The priority field is not a "weight" for load balancing. The sending MTA tries servers in strict priority order — it only falls back to priority 20 if priority 10 is unreachable. If you want true load distribution, run multiple servers at the same priority level.
MX records must point to hostnames, never IP addresses. Pointing an MX record to a CNAME technically works but violates the RFC and causes delivery failures with stricter MTAs. Always use A or AAAA records as MX targets.
TXT Records: Arbitrary Text, Specific Uses
TXT records hold arbitrary text strings, but in practice they serve three main purposes: SPF (sender policy), DKIM keys, and domain verification tokens.
# Retrieve all TXT records
dig example.com TXT +short
# Query just SPF records
dig example.com TXT +short | grep spf
# Check DKIM selector
dig default._domainkey.example.com TXT +short
SPF records declare which servers may send mail for your domain. DKIM records publish public keys for verifying email signatures. DMARC ties them together with a policy. Google and Microsoft increasingly reject mail from domains without these records, so they are effectively mandatory now.
Verification tokens from services like Google Search Console or GitHub also live in TXT records. These are one-time proofs — you can remove them after verification, though many admins leave them in place indefinitely.
NS Records: Delegation
NS (Name Server) records tell resolvers which servers are authoritative for a domain. They appear both at the parent zone (your registrar) and inside the zone itself. Both sets must match.
# Find the authoritative nameservers
dig example.com NS +short
# Verify all NS agree on the zone serial
dig @ns1.example.com example.com SOA +short
dig @ns2.example.com example.com SOA +short
NS record mismatches between parent and child zones cause bizarre, intermittent resolution failures. Use OpsCheck DNS Propagation Checker to query multiple public resolvers and confirm every resolver sees the same NS set.
SOA Records: Zone Metadata
The SOA (Start of Authority) record contains administrative metadata: the primary nameserver, the admin contact email (with the at-sign replaced by a dot), and timing values that control zone transfers and caching.
# Full SOA output
dig example.com SOA
# Fields: MNAME RNAME SERIAL REFRESH RETRY EXPIRE MINIMUM
The serial number is the most operationally important field. Secondary nameservers compare the master's serial to their local copy. If the master's serial is higher, they request a zone transfer. If you decrement the serial by accident, secondaries will never pick up changes until the serial surpasses the old value. The YYYYMMDDNN format prevents this: 2026061101 means June 11, 2026, revision 01.
PTR Records: Reverse DNS
PTR records map IP addresses back to hostnames — the inverse of A and AAAA records. They live in special .arpa zones, not your regular zone file, and are usually managed by whoever owns the IP block (your hosting provider or ISP).
# Reverse lookup an IPv4 address
dig -x 93.184.215.14 +short
# Manual PTR query for IPv4
dig 14.215.184.93.in-addr.arpa PTR +short
Reverse DNS matters most for email delivery. Many mail servers check that the sending IP's PTR record resolves back to a hostname that matches the HELO/EHLO banner. Failed reverse DNS checks increase your spam score. Use the OpsCheck Reverse DNS Tool to verify your PTR records are correctly configured before troubleshooting mail delivery issues.
Troubleshooting Scenario: The Vanishing Subdomain
A user reports that app.example.com works from the office but not from home. You run a quick lookup:
$ dig app.example.com A +short
# No output — no A recordBut the user insists it works on the office network. You check with a trace:
$ dig app.example.com A +traceThe trace reveals that the office DNS server has a stale cached entry from before a recent migration, while public resolvers correctly return NXDOMAIN. The migration changed the subdomain from a direct A record to a CNAME pointing at a load balancer, but the old A record's TTL was set to 86400 (24 hours). Office users are still within the cache window.
Solution: reduce TTLs to 300 seconds at least 24 hours before any planned DNS change. After the change, use the OpsCheck DNS Propagation Checker to confirm that resolvers worldwide are returning the new records and the old ones have expired.
DNS is not complicated — it is just unforgiving. Test every change with real queries before you close the ticket.