DNS Lookup Guide

What it does

DNS turns names such as www.example.com into the records that browsers, mail servers, and other clients need. Those records are published by authoritative nameservers and usually reached through a caching recursive resolver.

This lookup checks five common record types:

• A maps a name to an IPv4 address.
• AAAA maps a name to an IPv6 address.
• CNAME aliases one name to another name.
• TXT carries text used by services such as SPF and domain verification.
• NS lists nameserver records published at the exact name queried. At a zone apex, these usually name that zone’s authoritative servers.

Enter a hostname without https://, a path, or a port. Use example.com for records at the zone apex and www.example.com for records on the www host.

What this tool tells you

The result is the public answer returned by a recursive DNS resolver. It helps answer practical questions:

• Does the name exist in public DNS?
• Does it point to the expected IPv4 or IPv6 address?
• Is a CNAME sending clients to another hostname?
• Are expected TXT verification or policy records visible?
• Are NS records published at the exact name you queried?

Empty results are meaningful when the lookup completed without an error. A domain can have an A record but no AAAA or CNAME record. If one query fails, the result includes a lookup error rather than silently treating the failure as an empty answer. An error for every type stops the lookup.

Use the output to compare the intended DNS configuration with what clients can currently see. If a website moved, compare A and AAAA records with the new host. If a service cannot verify a domain, check the exact TXT name and value it requested. For inbound email routing, use the MX Lookup; MX records are deliberately handled separately.

How it fits with other technologies

A normal lookup crosses several layers:

1. The registrar delegates the domain through NS records and glue at the parent zone.
2. The authoritative zone publishes its own NS set plus A, AAAA, CNAME, MX, and TXT records.
3. Recursive resolvers cache those answers for their time to live (TTL).
4. Applications use the returned address or policy data to connect to a service.

DNS can therefore be correct while the application is still broken. An A record may point to the right server while HTTPS fails because the certificate is wrong. MX records may route mail correctly while SPF, DKIM, or DMARC causes authentication failures. A SPF check reads one specific TXT policy; it does not replace a general DNS check.

CNAME records add another lookup. The alias target must also resolve. At a traditional zone apex, a CNAME conflicts with the required SOA and NS records, so DNS providers often offer an ALIAS, ANAME, or CNAME-flattening feature instead.

Troubleshooting unexpected results

1. Check the exact name. example.com, www.example.com, and _service.example.com are different DNS names. Remove URLs, spaces, trailing paths, and accidental prefixes.
2. Check delegation separately. Confirm the registrar and parent zone list the nameservers your DNS provider assigned. An NS query for www.example.com does not discover the enclosing example.com zone or compare its parent and child NS sets.
3. Compare the authoritative answer. Find the authoritative NS, then query it directly with a command such as dig @ns1.provider.example www.example.com A. If that answer is right but a public resolver is stale, caching is the likely cause.
4. Allow for TTL caches. Lowering the TTL after a change does not shorten answers already cached under the old TTL. Wait for the previous TTL to expire.
5. Check both address families. A stale AAAA record can break IPv6 clients even when the A record is correct.
6. Follow aliases. Verify every CNAME target exists and ultimately reaches an A or AAAA record. Remove loops and conflicting records at the same name.
7. Look for DNSSEC failure. A stale DS record or bad signature can produce SERVFAIL from validating resolvers even though the zone appears populated at its authoritative server.
8. Consider split DNS. Corporate and home networks may intentionally return private answers that differ from public resolvers.

If two public resolvers disagree after the expected TTL has passed, inspect the authoritative nameservers individually. Different answers from nameservers in the same delegation usually mean a zone transfer, secondary server, or provider configuration is out of sync.

What this tool cannot prove

This lookup uses DNS-over-HTTPS through Cloudflare’s public resolver, with Google Public DNS as a transport fallback. It does not query every resolver worldwide, bypass all caches, discover the enclosing zone, trace parent delegation, or prove that a record has propagated everywhere. It also does not test whether the returned server is reachable, whether a web application responds, or whether TLS is configured correctly.

For authoritative detail, TTL values, DNSSEC validation, trace output, or a specific local resolver, confirm with dig, delv, or nslookup from the affected network. Treat this lookup as the public starting point, then test the next layer that consumes the DNS answer.