DNS A Record Explained
dns a record · a record lookup · ipv4 dns record · aaaa record
What DNS A and AAAA records do, how A record lookup tools work, CDN caveats, and verifying IPv4/IPv6 before go-live.
By DN01 Network Team
The A record maps a hostname to an IPv4 address. AAAA does the same for IPv6. Together they answer «where does this name point on the network?» — the first record type most operators change when moving web hosting or pointing a subdomain at a SaaS provider.
Use the DNS Checker for a combined view (A, AAAA, CNAME conflicts, and sibling MX/TXT). Use DIG when you need only A answers from a specific resolver.
A and AAAA lookups are also the bridge to TLS: once you know which IP answers for a hostname, run the SSL Certificate Checker on the same name to confirm the certificate matches what clients expect after a migration.
How A records work
Example: `www.example.com A 93.184.216.34`. Multiple A records at one name may round-robin. TTL controls cache lifetime — lower before intentional changes.
Never place a CNAME at the same label as other data (including A) per DNS rules; use ALIAS/ANAME at apex on providers that support it instead.
Authoritative NS must publish the A or AAAA you intend — recursive resolvers only cache what they receive. After edits, query with the DNS Checker and, if needed, DIG type A against each listed nameserver to confirm the zone file matches the panel.
A vs AAAA in practice
Publish AAAA when your origin supports IPv6; browsers prefer it when available. If only A exists, IPv6-only clients may fail unless a proxy handles dual stack.
After enabling CDN orange-cloud modes, A answers may show anycast IPs — that is expected. Compare grey-cloud vs orange-cloud in the DNS Checker when debugging origin routing.
Some SaaS onboarding flows ask for a temporary A record to a verification IP before switching to CNAME — document both phases in change tickets and re-check A answers after the final cutover.
Troubleshooting A record issues
Site down but A looks correct? Check TLS on the new IP with the SSL Certificate Checker and HTTP headers on the vhost. Wrong A often means editing the wrong DNS zone (child domain vs apex).
Flush local OS cache or query from an incognito session; stale TTL is the usual cause of «panel shows new IP, laptop shows old».
Split-horizon DNS (internal vs public) causes «works in office, fails on mobile» — always test from an external checker, not only from the corporate resolver.
A record change checklist
Before migration: capture baseline A/AAAA with the DNS Checker; lower TTL if policy allows. During cutover: update authoritative records, wait one TTL window, diff public answers. After cutover: verify HTTPS and redirects on every hostname that shares the zone.
If you use GeoDNS or traffic steering, A answers may differ by resolver location — note which region you tested when escalating to CDN support.
Pair A checks with WHOIS nameserver fields when delegation recently changed — empty zones at new NS look like «A is wrong» when the real issue is missing records at the new host.
Frequently asked questions
- How is A different from CNAME?
A returns an IP address. CNAME aliases one name to another name. Apex CNAME is traditionally invalid; use provider-specific ALIAS records instead.
- Can I have multiple A records?
Yes — simple load distribution. Ensure each target serves identical content or health checks.
- What TTL should I use?
300–900 seconds before migrations; higher in steady state to reduce query load.
- Does A record affect email?
Not directly — mail uses MX. But misconfigured web A does not explain mail failures; check MX/TXT separately.
- Why does DIG show a different A than DNS Checker?
Different resolvers or query timing. Compare TTL and query authoritative NS with DIG @ns1.example.com A if caches disagree.