DNS Record Lookup
Lookup DNS records online for a domain or IP, inspect TTL and DNSSEC response signals, and export clean tables or charts for troubleshooting.DNS Record Summary
| 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.
|
||
Introduction
DNS records are the published directions that tell clients which address, alias, mail route, name server, or policy data belongs to a name. When a cutover only partly shows up, a mail route looks wrong, or you need to see exactly what one public resolver is returning right now, a plain record lookup is usually the fastest first check.
This page looks up one target at a time and turns the answer set into several views: a records table, a field summary, raw resolver JSON, a record-count chart, a TTL chart, and a full JSON export. The default lookup asks for a broad bundle of common record types, and the Advanced panel lets you switch to web, email, security, or DNSSEC-focused bundles or enter your own custom list.
The lookup runs in your browser and sends queries directly to the selected DNS-over-HTTPS resolver. That is useful for quick troubleshooting because you see the resolver's current answer without a server-side translation layer, but it also means the domain or IP you enter and the flags you choose are disclosed to that resolver. The result is a single-resolver snapshot, not a worldwide propagation survey and not an authoritative-zone viewer.
IP input needs one extra adjustment. The page can build the correct reverse lookup name for IPv4 and IPv6, but it only sends that reverse query when the requested type list includes PTR. The default presets do not include PTR, so an IP lookup usually starts by switching to Custom and entering PTR in the record-types field.
Technical Details
The page starts with the first non-blank line from the input box and ignores any extra pasted lines. If the value looks like an HTTP or HTTPS URL, it extracts the hostname before querying. If the value includes internationalized characters, the hostname is converted to its ASCII form before lookup. Domains are then checked for basic structural validity, while IP addresses are handled separately.
Each requested record type becomes its own DNS-over-HTTPS request. Google Public DNS and Cloudflare both expose JSON-based DoH endpoints, and this tool uses those browser-friendly endpoints rather than binary DNS wireformat. In Auto mode the page tries Google first and falls back to Cloudflare if the response does not look like recognizable DNS JSON. That behavior makes the tool convenient for ordinary troubleshooting, but it also means the raw-response tab reflects provider-specific JSON rather than one formal cross-provider standard.
| View | What it shows | Best use |
|---|---|---|
| DNS Records Overview | Flattened answer rows with type, owner name, TTL, and record data. | Fast troubleshooting and clean CSV or DOCX evidence. |
| Field Breakdown | Normalized input, syntax-valid flag, resolver, DNSSEC AD flag, counts, and common summary facts. | Readable status snapshots for tickets and change notes. |
| Raw DoH Responses | The resolver JSON saved by query type, including the request name, response body, and resolver actually used. | Resolver-specific debugging and answer-shape inspection. |
| Record Type Breakdown | Bar chart of returned answer-row counts per type. | Quick inventory checks when many types are returned together. |
| TTL Distribution | Average, minimum, and maximum TTL grouped by returned type. | Cache-window review during migrations and inconsistent-answer triage. |
| JSON | Inputs, normalized single-result object, records, warnings, and chart data. | Archiving and repeatable comparisons outside the page. |
| Bit or flag | What the tool changes or reports | How to read it |
|---|---|---|
| DO | Adds the DNSSEC OK request bit so the resolver may include DNSSEC records such as RRSIG, NSEC, or NSEC3. |
Turn it on when you want DNSSEC material in the response. Leaving it off does not prove a zone lacks DNSSEC; it only means you did not request the extra records. |
| CD | Sets Checking Disabled in the query. | Use it only when you intentionally want the resolver not to validate on your behalf. It changes how you should interpret any AD signal that comes back. |
| AD | Reported exactly as the selected resolver returned it. | Read it as the resolver's authenticated-data claim, not as an independent validation performed by this page. |
The chart logic is intentionally simple. Record Type Breakdown counts answer rows by returned type. TTL Distribution groups answer rows by type and calculates average, minimum, and maximum TTL from the TTL values that came back in the resolver response. That makes the charts useful for spotting answer-shape changes and cache spread, but they do not predict global propagation timing or authoritative-zone intent on their own.
Everyday Use & Decision Guide
Start with the narrowest record bundle that matches your question. A broad preset is fine for general reconnaissance, but a smaller type set makes the output easier to scan and reduces the chance that unrelated rows distract from the real issue. If you are diagnosing a web cutover, the web-focused preset is usually enough. If the question is mail routing, the email bundle gives you a better first pass. If you are checking DNSSEC material, switch to the DNSSEC preset and decide up front whether you also want the DO or CD flags changed.
The summary badges are the first quick read. They show which resolver answered, whether the resolver returned AD, and how many common record families were found. After that, most people should read the records table before touching the raw tab. The table is where you can see exactly which answers came back, what their TTLs are, and whether the response contains the type you expected.
| Starting point | Requested types | Good for |
|---|---|---|
| General | A, AAAA, CNAME, TXT, MX, NS, SOA, CAA, SRV |
Broad first-pass checks when you need the overall DNS picture. |
| Web | A, AAAA, CNAME, HTTPS, SVCB, CAA, TXT |
Site cutovers, aliases, and newer web-service binding records. |
MX, TXT, SRV, CAA, NS, SOA |
Mail route checks and supporting DNS context. | |
| Security | CAA, TLSA, SSHFP, OPENPGPKEY, TXT |
Certificate, SSH host-key, and related policy evidence. |
| DNSSEC | DS, DNSKEY, RRSIG, NSEC, NSEC3 |
Delegation-signing and proof material, especially with DO enabled. |
| Custom | Your own comma-separated or space-separated list. | PTR lookups for IP addresses and any record combination not covered by a preset. |
Resolver choice also matters. Google and Cloudflare are both recursive public resolvers with their own caches and operational behavior. If a recent change has not fully propagated, one resolver may show a newer answer set or a different TTL than another. The Auto setting is a convenience path, not a comparison mode. If you want to compare two resolver views, rerun the same lookup with each resolver selected and keep the type list unchanged.
Use the raw-response tab only when the simplified table is not enough. Most operational questions are answered faster by the records table, the field summary, and the two charts. The raw tab becomes valuable when you need to inspect the actual JSON payload, the response status, or the resolver-specific metadata that the page stores by type.
Step-by-Step Guide
- Enter one value only. The page uses the first non-blank line and ignores any extra pasted lines after that.
- If you are checking a hostname, start with the preset that matches the job. If you are checking an IP address, open
Advanced, switch toCustom, and enterPTRso the page can build the reverse lookup name. - Choose the resolver you want to sample. Leave
Timeoutat0unless you specifically need an extra browser-side request timeout. - Turn on
DOwhen you want DNSSEC records included. Turn onCDonly when you deliberately want the resolver not to validate for you. - Run the lookup and read the summary badges and DNS Records Overview first. Then move to Field Breakdown, charts, raw responses, or JSON depending on the question you are answering.
- Export the evidence you need. Tables can be copied or downloaded as CSV and exported as DOCX, charts can be saved as PNG, WebP, JPEG, or CSV, and both the normalized and raw JSON views can be copied or downloaded.
Interpreting Results
The records table is the main truth surface for normal use. Each row is a returned answer with its type, owner name, TTL, and data field. If the answer you needed is missing, look first at the requested type list before assuming the zone is wrong. Many "missing record" cases are really "wrong query type" cases, especially when an IP was entered without switching the type list to PTR.
The Valid field in the breakdown view is only a shape check for domain syntax. It helps explain obviously malformed input, but it is not proof that a domain exists, that a zone is delegated correctly, or that the resolver should return answers. A valid-looking domain can still return no answers for the types you requested, and the page will warn about that explicitly.
TTL values are often the most useful operational clue. TTL is the cache lifetime attached to a returned record. When one record family has a short TTL and another has a long one, different users can continue to see different states for longer than expected. The TTL chart makes that easier to spot by grouping answer rows per type and showing average, minimum, and maximum TTL together.
Read the AD badge carefully. The page does not validate DNSSEC on its own. It simply shows whether the selected resolver reported authenticated data. That can still be useful, especially when you trust the resolver path you are testing, but it is not the same thing as an end-to-end DNSSEC audit from a validator you control. If you enable CD, remember that you asked the resolver not to validate on your behalf.
The raw-response tab is the fallback when you need the resolver payload as-is. The simplified views flatten answer rows and calculate charts, while the raw tab preserves the provider JSON per type. If the table and the raw view seem to disagree, the raw view is the better place to confirm whether the difference comes from answer normalization, missing answer rows, or the resolver's response status.
Worked Examples
Checking a web cutover
Use the web preset for the hostname or full URL you care about. Read the A, AAAA, and CNAME rows first, then glance at the TTL chart. If the addresses look right but some users still reach the old site, uneven TTLs can explain why caches are aging out at different times.
Checking mail routing context
Use the email preset for the domain. The records table will show the returned MX rows, while the supporting TXT, NS, and SOA rows provide surrounding DNS context. If you only need the routing picture, export the records table. If you need a concise ticket summary, the field breakdown is often the cleaner artifact.
Reverse lookup from a log IP
Paste the IP address, open Advanced, choose Custom, and set the record type to PTR. The page will convert the IP to its reverse lookup name and query that target. If you forget to request PTR, the default presets will usually come back with no answers even though reverse DNS may exist.
FAQ:
Why did an IP lookup return no records?
Because the page only performs reverse DNS for IP input when PTR is in the requested type list. The default presets do not include PTR, so switch to Custom and request PTR explicitly.
Does an AD badge mean DNSSEC is fully proven?
No. It means the selected resolver reported authenticated data. That can be useful evidence, but this page is not a full independent DNSSEC validator.
Is this the same as a propagation checker?
No. It shows one resolver path at a time. That is valuable for diagnosis, but it does not tell you what every resolver or every region in the world is seeing.
Why keep both a raw tab and a records table?
The records table is faster to read and export, while the raw tab preserves the resolver JSON exactly as returned for each queried type. They serve different troubleshooting needs.
Glossary:
- DNS-over-HTTPS
- A way to send DNS queries over HTTPS rather than plain DNS transport.
- TTL
- Time to live. The cache lifetime attached to a returned record, expressed in seconds.
- PTR
- The record type used for reverse DNS, mapping an address lookup name back to a host name.
- DO bit
- The DNSSEC OK request bit that asks the resolver to include DNSSEC-related records when appropriate.
- CD bit
- Checking Disabled. A request bit that tells the resolver not to validate DNSSEC on the client's behalf.
- AD flag
- Authenticated Data. A response signal from the resolver that the returned data was treated as authenticated under that resolver's policy.
References:
- DNS Queries over HTTPS (DoH), RFC Editor.
- Indicating Resolver Support of DNSSEC, RFC Editor.
- Redefinition of DNS Authenticated Data (AD) bit, RFC Editor.
- Domain Names - Implementation and Specification, RFC Editor.
- JSON API for DNS over HTTPS, Google Public DNS.
- DNS over HTTPS JSON API, Cloudflare Docs.