DNS Record Types Explained

The Domain Name System is a distributed database with typed records. It does much more than turn a website name into an address: DNS also delegates authority, routes mail, publishes service policies and supports reverse lookups. Reading a response starts with knowing which record type was requested and which name owns it.

Resolvers, authoritative servers and caching

An application normally asks a recursive resolver. If the answer is not cached, that resolver follows delegations from the DNS root toward the authoritative servers for the requested zone. The authoritative server publishes zone data; the resolver returns it to the client and may cache it. This separation explains why changing a zone does not make every resolver show the new answer immediately.

The DNS Lookup queries selected record types through the server’s configured resolver. The Hostname Lookup is narrower: it collects only public IPv4 and IPv6 destinations and fails closed on non-public answers.

Common record types

A and AAAA: destination addresses

An A record contains an IPv4 address; AAAA contains IPv6. A name can have several of either for load distribution, redundancy or regional routing. Clients may try candidates in an order influenced by operating-system address-selection rules and observed connectivity. Seeing an address in DNS does not prove that an HTTP server listens there.

Answers can vary by resolver location or client subnet because some authoritative systems steer traffic geographically. A content delivery network may also use short TTLs and rotate addresses. Treat the returned set as a snapshot.

CNAME: aliases and indirection

A CNAME says that its owner name is an alias of another name. A resolver follows that target to obtain the requested data. This indirection lets a service provider manage changing destination records while a customer retains a stable alias.

Classic DNS rules do not allow a CNAME owner to have other ordinary data, which makes using CNAME at a zone apex awkward because the apex also needs SOA and NS records. Some DNS providers offer flattening or proprietary alias features that synthesize address answers; those are operational conveniences, not literal CNAME records at the apex.

MX: mail routing

MX records direct email for a domain to mail exchangers. Lower preference numbers are tried first; equal preferences can distribute attempts. The target should be a hostname that resolves to addresses, not an IP literal. An MX record says where SMTP delivery should be attempted, not whether a mailbox exists or whether a message will be accepted.

A domain can publish a null MX to state that it does not accept email. Historical SMTP fallback behavior may try the domain’s address when MX is absent, so “no MX” must be interpreted cautiously. Use the Email DNS Checker for MX alongside SPF, DMARC and an optional DKIM selector.

TXT: a general carrier

TXT records carry one or more character strings. They are used for domain-control challenges, SPF, DKIM keys, DMARC policies and many vendor-specific values. DNS presentation may show quoted chunks even when applications concatenate them into one logical value. A generic TXT lookup should display the data without assuming every record uses the same grammar.

NS and delegation

NS records identify name servers. At a parent, they delegate a child zone; inside the child, they describe its authoritative set. “Glue” address records may be included by the parent when a delegated name server lies inside the child zone, avoiding a lookup dependency loop. Parent and child NS sets can briefly differ during a migration, but persistent inconsistency is worth investigating.

SOA: zone administration

The Start of Authority record contains the primary server name, a DNS-encoded responsible-party address, a serial number and timers used in zone maintenance and negative caching. Secondary servers use the serial to decide whether data changed. Its exact serial format is an operator convention; a date-like number is common but not mandatory.

PTR and reverse DNS

Reverse DNS stores PTR records beneath special trees derived from an IP address. The address-range operator controls that delegation. A PTR name need not be the inverse of every A or AAAA mapping, and many valid addresses have no PTR at all. Mail systems often care about coherent forward and reverse configuration, but a PTR is still published metadata rather than identity proof. Try the Reverse DNS Lookup for a public address.

TTL and changing answers

Time To Live is the number of seconds a resolver may normally cache a record. A 300-second TTL permits a five-minute cache, but it is not a promise that data changes exactly then: caches started at different times, local policy and intermediate systems matter. Lowering a TTL before a migration can shorten future cache windows, but already-cached records retain the prior TTL.

DNSSEC adds signatures and a chain of trust to DNS data; it does not change these record purposes or encrypt the lookup. Continue with DNSSEC Explained to understand DNSKEY and DS.