What DNS is and what A, AAAA, CNAME, MX and TXT records are for

DNS (Domain Name System) is the system that turns human-readable domain names, such as blog.aimran.es, into the IP addresses computers use to connect. It works as a distributed, hierarchical database: when you type a domain, your device asks a chain of servers until it gets the answer, which is cached for the time indicated by the TTL. A domain’s configuration is made up of records of different types: A and AAAA point to IP addresses, CNAME creates an alias to another name, MX says where email is received and TXT stores text for verifications and email policies.

This article explains how a name is resolved, what each record does, why changes “take time to propagate” and how to check all of it from the terminal.

How a domain is resolved

When the browser needs the IP of blog.aimran.es:

1. It checks the local cache (operating system or browser). If a valid answer is there, it stops.
2. If not, it asks the configured recursive resolver (your ISP’s, or a public one such as 1.1.1.1 or 8.8.8.8).
3. The resolver, if it does not have it cached either, asks the root servers, which point it to the top-level domain servers (.es).
4. The .es servers point it to the authoritative servers for aimran.es (the domain’s NS records).
5. The authoritative server answers with the requested record, and the resolver returns it to the browser and caches it for the TTL.

All of this takes milliseconds and, thanks to caches, most of the time it never reaches steps 3 and 4.

The most used record types

Record	What it does	Example value
A	Maps a name to an IPv4 address	203.0.113.10
AAAA	Maps a name to an IPv6 address	2001:db8::10
CNAME	Alias: states that one name is equivalent to another name	blog.aimran.es → site.hosting-provider.net
MX	Servers that receive the domain’s email, with priority	10 mail.provider.com
TXT	Free text: ownership verification, SPF, DKIM, DMARC	v=spf1 include:_spf.provider.com -all
NS	Authoritative name servers for the domain	ns1.dns-provider.com
CAA	Which authorities may issue TLS certificates for the domain	0 issue "letsencrypt.org"

A and AAAA

These are the “final” records: they give the IP. One name can have several A records (the client picks one), which serves as basic load distribution. If your server has IPv6, add the AAAA; more and more mobile networks prefer it.

CNAME: an alias with an important restriction

A CNAME says “this name is another name”: blog.aimran.es → site.provider.net, and the resolver carries on resolving the second. It is the usual choice for subdomains hosted on platforms (Netlify, Vercel, GitHub Pages, Cloudflare Pages), because the provider can change its IPs without you touching anything.

The restriction, defined in RFC 1034 (section 3.6.2): a name with a CNAME cannot have any other record. And the root domain (aimran.es, the apex) always has NS and SOA records, so it cannot be a CNAME. To point the apex at a platform there are two ways out: use the A/AAAA records the provider gives you, or use the non-standard features many DNS servers offer (ALIAS, ANAME or “CNAME flattening”), which resolve the alias server-side and return an IP.

MX: where email arrives

MX records indicate the incoming mail servers and their priority (lower number, higher priority). If you buy email from a provider, it will give you the exact values. Without MX, email to your domain has nowhere to go.

TXT: verifications and anti-spam policies

TXT records hold arbitrary text and are mainly used for:

• Verifying ownership of the domain with services such as Google Search Console or email providers (they ask you to add a specific value).
• SPF (RFC 7208): which servers may send email on behalf of your domain.
• DKIM: the public key that signs your outgoing email.
• DMARC: what to do with email that fails SPF/DKIM and where to send reports.

If you send email from the domain (even just the contact form), setting up SPF, DKIM and DMARC is what keeps you out of the spam folder.

TTL and the famous “propagation”

Every record carries a TTL (time to live) in seconds: how long resolvers may keep the answer cached. With a TTL of 3600, a resolver that looked up your A ten minutes ago will keep returning the old IP for another fifty, even if you have already changed it.

That is all “propagation” is: there is no process pushing the change around the world, just caches expiring at different rates. Hence the standard technique for a migration: lower the TTL (for example, to 300) a day or two before the change, make the change, and when everything works raise it again.

How to check records with dig

dig comes installed on macOS and most Linux distributions (dnsutils or bind-utils package); on Windows you can use nslookup or Resolve-DnsName in PowerShell.

# A record (answer only)
dig +short blog.aimran.es A

# MX and TXT records of the root domain
dig +short aimran.es MX
dig +short aimran.es TXT

# Ask the authoritative server directly, bypassing caches
dig @ns1.dns-provider.com aimran.es A

# See the remaining TTL in a public resolver's cache
dig @1.1.1.1 blog.aimran.es A

Querying the authoritative server directly (@server) is how you find out whether your change is in place, regardless of what the caches say.

Common mistakes

1. Trying to put a CNAME on the apex or next to other records of the same name: the panel will reject it or the domain will stop working.
2. Changing records with a high TTL and expecting the change to be immediate.
3. Forgetting the AAAA during a migration: the A points to the new server, the AAAA to the old one, and users on IPv6 see the old site.
4. Adding several SPF records: there can be only one; combine the include: entries in the same record.
5. Not setting a CAA: not mandatory, but limiting which authorities may issue certificates for your domain is a cheap security measure.

Conclusion

DNS is a chain of questions with a cache at every link. A/AAAA records give the IP, CNAME delegates to another name (never at the apex), MX receives email and TXT verifies and protects your identity when sending it. Once you understand TTL, you stop waiting for “propagation” and plan changes instead; once you use dig against the authoritative server, you always know what is really configured.