What is a DNS A record?

A DNS A record maps a hostname to an IPv4 address. When someone enters a domain name into a browser, the browser does not connect to the words in the domain. It asks a resolver for the address behind that name, and the A record is one of the answers that can tell the client where to send traffic.

A simple record might look like this:

www.example.com. 300 IN A 192.0.2.20

The name is www.example.com, the record type is A, the answer is an IPv4 address, and the TTL is 300 seconds. The TTL tells recursive resolvers how long they can cache the answer before checking again. In day-to-day operations, the TTL is often as important as the address because it affects how quickly planned and emergency changes reach users.

A records are common for root domains, subdomains, application hosts, API endpoints, status pages, and internal service names. They are not the only way to steer traffic, but they are still one of the simplest DNS building blocks.

How clients use the answer

A typical lookup path starts with the user's device asking a recursive resolver. If the resolver does not have a fresh cached answer, it walks the DNS hierarchy: root servers, top-level domain servers, and the authoritative servers for the domain. The resolver returns the A record to the client, and the client then opens a network connection to the returned IPv4 address.

Many sites publish both A and AAAA records. The A record supports IPv4 clients, while the AAAA record supports IPv6 clients. Modern clients may query both and choose a connection path based on address availability, network quality, and operating system behavior. That means changing an A record may not affect every user in the same way if IPv6 is also available.

Multiple A records can be returned for the same hostname. This is sometimes used for simple distribution across several addresses, but it should not be confused with health-aware load balancing. DNS can provide several possible destinations; it does not, by itself, guarantee that every returned address is healthy or close to the user.

Where A records affect operations

A records sit near the start of many user journeys, so mistakes can look like application outages even when the application itself is healthy. A wrong address sends clients to the wrong host. A stale address keeps some users on old infrastructure after a migration. A missing record can make a service unreachable even if the origin server is running normally.

They also matter for traffic management. A hostname may point directly to an origin, to a load balancer, to a CDN edge, to a reverse proxy, or to a cloud ingress address. Each option changes where TLS is terminated, where requests are logged, where security policy is applied, and which team owns incident response. The DNS record is therefore part of the control plane, not just a directory entry.

For public services, an exposed origin A record can also become a security concern. If attackers can bypass the intended edge, they may avoid rate limits, web application controls, bot rules, cache shielding, or DDoS filtering that normally apply before traffic reaches the origin. Hiding the origin is not a complete security model, but accidental direct exposure removes an important layer of operational control.

Configuration details worth checking

Start with the hostname's role. A user-facing website, an API, an admin panel, and a mail-related host may need different TTLs, address targets, and change windows. Avoid treating every record in a zone as interchangeable.

Check whether the address belongs to the infrastructure you expect. Cloud migrations, vendor changes, and temporary test environments often leave records behind. Inventory the owner of each address range, the system that terminates traffic, and the runbook for changing it.

Review the TTL before a planned cutover. A low TTL can help during a migration, but it does not make all caches disappear instantly. Some resolvers, clients, and applications cache answers independently. Lower the TTL well before the change, verify that the lower value is being served by authoritative DNS, then raise it again after the rollout is stable if that fits the service.

For hostnames with several A records, confirm whether all addresses serve the same content, support the same TLS certificates, and enforce the same security controls. Mixed backends can create intermittent errors that are difficult to reproduce because different users receive different answers.

Common failure modes

The most obvious failure is a typo or wrong IP address. Less obvious failures include records left behind after decommissioning, private addresses published in public DNS, public addresses published for internal-only services, and records that point to infrastructure no team still monitors.

TTL misunderstandings are also common. Operators may update a record and expect instant global behavior, then misread normal resolver caching as a broken deployment. The opposite can happen too: a very low TTL may increase query volume and make DNS behavior more sensitive to resolver or authoritative server problems.

Another failure mode is relying on A records for failover without health checks. If two A records are published and one backend fails, clients may still receive the failed destination until the record is removed and caches expire. For critical services, DNS should be paired with a clear failover design rather than assumed to solve availability on its own.

Security and rollout checks

Before changing an A record, capture the current answer from at least two independent resolvers and from the authoritative nameserver. After the change, repeat the checks and compare against expected TTLs. Use dig or an equivalent DNS tool, but also test the actual application path because a correct address can still lead to a TLS, firewall, routing, or virtual-host problem.

For sensitive hosts, verify that the target enforces the expected certificate, HTTP redirect behavior, security headers, access controls, and logging. If traffic should pass through an edge or reverse proxy, test that direct-origin access is not unintentionally available.

Keep a rollback value and owner ready before the change window. DNS changes are easy to make but can be slow to undo for users who have already cached the new answer. A good rollout plan treats the A record, the receiving infrastructure, and the monitoring signals as one change.

Related learning

• What is a DNS AAAA record?
• What is a DNS CNAME record?
• Common DNS issues and how to diagnose them