What are DNS records? A, AAAA, CNAME, MX, TXT and NS explained
This guide covers the six DNS record types you will actually touch when you run a website or mail on your own domain: A, AAAA, CNAME, MX, TXT and NS. Each type gets a one-line definition, a realistic example and the classic mistake we keep seeing in support tickets. It is written for developers and admins who edit their own zones, and it finishes with TTL strategy, how propagation really works, and the dig commands to verify everything.
The six record types, one by one
A: name to IPv4 address
An A record maps a hostname to an IPv4 address. It is the record that makes your domain open in a browser.
example.com. 3600 IN A 203.0.113.10
Classic mistake: publishing the server's internal address. An A record pointing at 192.168.1.20 resolves fine and then times out for everyone outside your own network. Always publish the public IP.
AAAA: name to IPv6 address
An AAAA record does the same for IPv6.
example.com. 3600 IN AAAA 2001:db8:10::1
Classic mistake: adding an AAAA record for a server that does not actually speak IPv6. Clients that prefer IPv6 try it first, hang, and only some of them fall back cleanly, so you get slow or broken page loads that are hard to reproduce. Publish AAAA only after you have tested the address yourself.
CNAME: alias to another name
A CNAME makes one name an alias for another name, and the lookup then continues at the target.
www.example.com. 3600 IN CNAME example.com.
Classic mistake: a CNAME at the zone apex, on example.com itself. The standard forbids it because a CNAME cannot coexist with any other record for the same name, and the apex must also carry SOA and NS records. Use an A or AAAA record at the apex, or your DNS provider's ALIAS or ANAME type if it offers one.
MX: where mail is delivered
MX records name the servers that accept mail for the domain, with a priority number where lower wins.
example.com. 3600 IN MX 10 mail.example.com. mail.example.com. 3600 IN A 203.0.113.25
Classic mistake: an MX pointing at an IP address. The right-hand side of an MX must be a hostname that has its own A or AAAA record; MX 10 203.0.113.25 is invalid and strict mail servers will refuse to deliver. The target should also not be a CNAME.
TXT: free text, mostly mail policy
TXT records hold free-form text. In practice they carry mail policy (SPF, DKIM, DMARC) and domain ownership proofs.
example.com. 3600 IN TXT "v=spf1 mx a -all"
Classic mistake: quoting. Most control panels add the quotes for you, so pasting a value that already contains them publishes literal quote characters and SPF validation fails. The other trap is length: one quoted string holds at most 255 characters, so a long DKIM key must be split into several quoted strings. Verify the published value with dig instead of trusting the form.
NS: who is authoritative for the zone
NS records declare which name servers are authoritative for the zone.
example.com. 86400 IN NS ns1.cloudhosting.lv. example.com. 86400 IN NS ns2.cloudhosting.lv.
Classic mistake: editing NS records inside the zone and expecting the world to follow. The delegation that resolvers actually use lives at the registry and is changed through your registrar. If the two disagree, the registry wins and your zone edits stay invisible.
TTL: cache lifetime and the pre-migration trick
TTL is the number of seconds a resolver is allowed to cache an answer. 3600 is a reasonable default for most records, and 86400 suits records that never change. A low TTL means faster changes but more queries hitting the name servers.
Before any planned move, use the standard trick:
- Lower the TTL of the record you will change to 300, at least one full old TTL before the migration. A day earlier is safe.
- Wait out the old TTL so every cache has picked up the short value.
- Change the record. The worst-case stale window is now 5 minutes instead of an hour or a day.
- Once the new server is confirmed working, raise the TTL back to its normal value.
How propagation actually works
There is no global push. When you change a record, nothing gets sent anywhere: authoritative servers simply start giving the new answer to whoever asks. Every resolver that cached the old answer keeps returning it until its own copy expires, and since each resolver fetched the record at a different moment, the copies expire at different moments. That is the whole explanation of "the site works for me but not for you" during a migration.
Two consequences follow. You cannot make remote caches forget a record early, which is exactly why the TTL trick above matters. And NS changes are the slowest of all, because the TLD servers hand out the delegation with a TTL of their own, commonly 24 to 48 hours, regardless of what you set in the zone.
Checking every record with dig
dig ships with every Linux distribution and with macOS. The +short flag prints just the answer.
dig A example.com +short dig AAAA example.com +short dig CNAME www.example.com +short dig MX example.com +short dig TXT example.com +short dig NS example.com +short
Three variants worth memorizing:
# ask the authoritative server directly, bypassing every cache dig A example.com @ns1.cloudhosting.lv +short # run it twice against your resolver and watch the TTL count down dig A example.com # walk the full delegation chain from the root servers dig A example.com +trace
The authoritative query is the important one. If it already returns the new value, your change is live and everything else is caches draining. The plain query shows the remaining TTL in the second column, which tells you exactly when your resolver will refetch.
Where you will edit this in practice
Every domain needs a working zone before anything else works, so the usual order is: get the domain, point the NS records at your DNS provider, then create A, MX and TXT records for the services you run. If you register a domain with us, DNS management is included and the NS delegation is set correctly from the start. On our web hosting plans the A, MX and SPF records are created for you, which removes most of the mistakes described above. Either way, keep dig in your toolbox: it answers in one second what a support ticket answers in an hour.