How to read a DNS lookup result
A practical walkthrough of record values, TTL, empty answers and DNS errors—with an example you can reproduce.
example.comOne row. Three clues to understand.
Start with the question you are trying to answer
A DNS lookup is useful when you compare its answer against an expected configuration. Before running one, write down the exact hostname, record type and value you expect. For a website, start with A and AAAA. For incoming mail, start with MX. For domain verification, use the record type and hostname supplied by the service.
The root domain and www are different names. A correct answer for example.com does not establish that www.example.com is configured correctly. Query both when diagnosing a website migration.
A worked example
The following is an illustrative response, not a live measurement. The IP address is reserved for documentation; do not copy it into your production zone.
Question: example.com / A Name: example.com. Type: A TTL: 240 Value: 192.0.2.10
The value is the IPv4 address returned for this name. The TTL is measured in seconds. Here, the recursive resolver can generally reuse its cached answer for another four minutes. The trailing dot represents a fully qualified domain name; it is not a typo.
If your host expects 192.0.2.20 in this hypothetical example, investigate whether you edited the active DNS zone and whether the old answer remains cached. Do not repeatedly change the record while you are still comparing caches: that makes the timeline harder to interpret.
Read the answer type, not just your requested type
A resolver may return a CNAME followed by an address record. That means the requested name is an alias and the answer includes the target. Multiple A or AAAA values can be intentional. Compare all returned values with your provider’s configuration instead of choosing the first line as the only correct answer.
| You see | What it means | Next check |
|---|---|---|
| NOERROR with answers | The resolver returned records. | Compare their values with your expected configuration. |
| NOERROR without an answer | No records of that type were returned; the name may still exist. | Check A versus AAAA, and the exact hostname. |
| NXDOMAIN | The resolver reports that the queried name does not exist. | Check spelling, delegation and negative caching. |
| SERVFAIL | The resolver could not complete the lookup. | Compare another resolver; investigate DNSSEC and nameserver availability. |
| HTTP or network error | The browser did not obtain a usable API response. | Check connectivity or select another resolver. This is not a DNS verdict. |
Use two resolvers carefully
Run the same query with Google Public DNS and Cloudflare. If their answers differ, save both results and the timestamps. Their caches can have different lifetimes; geographically directed DNS can also return different addresses by design. Agreement between these two services is useful evidence, but it is not proof of worldwide propagation.
For a direct authoritative comparison, use a terminal and replace the nameserver below with one that actually serves your domain:
dig example.com NS dig @ns1.your-dns-provider.example example.com A +norecurse dig @8.8.8.8 example.com A dig @1.1.1.1 example.com A
What a DNS lookup does not prove
A correct address does not prove that an HTTP server is running, a TLS certificate is valid, or a firewall allows access. An MX record does not prove a mailbox exists or that mail will reach an inbox. An AD flag reports the recursive resolver’s authentication result; an absent flag alone is not enough to diagnose DNSSEC.
Save useful evidence
Download the JSON report before contacting a provider. Include the hostname, record type, resolver, timestamp, expected value and observed value. Remove private or unnecessary information before sharing. A specific comparison is much easier to investigate than “DNS is not working.”