A record

An A record, also called an address record, is the DNS resource record that maps a domain name or hostname to an IPv4 address. It is the record type most people think of when they say “point a domain to a server.” If a user visits example.com, and that hostname has an A record, DNS can return an IPv4 address such as 203.0.113.10. The browser can then connect to that IP address over the network.

A records are simple, but their operational impact is enormous. A single incorrect A record can send visitors to the wrong server, break SSL/TLS, route traffic to decommissioned infrastructure, cause intermittent regional failures, or create false uptime alerts during migrations. Understanding A records is foundational for website reliability.

A record quick reference

How A records work

DNS resolution normally begins when a client needs to turn a hostname into an address. The client asks a recursive resolver for the A record of a name. If the resolver already has a cached answer, it may return that answer immediately. If not, it follows DNS delegation from the root zone to the relevant top-level domain and then to the authoritative nameservers for the domain.

When the authoritative DNS provider has an A record for the requested owner name, it returns the IPv4 address and TTL. The recursive resolver caches that answer for up to the TTL, and the client uses the returned IP address to initiate a network connection.

Client asks:      What is the A record for www.example.com?
Resolver finds:   www.example.com. 300 IN A 203.0.113.10
Client connects:  203.0.113.10 over IPv4

Important distinction: DNS resolution is not HTTP routing

An A record only answers “which IPv4 address should this hostname resolve to?” It does not decide which website appears after the connection reaches the server. Once DNS returns the IP address, the web server, TLS configuration, virtual host, application, CDN, load balancer, and HTTP routing determine what content is served.

A record syntax and examples

DNS control panels vary, but an A record usually has the same logical fields: name, TTL, class, type, and value. In zone-file form, an A record commonly looks like this:

www.example.com.  300  IN  A  203.0.113.10

Common examples

; Root/apex domain
example.com.      300  IN  A  203.0.113.10

; www hostname
www.example.com.  300  IN  A  203.0.113.10

; API subdomain
api.example.com.  300  IN  A  203.0.113.20

; Status page subdomain
status.example.com. 300 IN A 198.51.100.25

Examples that are not valid A records

; Invalid: contains a protocol
www.example.com. 300 IN A https://203.0.113.10

; Invalid: contains a port
www.example.com. 300 IN A 203.0.113.10:443

; Invalid: contains a URL path
www.example.com. 300 IN A 203.0.113.10/app

; Invalid: contains an IPv6 address
www.example.com. 300 IN A 2001:db8::10

Apex domains, www, and subdomains

The apex domain, sometimes called the root of the zone or naked domain, is the base domain such as example.com. A subdomain is any name below it, such as www.example.com, api.example.com, or status.example.com.

A records can be used for the apex and for any subdomain. Many websites use A records at the apex and either an A record or CNAME at www. The best choice depends on whether the destination is a fixed IPv4 address, a hosting provider hostname, a CDN, or a load balancer.

TTL and caching

TTL means time to live. It is the number of seconds a resolver may cache a DNS answer. If an A record has a TTL of 300 seconds, a resolver that receives that answer may reuse it for up to five minutes before asking again.

TTL affects how quickly DNS changes appear to take effect. If you change an A record from an old IP address to a new IP address, users whose resolvers cached the old answer can continue using the old address until the cached TTL expires. This is why migrations can appear inconsistent across users, networks, and regions.

Multiple A records and round-robin DNS

A hostname can have more than one A record. Multiple A records with the same owner name form an RRset. Resolvers and clients may receive several IPv4 addresses for the same hostname.

www.example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN A 203.0.113.11
www.example.com. 300 IN A 203.0.113.12

This is often called round-robin DNS. It can distribute connections across multiple addresses, but it is not the same as a health-aware load balancer. Standard DNS does not automatically know whether one of the returned servers is healthy. If one IP address is down and still published, some clients may still receive and try that address.

When multiple A records are useful

• Basic traffic distribution across multiple equivalent endpoints.
• Publishing several CDN, load balancer, or edge addresses.
• Providing redundancy when the application can tolerate client retry behavior.
• Supporting providers that intentionally return multiple A records.

When multiple A records are risky

• When one address can fail independently and there is no health-aware DNS or load balancing.
• When each server has different content, TLS certificates, or virtual-host configuration.
• When one IP address points to a staging server or old provider.
• When troubleshooting is difficult because different users receive different addresses.

A records vs AAAA records

A records return IPv4 addresses. AAAA records return IPv6 addresses. They are separate record types and may coexist for the same hostname.

If both A and AAAA records exist, many modern clients may prefer IPv6 or use connection racing behavior depending on the operating system and network. This means an IPv6 problem can affect users even when the IPv4 A record is correct. For reliability, monitor both address families when both are published.

A records vs CNAME records

An A record points directly to an IPv4 address. A CNAME record points one hostname to another hostname. The resolver must then resolve the target name to obtain address records.

Wildcard A records

A wildcard A record can match otherwise undefined names below a zone. For example, *.example.com can answer for anything.example.com if no more specific record exists.

*.example.com. 300 IN A 203.0.113.10

Wildcards are useful for certain SaaS, preview, and tenant-subdomain patterns, but they can also hide mistakes. A typo such as wwww.example.com might resolve successfully, making errors harder to detect. Use wildcard A records deliberately, and monitor the exact hostnames that matter.

Private, reserved, and documentation IPv4 ranges

Public websites should normally use public routable IPv4 addresses. Private or reserved ranges may be valid inside private networks, VPNs, split-horizon DNS, or internal infrastructure, but they should not be used for a public website unless that behavior is intentional.

A records and DNSSEC

DNSSEC does not change what an A record is. It adds cryptographic validation around DNS data so validating resolvers can verify that answers came from the correct signed zone and were not modified in transit.

When DNSSEC is healthy, an A record answer may be accompanied by related DNSSEC records such as RRSIG records. When DNSSEC is broken, a domain may fail to resolve for validating resolvers even if the A record exists and the authoritative nameserver appears to answer.

Common DNSSEC failure patterns that affect A records

• A stale DS record remains at the registrar after changing DNS providers.
• DNSKEY records no longer match the parent DS record.
• RRSIG signatures expire or are not published correctly.
• A zone is partially migrated and signed data is inconsistent between nameservers.
• Some resolvers validate DNSSEC and fail, while non-validating resolvers appear to work.

How A records affect uptime monitoring

Uptime monitoring begins with name resolution. If a monitor checks https://www.example.com, it must first resolve the hostname. If the A record is missing, stale, inconsistent, or pointed to an unhealthy address, the monitor may report downtime even when the web application code is not the root cause.

What an uptime monitor should capture

• The hostname checked.
• The resolved IPv4 address or addresses.
• The resolver or monitoring location that observed the answer.
• The DNS status, such as successful answer, NXDOMAIN, SERVFAIL, timeout, or no A record.
• The HTTP status code and response time after resolution succeeds.
• The TLS certificate presented by the server reached at that IP address.

A record troubleshooting checklist

1. Confirm the record exists at the authoritative nameserver

Start with the authoritative source, not only a public recursive resolver. Public resolvers may still have cached old answers.

dig A www.example.com

dig +trace A www.example.com

dig @ns1.example-dns-provider.com A www.example.com

2. Compare multiple resolvers

Compare answers from multiple recursive resolvers to identify caching, propagation, or DNSSEC differences.

dig @1.1.1.1 A www.example.com
dig @8.8.8.8 A www.example.com
dig @9.9.9.9 A www.example.com

3. Check the apex and www separately

example.com and www.example.com are different DNS owner names. A working apex does not mean www is correct, and a working www record does not mean the apex is correct.

4. Confirm the returned IP serves the expected website

DNS may point to a reachable server that is still the wrong server. Test the HTTP layer and TLS layer after confirming DNS.

curl -I https://www.example.com

curl --resolve www.example.com:443:203.0.113.10 -I https://www.example.com

5. Look for split-horizon DNS

Split-horizon DNS returns different answers depending on where the query comes from. This may be intentional for private networks, but it can create confusing differences between internal users, public users, and monitoring locations.

6. Check for DNSSEC validation errors

If one resolver returns the A record and another returns SERVFAIL, DNSSEC validation should be investigated. Compare validating and non-validating resolvers and inspect DS, DNSKEY, and RRSIG records.

Common A record failure modes

A record best practices

• Use A records when the destination is a stable IPv4 address you control or were instructed to use.
• Use CNAME or provider-specific ALIAS/ANAME/CNAME flattening when the provider manages changing IP addresses behind a hostname.
• Keep TTLs low before migrations and raise them only after the new destination is stable.
• Monitor the exact hostname customers use, not only the apex domain.
• Monitor every published address family: A for IPv4 and AAAA for IPv6.
• Do not publish multiple A records unless every returned IP can safely serve the same production traffic.
• Remove stale A records after provider migrations.
• Validate TLS and HTTP behavior after changing DNS, not just DNS resolution.
• Avoid pointing public hostnames to private IPv4 addresses unless you intentionally use split-horizon DNS.
• Document the owner and purpose of each production A record.

RFC and standards references

The A record is part of the original DNS specification. These are the most important primary references for understanding A records and surrounding DNS behavior:

Related DNS record types