An A record is a DNS resource record that maps a domain name to an IPv4 address. When a client looks up the name, DNS returns the address so traffic can be sent to the correct host, and changes to the record directly affect name resolution and reachability.
How an A Record Works
An A record is the most direct DNS path from a human-readable name to an IPv4 address. It is one of the core building blocks of forward resolution, and its value is that clients can keep using a stable name even when the underlying server address changes.
Because the record is returned during lookup, it sits on the critical path for reachability. A small edit can redirect traffic, restore a moved service, or break access entirely if the record points to the wrong host or the wrong environment.
Why A Records Matter in DNS Architecture
A records are usually created at the zone apex or for specific hostnames such as www, api, or mail. They are simple, but they shape how users, applications, load balancers, and monitoring systems find services on the network.
They also sit alongside other record types that solve different problems. An A record answers “what IPv4 address should this name use?”, while CNAME, MX, NS, TXT, and related records support aliasing, mail delivery, delegation, verification, and policy. Understanding that boundary helps prevent fragile DNS designs.
For protocol-level resolution behaviour, record choice, TTLs, and how DNS answers are cached, see the DNS Protocol Fundamentals for Defenders Guide.
Security Implications of A Record Changes
Because an A record controls where traffic is sent, it can become a high-value target for hijacking, misdirection, or service disruption. If an attacker can change the record, they may redirect users to a malicious endpoint, intercept traffic intended for the legitimate service, or cause outages by repointing the name to an invalid address.
That risk is especially important when DNS changes are made through shared consoles, third-party providers, or automation pipelines. The security question is not only whether the record exists, but who can change it, how quickly changes propagate, and whether the destination address is still trustworthy.
Operational mistakes can create similar exposure. A stale A record can leave users pointing at decommissioned infrastructure, while a rushed update can move a production name to an internal, test, or otherwise unintended host.
When a name should resolve to a service that may move or scale, the risk is often not the record itself but the control surrounding it, including inventory, approval, and change tracking. For takeover and cleanup scenarios caused by stale DNS entries, the Subdomain Takeover and Dangling DNS Guide is the most relevant companion resource.
Operational Use, Validation, and Related DNS Records
In practice, A records should be validated against the asset they represent, not just the domain label they carry. Teams need to know which host, load balancer, or application the address belongs to, because that ownership determines whether a change is safe.
A records are often paired with reverse expectations such as certificates, host headers, and application allowlists. If the destination address changes without those dependencies being updated, resolution may succeed while the service still fails authentication, routing, or trust checks.
DNS visibility also matters. Logging, zone reviews, and periodic comparisons against authoritative records help detect drift, accidental edits, and suspicious repointing. For defensive DNS controls, record hygiene, and detection ideas, the DNS Security Guide provides broader coverage.
For the authoritative registry of protocol parameters and DNS-related standards references, the IANA site is the canonical external reference.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | A record changes where network traffic is sent and must preserve trustworthy endpoint routing. |
| CM-3 — Configuration Change Control | A record updates are configuration changes that need approval and tracking. | |
| CM-8 — System Component Inventory | Correct A records depend on knowing which assets and services the name should map to. | |
| Recommendation — Validate destination changes and protect DNS-to-host routing paths against tampering. Track and approve A record edits through controlled change management. Maintain an accurate asset inventory so DNS records point to the intended hosts. | ||
| CIS Controls v8 | CIS-5 — Account Management | DNS record administration depends on tightly governed administrative access and ownership. |
| CIS-12 — Network Infrastructure Management | DNS is core network infrastructure and record integrity directly affects reachability. | |
| Recommendation — Restrict and review DNS admin access so only approved operators can change records. Harden and monitor DNS infrastructure to detect unauthorized or risky record changes. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org