DNS Record Lookup

What each record type is for

• A — maps a domain to one or more IPv4 addresses. The most common record.
• AAAA — same as A but for IPv6 (the four As stand for "four times A", since IPv6 is four times longer).
• MX — Mail eXchanger. Tells the world where to deliver email for this domain. Lower priority values are preferred.
• TXT — arbitrary text. Used for SPF, DKIM, DMARC, domain-ownership verification (Google Search Console, Stripe, etc.), and anything else where you need to publish a small string.
• NS — Name Server. Lists the authoritative DNS servers for the domain. The first thing the DNS resolver looks up before any other records.
• CNAME — Canonical Name. Aliases this domain to another. www.example.com often CNAMEs to example.com. Cannot coexist with other records on the same name.
• SOA — Start Of Authority. One per zone. Lists the primary name server, admin email, serial number (incremented on every change), and TTLs for negative caching.
• CAA — Certificate Authority Authorization. Specifies which CAs (Let's Encrypt, DigiCert, etc.) are allowed to issue TLS certificates for the domain. CAs must check this before issuing.
• SRV — Service location. Used for service discovery — XMPP, SIP, Minecraft, Active Directory, and others publish hostname + port via SRV.
• PTR — Reverse DNS. Maps an IP back to a hostname. Used by mail servers to verify legitimacy (a forward + reverse match increases sender reputation).

TTL — why DNS changes take time to propagate

Every DNS record has a Time-To-Live (TTL) — the number of seconds a resolver should cache the record before checking again. Typical values: 300 (5 min) for fast-changing infrastructure, 3600 (1 hr) for stable apex records, 86400 (24 hr) for very stable records like MX or NS.

"DNS propagation" — the lag between updating a record and the change being globally visible — is mostly about caches expiring. Lower the TTL before you plan a change (a week ahead, drop to 60), wait for the old TTL to expire, then make the change. Most resolvers will pick up the new value within 60 seconds.

Why this tool's results may differ from "dig"

This tool uses the system DNS resolver of the server running it (typically a recursive resolver close to the application). It returns the resolver's cached answer. dig on your local machine uses your local resolver — which may have its own cache, or may be pointed at a different upstream (Google 8.8.8.8, Cloudflare 1.1.1.1, your ISP). All three should return the same data, but cache freshness can cause short-term differences when records have been updated recently.

To bypass caches and query the authoritative server directly, use dig @ns1.example.com example.com TXT locally — this skips intermediate resolvers entirely.

Common patterns to look for

• No MX records means the domain doesn't accept email. Some domains explicitly publish 0 . (a "null MX") which signals "this domain never sends or receives mail" — a useful RFC 7505 declaration for parked domains.
• Multiple TXT records are normal. SPF, DKIM (under _domainkey subdomains), DMARC (under _dmarc), site-verification tokens — they all coexist. Each is a separate TXT record.
• CNAME on the apex (root domain like example.com) is forbidden by DNS standards. Workarounds: ALIAS or ANAME records (provider-specific), or use A records pointing to load-balancer IPs.
• Wildcard records (*.example.com) match any subdomain that doesn't have an explicit record. Convenient but can mask configuration mistakes — explicit records always win.