DNS Response Time Test — Per-Record Latency Benchmark

Resolvers fetch different record types at different moments. Browsers need A and AAAA. Mail transfer agents query MX then resolve MX hostnames. Receivers expand SPF and DKIM through TXT lookups that can chain multiple includes. A domain with fast A records but bloated TXT may still feel slow to mail infrastructure even when web performance looks fine.

Timing each QTYPE separately exposes that imbalance. Our probes treat each type as an independent measurement so you can correlate slowest.type with operational pain — for example MX latency during inbound mail bursts or TXT during authentication-heavy periods.

Each probe row shows type, latencyMs, recordCount, and status. High recordCount on TXT often correlates with higher latency when SPF strings sprawl across multiple strings or includes. Zero records with low latency may mean NXDOMAIN or empty NOERROR — still a valid timing signal for negative caching behavior.

averageMs aggregates successful probes only. If one type errors, it is excluded from the average so a single failure does not poison the headline number. slowest highlights the maximum latency probe — your first optimization target when authoritative responses need slimming or TTL tuning.

Web stacks primarily stress A and AAAA. Mail pipelines stress MX first, then A lookups on MX hostnames elsewhere, plus TXT for SPF and DMARC at the envelope domain. A domain can show 20ms A answers and 200ms TXT answers when SPF includes recurse through several DNS lookups on the receiver side — our TXT probe approximates authoritative answer time for the TXT set at your zone apex.

Compare MX and A timings when debugging deferrals. MX should return quickly; slow MX often means oversized zone files or distant authoritative NS. Pair results with SMTP server finder when correlating MX host resolution with SMTP connection delays.

NS and SOA probes reflect how quickly delegation metadata returns. Slow NS at the apex may indicate overloaded authoritative servers or long round trips to your DNS host region. SOA probes return a single structured record — unusually high latency here alongside fast A may point to resolver issues rather than zone bulk.

After NS migrations, rerun timing tests from multiple tools and compare. Persistent elevation across all types suggests resolver or network path problems. Elevation on one type suggests record-specific bloat or complexity.

All probes use Google Public DNS JSON API for consistency with sibling lookup tools. Google anycast may hit a nearby POP with warm cache for popular domains — your first query may be faster than a truly cold authoritative hit. Repeat measurements after TTL expiry for a more conservative picture.

Results describe public resolution, not your corporate forwarder. Internal Windows AD DNS or Pi-hole instances may cache differently. Use this tool for internet-facing authoritative tuning; use local dig from office networks for employee DNS path analysis.

When TXT probes dominate slowest, audit SPF for excessive includes and remove obsolete mechanisms. Flatten SPF carefully — over-flattening breaks when provider IPs change. When MX is slow, verify you are not publishing unnecessary low-priority backup MX records that expand answer size without operational value.

Lowering TTL does not reduce lookup time — it increases query frequency. Optimization targets answer weight, include depth, and authoritative NS placement closer to your user and mail receiver populations via anycast DNS hosts.

Our DNS benchmark tool compares resolver providers against each other for the same domain. DNS response time test drills into record types on a single resolver path. Use benchmark to pick a resolver; use response time to tune your zone contents and record shapes.

Together they separate provider choice from authoritative hygiene — both must be healthy for end-to-end performance.

Run after every DNS change affecting TXT, MX, or NS. Schedule weekly baselines for high-traffic domains and before major campaigns when mail volume will amplify receiver DNS load. Archive JSON snapshots to prove performance did not regress after SPF or DKIM updates.

Incident response for slow site loads should capture a timing snapshot early — before caches warm — alongside traceroute and SSL checks for complete picture.

One probe per type is a snapshot, not p95 or p99 over hours. Transient spikes from DDoS on authoritative NS or regional outages may be missed. Repeat runs or external synthetic monitoring fill that gap.

We do not measure DNS over HTTPS or DNS over TLS separately here — use our DNS-over-HTTPS tester for encrypted resolver paths.

Timing queries public DNS for domains you submit. No DNS records are modified. Use measurements for capacity planning, post-change validation, and support tickets to DNS hosts.

Announcing slow DNS for third-party domains you do not operate should stay within responsible security research norms — focus on domains you administer.