Domain Name System (DNS) Record Lookup

Introduction:

Domain Name System records describe how a name points to addresses, mail servers, and other services. Reading them shows where traffic is directed and why a host behaves a certain way.

Enter one domain or an internet address, choose what you want to inspect, and review the answers in a tidy table. A quick domain record lookup for email deliverability and basic routing checks can spotlight configuration gaps early.

You provide a single line and the tool reads only the first non blank line so you can paste from logs or tickets without cleanup. Optional checks reveal whether mail policy entries exist and what action a receiver would see.

Results reflect the resolver you select and the moment you query, so very recent changes may take time to appear. For consistent comparisons, test the same name with the same settings.

Technical Details:

The Domain Name System (DNS) maps hostnames to resource records (RRs). This utility retrieves the contents of selected RR types and surfaces what matters for day‑to‑day troubleshooting: each record’s time to live, the data string, counts by type, whether any response carried the DNSSEC Authenticated Data (AD) flag, and whether common mail policy entries are published (DMARC policy and a DKIM selector check).

The computation is straightforward: queries are issued for the chosen types, answers are normalized by trimming trailing dots, then simple aggregates are derived — counts for A, AAAA, MX, NS, TXT, SOA, CAA, SRV, and PTR, a total record count, and a first CNAME target if present. Mail policy checks look for a DMARC tag set to v=DMARC1 and a policy of none, quarantine, or reject, and for a DKIM TXT that declares v=DKIM1.

Interpretation notes: the AD indicator reflects what the resolver asserts after validation; it is not a signature itself. DMARC shows only whether a policy exists and which action is stated; it does not evaluate alignment or reporting tags. The DKIM check reports presence by selector, not key strength or rotation.

Comparability and scope: IPv4 addresses are handled directly, and reverse lookups are used for PTR. IPv6 input accepts compressed forms; the zone identifier is ignored during reverse‑name construction. Domain validation is conservative and aims to filter obvious typos rather than enforce every edge of the standard.

Processing pipeline

1. Parse input, classify as domain or address; extract hostname if a URL is pasted.
2. For domains, convert to ASCII via URL parsing; for IPv6, expand and build ip6.arpa.
3. Normalize the record‑type list from comma or space separated text.
4. Issue DNS‑over‑HTTPS queries to the selected resolver for each type in parallel.
5. Collect answers, trim trailing dots, and compute type‑level counts and totals.
6. Mark AD if any response includes the Authenticated Data flag.
7. Optionally query _dmarc.<domain> for a policy and a DKIM selector TXT.
8. Render the Records table, derived Fields, and a JSON snapshot for copy or download.

Validation & bounds from the code

I/O formats & encoding

Networking & storage behavior

• Queries use DNS‑over‑HTTPS endpoints on the chosen resolver; responses are parsed client‑side.
• Cloudflare requests include an Accept: application/dns‑json header; Google uses a JSON endpoint.
• Optional timeouts are enforced with an abort controller; zero disables extra timeout.
• No persistent storage is used; copy, download, and file reads occur in your browser.

Privacy & compliance

No data is transmitted or stored server‑side by this app. DNS queries you initiate are sent from your browser to the selected resolver. Avoid pasting sensitive hostnames from private environments.

Assumptions & limitations

• Only the first non blank line is processed in single‑query mode.
• Domain checks are “likely valid” filters, not full specification conformance.
• IPv6 detection is permissive; compressed forms are accepted and expanded internally.
• AD reflects resolver validation state, not an on‑path signature check. Heads‑up
• DMARC parsing reads only policy action; other tags are not interpreted.
• DKIM is reported as present by selector only; keys and algorithms are not evaluated.
• Reverse lookups are used for addresses; only PTR is queried for IP input.
• Network filters, captive portals, or resolver blocks can yield empty answers.

Edge cases & error sources

• Internationalized names rely on URL parsing for ASCII conversion; odd host strings may fail.
• Trailing dots are removed from names and data; zone files with dots may look different.
• Very long TXT answers are concatenated by the resolver; formatting can vary.
• Aborted requests from short timeouts appear as lookup failures.
• Resolvers may differ in AD behavior for the same zone state.
• DMARC policies outside none, quarantine, reject are ignored.
• DKIM checks do not verify key length, rotation, or alignment.
• PTR names depend on address normalization; malformed input returns no reverse name.
• Local DNS caches and TTLs introduce timing differences between repeated runs.
• Firewall or content filters can block DNS‑over‑HTTPS endpoints.

Standards context

Behavior aligns with core concepts from the DNS specifications and security extensions, mail authentication policies, and selector records (e.g., the base DNS RRs, DNSSEC validation semantics, DMARC policy tags, and DKIM TXT markers).

Step‑by‑Step Guide

Domain records are retrieved and summarized to show where a name points and whether mail policies exist.

1. Enter a domain or address into Domain or IP.
2. Optionally adjust Record types and pick a Resolver.
3. Toggle DNSSEC DO or CD if you need validation signals.
4. Set a Timeout if networks are unreliable.
5. Enable Check DMARC and add a DKIM selector if you audit mail.
6. Run the lookup and read the Records, Fields, or JSON view.

Example. Input mail.example; enable DMARC and selector default. Review MX targets, note AD, confirm DMARC policy, and see whether that selector is published.

You now have concrete answers to share or archive.

FAQ

Troubleshooting

• Empty table: confirm record types include something the zone publishes.
• DMARC absent: ensure the base domain is queried, not a host name.
• DKIM missing: verify the selector spelling and that the option is enabled.
• Slow responses: set a modest timeout and retry.
• Different results across networks: pick a single resolver for comparisons.
• Punycode confusion: paste the Unicode name; it will be converted to ASCII for querying.

Advanced Tips

• Tip Keep record types lean to reduce latency when you only need mail checks.
• Tip Use the same resolver and options when capturing before‑and‑after snapshots.
• Tip Prefer querying the base domain for DMARC rather than a subdomain unless policy is delegated.
• Tip Inspect TTL differences to spot mixed caches or recently changed hosts.
• Tip For PTR, verify the address is correct and not a NAT or private range.
• Tip Copy the JSON view when you need a structured record of what was observed.

Glossary

Resource Record (RR)

A typed DNS entry such as A or MX.

Time To Live (TTL)

Seconds a record may be cached.

Authenticated Data (AD)

Resolver’s flag indicating DNSSEC validation.

DMARC

Mail policy stating none, quarantine, or reject.

DKIM selector

Label used to locate a DKIM TXT record.

PTR

Reverse mapping from address to a name.