冗談は一切抜きに、Cloudflareの1.1.1.1リゾルバーが2018年のエイプリルフールに発売されました。プライバシーに配慮し高いパフォーマンスとセキュリティを重視するこのサービスは、過去7年間で、世界の約250か所（国/地域）から1日あたり平均1.9兆件のクエリーを処理するまでに成長しました。このトラフィックの集約された分析は、単純なWebトラフィックの傾向を超えたインターネット活動に関する独自の洞察を提供し、現在、Radarのドメインページとレーダードメインランキングに1.1.1.1のデータの分析を使用しています。
2022年12月、 CloudflareはAS112プロジェクト に参加し、インターネットが誤ったDNSクエリに対処できるよう支援しています。2023年3月、RadarでAS112の統計ページを公開し、トラフィックの傾向やこの誤送信トラフィックに対するクエリタイプに関する情報を提供しました。このページで提供する基本的な分析を拡張し、Domainsページに使用したリゾルバーデータの分析を基に、本日、 Cloudflare Radar上にDNS専用ページを立ち上げ、1.1全体に見られる集約されたトラフィックと使用の傾向をより明確に可視化しました。 1.1リゾルバートラフィック。グローバル、ロケーション、自律システム（ASN）トラフィックのトレンドを見るだけでなく、プロトコルの使用状況、クエリと応答の特性、 DNSSECの使用状況に関する視点も提供します。
この新しいページで分析されたトラフィックは、手動で1.1.1.1をリゾルバとして使用するようにデバイスやローカルルーターを設定しているユーザー、1.1.1.1を加入者のデフォルトのリゾルバとして設定しているISP、1.1.1.1を自身のデバイスにCloudflareの1.1.1.1/WARPアプリをインストールしているユーザーが、自分のデバイスにリゾルバーを追加したり、トラフィックの分析は、Cloudflareのプライバシーポリシーおよび当社の1.1.1.1パブリックDNSリゾルバーのプライバシー保護へのコミットメントに従って、匿名化されたDNSクエリログに基づいています。
以下では、Radarの新しいDNSページのセクションを説明し、含まれるグラフとそのグラフが提供するメトリクスの重要性を確認します。これらのグラフ内に示されるデータと傾向は、集約されたクエリの発信元である場所やネットワーク、および選択された時間枠によって異なります。
多くのRadar指標と同様に、DNSページはトラフィックの傾向を主導し、世界レベル（デフォルト）、または選択された場所または自律システム（ASN）からの正規化されたクエリー量を示しています。他のRadarトラフィックベースのグラフと同様に、表示される期間は日付ピッチカーを使用して調整することができ、デフォルト選択（過去24時間、過去7日間など）の場合、前の期間のトラフィックとの比較もできます。プロットされています。
場所レベルのビュー（以下の例の ラトビア など）では、クエリ量別の上位5つのASNを示す表がグラフの横表示されています。選択した場所からのクエリのネットワークの割合が表示されており、この表は、ユーザーが1.1.1.1への最も多くのトラフィックを生成しているプロバイダーに関するインサイトを提供します。
国/地域を選択すると、その場所の集約トラフィックグラフに加えて、その国に関連付けられている国コードのトップレベルドメイン（ccTLD）のクエリ量も表示されます。グラフには、そのccTLDに対する全世界のクエリー量を示す線と、関連する場所からのクエリーに基づくクエリー量を示す線が含まれています。アンギラのccTLDは.aiで、成長を続けるAIに焦点を当てた 企業の中で、人気のある選択肢となっています。ほとんどの地域では、ccTLDの世界と「ローカル」のクエリー量の間にギャップがあるのに対し、アンギラのギャップはかなり大きく、下のグラフが示すように、このギャップのサイズは、ccTLDの人気と、アンギラの比較的小規模なユーザー層の両方に起因しています。 。（Traffic for .aiアンギラからのドメインは、グラフの下のダークブルーの線で示されています。同様に、かなりのギャップが、.ioのような他の「人気のある」ccTLDでも見られます。（イギリス領インディアナ州）、.fm（ミクロネシア連邦）、および.co（コロンビア）。他の場所での「ローカル」ccTLDクエリー量が多いと、全世界のクエリー量と比較した場合、ギャップが小さくなります。
特定の場所またはASNからの信号の強さ（つまり、トラフィックの量）によっては、このデータは、報告されたインターネットの停止や遮断、または1.1.1.1のブロックの報告の裏付けとして使用することもできます。たとえば、下のグラフは、ベネズエラのプロバイダーであるCANTVが加入者の1.1.1.1へのアクセスをブロックしたと報告した結果を示しています。同じ時期にCloudflareのリゾルバーへのアクセスをブロックしたと報告している別のベネズエラプロバイダーである Supercable でも同様の減少が見られます。
個々のドメインページ（cloudflare.com のように、たとえば、）は長い間、各場所からのそのドメインに対するDNSクエリの割合に基づいて、場所別ドメインの人気度を示すチョロレスマップと表を添付していました。同様のデータが、世界概要ページの下部に、各場所からの1.1.1.1へのグローバルクエリーの割合に基づいて表示されています。
トラフィックの傾向は常に興味深いものであり追跡することが重要ですが、1.1.1.1に対するクエリの特性と関連する応答を分析することで、基盤となるトランスポートプロトコルの採用、タイプの一般性、キャッシュ可能性、セキュリティに関する洞察を提供することができます。
UDPTCP。 」その後の30年超に渡り、 UDPはDNSクエリの主要なトランスポートプロトコルであり、応答が大きすぎて単一のUDPパケットに収まらない場合など、限られた数のユースケースでTCPに頼っていました。しかし、プライバシーが非常に大きな問題となっているため、2016年のDNS over TLS （DoT）、2018年のDNS over HTTPS （DoH）の仕様を通じて、暗号化されたクエリが可能になりました。Cloudflareの1.1.1.1リゾルバーは、公開以来、これらのプライバシー保護プロトコルの両方をサポートしています。DNSトランスプロトコルのグラフは、これら4つのプロトコルにおける1.1.1.1へのクエリの分布を示しています。（デバイスまたはルーターで1.1.1.1を設定すると、デフォルトでDNS over UDPを使用しますが、最近のAndroidのバージョンはDoTとDoHをサポートしています。1.1.1.1アプリはデフォルトでDNS over HTTPSを使用しており、ユーザーはDNS over HTTPSを使用するようにブラウザを設定することもできます。）
なお、Cloudflareのリゾルバは、 Mozilla やその他の大規模プラットフォームに対し、DoHや Oblivious DoH（ODoH） でのクエリーも提供していますが、このトラフィックは、現在分析に含まれていません。そのため、DoHの普及率はこのグラフでは十分に示されていません。
2月19日から2月26日までの全世界を集計すると、トランスポートプロトコルの分布は、 UDPが86.6%、DoTが9.6%、 TCPが2.0%、DoHが1.7%でした。ただし、場所によっては、ユーザーのプライバシー意識が高い場合に、この割合が変化する可能性があります。たとえば、下のグラフは、同時期のエジプトの分布を示しています。その国では、 UDPとTCPの割合が世界レベルよりも大幅に低くなっているのに対して、DoTとDoHの割合は大幅に高くなっており、これはユーザーがDNSクエリのプライバシーを世界平均よりも心配している可能性がある、またはDoTを使用して手動で1.1.1.1を設定したAndroid端末の1.1.1.1ユーザーに大幅に集中しています。（ 2024 Cloudflare Radar Year in Review では、Androidが エジプトにおけるモバイル端末トラフィックの85%を占めている ことがわかりました。したがって、同国のモバイル端末の使用率はAndroidに大きくかかっています。）
RFC1035はまた、送信されたクエリ名に関する関連情報を返す多くの標準的かつインターネット固有のリソースレコードタイプを定義しました。最も一般的なレコードタイプは A と AAAA で、それぞれホスト名の IPv4 と IPv6 アドレス（存在するものと仮定）を返します。下のDNSクエリタイプグラフを見ると、世界的に見れば、これら2つのレコードタイプは、1.1.1.1が受信するクエリの80%を占めていることがわかります。グラフに示された他のレコードのうち、HTTPSレコードはHTTP/3とHTTP/2のサポートを示すために使用でき、PTRレコードは与えられたIPアドレスに基づいてドメイン名を検索するためにリバースDNSレコードで使用され、NSレコードは権威を示しています。調達することにしました。
レスポンスコードは、1.1.1.1からクライアントへの各レスポンスとともに送信されます。6つの可能な値は、もともと RFC 1035 で定義されたものであり 、そのリストは RFC 2136 と RFC 2671 で さらに拡張されました 。NOERROR は、その名の通り、クエリでエラー状態が発生しなかったことを意味します。NXDOMAIN REFused など）こともあれば、上流の権威ネームサーバー（ NXDOMAIN など）から来ている可能性もあります。
以下に示したDNSレスポンスコードグラフは、グローバルに見られるクエリの大部分が、解決プロセス中にエラーに遭遇しないこと（NOERROR）、およびエラーが発生した場合、そのほとんどがNXDOMAIN（そのようなレコードがない）であることを強調しています。NOERRORには空のレスポンスも含まれることに注意してください。これは、クエリ名とクエリタイプのレコードがない場合に発生する空のレスポンスですが、クエリ名と他のクエリタイプのレコードがある場合に発生します。
DNSは他の多くのプロトコルの最初のステップの依存関係であるため、特定の種類のクエリの量を使用して、それらのプロトコルの普及率を間接的に測定することができます。しかし、普及率を効果的に測定するには、DNSレコード普及率グラフで表される有用な応答が得られたクエリーの割合も考慮する必要があります。
下の例は、Aレコードのクエリーに対するクエリーの88％近くが有用な応答を返していることを示しています。IPv4は確立されたプロトコルであるため、残りの12%は、A レコードのない有効なホスト名に対するクエリ（例：MXレコードだけを持つメールドメイン）。しかし、同じグラフを見ると、IPv6に関する懸念された普及率のギャップは依然として大きいことがわかります。
CloudflareのDNSリゾルバーは、上流の権威ネームサーバーから応答を受け取ると、指定された時間、それをキャッシュします。詳細は後述します。これらの応答をキャッシングことで、同じ名前に対する後続のクエリをより効率的に処理できます。DNSのキャッシュヒット率のグラフは、キャッシュから応答が提供される頻度に関する洞察を提供します。世界レベルでは、以下に示すように、クエリの80%以上にすでにキャッシュされているレスポンスがあります。これらの割合は、クエリのパターンが地域やネットワークによって異なるため、場所やASNによって異なります。
前の段落で述べたように、権威ネームサーバーが1.1.1.1に応答を送信すると、その中の各レコードには、どれくらいの期間キャッシュされるべきか、有効とされるかについての情報が含まれています。この情報の一つをTime-To-Live（TTL）と呼びます。レスポンスには複数のレコードを含む可能性があるため、これらのTTLのうちの最小のTTL（「最小」 TTL）は、1.1.1.1がリクエスト全体をキャッシュできる時間を定義します。 。1.1.1.1のIPトンネルから配信された各レスポンスのTTLは、キャッシュは、時間が経つにつれてゼロに向かって減少します。その時点で1.1.1.1は権威ネームサーバーに戻る必要があります。TTL値が比較的低いホスト名は、関連するリソースのトラフィック管理のため、レコードがやや動的であることを示唆しています。 TTL値が長いと、関連するリソースがより安定しており、変更頻度が低いことが期待されることを示しています。
DNS最小TTLグラフは、1分未満から1週間超まで、7つのバケットに分類した、一般的な5つのDNSレコードタイプのTTL値の集約分布を示しています。たとえば、2月の第3週では、AおよびAAAA応答はTTLが低い傾向があり、80%以上が5分未満でした。対照的に、 NSとMXの応答は、15分から1時間、1時間から1日と、より集中していました。MXレコードとNSレコードは変更頻度が低いため、通常は高いTTLで設定されます。これにより、 DNS解決を高速化するために、より長い期間キャッシュされるようになります。
DNSセキュリティ拡張機能（DNSSEC）は、 DNSに認証の追加レイヤーを追加し、 DNS応答の完全性と信頼性を確立します。これにより、後続のHTTPSリクエストがスプーフィングされたドメインにルーティングされないようにします。1.1.1.1にクエリーを送信する際、DNSクライアントは、クエリに特定のフラグ（「DO」ビット）を設定することでDNSSEC対応であることを示すことができ、これにより、応答でDNSSECデータを返して良いことをリゾルバーに知らせることができます。DNSSECクライアント認識グラフは、1.1.1.1が見るDNSSECを理解しているクライアントと、理解していないクライアントからのクエリの割合を分析したものです。（デフォルトでは、1.1.1.1は、「CD」（チェック無効）ビットを設定してクライアントが明示的に指示されない限り、権威ネームサーバーからのDNSSEC の応答を常に検証し、無効な応答をクライアントに転送しないようにして、クライアントを保護しようとすることに注意してください。 ）。
残念ながら、下のグラフが示すように、Cloudflareのリゾルバが見るクエリの90%近くは、 DNSSECを認識しないクライアントからのクエリです。このようにクライアントが広く認識していない原因は、いくつかあります。クライアント側では、 DNSSECはほとんどのユーザーにとってデフォルトで有効になっておらず、 DNSSECを有効にするには、技術に精通したセキュリティ意識の高いユーザーであっても追加の作業が必要です。権威面では、ドメイン所有者にとって、 DNSSECをサポートするには追加の運用保守と知識が必要であり、間違いを犯すとインターネットからドメインが消えてしまい、重大な（金銭的な）問題が生じる可能性があります。
関連するエンドツーエンドセキュリティグラフは、クライアントのDNSSEC能力と暗号化の使用（DoTまたはDoHの使用）を考慮した場合に、改ざんから保護されたDNSインタラクションの割合を表しています。このことから、世界全体で不均衡がさらに広がっていることがわかり、暗号化とDNSSECのさらなる導入の重要性を浮き彫りにしています。
DNSSECの検証が行われるためには、リクエストされるクエリ名がDNSSEC対応ドメインの一部である必要があります。DNSSEC検証ステータスグラフは、「セキュア」および「無効」ラベルの下で該当するクエリの割合を表しています。DNSSECなしのドメインのクエリは 安全でない とラベル付けされ、 DNSSEC検証が適用されなかった（さまざまな種類のエラーなど）クエリは その他 のラベルに分類されます。2025年2月現在、汎用トップレベルドメイン（TLD）の約93%と国コードのトップレベルドメイン（ccTLD）の65%がDNSSECで署名されているものの、個々の（子）ドメインの採用率はグラフのように大きく異なります。以下は、クエリの80%以上が安全でないとラベル付けされたことを示しています。
DNSは、インターネットの基本的な基盤部分です。多くのインターネットユーザーは、 DNSを、覚えやすいホスト名をIPアドレスに変換するという役割以上のものとして考えていませんが、プライバシーからパフォーマンス、セキュリティまで、それを実現するために多くのことが取り組んでいます。Cloudflare Radarの新しいDNSページは、グローバル、国、ネットワークレベルでの舞台裏で何が起こっているかを可視化するために努めています。
上記のグラフはDNSページから取得したものですが、基になるデータはすべてAPI経由で利用可能で、RadarのData Explorer と AIアシスタントを使って、場所、ネットワーク、期間を問わず、より詳細な情報をインタラクティブに調査することができます。またこれまでと同様、RadarとData Assistantのチャートとグラフはダウンロードして共有することができ、ご自身のブログ記事、Webサイト、またはダッシュボードに埋め込むことができます。
DNSグラフをソーシャルメディアで共有する場合は、 @CloudflareRadar および @1111Resolver （X）、 noc.social/@cloudflareradar （Mastodon）、 radar.cloudflare.com （Bluesky）などのタグを必ず付与してください。ご質問またはご意見がございましたら、ソーシャルメディアでまたは、メールでご連絡ください。