What DNS Records Are and Why They Exist
The Domain Name System is a hierarchical, distributed database that maps human-readable names to machine-readable data. At the heart of this system are resource records (RRs) — structured data entries stored in zone files on authoritative name servers. Each record type serves a specific purpose, and understanding what each one does — and how it interacts with others — is fundamental to anyone managing production infrastructure.
This article covers the six most operationally critical DNS record types: A, AAAA, CNAME, MX, TXT, and PTR. We examine each type's wire format, resolution mechanics, failure modes, and how it fits into real infrastructure environments built around solvethenetwork.com.
How DNS Resolution Works
Before examining individual record types, it is worth anchoring the mechanics that all record types share. When a stub resolver on a client machine queries a name, the request travels to a recursive resolver, which follows a chain: root servers → TLD authoritative servers → domain authoritative servers. The authoritative server holds the zone file containing the actual records. The recursive resolver caches the response according to the record's TTL (Time to Live), expressed in seconds, and returns it to the client.
A DNS query contains a QTYPE field specifying which record type is requested. Common QTYPE values include A (1), AAAA (28), CNAME (5), MX (15), TXT (16), and PTR (12). The authoritative server returns matching records in the answer section, or signals NXDOMAIN (the name does not exist) or NOERROR with an empty answer section (the name exists but has no records of the requested type).
; Query specific record types using dig
dig A mail.solvethenetwork.com
dig AAAA mail.solvethenetwork.com
dig MX solvethenetwork.com
dig TXT solvethenetwork.com
dig PTR 30.10.168.192.in-addr.arpa
dig CNAME www.solvethenetwork.com
; Show the full resolution chain with +trace
dig +trace A www.solvethenetwork.comA Record — IPv4 Address Mapping
What It Is
The A record (Address record) is the most fundamental DNS record type. It maps a fully qualified domain name (FQDN) to a 32-bit IPv4 address. Defined in RFC 1035, it is the backbone of forward DNS lookups for all IPv4-addressed infrastructure. Without A records, virtually no service reachable by hostname over IPv4 would function.
How It Works
An A record contains exactly one IPv4 address in dotted-decimal notation. A zone can contain multiple A records for the same name — this is the basis of round-robin DNS load distribution. Resolvers return all matching records in the answer section, and clients cycle through them on successive connections. The TTL on each A record controls how long downstream resolvers and clients cache the response before querying again.
; Zone file entries for solvethenetwork.com
$ORIGIN solvethenetwork.com.
$TTL 300
; Web servers — round-robin across three hosts
www IN A 192.168.10.20
www IN A 192.168.10.21
www IN A 192.168.10.22
; Dedicated mail server
mail1 IN A 192.168.10.30
; Internal management switch
sw-infrarunbook-01 IN A 10.10.1.50Why It Matters
Every IPv4-addressed service reachable by name depends on A records: web servers, mail servers, VPN endpoints, monitoring systems, internal dashboards, and NTP sources. TTL tuning on A records directly controls failover speed. A low TTL (60–300 seconds) enables faster DNS-based failover at the cost of increased query volume on your authoritative servers. A high TTL (3600–86400 seconds) reduces resolver load but extends the window during which clients cache a stale, failed address.
Real-World Example
The internal operations dashboard for solvethenetwork.com runs on three application servers. The A records carry a 60-second TTL. When sw-infrarunbook-01 detects that 192.168.10.21 has failed its health check, the NOC removes that A record from the zone. Within 60 seconds, all clients re-resolve and stop sending traffic to the dead host — without touching load balancer configuration or routing tables.
; Short TTL for fast failover
dashboard 60 IN A 192.168.10.20
dashboard 60 IN A 192.168.10.21
dashboard 60 IN A 192.168.10.22AAAA Record — IPv6 Address Mapping
What It Is
The AAAA record (commonly called the quad-A record) maps an FQDN to a 128-bit IPv6 address. Defined in RFC 3596, it is the IPv6 equivalent of the A record. The name quad-A reflects the fact that an IPv6 address is four times the bit-length of an IPv4 address.
How It Works
AAAA records follow identical mechanics to A records but carry 128-bit addresses in colon-separated hexadecimal notation. Dual-stack hosts should have both A and AAAA records published. Clients with IPv6 connectivity will prefer AAAA lookups per RFC 6724 address selection rules and the Happy Eyeballs algorithm (RFC 8305), which races IPv4 and IPv6 connections simultaneously and commits to whichever establishes first — typically the IPv6 connection on well-provisioned networks.
; Dual-stack configuration for solvethenetwork.com
www IN A 192.168.10.20
www IN AAAA 2001:db8:abcd:0012::20
mail1 IN A 192.168.10.30
mail1 IN AAAA 2001:db8:abcd:0012::30
sw-infrarunbook-01 IN A 10.10.1.50
sw-infrarunbook-01 IN AAAA 2001:db8:abcd:0001::50Why It Matters
IPv6 adoption is no longer optional for organizations that handle traffic from mobile carriers or ISPs running carrier-grade NAT (CGNAT) on IPv4. Without AAAA records, IPv6-native or IPv6-preferred clients must fall back to IPv4, introducing latency and dependency on NAT64 gateways outside your control. AAAA records are also a prerequisite for DNSSEC-secured dual-stack deployments and for passing certain third-party security audits that evaluate IPv6 readiness.
CNAME Record — Canonical Name Aliasing
What It Is
The CNAME (Canonical Name) record creates a DNS alias from one name to another. Rather than pointing directly to an IP address, it points to a hostname — the canonical name — which must itself ultimately resolve to an A or AAAA record through further DNS lookups. Defined in RFC 1035.
How It Works
When a resolver encounters a CNAME in the answer section, it follows the chain: it takes the CNAME target and issues a new lookup for the originally requested record type on that target hostname. This process continues until the chain terminates in an A or AAAA record (or fails with NXDOMAIN or SERVFAIL). The resolver returns the full CNAME chain plus the final address records in the answer section. Most resolvers enforce a maximum chain depth of eight hops to prevent infinite loops.
; CNAME aliasing — www resolves through app-cluster
www IN CNAME app-cluster.solvethenetwork.com.
app-cluster IN A 192.168.10.20
app-cluster IN A 192.168.10.21
; Service aliases pointing to canonical hostnames
ftp IN CNAME files.solvethenetwork.com.
docs IN CNAME confluence.solvethenetwork.com.
status IN CNAME statuspage.solvethenetwork.com.Why It Matters
CNAMEs decouple service names from infrastructure hostnames. When the underlying IP changes — because of a server migration, cloud provider change, or infrastructure refresh — only the A record at the canonical name requires updating. All CNAME aliases automatically resolve to the new address without individual updates. This is especially valuable in cloud-native environments where infrastructure is ephemeral and IP addresses change frequently.
Critical Restrictions
CNAME records carry constraints that are among the most common sources of DNS misconfigurations:
- A CNAME cannot coexist with any other record type at the same owner name (with the exception of DNSSEC RRSIG and NSEC records). This is why a CNAME cannot be placed at the zone apex.
- MX and NS records must not point to a CNAME — their targets must resolve directly via A or AAAA records. RFC 2181 is explicit on this point.
- CNAME chains longer than eight hops are rejected by most resolvers as protection against loops.
; INVALID — CNAME at zone apex conflicts with required SOA and NS records
solvethenetwork.com. IN CNAME other.solvethenetwork.com. ; PROHIBITED
; VALID — CNAME on a non-apex subdomain
shop IN CNAME storefront.solvethenetwork.com. ; CORRECT
api IN CNAME gateway.solvethenetwork.com. ; CORRECTMX Record — Mail Exchange
What It Is
The MX (Mail Exchanger) record specifies which mail servers are responsible for accepting inbound SMTP connections for a domain. Defined in RFC 1035 and clarified by RFC 2181, MX records include a numeric priority value that governs delivery order when multiple MX records exist for the same domain.
How It Works
An MX record carries two data fields: a priority (preference) value and an FQDN of the mail server. Lower priority numbers indicate higher preference — the sending MTA tries the lowest-numbered entry first. Equal-priority MX records are tried in random order, providing basic load distribution across equivalent servers. If the highest-priority server is unreachable after retry attempts, the sender falls back to the next-highest-priority entry.
; MX configuration for solvethenetwork.com
; Primary mail servers — equal priority, load-distributed
solvethenetwork.com. IN MX 10 mail1.solvethenetwork.com.
solvethenetwork.com. IN MX 10 mail2.solvethenetwork.com.
; Backup MX in secondary site — lower priority
solvethenetwork.com. IN MX 20 mail-backup.solvethenetwork.com.
; A records for MX targets (mandatory — no CNAME allowed)
mail1 IN A 192.168.10.30
mail2 IN A 192.168.10.31
mail-backup IN A 10.20.1.15Why It Matters
Incorrect MX configuration is among the most common causes of complete mail delivery failure. MX record targets must resolve directly via A or AAAA records — RFC 2181 explicitly prohibits MX targets from being CNAMEs, and compliant MTAs will refuse to deliver to such configurations. MX targets must also have valid PTR records, as many receiving mail servers reject SMTP connections from hosts that lack reverse DNS or where the PTR hostname does not forward-resolve back to the connecting IP.
TXT Record — Arbitrary Text Data
What It Is
The TXT (Text) record stores arbitrary text data associated with a domain name. Originally defined in RFC 1035 for general human-readable annotation, TXT records have evolved into the de facto mechanism for email authentication policies, domain ownership verification, and service discovery hints.
How It Works
A TXT record can contain one or more character strings, each up to 255 bytes. Multiple strings within a single TXT record are concatenated by resolvers. A single domain name can carry multiple TXT records simultaneously — all are returned in the answer section. The content is structurally uninterpreted by DNS itself; meaning and format are defined entirely by the consuming application layer.
; TXT records for solvethenetwork.com
; SPF — defines authorized mail senders
solvethenetwork.com. IN TXT "v=spf1 ip4:192.168.10.0/24 ip4:10.10.0.0/16 ~all"
; DMARC policy — aggregate reports to admin mailbox
_dmarc.solvethenetwork.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:infrarunbook-admin@solvethenetwork.com; pct=100; adkim=s; aspf=s"
; DKIM public key — selector: mail2024
mail2024._domainkey.solvethenetwork.com. IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
"7nK9pLmQ3vX8wR1tF6sN4bJ0cD5eA7gH2iK8lM9oP6rS1uT3vW4xY5z"
"A8bC7dE6fG5hH4iJ3kL2mN1oP0qR9sT8uV7wX6yZ5aB4cD3eF2gH1iJ"
)
; Domain control validation token for certificate issuance
solvethenetwork.com. IN TXT "google-site-verification=Xk9mN3pQ7rT2vW5yA8bC1dE4fG6hJ0kL"Why It Matters
TXT records underpin modern email security. SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) all publish their policies and cryptographic keys through TXT records. Misconfigured or absent TXT records are a primary cause of mail delivery failures, spam classification, and successful phishing campaigns that spoof your domain. Beyond email, TXT records are used for domain control validation during certificate issuance via the ACME protocol, and as a mechanism for zero-downtime service migrations where clients read configuration hints from DNS.
Operational note: Individual TXT strings are bounded at 255 bytes. Large DKIM public keys (2048-bit RSA) exceed this limit and must be split across multiple concatenated strings within a single TXT record. Failure to split correctly causes the key to be unparseable and DKIM verification to fail silently.
PTR Record — Reverse DNS Lookup
What It Is
The PTR (Pointer) record maps an IP address back to a hostname — the reverse of what A and AAAA records accomplish. PTR records live in special reverse lookup zones:
in-addr.arpafor IPv4 and
ip6.arpafor IPv6. Defined in RFC 1035.
How It Works
For IPv4, the address octets are reversed and appended with
.in-addr.arpa.The PTR record for 192.168.10.30 therefore lives at the name
30.10.168.192.in-addr.arpa.The reverse zone for the 192.168.10.0/24 subnet is delegated as
10.168.192.in-addr.arpa.and is typically managed by whoever holds the IP allocation — your ISP for public addresses, or your own DNS infrastructure for RFC 1918 space.
; Reverse zone file: 10.168.192.in-addr.arpa
$ORIGIN 10.168.192.in-addr.arpa.
$TTL 300
@ IN SOA ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. (
2024041501 ; Serial (YYYYMMDDnn)
3600 ; Refresh
900 ; Retry
604800 ; Expire
300 ; Negative cache TTL
)
IN NS ns1.solvethenetwork.com.
IN NS ns2.solvethenetwork.com.
; PTR records — last octet maps to FQDN
20 IN PTR www.solvethenetwork.com.
30 IN PTR mail1.solvethenetwork.com.
31 IN PTR mail2.solvethenetwork.com.
35 IN PTR mail-backup.solvethenetwork.com.
50 IN PTR sw-infrarunbook-01.solvethenetwork.com.Why It Matters
PTR records are operationally mandatory for any host that sends SMTP. Receiving MTAs perform reverse DNS validation on connecting IP addresses. A missing PTR record, or one where the PTR hostname does not forward-resolve back to the connecting IP (forward-confirmed reverse DNS, FCrDNS), causes mail to be rejected or silently classified as spam by the majority of enterprise and hosted mail platforms.
PTR records are also critical for network operations and security work. Firewall logs, SIEM alerts, syslog streams, and intrusion detection events all become significantly more useful when IP addresses resolve to meaningful hostnames. Traceroute output becomes interpretable. Network path debugging becomes faster. Treating rDNS as optional is a common oversight that surfaces during mail deliverability audits and post-incident forensic reviews.
IPv6 PTR Records
IPv6 PTR records use the
ip6.arpazone. The full 128-bit address is expanded to 32 hexadecimal nibbles, reversed, and each nibble separated by a dot. For the address 2001:0db8:abcd:0012:0000:0000:0000:0030:
; Full expanded IPv6 address: 2001:0db8:abcd:0012:0000:0000:0000:0030
; Reversed nibble-by-nibble:
0.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.1.0.0.d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa.
IN PTR mail1.solvethenetwork.com.
; Verify with:
dig -x 2001:db8:abcd:12::30Common Misconceptions
Misconception 1: CNAME and A Records Are Interchangeable
They are not. A CNAME adds an extra resolution hop and cannot be used at the zone apex. Using a CNAME as an MX or NS target violates RFC standards and causes delivery failures or delegation breakage with compliant implementations. Always use A records where protocols require direct address resolution.
Misconception 2: Multiple A Records Provide True Load Balancing
Round-robin DNS is load distribution, not load balancing. It has no health awareness. If one of three A record targets goes offline, clients that resolved to the dead IP continue to send traffic there until the TTL expires. True load balancing requires a health-aware layer: a dedicated load balancer, anycast routing, or a DNS provider with active health checks that automatically removes failed records from the rotation.
Misconception 3: Lowering the TTL Takes Immediate Effect
A TTL change only affects resolvers that fetch the record after the change is published. A resolver that cached the old record with a 86400-second TTL one second before the change will continue serving stale data for up to 86399 more seconds. The correct procedure is to lower the TTL 24–48 hours before a planned IP change, wait for the old TTL to expire everywhere, make the IP change, then restore the higher TTL after propagation is confirmed.
Misconception 4: PTR Records Are Optional
For any host that sends SMTP, PTR records are a hard operational requirement. They are also important for syslog servers, NTP peers, VPN endpoints, and any infrastructure identified by hostname in logs and alerts. Treating rDNS as optional is a gap that consistently surfaces during mail deliverability audits and security investigations.
Misconception 5: TXT Records Have No Practical Size Limit
Individual TXT strings are bounded at 255 bytes per RFC 1035. While a single TXT record can contain multiple strings that resolvers concatenate, total DNS response size is constrained by the EDNS0 buffer size, typically 4096 bytes. Large DKIM keys combined with verbose SPF and DMARC records can approach this limit and trigger truncation, forcing TCP fallback queries — and in environments where DNS TCP is blocked at the firewall, causing silent resolution failures.
Frequently Asked Questions
Q: What is the difference between an A record and a CNAME record?
A: An A record maps a hostname directly to an IPv4 address. A CNAME maps a hostname to another hostname, which must itself resolve to an A or AAAA record through additional lookups. CNAMEs are useful for aliasing multiple service names to a single canonical infrastructure name, but they add a resolution hop, cannot coexist with other record types at the same name, and are prohibited at the zone apex.
Q: Can I point an MX record to a CNAME?
A: No. RFC 2181 Section 10.3 explicitly prohibits MX record targets from being CNAMEs. The target of an MX record must resolve directly via A or AAAA records. Mail transfer agents that comply with the RFC will refuse to deliver to a CNAME-targeted MX entry. This is a silent failure mode — the sending MTA simply gives up and queues or bounces the message.
Q: Why should I publish both A and AAAA records for the same hostname?
A: If your server is dual-stack, publishing both record types allows IPv6-capable clients to connect directly without traversing NAT64 or other translation mechanisms. This reduces latency and removes dependency on middleboxes outside your control. The Happy Eyeballs algorithm (RFC 8305) handles the preference logic transparently on the client side, so there is no risk of breaking IPv4-only clients.
Q: How do I verify that a PTR record is correctly configured?
A: Use
dig -x 192.168.10.30to query the PTR record directly. The response should return
mail1.solvethenetwork.com.Then forward-verify:
dig A mail1.solvethenetwork.commust return 192.168.10.30. Both directions must agree. Mismatches trigger FCrDNS failures at receiving mail servers and appear as suspicious entries in security tooling.
Q: What is the purpose of having MX records with different priority values?
A: Multiple MX records with different priorities enable mail server redundancy and controlled failover. The sending MTA always tries the lowest-priority-number (highest-preference) entry first. If that server is unreachable after the configured retry period, the sender falls back to higher-numbered entries. Equal-priority MX records are tried in random order, distributing inbound load across equivalent servers in the same tier.
Q: Why can I not place a CNAME at the root of my domain?
A: The zone apex must carry SOA and NS records, which are structurally required for the zone to be valid. RFC 1034 prohibits a CNAME from coexisting with any other record type at the same owner name. Since the apex always has SOA and NS records, adding a CNAME there is invalid. Some DNS providers offer proprietary workarounds — ALIAS, ANAME, or CNAME flattening — that resolve the CNAME target at query time and return A/AAAA records directly, bypassing the restriction at the protocol level.
Q: What is an SPF TXT record and why is it critical for mail delivery?
A: SPF (Sender Policy Framework, RFC 7208) is a TXT record published at the domain apex that lists the IP addresses and hostnames authorized to send email on behalf of that domain. Receiving mail servers perform an SPF lookup during the SMTP transaction and compare the connecting IP against the policy. A missing or overly permissive SPF record significantly increases the probability that your outbound mail is classified as spam or that your domain is successfully spoofed in phishing campaigns.
Q: How long should DNS record TTLs be set?
A: TTL selection is a tradeoff between propagation speed and resolver query load. For stable records that rarely change — NS records, infrastructure hostnames — 3600 to 86400 seconds is appropriate. For records associated with services that may require fast failover — load-balanced web or mail servers — 60 to 300 seconds limits the blast radius of an outage. Always lower the TTL 24 to 48 hours before a planned change, then restore it after propagation is verified.
Q: Can a hostname have both multiple A records and a CNAME simultaneously?
A: No. A CNAME is mutually exclusive with every other record type at the same owner name. You can have multiple A records for a single name (for round-robin), but adding a CNAME to that same name produces an invalid zone. RFC 1034 is unambiguous on this point. Authoritative servers that strictly follow the specification will refuse to load such a zone configuration entirely.
Q: What happens when PTR and forward DNS records do not match?
A: When the PTR record for an IP points to a hostname that does not forward-resolve back to that IP, the host fails forward-confirmed reverse DNS (FCrDNS) validation. Most enterprise spam filters and many MTAs treat this as a strong spam signal or reject the connection outright. It also produces confusing output in traceroute and log analysis because the name and address tell contradictory stories.
Q: How do I retrieve all TXT records for a domain from the command line?
A: Query the apex with
dig TXT solvethenetwork.com +shortto see all TXT records at the domain root, including SPF and verification tokens. For DMARC, query the dedicated subdomain:
dig TXT _dmarc.solvethenetwork.com +short. For a DKIM selector named mail2024:
dig TXT mail2024._domainkey.solvethenetwork.com +short. The
+shortflag strips the query metadata and returns only the record data.
Q: Why do AAAA queries sometimes fail even when an IPv6 address is configured on the host?
A: Several root causes are common: the AAAA record exists in DNS but the host's IPv6 address is unreachable due to a routing gap or firewall ACL blocking IPv6; the AAAA record was added to the wrong zone or with a typographical error in the address; or the upstream resolver filters AAAA responses, which occurs in some embedded network appliances and older resolver implementations. Diagnose by first confirming the record exists with
dig AAAA sw-infrarunbook-01.solvethenetwork.com +short, then test connectivity separately with
ping6or
curl --ipv6to isolate whether the failure is in DNS or in the data plane.