Check DNS records and understand the answer

Choose the record that matches your question

• A: IPv4 addresses associated with a name.
• AAAA: IPv6 addresses, which should be checked separately from A.
• CNAME: an alias pointing a name to another DNS name.
• MX: mail destinations with preference values; lower values are preferred.
• TXT: published text, often used for verification or mail policy.

The selector also offers NS, SOA and CAA. Start with the type related to the symptom rather than checking every option. A working A record does not confirm that mail is configured, and an MX answer does not prove that the website is online.

Run a focused lookup

1. Open the DNS lookup tool and enter the exact public hostname. example.com and www.example.com are different names.
2. Select one record type and start the check.
3. Confirm the displayed domain and resolver, then inspect the DNS status and answer list.
4. Change the type and repeat when comparing IPv4 with IPv6, or addresses with aliases.

The browser sends the query to Google Public DNS over HTTPS. There is no need to change the operating system's DNS settings. This is Google's answer to the request, not a readout of the resolver every application on your device uses. It is not a DNS leak test.

Read records, status and TTL together

An answer can include its name, numeric type, TTL and data. Common type numbers are 1 for A, 28 for AAAA, 5 for CNAME, 15 for MX and 16 for TXT. Multiple answers can be valid. Keep the full set when investigating a difference; aliases can also appear alongside requested address records.

TTL is expressed in seconds and concerns caching. A recursive resolver may show remaining cache lifetime. It does not promise that every user worldwide will see a change after exactly that many seconds.

Status 0 means the DNS request completed without a DNS error, but an answer of the selected type may still be absent. Status 3 generally means the name does not exist; status 2 indicates a server failure. A browser request failure is different again, because no DNS response may have reached the tool.

Understand the DNSSEC indicator

The DNSSEC authenticated field reflects the AD flag in Google's response. True means the resolver reports authenticated response data. False does not, by itself, mean the domain is malicious or compromised; an unsigned domain can legitimately return false.

IP Lens requests DNSSEC-related records when available, but does not independently validate the trust chain inside the page. DNSSEC does not assess the safety of website content either. Treat this indicator as a property of one DNS response, separate from HTTPS certificates, availability and reputation.

Follow a short troubleshooting sequence

1. Verify spelling, the exact hostname and the selected type. A parent domain's records do not automatically apply to every subdomain.
2. Compare returned data with the intended settings in your DNS provider's control panel. IP Lens reads public records and cannot change them.
3. After a recent edit, record the time and TTL, then retry after a reasonable interval. Avoid continuous rapid queries.
4. When answers are missing, distinguish an absent record from a nonzero status or failed HTTP request before taking action.
5. If DNS looks correct but a site still fails, investigate the connection and service separately. The IPv4, IPv6 and HTTP latency guide helps separate these checks.

The IP and ASN guide explains how to interpret an address returned by DNS. A CDN-like CNAME is only a clue, not proof of the edge server your browser reached. Likewise, a TXT mail policy is not a complete deliverability audit. Keep those limits in any report you share.

Sources and further reading

See Google's DNS JSON API specification for response fields, IETF RFC 1035 for core DNS records, and IETF RFC 3596 for AAAA records. The workflow here describes the checks available in IP Lens.