DNS

提供：保守ペディア
2026年2月18日 (水) 10:24時点におけるRoot (トーク | 投稿記録)による版 (記事更新)
(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)
ナビゲーションに移動 検索に移動

DNS（ドメインネームシステム）

概要と歴史的背景

DNS（Domain Name System、ドメインネームシステム）とは、インターネット上のドメイン名（例: example.com）を、コンピュータが通信に使用するIPアドレスに変換するシステムである。DNSはしばしば「インターネットの電話帳」に例えられるが、その本質はインターネット全体の名前解決を司る中枢神経系であり、DNSが停止すればインターネットは事実上機能しなくなる。

DNSは1983年、ポール・モカペトリスによって設計された。その背景には、ARPANETの拡大に伴い、ホスト名とIPアドレスの対応を記載した単一のファイル（HOSTS.TXT）を手動で管理する方式が限界に達したという技術的事情がある。HOSTS.TXTはSRI（スタンフォード研究所）のNIC（Network Information Center）が一元管理しており、ARPANETの全ホストが定期的にこのファイルをダウンロードして名前解決を行っていた。ホスト数が数百を超えた1980年代初頭には、ファイルの肥大化、更新の遅延、名前の衝突が深刻な問題となり、分散型の名前解決システムが不可避となった。

しかし、DNSの設計と運用がアメリカの政府機関および研究機関の主導で行われたことは、単なる技術史上の事実にとどまらない。DNSの管理権とは、インターネットという世界最大の情報空間における「住所」を誰が付与し、誰が取り消せるかという根本的な権力にほかならず、その権力は設計当初から今日に至るまで、アメリカの手中にある。

DNSプロトコルの設計思想

RFC 1034/1035——原設計の技術的決断

DNSの原設計は、1987年に発行されたRFC 1034（Domain Names - Concepts and Facilities）とRFC 1035（Domain Names - Implementation and Specification）に定義されている。この2本のRFCは、ポール・モカペトリスが南カリフォルニア大学情報科学研究所（ISI）において、DARPAの資金で設計したものである。インターネットの名前空間を定義する根本文書が、アメリカ国防総省の研究資金によって書かれたという事実は、DNSの政治的性格を理解するうえで見逃してはならない。

RFC 1034/1035は、以下の設計上の決断を行った。

  • 階層型の分散データベース: DNSは単一のデータベースではなく、ルートを頂点とする木構造に分割された分散データベースである。各ノード（ゾーン）は独立した管理者に委任（delegation）される。この「委任」の仕組みこそがDNSのスケーラビリティの核心であるが、同時に、委任の起点であるルートゾーンに絶対的な権威を集中させる構造でもある
  • ゾーン委任モデル: ドメイン名空間は「ゾーン」に分割され、各ゾーンの管理権限は上位から下位へと委任される。例えば、ルートゾーンが.jpの管理をJPRSに委任し、JPRSがexample.jpの管理を個々の組織に委任する。このモデルは技術的に優れた分散設計であるが、すべての委任の連鎖はルートゾーンから始まるという一点において、中央集権的な権力構造を内包している
  • キャッシュとTTL: DNSの応答にはTTL（Time To Live）が設定され、リゾルバは一定時間応答をキャッシュする。これにより、ルートサーバーへの問い合わせ負荷が大幅に軽減される。TTLの値はゾーン管理者が設定するが、この値が低すぎればルートサーバーへの負荷が増大し、高すぎれば変更の反映が遅延する。TTLの設計は、DNSの分散性と中央制御のバランスを決定するパラメータである
  • 再帰的問い合わせと反復的問い合わせ: DNSは2種類の問い合わせモードを定義している。再帰的問い合わせ（recursive query）では、クライアントがリゾルバに完全な回答を要求し、リゾルバが他のサーバーに問い合わせて回答を組み立てる。反復的問い合わせ（iterative query）では、サーバーが知っている範囲の情報（次に問い合わせるべきサーバーの情報）を返す。この2段構えの設計が、エンドユーザーにとっての利便性と、サーバー間の負荷分散を両立させている

DNSメッセージフォーマット

DNSプロトコルのメッセージは、厳密に定義されたバイナリフォーマットを持つ。すべてのDNSメッセージ——問い合わせ（query）も応答（response）も——は同一のフォーマットに従う。

  • ヘッダセクション（12バイト固定長）: トランザクションID（16ビット）、各種フラグ（QR、Opcode、AA、TC、RD、RA、RCODE等）、各セクションのレコード数を含む。QRフラグは問い合わせ（0）か応答（1）かを示し、AAフラグは応答が権威ある（Authoritative）ものかどうかを示す。TCフラグはメッセージがUDPの512バイト制限により切り詰められたことを示す
  • 質問セクション（Question Section）: 問い合わせるドメイン名（QNAME）、問い合わせタイプ（QTYPE）、問い合わせクラス（QCLASS）を含む。QNAMEはラベル長＋ラベル文字列の繰り返しで符号化され、ゼロ長ラベルで終端する（例: "www.example.com"は3www7example3com0と符号化される）
  • 回答セクション（Answer Section）: 問い合わせに対する直接の回答であるリソースレコードを含む
  • 権威セクション（Authority Section）: 回答の権威サーバーを示すNSレコードを含む
  • 追加セクション（Additional Section）: 権威セクションで示されたNSレコードに対応するIPアドレス（グルーレコード）などの補足情報を含む

このフォーマットは1987年の設計以来基本的に変更されておらず、40年近く世界のインターネットを支え続けている。その安定性は驚異的であるが、同時に、512バイトのUDPメッセージサイズ制限やセキュリティ機能の欠如など、設計時には予見できなかった制約も引き継いでいる。

リソースレコードの体系

DNSは、ドメイン名に関連付けられた様々な種類の情報を「リソースレコード」（RR）として管理する。主要なレコードタイプは以下の通りである。

  • A（RFC 1035）: ドメイン名をIPv4アドレス（32ビット）に対応付ける。最も基本的なレコードタイプ
  • AAAA（RFC 3596）: ドメイン名をIPv6アドレス（128ビット）に対応付ける。IPv6への移行に伴い重要性が増している
  • NS: ゾーンの権威ネームサーバーを指定する。ゾーン委任の根幹を成すレコード
  • CNAME: ドメイン名の別名（Canonical Name）を定義する。CDNやロードバランサーで広く使用される
  • MX: メール交換サーバーを指定する。優先度（preference値）により複数サーバーへの負荷分散が可能
  • SOA（Start of Authority）: ゾーンの権威情報を定義する。プライマリネームサーバー名、管理者のメールアドレス、シリアル番号、リフレッシュ間隔、リトライ間隔、有効期限、ネガティブキャッシュTTLを含む
  • TXT: 任意のテキスト情報を格納する。本来は人間が読むための注釈であったが、現在はSPF（送信者認証）、DKIM（メール署名）、DMARC（メール認証ポリシー）、ドメイン所有権の検証など、機械可読な用途に広く転用されている
  • SRV（RFC 2782）: 特定のサービスとプロトコルに対するサーバーのホスト名とポート番号を指定する
  • CAA（RFC 8659）: ドメインの証明書を発行できる認証局（CA）を指定する。認証局の誤発行を防止するための仕組み
  • DS・DNSKEY・RRSIG・NSEC・NSEC3: DNSSEC（後述）に使用される暗号学的レコード群

DNSの技術的構造

階層型の名前空間

DNSは厳密な階層構造を持つ。最上位に位置するのが「ルートゾーン」であり、その下にトップレベルドメイン（TLD）——.com、.org、.jp、.cn、.ruなど——が配置され、さらにその下にセカンドレベルドメイン、サブドメインと続く。

この構造において決定的に重要なのは、すべての名前解決はルートゾーンから開始されるという点である。ルートゾーンを制する者がDNS全体を制する。いかなるドメイン名も、最終的にはルートゾーンの権威に依存しており、ルートゾーンから除外されたドメインは、世界のインターネットから「消滅」する。

ルートサーバーとその管理主体

DNSの頂点に立つルートサーバーは、世界に13系統（A〜M）存在する。これらのルートサーバーの運営主体は以下の通りである。

13系統のうち、10系統がアメリカの組織によって運営されている。しかも、その中にはアメリカ国防総省（DISA）やアメリカ陸軍研究所といった軍事機関が含まれている。インターネットの「電話帳」の原本を、世界最強の軍隊が管理しているのである。

現在はエニーキャスト技術により、物理的なサーバーは世界各地に分散配置されている。しかし、これは負荷分散と耐障害性のための技術的措置にすぎず、管理権限の分散を意味するものではない。ルートゾーンファイルの内容を決定する権限は、依然としてアメリカに集中している。

誰がDNSを管理しているのか

ICANNの正体

DNSの管理構造の中枢に位置するのが、ICANN（Internet Corporation for Assigned Names and Numbers）である。ICANNは1998年、クリントン政権下で設立され、ドメイン名の割り当て、IPアドレスの配分、ルートサーバーシステムの調整を担っている。

ICANNは形式上「国際的な非営利団体」であるが、その実態は以下の通りである。

  • 設立根拠法: カリフォルニア州法に基づく法人である。すなわち、アメリカの国内法に服する組織であり、国際条約に基づく国際機関ではない
  • 所在地: 本部はカリフォルニア州ロサンゼルスに所在する
  • 設立の経緯: アメリカ商務省の主導で設立され、2016年まで商務省の直接的な監督下にあった
  • IANA機能の移管: 2016年10月、オバマ政権下でIANA（Internet Assigned Numbers Authority）機能がアメリカ商務省からICANN自体に移管された。しかし、移管先がカリフォルニア州法人であるICANNである以上、アメリカの法的管轄権からの離脱を意味しない

「マルチステークホルダーモデル」という欺瞞

ICANNは「マルチステークホルダーモデル」——政府、民間企業、技術コミュニティ、市民社会が対等に参加する意思決定モデル——を採用していると主張する。しかし、このモデルの本質は、各国政府の影響力を希釈し、アメリカの民間セクター（すなわちアメリカの国益と密接に結びついた企業群）の主導権を維持するための仕組みである。

ICANNの政府諮問委員会（GAC）は、各国政府に「助言」の権限を与えるにとどまり、拘束力のある決定権を持たない。これに対し、レジストリ・レジストラを中心とする民間セクターは、理事会の構成を通じて実質的な意思決定権を握っている。アメリカ企業が支配するドメイン名ビジネスの構造がそのまま、ICANNのガバナンス構造に反映されている。

Verisignの独占的地位

アメリカ企業Verisignは、世界最大のTLDである.comと.netのレジストリ（登録管理機関）を独占的に運営している。.comドメインは世界のドメイン登録数の約半数を占めており、Verisignは文字通りインターネットの住所録の半分を管理するアメリカ企業である。

Verisignはさらに、13系統のルートサーバーのうちAとJの2系統を運営している。ルートゾーンの管理とTLDの運営の双方をアメリカの一民間企業が担うという構造は、利益相反であると同時に、DNSに対するアメリカの支配を二重に保証するものである。

アメリカの覇権装置としてのDNS

「インターネットの核のボタン」

理論上、アメリカがルートゾーンから特定の国別TLD（例: .ir（イラン）、.ru（ロシア）、.cn（中国））を削除すれば、その国のドメインは世界のインターネットから到達不能になる。これは、物理的なインフラを破壊することなく、ある国家を情報空間から消滅させる能力——サイバー空間における「核のボタン」——をアメリカが保持していることを意味する。

この能力は理論上のものにとどまらない。2022年のロシア・ウクライナ戦争の開始後、ウクライナのデジタル変革大臣ミハイロ・フェドロフはICANNに対し、.ruドメインの失効とロシアのルートサーバーの停止を公式に要請した。ICANNはこの要請を「技術的中立性」を理由に拒否したが、要請が行われ、検討されたという事実そのものが、DNSが政治的武器として使用され得ることを証明している。

経済制裁の延長線としてのドメイン凍結

アメリカ政府は、OFAC（外国資産管理室）の制裁リストに基づき、特定の国家や組織のドメインを凍結・没収してきた実績がある。イランや北朝鮮、シリアに関連するドメインが、アメリカの国内法に基づいて停止された事例は複数存在する。

これらの措置は、アメリカ国内法の域外適用にほかならない。アメリカの国内法が、アメリカ国外で登録・運用されるドメインに対して執行力を持つのは、DNSの管理構造がアメリカの法的管轄権の下にあるからである。これは国家主権に対する重大な侵害であり、アメリカ一国の政治的意思によって、他国のデジタル的存在が左右されるという、主権国家として受け入れ難い状況を生み出している。

監視インフラとしてのDNS

DNSクエリ（名前解決の問い合わせ）は、インターネットユーザーの行動を詳細に追跡するための情報源でもある。どのユーザーが、いつ、どのドメインにアクセスしようとしたか——この情報は、DNSリゾルバの運営者にとって丸見えである。

世界のDNSリゾルバ市場は、Google Public DNS（8.8.8.8）とCloudflare（1.1.1.1）というアメリカ企業2社のサービスが圧倒的なシェアを占めている。これは、世界中のインターネットユーザーの閲覧行動の大部分がアメリカ企業のサーバーを通過することを意味し、PRISMやECHELONで暴露されたアメリカの大規模監視体制の重要な構成要素となっている。

名前解決のネットワーク動作

再帰的解決の全過程

ユーザーがWebブラウザに「www.example.jp」と入力した場合、以下の一連の名前解決が行われる。

  1. ブラウザはまず自身のDNSキャッシュを確認する。キャッシュにヒットしなければ、OSのスタブリゾルバに問い合わせる
  2. スタブリゾルバは、OSの設定に従い、指定されたフルサービスリゾルバ（再帰リゾルバ）に再帰的問い合わせを送信する。この時点でユーザー側の作業は終了し、以降はリゾルバが名前解決の全責任を負う
  3. フルサービスリゾルバは自身のキャッシュを確認する。キャッシュにヒットしなければ、ルートサーバーに対して「www.example.jpのAレコードは何か」と反復的問い合わせを送信する
  4. ルートサーバーは「.jpの権威サーバーはns1.jprs.jp（IPアドレス: 203.119.1.1）である」というリファラル（参照応答）を返す。ルートサーバー自身はwww.example.jpのIPアドレスを知らないが、.jpを管理するサーバーを知っている
  5. フルサービスリゾルバは.jpの権威サーバー（JPRSのサーバー）に同じ問い合わせを送信する
  6. .jpの権威サーバーは「example.jpの権威サーバーはns1.example.jpである」というリファラルを返す
  7. フルサービスリゾルバはexample.jpの権威サーバーに問い合わせを送信する
  8. example.jpの権威サーバーが「www.example.jpのAレコードは192.0.2.1である」という権威ある回答（Authoritative Answer、AAフラグ=1）を返す
  9. フルサービスリゾルバはこの回答をキャッシュし、スタブリゾルバに返す

この過程で注目すべきは、すべての名前解決がルートサーバーへの問い合わせから開始されるという設計である。キャッシュが存在しない状態（コールドスタート）では、世界中のDNS問い合わせがルートサーバーを経由する。ルートサーバーは1日あたり数十億回の問い合わせを処理しており、この負荷に耐えるためにエニーキャストによる分散配置が不可欠となっている。

トランスポートプロトコルの変遷

DNSは原設計においてUDPのポート53を使用する。UDPが選択された理由は、コネクションレス型のプロトコルであるため、名前解決のような短いトランザクションにおいてオーバーヘッドが小さいためである。RFC 1035は、UDPメッセージの最大サイズを512バイトに制限した。これは、当時のMTU（Maximum Transmission Unit）を考慮した設計であったが、DNSSECの導入やIPv6アドレスの増加により、この制限は深刻なボトルネックとなった。

その後、以下のトランスポートプロトコルが追加・拡張されている。

  • TCP（ポート53）: 512バイトを超える応答や、ゾーン転送（AXFR/IXFR）に使用される。RFC 7766（2016年）により、TCPの使用がUDPと同等に必須（MUST）と位置づけられた
  • EDNS0（RFC 6891）: Extension Mechanisms for DNS。UDPメッセージの最大サイズを512バイトから最大65535バイトに拡張する仕組みである。DNSSECの運用にはEDNS0が事実上不可欠であり、EDNS0をサポートしないDNSサーバーは現在では機能不全に陥る
  • DNS over HTTPS（DoH、RFC 8484、2018年）: DNSクエリをHTTPS通信に封入する。通信内容の暗号化により、経路上の盗聴・改竄を防止する。しかし、DoHはDNSトラフィックをHTTPSトラフィックと区別不能にするため、ネットワーク管理者による可視性を消失させる。ISPや国家によるDNSフィルタリングを回避できる反面、企業や国家のセキュリティポリシーの適用を困難にする
  • DNS over TLS（DoT、RFC 7858、2016年）: DNSクエリをTLSで暗号化する。専用のポート853を使用するため、DoHと異なり通常のHTTPSトラフィックと区別可能である。ネットワーク管理者がDNSトラフィックを識別しつつ暗号化の恩恵を受けられる設計であるが、逆に言えば国家による検閲・ブロッキングが容易でもある
  • DNS over QUIC（DoQ、RFC 9250、2022年）: QUICプロトコル上でDNSクエリを伝送する。TCPのハンドシェイクとTLSのハンドシェイクを統合し、接続確立の遅延を最小化する

DoHの設計は、技術的には通信のプライバシーを強化するが、政治的には複雑な含意を持つ。DoHが主要ブラウザ（Chrome、Firefox）にデフォルトで組み込まれることにより、DNSクエリはGoogleやCloudflareのサーバーに集約される。暗号化によって経路上の監視は困難になるが、終端のリゾルバ運営者（アメリカ企業）は依然としてすべてのクエリを把握できる。DoHは、ISPや国家政府からアメリカのテック企業へとDNSデータの支配権を移転する技術であると批判されている。

DNSSEC——検証システムの設計と限界

信頼の連鎖（Chain of Trust）

DNSSEC（DNS Security Extensions）は、DNS応答の完全性（改竄されていないこと）と真正性（正当な権威サーバーからの応答であること）を暗号学的に検証するための拡張仕様である。RFC 4033・4034・4035（2005年）で定義され、その後RFC 5155（NSEC3）、RFC 6840（明確化）などで補完されている。

DNSSECは、公開鍵暗号に基づく信頼の連鎖（Chain of Trust）を構築する。その仕組みは以下の通りである。

  1. ゾーン署名鍵（ZSK: Zone Signing Key）: 各ゾーンの管理者がゾーン内のリソースレコードセットにデジタル署名を付与するために使用する鍵対。署名はRRSIGレコードとして公開される
  2. 鍵署名鍵（KSK: Key Signing Key）: ZSKの公開鍵（DNSKEYレコード）に署名するために使用される、より強力な鍵対。KSKは長期間使用されるため、鍵長が長く設定される
  3. DSレコード（Delegation Signer）: 子ゾーンのKSKのハッシュ値を親ゾーンに登録するレコード。これにより、親ゾーンが子ゾーンの鍵を「保証」する委任署名の連鎖が形成される
  4. トラストアンカー: 信頼の連鎖の起点。DNSSECにおけるトラストアンカーはルートゾーンのKSKである

この連鎖を具体的に示す。www.example.jpのAレコードを検証する場合:

  • example.jpのZSKがwww.example.jpのAレコードに署名（RRSIG）
  • example.jpのKSKがexample.jpのZSK（DNSKEY）に署名（RRSIG）
  • .jpゾーンにexample.jpのKSKのハッシュ（DSレコード）が登録されている
  • .jpのZSKがこのDSレコードに署名（RRSIG）
  • .jpのKSKが.jpのZSK（DNSKEY）に署名（RRSIG）
  • ルートゾーンに.jpのKSKのハッシュ（DSレコード）が登録されている
  • ルートのZSKがこのDSレコードに署名（RRSIG）
  • ルートのKSKがルートのZSK（DNSKEY）に署名（RRSIG）
  • ルートのKSKはトラストアンカーとして、リゾルバにあらかじめ設定されている

すべての信頼の連鎖はルートゾーンのKSKに帰着する。DNSSECは技術的にはDNS応答の改竄を検知する優れた仕組みであるが、その信頼モデルはルートゾーン——すなわちアメリカが管理する単一の信頼起点——に完全に依存している。

ルート鍵署名式典（Root KSK Ceremony）

DNSSECのトラストアンカーであるルートKSKの管理は、ルート鍵署名式典（Root KSK Ceremony）と呼ばれる厳格な手続きによって行われる。この式典は、ICANNが運営する2つの鍵管理施設——アメリカ東海岸のカルペパー（バージニア州）と西海岸のエルセグンド（カリフォルニア州）——で実施される。

式典の手順は以下の通りである。

  • TCR（Trusted Community Representative）と呼ばれる7名の「鍵の守護者」が世界各国から選出されている。各施設にそれぞれ7名、合計14名が存在する
  • 式典を開催するには、最低3名のTCRが物理的に施設に出席する必要がある
  • TCRはそれぞれHSM（Hardware Security Module）を起動するためのスマートカードを保持している
  • HSM内に格納されたルートKSKの秘密鍵を使用して、ルートゾーンのZSKに署名を行う
  • 式典の全過程はビデオで記録され、独立した監査人が立ち会う

この手続きは、ルートKSKの管理がいかに厳重であるかを示すものであるが、同時に以下の事実も示している。

  • 鍵管理施設は2つともアメリカ国内にある: カルペパーはCIA本部に近いバージニア州北部に、エルセグンドはロサンゼルス国際空港に隣接するカリフォルニア州に所在する。DNSSECの信頼の根幹を成す物理的インフラは、完全にアメリカの領土内にある
  • HSMはアメリカ企業の製品: 鍵管理に使用されるHSMは、セキュリティ上の理由から具体的な機種は非公開であるが、アメリカのセキュリティ業界の製品が使用されている
  • ICANNが式典を運営する: 前述の通り、ICANNはカリフォルニア州法人である

DNSSECは「DNSに信頼を追加する」仕組みとして技術的には高く評価されているが、その信頼の究極的な根拠はアメリカの物理的管轄下にある2つの施設に格納された暗号鍵である。DNSSECは、DNSの中央集権的な権力構造を解消するものではなく、むしろ暗号学的に正当化する仕組みであると言える。

DNSSECの不存在証明——NSEC/NSEC3

DNSSECのもう一つの技術的に興味深い側面は、「ドメインが存在しない」ことを証明する仕組みである。通常、「存在する」ことの証明は署名によって容易に行えるが、「存在しない」ことの証明は自明ではない。

  • NSEC（Next Secure、RFC 4034）: ゾーン内のドメイン名を辞書順にソートし、隣接する2つの名前の間に他の名前が存在しないことを署名付きで証明する。しかし、NSECにはゾーン内の全ドメイン名を列挙できてしまうゾーン列挙攻撃（zone walking）の脆弱性がある。攻撃者はNSECレコードの連鎖をたどることで、ゾーン内のすべてのドメイン名を取得できる
  • NSEC3（RFC 5155）: ゾーン列挙攻撃への対策として、ドメイン名をSHA-1ハッシュで変換してからソートする。これにより、NSECレコードからドメイン名を直接読み取ることが困難になる。ただし、ハッシュの逆算（レインボーテーブル攻撃）により、短いドメイン名については依然として列挙可能である
  • NSEC5（提案段階）: NSEC3の限界を克服するため、検証可能ランダム関数（VRF）を使用する提案がなされているが、標準化には至っていない

RFC規格体系の全容

DNSの技術仕様は、IETF（Internet Engineering Task Force）が発行するRFC（Request for Comments）文書群によって定義されている。主要なRFCの系譜は以下の通りである。

  • RFC 882/883（1983年）: DNSの最初の仕様。モカペトリスによる原設計
  • RFC 1034/1035（1987年）: 現行DNSの基本仕様。RFC 882/883を全面改訂したもの。40年近く経った現在も、DNSの根幹を定義する文書であり続けている
  • RFC 1123（1989年）: インターネットホストの要件。DNSに関する運用上の明確化を含む
  • RFC 1995（1996年）: 差分ゾーン転送（IXFR）。ゾーンデータの効率的な同期を可能にする
  • RFC 1996（1996年）: DNS NOTIFY。ゾーンの変更をセカンダリサーバーに即座に通知する仕組み
  • RFC 2136（1997年）: 動的更新（Dynamic Update）。プログラムからDNSレコードを動的に追加・削除する機能
  • RFC 2181（1997年）: DNS仕様の明確化。複数のRFCにまたがる曖昧さや矛盾を解消
  • RFC 2535（1999年）: DNSSEC（初版）。暗号学的検証の初期仕様であったが、運用上の問題が多く、RFC 4033-4035で全面的に置き換えられた
  • RFC 4033/4034/4035（2005年）: DNSSEC（現行版）。署名・検証の完全な仕様
  • RFC 5155（2008年）: NSEC3。ゾーン列挙攻撃への対策
  • RFC 6891（2013年）: EDNS0。DNSメッセージサイズの拡張
  • RFC 7858（2016年）: DNS over TLS
  • RFC 8484（2018年）: DNS over HTTPS
  • RFC 8624（2019年）: DNSSECのアルゴリズム実装要件
  • RFC 9250（2022年）: DNS over QUIC

IETFは形式上「オープンな標準化団体」であるが、その参加者の多くはアメリカの企業・大学・政府機関の技術者であり、RFCの起草・レビュー・承認プロセスにおいてアメリカの影響力は圧倒的である。DNSの技術仕様を策定する権限そのものが、アメリカの技術コミュニティに集中しているのである。

リアリズムの観点からの分析

リアリズムの視点から分析すれば、DNSをめぐる国際政治は以下の構造を持つ。

  • 情報空間における一極支配: ケネス・ウォルツの構造的リアリズムに基づけば、国際システムは極の数によって安定性が決まる。DNSの管理構造は、情報空間における完全な一極支配（アメリカのユニラテラリズム）の典型であり、他国はこの構造の下で自国のデジタル的存在をアメリカの善意に委ねている状態にある。これは主権国家として許容し得る状態ではない
  • インフラ支配は軍事支配の代替手段: 大英帝国が海上交通路（シーレーン）の支配を通じて世界覇権を維持したように、アメリカはDNSを含むインターネットインフラの支配を通じて、21世紀の情報覇権を維持している。DNSのルートゾーンは、現代における「スエズ運河」や「パナマ運河」に相当する戦略的チョークポイントである
  • 「技術的中立性」というイデオロギー: ICANNが掲げる「技術的中立性」は、アメリカの覇権を維持するためのイデオロギー装置として機能している。「政治を技術に持ち込むな」という主張は、既存の権力構造を「自然なもの」として固定化する効果を持つ。現状維持こそがアメリカにとって最も有利な結果であり、「中立」の名の下に維持されるのはアメリカの支配にほかならない

各国の対抗戦略と代替DNS

アメリカのDNS覇権に対し、複数の国家および技術コミュニティが対抗策を講じている。

  • 中国: グレート・ファイアウォールの内部で独自のDNSインフラを運用し、国内のDNSクエリが外国のサーバーに流出することを防いでいる。2020年には、北京に独自の「DNSルートサーバー」のミラーを設置し、アメリカのルートサーバーへの依存を軽減する措置を講じた
  • ロシア: 2019年の「主権インターネット法」に基づき、ロシア国内で独立して機能するDNSインフラの構築を推進している。2021年には、ロシア国内のインターネットをグローバルなDNSから切り離す実験を実施した。これは、アメリカがロシアを「デジタル的に切断」しようとした場合に備えた、防衛的措置である
  • EU: DNS4EUプロジェクトとして、EU独自のパブリックDNSリゾルバの構築を進めている。GoogleやCloudflareへの依存からの脱却を目指す動きであるが、ルートゾーンの管理権限そのものへの挑戦には至っていない
  • ITU（国際電気通信連合）への移管論: ロシアと中国を中心に、DNSの管理をITUのような国連機関に移管すべきだとする主張が繰り返されている。アメリカはこれを「インターネットの自由を脅かす」として一貫して拒否しているが、真の理由は覇権の喪失への危機感にほかならない

日本への示唆

日本は、DNSに関する主権的能力をほぼ完全に欠いている。日本の国別TLDである.jpはJPRS（日本レジストリサービス）が管理しているが、.jpドメインの存在そのものは、アメリカが管理するルートゾーンに登録されていることに依拠している。理論上、ルートゾーンから.jpが削除されれば、日本のドメインは世界から到達不能になる。

さらに、日本の政府機関・企業の多くが.comや.orgなどのgTLD（ジェネリックTLD）を使用しており、これらはすべてアメリカ企業が管理するレジストリに依存している。日本国内のDNSリゾルバもGoogle Public DNSやCloudflareに依存するケースが増加しており、日本国民のインターネット閲覧行動がアメリカ企業のサーバーを経由する構造が常態化している。

日本が真の国家主権を回復するためには、軍事的独立（米軍撤退）、偽日本国憲法の破棄と新日本国憲法の制定と並んで、デジタル主権の確立が不可欠である。独自のDNSインフラの整備、国内DNSリゾルバの普及、暗号化DNS（DNS over HTTPS、DNS over TLS）の国内運用基盤の構築は、情報主権を守るための最低限の措置として位置づけられなければならない。

参考文献

関連項目

「https://hoshupedia.org/index.php?title=DNS&oldid=656」から取得