DNS record types explained

How a record is built

Every DNS record has an owner name, a type, a class (always IN on the internet), a TTL and a value. The owner name says where in the namespace the record applies, the type says what kind of information the value is, and the TTL says how many seconds a resolver may keep a copy before asking again. A set of records with the same name and type is called an RRset, and resolvers treat it as a unit: they cache it together and DNSSEC signs it together.

A zone is the set of records an organisation is responsible for, managed at a pair or more of authoritative name servers. The registrar's delegation to those servers, held in the parent zone, is how the rest of the world finds them. Keeping these two ideas apart, what the zone contains and who is delegated to serve it, avoids much of the confusion around DNS changes.

Address records: A and AAAA

An A record maps a name to an IPv4 address and an AAAA record maps it to an IPv6 address. They are what a browser needs in the end. A name may carry several of each, and clients choose among them, so the order is not a ranking. A AAAA record that points to a host that does not actually serve IPv6 can make connections slow, which is a reason to publish AAAA only once the service works over IPv6.

Use the DNS Lookup tool to see both, and compare what the authoritative servers say with what the resolver returns.

Aliases: CNAME

A CNAME says that a name is an alias for another name. The resolver starts again at the target and returns whatever it finds. The rule that surprises people is that a name with a CNAME may not have any other record types, which is why a CNAME cannot be placed at the zone apex, where SOA and NS records must exist. Providers get around this with their own flattening features, which return plain address records.

Targets of MX, NS and SRV records must be canonical names with addresses, not aliases. A CNAME that points at a name that no longer exists leaves a dangling alias, and it is worth removing aliases when you retire the service they point to. The CNAME Lookup follows chains and flags loops and dangling targets.

Mail and service location: MX and SRV

An MX record names a mail server and a preference; senders try the lowest number first. The target must be a host name with its own address records, and a null MX (preference 0, target a single dot) states that a domain accepts no mail. An SRV record generalises the idea to other services: it publishes priority, weight, port and target at a name like _sip._tcp.example.com, so that clients need not guess ports.

Neither record proves that the service answers. They are signposts; the connection still has to succeed. See MX Lookup and SRV Lookup.

Text records: TXT

TXT carries free text but is used for structured policy. SPF lists senders allowed to use a domain, and exactly one SPF record may exist per name. DMARC is published at _dmarc.example.com, and DKIM public keys at selector._domainkey.example.com. Verification tokens for other services also live in TXT.

Long values are stored as several strings of up to 255 bytes each, which readers join together. Large TXT sets can exceed the usual UDP size and force TCP fallback. The TXT Lookup shows the classification of each entry.

Zone structure: NS and SOA

NS records list the authoritative servers, and they exist twice, at the parent (the delegation) and inside the zone. If these differ, resolvers follow the parent. The SOA record at the apex has the primary server, a contact, the zone serial and four timers, one of which is the negative-caching TTL, the time a resolver may remember that a name does not exist.

Use NS Lookup and SOA Lookup to check these. A stale serial on one server or a delegation that still points at a former provider are among the commonest real problems.

Reverse DNS and certificate policy: PTR and CAA

A PTR record maps an address back to a name in the reverse tree under in-addr.arpa or ip6.arpa. That zone belongs to whoever holds the address block, so you configure it through your hosting provider or ISP, not in your own zone. Mail servers are expected to have a PTR that resolves back to the same address.

CAA records list the certificate authorities permitted to issue for a name, and a CA climbs from the host name to its parents until it finds a policy. It restricts new issuance only. See PTR Lookup and CAA Lookup.

DNSSEC records: DS, DNSKEY and RRSIG

DNSKEY holds the zone's public keys, RRSIG holds signatures over each RRset, and DS, published at the parent, holds a digest of a child key to link the zone into the chain of trust. DS is the record that is risky to leave behind when changing providers. Read the DNSSEC explained guide before enabling or disabling signing, and test with the DNSSEC Checker.

Mistakes that break domains

• A CNAME added where other records already exist.
• A second SPF record instead of merging into the first.
• A trailing dot omitted so the panel appends your own zone to a full name.
• NS records changed in the zone but not at the registrar, or the reverse.
• A stale DS record after a DNS provider change.
• A very long TTL on a record that needs to change soon.

Where to go next

Read DNS propagation explained for how TTLs govern when a change is seen, and the DNS change checklist before editing a live zone. When a lookup misbehaves, troubleshooting NXDOMAIN, SERVFAIL and timeouts explains what each outcome means.

Written by DNS Tools editorial · Last updated 2026-10-09