An A record maps a name to an IPv4 address. An AAAA record does the same for IPv6. Between them they are the records that decide whether your website loads at all. Everything else in DNS is about mail, verification or convenience.
What they look like
Name Type Value @ A 203.0.113.45 www A 203.0.113.45 blog A 203.0.113.45 @ AAAA 2001:db8::1
@ means the domain itself. A bare word means that subdomain.
A domain can hold both an A and an AAAA record at the same name. They do not conflict. A visitor's device uses whichever protocol it has, preferring IPv6 where both are available.
www and the bare domain are separate
This catches people constantly, and the symptom is a site that works at one address and not the other.
Having an A record for example.com does not give you www.example.com. They are different names and each needs its own record, either two A records with the same address, or an A record for the domain and a CNAME for www pointing at it.
Both should resolve, and one should redirect to the other at the web server so you have a single canonical address. It also affects certificates: one covering only the bare domain shows a warning to everyone who types www.
Changing one to move a website
This is the smaller, safer alternative to a nameserver change, and it is underused.
If the website is moving but mail should stay where it is, changing the A record moves the site and leaves everything else untouched: MX records, SPF, verification records, subdomains pointing elsewhere. Nothing to recreate and nothing to lose.
A nameserver change hands the entire zone to a new provider that starts from defaults, which is why mail so reliably breaks during migrations. Changing nameservers goes into when that larger change is genuinely needed.
Before changing an A record, lower its TTL to 300 a day in advance. The change then spreads in minutes rather than hours, and a mistake is equally quick to correct, understanding DNS propagation explains why it has to be done ahead of time.
Two A records is not failover
Putting two addresses on the same name looks like redundancy and is not.
Resolvers return both, and clients choose between them with no knowledge of which server is actually running. If one is down, roughly half your visitors reach it anyway and see nothing.
Real failover requires something that checks whether each server is up and withdraws the address when it is not. That is a DNS service feature, not something two records achieve.
Two A records is useful for load sharing across servers that are both working, which is a different goal.
AAAA and IPv6
An AAAA record works exactly like an A record with an IPv6 address. Add one only if your server actually has IPv6 and the web server is configured to answer on it.
The failure mode is worth understanding. Devices prefer IPv6 when an AAAA record exists. If that record points somewhere not serving your site, those visitors get a failure while everyone on IPv4 sees a working site, and you are almost certainly on IPv4 yourself, so it looks fine to you.
A broken AAAA record is worse than no AAAA record. If you are unsure whether the server serves IPv6, leave it out.
Verify
dig example.com dig www.example.com dig AAAA example.com
Check both names, not just the one you use yourself. And query a public resolver to see what the wider internet has:
dig @8.8.8.8 example.com
Common problems
Bare domain works, www does not. No record for www. Add one.
Changed the record, nothing happened. Either it is still propagating, or a second A record for the same name is still present. Check the full zone instead of the record you edited.
Resolves correctly but shows the wrong site. Not a DNS problem. The domain reaches the server and the server does not know which site to serve, check the account holds that domain and its document root is right.
Works for some people, fails for others. Propagation, or two conflicting records. Compare two public resolvers.
Fails only for some visitors, consistently. Suspect an AAAA record pointing at something not serving the site.
The TTL decides how fast a change can be undone
The value attached to a record is not a detail. It is the length of time you are committed to any mistake.
dig example.com A
dig example.com A | awk '/^example/ {print "TTL:", $2, "saniye"}'
The number in the second column of the answer is how long resolvers keep it. At a day, a change made now is still being served to some visitors tomorrow evening, including a change made to fix a mistake.
Lower it well before a planned move, and remember that lowering it is itself subject to the old value. Reducing a day long TTL takes a day to take effect, which is why the reduction has to happen days ahead rather than on the morning of the change.
Both address families have to be right
Publishing an address for the newer protocol commits you to serving it, and a record pointing somewhere that does not answer is worse than no record.
dig example.com A +short dig example.com AAAA +short curl -4 -sI https://example.com/ | head -1 curl -6 -sI https://example.com/ | head -1
Clients that support the newer protocol prefer it, so a stale entry produces a site that is slow or unreachable for exactly those visitors and perfectly fine for everyone else, including you.
The failure is intermittent, affects a minority, and does not appear in any test you run from a network that lacks the protocol. If you cannot confirm the address works, removing the record is the safer state. Understanding IPv6 covers when it is worth having.
Check what the world sees, not your resolver
Your own machine caches, your provider caches, and both can show a change that has not reached anyone else.
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do printf '%-10s %s\n' "$r" "$(dig "@$r" example.com A +short | tr '\n' ' ')" done dig example.com A @"$(dig example.com NS +short | head -1)" +short
The last query asks the authoritative server directly, which is the correct answer with no caching involved. Comparing it against the public resolvers tells you whether a difference is a propagation delay or a configuration error.
If the authoritative answer is wrong, waiting will not help and the record needs fixing. If it is right and the others disagree, waiting is the only correct action.