A Records Explained: The Most Important DNS Record

If you have ever wondered how typing a domain name into a browser magically loads a website, the answer almost always starts with a DNS A record. The A record is the oldest, most fundamental building block of the Domain Name System. It maps a human-readable hostname to an IPv4 address, and without it, your website, mail server, API, and virtually every internet-facing service simply would not be reachable. Whether you are setting up a brand-new domain, migrating a site to a new host, or chasing down why your site went dark at 2 a.m., understanding A records is non-negotiable.

What Is a DNS A Record?

An A record (short for Address record) is a DNS resource record that associates a domain or subdomain name with a 32-bit IPv4 address. It is defined in RFC 1035, which dates back to 1987, making it one of the original DNS record types. The structure is straightforward:

• Name: The hostname, such as example.com or www.example.com
• Type: A
• TTL: Time-to-live in seconds (e.g., 3600 means one hour)
• Value: An IPv4 address in dotted-decimal notation (e.g., 203.0.113.42)

When a user types example.com into their browser, a recursive DNS resolver queries the authoritative nameserver for that domain and retrieves the A record. The IP address returned is where the browser then sends its HTTP or HTTPS request. That is the entire lookup chain in one sentence.

How an A Record Lookup Actually Works

The process is fast but involves several steps happening behind the scenes in milliseconds:

1. The browser checks its local DNS cache. If the A record is still within its TTL window, it uses the cached IP and skips the rest.
2. If no cache entry exists, the query goes to the operating system resolver, which checks its own cache and the hosts file.
3. If still unresolved, the query reaches the recursive resolver (usually provided by your ISP, Google, or Cloudflare).
4. The recursive resolver walks the DNS hierarchy: root servers, then TLD nameservers (e.g., .com), then the authoritative nameserver for your domain.
5. The authoritative nameserver returns the A record with the IP address and TTL.
6. The resolver caches the result and returns it to the browser.

The entire round trip typically completes in under 100 milliseconds on a warm network. The TTL controls how long intermediate resolvers cache the result before re-querying, which is why lowering your TTL before a server migration matters so much.

A Records vs. CNAME, AAAA, and Other Record Types

New users often confuse A records with similar-looking record types. Here is how they differ:

• A record: Maps a hostname to an IPv4 address. Direct, definitive.
• AAAA record: Does exactly the same thing but for IPv6 addresses (128-bit). Most modern setups publish both A and AAAA records for dual-stack support.
• CNAME record: Maps a hostname to another hostname (an alias), not directly to an IP. A CNAME for www pointing to example.com means resolvers first look up the A record for example.com. You cannot use a CNAME at the zone apex (naked domain) on most DNS providers.
• MX record: Handles email routing. MX records point to hostnames, which must themselves have A (or AAAA) records.

Common A Record Configurations

Pointing a Naked Domain to a Web Server

This is the most common use case. You want example.com (no www) to resolve to your server. In your DNS zone, you create an A record with the host field set to @ (which represents the root of the zone) and the value set to your server IP:

Pointing a www Subdomain

Many registrars and hosts still recommend publishing a separate A record for www, even if you also have a CNAME. This avoids CNAME-at-apex issues and removes one extra lookup hop:

Round-Robin Load Balancing

You can assign multiple A records to the same hostname, each pointing to a different IP. Resolvers return all of them in a rotating order, spreading client connections across multiple servers. This is primitive load balancing with no health-check awareness, but it is simple and free:

Subdomain for a Specific Service

Isolating services to subdomains is clean and makes migrations easier. For example, pointing an API subdomain to a separate application server:

How to Create or Edit an A Record

The exact steps depend on where your DNS is hosted. The most common locations are your domain registrar (GoDaddy, Namecheap, Google Domains) or a separate DNS provider (Cloudflare, Route 53, DNSimple). Here is the general workflow:

1. Log into your DNS provider's control panel.
2. Navigate to the DNS management section for your domain. Cloudflare calls it DNS, cPanel calls it Zone Editor, GoDaddy calls it DNS Management.
3. Click Add Record or Add New Record.
4. Set the type to A.
5. Enter the hostname in the Name or Host field. Use @ for the root domain.
6. Enter the IPv4 address in the Value or Points To field.
7. Set the TTL. For most stable records, 3600 (1 hour) is reasonable. Drop it to 300 (5 minutes) before a planned migration.
8. Save the record.

To edit an existing A record, find it in the list, click the edit or pencil icon, change the IP address, and save. To delete one, click the trash icon or delete button next to it. Always double-check you are editing the correct record, especially when multiple subdomains share similar names.

Verifying Your A Record Is Working

Never assume a record saved correctly. Always verify. The fastest method is the command line. On Linux, macOS, or Windows Subsystem for Linux:

On Windows Command Prompt or PowerShell:

To query a specific nameserver directly (bypassing your local cache and confirming the authoritative answer):

If you want to check which authoritative nameservers are being used for your domain:

You can also use the DNS Lookup tool on this site to run an A record lookup from our servers without needing terminal access.

Troubleshooting A Record Problems

Wrong IP Address Returned

The most common cause is a stale cache. Recursive resolvers hold A records for the duration of the TTL set at the time the record was last fetched. If you changed the IP on your server but the old record had a TTL of 86400 (24 hours), resolvers can serve the old IP for up to a full day. There is no way to force third-party resolvers to flush their cache immediately. Your only leverage is setting a low TTL before the change, not after.

To check whether the problem is your local cache specifically, flush it:

No A Record Found at All

If dig returns a NXDOMAIN (non-existent domain) or an empty answer section, the record either does not exist or the wrong nameservers are being queried. First, confirm which nameservers are authoritative for your domain:

Then query those nameservers directly:

If the record shows up when querying the authoritative nameserver but not from 8.8.8.8, propagation is still in progress. If the record is absent even on the authoritative nameserver, it was never created or was accidentally deleted. Go back into your DNS panel and re-add it.

Site Loads for Some Users but Not Others

This is a classic propagation symptom. Different resolvers refresh their caches at different times. A user on Comcast may be seeing the old IP while a user on Verizon already has the new one. This is expected and temporary. Use the propagation checker to get a global view of which resolvers are seeing which IP.

A Record Correct but Site Still Down

If the A record resolves to the right IP but the site is unreachable, the problem is not DNS. Check that:

• The web server process (nginx, Apache, etc.) is actually running on that IP.
• Port 80 and 443 are open in the firewall or security group rules.
• The server is not blocking requests via hosts.deny, fail2ban, or a WAF rule.
• SSL/TLS is configured correctly if you are using HTTPS.

Best Practices for Managing A Records

Following a few simple practices will save considerable pain during migrations and incidents:

• Lower TTL before changes: Set TTL to 300 seconds at least one full TTL cycle before you plan to change the IP. After the change, raise it back to 3600 or higher.
• Document your zone: Keep a spreadsheet or version-controlled zone file so you can restore records quickly after an accidental deletion.
• Use a monitoring tool: Services like UptimeRobot or Pingdom will alert you within minutes if your A record starts resolving to an unexpected IP, which can happen after an account compromise or accidental edit.
• Separate authoritative DNS from your registrar: Moving your DNS to a dedicated provider like Cloudflare gives you faster propagation, a better API, and more granular TTL control than most registrar DNS panels offer.
• Audit regularly: Old A records pointing to decommissioned IPs can be claimed by another customer at a cloud provider and exploited for subdomain takeover. Delete records you no longer need.

A Records and SSL Certificates

When you provision a TLS certificate using ACME (Let's Encrypt, ZeroSSL), the certificate authority performs a DNS lookup to verify that your server controls the domain. If your A record points to the wrong server, HTTP-01 domain validation will fail, and you will not receive a certificate. Always confirm the A record resolves to the correct IP before running certbot or any ACME client. The error message Invalid response from http://example.com/.well-known/acme-challenge/ is almost always a sign that the A record is wrong or has not finished propagating.

The Difference Between Proxied and Unproxied A Records

If your DNS is hosted on Cloudflare, you will see an orange cloud icon next to each record. When the cloud is orange, Cloudflare proxies the traffic through its network, meaning the A record returned to clients is a Cloudflare anycast IP, not your real server IP. This enables DDoS protection, caching, and Cloudflare's WAF. When the cloud is grey, the record is DNS-only and resolvers receive your actual server IP. For most public-facing web traffic, the proxied (orange cloud) setting is recommended. For records that must not be proxied, such as mail server A records or game server IPs, use DNS-only.

Understanding A records is not just academic. Every web migration, every SSL setup, every CDN configuration, and every server move will require you to touch an A record at some point. Get comfortable with the lookup commands, keep your TTLs sensible, and verify changes immediately after saving them. The DNS system is reliable, but it rewards those who understand how it caches and propagates changes.