DNS Lookup: A, MX, CNAME & TXT Records

How DNS actually resolves a name

When someone types your hostname, a stub resolver asks a recursive resolver, which walks the DNS tree from the root, following NS delegations until it reaches the authoritative nameservers for your zone. Those servers return the requested record types—along with TTLs—that resolvers cache for subsequent queries. That chain is why a single typo in an NS record at the registrar can make your entire zone appear empty or stale, even when your hosting panel “looks correct.”

Record types operators rely on daily

A and AAAA tie names to IPv4 and IPv6 endpoints. MX prioritizes mail exchangers; lower numbers win, and every MX hostname must resolve or mail will fail. CNAME cannot coexist with most other data at the same owner name (apex CNAME has special cases like ALIAS/ANAME at some DNS hosts). TXT is the workhorse for email authentication and third-party domain verification. NS at the zone apex must match what the registrar publishes; a mismatch between registrar glue and zone NS records is a classic outage pattern.

Common use cases beyond “is it up?”

Teams use DNS lookup during migrations (confirming cutover targets), incident response (spotting hijacked or poisoned answers), and compliance (documenting which resolvers see which TXT for DMARC). Pairing DNS with a TLS checker helps catch cases where HTTP works on the wrong cert because the client hit a different IP than expected. For registration and expiry context—not live zone data—domain WHOIS fills in the ownership picture.

Practical troubleshooting mindset

Treat DNS as cached, distributed state: if “it works for me,” you may be hitting a resolver with a fresh cache while others still see the old TTL. Document expected records, test before lowering TTL, and after changes validate MX targets and mail-related TXT in one pass. When HTTPS misbehaves despite correct A records, run the SSL certificate checker on the exact hostname the browser uses, including any www vs apex difference.

CDNs, CNAME flattening, and split-brain surprises

Modern edges often use CNAME flattening (ALIAS/ANAME) at the apex so you can point example.com at a CDN without breaking the “no CNAME at apex” rule. The public resolver still sees A/AAAA answers, but your dashboard may hide the indirection—when debugging, compare what authoritative NS return with what a recursive resolver caches. Split-horizon DNS (different answers inside a corporate network vs the internet) explains cases where employees see an internal IP while customers see a public one; a public lookup tool reflects the latter only.

If you delegate a subdomain to another provider (for example _acme-challenge or mail), ensure glue records and parent NS delegations agree. Stale DS records after a KSK rollover can make resolvers SERVFAIL while A records look fine—when you touch DNSSEC, validate with your registrar and DNS host’s DNSSEC debugger in addition to plain record fetches. For mail, remember that MX preference is only half the story: the target host must accept SMTP on the expected port and present sensible TLS; the TLS checker is relevant when that host serves HTTPS too.

Finally, operational hygiene beats heroics: export a baseline zone after each change, monitor SOA serial increments if you still use NOTIFY/AXFR patterns, and keep runbooks that link hostname to owning team to expected A/MX/TXT. When an incident involves both routing and registration, combine this tool with domain WHOIS so you know whether the problem is the zone file, the registrar delegation, or an application misconfiguration above the stack.