A and AAAA Records: Mapping Names to IP Addresses

At the absolute core of the Domain Name System lies a simple but profound capability: translating human-readable domain names into machine-routable IP addresses. This fundamental translation—the raison d'être of DNS—is accomplished through two critical resource record types: A records for IPv4 addresses and AAAA records for IPv6 addresses.

Every time you type a URL into a browser, every API call your application makes, every email your server attempts to deliver—all of these operations begin with an address record lookup. Without A and AAAA records, the elegant abstraction of domain names would collapse, forcing users to memorize 32-bit or 128-bit numerical addresses.

This page provides exhaustive coverage of these foundational record types, examining their internal structure, wire format, resolution behavior, caching semantics, and real-world deployment patterns. You will emerge with Principal Engineer-level understanding of how the Internet's address resolution backbone operates.

The A record (Address record) is the original and most fundamental DNS record type, defined in RFC 1035 as part of the initial DNS specification in 1987. Its purpose is singular and essential: map a domain name to an IPv4 address.

Formal Definition

An A record establishes a binding between:

• Owner Name: The fully qualified domain name (FQDN) being resolved
• IPv4 Address: A 32-bit address in dotted-decimal notation (e.g., 192.0.2.1)

The abstract relationship can be expressed as:

<owner-name>  IN  A  <ipv4-address>

For example:

www.example.com.  IN  A  93.184.216.34

This record declares: "When any resolver asks for the IPv4 address of www.example.com, respond with 93.184.216.34."

Why "A" Records?

The designation "A" stands for Address. In the early DNS specification, the naming was intentionally terse—single letters for record types that would appear billions of times in zone files and DNS messages. The A record was type number 1, reflecting its primacy in the DNS type hierarchy.

A Record Wire Format

Understanding the wire format is essential for debugging packet captures and comprehending DNS at a systems level. In DNS messages, an A record appears in the answer section with the following structure:

The RDATA section for an A record is exactly 4 bytes, representing the 32-bit IPv4 address. For the address 93.184.216.34, the RDATA bytes would be:

0x5D 0xB8 0xD8 0x22  (93.184.216.34 in hex)

Each octet of the dotted-decimal address occupies one byte in network byte order (big-endian).

The AAAA record (pronounced "quad-A") extends address resolution to the IPv6 address family. Defined in RFC 3596 (2003), the AAAA record performs the same function as the A record but for 128-bit IPv6 addresses instead of 32-bit IPv4 addresses.

Why "AAAA"?

The name "AAAA" reflects the size relationship between IPv4 and IPv6 addresses:

• An A record contains a 32-bit address (4 bytes)
• An AAAA record contains a 128-bit address (16 bytes)
• Since 128 = 4 × 32, the record type was named with four "A"s: AAAA

This naming convention, while somewhat playful, created an instantly memorable designation that clearly signals the IPv6 context.

Formal Definition

An AAAA record establishes a binding between:

• Owner Name: The fully qualified domain name (FQDN) being resolved
• IPv6 Address: A 128-bit address in colon-hexadecimal notation

The abstract relationship:

<owner-name>  IN  AAAA  <ipv6-address>

For example:

www.example.com.  IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

This record declares: "When any resolver asks for the IPv6 address of www.example.com, respond with 2606:2800:220:1:248:1893:25c8:1946."

AAAA Record Wire Format

The AAAA record follows the same general structure as the A record, with the critical difference being the RDATA length:

The RDATA section contains exactly 16 bytes representing the 128-bit IPv6 address. For the address 2001:0db8:85a3:0000:0000:8a2e:0370:7334, the bytes are:

20 01 0D B8 85 A3 00 00 00 00 8A 2E 03 70 73 34

Each 16-bit group in the IPv6 address corresponds to 2 bytes in the RDATA.

Understanding how A/AAAA queries traverse the DNS hierarchy is essential for debugging resolution failures, optimizing performance, and designing resilient infrastructure.

The Query Lifecycle

When an application needs to resolve www.example.com to an IP address, the following sequence unfolds:

Step 1: Application Initiates Resolution

The application calls a resolver function (e.g., getaddrinfo() on POSIX systems, Dns.GetHostEntry() in .NET). This system call creates a resolution request.

Step 2: Stub Resolver Check

The operating system's stub resolver first checks:

1. Local hosts file (/etc/hosts on Unix, C:\Windows\System32\drivers\etc\hosts on Windows)
2. Local DNS cache (system-level cached responses from previous queries)

If found, resolution completes immediately without network traffic.

Step 3: Query to Recursive Resolver

If not cached locally, the stub resolver sends a query to its configured recursive resolver (typically provided by DHCP from the ISP, or explicitly configured like Google's 8.8.8.8 or Cloudflare's 1.1.1.1).

The DNS query message contains:

• QNAME: www.example.com
• QTYPE: A (type 1) or AAAA (type 28)
• QCLASS: IN (Internet, class 1)
• RD Flag: Set to 1 (Recursion Desired)

Step 4: Recursive Resolver Processes Query

The recursive resolver checks its own cache. If a valid (non-expired) answer exists, it returns immediately. Otherwise, it begins iterative resolution through the DNS hierarchy.

Iterative Resolution Through Hierarchy

When the recursive resolver must perform full resolution:

1. Root Server Query

The resolver queries a root server (e.g., a.root-servers.net) for www.example.com. The root server doesn't know the answer but returns a referral to the .com TLD servers, including their NS records and glue A/AAAA records.

2. TLD Server Query

The resolver follows the referral and queries a .com TLD server. This server returns another referral to example.com's authoritative nameservers.

3. Authoritative Server Query

Finally, the resolver queries example.com's authoritative nameserver, which returns the actual A record with the IP address.

4. Response Delivery

The recursive resolver caches the response (respecting TTL), then returns it to the stub resolver, which caches it locally and delivers it to the application.

Query Flags and Their Significance

The Time-To-Live (TTL) field in A and AAAA records is fundamental to DNS's distributed caching architecture. Proper TTL configuration directly impacts resolution latency, server load, failover speed, and propagation timing during infrastructure changes.

TTL Fundamentals

The TTL is a 32-bit unsigned integer representing the maximum number of seconds a record should be cached before re-querying the authoritative source. The value ranges from:

• Minimum: 0 (do not cache)
• Maximum: 2,147,483,647 seconds (~68 years, theoretical maximum)
• Practical Range: 60 seconds to 86,400 seconds (1 minute to 24 hours)

TTL Countdown Mechanism

When a resolver caches an A/AAAA record:

1. Initial Cache Entry: Record stored with original TTL value
2. Time Passage: TTL decrements each second the record remains cached
3. TTL Exhaustion: When TTL reaches 0, the cached entry is considered stale
4. Re-query Required: Next lookup triggers fresh query to authoritative server

Importantly, when a resolver returns a cached response to a client, it includes the remaining TTL, not the original TTL. This creates a cascading countdown across all caching layers.

Caching Layers in Practice

A/AAAA records traverse multiple caching layers, each respecting TTL:

Layer 1: Browser Cache Modern browsers cache DNS responses internally for performance. Chrome, Firefox, and Safari each maintain their own resolver caches, typically respecting TTL but sometimes imposing minimum cache durations.

Layer 2: Operating System Cache The OS stub resolver maintains a system-wide DNS cache:

• Windows: DNS Client service (ipconfig /displaydns)
• macOS: mDNSResponder (sudo killall -HUP mDNSResponder to flush)
• Linux: Varies by distribution (systemd-resolved, nscd, etc.)

Layer 3: Recursive Resolver Cache The configured DNS resolver (ISP's resolver, Google DNS, Cloudflare, etc.) maintains massive caches serving millions of users. A single cached A record can eliminate millions of authoritative queries.

Layer 4: Authoritative Server Cache Even authoritative servers may cache data from backend databases or upstream systems.

Negative Caching (NXDOMAIN)

When a domain doesn't exist, the authoritative server returns an NXDOMAIN response. This negative result is also cached, with TTL taken from the SOA record's minimum TTL field. This prevents repeated queries for non-existent domains but can delay detection of newly created records.

A single domain name can have multiple A records (and multiple AAAA records), enabling primitive but effective load distribution and failover capabilities directly within DNS.

Multiple A/AAAA Records Configuration

Zone file example with multiple addresses:

www.example.com.  300  IN  A     93.184.216.34
www.example.com.  300  IN  A     93.184.216.35
www.example.com.  300  IN  A     93.184.216.36

www.example.com.  300  IN  AAAA  2606:2800:220:1:248:1893:25c8:1946
www.example.com.  300  IN  AAAA  2606:2800:220:1:248:1893:25c8:1947

When a resolver queries for www.example.com, the authoritative server returns all matching records in the answer section. The resolver (and ultimately the application) receives the complete set.

Round-Robin DNS

Traditionally, DNS servers rotate the order of multiple A/AAAA records in each response—a technique called round-robin DNS:

• First query returns: [A, B, C]
• Second query returns: [B, C, A]
• Third query returns: [C, A, B]

Since applications typically use the first address returned, this creates naive load distribution across servers. However, this is not true load balancing:

1. No health awareness: DNS doesn't know if a server is down
2. Caching disrupts distribution: Cached responses return the same order
3. No session affinity: Subsequent requests may hit different servers
4. No load-based routing: All servers receive equal weight regardless of capacity

Client-Side Address Selection

How do clients choose among multiple addresses? The behavior varies:

RFC 6724: Default Address Selection for IPv6

This RFC defines a sophisticated algorithm for selecting among multiple addresses, considering:

• Prefix matching (prefer addresses with longer common prefixes)
• Scope (prefer addresses with matching scope)
• Source/destination address pairing
• Historical connection success

Happy Eyeballs (RFC 8305)

Modern clients implement "Happy Eyeballs" for dual-stack environments:

1. Initiate IPv6 connection attempt
2. After brief delay (typically 250ms), initiate parallel IPv4 attempt
3. Use whichever connects first
4. Remember preference for future connections

This algorithm ensures users get the fastest connection while preferring IPv6 when both protocols work.

Intelligent DNS Solutions

For production systems requiring true load balancing, organizations typically layer additional intelligence:

• Global Server Load Balancing (GSLB): DNS servers with health checking, returning only healthy IPs
• GeoDNS: Return addresses based on client geographic location
• Latency-based routing: Return the server with lowest measured latency
• Weighted routing: Distribute traffic according to server capacity

Major cloud providers (AWS Route 53, Google Cloud DNS, Cloudflare) offer these capabilities as managed services.

Deploying both A and AAAA records for the same domain—dual-stack DNS—is the recommended approach for modern Internet services. This enables seamless connectivity for both IPv4-only and IPv6-capable clients while supporting the gradual transition to IPv6.

Why Dual-Stack Matters

IPv6 adoption continues growing:

• Major mobile carriers (T-Mobile, Verizon, AT&T) operate IPv6-primary networks
• Key content providers (Google, Facebook, Netflix) are fully dual-stack
• IPv6-only networks exist in mobile and data center environments

Domains without AAAA records are inaccessible from IPv6-only networks. Conversely, domains without A records are inaccessible from IPv4-only networks (still common in corporate environments and legacy infrastructure).

Zone File Configuration

A properly configured dual-stack zone includes both record types:

; Dual-stack configuration for www.example.com
www.example.com.  300  IN  A     93.184.216.34
www.example.com.  300  IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

; Multiple addresses for redundancy
www.example.com.  300  IN  A     93.184.216.35
www.example.com.  300  IN  AAAA  2606:2800:220:1:248:1893:25c8:1947

Query Behavior in Dual-Stack Environments

When an application requests resolution in a dual-stack environment:

1. Modern resolvers send parallel A and AAAA queries, or use a single QTYPE=ANY query
2. Both record types are returned in the response (if both exist)
3. The application's address selection algorithm chooses which to use first
4. Most modern systems prefer IPv6 when both are available and functional

IPv6 Address Assignment Strategies

Unlike IPv4, where address scarcity drove complex allocation, IPv6 provides abundant addressing. Organizations typically receive a /48 or /32 allocation, offering trillions of addresses.

Best Practices for IPv6 Address Assignment:

1. Document your addressing scheme: Create a systematic plan before assigning addresses
2. Use static addresses for DNS records: Don't rely on SLAAC for server addresses
3. Consider memorability: 2001:db8::1 is easier to remember than a random EUI-64 address
4. Plan for subnetting: Reserve adequate space for future growth
5. Avoid embedding IPv4 addresses: Using ::ffff:192.0.2.1 format can cause confusion

Troubleshooting Dual-Stack Issues

Common dual-stack problems and their symptoms:

A and AAAA records, as the fundamental building blocks of name-to-address mapping, are prime targets for various attacks. Understanding these vulnerabilities is essential for defensive configuration.

DNS Spoofing and Cache Poisoning

Attack Vector: An attacker injects fraudulent A/AAAA records into resolver caches, causing victims to connect to attacker-controlled servers.

Mechanism:

1. Attacker triggers victim's resolver to query for a target domain
2. Attacker races to respond before the legitimate authoritative server
3. If attacker's forged response arrives first with matching query ID and UDP port, it's accepted
4. False A/AAAA record is cached and served to all users of that resolver

Defense: DNSSEC (DNS Security Extensions) provides cryptographic authentication of DNS responses, preventing acceptance of forged records. DNSSEC-validating resolvers reject unsigned or improperly signed A/AAAA records for signed zones.

DNSSEC for A/AAAA Records

When DNSSEC is enabled for a zone, A and AAAA records are accompanied by RRSIG (Resource Record Signature) records:

www.example.com.  300  IN  A      93.184.216.34
www.example.com.  300  IN  RRSIG  A 13 3 300 20240101000000 20231201000000 12345 example.com. ABC123...

The RRSIG contains:

• Algorithm used (13 = ECDSA P-256)
• Type covered (A)
• Original TTL
• Signature expiration and inception times
• Key tag identifying the signing key
• Signer's name
• Digital signature

Validating resolvers verify this signature against the zone's DNSKEY records, which are themselves authenticated via a chain of trust to the root zone.

Additional Security Best Practices

1. Minimal Exposure

• Only publish A/AAAA records for services that must be publicly accessible
• Use internal DNS or hosts files for internal-only services

2. Monitoring

• Monitor for unauthorized changes to A/AAAA records
• Set up alerts for unexpected record modifications
• Use DNS monitoring services to detect tampering

3. Access Control

• Restrict who can modify DNS records
• Enable MFA for DNS management interfaces
• Audit access logs regularly

4. Registry Lock

• Enable registry lock for high-value domains to prevent unauthorized transfers
• This adds human verification for any registrar-level changes