DNS Network Performance Monitoring

DNS latency --the time it takes for a resolver or client to get a response from an authoritative nameserver --is the single most impactful metric for DNS performance. A few extra milliseconds on every DNS lookup compounds across every page load, API call, and email delivery that depends on your domain.

DNScale publishes real-time DNS response time measurements on our network performance page, collected from independent probes operated by RIPE Atlas, a global measurement network maintained by RIPE NCC. This guide explains how the measurements work, what the data means, and how to read the results.

How We Measure

RIPE Atlas

RIPE Atlas is the world's largest internet measurement network. It consists of thousands of hardware and software probes hosted by volunteers and organisations across every continent. Each probe can perform DNS queries, traceroutes, pings, and TLS checks against any target on the internet.

What makes RIPE Atlas valuable for DNS measurement:

• Independent infrastructure --probes are hosted by third parties, not by DNScale, so the measurements are unbiased
• Geographic diversity --probes exist in data centres, office networks, and residential connections worldwide
• ASN diversity --probes span hundreds of autonomous systems, from Tier-1 transit providers to consumer ISPs
• Reproducible --every measurement is logged and publicly accessible with full metadata

Measurement Process

Every hour, DNScale creates one-off DNS measurements through the RIPE Atlas API. Each measurement:

1. Selects specific probes --we pin probes by ID to ensure consistent, comparable results from known-good vantage points
2. Queries our nameservers directly --probes send a DNS query for dnscale.eu (type A) directly to our authoritative nameservers, bypassing local resolvers. This measures the true network latency between the probe and our anycast infrastructure
3. Records the response time --the round-trip time (RTT) in milliseconds from query to answer
4. Filters outliers --results from overloaded or poorly connected probes are excluded to prevent skewing the averages

European probes query ns1.dnscale.eu and ns2.dnscale.eu (our EU nameservers). All other regions query ns1.dnscale.com and ns2.dnscale.com (our Global anycast network). The nameserver alternates between ns1 and ns2 each measurement cycle.

Backbone vs Last Mile

The network performance page separates measurements into two categories, selectable via the toggle at the top:

Backbone (Tier-1 Transit)

What it measures: latency from probes on Tier-1 transit and backbone networks --the carriers that form the core of the internet.

These probes sit on networks like Arelion (Telia), GTT, Cogent, Lumen, PCCW Global, and NTT. They're typically located in major internet exchanges and data centres with direct peering to DNScale's infrastructure.

What it tells you: how well DNScale is peered and interconnected. Low backbone latency means our nameservers are reachable with minimal hops from the internet's core routing infrastructure. This is the best-case latency --the floor that all other paths build upon.

Typical values: 1-10 ms in regions with a nearby point of presence, 10-25 ms in regions routing through an adjacent exchange.

Last Mile (Eyeball ISPs)

What it measures: latency from probes on consumer ISP networks --the "eyeball" networks where actual end-users connect.

These probes sit on networks like Deutsche Telekom, BT, Comcast, AT&T, SingTel, and Telstra. They're residential or business connections that route through the ISP's internal network before reaching an internet exchange where they peer with DNScale.

What it tells you: the DNS latency that real users experience. Last-mile latency includes the ISP's internal routing overhead on top of the backbone latency. This is the metric that matters most for end-user performance.

Typical values: 3-15 ms for ISPs with good peering in the same metro area, 15-30 ms for ISPs routing through a regional exchange, 30+ ms for ISPs with suboptimal routing.

Why Both Matter

A DNS provider can have excellent backbone numbers but poor last-mile performance if they lack peering with major consumer ISPs. Conversely, good peering with ISPs means nothing if the backbone infrastructure is congested.

By showing both, you can evaluate:

• Peering quality --is DNScale well-connected at major internet exchanges?
• User experience --what latency do actual customers see from their ISP?
• Regional coverage --are there regions where last-mile latency is significantly higher than backbone, suggesting a peering gap?

Reading the Results

Region Cards

Each region card shows three metrics calculated from the last 24 hours of measurements:

• Average --the arithmetic mean of all successful measurements. Gives a general sense of latency in the region
• Median (P50) --the 50th percentile. Half of all measurements are faster than this value. Less sensitive to outliers than the average
• P95 --the 95th percentile. 95% of measurements are faster than this value. Represents the worst-case latency that most users experience

A healthy region typically shows P95 within 2-3x of the median. A large gap between P50 and P95 suggests inconsistent routing or a subset of poorly connected probes.

Probe Map

The interactive map shows the physical location of each probe, colour-coded by average response time:

• Green (under 20 ms) --excellent latency, probe is near or well-peered with a DNScale POP
• Yellow (20-50 ms) --good latency, probe is routing through a nearby exchange
• Orange (50-100 ms) --elevated latency, probe may be routing through a distant exchange
• Red (over 100 ms) --high latency, probe is either far from any POP or routing suboptimally

Response Time Trend

The time-series chart shows how latency changes over time, with one line per region. Use the period selector (24h / 7d / 30d) to zoom in or out.

Patterns to look for:

• Flat lines --consistent latency, healthy infrastructure
• Spikes --temporary routing changes, congestion, or probe issues
• Gradual increase --potential capacity issue or routing change worth investigating
• Diurnal patterns --latency that increases during business hours, common on congested eyeball networks

Probe Table

The detailed table shows per-network latency with average and P95 values. Sortable by any column. Use this to identify which specific networks have the best or worst connectivity to DNScale.

Our Infrastructure

DNScale operates an anycast DNS network with points of presence across multiple continents. When a probe sends a DNS query to our nameserver IP, BGP routing directs it to the nearest POP. The response time you see on the network page is the round-trip between the probe and whichever POP served the query.

For more about how anycast routing works and why it delivers low-latency DNS, see our guide on anycast DNS networks. For information about running your own DNS infrastructure across multiple providers, see multi-provider DNS deployment.

Next Steps

• View live network performance --see current DNS response times from probes worldwide
• Anycast DNS Network --understand how anycast routing delivers queries to the nearest POP
• Global DNS Resolution Balancing --learn how geographic traffic distribution works
• DNS TTL Best Practices --optimise caching to reduce DNS lookup frequency
• DNS Propagation Explained --understand how DNS changes reach resolvers globally