【入門編】モバイル網におけるDNSキャッシュサーバの挙動とEDNS Client Subnet(ECS) – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

こんにちは！ネットワークの世界にどっぷり浸かっていると、時折「インフラって本当に面白いな」と深夜の作業中にふと思うことがあります。

さて、皆さんはスマホで動画を再生したとき、「読み込みが遅いな……」と感じたことはありませんか？実はその裏側で、あなたのスマホとインターネットの巨大な郵便局たちが、ものすごく高度な「お見合い」を繰り広げているんです。

今日は、モバイル通信の現場でひっそりと、しかし超重要に働いている「DNSキャッシュサーバ」と、CDNを最適化する魔法の仕組み「EDNS Client Subnet (ECS)」について、専門書を閉じて、身近な例え話で紐解いていきましょう。

—

まず、DNS（Domain Name System）を理解しましょう。インターネット上のサーバーは、実は人間が覚えられないような「数字の羅列（IPアドレス）」で管理されています。でも、私たちは google.com とか youtube.com といった名前でアクセスしますよね。

この「名前」を「数字の住所」に変換してくれるのが、DNSという案内所です。

モバイル通信において、この案内所は非常に巨大です。あなたのスマホが「この動画が見たい！」とリクエストを送ると、まずはキャリア（ドコモやau、ソフトバンクなど）が用意した「キャッシュサーバ」という、近所の郵便局のような場所に問い合わせが行きます。

—

現代のインターネットでは、動画や画像は「CDN（Contents Delivery Network）」という仕組みを使って、世界中に散らばった「エッジサーバ」から配信されています。

ここで問題が発生します。
例えば、あなたが東京にいるのに、DNSが「一番近いサーバを教えて」と聞いた結果、なぜかロサンゼルスのサーバを案内されたらどうなるでしょう？当然、動画の読み込みは遅くなりますよね。

これまでは、DNSサーバは「あなたのIPアドレス」ではなく「DNSサーバ自身のIPアドレス」を元に場所を判断していました。でも、キャリアのDNSサーバは巨大なデータセンターにあることが多く、「ユーザーはどこにいるか分からない」というジレンマがあったのです。

—

そこで登場したのが、EDNS Client Subnet (ECS) です。
これは、DNSの問い合わせの中に「実は、ユーザーさんはこのエリア（ネットワークのセグメント）にいる人ですよ」という「ヒント」をこっそり書き添えて送る仕組みです。

郵便物に例えるなら、こんな感じです。

このおかげで、CDNはユーザーの現在地に最も近いエッジサーバを選択でき、動画が爆速で再生されるようになるわけです。

—

実際に、このECSがどう動いているかを確認する簡単な方法があります。エンジニアの必携ツール dig コマンドを使ってみましょう。

以下のコマンドをターミナルで叩くと、DNSサーバに対して「ECSの情報を付与して教えてくれ」とリクエストを送ることができます。

# GoogleのDNS(8.8.8.8)に対して、クライアントサブネット情報(1.2.3.0/24)を付けて問い合わせる
dig @8.8.8.8 example.com +subnet=1.2.3.0/24

このコマンドの結果を見ると、EDNS セクションにクライアントのサブネット情報が含まれているのが確認できるはずです。開発現場では、CDNの設定が正しい地域を返しているかチェックする際、この +subnet オプションは必須のデバッグ手法です。

—

モバイル通信が4Gから5Gへと進化し、ミリ波やSub6といった電波の技術ばかりが注目されがちですが、その裏側でこうした「いかにユーザーの場所を正しく伝え、最適な体験を届けるか」という地道な工夫が積み重なっています。

私たちが何気なく見ている動画の裏には、こうした「パケットの郵便配達」を最適化するための緻密な計算がある。そう思うと、少しだけネットワークが愛おしくなりませんか？

もし皆さんがインフラエンジニアを目指しているなら、まずはこの「クライアントの場所をどうやって伝えるか」という視点を持つだけで、トラブルシューティングの引き出しがグッと増えるはずです。

次回は、このDNSキャッシュサーバがどうやって「鮮度」を保っているのか、TTL（Time To Live）という「賞味期限」の話を深掘りしてみましょう。それでは、また次回の記事でお会いしましょう！