DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, NS and PTR
2026-09-02 · 6 min
When something 'DNS' breaks, the failure is almost never about DNS in general - it is about one specific record type being missing, wrong, or cached for too long. The domain resolves but mail bounces; the site works but email verification fails; the new server is live but some visitors still see the old one.
Each of those is a different record type. Here is the practical map of the seven you will actually meet, what question each one answers, and how to debug them with a lookup tool.
1983
DNS is specified
RFC 882 and 883 define the Domain Name System, replacing the hosts.txt file that every machine on the (tiny) ARPANET downloaded - the typed record structure is there from the start.
1987
The core standard
RFC 1034 and 1035 consolidate DNS as we still use it today: the record types, the zone delegation model, and the caching behavior that makes the whole system scale.
1996
AAAA for IPv6
RFC 1886 defines the AAAA record to carry 128-bit IPv6 addresses - four times the letters of A, four times the address size, and the reason dual-stack sites list both records.
2010
The root goes DNSSEC
The root zone is signed with DNSSEC (RFC 4034 family), adding cryptographic signatures on top of the classic record types so answers can be verified, not just trusted.
The records you meet every day
A maps a name to an IPv4 address; AAAA does the same for IPv6. CNAME is an alias - it points a name at another name instead of an address, which is why www is usually a CNAME to the bare domain. NS records say which servers are authoritative for a zone: they are the delegation mechanism that makes DNS a tree.
MX is the odd one: it answers 'which servers accept mail for this domain', with a priority number to allow backups. A domain can have a working website with a completely broken MX - which is exactly why 'the site works but mail doesn't' is a one-record diagnosis.
TXT: the swiss-army record
TXT records carry arbitrary text, and the ecosystem has piled its most important policies into them. SPF lists which servers may send mail for the domain; DKIM publishes signature keys; DMARC tells receivers what to do when those two fail. Domain-ownership verification for dozens of services (search consoles, certificate authorities, SaaS signups) is also just a TXT record with a challenge string.
This is why mail deliverability debugging starts with TXT: a missing or malformed SPF can make even a perfectly healthy server's mail land in spam. The records are small, but they carry the trust decisions of the entire mail system.
One name, many answers: the record type selects the question - address, alias, mail routing, policy text, delegation or reverse lookup.
PTR: the reverse record people forget
PTR is the mirror of A: it maps an address back to a name. It lives in special reverse zones under in-addr.arpa (and ip6.arpa for IPv6), and is configured by whoever owns the IP block - typically your hosting provider, not your DNS registrar. This is why a PTR cannot be set in the same panel as the rest of your records.
Mail receivers care a lot about PTR: a sending server whose address has no reverse lookup - or one that does not match its HELO name - looks exactly like spam infrastructure. If your server's mail is rejected with a reverse-DNS error, the fix is at the provider, not in your zone.
TTL: why your change hasn't propagated
Every record carries a TTL - the number of seconds any resolver on the planet may cache the answer. This is why DNS changes 'take time': resolvers keep serving the old answer until its TTL expires. A record with a 3600-second TTL can be stale for an hour everywhere it was already queried.
The practical pattern: lower the TTL well before a planned change (many operators drop to 300 seconds), make the change, verify with lookups against multiple resolvers, then raise the TTL again to enjoy the caching. When a lookup tool shows a different answer than your local dig, a cache somewhere is almost always the explanation.
要点总结
Every 'DNS problem' is a specific record with a specific question. Identify the type, check it with a lookup tool, and mind the TTL - that is ninety percent of DNS debugging in one sentence.
为防止滥用，请求会受到频率限制。此实例的运营者可以选择性地启用请求活动日志记录——如果启用，每次工具请求（您的 IP 地址、时间戳、使用的工具及输入的目标/查询内容）可能会被记录到数据库中，用于安全、防滥用和使用情况分析。此功能默认关闭。使用本网站即表示您同意上述条款；如果您不同意，请不要使用本网站。