DNS Record Lookup

DNS Record Summary

{{ singleRecords.length }} record{{ singleRecords.length === 1 ? '' : 's' }} Resolver: {{ singleResult.resolver }} DNSSEC AD DNSSEC AD: off A {{ singleResult.derived.a_count }} AAAA {{ singleResult.derived.aaaa_count }} MX {{ singleResult.derived.mx_count }}

Domain or IP:

Enter one domain, hostname, URL host, IPv4, or IPv6; use PTR in record types for IP reverse lookups.

Preset:

Choose Custom before editing the comma-separated type list by hand.

Record types:

Comma or space separated: A AAAA CNAME TXT MX NS SOA CAA SRV PTR HTTPS SVCB.

Ignored {{ singleExtraLinesNotice }} extra line(s). This tool processes only the first non‑blank line.

Resolver:

Auto tries Google first, then Cloudflare if the response is unusable.

DNSSEC DO bit:

Switch on when you need DNSSEC material alongside ordinary answers.

DNSSEC CD bit:

Use only while isolating DNSSEC validation errors.

Timeout:

Set 0 for browser defaults, or about 1500-5000 ms for strict troubleshooting.

Type	Name	TTL	Data	Copy
{{ r.type }}	{{ r.name }}	{{ r.ttl }}	{{ r.data }}
No DNS records returned Try another record type, resolver, or target if you expected an answer.

Field	Value	Copy
{{ row.k }}	{{ row.vs.join('; ') }}
No field breakdown available Run a successful lookup to populate derived DNS fields.

No record data to visualize yet.

TTL information is unavailable for the current lookup.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

DNS records are the public instructions that connect a domain name to addresses, mail routes, aliases, name servers, certificate policies, service hints, and other operational data. A record lookup is often the first check when a website cutover looks partial, email delivery breaks, a security record is missing, or one resolver appears to disagree with another.

The most useful DNS snapshot names the target, the record types requested, the resolver used, the returned owner names, the Time to Live values, and the record data itself. TTL matters because it tells caches how long an answer may be reused. DNSSEC flags matter because they show whether the selected resolver treated an answer as authenticated or whether validation was deliberately bypassed.

A single public resolver view is useful because it reflects what that resolver returns at the moment of the check. It is not a full propagation audit, an authoritative-zone dump, or proof that every network sees the same data. Resolver cache age, DNSSEC validation, negative answers, and provider-specific JSON behavior can all change what appears in the result.

IP addresses need a reverse lookup path. For IPv4, the address is reversed under in-addr.arpa. For IPv6, the expanded hexadecimal nibbles are reversed under ip6.arpa. The lookup only uses that path when PTR is one of the requested record types.

How to Use This Tool:

Use one target per lookup. The result is easiest to read when the record-type preset matches the problem you are testing.

Enter one domain, hostname, URL host, IPv4 address, or IPv6 address in Domain or IP. Extra non-blank lines are ignored and reported.
Choose a Preset. General covers common web, mail, and policy records; Web, Email, Security, and DNSSEC narrow the type list for common troubleshooting tasks.
Use Custom before editing Record types by hand. For IP reverse checks, use PTR.
Open Advanced when resolver choice matters. Google and Cloudflare query that public resolver, while Auto tries Google first and then Cloudflare if the first response is unusable.
Turn on DNSSEC DO bit when you need DNSSEC-related material, and use DNSSEC CD bit only when comparing validated behavior with raw DNSSEC data.
Review DNS Records Overview for the answer rows, then use Field Breakdown, Raw DoH Responses, Record Type Breakdown, and TTL Distribution when you need a deeper audit trail.
If the output says no answers were returned, confirm the target spelling, check whether the requested type applies to that target, and compare the other resolver before changing production DNS.

During a migration, keep the resolver, record types, DNSSEC bits, and timeout consistent across repeated checks so differences are more likely to reflect DNS state instead of changed test settings.

Interpreting Results:

Start with the record rows, not the charts. The Type, Name, TTL, and Data columns are the operational evidence. Counts and charts are summaries that help spot shape and cache-window patterns after the actual answers are visible.

TTL is measured in seconds. Low values can help a change converge faster, while high values can leave old answers in caches longer.
DNSSEC AD means the selected resolver marked returned answers as authenticated. It is not the same as running your own end-to-end DNSSEC validator.
No answers can mean the record type is absent, the name is wrong, the resolver has cached a negative response, or the selected type is incompatible with an IP lookup.
Raw responses are useful when provider-specific details matter, but the visible answer rows are usually easier to compare in tickets and change notes.

Technical Details:

DNS resolution asks a resolver for resource records of a specific type at a specific owner name. The returned answer can include one record, several records, no records, or an error status. Public DNS-over-HTTPS resolvers expose those answers over HTTPS, which is convenient for browser-based troubleshooting but still reflects one resolver's cache, policy, and validation behavior.

Record type choice changes the question. A and AAAA ask for IPv4 and IPv6 addresses. CNAME asks for an alias. MX asks for mail exchangers. TXT carries text records such as SPF or verification records. CAA limits certificate-authority issuance. PTR is the reverse-name path for IP addresses.

Lookup Core

The target is reduced to the first non-empty line. URL input is reduced to the host name, internationalized names are converted to ASCII form by the browser, and domain syntax is checked for label length and hyphen placement. Each requested record type becomes a separate public resolver request, then answer records are flattened into rows.

DNS lookup paths by target type
Target type	Lookup name used	Allowed record path	Common mistake
Domain or host	Cleaned host name, converted to ASCII form when needed	Any requested record type from the type list	Leaving a path or scheme in a pasted URL and expecting it to affect DNS.
IPv4 address	Octets reversed under `in-addr.arpa`	`PTR` only	Running the default preset and seeing no answer because `PTR` was not requested.
IPv6 address	Expanded nibbles reversed under `ip6.arpa`	`PTR` only	Testing an abbreviated IPv6 address without checking that the reverse name was formed correctly.

Aggregation Core

Charts and field summaries are derived from the returned answer rows. Record-count bars count rows by type. TTL statistics use only rows with finite non-negative TTL values.

averageTTL = \frac{\sum_{i = 1}^{n} {TTL}_{i}}{n}

Minimum TTL is the smallest TTL in the returned group, maximum TTL is the largest, and average TTL is rounded for display. If no TTL-bearing rows exist for a type, that type does not appear in the TTL chart.

DNSSEC and resolver controls
Control or flag	Meaning	How to read it
`Resolver`	Chooses Google, Cloudflare, or an automatic fallback attempt.	Different resolvers can show different cache age, filtering, or validation behavior.
`DNSSEC DO bit`	Requests DNSSEC records and validation-related material when available.	Useful when checking DS, DNSKEY, RRSIG, NSEC, or NSEC3 evidence.
`DNSSEC CD bit`	Asks the resolver to disable validation for the query.	Use it only to isolate DNSSEC failures; it can produce answers that a validating resolver would reject.
`DNSSEC AD`	Indicates the resolver marked returned data as authenticated.	Trust depends on the resolver; it is not independent validation by the browser.
`Timeout`	Caps each per-type public resolver request.	Short values fail faster during outage triage but can hide slow valid responses.

Privacy and Accuracy Notes:

The domain, host, IP address, requested record types, DNSSEC bits, and resolver choice are sent to the selected public DNS-over-HTTPS resolver. Use a local resolver or internal DNS tooling for private hostnames, split-horizon zones, or sensitive investigation targets.

A single resolver snapshot does not prove global propagation.
Provider JSON formats are convenient but not a formal shared DNS response standard.
Cached answers can persist until TTLs expire, and negative answers may also be cached.
DNSSEC flags should be treated as resolver evidence, not as a complete security audit.

Worked Examples:

A web migration for www.example.com starts with the Web preset. The DNS Records Overview rows show whether A, AAAA, CNAME, HTTPS, or SVCB records are present. If the TTL chart shows long maximum TTL values, old addresses may remain cached after the authoritative change.

An email issue for example.com uses the Email preset. The result should be checked for MX rows first, then relevant TXT policy records. A missing MX answer with existing TXT rows means the domain answered DNS, but not for the requested mail route.

A reverse lookup for 8.8.8.8 uses Custom with PTR. If the default type list is left in place, the lookup skips IP-incompatible types and may return no useful records. Switching to PTR gives the reverse-name path a valid question to ask.

FAQ:

Why did my IP lookup return no records?

IP addresses need a reverse PTR query. Choose Custom, enter PTR in Record types, and run the lookup again.

Does DNSSEC AD mean the domain is fully secure?

No. DNSSEC AD means the selected resolver marked the answer as authenticated. It does not check every domain-security setting, registrar state, or application configuration.

Why do Google and Cloudflare return different results?

Resolvers can have different cache ages, policies, DNSSEC behavior, and provider-specific JSON details. Compare the record rows, TTL values, and raw responses before deciding which difference matters.

Can this check internal DNS names?

No. The lookup uses public DNS-over-HTTPS resolvers. Private split-horizon names should be tested from a network and resolver that can actually see the internal zone.

Glossary:

DNS-over-HTTPS: A way to send DNS queries over HTTPS to a resolver.
TTL: Time to Live, the number of seconds a DNS answer may be cached.
PTR: A reverse DNS record type used to map an IP-derived reverse name to a hostname.
AD bit: Authenticated Data, a resolver flag indicating that returned data was validated according to DNSSEC rules.
CD bit: Checking Disabled, a query flag that asks the resolver not to apply DNSSEC validation.

References:

Domain Names - Implementation and Specification, RFC Editor, November 1987.
DNS Queries over HTTPS, RFC Editor, October 2018.
DNS-over-HTTPS, Google for Developers.
Using JSON, Cloudflare Docs.