What Is an A Record? How DNS A Records Work
Michel Bardelmeijer is Tech Lead and Sales at redirect.pizza, where he helps DevOps and IT teams solve domain redirect challenges at scale. Michel has guided organizations like SD Worx, Zurich Airport and Harvard through complex redirect scenarios involving thousands of domains.
Have questions about bulk redirects, HTTPS migrations, or domain consolidations? Connect with Michel on LinkedIn or reach out to the redirect.pizza team.
An A record is the smallest, most-queried piece of data on the internet. Get one digit wrong and the site is dead, with no error to tell you why. Here is what it does, how DNS finds it, and how to keep that digit right.
The A record is one of the original DNS record types, defined in RFC 1035 in 1987. It does one thing: connect a domain name to an IPv4 address. Every website visit, every API call, every email delivery starts with a resolver chasing down an A record (or its IPv6 sibling, the AAAA record). Multiply that by every person on the internet and it adds up to billions of lookups per second across the global DNS infrastructure.
A records are also the most common point of failure when domains misbehave. A wrong IP looks identical to a correct one in your DNS panel, but produces a dead site. A TTL set too high makes a small DNS change take a full day to reach all visitors. A second A record added by mistake spreads traffic across two servers when you only meant to use one.
When a redirect misbehaves, the A record is often the first thing to check. Our URL Redirects Complete Guide covers the rest of the chain.
Key Takeaways
- An A record maps a domain or subdomain to a 32-bit IPv4 address (like 89.106.200.1). Most DNS lookups end with an A record as the answer.
- When a browser loads a website, a DNS resolver works through root, TLD, and authoritative name servers to find the A record. The IPv4 address it contains is what the browser uses to open the connection.
- A single domain can have multiple A records pointing to different IP addresses, a setup called round-robin DNS that gives you simple load balancing.
- TTL (Time To Live) controls how long resolvers cache an A record before re-querying. "DNS propagation" is the time it takes for caches around the internet to expire.
- IPv4 (A records) and IPv6 (AAAA records) coexist on the internet today. Most domains publish both, since visitors can arrive over either protocol.
What an A record actually is
The A in A record stands for Address. Around 90 DNS record types have been defined over the years and are tracked in the IANA DNS Parameters registry, but A is by far the most used.
An A record contains four pieces of information: the domain name it applies to (example.com), the record type (A), a TTL value in seconds, and an IPv4 address. The IPv4 address is the answer. Everything else is metadata.
In a zone file, it looks like this:
example.com. 3600 IN A 89.106.200.1
3600 is the TTL in seconds (one hour). IN means "internet class," the default. A is the record type. 89.106.200.1 is what the resolver returns to the browser.
A records live on authoritative name servers, the DNS servers responsible for a specific domain. When you edit a record at Cloudflare or Namecheap, you are editing this source of truth. Resolvers around the world cache the value temporarily, but the authoritative server is where it lives.
The DNS resolution flow with an A record
When you type example.com into a browser, here is what happens before the page starts loading:
- Local caches first. The browser checks its own cache, then the operating system cache. If either has a fresh answer, the lookup ends here. Most of the time, it does.
- The recursive resolver gets the query. This is the DNS server your ISP, router, or chosen provider (Cloudflare 1.1.1.1, Google 8.8.8.8) runs for you. It checks its own cache first.
- If the resolver does not have the answer, it asks a root name server. There are 13 root server clusters worldwide. Root does not know the IP of example.com. It knows where to find the .com TLD servers.
- The resolver then asks the .com TLD server. TLD does not know the IP either. But it knows which name server is responsible for example.com.
- Finally, the resolver asks that name server. This is where the A record lives. The server returns the IPv4 address.
- The resolver returns the answer to the browser and caches the result for the TTL. The next query from anyone using that resolver gets an instant response.
- The browser opens a TCP connection to the IP. From here, HTTP, TLS, and everything else takes over. DNS is done.
Four queries, several cache checks, all to translate one name into one number. On a warm cache the whole thing finishes in under 10 milliseconds. On a cold cache (first visit, expired TTL), 100 to 200 milliseconds.
Every other DNS record type (CNAME, MX, TXT, NS) participates in similar flows for different purposes. A records are the most common endpoint.
Inside the IPv4 address
An IPv4 address is a 32-bit number. Humans write it as four numbers separated by dots, like 192.0.2.1, but the actual value is a single 32-bit integer. Each of the four parts (called octets) is 8 bits and holds a value from 0 to 255. Total address space: about 4.3 billion (2^32).
DNS does not validate that an IP is reachable, or that a server is running there. The system is a key-value store: domain name in, IP address out. A typo (89.106.200.111 instead of 89.106.200.1) resolves fine. The browser gets the wrong IP, tries to connect, and either times out or hits the wrong server. No warning, no validation error. The mistake shows up as a broken site.
Some IP ranges are reserved for private networks and should never appear in a public A record. RFC 1918 defines three private blocks: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Add to that 127.0.0.0/8 (loopback) and 169.254.0.0/16 (link-local). A public A record pointing to one of these only works on the local network of whoever owns that private IP. A surprisingly common mistake when someone copies an internal IP to a public DNS record.
Multiple A records for one domain
A domain can have more than one A record. When a resolver queries a domain with multiple A records, the name server returns all of them, and most resolvers rotate the order on each query. The setup is called round-robin DNS, defined in RFC 1794 back in 1995. It is the simplest form of load balancing available.
In a zone file:
example.com. 300 IN A 89.106.200.1
example.com. 300 IN A 89.106.200.2
example.com. 300 IN A 89.106.200.3Three records, three IPs. Different clients connect to different servers, traffic spreads roughly evenly over time. The exact rotation depends on the resolver, since the DNS spec does not mandate a specific algorithm.
Round-robin DNS has real limitations, documented by Cloudflare and others. No health checking: if an IP goes down, the name server keeps returning it in rotation, and a portion of visitors hit a dead server until you manually remove the record. No session stickiness: the same client may hit a different IP on each request, breaking anything that depends on server-side state. And resolver caching is unpredictable: a popular resolver might serve the same IP to thousands of clients for the duration of the TTL.
A dedicated load balancer (HAProxy, AWS ALB, Cloudflare) handles health checking, session affinity, and weighted distribution that round-robin DNS cannot. Round-robin works as a budget option when you want to spread traffic without infrastructure, not as a replacement.
TTL and what propagation really means
TTL (Time To Live) is a value in seconds that controls how long resolvers and clients cache an A record before discarding it and re-querying. A TTL of 3600 means "this answer is valid for one hour." After that hour, the resolver must ask the name server again. A short TTL (300 seconds) means changes propagate quickly but resolvers query more often. A long TTL (86400 seconds, one day) means resolvers cache aggressively, cheaper for infrastructure but slower to update.
"DNS propagation" causes confusion here. People talk about it as if DNS changes are pushed out to the internet, like a broadcast. They are not. The name server has the new value the moment you save the record. What takes time is every resolver in the world realizing its cached value has expired and re-querying. If your TTL is 24 hours and you change a record at 9 AM Monday, a resolver that cached it at 8 AM Monday keeps serving the old value until 8 AM Tuesday. There is nothing you can do about that resolver. The cache thinks it has another 23 hours of validity, and your update does not exist for it until then.
The fix is to lower your TTL before you make changes, not after. Drop it to 300 seconds a week ahead of a planned change. By the time you flip the record, every resolver has either re-queried (and now has the short TTL) or never cached your record in the first place. Raise the TTL back up after the change has been stable for a few days.
"We see the same migration story every other week. Team plans the cutover for Saturday morning, flips the A record at 9, watches half their traffic still hitting the old IP at 11, and only then thinks to check the TTL. It is sitting at 86400. They are stuck until Sunday. Lower TTLs a week out, not the morning of."
Michel Bardelmeijer, Tech Lead at redirect.pizza
A records and AAAA records side by side
An A record holds an IPv4 address. An AAAA record (pronounced "quad-A") holds an IPv6 address. The two coexist because the internet runs both protocols in parallel. IPv6 uses 128-bit addresses (3.4 followed by 38 zeros worth of devices) and exists because 4.3 billion IPv4 addresses are not enough.
Most domains today publish both. The resolver returns whichever the client asks for. If you only publish an A record, your domain still works for almost everyone, but pure-IPv6 networks cannot reach you.
On apex domains (example.com without www), only A and AAAA records work, not CNAMEs. For the full breakdown of which record type to use for redirects, see A Record vs CNAME for Redirects.
How to query an A record
You do not need a DNS panel to check what A records a domain has. Two command-line tools do it in a single command.
dig is the most common DNS query tool on Linux and macOS:
dig example.com AThe output includes the IPv4 address, the TTL, and which resolver answered. dig is the go-to for serious DNS work.
nslookup is available on Windows, macOS, and Linux. Less verbose but works for basic queries:
nslookup example.comFor an explicit type, use nslookup -type=A example.com.
Both query a DNS resolver, not the name server directly. To bypass caches and check the source answer, use dig @ns1.example.com example.com A, where ns1.example.com is the name server for the domain. Web-based options (dnschecker.org, Google's Dig tool) work when you do not have terminal access.
Frequently Asked Questions
An A record maps a domain name directly to an IPv4 address. A CNAME record maps a domain name to another domain name, which then has to be resolved to an IP through its own A record. Use an A record when you have an IP address to point to, which is required on apex domains (example.com without a prefix) because DNS does not allow a CNAME at the zone apex. Use a CNAME on subdomains (www.example.com, shop.example.com) when you want to point to another hostname and let it manage the underlying IP.
Yes. A domain can have multiple A records pointing to different IP addresses. When queried, the name server returns all of them and most resolvers rotate the order, spreading traffic across the servers. This is called round-robin DNS and is the simplest form of load balancing. It has no health checking, though, so if one IP goes down the name server keeps handing it out until you remove the record. For production load balancing with failover, a dedicated load balancer is the better choice.
It depends on the TTL set on the record. The authoritative name server has the new value the instant you save it, but resolvers around the internet keep serving their cached copy until the TTL expires. With a TTL of 3600 seconds, a resolver that cached the old value will keep using it for up to an hour. With a TTL of 86400, up to a full day. To make a change take effect quickly, lower the TTL to 300 seconds about a week before the change, then raise it again once the new value has been stable for a few days.
Related Reads
- A Record vs CNAME for Redirects
- What Is a CNAME Record?
- DNS-Level vs Server-Side Redirects
- URL Redirects Complete Guide
One record, no guessing
A wrong A record fails silently. The site just does not load, with nothing to tell you why. redirect.pizza manages your DNS-level redirects with automatic HTTPS, so you point your records once and skip the server config entirely. Get started for free.
