DNS Record Enumerator
Enumerate public DNS records for a domain, URL, email domain, or IP with resolver evidence, mail-auth checks, DNSSEC clues, and action flags.{{ summaryStateLabel }}
| # | Metric | Value | Notes | Copy |
|---|---|---|---|---|
| {{ idx + 1 }} | {{ row.metric }} | {{ row.value || '-' }} | {{ row.note || '-' }} |
| # | Priority | Recommendation | Why now | Copy |
|---|---|---|---|---|
| {{ idx + 1 }} | {{ row.priority }} | {{ row.recommendation }} | {{ row.rationale }} |
| # | Section | Type | Name | Data | TTL | Copy |
|---|---|---|---|---|---|---|
| {{ idx + 1 }} | {{ row.section }} | {{ row.type }} | {{ row.name }} | {{ row.data }} | {{ row.ttl }} |
| # | Query | Status | Resolver | Answers | AD | Latency (ms) | Copy |
|---|---|---|---|---|---|---|---|
| {{ idx + 1 }} | {{ row.query }} | {{ row.status }} | {{ row.resolver }} | {{ row.answers }} | {{ row.ad ? 'Yes' : 'No' }} | {{ row.ms === null ? '-' : row.ms }} |
Introduction
DNS failures often look like something else. A web server appears down, mail is rejected, a certificate order stalls, or a new service works from one network but not another. Before changing application code or firewall rules, the useful first question is narrower: which public DNS records can a normal recursive resolver see for this name or IP address?
Enumeration collects those public answers by asking for several record families in one run. Address records point names to IPv4 and IPv6 addresses. Delegation records expose authoritative name servers and zone administration. Mail records describe routing and sender policy. DNSSEC records show whether signing material is visible. Service records and host-label probes can reveal public endpoints without claiming to discover every subdomain.
A recursive resolver is an evidence source, not the zone itself. It may answer from cache, apply DNSSEC validation, hide an authority-section detail, time out on one record type, or show a value that another resolver has not seen yet. That is why target spelling, resolver choice, DNSSEC flags, record families, timeout, retries, and host probes should stay consistent when comparing two runs.
Public DNS records answer DNS questions only. An A record can exist while the web server is offline. An MX record can route mail while SPF, DKIM, or DMARC is weak. A visible CAA record can limit certificate authorities without proving that a certificate is installed. A PTR answer can name a host without proving that the hostname maps back to the same address.
| Record family | Useful evidence | Common mistake |
|---|---|---|
| Address and reverse DNS | A, AAAA, and PTR answers. |
Reading resolution as proof of HTTP, TLS, SSH, or application health. |
| Mail and sender policy | MX, SPF TXT, DMARC TXT, DKIM selector TXT, MTA-STS, and TLS-RPT records. |
Assuming successful delivery means sender authentication is enforced. |
| Delegation and security policy | NS, SOA, CAA, DNSKEY, DS, and RRSIG. |
Treating optional policy records as universal requirements for every domain role. |
Enumeration is strongest as a triage and audit aid for zone migrations, mail-provider cutovers, certificate policy reviews, DNSSEC checks, reverse-DNS checks, and public-host inventory. It narrows where to investigate next, but the final confirmation often comes from a second DNS resolver or a protocol-specific test such as HTTP, TLS, SMTP, or a mail-authentication report.
How to Use This Tool:
Begin with the smallest record set that answers the current change or incident, then widen the run when the first evidence points to a DNS, mail, DNSSEC, or host-discovery gap.
- Enter one DNS target. A domain, hostname, URL, email address, IPv4 address, or IPv6 address is accepted. If several lines are pasted, only the first nonblank target runs and Run Notes reports the ignored lines.
- Choose Preset. Balanced includes core records, service records, DNSSEC, mail-auth checks, authority data, and up to 6 host probes. Fast triage limits optional checks and uses no retries. Mail hardening focuses on mail policy and mail host labels. Deep audit includes authority, additional, service, DNSSEC, mail, and up to 12 host probes.
- Set Resolver. Auto tries Cloudflare and can fall back to Google. Pin Cloudflare or Google when you need one provider view for repeat comparisons.
- Open Advanced for repeatable troubleshooting. Timeout is clamped from 400 to 20,000 ms, and Retries is clamped from 0 to 4. The DNSSEC DO bit asks for DNSSEC material, while the CD bit is for broken-chain troubleshooting.
- Toggle record families to match the question. Service binding adds
SVCB,HTTPS,SRV, andNAPTR. DNSSEC addsDNSKEY,DS,RRSIG,NSEC, andNSEC3. Mail-auth checks add SPF, DMARC, selected DKIM, MTA-STS, and TLS-RPT names. - Use Probe common host labels when public hostnames matter. Host probe list accepts labels or full names, and Max host probes limits the expanded A and AAAA questions.
- Run Enumerate. If the target is rejected, check for spaces, unsupported characters, labels longer than 63 characters, a hostname without a dot, or an internationalized domain that needs its ASCII A-label form.
Interpreting Results:
Probe Snapshot is the first read. Check the normalized target, resolver mode, successful probes, record count, latency profile, TTL range, SPF coverage, DMARC policy, and top queued action. Counts are useful for comparing runs with the same settings, but they are not a health score.
Record Ledger is the row-by-row evidence. Confirm owner names, record types, values, TTLs, and resolver labels there before editing a zone. Resolver Evidence explains how each DNS question behaved, including DNS status, answer count, authenticated-data flag, resolver, and latency.
Hardening Queue turns current evidence into follow-up items. High items commonly include missing apex NS or SOA, missing SPF, missing DMARC, or SPF policies above the 10 DNS-mechanism lookup ceiling. Medium and low items need context, especially for CAA, MTA-STS, TLS-RPT, DNSSEC signing material, and failed query classes.
Record Constellation and Policy Signal Radar are comparison aids. They can show whether repeated runs are moving in the expected direction, but a full-looking chart does not prove website reachability, mailbox delivery, TLS validity, DNSSEC correctness, or certificate issuance policy by itself.
Technical Details:
DNS enumeration is a typed lookup plan. For domain-like targets, the core plan asks the apex for A, AAAA, NS, SOA, MX, TXT, and CAA. Optional families add service binding, DNSSEC, mail-authentication names, authority records, additional records, and A/AAAA probes for selected host labels. IP targets switch to a single reverse-DNS PTR path.
Input normalization keeps the run bounded. A URL is reduced to its host, an email address is reduced to its domain, a trailing dot is removed, hostnames are lowercased, and internationalized names need their ASCII A-label form. Pasted extra lines are ignored after the first nonblank target so one run cannot mix unrelated domains.
Rule Core:
| Query family | Names and record types | What the evidence can support |
|---|---|---|
| Core zone view | Apex A, AAAA, NS, SOA, MX, TXT, and CAA. |
Address visibility, delegation clues, zone administration, mail routing, text policy, and certificate-authority policy. |
| Mail-authentication view | Apex SPF TXT, _dmarc, selected ._domainkey labels, _mta-sts, and _smtp._tls. |
Sender authorization, DMARC disposition, DKIM selector visibility, MTA-STS policy discovery, and SMTP TLS reporting. |
| DNSSEC visibility | DNSKEY, DS, RRSIG, NSEC, NSEC3, and resolver AD evidence when available. |
Whether signing material and authenticated-data signals are visible through the selected recursive resolver path. |
| Service and host discovery | SVCB, HTTPS, SRV, NAPTR, plus A/AAAA probes for configured labels. |
Public service hints and likely hostnames, without claiming complete subdomain enumeration. |
| Reverse DNS | PTR for the derived in-addr.arpa or ip6.arpa name. |
Whether an IP address maps back to a hostname. Forward records for that hostname need a separate run. |
Resolver responses are normalized for review. TXT strings are dequoted, MX rows keep preference and exchange, SOA rows keep the primary server and serial, CAA rows keep the tag and value, and service-binding rows preserve priority, target, and parameters. Authority and additional sections appear only when their controls are enabled.
Mail hardening checks parse specific TXT records. SPF lookup pressure counts DNS-mechanism terms such as a, mx, ptr, include:, exists:, and redirect=. DMARC reads the p= policy, MTA-STS expects a v=STSv1 policy ID record, and TLS-RPT expects a v=TLSRPTv1 report destination record.
Formula Core:
The radar scores are local summaries derived from the current evidence. Core DNS, mail authentication, DNSSEC, and similar boolean groups use the same pass-rate rule:
Reliability is successful NOERROR probes divided by total probes. Action Debt starts at 100 and subtracts more for high-priority recommendations than for medium or low recommendations:
Here H, M, and L are the number of high, medium, and low queued items. A score near 100 means the current query set produced fewer flagged actions. It does not certify DNS compliance or prove that all external service requirements are met.
| Trigger | Priority | Technical reason |
|---|---|---|
Missing apex NS or SOA. |
High | Delegation and zone-administration visibility are baseline DNS evidence. |
| Missing SPF or missing DMARC when mail checks are included. | High | Receivers lose important sender-authorization and disposition guidance. |
| SPF DNS-mechanism count is greater than 10, or reaches 9 to 10. | High or Medium | SPF evaluation has a 10-lookup ceiling, so near-limit policies are fragile. |
DMARC policy is missing or remains p=none. |
High or Medium | Missing DMARC provides no policy record; p=none is monitoring rather than enforcement. |
| Missing CAA, MTA-STS, TLS-RPT, DS, DNSKEY, RRSIG, AD evidence, or successful query classes. | Medium or Low | The importance depends on whether the domain issues certificates, receives mail, or is expected to be DNSSEC-signed. |
Privacy and Accuracy Notes:
The browser sends the active target and selected DNS questions to the chosen public DNS-over-HTTPS resolver. The page can also carry the target and options in the address bar for repeatable runs, so avoid entering internal names or private hostnames that you are not allowed to disclose.
- Use the lookup for domains, hosts, and IP addresses you own or are authorized to review.
- Resolver answers can differ because of cache state, propagation timing, DNSSEC validation behavior, provider policy, timeout limits, and blocked networks.
- DNS evidence does not prove website availability, SMTP acceptance, mailbox deliverability, TLS certificate validity, or application health.
Worked Examples:
Zone migration check
A team moves example.com to new DNS hosting and runs Balanced with the resolver pinned for comparison. Probe Snapshot should show the normalized target, successful probes, a sensible TTL range, and the top queued action. If Hardening Queue flags missing NS or SOA, confirm the exact rows in Record Ledger before editing the zone.
Mail-provider cutover
A mail administrator uses Mail hardening with selectors such as default, google, and selector1. Useful evidence includes apex SPF, _dmarc, DKIM selector TXT rows, _mta-sts, and _smtp._tls. If DMARC policy reports p=none, the domain is monitoring alignment failures but not asking receivers to quarantine or reject them.
Signed-zone review
After enabling DNSSEC, a Deep audit run with the DNSSEC DO bit enabled should expose DNSKEY, DS, and RRSIG evidence when the chain is visible. If Resolver Evidence shows AD as No, repeat the run with another pinned resolver and check parent-side DS publication before assuming local signing failed.
Reverse lookup from an IP address
Entering 8.8.8.8 builds a PTR-only lookup. Probe Snapshot labels the target as an IP target, and Record Ledger shows any returned PTR rows. The run does not enumerate forward records or mail policy for the returned hostname; enter that hostname as a separate target when those records matter.
FAQ:
Why was my target rejected?
The target must normalize to an ASCII domain, hostname, URL host, email domain, IPv4 address, or IPv6 address. Check unsupported characters, spaces, missing dots, overlong labels, or an internationalized domain that needs its ASCII A-label form.
Why were extra pasted lines ignored?
Each run uses one target. The first nonblank line is kept so the query plan remains unambiguous, and Run Notes reports how many additional lines were skipped.
Does an AD flag prove DNSSEC is correct?
No. AD is a resolver-reported authenticated-data signal. Check DNSKEY, DS, and RRSIG rows, then compare another resolver when DNSSEC correctness matters.
Why did a record type return no rows?
The record type may not exist, the resolver may have returned a non-success DNS status, or an IP target may have switched to PTR-only mode. Open Resolver Evidence to separate empty answers, DNS statuses, timeouts, and provider failures.
Can this confirm that a website or mailbox works?
No. It confirms public DNS evidence from selected recursive resolvers. HTTP, TLS, SMTP delivery, mailbox acceptance, and application behavior need separate checks.
Glossary:
- Recursive resolver
- The DNS resolver that answers a user's DNS question, often from cache or by querying other name servers.
- TTL
- Time to live, the cache duration attached to a DNS record in seconds.
- PTR
- A reverse-DNS record that maps an IP address back to a hostname.
- DO bit
- A DNSSEC query flag used to request DNSSEC-related data from a resolver path.
- CD bit
- A DNSSEC query flag that asks a validating resolver to return data without enforcing its own validation result for that response.
- AD flag
- A resolver-reported indicator that returned data was considered authenticated by that resolver.
- DKIM selector
- The label before
._domainkeyused to locate a domain's DKIM public key record. - CAA
- A DNS record that publishes which certificate authorities may issue certificates for a domain.
References:
- RFC 1035: Domain Names - Implementation and Specification, RFC Editor, November 1987.
- RFC 8484: DNS Queries over HTTPS (DoH), RFC Editor, October 2018.
- RFC 4035: Protocol Modifications for the DNS Security Extensions, RFC Editor, March 2005.
- RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, RFC Editor, April 2014.
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, RFC Editor, September 2011.
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC), RFC Editor, March 2015.
- RFC 8461: SMTP MTA Strict Transport Security (MTA-STS), RFC Editor, September 2018.
- RFC 8460: SMTP TLS Reporting, RFC Editor, September 2018.
- RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record, RFC Editor, November 2019.
- RFC 9460: Service Binding and Parameter Specification via the DNS, RFC Editor, November 2023.
- How to query DNS records in Windows, Simplified Guide.
- How to add a DNS record in cPanel, Simplified Guide.
- How to add and configure MX records in cPanel, Simplified Guide.