How to Configure an A Record: A Practical Walkthrough

Same Four Fields, Every Provider

Every DNS provider's interface looks slightly different, but underneath the styling, adding an A record always comes down to the same four inputs: which name it applies to, the record type, the target IPv4 address, and the TTL. Once you understand those four decisions independently of any specific dashboard, moving between providers — or reading someone else's screenshot in a support ticket — stops being confusing.

This walkthrough covers the decisions themselves, then how they map onto a handful of common environments: standard hosting dashboards, cloud DNS platforms with their own quirks, and CDN-fronted setups where the "right" configuration isn't always the obvious one.

Step 1: Decide Between Apex and Subdomain

The very first decision is which name you're actually configuring. The apex (or root) domain — example.com with nothing in front of it — behaves differently from a subdomain like www.example.com or app.example.com in one important way: the apex generally cannot use a CNAME record, because a zone's apex must also hold other required record types (like NS and SOA records), and CNAME can't coexist with anything else at the same name. This is exactly why apex domains are so often configured with an A record even when the target infrastructure would otherwise prefer a CNAME-style pointer.

Step 2: Determine the Correct Target IP

Where this IP comes from depends entirely on what's serving the site. For traditional hosting, it's the server's public IP, usually visible in the hosting provider's own dashboard. For a CDN-fronted deployment, it's whatever anycast or edge IP the CDN documentation specifies — not the origin server's IP, since pointing directly at origin would bypass the CDN entirely. For a cloud load balancer, it's the load balancer's assigned static or elastic IP, not any individual backend instance.

Step 3: Set an Appropriate TTL

Pick a TTL based on how likely you are to need to change this record again soon. If this is a first-time setup with a stable long-term IP, 3600 seconds (one hour) is a common, sensible default. If you're mid-migration or expect to make further changes, drop to 300 seconds until things stabilize, then raise it back up afterward.

Step 4: Provider-Specific Configuration Patterns

The concepts above apply everywhere; the interface details vary. A general mapping of common environments:

Home Networking: A Records Without Public DNS

Not every A-record-equivalent configuration touches the public internet. A home router's local DNS resolver, or a manually edited hosts file on an individual machine, can hold name-to-IP mappings that behave identically in principle but are resolved entirely on the local network, never reaching the public DNS hierarchy at all. This is common for accessing devices like a home NAS or a self-hosted service by a friendly name instead of memorizing a local IP, and it's worth knowing that changes here have zero effect on how the outside world resolves anything — they're invisible beyond your own network.

Enterprise DNS: Change Control Around A Records

In larger organizations, configuring an A record often isn't just a dashboard edit — it goes through a change management process: a ticket, a peer review of the proposed record, a scheduled maintenance window, and a documented rollback plan. This isn't bureaucracy for its own sake. A single mistyped A record on a production apex domain can take an entire public-facing service offline, and the blast radius scales with how much traffic depends on that one name. Treating A record changes on critical domains with the same rigor as a production deployment, rather than a quick DNS tweak, reflects that real risk.

Verifying the Change Actually Worked

Saving a record in a dashboard is not the same as confirming it works. A proper verification step queries the record externally, not just trusts the dashboard's confirmation message:

1. Query the record directly with dig A yourdomain.com +short @8.8.8.8, or use A Record Lookup for the same check without a terminal.
2. Confirm the returned IP matches exactly what you intended — a single wrong digit is easy to miss visually.
3. If it doesn't match yet, check whether the previous TTL simply hasn't expired at the resolver you're querying, rather than assuming the change failed.
4. Test from more than one external vantage point if the result seems inconsistent, since local caching can vary by network.

Configuration Reference: A Best-Practice Checklist

Related Tools

Verify any A record change instantly with A Record Lookup. Check how far a change has propagated with DNS Propagation Checker. For the complete record set beyond just A, use DNS Lookup, For decoding what happens when it goes wrong, see A Record Errors, and for the underlying mechanics, A Record Explained.