Domain Name System (DNS) Configuration Report

Introduction:

Domain Name System records describe where a domain lives, which servers speak for it, and how mail should be handled so people and services find the right destination. Many teams look for a quick DNS health check for domains that highlights what is present, what is missing, and what likely needs attention.

The report here focuses on the essentials that keep a site reachable and messages deliverable, then summarizes the result in plain language so you can act without reading logs. Enter a domain, run the queries, and review a concise table of records alongside simple pass and fail checks that point to common misconfigurations.

Results include lookup times in milliseconds, a snapshot of authoritative data, and email safety indicators such as SPF and DMARC. A typical good outcome shows at least two name servers, working A or AAAA answers, mail hosts that resolve, and a DMARC policy that enforces quarantine or reject.

Configuration drifts over time, so compare runs before and after changes and keep notes on expected values. When something looks off, start with record presence and host resolution, then move to time to live settings and policy text for clarity.

Technical Details:

This report inspects DNS for a single domain and observes record presence, host resolution, time to live values, and resolver validation. It also captures query duration so you can spot slow types and transient answers without packet captures.

The computation extracts answers and TTL from DNS responses, records whether the resolver asserted validation, and parses selected fields used in operational rules. Email safety is summarized by looking for SPF text at the apex and a DMARC record under the dedicated label for policy.

Results are interpreted as simple checks such as required records present, hosts resolve to addresses, reasonable TTL ranges, and protective mail policies in place. Crossing a boundary signals probable risk such as an alias at the apex or a permissive DMARC policy that does not enforce action.

Comparisons are valid for the same domain when run through the same resolver conditions. Values can vary between networks, so treat timing as indicative rather than absolute.

1. Normalize the input domain and verify hostname syntax.
2. Query NS, SOA, A, AAAA, CNAME, MX, TXT, CAA, and DNSKEY.
3. Derive email context: fetch TXT at the apex and under the DMARC label.
4. Parse SOA serial and timers; extract TTL from the first answer per type.
5. For each NS and MX host, attempt A and AAAA resolution.
6. Compute checks: structure, resolution, timer ranges, and policy requirements.
7. Aggregate total query time and format records, checks, and JSON payload.

Units, precision, and rounding. Query duration uses the browser clock and is rounded to the nearest millisecond. TTL values are shown as provided by the first answer for a type. Missing answers appear as an em dash.

Networking and storage behavior. Lookups are executed from the browser against a DNS over HTTPS endpoint at https://cloudflare-dns.com/dns-query using GET with name and type parameters and an Accept: application/dns-json header. The domain you enter is sent to that resolver. No separate application server stores your results.

Performance and complexity. One base query per record type is made sequentially, followed by up to two address checks per NS and MX host. Overall cost is roughly O(R + 2H) for R record types and H hostnames. Timing varies by network distance and resolver caching.

Diagnostics and determinism. Identical inputs can yield different answers when upstream records change or caches expire. Checks are deterministic for a given response set.

Security considerations. Inputs are constrained to hostname syntax. Untrusted text is displayed without script execution. Answers are shown verbatim from the resolver response.

• Assumptions & limitations.
• Only a single domain is evaluated per run.
• Resolver status and validation are taken at face value.
• Only apex TXT is scanned for SPF text.
• DMARC is read from the dedicated label only.
• CAA analysis is presence based, not issuer specific.
• DNSSEC is summarized by DNSKEY presence and the AD flag.
• Timing reflects one resolver path, not global reachability.
• Heads‑up Apex CNAME fails the check even if downstream resolves.
• TTL ranges are heuristic pass bands, not mandates.
• Unicode hostnames must be entered in ASCII form.

• Edge cases & error sources.
• NXDOMAIN or SERVFAIL answers produce empty rows.
• Transient network loss yields fast failures with no data.
• Mixed‑case host input is normalized but still must be valid.
• Trailing dots are rejected by input validation.
• Overlong labels beyond 63 characters fail validation.
• Non‑ASCII characters in hostnames are not accepted.
• Very short TTLs can change between sequential queries.
• Resolver caching may hide upstream changes briefly.
• Large TXT records are shown as a single joined string.
• Multiple answers share the first TTL for that type.

Scientific and standards backing. Concepts align with DNS and DNSSEC behavior defined by core IETF RFCs, DNS over HTTPS conventions, Certification Authority Authorization, the Sender Policy Framework, and DMARC policy notation.

Privacy & compliance. Requests are issued from your browser to the resolver provider; no account data or secrets are involved, and no server‑side storage is performed by this page.

How‑to Guide:

DNS records and basic health checks for a domain are summarized into tables and a timing view.

1. Enter the target domain in the field marked Domain.
2. Start the report and wait for the results to populate.
3. Review Records for answers, TTL, and timing.
4. Open Health to see pass and fail checks.
5. Use the timing view to spot slow record types.
6. Copy or download CSV and JSON for tracking.

Example. Enter example.com, verify two NS entries, confirm A or AAAA exists, and look for a DMARC policy stronger than p=none.

• Repeat measurements after DNS changes to confirm propagation.
• Short TTLs help rollouts; longer TTLs reduce query load.

When the checks read cleanly, you have a strong baseline for stable resolution and mail delivery.

FAQ:

Troubleshooting:

• “Please enter a valid domain” appears → check spelling and remove any trailing dot.
• No records returned → the domain may not exist or the resolver failed.
• NS resolution fails → verify name server hostnames exist and resolve.
• MX present but SPF missing → add an SPF TXT at the apex.
• DMARC present with p=none → raise to quarantine or reject when ready.
• Timing chart empty → populate records first, then open the timing tab.

Advanced Tips:

Prefer consistent TTLs across A and AAAA unless you have a clear reason to diverge.

Keep at least two unique NS hosts on different providers or networks.

Use distinct MX hosts and test that each resolves to multiple addresses.

Tighten DMARC gradually and monitor bounces before moving to reject.

Review SOA timers during large migrations to balance agility and stability.

Re‑run checks from different networks to compare resolver views and caches.