DNS Record Enumerator

Introduction:

Domain Name System records are the public signposts that tell devices where a site, email, or service lives and how to reach it reliably. When something breaks, a Domain Name System record lookup for a domain can reveal whether the name points to the right place or if it drifts between answers.

You provide a domain name, a host name, or a numeric address and the page returns an inventory of published records along with timing and summary counts. It also highlights common configuration gaps, so you can spot missing mail policies or unexpected redirects without digging through separate lookups.

For example, if messages are bouncing you can confirm which mail exchangers are listed, whether sender policy text is present, and whether related host names resolve to addresses. Results should be treated as a snapshot because caching and resolver choice can change what you see from minute to minute. A clean looking record set still does not prove that the service behind it is reachable or correctly configured.

Choose this when you want a broad picture across many record types rather than checking one type at a time. For the clearest comparisons, run the same target twice with the same settings, then repeat after you publish a change and watch how time to live values settle.

If your target list includes internal names, treat them as sensitive and avoid sharing outputs widely. Only enumerate domains you own or have permission to assess.

Technical Details:

The Domain Name System (DNS) answers questions like “what address should this name use” by returning resource records grouped into sections such as Answer, Authority, and Additional. Each record includes a Time To Live (TTL) value in seconds, which is a caching hint that influences how quickly changes show up.

This enumerator sends DNS over HTTPS (DoH) queries to a selected resolver and collects response codes, flags, counts per section, and the elapsed query time in milliseconds. From those raw responses it builds a single record inventory and computes summaries such as unique names, unique values, records per type, and TTL and timing statistics.

Several record types are parsed into human friendly fields to make patterns easier to spot, including Start Of Authority (SOA), Mail Exchanger (MX), Service (SRV), Certification Authority Authorization (CAA), Naming Authority Pointer (NAPTR), and Service Binding (SVCB) and HTTPS service records. Optional checks also look for common email authentication records such as Sender Policy Framework (SPF), Domain-based Message Authentication, Reporting, and Conformance (DMARC), Mail Transfer Agent Strict Transport Security (MTA-STS), TLS Reporting (TLS-RPT), and DomainKeys Identified Mail (DKIM) selectors.

Interpret results as a point in time rather than a guarantee. Different resolvers and caches can surface different answers, wildcard DNS can make many names appear to exist, and some records describe intent but do not prove that a service is reachable.

Core processing pipeline

1. Read the first non blank line and normalize URLs, emails, and host and port inputs to a hostname.
2. Convert Unicode hostnames to ASCII for internationalized names before queries.
3. If the target is an IP address, build the PTR reverse lookup name and query only PTR.
4. Assemble record types from the core set and optional service, DNSSEC, and security families.
5. Query each record type over DoH and measure per query time in milliseconds.
6. Flatten Answer, Authority, and Additional sections into a single inventory.
7. Normalize values by removing TXT quotes and trailing dots where records allow them.
8. Optionally query email policy TXT names and DKIM selectors and summarize findings.
9. Optionally discover subdomains from certificate logs and a wordlist, then resolve A, AAAA, and CNAME.
10. Optionally resolve related targets referenced by NS, MX, SRV, SVCB, HTTPS, CNAME, and SOA.
11. Optionally test a random subdomain for wildcard answers and reverse resolve IPs to PTR.
12. Compute statistics, checks, parsed details, and structured JSON for exporting.

Core calculations

Interpretation aids

Variables and parameters

Constants and built in lists

Units, precision, and rounding

• Query duration is measured with a high resolution clock and rounded to the nearest millisecond.
• TTL averages are displayed with two decimals, and average query time is displayed with one decimal in the overview.
• Non finite numeric inputs, such as empty or invalid numbers, fall back to safe defaults.
• TXT values are displayed with quotes removed, and many name like values have trailing dots stripped.

Validation and bounds

I/O formats and normalization

Networking and storage behavior

• DoH lookups are sent to the selected public resolver provider, with an auto mode that tries Cloudflare then Google.
• Certificate discovery can call a Cert Spotter API and crt.sh, and may route requests through an auxiliary CORS proxy when needed.
• Requests can be aborted by a configurable timeout, and a cancel action prevents stale results from being displayed.
• No local or session storage writes are used in this package, and results stay in memory unless you export them.

Performance and complexity

Most work is network bound. The base request count is the number of queried record types, which is 8 core types plus any enabled families, and each discovered or referenced hostname adds three lookups for A, AAAA, and CNAME.

• Email checks add 4 TXT queries plus one TXT query per DKIM selector.
• Wildcard detection adds 3 queries against a random name.
• Reverse PTR adds 1 query per unique IP, capped by the configured limit.
• Host probes add 3 queries per wordlist item, and SRV probes add 1 query per service label.

Diagnostics and determinism

Identical inputs can yield different outputs across time because caches expire, certificate logs update, and wildcard tests use a random label. Within a single run, a sequence guard prevents late responses from overwriting a newer run after you cancel or restart.

Security considerations

• Use targets you own or are authorized to assess, since discovery and probing generate real DNS traffic.
• Heads-up Wildcard DNS can make wordlist discovery appear successful even when hosts do not exist.
• TXT records can contain sensitive policy details, so treat exports as potentially confidential.
• Public resolvers and discovery sources may log queries, so avoid pasting secrets into the target field.

Assumptions and limitations

• The tool is designed for public DNS visibility through the selected resolver, not private split horizon views.
• Only the first non blank line of the target input is processed, and extra lines are ignored.
• Hostnames are validated with relaxed rules that allow underscores for service labels.
• When the target is an IP address, the tool only performs PTR lookups and skips other types.
• TXT records are returned as separate strings and are not concatenated into a single logical value.
• Discovery through certificate sources is best effort and may miss new or unissued subdomains.
• A max discovery value of 0 removes the local cap, but discovery sources still have page and count limits.
• Target resolution follows hostnames referenced by specific record types and does not chase every embedded name.
• Average values summarize what was returned and do not predict future resolver performance.
• Exports mirror the current view and do not include hidden context beyond the collected responses.

Edge cases and error sources

• Internationalized domain names are converted to ASCII, and different Unicode spellings can map to the same name.
• Trailing dots are trimmed from names, which can hide the difference between relative and absolute forms.
• Inputs like email addresses are reduced to the domain portion after the at sign.
• Host and port parsing only strips a port when there is a single colon and trailing digits.
• Bracketed IPv6 forms are supported, but unusual zone identifiers can fail PTR conversion.
• IPv6 expansion depends on canonical hextet parsing, and malformed compression can yield an invalid PTR name.
• Resolvers can return empty Answer sections with NOERROR, which is not the same as NXDOMAIN.
• Timeouts and network blockers can produce NO RESPONSE for one resolver but not the other.
• Long TLSA and SSHFP fingerprints are shortened in summaries for readability.
• Some record types rely on token splitting, so unexpected whitespace can affect parsed fields.
• Wildcards and parking services can cause many unrelated names to resolve to the same answers.
• Cancellation stops result display but may not stop in flight network requests already sent.

Standards and conventions

Record meanings and flags follow common IETF DNS conventions, while email policy checks follow widely used SPF, DMARC, DKIM, MTA-STS, and TLS-RPT conventions.

Privacy and compliance

Requests are made from the browser to the chosen resolver and optional discovery sources, results are not written to local storage by this package, and use should be limited to authorized targets.

Step by Step Guide:

Domain record enumeration is easiest when you start with the core name, then expand outward to related hosts and policies until the picture matches what you intended.

1. Enter a Target domain, hostname, or IP address, then run the enumeration.
2. If results look inconsistent, switch the Resolver and compare response codes and TTL.
3. Adjust Timeout if your network is slow or the resolver is rate limiting.
4. Enable service, DNSSEC, or security record families when you need a wider footprint.
5. Keep email checks enabled when diagnosing mail delivery or spoofing controls, and add DKIM selectors if you know them.
6. Enable discovery and set a reasonable max discovered hosts when you want a quick subdomain sweep.
7. Turn on related target resolution to see where name servers, mail exchangers, and service targets point.
8. Use Wildcard detection before trusting discovery results, and enable reverse PTR when you need hostname context for IPs.

Pro tip: keep one known good baseline run and compare future changes against it before chasing noise.

FAQ:

Troubleshooting:

• If you see NO RESPONSE, try switching the resolver or increasing the timeout.
• If subdomain discovery shows nothing, enable certificate discovery and wordlist discovery, then rerun.
• If discovery finds many hosts that all resolve the same way, check whether wildcard detection was triggered.
• If email checks show missing records, confirm you are querying the correct organizational domain rather than a subdomain.
• If reverse PTR returns no hostnames, the IP may not have PTR records published.
• If parsed details look odd, inspect the raw record inventory for unexpected spacing or quoting.

Advanced Tips:

• Tip Start with core types, then enable DNSSEC only when you need validation clues.
• Tip Use related target resolution to spot external dependencies outside the target domain.
• Tip Keep a low max discovery value for quick triage and raise it only when the baseline looks clean.
• Tip Add known DKIM selectors from your mail platform to avoid guessing and reduce noise.
• Tip When SERVFAIL appears, rerun after a short wait to separate transient upstream failures from a persistent issue.
• Tip Treat PTR names as hints and corroborate them with forward lookups if you use them for access rules.

Glossary:

DNS

Domain Name System, maps names to records used by clients.

DoH

DNS over HTTPS, DNS queries sent via HTTPS requests.

TTL

Time To Live, seconds a resolver may cache an answer.

RCODE

Response code, indicates success, failure, or non existence.

PTR

Pointer record used for reverse mapping an IP to a name.

DNSSEC

DNS Security Extensions, signatures that protect record integrity.

AD and CD

Authenticated Data and Checking Disabled flags related to DNSSEC validation.

Wildcard DNS

A zone behavior where many names resolve even if not defined.

CT

Certificate Transparency, public logs that can reveal issued names.

SPF and DMARC

Email authentication policies published as TXT records.