A Records: Mapping Names to IPv4 Addresses

Every link you click, every image that loads, every API call your apps make—all of them start with the same question: "What's the number for this name?"

The A record answers that question. It maps a domain name like connected.app to an IPv4 address like 192.0.2.10. The "A" stands for Address, and these records are why you can type words into your browser instead of memorizing numbers.

Humans think in meaning. Machines think in numbers. A records are the translation layer between these two ways of addressing the world.

How A Records Work

When you type a domain into your browser, your device asks DNS servers: "What's the IP address for this name?" The DNS server looks up the A record and responds with the IPv4 address. Your browser connects to that address. This happens in milliseconds, invisibly, thousands of times a day.

An A record looks like this:

example.com.    3600    IN    A    192.0.2.10

Breaking it down:

• Name: The domain or subdomain (example.com or www.example.com)
• TTL: Time To Live in seconds—how long resolvers can cache this answer
• Class: IN for Internet (the only class you'll encounter)
• Type: A for Address record
• Value: The IPv4 address in dotted decimal notation

The TTL Tradeoff

TTL is a bet on stability. High TTL says: "This won't change—cache it." Low TTL says: "This might change—check often."

Short TTL (60-300 seconds): For infrastructure in flux. Migrations, testing, or anything you might need to change quickly. More DNS queries, but changes propagate in minutes.

Medium TTL (1-2 hours): The standard for production. Balances performance with reasonable update speed.

Long TTL (24+ hours): For infrastructure that rarely changes. Maximum caching, but changes take a full day to propagate globally.

The migration pattern: lower your TTL 24-48 hours before a planned IP change. Make the change. Raise the TTL once propagation completes. This minimizes the window where some users hit the old address while others hit the new one.

Common Configurations

A typical domain has multiple A records pointing different subdomains to different servers:

example.com.        3600    IN    A    192.0.2.10
www.example.com.    3600    IN    A    192.0.2.10
mail.example.com.   3600    IN    A    192.0.2.20
api.example.com.    3600    IN    A    192.0.2.30

The root domain and www usually point to the same address—users expect both to work. Other subdomains point to specialized servers: mail handlers, API endpoints, staging environments. This is how one domain becomes many services.

Round-Robin DNS

A single name can have multiple A records:

example.com.    3600    IN    A    192.0.2.10
example.com.    3600    IN    A    192.0.2.11
example.com.    3600    IN    A    192.0.2.12

DNS servers return all addresses but rotate the order with each query. First query gets 192.0.2.10 first; next query gets 192.0.2.11 first. Traffic distributes across servers automatically.

But DNS is stateless. It doesn't know if a server is healthy. It can't—it's a phone book, not a doctor. Round-robin will keep sending traffic to a crashed server until you remove the record. This isn't a flaw; DNS was designed to map names to numbers, not to monitor infrastructure. Production systems with high availability requirements use dedicated load balancers that actually check server health.

A Records vs. AAAA Records

A records map names to IPv4 addresses (32-bit, like 192.0.2.10). AAAA records map names to IPv6 addresses (128-bit, like 2001:db8::1). Most domains configure both, allowing connections over either protocol. The four A's in AAAA reflect that IPv6 addresses are four times longer than IPv4.

What A Records Can't Do

A records point to IP addresses, not to other domain names. If you want one name to be an alias for another, you need a CNAME record. And you can't have both—a CNAME must be the only record for that name (DNSSEC records excepted). This constraint exists because CNAME means "this name is really that name," and mixing that with direct answers would create ambiguity.

A records also can't tell you if the server at that address is actually running. That's not DNS's job. Monitoring, health checks, and failover happen at other layers of the stack.