{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }}: {{ badge.value }}
{{ summaryAnnouncement }}
DNS record lookup controls
Enter one value, such as example.com, https://example.com/path, 8.8.8.8, or 2001:4860:4860::8888.
The set controls which independent DNS questions are sent during this lookup.
Supported: A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, SRV, NAPTR, PTR, HTTPS, SVCB, DS, DNSKEY, RRSIG, NSEC, NSEC3, TLSA, SSHFP.
The selected public resolver receives the submitted query name and record type.
Off is neutral. Enable it when inspecting RRSIG, DS, DNSKEY, NSEC, or NSEC3 material.
{{ doFlagEnabled ? 'On' : 'Off' }}
Off is neutral and keeps the resolver's normal validation policy.
{{ cdFlagEnabled ? 'On' : 'Off' }}
ms
The default is 9000 ms; accepted range is 3000-15000 ms.
{{ tableStatus.records }}
TypeNameTTLDataCopy
{{ row.type }}{{ row.name }}{{ formatTtl(row.ttl_seconds) }}{{ row.data }}
The resolver returned no answer records for the requested types.
{{ chartStatus }}
{{ tableStatus.evidence }}
TypeResolverResponseAnswersDNSSECCopy
{{ row.type }}{{ row.resolver }}{{ row.response }}{{ row.record_count }}{{ row.ad ? 'AD set' : 'AD not set' }}

A DNS check begins with two precise choices: the name to ask about and the record type to request. A website, mail system, certificate policy, service-discovery record, and reverse address can all use the same Domain Name System while returning completely different data. Looking up several record types is therefore a set of independent questions, not one request for a domain's complete configuration.

Recursive resolvers answer from their current view of authoritative data and cache. During a migration, Google Public DNS and Cloudflare may legitimately return different answers or remaining cache lifetimes for a while. A fresh result proves what the selected resolver returned at that moment; it does not prove that every resolver worldwide has the same view.

Common DNS record groups and their purpose
Question Common record types What to inspect
Where does a host resolve?A, AAAA, CNAMEIPv4 and IPv6 addresses or an alias target.
Where is mail delivered?MX, TXTMail exchangers and text-based sender or domain policies.
Who serves the zone?NS, SOAAuthoritative name servers and zone timing metadata.
How is a service discovered?SRV, NAPTR, SVCB, HTTPSService targets, priorities, ports, and connection hints.
What DNSSEC material is visible?DS, DNSKEY, RRSIG, NSEC, NSEC3Delegation, keys, signatures, and authenticated denial records.

A blank Answer section is not one universal failure. NOERROR with no answer can mean the owner exists but has no record of that type, while NXDOMAIN means the queried name does not exist in the resolver's view. SERVFAIL often points to an upstream or validation problem. The response code matters as much as the row count.

Time to live (TTL) is the number of seconds a returned record may remain cached before it is considered stale. It is not a countdown to guaranteed global change, and a resolver may already have spent part of the authoritative TTL before returning the value you see.

How to Use This Tool:

Choose the smallest record set that answers the troubleshooting question, then compare resolver evidence when the result is unexpected.

  1. Enter one domain, hostname, URL, IPv4 address, or IPv6 address. A URL is reduced to its hostname; an IP address is converted to its reverse-DNS name and queried for PTR.
  2. Select a Record set. Use Custom record types only when you need a specific combination from the supported list; at most 20 unique types are queried.
  3. Run Lookup records, then read the response code and answer count for each requested type before interpreting the record rows.
  4. Compare the owner name, type, TTL, and data. During a change, re-run with the other Resolver policy instead of assuming one cached view is universal.
  5. Enable Request DNSSEC records when you need DNSSEC material. Use Disable resolver validation only for troubleshooting because it asks the resolver not to reject data that fails validation.

Interpreting Results:

Start with the resolver response for each type, then inspect the returned records. A successful HTTPS request can still carry NXDOMAIN, SERVFAIL, or another DNS failure code.

  • NOERROR plus answer rows means the resolver returned records for that question.
  • NOERROR with zero returned rows does not prove the whole domain is empty; it only shows that no Answer records were retained for that type.
  • NXDOMAIN refers to the queried owner name, not merely a missing record type.
  • An AD set result is evidence that the recursive resolver marked the answer as authenticated. Signatures are not validated again in the browser.
  • A low TTL suggests the returned row may be refreshed soon, but it does not predict when every resolver or client cache will update.

Technical Details:

DNS-over-HTTPS (DoH) maps each DNS question to an HTTPS exchange. This lookup uses the JSON formats offered by Google Public DNS and Cloudflare, then normalizes the Answer records into owner name, type, TTL seconds, and type-specific data. The two providers follow a similar JSON shape, but that JSON shape is not itself standardized by an RFC.

Lookup Core

Every requested record type is queried independently. In ordered failover mode, Google is tried first for each question and Cloudflare is used only when Google does not return usable JSON. The complete lookup succeeds when at least one question returns a usable DNS response; failed questions remain visible as resolver evidence.

DNS input normalization and lookup rules
Input or option Rule
Hostname or URLThe hostname is lowercased, a final dot is removed, and every label must contain 1 to 63 letters, digits, or hyphens without a leading or trailing hyphen.
IPv4 addressOctets are reversed and followed by in-addr.arpa; the record set becomes one PTR question.
IPv6 addressThe address is expanded to 32 hexadecimal nibbles, reversed nibble by nibble, and followed by ip6.arpa; the record set becomes one PTR question.
Custom typesUnsupported names and duplicates are removed, and no more than 20 supported types are retained.
Returned recordsOnly recognized Answer records are normalized. TTL must be an integer from 0 through 2,147,483,647 seconds, and the total is capped at 5,000 rows.

Rule Core

DNS response and DNSSEC flag interpretation
Signal Meaning in this lookup
NOERROR (0)The DNS message was processed without that response-code error; the Answer section may still be empty.
FORMERR (1)The DNS server reported a format error.
SERVFAIL (2)The resolver could not complete the DNS operation, including possible DNSSEC validation failure.
NXDOMAIN (3)The queried owner name does not exist in that resolver view.
NOTIMP (4) or REFUSED (5)The operation is unsupported or refused by the resolver.
DO requestedThe query asks for DNSSEC records when applicable; it does not perform browser-side validation.
CD requestedThe query asks the recursive resolver to disable its normal validation rejection behavior.
AD setThe resolver reports authenticated data for that response. This is resolver-supplied evidence, not an independent local signature check.

Formula Core

For each requested type, TTL coverage reports the minimum, arithmetic mean, and maximum over the returned Answer rows for that question.

TTLavg= i=1nTTLin

n is the number of returned records for the requested type. When no rows are returned, the displayed minimum, average, and maximum are all zero rather than an inferred cache lifetime. Averages are not rounded before being retained.

Privacy and Accuracy Notes:

The selected public resolver receives every submitted query name and record type. With JSON DoH over GET, the query is encoded in the request URL, so sensitive internal names should not be submitted to a public resolver.

  • Google and Cloudflare apply their own caching, filtering, logging, availability, and DNSSEC policies.
  • The record ledger retains Answer rows, not the complete Authority and Additional sections. Use a full DNS diagnostic when negative-response authority data matters.
  • Resolver differences may reflect cache age, routing, policy, or an ongoing authoritative change. Compare authoritative servers when the public recursive views disagree.
  • Disabling resolver validation is a diagnostic comparison, not evidence that failing DNSSEC data is safe to use.

Worked Examples:

Checking a website cutover

Enter the production hostname and choose Web and aliasing. Compare the returned A, AAAA, CNAME, HTTPS, and SVCB rows with the intended destination. If one public resolver still shows the old address, note its TTL and compare the other resolver before changing the zone again.

Reverse lookup for an IP address

Enter 8.8.8.8. The lookup changes the question to 8.8.8.8.in-addr.arpa PTR and ignores the selected record bundle. A returned PTR name is reverse-DNS evidence; it does not authenticate the service or prove forward-confirmed ownership.

References: