要約
- Gaurav Kansalの報告によると、91日間のRIPE Atlas比較でNICの公開リゾルバー
1.10.10.10は、DNS応答の平均が27.0ミリ秒、pingの平均が17.3ミリ秒だった。これは著者が公表した値であり、独立したサービス監査の結果ではない。 - この調査は、限界を含めて読むと有用だ。人気ドメインはキャッシュに残っていた可能性が高く、失敗やパケット損失は除外されていない。観測件数はサービスごとに異なり、確認できた公開ファイルだけでは平均値を再計算できない。
数字をランキングに変える前に
2026年9月、Gaurav Kansalは「Monitoring 1.10.10.10 with RIPE Atlas Probes」を公開した。インドのNational Informatics Centre(NIC)が提供する公開DNSアドレス1.10.10.10を、Cloudflare、Google、Quad9と比較した記事だ。対象期間は2025年11月13日から2026年2月11日まで。次の値は記事に掲載された平均と件数であり、個々の測定記録から独立に再集計したものではない。
| リゾルバー | ping平均 | ping観測数 | DNS応答平均 | DNS観測数 |
|---|---|---|---|---|
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 |
報告されたDNS平均では、この条件下でNICの値が3社より低い。一方、pingではCloudflareとGoogleより2.5ミリ秒遅い。これは矛盾ではない。pingはICMPパケットの往復時間を測り、DNSの試験は名前解決の応答を測る。二つは異なる経路と処理を見ている。どちらも一般的な「最良のリゾルバー」を決める指標ではない。可用性、回答の正しさ、プライバシー、安全性、障害からの復旧といった性質は、低い遅延からは導けない。
この研究の価値は、公共サービスの運用面を比較可能にし、期間、件数、方法上の注意点を示したところにある。手法を伴う比較は、根拠のない優位性の宣言より検討しやすい。ただし、表が明快でも、測った範囲は広がらない。結果はプローブの場所、問い合わせた名前、キャッシュの状態、失敗を記録する規則に左右される。
毎日の10ドメインが問いを決める
記事によれば、DNS測定では毎日、NICのトラフィックでアクセス数が最も多い10ドメインを選び、その日の同じ10件を4つのリゾルバーに問い合わせた。名前の一覧は日ごとに変わる。各サービスに同じ日の同じ入力を与える設計は、別々の名前を偶然比較することを避ける点で有益だ。
同時に、それはNICの環境で人気の高い名前を測る設計でもある。Kansal自身、ほとんどがキャッシュにヒットした可能性を指摘している。リゾルバーに回答が保存されていれば、DNS階層をたどり直さずに応答できる。だからといって測定が無意味になるわけではない。よく使われる名前への応答は日常運用の一部だ。制約は結論の範囲にある。これは人気があり、繰り返し問い合わせられる可能性のある名前の比較に近く、初回の冷たい問い合わせ、まれな名前、任意のドメインすべての試験ではない。
「よく使われる」の基準がNICのトラフィックであることも重要だ。NICの運用負荷を見る目的には適切かもしれないが、インド全域のネットワークや公開DNS利用者を代表するとは限らない。RIPE Atlasのプローブは測定の起点であり、NICのトラフィックは名前の選択元だ。二つの母集団を組み合わせても、全国の利用実態を示す標本にはならない。
pingが答える問いはさらに限定的だ。測定地点から宛先へのICMPパケットが応答したか、その往復にどれだけ時間がかかったかを示す。DNSの回答が正しいか、ウェブページが速く表示されるか、アプリケーションが使えるかは測っていない。pingとDNSを単一の総合点にまとめると、原因の違いを説明するどころか覆い隠してしまう。
件数の多さと分母の意味は別の問題
報告された件数は大きい。各サービスでpingは100万件超、DNSは50万件超の観測がある。多くの測定値は、実際に収集された対象について平均を安定させ得る。しかし、どの結果が平均に入ったか、何が欠けたか、失敗がどう扱われたかまでは総数から分からない。DNS件数はCloudflareの528,540からGoogleの596,800まで開き、ping件数も同一ではない。
Kansalは、取得スクリプトがパケット損失や失敗した問い合わせを除外しなかったと記している。都合の悪い結果を単純に捨てた平均ではない、という点で重要な説明だ。ただ、「除外しなかった」だけでは、正常な応答時間のないタイムアウトを平均にどう反映したのか、再試行があったのか、観測数が予定された測定数・返却レコード数・成功応答数のどれを指すのかは分からない。平均の分母を理解するには、この定義が必要になる。
公開リポジトリの一つのファイルは、この論点を示すが答えは与えない。2025年11月13日のDNS件数ファイルはアドレスごとの数を示すが、個々の遅延値ではない。同日の件数は異なる。1日分だけで障害や偏り、平均の誤りを断定することはできない。数え方と元データが必要だと分かるにとどまる。
公開リポジトリ1.10.10.10-testsとREADMEには日別の件数とグラフが説明されている。今回確認した公開ツリーでは、測定ID、全遅延記録、収集スクリプトと明確に識別できるファイルを確認できず、公開物だけから91日間の平均を再現するには不足していた。これは確認したツリーに限る観察であり、別の場所に資料が存在しないという主張ではない。
平均値は分布も隠す。27ミリ秒が典型的な応答に近いのか、少数の遅い時間帯に引き上げられたのか、地域や経路ごとに差があるのかは分からない。中央値、高いパーセンタイル、日別推移、プローブごとの差があれば、別の特徴が見える。大量のパケットは、観測された地点の挙動を詳しくしても、未観測のネットワークを代表する保証にはならない。
RIPE Atlasは測定点を広げるが、監査の独立性は与えない
RIPE Atlasの仕組みと利用者定義測定の説明によれば、異なるネットワークに置かれたプローブから測定を実行できる。地理・ネットワーク上の視点が増えるのは利点だ。しかし、RIPE Atlasがここでドメイン選択や集計、Kansalの解釈を決めたわけではない。第三者がホストするプローブを使っても、運用者が執筆する研究が自動的に独立監査になることはない。RIPE NCCが結果を承認したという記録もない。
記事が示すのは、通常130〜145台のインド所在プローブだ。インドの通信事業者、アクセス網、利用者を確率的に抽出し、人口構成に合わせて重み付けした標本とは説明されていない。プローブがある場所には有益な観測でも、結果をどこまで一般化できるかは別問題だ。全国平均を名乗るには、対象集団、選び方、重み付けの根拠が必要になる。
役職の情報と、利用者を代表する権限を分ける
APNICの著者紹介はKansalをNICのJoint Director (IT)とし、Sarvagya/Bharat Public DNSを率いる人物として紹介している。APNICの記事は署名付き寄稿で、2026年8月の掲載説明には見解は著者個人のものとある。こうした記録は仕事の組織的な位置を示すが、インドの全インターネット利用者を代表することを意味しない。
インド政府のCGAサイバーセキュリティ案内とNIC Informaticsの2025年7月記事は、設定・強化の文脈で1.10.10.10および2409::1を挙げる。確認できるのは文書化された推奨であり、何台が設定したか、全国で使われているか、利用者にどのような結果があったかではない。
Kansal本人のウェブサイトには、規模、データの国内処理、脅威ドメインのフィルタリングについての記述もある。これらは本人のプロフィールに帰属させるべきで、この遅延調査で検証された事実として扱えない。応答が速いことからログ保存方針、フィルターの精度、安全性、可用性は分からない。それぞれに別の証拠が必要だ。
RFC 1034は名前解決の基礎を定める。応答時間は公共インフラサービスの一面に過ぎない。多数の端末を同じ設定にする場合、障害時の切替、変更権限、問い合わせ先、プライバシー、他サービスに移る手段も重要になる。
次の比較を再計算できる形にする
次回は各測定にRIPE AtlasのIDを付け、プローブの選定・分布とその変化、問い合わせの種類、リゾルバー設定を公開すると検証しやすい。タイムアウト、再試行、パケット損失、失敗応答の数え方も定義する必要がある。プライバシーを損なわない範囲で個々の結果と集計コードを出せば、別の分析者が平均を再計算できる。
平均は要約として残しつつ、中央値、高いパーセンタイル、日別推移、応答なしの割合を併記できる。人気ドメインのキャッシュ試験と冷たい初回問い合わせ、既知の正答を使う試験は分けたい。可用性、回答の正しさ、DNSSEC、プライバシー、フィルタリング、安全対策には別個の評価が必要で、いずれも遅延値だけからは導けない。
時期も明記すべきだ。観測は2026年2月11日に終わり、記事は同年9月17日に公開された。これは過去の測定であり、9月時点の状態を示すものではない。継続的に、同じ定義または変更点を明示して計測すれば、結果の持続性が見える。
最も堅実な結論は、「NICが大手に勝った」でも「この研究には価値がない」でもない。公表されたプローブ、名前、期間、方法の下で、著者のDNS平均は三つの比較対象より低く、ping平均はGoogleとCloudflareよりやや高かった。記事には議論の出発点になる情報がある一方、確認できた公開資料は平均値を完全に再現するには足りない。
Kansalの仕事を評価する際の焦点は、この境界にある。比較測定を通じて公共サービスの一面を可視化した点は認められる。それを全国規模の監査と呼んだり、役職を全利用者の代表権とみなしたりする必要はない。比較表は、限界を示し、他者が数値を検証できるときに、より有用になる。
出典
- Gaurav Kansal、「Monitoring 1.10.10.10 with RIPE Atlas Probes」。
1.10.10.10-testsリポジトリ、README、2025年11月13日のDNS件数ファイル。- APNICのKansal著者紹介および2026年8月の寄稿。
- Gaurav Kansal本人のウェブサイト。
- インド政府CGA案内、NIC Informatics、2025年7月。
- RIPE NCC、RIPE Atlasの仕組みと利用者定義測定。
- RFC 1034。
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
