DNS Records, TTL Strategy, and Cache Behavior

DNS records encode more than addresses—they define routing policies, ownership verification, security constraints, and service discovery. TTL (Time To Live) values control how long resolvers cache these records, creating a fundamental trade-off between propagation speed and query load. This article covers record types in depth, TTL design decisions for different operational scenarios, and the caching behaviors that determine how quickly DNS changes take effect.

Abstract

DNS records fall into four functional categories: address resolution (A, AAAA, CNAME), zone delegation (NS, SOA), service location (MX, SRV), and security/verification (TXT, CAA). Each type has specific constraints—CNAME cannot coexist with other records at the same name, MX targets must be A/AAAA records (never CNAMEs), and SOA’s MINIMUM field controls negative caching duration.

TTL strategy depends on the operational scenario:

• Static infrastructure: 3600-86400s (1-24 hours) reduces resolver load
• CDN/anycast: 300s or less enables rapid failover
• Migrations: Lower TTL 24-48 hours before the change, wait for old TTL to expire, then make the change

“DNS propagation” is a misnomer—there is no active push mechanism. Changes take effect as cached records expire across resolver layers. The effective propagation time equals the maximum of: the old record’s remaining TTL, negative cache TTL (SOA MINIMUM), and any resolver TTL floors that ignore authoritative values.

Address Resolution Records

A and AAAA Records

The A record (RFC 1035) maps a hostname to a 32-bit IPv4 address. The AAAA record (RFC 3596) maps to a 128-bit IPv6 address—the name “quad-A” reflects the fourfold size increase.

Key behaviors:

• Multiple A/AAAA records for the same name enable round-robin load distribution
• Records cannot point to other hostnames; they contain literal IP addresses
• The query transport protocol is independent of record type—you can query AAAA records over IPv4

Design decision—why separate record types? IPv6 addresses are four times larger than IPv4. Rather than overloading the A record with a variable-length format, RFC 3596 introduced a distinct type. This simplifies parsing and allows resolvers to query specifically for the address family they need.

1
api.example.com.    300    IN    A    192.0.2.10
2
api.example.com.    300    IN    A    192.0.2.11
3
api.example.com.    300    IN    A    192.0.2.12

Per RFC 2181, all records in an RRSet (Resource Record Set) must have identical TTLs. If a resolver receives differing TTLs for the same name and type, it must treat this as an error and use the lowest value.

CNAME Records

A CNAME (Canonical Name) record declares that one name is an alias for another. Per RFC 1034 Section 3.6.2: “If a CNAME RR is present at a node, no other data should be present.”

The zone apex restriction: CNAME cannot exist at the zone apex (e.g., example.com) because:

1. Every zone apex must have SOA and NS records (RFC 1034 Section 4.2.1)
2. CNAME cannot coexist with any other record type
3. Therefore, placing CNAME at apex violates the protocol

Why this constraint exists: When a resolver encounters a CNAME, it restarts the query using the target name. If other records existed at the same name, the resolver couldn’t determine whether to follow the CNAME or return the other records. The exclusivity rule eliminates this ambiguity.

Workarounds for apex aliasing:

Cloudflare’s CNAME flattening and Route 53’s Alias records work by resolving the CNAME chain at query time and returning the resulting A/AAAA records directly. The limitation: location-dependent responses (GeoDNS) will be based on the authoritative server’s location, not the end user’s resolver.

PTR Records

PTR (Pointer) records provide reverse DNS—mapping IP addresses to hostnames. The address is encoded in reverse order under a special domain:

• IPv4: 192.0.2.5 → 5.2.0.192.in-addr.arpa
• IPv6: Uses ip6.arpa with nibbles (4-bit values) reversed

Why reverse order? DNS is hierarchical from right to left (com → example → api). IP addresses are hierarchical from left to right (network → host). Reversing the IP aligns with DNS delegation—the /8 network owner controls 192.in-addr.arpa and can delegate /16 blocks.

Operational impact: Many mail servers reject connections from IPs without valid PTR records or where forward and reverse DNS don’t match. Cloud providers typically manage PTR records for their IP ranges; you must request updates through their interface.

Zone Delegation Records

NS Records

NS (Name Server) records identify the authoritative DNS servers for a zone. They serve two distinct purposes:

1. At zone apex: Declare which servers are authoritative for this zone
2. At delegation points: Direct resolvers to child zone nameservers

The delegation distinction: NS records in the parent zone (e.g., .com zone containing example.com NS) are not authoritative—they’re “delegation hints.” The authoritative NS records are those served by the zone’s own nameservers.

Glue records solve a circular dependency: if ns1.example.com is the nameserver for example.com, you’d need to resolve example.com to find ns1.example.com. Glue records—A/AAAA records embedded in the parent zone’s delegation—break this cycle.

Per RFC 9471, glue is required when nameservers are “in-bailiwick” (within or below the delegated zone). The IP addresses in glue must match the authoritative A/AAAA records for those nameservers.

1
; In the .com zone (parent)
2
example.com.        172800  IN  NS  ns1.example.com.
3
example.com.        172800  IN  NS  ns2.example.com.
4
ns1.example.com.    172800  IN  A   192.0.2.1
5
ns2.example.com.    172800  IN  A   192.0.2.2

SOA Records

Every DNS zone must have exactly one SOA (Start of Authority) record at the zone apex. It contains zone metadata critical for replication and caching:

The MINIMUM field evolution: Originally (RFC 1035), this specified the minimum TTL for all records in the zone. RFC 2308 redefined it exclusively for negative caching—the TTL for NXDOMAIN and NODATA responses. The field name is now misleading, but changing it would break compatibility.

1
example.com.  86400  IN  SOA  ns1.example.com. hostmaster.example.com. (
2
                          2024011501  ; Serial
3
                          7200        ; Refresh (2 hours)
4
                          3600        ; Retry (1 hour)
5
                          1209600     ; Expire (14 days)
6
                          3600        ; Minimum (negative cache TTL)
7
                          )

Service Location Records

MX Records

MX (Mail Exchange) records direct email delivery. The format includes a preference value:

1
example.com.    300    IN    MX    10    mail1.example.com.
2
example.com.    300    IN    MX    20    mail2.example.com.

Priority semantics: Lower preference values indicate higher priority. When multiple servers share the same preference, RFC 5321 requires the sending server to randomize selection for load distribution.

Fallback behavior: If a domain has no MX records, RFC 5321 specifies an implicit MX of preference 0 pointing to the domain itself (the A/AAAA records). However, if MX records exist, the domain’s A/AAAA records must not be used for mail delivery.

Critical constraint: MX targets must resolve to A/AAAA records, never CNAMEs. Per RFC 2181 and RFC 5321, an MX pointing to a CNAME is invalid. Some implementations follow the CNAME anyway, but this behavior is non-standard and unreliable.

SRV Records

SRV (Service) records generalize service discovery beyond email. RFC 2782 defines the format:

1
_sip._tcp.example.com.  300  IN  SRV  10 60 5060 sipserver.example.com.
2
;                                     ^  ^  ^    ^
3
;                                     |  |  |    +-- Target
4
;                                     |  |  +------- Port
5
;                                     |  +---------- Weight
6
;                                     +------------- Priority

The underscore prefix: Service and protocol labels start with _ to avoid collisions with natural DNS labels. This was a design choice to keep SRV in the same namespace as other records.

Weight-based load balancing: Among servers with equal priority, weight determines selection probability. A server with weight 60 receives three times the traffic of weight 20. Weight 0 indicates a backup server—use only when all higher-weight servers are unavailable.

Common uses:

• Microsoft Active Directory (domain controller discovery)
• SIP/VoIP (_sip._tcp, _sip._udp)
• XMPP/Jabber (_xmpp-client._tcp)
• CalDAV/CardDAV (_caldavs._tcp, _carddavs._tcp)

Target constraint: Like MX, SRV targets must be A/AAAA records. A target of . (root) explicitly indicates the service is not available at this domain.

Security and Verification Records

TXT Records

TXT records store arbitrary text, originally intended for human-readable information. Today they’re primarily used for machine-readable verification and policy:

Size constraints:

• Each string within a TXT record: 255 bytes maximum (RFC 1035)
• Multiple strings are concatenated without separators
• Total record size limited by DNS message size (512 bytes UDP, ~65KB with EDNS0)

1
example.com.  300  IN  TXT  "v=spf1 include:_spf.google.com " "include:amazonses.com -all"

The strings are concatenated to: v=spf1 include:_spf.google.com include:amazonses.com -all

Email authentication records:

SPF lookup limit: SPF evaluation allows maximum 10 DNS lookups (including include:, a:, mx:, redirect=). Exceeding this limit causes a permanent error (permerror), potentially causing mail rejection. Flatten SPF records by replacing includes with direct IP ranges for high-volume domains.

Domain verification: Services like Google Workspace, Microsoft 365, and AWS SES use TXT records to verify domain ownership. The record typically contains a unique token: google-site-verification=abc123...

CAA Records

CAA (Certification Authority Authorization) records specify which Certificate Authorities may issue certificates for a domain. RFC 8659 defines the format:

1
example.com.  300  IN  CAA  0  issue  "letsencrypt.org"
2
example.com.  300  IN  CAA  0  issuewild  "digicert.com"
3
example.com.  300  IN  CAA  0  iodef  "mailto:security@example.com"

Property tags:

• issue: CAs authorized to issue non-wildcard certificates
• issuewild: CAs authorized for wildcard certificates (if absent, issue applies)
• iodef: URL or email for violation reports

CA/Browser Forum mandate: Since September 2017, CAs must check CAA records before issuance. If CAA records exist and don’t authorize the CA, issuance must fail.

Inheritance: CAA records at example.com apply to all subdomains unless overridden. To allow any CA for a subdomain while restricting the parent:

1
example.com.      300  IN  CAA  0  issue  "letsencrypt.org"
2
dev.example.com.  300  IN  CAA  0  issue  ";"  ; Allow any CA

The value ";" explicitly permits any CA.

TTL Strategy and Design Decisions

TTL Mechanics

TTL is a 32-bit unsigned integer specifying how long a record may be cached, in seconds. Per RFC 1035: “TTL specifies the time interval that the resource record may be cached before the source of the information should again be consulted.”

Bounds (RFC 2181):

• Minimum: 0 (use only for current transaction, do not cache)
• Maximum: 2147483647 (2³¹ - 1 seconds, ~68 years)
• Practical maximum: 604800 (7 days, per RFC 8767 recommendation)

Zero TTL behavior: The record may only be used for the transaction in progress and must not be cached. Use case: SOA records during zone transfers, or extremely volatile data like real-time load balancer targets.

TTL by Scenario

CDN provider behavior: Cloudflare automatically sets 300s TTL for proxied records (orange cloud) and doesn’t allow customization. This ensures their anycast routing changes propagate within 5 minutes.

Failover and health checks: AWS Route 53 recommends 60s or less for health-checked records. Lower TTL means faster failover but higher query volume—a 60s TTL generates 1440 queries per day per caching resolver versus 24 queries for 3600s.

Migration TTL Strategy

DNS migrations require careful TTL management to minimize both stale cache impact and query load:

Pre-migration (24-48 hours before):

1. Lower TTL to 300-600s on records that will change
2. Wait for the old TTL to expire everywhere
3. Verify TTL change propagated: dig +norecurse @8.8.8.8 example.com

During migration:

4. Make the DNS change
5. Verify new records are served by authoritative servers
6. Monitor for traffic shift (may take up to new TTL duration)

Post-migration (after verification):

7. Restore higher TTL for normal operation
8. Keep lower TTL for 24-48 hours if rollback might be needed

NS record migrations are special: NS records often have 172800s (48h) TTL. You must lower TTL at both old and new DNS providers. Plan for 2-3 days minimum migration window.

1
; Step 1: Lower TTL (wait 24h if original was 86400s)
2
api.example.com.    300    IN    A    192.0.2.10
3

4
; Step 2: After old TTL expires, change the record
5
api.example.com.    300    IN    A    198.51.100.20
6

7
; Step 3: After verification, restore normal TTL
8
api.example.com.    3600   IN    A    198.51.100.20

Caching Behavior and Propagation

Caching Layers

DNS responses pass through multiple caching layers, each with distinct behavior:

Resolver TTL floors: Some resolvers enforce minimum TTLs regardless of authoritative values. ISP resolvers may cache for longer than specified. Google Public DNS (8.8.8.8) generally respects TTLs but may serve stale data during authoritative outages (RFC 8767 serve-stale).

Negative Caching

When a name doesn’t exist (NXDOMAIN) or exists but has no records of the requested type (NODATA), resolvers cache this negative result. RFC 2308 specifies:

Negative cache TTL = min(SOA.MINIMUM, SOA TTL)

Authoritative servers must include the SOA record in the Authority section of negative responses. Without SOA, the response should not be cached—this prevents infinite negative caching loops.

Operational impact: If you delete a DNS record, resolvers may cache the NXDOMAIN response for up to SOA.MINIMUM seconds. Before deleting, consider:

1. Check your SOA.MINIMUM value
2. Lower it temporarily if the default is high
3. Or change the record to point elsewhere rather than deleting

1
; If SOA.MINIMUM is 3600 (1 hour):
2
; Deleting api.example.com means NXDOMAIN cached for up to 1 hour
3
; Resolver won't re-query until negative cache expires

The “Propagation” Reality

“DNS propagation” suggests an active push mechanism—it doesn’t exist. DNS changes take effect passively as caches expire.

What people mean by “propagation time”:

1. Maximum of all cache TTLs: The old record’s remaining TTL across all resolver caches
2. Negative cache duration: If the name was queried before creation (NXDOMAIN cached)
3. Resolver refresh behavior: Some resolvers batch updates or have minimum TTL floors

Why changes seem slow:

• You lowered TTL to 300s, but the old 86400s TTL hasn’t expired everywhere
• ISP resolver ignores TTL and caches for 24 hours regardless
• Browser DNS cache retains old entry independent of system resolver
• Application-level DNS caching (Java, .NET) with separate TTL handling

Verification approach:

# Query authoritative server directly
dig @ns1.example.com api.example.com

# Check what recursive resolver has cached
dig +norecurse @8.8.8.8 api.example.com

# If +norecurse returns nothing, force a fresh lookup
dig @8.8.8.8 api.example.com

Split-Horizon DNS

Split-horizon (split-brain) DNS returns different responses based on query source—typically internal vs. external networks.

Use Cases

1. Internal services: api.internal.example.com resolves to 10.0.1.50 internally, NXDOMAIN externally
2. Security: Hide internal infrastructure from external reconnaissance
3. Performance: Internal clients reach services via private network, not hairpinning through public IPs
4. Compliance: Prevent internal DNS information from leaking externally

Implementation Approaches

Separate servers:

1
                    ┌─────────────────┐
2
    Internal DNS ───│ 10.0.0.53       │─── Internal zone files
3
                    └─────────────────┘
4

5
                    ┌─────────────────┐
6
    External DNS ───│ 203.0.113.53    │─── External zone files
7
                    └─────────────────┘

DNS views (BIND):

2 collapsed lines
1
acl "internal" { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
2

3
view "internal" {
4
    match-clients { internal; };
5
    zone "example.com" {
6
        type master;
7
        file "zones/example.com.internal";
8
    };
9
};
10

11
view "external" {
12
    match-clients { any; };
13
    zone "example.com" {
14
        type master;
3 collapsed lines
15
        file "zones/example.com.external";
16
    };
17
};

Operational Pitfalls

Record drift: Internal and external zone files can diverge. Automate zone generation from a single source of truth, or use infrastructure-as-code (Terraform, Pulumi) to manage both.

VPN transitions: A laptop connecting to VPN may have cached external IPs. Symptoms: internal services unreachable until DNS cache expires. Mitigation: shorter TTLs (300s) for records that differ between views.

Debugging complexity: “It works on my machine” gains a new dimension when DNS responses vary by network. Document which records differ and include source IP in troubleshooting procedures.

DNSSEC challenges: Each view must maintain consistent signatures. Zone signing must happen separately for each view’s zone file, complicating key management.

Operational Checklists

Record Change Checklist

• Verify current TTL: dig +noall +answer example.com
• If TTL > 300s and change is time-sensitive, lower TTL and wait
• Make change on authoritative servers
• Verify authoritative response: dig @ns1.example.com example.com
• Verify recursive resolver sees change: dig @8.8.8.8 example.com
• For critical changes, check multiple public resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9)
• Restore normal TTL after verification period

New Domain Setup Checklist

• NS records delegated at registrar (match authoritative NS records)
• Glue records present if nameservers are in-bailiwick
• SOA record with appropriate MINIMUM for negative caching (typically 3600s)
• A/AAAA records for web traffic
• MX records pointing to A/AAAA targets (not CNAMEs)
• SPF TXT record for email authentication
• DKIM TXT record(s) for each email provider
• DMARC TXT record with policy
• CAA records restricting certificate issuance

Migration Checklist

• Document current records: dig +noall +answer example.com ANY
• Lower TTL to 300s on changing records
• Wait for old TTL duration (check: dig +norecurse @8.8.8.8)
• For NS changes: lower TTL at both old and new providers
• Make DNS changes
• Verify from multiple locations/resolvers
• Monitor for traffic shift and errors
• Keep rollback option for 24-48 hours
• Restore normal TTLs after stabilization

Conclusion

DNS record types encode specific semantics—A/AAAA for addresses, CNAME for aliases (with zone apex restrictions), NS/SOA for delegation, MX/SRV for service discovery, and TXT/CAA for verification and security policy. Each type has constraints that reflect protocol design decisions: CNAME exclusivity prevents ambiguity, MX/SRV targets must be A/AAAA to avoid resolution loops, and SOA.MINIMUM controls negative caching duration.

TTL strategy is a trade-off between cache efficiency and change velocity. Static infrastructure benefits from high TTLs (3600-86400s) that reduce resolver load. Failover scenarios require low TTLs (60-300s) to enable rapid traffic shifts. Migrations demand TTL lowering before the change, waiting for old caches to expire, then executing the change.

“DNS propagation” is cache expiry, not active distribution. Changes take effect as cached records reach TTL zero across the resolver hierarchy. When changes seem stuck, check: authoritative servers are returning new data, recursive resolvers have refreshed their cache, and client-side caches (OS, browser, application) have expired.

Appendix

Prerequisites

• DNS resolution fundamentals (see DNS Resolution Path)
• Basic understanding of IP addressing (IPv4/IPv6)
• Familiarity with command-line DNS tools (dig, nslookup)

Terminology

Summary

• A/AAAA map hostnames to IPv4/IPv6 addresses; multiple records enable round-robin
• CNAME creates aliases but cannot coexist with other records; forbidden at zone apex
• NS records delegate zones; glue records break circular dependencies for in-bailiwick nameservers
• SOA.MINIMUM controls negative caching duration—check before deleting records
• MX/SRV targets must be A/AAAA, never CNAMEs; lower preference = higher priority
• TXT records support SPF, DKIM, DMARC; SPF has 10-lookup limit
• CAA restricts certificate issuance; mandatory CA check since September 2017
• TTL strategy: High for static (3600-86400s), low for failover (60-300s), temporarily low for migrations
• Propagation = cache expiry; lower TTL before changes, wait for old TTL to expire

References

• RFC 1035 - Domain Names: Implementation and Specification - Core record types, TTL definition
• RFC 1034 - Domain Names: Concepts and Facilities - CNAME semantics, zone structure
• RFC 2181 - Clarifications to the DNS Specification - TTL bounds, RRSet consistency
• RFC 2308 - Negative Caching of DNS Queries - NXDOMAIN/NODATA caching, SOA.MINIMUM redefinition
• RFC 1912 - Common DNS Operational and Configuration Errors - Best practices, SOA values
• RFC 3596 - DNS Extensions to Support IP Version 6 - AAAA records
• RFC 2782 - A DNS RR for specifying the location of services (SRV) - SRV record format and semantics
• RFC 5321 - Simple Mail Transfer Protocol - MX record usage, implicit MX
• RFC 8659 - DNS Certification Authority Authorization (CAA) - CAA record specification
• RFC 9471 - DNS Glue Requirements in Referral Responses - Glue record requirements
• RFC 7208 - Sender Policy Framework (SPF) - SPF TXT record format
• RFC 6376 - DomainKeys Identified Mail (DKIM) - DKIM TXT record format
• RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC) - DMARC policy
• RFC 8767 - Serving Stale Data to Improve DNS Resiliency - Stale serving, TTL cap recommendation
• Cloudflare - CNAME Flattening - Zone apex CNAME workaround
• AWS Route 53 Best Practices - TTL recommendations for failover
• Julia Evans - DNS doesn’t propagate - Propagation misconceptions explained