What Is a DNS A Record? IPv4 Addresses, Hostnames, and Common Mistakes

A DNS A record connects a hostname to an IPv4 address. When someone looks up a name such as www.example.com, an A record can supply an address such as 203.0.113.42 that a client can use to reach the host. In DNS terminology, an A record stores a 32-bit Internet address. RFC 1035, section 3.4.1

That is the short answer. The useful follow-up is: which hostname needs the record, what address should it contain, and is DNS actually the layer that is failing? This guide explains how to answer those questions without treating every website issue as an A-record problem.

Start with the exact hostname

DNS records apply to names, not to an entire website in the abstract. example.com, www.example.com, api.example.com, and app.example.com are different names and can have different records. Before changing anything, copy the exact hostname from the browser error, hosting provider, deployment setting, or service instructions.

For example, these are separate questions:

example.com       → Which address should the root domain use?
www.example.com   → Does the web hostname point where visitors expect?
api.example.com   → Does the application API use its own address or provider?

An A record is appropriate only when the destination has given you an IPv4 address for that particular name. Do not substitute an address from an old support ticket, a command output from a different hostname, or a value that merely looks familiar. A shared host, load balancer, CDN, or platform can change addresses and may require a CNAME or another provider-specific setup instead.

What an A record contains

An A record has an owner name, a type, a time to live (TTL), and an IPv4 address. DNS messages represent the address as four octets, conventionally written in dotted-decimal form. RFC 1035, section 3.4.1

In a DNS-provider dashboard, a simplified entry might look like this:

Field	Example	What it identifies
Host or name	www	The hostname relative to the zone, often www.example.com
Type	A	An IPv4 address record
Value or target	203.0.113.42	The IPv4 address supplied by the destination operator
TTL	300	A cache lifetime expressed in seconds

The values above are documentation addresses, not an instruction to route a real website to them. RFC 5737 reserves 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 for examples and documentation. RFC 5737

TTL is a caching instruction, not a guarantee that every resolver will show a change at one exact moment. A resolver can have cached the prior answer before the change. That is why an authoritative lookup and a public-resolver lookup may differ temporarily after a DNS update. Keep the old value, the change time, the hostname, and the intended TTL in the troubleshooting record.

A record vs. AAAA record vs. CNAME

These record types solve different problems:

Record	Purpose	Example value
A	Connects a name to an IPv4 address	203.0.113.42
AAAA	Connects a name to an IPv6 address	2001:db8::42
CNAME	Makes one domain name an alias of another domain name	target.hosting.example

An AAAA record is the IPv6 counterpart to an A record; its RDATA is a 128-bit IPv6 address. RFC 3596, section 2.2 A CNAME record identifies an alias rather than directly supplying an address. RFC 1034, section 3.6.2

That distinction prevents a common mistake: replacing a required CNAME with an A record just because both can eventually lead a browser to a website. A provider that asks for a CNAME may use its target name to manage routing, certificates, or future infrastructure changes. Follow the destination provider's exact record type, hostname, and target instead of translating it into an address by hand.

At a single owner name, a CNAME should not coexist with other DNS data. RFC 2181 states that if a CNAME record is present at a node, no other data should be present there. RFC 2181, section 10.1 If a dashboard rejects an A record beside an existing CNAME for the same hostname, that is a signal to review the intended configuration, not to force a duplicate entry.

Check an A record before changing it

Use this small sequence to reduce accidental changes:

1. Identify the complete hostname and the purpose of the record: website, API, redirect, verification, or another service.
2. Obtain the desired record type and value from the destination operator's current documentation or control panel.
3. Inspect the existing A, AAAA, and CNAME records for that exact hostname. Record them before editing.
4. Make one deliberate change, then query the exact hostname and record type.
5. Compare the published result with the value you intended to publish. If it matches but the service still fails, continue at the TLS, HTTP, hosting, firewall, or application layer.

yukt.tools includes a DNS lookup utility, which can help inspect a hostname's published DNS response. Use it to examine a non-sensitive lookup result; it cannot determine which address a third-party host intends you to configure or prove that the web application behind an address is healthy.

Do not confuse DNS resolution with website health

An A-record answer establishes only that DNS returned an IPv4 address for the name queried. It does not prove that the address is reachable, that a web server recognizes the hostname, that the TLS certificate is valid, or that the application returns the right page.

When an A lookup returns the expected address but a site is still down, check the next layer in order:

• Can the network reach the address on the intended port?
• Does the TLS certificate cover the requested hostname?
• Does the web server or CDN route that hostname to the intended site?
• Does the application return a successful response after the connection is made?

Conversely, do not edit an A record to solve a browser certificate warning or an application error unless the hosting provider has confirmed the address itself is wrong. DNS changes can create a second problem while leaving the original one untouched.

Frequently asked questions

Does every website need an A record?

No. A hostname may use an AAAA record for IPv6, a CNAME where the DNS provider and destination support that arrangement, or a provider-managed configuration. A domain can also have more than one A record for the same name, which returns multiple addresses; the right configuration depends on the service operating that name. Do not add an A record solely because a site has a web address.

How long does an A-record change take to work?

There is no one universal propagation time. Existing resolver caches may retain the previous answer until the applicable TTL expires, while authoritative servers can show the new zone data sooner. First verify that the authoritative zone has the intended record, then compare public-resolver results and note the TTL rather than repeatedly changing the record.

Why does my A record look correct but the site still fails?

The DNS step may be complete while another layer fails. The address could be unreachable, the server may not be configured for that hostname, the certificate may be wrong, or the application may be unhealthy. Preserve the confirmed DNS result and investigate the first layer that fails rather than changing a known-good record.

Sources and research

1. RFC 1035, section 3.4.1: A RDATA format — IETF specification of the DNS A record and its 32-bit Internet address, accessed 2026-10-19.
2. RFC 5737: IPv4 Address Blocks Reserved for Documentation — IETF specification reserving the example IPv4 ranges used in this guide, accessed 2026-10-19.
3. RFC 3596, section 2.2: AAAA RDATA format — IETF specification of the DNS AAAA record and its IPv6 address data, accessed 2026-10-19.
4. RFC 1034, section 3.6.2: Aliases and canonical names — IETF description of CNAME aliases, accessed 2026-10-19.
5. RFC 2181, section 10.1: CNAME resource records — IETF clarification that a CNAME node cannot have other data, accessed 2026-10-19.