Summary

  • Gaurav Kansal’s report says NIC’s 1.10.10.10 averaged 27.0 milliseconds for DNS responses and 17.3 milliseconds for ping across a 91-day RIPE Atlas comparison. Those are author-reported means, not an independent service audit.
  • The study is useful because its design and caveats are unusually visible: the daily top-ten domains likely produce cache hits, failures and packet loss were not filtered, observation counts differ, and the repository checked here does not expose enough underlying material to reproduce the averages.

The number that looks like a verdict

The most marketable line in Gaurav Kansal’s September 2026 account is easy to compress into a ranking. Over a reported 91-day period, India’s National Informatics Centre (NIC) public DNS resolver, 1.10.10.10, returned the lowest average DNS response time among four resolvers tested from RIPE Atlas probes in India. In the same study, its average ping time was not the lowest. A scorecard can make those two facts sit next to each other; a profile has to ask what the comparison actually observed.

Kansal’s post, “Monitoring 1.10.10.10 with RIPE Atlas Probes”, reports the following means and measurement totals for 13 November 2025 through 11 February 2026:

Resolver Average ping Ping observations Average DNS response DNS observations
NIC 1.10.10.10 17.3 ms 1,038,738 27.0 ms 580,916
Cloudflare 1.1.1.1 14.8 ms 1,047,581 43.2 ms 528,540
Google 8.8.8.8 14.8 ms 1,039,961 32.1 ms 596,800
Quad9 9.9.9.9 55.8 ms 1,050,441 112.1 ms 577,032

The reported DNS mean places NIC ahead of the other three in this particular sample. The ping mean places NIC 2.5 milliseconds behind Cloudflare and Google, but well ahead of Quad9. That is a direct description of the table. It is not yet a conclusion that one resolver is “best,” that it is more reliable, or that its users have a better experience overall. Each stronger claim would need a different definition of success and, in several cases, different evidence.

The contrast is still interesting. A public operator did not merely announce a resolver address or a national project. Kansal published a comparison against familiar public alternatives, supplied the date window and sample totals, linked a repository, and disclosed several limitations. That makes the work more reviewable than an unqualified speed claim. At the same time, the numbers must stay attached to the measurement choices that produced them. A mean without its population, denominator and failure rules can look more conclusive than it is.

The article’s subject is therefore not just a latency table. It is a technical leader’s attempt to make an operating service legible through an external measurement network—and the boundary between an informative comparison and a public-service verdict. On the first side of that boundary, the study offers a real observation. On the second, much remains unmeasured.

What a DNS response time includes

DNS, the Domain Name System, is the machinery that lets a device ask for the network address associated with a name. A public recursive resolver receives that question and returns an answer from its cache or obtains information through the DNS hierarchy before replying. The distinction matters for performance claims. A response time can include the path from a probe to a resolver and the resolver’s work; it is not automatically the time required for a cold lookup that must be resolved from scratch.

Kansal says the daily DNS measurement used the ten domains with the highest hit counts in NIC network traffic that day. He also explicitly notes that most queries were likely to be cache hits. That caveat is not a minor footnote. A popular domain queried repeatedly may already be in a resolver’s cache, which allows a quick answer without repeating every upstream step. A less popular domain, a name with expired cache data, or a domain never requested before can present a different path and a different delay. The report itself distinguishes its test from a worst-case cold-resolution test.

This does not make a cache-hit result useless. People often request popular names, and a resolver’s ability to answer those requests quickly can be relevant to normal operation. The limitation is one of scope. The measurement is closer to a comparison of response behavior for a moving set of popular names than a stress test of every kind of DNS resolution. It cannot be silently widened into “all domains resolve faster” or “the resolver handles every user’s needs better.”

Ping is narrower still. Internet Control Message Protocol (ICMP) ping measures whether a destination responds to a network packet and how long the round trip takes from a vantage point. It is useful as a reachability and path-latency signal. It is not a DNS query. It does not say whether the returned answer is correct, whether a website loads quickly after resolution, whether an application is available, or whether a user can reach a service through the rest of the network. A service can have a slightly slower ping and a faster cached DNS response; the measurements describe distinct parts of an experience.

The report’s comparison is strongest when each metric stays in its lane. The DNS mean is evidence about reported resolver response times under the chosen query workload. The ping mean is evidence about round-trip behavior to four IP addresses from the chosen probes. Neither is a general Internet-quality score. This may sound like a narrow reading, but the value of a comparative study depends on maintaining exactly that kind of boundary.

A moving workload, held in common

The design has an intelligible strength. Rather than send an unrelated set of names to each provider, the post says it used the same ten domains against all four resolvers on a given day. That keeps the day’s query list constant across the comparison. The names changed from day to day as NIC traffic changed, but the resolvers were given the same daily set. As a controlled comparison of those names, that is more informative than four separate tests with unrelated inputs.

The design also anchors the workload in traffic observed by NIC rather than a list chosen solely because it is convenient to test. That gives the measurement a clear operational point of view: it asks how the four resolvers respond to domains prominent in one network’s traffic. It does not establish that the set represents all Indian Internet use, or even all users who might choose NIC’s public resolver. The observations begin at participating RIPE Atlas probes. The query selection begins from NIC’s view of traffic. Those are different frames, and neither is a census of the country.

Using the same daily ten names can answer a useful but bounded question: when the test sends this day’s popular names from these probes to these resolver addresses, what response times does the collector report? It is less suited to questions such as: How long does a first-time lookup take? How does latency vary for uncommon domains? What happens during a resolver outage? How do users on different access networks fare? How does the resolver behave when the query is blocked or malformed? Those questions require added query classes, failure definitions, or user-side measurements.

There is also a design choice hidden inside “the same ten.” The list is drawn from NIC traffic and may describe names already common in the NIC environment. That may be a sensible load for evaluating the NIC service, but it can create a warmer cache at the NIC resolver than at an external alternative, depending on the source of each resolver’s traffic and cache state. The report’s author acknowledges likely cache hits but does not publish enough detail in the linked material to reconstruct each resolver’s cache state.

The point is not that the comparison is unfair; it is that identical names do not make every resolver’s surrounding conditions identical.

Resolvers also differ in network topology and placement. A request to each address follows a route from the probe, and the responding infrastructure may be located or distributed differently. The measured round trip therefore combines the resolver’s service with the path between the probe and the responder. That combination is relevant to users at those probe locations. It is not a laboratory isolation of software performance alone, and it is not a neutral ranking independent of geography.

These distinctions help read the result charitably without overstating it. The study gives the same daily names to four providers from the same measurement pool. This is a meaningful control. Its population remains the available India-located probes, the daily workload remains ten NIC-traffic names, and the result remains a response-time summary rather than a full test of correctness or service quality.

The sample is large; the denominator still matters

The number of observations is striking: more than one million ping measurements per resolver and more than half a million DNS measurements per resolver during the study window. Larger samples can reduce the influence of one-off noise, especially when measurements are spread across time and vantage points. But a large count does not by itself disclose what each row contains, which observations were eligible for an average, or whether one resolver’s missing or failed observations were handled in the same way as another’s.

Kansal writes that the retrieval scripts did not filter out packet loss or failed queries. That statement is important because it rejects the idea that the author simply discarded inconvenient outcomes. It also raises a technical question that should remain open until the data definitions are available: how were failures represented in the reported averages? A failed query may not have a normal response-time value. Packet loss can be recorded as absence, timeout, or another result, depending on the measurement and collector.

“Unfiltered” tells readers a deliberate filter was not applied; it does not, on its own, show how every non-response entered the denominator or the arithmetic mean.

The total counts in the post are not equal across resolvers. For example, the DNS totals range from 528,540 Cloudflare measurements to 596,800 Google measurements. Ping totals also vary, from 1,038,738 NIC measurements to 1,050,441 Quad9 measurements. Counts need not be identical for a comparison to be useful: probes can be unavailable, jobs can return different numbers of records, and data collection can have operational constraints. But the differences make denominator rules central.

Readers need to know whether a count means scheduled queries, returned result records, successful responses, or another unit—and what the average does with each category.

One sample file in the linked repository illustrates the issue without answering it. The daily DNS count file for 13 November 2025 lists counts for the four IPv4 resolver addresses, and the values differ. The public file describes counts, not individual latency records. That is a reason to request clearer metadata, not a reason to infer from one day that a resolver failed, that the study was biased, or that the reported means are wrong. One example cannot diagnose the process that produced it.

The distinction between number of observations and representativeness is also easy to lose. Hundreds of thousands of results can make a measurement precise for the sampled probes and query regime while leaving uncertainty about how the sample maps to networks outside it. A large number of packets from a limited set of vantage points is not equivalent to a carefully weighted national sample. To support a broader claim, a report would need to explain probe selection, geography, access networks, changes in active probes and how those features influence the summary.

Means are especially compact. They do not show how responses are distributed across probes or days. A 27-millisecond mean could conceal a low median and a long tail, consistent performance in most places and a poor result in a smaller region, or a sharp change on a few days. The table does not include percentiles, daily distributions, response codes or a probe-by-probe view. Without those, readers cannot tell whether the average describes a typical observation or whether a minority of slow or missing results has material effect.

Again, this is not a refutation. It is the set of questions that separates a headline average from a reviewable method. The post provides the time window, main schedule, probe range, comparison addresses, totals and explicit no-filtering caveat. A stronger public package would map those declarations to raw records and aggregation steps so another analyst could see how the denominator was formed.

RIPE Atlas adds vantage points, not an outside auditor

RIPE Atlas is useful precisely because it moves measurements away from a single test server. The RIPE NCC’s description explains a community network of probes hosted by volunteers, organizations and network operators. A distributed set of probes can show how paths vary from different networks. RIPE Atlas provides measurement infrastructure; the person who designs a test still chooses its targets, schedule, probe filters and analysis.

Kansal says his study generally had between 130 and 145 active probes located in India. That is a substantial distributed vantage pool compared with a single data-center test. But probes are not randomly assigned survey respondents. Their locations and connectivity depend on who hosts them and which probes are available for a given measurement. A probe represents a measurement point on a network connection, not a person or a region in proportion to population. The post’s phrase “real network conditions” captures an advantage over a lone server but should not be stretched into a claim that the sample represents every Indian user.

There are at least three different kinds of independence here. The probes are hosted across different networks, which can make paths independent of the operator’s own test environment. RIPE Atlas is operated by the RIPE NCC, a separate organization, which supplies the measurement platform. But the study is authored by Kansal, whom APNIC describes as the NIC official who spearheads Sarvagya. A third-party platform does not transform an operator-led study into an independent audit. The author selected the workload and interpretation, and the public report is his account.

That distinction is not a conflict accusation. Operators often have the best access to service questions and can publish useful first-party measurement. In some cases, an operator’s transparency is more valuable than a less informed outside commentator’s confidence. The correct description is simply precise: this is a study by a technical lead about a service he leads, using an external community measurement network. It is neither an anonymous marketing claim nor an independent evaluation by RIPE NCC.

The official RIPE Atlas user-defined measurement documentation also shows why exact definitions matter. Measurement jobs have configuration, selected probes, schedules and outcomes. Their IDs and result records give a reader a way to inspect the test itself. The blog explains its high-level design, while the linked repository provides daily counts and graphs. In the checked public tree, however, no measurement IDs or collector scripts were apparent. A reader can understand the described approach without being able to reconstruct every sample from the public package.

An external measurement network makes a service easier to observe. It does not automatically make the service trustworthy, the test reproducible, or the observed population representative. Those are separate propositions, and each needs separate support.

What the repository lets a reader repeat

The GitHub repository linked by Kansal calls itself a collection of daily network-measurement logs for four public resolvers. Its README describes DNS and ping subdirectories, daily files, counts and generated graphs. It is a useful trace of activity over time. A reader can see that measurements were being collected on particular days and compare the counts the author chose to publish.

There is a difference between an audit trail and reproducible evidence. The checked repository tree contained daily count files and HTML graphs, and its README describes collector scripts, but the public tree checked on 29 September 2026 did not expose the scripts, the RIPE Atlas measurement IDs, or the individual latency results used to calculate the 91-day means. The sample count file contains resolver counts, not a set of timestamped response-time values. This finding is bounded to the public repository contents examined here. It does not establish that Kansal has no other data or that the reported averages are inaccurate.

It does mean the repository alone was not enough to recompute them.

That gap matters because the post’s central contribution is quantitative. A reader should be able to move from statement to evidence: identify a measurement, inspect the probes and DNS parameters, retrieve results, understand failures and re-run the aggregation. If the repository only supplies counts, it can confirm that the author reports many observations but cannot let another analyst verify how latency was calculated. Counts answer “how many records or events were counted?” They do not answer “what were the individual response times?”

The post does link two repositories divided by period: 1.10.10.10-measurement for February to October 2025 and 1.10.10.10-tests for November 2025 to February 2026. The newer repository’s README says that small Bash scripts retrieve results from RIPE Atlas, count or aggregate them, and draw graphs. The existence of a described process is helpful. Making the scripts and exact measurement identifiers public would make it possible to check whether the process matches the prose and to reproduce the stated result.

Reproducibility is not only a matter for academics. A network operator deciding whether to point devices at a resolver may care about latency in a particular region, the stability of results over time, and the treatment of failed queries. A government department may need evidence of uptime, support arrangements and security controls. An end user may want to know whether queries are logged. An engineer auditing a DNS configuration may need the resolver’s precise behavior for DNSSEC or blocked domains. One performance table cannot serve all these audiences, but a transparent measurement package lets each begin from a shared factual base.

The goal is not to demand that every public-service project publish an enterprise-grade observability stack. It is to distinguish what is public. A repository of daily counts can be valuable as an activity log. It should not be described as a raw latency dataset if it does not expose the underlying responses. A report can state that its averages are author-calculated and invite review. The claim can then be strong enough for the evidence actually shown.

An official configuration address is not an adoption survey

NIC’s service exists in a public-sector setting, not merely as another consumer alternative. A Government of India cyber-security guide tells government employees to configure NIC DNS addresses, including 1.10.10.10 and the IPv6 address 2409::1. A July 2025 NIC Informatics article likewise describes configuring NIC DNS as a hardening parameter in government networks. These documents establish that the addresses appear in official technical guidance.

That is meaningful evidence of intended use. It places the resolver within a government-administration context and shows that its address is not known only through personal promotion. But instructions are not implementation. A directive to configure a resolver does not tell us how many computers actually use it, whether every network can reach it, whether exceptions exist, or what outcomes users experience. A hardening guide is not a national adoption audit. It is a document that recommends a setting.

The distinction matters because “public DNS” can refer to several things: an address reachable by external users, a service offered by a public institution, a recommendation for government endpoints, or a service widely used across a country. These meanings overlap but are not interchangeable. The cited guidance supports the second and third propositions; the measurement supports a narrow performance comparison at selected probe points. Neither alone establishes the fourth.

Kansal’s personal portfolio describes Sarvagya as handling more than five billion queries a day, keeping traffic and generated data inside India, and filtering malicious domains through a “Cyber Kavach” pipeline. Those are claims on the project lead’s own site. They may be important dimensions of the service, but the RIPE Atlas study does not measure query volume, locality, filtering precision, false positives or security outcomes. A speed comparison cannot verify them. In an evidence-led profile, the right move is neither to repeat them as fact nor to dismiss them; it is to attribute them and state what evidence would test them.

Query volume, for example, would need a clearly defined period and counting method. “Queries” could include retries, cached answers, internal traffic or different network vantage points; public traffic totals can be shaped by local network design. A locality claim would require a definition of which data, at which stage of the resolution path, is kept within which boundary. Threat filtering would need a description of the source lists, the intervention point, how false positives are handled, and an external way to evaluate both blocked malicious names and incorrectly blocked benign names. None of these are answered by mean response time.

For public administrators, the deeper question is not whether a national address sounds independent. It is whether service properties are documented in ways that match operational obligations. A resolver might be fast for the selected workload yet still require stronger evidence about availability, maintenance, incident response and privacy. Conversely, the absence of those measurements in one blog post does not prove that those properties are absent from the service. It means readers should not infer them from a latency chart.

The date window has a shelf life

The measured window ended on 11 February 2026. Kansal published the report on 17 September, more than seven months later. A 91-day period is long enough to show recurring observations rather than a one-hour screenshot, but the calendar gap changes how it can be used. The study tells a reader what its collector reported over that historic interval. It does not establish present-day performance in late September.

Networks change. Routes move, upstream arrangements change, resolver capacity is adjusted, and the set of probes available from a given country changes. A public service can improve, degrade or remain broadly stable. Without a current window, the old sample cannot distinguish among those possibilities. Its result remains useful as a documented baseline, provided it is labelled with its dates.

That timing also clarifies why a 91-day mean is not the same as continuous assurance. The frequency in the report—ping four times a day and DNS once a day—creates repeated samples, but not a minute-by-minute service monitor. A resolver might have a short outage between measurements, or a regional path might fail while the selected probes are inactive. Conversely, a few short delays may have little effect on the long-period mean. Neither fact invalidates the study; both define the kind of visibility it offers.

The freshness question has a practical trigger. If the service is recommended to large numbers of government endpoints, officials and network operators should be able to tell whether the published performance profile is current. A dated report can be followed by repeated windows, live service indicators, a status history and clear incident communication. Those instruments serve a different purpose from a retrospective comparative experiment.

There is a balance to strike. Nobody should dismiss the study just because it is historical; almost every technical measurement becomes a snapshot as soon as it ends. But a public profile should not use the table as a present tense guarantee. The careful formulation is “during the period Kansal measured, the published mean was…” That phrasing preserves the evidence and prevents an old statistic from quietly becoming an uptime promise.

The work behind the public comparison

APNIC’s 10 August 2026 author profile describes Kansal as Joint Director (IT) at the National Informatics Centre and says he spearheads “Sarvagya — Bharat Public DNS (1.10.10.10).” The same article is a guest post in which he writes about APNIC’s Special Interest Groups and a review of their guidelines. His own portfolio calls him the technical lead for Bharat Public DNS. Those sources support a role-based account of the subject, while the measurement report records observable work tied to that role.

Kansal’s profile also lists earlier APNIC community work, including service on the NRO Number Council and as NIR SIG Co-Chair. The roles place him in two technical-policy environments: the government systems built at NIC and the regional discussions in APNIC. The article does not need to turn that into a claim that he represents every Indian network, operator or user. A committee seat, a technical leadership role and authorship of a measurement report describe participation and work. They do not, by themselves, authorize a person to speak for a whole public.

What can be observed in the DNS study is more specific. A test plan selected recurring probes and metrics. A list of four resolver addresses made comparison possible. The author presented means and totals, linked a repository and disclosed likely cache hits and lack of filtering. These are the visible elements of an effort to evaluate one service. They are enough to ask how the service performs within that test; they are not enough to infer what Kansal intended or what every user experiences.

The most revealing choice may be the inclusion of the caveats alongside the favorable DNS average. The post says NIC led on reported DNS response time, but it also says top-ten queries were likely cached and that failures were not excluded. That combination helps readers separate a result from an advertisement. The caveats do not solve every method question, but their presence gives reviewers a starting point and makes the claim more bounded.

This is one way to describe technical leadership without relying on biography as proof. A title says where a person sits. A measurement says what they chose to make observable. The profile becomes meaningful when the observed choices—query selection, recurrence, comparison set, published data and caveats—are connected to the service they operate. A role is context; the work and its consequences are the evidence.

A scorecard can be useful without being complete

The word “scorecard” carries an implicit promise that a reader can compare options. Kansal’s work gives a first version of such a comparison: four resolver addresses, repeated probes, DNS and ping metrics, means, totals and a fixed 91-day period. There is real informational value in that structure. It permits a reader to see that “fast” is not one number: NIC’s reported DNS result leads, while Cloudflare and Google have lower ping means.

But a scorecard becomes a verdict only when readers know what is scored and what is not. For a public DNS service, response time is one dimension. Reliability requires an availability definition and a time series of failures. Correctness requires a way to verify answers against authoritative data. Security requires evidence about behavior such as DNSSEC validation, abuse response and any filtering functions claimed. Privacy requires documentation about logs, retention, access and onward sharing. Adoption requires traffic or endpoint data with a denominator. Each topic has a different control surface and potential harm.

This distinction is especially important for a state-supported service. A government institution may have reasons to operate infrastructure locally or to provide an alternative to commercial resolvers. Those reasons are matters of policy and operations, not proof that the service is safer or more sovereign in every sense. Local ownership, physical server location, query path, administrative access and legal jurisdiction are related but separate. A local IP address does not answer all of them. A well-measured response time answers none of them directly.

The same caution applies in the other direction. The comparison’s limits do not imply that the service has weak security or poor privacy. They indicate that this study is not the evidence needed to judge those properties. Keeping that distinction symmetrical is essential. Otherwise, the profile would merely replace an unsupported positive claim with an unsupported negative one.

A mature public evidence package could keep these strands separate while making them accessible together. One page might document the service’s operator, supported resolver addresses, network reachability and service-status history. Another could publish repeatable performance studies with measurement IDs and per-result data. A security statement could describe DNSSEC behavior, filtering scope and incident processes. A privacy statement could explain query logging and retention. An adoption report could state how usage is counted and which populations are included.

The package would let each reader evaluate the property relevant to their decision.

For the performance comparison specifically, a repeatable release could publish the exact RIPE Atlas measurement identifiers, probe-selection criteria and country/network distribution; the daily domain list or a privacy-safe description of how it was selected; query type and resolver settings; raw result records; treatment of retries, timeouts and packet loss; collector code; and the formulas used for means and percentiles. A new window could then be compared with the old one without pretending the same sample is permanently current.

The answer is not to reject averages. Averages are efficient summaries. The answer is to show enough context that the summary can be challenged, reproduced and used only for the question it answers. That would make a performance table more useful to network operators and public administrators than either an unexplained rank or a broad claim of national success.

The measured user is not every user

The post’s probe count can sound like a proxy for national reach. It is better understood as a distributed sample of measurement points. RIPE Atlas probes are hosted on networks around the world, and user-defined measurements run from whichever probes are selected and available. The RIPE NCC documentation describes how probes and jobs are managed; it does not say that a set of probes automatically forms a representative public-opinion or population sample.

This difference becomes practical when a result is used to justify configuration. A central agency may issue a guide, a network administrator may deploy the setting to a subset of systems, an individual may choose a public resolver manually, and a device may continue using an ISP or operating-system default. These groups experience different paths, have different options and bear different consequences when DNS fails. The fact that a resolver is public does not reveal who uses it, who can opt out, or who is exposed to its logging and filtering policies.

The comparison does not try to answer those distribution questions. That is acceptable for a latency study; no one test must answer everything. But if the service is described as national infrastructure, the public case should add evidence on adoption and governance rather than stretching a technical sample. How many endpoints are configured? Which agencies and regions are included? Are devices able to fail over? Who can authorize changes to blocking behavior? What service commitments apply when the resolver is unreachable? Those questions address the relationship between a central service and the people or organizations that depend on it.

There is also a subtle distinction between being technically present and having a mandate. Kansal’s role and APNIC participation establish that he works in relevant institutions. The government guide establishes that the resolver is recommended for particular settings. The Atlas study establishes that measurements were run from a set of probes. None of those records alone says that a broader population consented to a policy, endorsed the operator, or authorized a representative. That is not a criticism of Kansal; it is a limit on what can be inferred from participation and technical evidence.

The same logic makes the scorecard more useful. A transparent measurement can inform public choices without claiming to settle them. It can help an administrator see that the measured resolver’s reported latency compares favorably for a particular workload. The administrator still needs to know the failure handling, privacy posture, security properties, configuration control and recovery plan. An individual user still needs to understand what the service collects or filters. A policy-maker still needs to know how the service is governed and who bears its risks.

For the author, this is a powerful form of technical contribution: make the observable surface clear enough that other actors can make their own decision. The report can be an input to evaluation without becoming a substitute for user experience, service commitments or public accountability.

The next comparison should be easier to audit

Kansal’s study points toward an agenda that is concrete rather than rhetorical. The first improvement is identification: link each daily schedule to its RIPE Atlas measurement ID, and state the exact start and stop times. Then a reader can see which probes participated, how often they ran, when results were missing and what configuration each test used. If some details should not be published, the report can explain the restriction and provide a privacy-safe summary.

The second is a complete outcome vocabulary. For every scheduled probe and query, record whether the job ran, whether a DNS response arrived, whether it timed out, whether the answer was usable, and how retries were counted. For ping, distinguish a missing ICMP reply from a measurement that was never executed. State which categories enter the mean and which are shown separately. Report the denominator alongside each statistic. This would make the existing “unfiltered” principle more informative by letting readers understand exactly what was left in.

The third is a distributional view. Keep means for a compact summary, but add medians and high percentiles; show day-by-day results and the spread across locations or networks where safe; mark periods with low probe availability. A resolver that performs well for the median but poorly for a subset of routes raises a different operational question than one that is consistently close to the same mean. A percentile chart cannot replace raw data, but it helps reveal the pattern hidden by one number.

The fourth is a set of separate service tests. A cold-lookup workload could complement popular cached names. A controlled known-answer set could address correctness. DNSSEC behavior could be evaluated with signed and unsigned test names. Availability could be tracked at shorter intervals. Security filtering, privacy/logging and traffic locality would each need their own documented method and governance description. None should be inferred from a fast response time.

Finally, the reporting window should recur. A 91-day historical comparison gives context; monthly or quarterly updates can show whether the result is stable and whether service changes altered it. A public status record can describe incidents and maintenance. The old study then becomes a baseline rather than a permanent statement of current performance.

These suggestions do not demand a particular resolver architecture or a choice between government and commercial providers. They describe how evidence should travel with a claim. A reader should be able to see which property was tested, who ran the test, how the sample was formed, how failures were counted, and what the result cannot establish. That is a practical standard for any public resolver, including the largest commercial services.

A bounded contribution

The strongest version of the story is neither “NIC beats the global resolvers” nor “the study is too limited to matter.” The source record supports a narrower conclusion. Kansal published a 91-day comparison from Indian RIPE Atlas probes; his post reports a 27.0-millisecond DNS mean for NIC against higher reported means for Google, Cloudflare and Quad9, while NIC’s reported ping mean is slightly slower than Google and Cloudflare. He explained the daily workload, probe range and lack of filtering, and acknowledged that the domain set likely favored cached responses.

Those details make the work useful. They also locate its limits. The results are self-reported; the sample is not demonstrated to represent all Indian networks; observation totals differ; the public repository checked here contains counts and graphs rather than the complete materials needed to recalculate the averages; and the measurements are historical. The study does not test availability, correctness, security, privacy, filtering quality or adoption.

The human significance is in that boundary. As NIC Joint Director (IT) and the official APNIC describes as spearheading Sarvagya, Kansal is attached to an operational public resolver. His published study makes one part of that service visible through a comparative measurement. A reader can appreciate that contribution without treating him as the voice of all users or the chart as a national-service audit. The scorecard begins an accountability conversation; its next version can make that conversation easier to verify.

Sources