DNS maps names to data through typed records. Each record type answers a different question: where is the IPv4 address, what is the alias, where does mail go, and what arbitrary text is published. Reading them correctly is the first step in debugging name resolution.
Before you start
You should understand that names resolve to addresses and be able to run dig or nslookup. This article covers the common record types.
Step-by-step walkthrough
Step 1: Match the record type to the question
An A record maps a name to an IPv4 address, and AAAA maps to IPv6. A CNAME maps a name to another name, which then resolves further. MX names mail servers with a priority, and TXT holds arbitrary strings used for verification and policy such as SPF.
Step 2: Respect the CNAME rules
A CNAME cannot coexist with other records at the same name, so the zone apex — where you also need NS and SOA records — cannot be a CNAME. Providers offer ALIAS or ANAME pseudo-records to point an apex at another name, since a plain CNAME is not allowed there.
Step 3: Set a TTL that matches change frequency
The TTL tells resolvers how long to cache the answer. Use a short TTL during a migration so changes propagate quickly, and a longer TTL in steady state to reduce query load. The TTL also drives how long a mistake sticks.
Worked scenario
The queries show the record types for a name.
dig +short example.com A # 93.184.216.34
dig +short example.com AAAA # 2606:2800:... (IPv6)
dig +short example.com MX # 10 mail.example.com.
dig +short example.com TXT # "v=spf1 -all"
dig +short www.example.com CNAME # example.com.Walk through the example
Each query returns one type, and www returns a CNAME pointing at the apex, so www resolves by following the alias. Mail is directed by the MX record, and the TXT record publishes the SPF policy. The TTL shown by the full dig output controls caching.
Common mistake
Pointing the zone apex at another name with a CNAME, which conflicts with the required NS and SOA records. Another is assuming a change is instant when a long TTL is cached across many resolvers.
Verify the behavior
Query each record type and confirm it exists and points where intended. Check the apex does not use a CNAME. Look at the TTL and confirm it matches your change policy, and query from a public resolver to see the externally visible answer.
Interview exercise
Why can the apex of a zone not be a CNAME?
Answer and reasoning
The apex must hold SOA and NS records, and a CNAME cannot coexist with any other record at the same name. So a CNAME at the apex would conflict with records the zone requires. Providers solve it with an ALIAS/ANAME record that resolves like a CNAME but is served as the target’s address records.
Continue learning
Compare resolution in DNS resolution and caching in DNS caching and TTL. Read the MDN DNS reference and try the Networking interview questions.