The most surprising thing about DNS record types is how little they actually "do" and how much they "mean." They’re not commands; they’re labels that tell other systems how to interpret a name.
Let’s see what that looks like in practice. Imagine you’re setting up a new web server. You’ve got its IP address, say 192.0.2.1. You want www.example.com to point to it.
Here’s the Route 53 console, ready for a new record:
Hosted zone: example.com
Record name: www.example.com
Record type: A
Value: 192.0.2.1
TTL: 300 seconds
And here’s what happens when someone’s browser asks for www.example.com:
- The browser asks a local DNS resolver (like your ISP’s or Google’s
8.8.8.8). - The resolver, if it doesn’t have the answer cached, asks the root DNS servers.
- The root servers say, "I don’t know
www.example.com, but I know who to ask for.com." - The resolver then asks the
.comTLD servers. - The
.comservers say, "I don’t knowwww.example.com, but I know who to ask forexample.com." - The resolver asks Route 53 for
example.com’s name servers. - Route 53 says, "I’m authoritative for
example.com. Forwww.example.com, the answer is192.0.2.1."
This A record is the most fundamental type. It maps a hostname to an IPv4 address. The value field is the IP address itself. The TTL (Time To Live) of 300 seconds means resolvers should cache this answer for 5 minutes before asking again.
Now, what if your server uses IPv6? That’s where AAAA records come in. They look identical, but the value is an IPv6 address, e.g., 2001:0db8:85a3:0000:0000:8a2e:0370:7334. You can have both an A and an AAAA record for the same hostname.
But what if you don’t want to manage the IP address directly, or you want to point www.example.com to another hostname, like my-app.herokuapp.com? That’s a CNAME (Canonical Name) record.
Hosted zone: example.com
Record name: www.example.com
Record type: CNAME
Value: my-app.herokuapp.com
TTL: 300 seconds
When a resolver gets this CNAME record, it doesn’t stop. It must then go and resolve my-app.herokuapp.com to find its IP address. A CNAME essentially says, "The real name for this is that other name." This is why you can’t have a CNAME for the zone apex (example.com) itself, because other records (like MX, NS, SOA) must be associated with the apex name, and a name can only have one canonical name.
Email is a bit different. When someone sends email to user@example.com, the sending mail server needs to know which server is responsible for accepting mail for example.com. That’s what MX (Mail Exchanger) records are for.
Hosted zone: example.com
Record name: example.com
Record type: MX
Value:
10 mail.example.com.
20 backup-mail.example.com.
TTL: 300 seconds
The value here is a bit more complex. It has two parts: a priority and a hostname. The priority is a number (lower is preferred). So, mail servers will try to deliver to mail.example.com first. If that fails, they’ll try backup-mail.example.com. The hostname must be a fully qualified domain name that itself resolves to an IP address (usually via an A or AAAA record). You cannot use an MX record to point directly to an IP address.
These records are just pointers. The magic happens when a resolver follows them. The most counterintuitive part is that a CNAME record for www.example.com means that www.example.com is not www.example.com in the DNS lookup process; it is an alias for whatever hostname it points to, and the lookup continues from there. If you point www.example.com to app.example.com via CNAME, and app.example.com has an A record for 192.0.2.5, the final answer the browser gets for www.example.com is 192.0.2.5, but the DNS response will explicitly state that www.example.com is an alias.
The next step is often realizing how these records interact with load balancing and failover strategies.