DNSの基礎と課題【分散型ドメイン 前編】

おはようございます。
web3リサーチャーのmitsuiです。

毎週土日のお昼にはweb3の基礎の基礎レポートを更新しています。今週は「ドメイン」について解説します。ぜひ最後までご覧ください！

はじめに

なぜ「ドメイン名解決」は重要なのか

普段、私たちがインターネットを使う時、「google.com」や「amazon.co.jp」といった覚えやすい名前を入力してWebサイトにアクセスします。しかし、コンピュータ同士が実際に通信を行う際は、「192.168.1.1」のような数字の組み合わせ（IPアドレス）を使用しています。

この違いを理解するために、現実世界での住所システムを考えてみましょう。私たちが友人の家を訪ねる時、「田中さんの家」と言えば分かりやすいですが、郵便配達員にとっては「東京都渋谷区○○1-2-3」という正確な住所が必要です。同様に、コンピュータの世界でも、人間にとって覚えやすい「名前」と、コンピュータが理解できる「番号」を結び付ける仕組みが不可欠なのです。

現在、この「名前」と「番号」を結び付ける役割を担っているのが、DNS（Domain Name System）というシステムです。DNSは1980年代から使われ続けている、インターネットの基盤となる重要な技術です。

web3時代における新たな課題

しかし、web3と呼ばれる新しいインターネットの時代を迎えた現在、従来のDNSシステムには様々な限界が見えてきました。

まず、DNSは基本的に中央集権的な管理体制を取っています。つまり、特定の組織や政府がドメイン名の管理権限を持っているため、その組織の判断によってアクセスが制限されたり、完全に遮断されたりする可能性があります。実際に、政治的な理由でSNSサービスへのアクセスが国レベルで遮断された事例も数多く存在します。

また、従来のDNSは主にWebサイトの場所を示すことに特化しており、web3時代に必要とされる多様な機能には対応できていません。暗号通貨のウォレットアドレスや、分散ストレージシステムのファイルハッシュなど、新しいタイプのデジタル資産への対応が求められています。

記事全体の構成と学習目標

この記事は、前編・後編の2部構成となっています。前編である本記事では、現在のインターネットの基盤となっているDNSの仕組みを基礎から解説し、その歴史的背景と現在抱えている課題を説明します。

後編では、web3時代の新しい名前解決システムであるENS（Ethereum Name Service）について、その仕組みと可能性を解説します。

ぜひ最後までご覧ください！

DNSの誕生と歴史的背景

インターネット初期の素朴な名前管理

インターネットの前身であるARPANET（1969年開始）では、ネットワークに接続されているコンピュータは全世界でも数台程度でした。当時の研究者たちは、「hostsファイル」という極めて単純な仕組みを使って、コンピュータの名前とIPアドレスの対応を管理していました。

hostsファイルは、各コンピュータに保存されるテキストファイルで、「192.168.1.10 server1」のような形式で、数字のIPアドレスと覚えやすい名前を対応付けて記録していました。

この方式は、ネットワーク上のコンピュータが少数である間は十分に機能していました。研究機関同士の小規模なネットワークでは、新しいコンピュータが追加されることも稀で、手動での管理が可能だったのです。

爆発的なネットワーク拡大による問題の顕在化

1970年代後半から1980年代にかけて、学術機関や政府機関を中心にコンピュータネットワークの利用が急速に拡大しました。ARPANETに接続されるコンピュータの数は、数十台から数百台、そして数千台へと指数的に増加していきました。

この段階で、従来のhostsファイル方式には深刻な問題が発生し始めました。

• 管理の集中化による限界：当時、スタンフォード研究所が全世界のhostsファイルを一元管理していました。新しいコンピュータがネットワークに接続される度に、管理者がファイルを手動で更新し、それを全世界のコンピュータに配布する必要がありました。しかし、ネットワークの規模が拡大するにつれて、更新要求が殺到し、処理が追いつかなくなりました。
• データの不整合問題：すべてのコンピュータに同じhostsファイルを配布するのは困難で、異なるコンピュータが異なる情報を持つ状況が頻発しました。例えば、Aのコンピュータでは「server1」が「192.168.1.10」を指しているのに、Bのコンピュータでは同じ「server1」が「192.168.1.15」を指している、といった混乱が日常的に発生していました。
• 名前衝突の深刻化：異なる組織が同じコンピュータ名を使いたがる場合の調整が困難になりました。グローバルに一意の名前を維持するための仕組みが必要でしたが、中央管理では限界がありました。

DNSの設計思想と標準化

これらの問題を根本的に解決するため、1983年にカリフォルニア大学バークレー校のポール・モカペトリスを中心とするチームが、全く新しいアプローチを提案しました。それがDNS（Domain Name System）です。

DNSの設計では、革新的なアイデアが採用されました。従来の平坦なhostsファイルとは異なり、DNSでは階層構造を導入しました。最上位のルートから、国別やカテゴリ別のトップレベルドメイン、さらにその下の組織ドメインという階層を作ることで、管理責任を分散しました。

また、一度取得した情報を一定時間保存（キャッシュ）することで、同じ情報への問い合わせを高速化し、ネットワーク負荷を大幅に軽減しました。

1984年にDNSの初期仕様が定義され、その後1987年により詳細で実用的な仕様が策定されました。これらの仕様は、現在でもDNSの基本的な枠組みとして使用されており、40年近くにわたってインターネットの成長を支え続けています。

DNSの仕組み

階層構造の基本原理

DNSの最も革新的な特徴は、その階層構造にあります。この構造を理解するために、図書館の分類システムを想像してみてください。図書館では、すべての本を「総記・哲学・歴史・社会科学...」のような大分類に分け、さらにその中を中分類、小分類と細かく分けて整理しています。DNSも同様に、世界中のすべてのドメイン名を階層的に整理しているのです。

ルートドメイン（.）

階層の最頂点に位置するのがルートドメインです。これは通常省略されますが、技術的には「www.example.com.」のように最後にドット（.）が付きます。ルートドメインは、世界中のすべてのトップレベルドメインがどこで管理されているかという情報を持っています。

トップレベルドメイン（TLD）

ルートドメインの直下にあるのがTLDです。

• 国別コードトップレベルドメイン（ccTLD）は、各国が管理するドメインです。日本の「.jp」、イギリスの「.uk」、ドイツの「.de」などがこれに該当します。
• 汎用トップレベルドメイン（gTLD）は、特定の国に限定されないドメインです。商用サイト向けの「.com」、組織向けの「.org」、ネットワーク関連の「.net」などが代表的です。

セカンドレベルドメイン

TLDの下に位置するのがセカンドレベルドメインです。「example.com」の「example」部分がこれに該当します。これは、個人や組織が実際に登録・管理するドメイン名の主要部分です。

問い合わせの流れ

DNSでは、ドメイン名をIPアドレスに変換する際に、階層構造を上から下へと辿っていきます。一般的なユーザーがWebサイトにアクセスする際の流れを見てみましょう。

1. あなたがブラウザで「www.example.com」と入力すると、まずあなたのコンピュータが最寄りのDNSリゾルバ（通常はプロバイダーが提供）に問い合わせを送信します。
2. リゾルバは、まずルートサーバーに「.comドメインはどこで管理されているか」を問い合わせます。
3. ルートサーバーが「.comサーバーの場所はここです」と回答します。
4. リゾルバは.comサーバーに「example.comはどこで管理されているか」を問い合わせます。
5. .comサーバーが「example.comの詳細情報を管理するサーバーはここです」と回答します。
6. 最後に、リゾルバはexample.comの管理サーバーに「www.example.comのIPアドレスは何か」を問い合わせ、
7. 最終的なIPアドレスを取得してあなたのコンピュータに返します。

この一連のプロセスは通常数ミリ秒で完了し、ユーザーは複雑な処理を意識することなく、簡単にWebサイトにアクセスできます。

キャッシュシステムの重要性

DNSの性能を支える重要な仕組みがキャッシュシステムです。一度取得したDNS情報は一定時間メモリに保存され、同じドメイン名への問い合わせが再度発生した場合、保存されている情報を使用することで即座に応答できます。

これは、よく使う本や資料をデスクの上に置いておくことで、毎回本棚まで取りに行く手間を省くのと同じ考え方です。キャッシュされた情報には有効期限が設定されており、期限が切れると自動的に削除され、次回の問い合わせ時には改めて最新の情報が取得されます。

主要コンポーネント

ルートサーバーの役割

DNSの階層構造の頂点に位置するルートサーバーは、インターネット全体の「住所録の総目次」とも言える存在です。世界中のあらゆるDNS問い合わせの出発点となる、極めて重要なインフラストラクチャです。

現在、世界には論理的に13のルートサーバーが存在します。この「13」という数字は技術的制約に由来していますが、実際の運用では「エニーキャスト」という技術を使用して、世界中に数百台の物理的なルートサーバーが分散配置されています。

ルートサーバーが管理する情報は比較的シンプルです。すべてのTLD（.com、.org、.jp など）について、「このTLDの詳細情報はこのサーバー群が管理している」という情報のみを保持しています。つまり、ルートサーバーは直接的な答えを提供するのではなく、適切な次の問い合わせ先を案内する「交通整理役」のような機能を果たしています。

TLDサーバーと権威DNSサーバー

各TLD（トップレベルドメイン）は、それぞれ専用のTLDサーバー群によって管理されています。最も有名な.comドメインはアメリカのVerisign社が管理しており、日本の.jpドメインはJPRS（株式会社日本レジストリサービス）が管理しています。

権威DNSサーバーは、特定のドメインについて「公式で正確な」情報を保持するサーバーです。これは、いわばそのドメインの「戸籍台帳」のような存在で、最終的な情報源となります。

例えば、「example.com」というドメインを所有する組織は、必ず権威DNSサーバーを指定する必要があります。このサーバーには、ドメイン名とIPアドレスの対応、メール配送先の指定、その他の各種設定情報が登録されています。

リゾルバの機能

リゾルバは、一般ユーザーからのDNS問い合わせを受け付け、DNS階層を辿って最終的な回答を見つけ出すサーバーです。しかし、単純な「問い合わせ代行」以上の重要な機能を数多く担っています。

ISP（インターネットサービスプロバイダー）や企業が提供する本格的なリゾルバは、地域内の多数のユーザーが共有するDNSキャッシュを管理します。一度誰かがアクセスしたサイトは、地域内の他のユーザーにとっても高速にアクセスできるようになります。

また、Google（8.8.8.8）、Cloudflare（1.1.1.1）などが提供するパブリックリゾルバサービスもあり、これらは高性能・高可用性・プライバシー保護などの特徴を謳っています。

運用上の問題点と課題

可用性の問題とDDoS攻撃

DNSは「インターネットの道路標識システム」と表現できます。道路標識が見えなくなると車が目的地にたどり着けないように、DNSが機能しなくなると、すべてのインターネットサービスが事実上利用不可能になってしまいます。

2016年10月21日に発生したDyn社への大規模DDoS攻撃は、DNSの重要性を世界中に知らしめる象徴的な事件でした。IoTデバイスで構成された巨大なボットネット「Mirai」による攻撃により、Twitter、Netflix、PayPal、Spotifyなど、多数の主要サービスが数時間にわたって利用困難になりました。

この攻撃に使用されたのは、セキュリティが不十分なWebカメラ、デジタルビデオレコーダー、ルーターなど、数十万台のIoTデバイスでした。攻撃の規模は1Tbps（テラビット毎秒）を超える規模で、当時としては史上最大級のDDoS攻撃でした。

現在では、エニーキャスト技術による負荷分散、レート制限による攻撃トラフィックの制御、機械学習を活用した異常検知システムなど、多層的な防御策が採用されています。

セキュリティリスク

DNSプロトコル自体は1980年代に設計されたため、現代のサイバーセキュリティ環境に対しては本質的な脆弱性を抱えています。当時はインターネットが学術・研究目的の閉じたネットワークだったため、悪意ある攻撃を想定した設計にはなっていませんでした。

DNSキャッシュポイズニング攻撃

この攻撃では、攻撃者がDNSキャッシュサーバーに偽の情報を注入し、多数のユーザーを攻撃者が用意した偽サイトに誘導します。リゾルバが偽の応答を正当なものと誤認してキャッシュしてしまうと、以降そのドメインへの問い合わせに対して、攻撃者のサーバーのIPアドレスを返すようになります。

結果として、そのリゾルバを使用するすべてのユーザーが、正規のWebサイトではなく攻撃者の偽サイトにアクセスしてしまいます。

DNSSEC の課題

DNSSEC（DNS Security Extensions）は、DNSレスポンスの真正性を暗号学的に検証する仕組みですが、設定と管理が極めて複雑で、一つでも設定を間違えるとドメイン全体がアクセス不能になるリスクがあります。また、署名の生成と検証には計算コストがかかるため、サーバーの負荷増加や応答時間の遅延が発生します。

結果として、2024年現在でも世界的なDNSSEC普及率は30%程度に留まっています。

検閲と情報統制の現実

DNSシステムの中央集権的な性質は、政府や企業による検閲・情報統制を比較的容易にしています。多くの国では、政治的・社会的な理由でインターネットアクセスの制限が行われており、DNSがその主要な手段として使用されています。

実際の検閲事例

中国の「グレートファイアウォール（金盾工程）」は、世界最大規模のインターネット検閲システムです。Google、Facebook、Twitter、YouTube、Wikipediaなど、数万のサイトへのアクセスが制限されています。技術的には、DNSブロッキング、IPブロッキング、通信内容の検査、さらには機械学習を使った動的なブロッキングなど、極めて高度な技術が使用されています。

2014年のトルコにおけるTwitter遮断事件では、地方選挙前の政治的混乱の中で、政府がTwitterへのアクセスを完全に遮断しました。しかし、技術に詳しいユーザーがGoogle Public DNS（8.8.8.8）を使用することで制限を回避したため、政府はさらにGoogle DNSへのアクセスも遮断するという事態に発展しました。

2011年のエジプト革命では、政府が国内のインターネットインフラを物理的に遮断し、人口8000万人以上の国が5日間にわたってほぼ完全にインターネットから切り離されました。この「インターネット・キルスイッチ」の発動は、DNSを含むインターネットインフラの脆弱性を世界に示しました。

回避技術とその限界

ユーザーが検閲を回避するための技術も数多く開発されています。代替DNSサーバーの使用、VPN（Virtual Private Network）、Tor（The Onion Router）、DNS over HTTPS（DoH）などがありますが、政府がこれらのサービス自体を遮断する場合には効果が限定されます。

まとめと後編予告

DNSの功績と構造的限界

本記事では、1980年代から40年以上にわたってインターネットの基盤を支え続けているDNSシステムについて、その誕生の背景から現在抱えている課題まで解説してきました。

DNSは確かに革新的なシステムでした。ARPANETの時代の単純なhostsファイルから、階層構造とキャッシュメカニズムを備えた分散システムへの進化は、インターネットの爆発的な成長を可能にした偉大な技術的成果です。現在でも1日あたり数兆回のDNS問い合わせを確実に処理し、私たちの日常的なインターネット利用を支えています。

DNS の技術的優位性

DNSの階層構造は、管理責任の分散と効率的な名前空間の利用を実現しました。ルートからTLD、セカンドレベルドメインまでの明確な階層により、世界中で重複のない一意の名前を維持しながら、各レベルでの独立した管理が可能になりました。

キャッシュメカニズムは、問い合わせの高速化とネットワーク負荷の軽減を実現しました。一度取得した情報を効率的に再利用することで、現代のインターネットの応答速度を支えています。

構造に起因する根本的な課題

しかし、DNSの40年間の運用実績の中で、その構造に起因する根本的な限界も明らかになってきました。

中央集権的管理の問題は、各階層で特定の組織が管理権限を握ることで生じます。ルートサーバーの管理権限は事実上アメリカ政府が握っており、TLDの管理も特定の国や企業に委ねられています。この構造は、政治的・経済的な影響による検閲や、管理組織の判断による一方的なサービス停止のリスクを内包しています。

セキュリティの後付け対応という問題もあります。DNSは本来セキュリティを考慮して設計されていないため、DNSSECのような追加的なセキュリティ機能は複雑で普及が困難です。

機能的制約も重要な課題です。DNSは基本的にドメイン名をIPアドレスに変換することに特化しており、Web3時代に求められる多様な機能（暗号通貨アドレスとの紐づけ、分散ストレージの活用、プログラマブルな条件処理など）には対応できていません。

web3時代が求める新しいパラダイム

web3と呼ばれる新しいインターネットの時代では、従来のWeb2.0とは根本的に異なる価値観と技術要件が求められています。

真の分散化とは、単にサーバーを地理的に分散させることではなく、管理権限自体を分散させ、単一の組織や政府による支配を不可能にすることです。デジタル資産との seamless な統合、プログラマビリティの実現、ユーザー主権の確立が重要な要件となっています。

ENS - Web3時代の名前解決システム

これらの新しい要件を満たすために開発されたのが、ENS（Ethereum Name Service）です。ENSは単なるDNSの代替品ではなく、web3時代の包括的なデジタルアイデンティティシステムとして設計されています。

後編では、ENSがどのようにしてDNSの限界を克服し、web3時代の要件を満たしているかを詳しく解説します。

免責事項：リサーチした情報を精査して書いていますが、個人運営&ソースが英語の部分も多いので、意訳したり、一部誤った情報がある場合があります。ご了承ください。また、記事中にDapps、NFT、トークンを紹介することがありますが、勧誘目的は一切ありません。全て自己責任で購入、ご利用ください。

🗓️イベント情報

• 0から学ぶweb3基礎勉強会 #1 ~DePIN~
  • 7月14日(月)@名古屋
  • 7月15日(火)@東京
  • 7月15日(火)@オンライン（東京回をオンライン配信）
• OrbsCafe #12　『Ethereum徹底解説』（登壇）
  • 7月27日(日)@東京

About us：「web3 for everyone」をコンセプトに、web3の注目トレンドやプロジェクトの解説、最新ニュース紹介などのリサーチ記事を毎日配信しています。

Author：mitsui @web3リサーチャー
「web3 Research」を運営し、web3リサーチャーとして活動。

Contact：法人向けのリサーチコンテンツの納品や共同制作、リサーチ力を武器にしたweb3コンサルティングや勉強会なども受付中です。詳しくは以下の窓口よりお気軽にお問い合わせください。（📩 X / HP）

→お問い合わせ先はこちら