DNS Record Enumerator

Introduction:

DNS records are the public instructions that tell recursive resolvers where a name should point, which mail hosts should accept traffic, whether certificate issuance is constrained, and whether signed data is visible. When those records are incomplete or inconsistent, users often experience the problem as a broken site, failed mail flow, or confusing resolver drift rather than as a DNS issue.

This page gathers that public view for one target and turns it into a review set that is easier to scan than a stack of single-record lookups. You can enter a domain, hostname, URL, email address, or IP address. Domain-style input expands into core record checks and, when enabled, service-binding records, DNSSEC material, mail-policy names, and A or AAAA probes for common host labels. IP input follows a different path and queries only the derived PTR name for reverse DNS.

The result is split into practical layers. The summary box and Probe Snapshot answer the immediate questions about probe success, record volume, latency, TTL spread, and the strongest next action. Hardening Queue turns common DNS, mail-authentication, and DNSSEC gaps into ranked follow-up items. Record Ledger and Resolver Evidence keep the exact lookup trail available, while the two charts compress type mix and a local posture heuristic for repeat comparisons.

The privacy and scope boundary matters. The browser builds the query plan locally, then sends requests to public DNS-over-HTTPS providers, and the active target plus settings are also reflected in the page URL so runs can be shared or repeated. Use it only for assets you own or are explicitly allowed to assess. It does not attempt zone transfers, it does not talk to authoritative servers directly, and it does not prove that a website, mail server, or certificate endpoint is reachable.

Technical Details:

Input handling is deliberately narrow so the run stays predictable. The page keeps only the first nonblank line, trims whitespace, strips a trailing dot, lowercases the result, extracts the hostname from a pasted URL, and uses the domain portion of a pasted email address. Hostnames must already be ASCII labels, so an internationalized name has to be entered in its A-label form. If the target is an IPv4 or IPv6 address, the page converts it into the matching in-addr.arpa or ip6.arpa name and switches to PTR-only mode.

Resolver behavior is explicit rather than hidden. In Auto mode the page tries Cloudflare first and then falls back to Google only after a failed request. Pinning one provider is useful when you want a single recursive view for change review or when you are chasing resolver-specific behavior. Timeout and retry settings control how aggressively the run waits for each answer. The optional DO and CD bits are passed through to the outbound request so DNSSEC-aware lookups can ask for DNSSEC records or request unchecked data from a validating resolver path when needed.

Returned answers are normalized before they reach the tables. TXT records are dequoted, MX rows keep preference plus exchange, SOA rows collapse to the primary server and serial, CAA rows keep the useful tag and value, and SVCB or HTTPS answers are shortened into a more readable form. The ledger always captures the Answer section, and the Authority and Additional toggles decide whether those sections should be recorded too.

Everyday Use & Decision Guide:

The fastest way to get useful output is to pick the preset that matches the question instead of turning every switch on at once. That choice changes the query plan, which means it also changes record counts, chart shapes, and the hardening queue. If you are comparing a before-and-after state, keep the same preset, resolver mode, and target format for both runs.

For most domains, read the page in this order: summary box, Probe Snapshot, Hardening Queue, then the evidence tabs. That sequence gets you to the highest-value answer quickly without hiding the raw details. The summary badges call out resolver mode, unique record-type count, probe count, average latency, whether AD was seen, and any DMARC or SPF signals that were discovered. The queue then tells you which finding should be handled first.

Use the advanced controls when you have a concrete reason. Turn on service records when you care about endpoint hints or application discovery. Turn on DNSSEC when you are checking a signed zone or parent delegation. Turn on Authority or Additional capture when you want more of the resolver response recorded in the ledger. Edit the DKIM selector list or host probe list when the defaults do not match the environment you are auditing.

Step-by-Step Guide:

1. Enter one target as a domain, hostname, URL, email address, or IP address.
2. Choose the preset that best matches the job. Balanced is the normal first pass.
3. Select Auto if you want fallback behavior, or pin Cloudflare or Google when you need one resolver's exact view.
4. Enable or disable service records, DNSSEC checks, mail-policy names, Authority capture, Additional capture, and host probes to match the question you are answering.
5. Edit the DKIM selector list or host probe list if your environment uses non-default labels.
6. Run the enumeration and read the summary box plus Probe Snapshot first.
7. Use Hardening Queue to identify the next action, then confirm the evidence in Record Ledger and Resolver Evidence.
8. Export CSV, DOCX, chart images, chart CSV, or JSON when you need to attach the run to a ticket, audit note, or change record.

If the target is an IP address, keep expectations narrow. The page is answering a reverse-DNS question only in that mode. Run the hostname separately when you also need forward records, mail-policy checks, or DNSSEC visibility for the zone.

Interpreting Results:

The snapshot table is your quick summary of run health. It records the normalized target, resolver mode, successful probe count, total records collected, latency range, TTL range, SPF coverage, DMARC policy, and the first queued action. A high record count is not automatically good, and a low count is not automatically bad. The important question is whether the records you expected for this target and preset are present and consistent.

The hardening queue is opinionated on purpose. Missing apex NS or SOA records are treated as urgent because they undermine normal delegation visibility. Missing SPF or DMARC is also treated as urgent when mail-policy checks are in scope. Missing CAA, absent _mta-sts, missing parent DS, or failed query classes are ranked below that, but they still matter because they often explain why posture looks weaker than expected.

Record Ledger is the right place to inspect exact names, TTLs, normalized data, and whether a row came from Answer, Authority, or Additional. Resolver Evidence shows the query string, status, provider, answer count, AD flag, and response time for each probe. Those two tabs are where you decide whether the hardening advice matches the underlying facts.

Record Constellation is a type-count view, not a severity view. It helps you see whether the run is dominated by TXT-heavy mail records, basic apex records, or a broader service mix. Policy Signal Radar goes a step further and compresses the local rule set into five dimensions. That makes it useful for comparing repeated runs with the same settings, but it should never be mistaken for a compliance certification.

A few absences need context. Some domains do not need to resolve directly at the apex, so missing apex A or AAAA is only a problem when direct apex resolution is expected. Likewise, a missing service-binding record does not mean the service is broken. It may simply mean the domain is using older discovery methods or no service-binding record at all.

Worked Examples:

Change review after a DNS migration

A team has moved a domain to new authoritative hosting and wants to confirm the public recursive view without testing every record manually. Running the Balanced preset gives a broad apex snapshot plus a small host-probe set. The most useful review order is summary box, Probe Snapshot, then Record Ledger for NS, SOA, apex A or AAAA, and CAA. If host probes for www or api fail while the apex looks correct, the migration may be incomplete at the hostname layer rather than at the zone apex.

Mail hardening review before a cutover

A mail administrator wants to verify that the published policy set is strong enough before routing changes are finalized. The Mail hardening preset keeps focus on SPF, DMARC, DKIM selectors, _mta-sts, _smtp._tls, and a mail-heavy probe list. Here the queue matters because it flags missing SPF, missing DMARC, a DMARC policy stuck at none, a missing MTA-STS identifier, and an SPF lookup count that approaches or exceeds the RFC ceiling. The ledger then gives the exact TXT content you need for the change record.

DNSSEC visibility check after signing a zone

After publishing DNSKEY material and requesting a parent DS record, a deeper run helps confirm that public resolvers can see the chain. Use Balanced or Deep audit with DNSSEC enabled, then look first for DNSKEY, DS, and RRSIG rows in the ledger. If AD is still absent, that does not automatically mean the signing failed, but it is a reason to compare resolver behavior and verify the parent-side delegation step.

PTR confirmation for a public IP address

An administrator has an address and needs to know whether reverse DNS is published. Entering the IP makes the page construct the reverse name and query only the PTR path. That gives a quick answer to the reverse-DNS question, but nothing more. If the address maps back to a hostname and you want to inspect that hostname's forward records, mail TXT names, or DNSSEC signals, run the hostname as a separate target.

FAQ:

Glossary:

TTL

Time to live, the cache hint attached to a DNS record in seconds.

PTR

The reverse-DNS record type that maps an IP address back to a hostname.

DO bit

A DNSSEC-related query flag used to request DNSSEC records in a response path.

CD bit

A query flag that asks a validating resolver path to return data without enforcing its own signature-validation result on that response.

AD flag

A resolver-reported indicator that the returned data was considered authentic by that recursive resolver.

CAA

A DNS record that lets a domain publish which certificate authorities are allowed to issue certificates for that name.

DKIM selector

The label placed before ._domainkey when looking up a domain's DKIM public key record.

SVCB and HTTPS records

Service-binding DNS records that can advertise preferred endpoints or connection parameters for clients that understand them.

References:

• RFC 8484: DNS Queries over HTTPS (DoH), RFC Editor.
• RFC 4035: Protocol Modifications for the DNS Security Extensions, RFC Editor.
• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, RFC Editor.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC), RFC Editor.
• RFC 8461: SMTP MTA Strict Transport Security (MTA-STS), RFC Editor.
• RFC 8460: SMTP TLS Reporting, RFC Editor.
• RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record, RFC Editor.
• RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records), RFC Editor.