What a DNS record is
A DNS record is a single entry in a domain's zone that maps a name to a piece of information the internet can act on — an address to connect to, a nameserver to ask next, a mail-authentication policy to check. The Domain Name System is the distributed database that holds these records, and resolving a domain means collecting the right records from the right servers until you have the answer you came for (RFC 1034).
Every record shares the same shape, regardless of type:
example.com. 3600 IN A 203.0.113.10
Reading left to right, that is the owner name the record belongs to (example.com.), the TTL in seconds that resolvers may cache it (3600), the class (IN, for internet — effectively always this), the type (A), and the RDATA, the type-specific value (203.0.113.10). The type is what makes one record an address and another a mail policy; everything below is a tour of the types that matter, grouped by the job they do. The IANA DNS parameters registry lists every type, but a working domain uses a small handful.
Address records: A and AAAA
The most basic job is turning a name into an IP address. An A record maps a hostname to a 32-bit IPv4 address, and an AAAA record maps the same hostname to a 128-bit IPv6 address. A dual-stack host publishes both, and clients pick whichever they can reach. These are the records behind almost every website and API endpoint, and the ones you edit when a server moves.
Aliases: the CNAME record
Instead of an address, a CNAME record points one name at another name. A resolver that finds a CNAME restarts its lookup at the target and takes whatever it needs from there, which is how you point a subdomain at a hosting provider or CDN without hard-coding addresses you do not control. The catch is that a name with a CNAME may hold no other record, so you cannot place one at the zone apex — a limit worth understanding before you design your records.
The zone's own records: SOA and NS
Two record types describe the zone itself rather than any host in it. The SOA record — Start of Authority — sits at the apex and holds the zone's serial number and the timers that keep secondary nameservers in sync; there is exactly one per zone. The NS records name the authoritative nameservers the zone is delegated to. Together they are the plumbing: NS says who answers for the zone, and SOA says how those servers stay current. You rarely write them by hand, but they explain why a change propagates the way it does.
Reverse DNS: the PTR record
Address records go from name to IP; a PTR record goes the other way, from an IP back to a hostname. This is reverse DNS, and it lives in a separate part of the tree (in-addr.arpa for IPv4, ip6.arpa for IPv6) that is controlled by whoever owns the IP block — your host or cloud provider, not your own zone. It matters most for sending mail: a server with missing or mismatched reverse DNS is treated as suspicious by receivers. You can check any IP's reverse record with the reverse-DNS lookup tool.
Text records: TXT
A TXT record holds free-form text at a name, and that flexibility made it the home of email authentication. SPF policy, DKIM public keys, and DMARC records are all published as TXT records, alongside domain-ownership verification strings from providers like Google and Microsoft. Because it is a general-purpose container, one name can carry several TXT records at once — with one firm exception: only a single SPF record is allowed. How each of those email policies works is covered under email authentication explained.
Certificate authorization: CAA
A CAA record tells certificate authorities which of them may issue TLS certificates for your domain. It is a guardrail against mis-issuance: a CA is required to read your CAA record before it signs a certificate, and to refuse if it is not on the list. Browsers never look at it — the check happens once, at issuance. A domain with no CAA record lets any public CA issue.
TTL, caching, and propagation
Every record carries a TTL, and the TTL is why DNS changes are not instant. When a resolver fetches a record, it may serve that copy from cache until the TTL expires, so an edit you make now can take up to the old TTL to be seen everywhere. If you know a change is coming, lower the TTL a day ahead so the switch is quick, then raise it again afterward to cut query load. Negative answers cache too — the SOA record's minimum field sets how long a "no such name" result sticks, which is why a record you just published can still read as missing for a while.
To see any of these for a domain, query them directly: dig A example.com, dig TXT example.com, or nslookup -type=SOA example.com on Windows. Run a full domain check from the home page to read a domain's mail-relevant records — MX, SPF, DKIM, DMARC, and more — in one pass, look up MX records on their own to see where the domain receives mail, or open any record page above for how to read and fix that type.