1.10.10.10 is NIC's public DNS resolver. We wanted to know how it actually performs for users in India — not in theory, but from real, independently hosted network connections spread across the country. So we built a small measurement setup using RIPE Atlas probes based in India, and ran it over a 91-day window from 13 November 2025 to 11 February 2026.
Every day, these probes send Ping and DNS queries to 1.10.10.10. For comparison, they send the same queries to three other well-known public resolvers: 1.1.1.1 (Cloudflare), 8.8.8.8 (Google), and 9.9.9.9 (Quad9). We pull the results, summarise them, and push them to a public GitHub repository.
1.10.10.10 holds its own on ping latency and clearly leads on DNS response time — the metric that most directly reflects the end-user experience of resolving a domain name.
What is RIPE Atlas
RIPE Atlas is a global Internet measurement network run by the RIPE NCC — the regional Internet registry for Europe, the Middle East, and parts of Central Asia. It's built out of thousands of small measurement devices called probes, hosted by volunteers, ISPs, universities, and companies all over the world.
Anyone can use the network to run measurements like Ping, Traceroute, and DNS query checks from any of these vantage points. That's far more useful than testing from a single server sitting in one data centre.
What are probes
A RIPE Atlas probe is a small physical (or in some cases software/virtual) device that sits on someone's network connection. It continuously runs measurements assigned to it by the RIPE Atlas platform, then reports the results back. Hosts get "credits" for running a probe, which they can spend to run their own measurements from the rest of the network — it's a mutual, credit-based system rather than a paid service.
For our purposes, what matters is this: each probe represents a real, independently hosted network connection somewhere in India — a mix of ISPs, regions, and network conditions. When we query 1.10.10.10 from over a hundred of these probes instead of from one machine, the results reflect real-world variation.
How we're using the probes
We used a pool of active RIPE Atlas probes hosted across different locations in India — typically between 130 and 145 probes active at any given time — to run two kinds of recurring measurements against 1.10.10.10, alongside the same measurements against 1.1.1.1, 8.8.8.8, and 9.9.9.9 for context:
- 4×/day — Ping (ICMP) measurements, covering reachability and round-trip latency
- 1×/day — DNS query measurements, covering response time for the day's top 10 domains
- 130–145 active RIPE Atlas probes across India
Which domains we query
The DNS measurements aren't run against random or fixed test domains. Every day, we pull the top 10 domains by hit count from our NIC network traffic — the domains real users on our network are querying the most that day. Those same 10 domains are then used as the query set for the DNS measurements against all four resolvers: 1.10.10.10, 1.1.1.1, 8.8.8.8, and 9.9.9.9.
Since the top-10 list is refreshed daily rather than fixed once, the query set drifts with real usage patterns. But on any given day, all four resolvers are tested against the exact same set of domains, so the DNS response-time comparison stays fair.
A note on the DNS numbers: because the query set is the day's top 10 domains by traffic, most of these queries are likely cache hits at the resolver, not cold lookups. That's realistic — it reflects what real users experience — but it means these numbers measure cached-response speed more than worst-case resolution time.
How we calculate the numbers
A set of Bash scripts pulls the results back from the RIPE Atlas API. The script greps the relevant fields out of the raw output and runs the averages directly on that — there's no filtering or exclusion of packet loss or failed queries. The reported averages below reflect exactly what the probes returned, unfiltered. The scripts then generate a self-contained HTML bar-graph for a quick visual read, and push both the raw data and the graph to our GitHub repository.
Repository
- github.com/kansal15/1.10.10.10-measurement — February to October 2025
- github.com/kansal15/1.10.10.10-tests — November 2025 to February 2026
What the data shows
Here we're using data from 13 November 2025 to 11 February 2026 (91 days), and we've used that same 91-day window for a like-for-like comparison across ping and DNS query response times.
Ping latency — 13 Nov 2025 to 11 Feb 2026 (91 days)
| Resolver | Avg. ping (ms) | Total measurements |
|---|---|---|
| 1.10.10.10 (NIC) | 17.3 | 1,038,738 |
| 1.1.1.1 (Cloudflare) | 14.8 | 1,047,581 |
| 8.8.8.8 (Google) | 14.8 | 1,039,961 |
| 9.9.9.9 (Quad9) | 55.8 | 1,050,441 |
Avg. ping response — Indian probes
Avg. ping response from Indian probes, 13 Nov 2025 – 11 Feb 2026
DNS response time — 13 Nov 2025 to 11 Feb 2026 (91 days)
| Resolver | Avg. DNS response (ms) | Total measurements |
|---|---|---|
| 1.10.10.10 (NIC) | 27.0 | 580,916 |
| 8.8.8.8 (Google) | 32.1 | 596,800 |
| 1.1.1.1 (Cloudflare) | 43.2 | 528,540 |
| 9.9.9.9 (Quad9) | 112.1 | 577,032 |
Avg. DNS query time — Indian probes
Avg. DNS query time from Indian probes, 13 Nov 2025 – 11 Feb 2026
Summary
Overall, 1.10.10.10's performance across this measurement window is commendable. It holds its own on ping latency and clearly leads on DNS response time — the metric that most directly reflects the end-user experience of resolving a domain name.
On ping, 1.10.10.10 (17.3 ms) trails 1.1.1.1 and 8.8.8.8 (14.8 ms each) by a small margin, while comfortably beating 9.9.9.9 (55.8 ms). The most likely reason for this gap is infrastructure footprint: Cloudflare and Google run large global anycast networks with many points of presence inside India, so more probes land close to one of their nodes. 1.10.10.10 runs from fewer physical locations, so some probes travel a bit further to reach it. This is a scale difference, not a reliability problem.
On DNS response time, 1.10.10.10 performs significantly better than the other resolvers, averaging 27.0 ms against 32.1 ms (8.8.8.8), 43.2 ms (1.1.1.1), and 112.1 ms (9.9.9.9). Taken together, the data indicates that 1.10.10.10 is a strong, reliable resolver for users in India.
Why this holds up
- Large, unfiltered sample: 1M+ ping and 500K+ DNS measurements per resolver over 91 days
- 130–145 active probes across a range of ISPs and regions in India
- Same 10 domains queried against all four resolvers on any given day — a fair comparison
- No cherry-picking: averages are computed directly from raw probe output, packet loss included
These conclusions are based on a large sample size — over 1,000,000 ping measurements and over 500,000 DNS measurements per resolver across the 91-day window — gathered from probes spread across a range of ISPs and regions in India. That gives reasonable confidence that the results reflect real, representative conditions rather than a one-off snapshot.