Loading article…
DNSルート ゾーンは、インターネットのドメイン ネーム システム (DNS) の階層型名前空間における最上位の DNS ゾーンです。
2016年10月1日まで、ルートゾーンはインターネット番号割当機関（ICANN）によって監視されていましたが、ICANNは、その管理をインターネット番号割当機関（IANA）として機能する子会社に委任していました。[1]配布サービスはVerisignによって提供されています。これ以前は、ICANNが米国商務省の機関である国家電気通信情報局（NTIA）の監視下で管理責任を担っていました。[2]監視責任は、ICANNのガバナンス構造内に代表される世界的な利害関係者コミュニティに移行しました。
DNS定義と特定のプロトコルの制限、つまり断片化されていないユーザーデータグラムプロトコル[2]（UDP）パケットの実際のサイズの組み合わせにより、DNS名前クエリ応答で収容できるルートネームサーバーアドレスの実際の最大数は13になりました。ただし、ルートゾーンは多くの国の130を超える場所にある数百のサーバーによってサービスされています。[3] [4]
DNSサービスの初期化
DNSルートゾーンは、インターネットのトップレベルドメインへのクエリに対して権限を持つ13のルートサーバークラスターによって提供されます。 [5] [6]したがって、すべての名前解決は、ルートサーバーへのクエリから開始されるか、ルートサーバーから一度取得した情報を使用します。
ルートサーバークラスタの正式名称は、a.root-servers.netからm.root-servers.netです。[6]これらの名前をアドレスに解決するには、DNS リゾルバはまずネットゾーンの権威サーバーを見つける必要があります。この循環依存を回避するには、DNS へのブートストラップアクセス用に少なくとも 1 つのルートサーバーのアドレスを知っておく必要があります。このため、オペレーティングシステム、DNS サーバー、またはリゾルバソフトウェアパッケージには通常、DNS ルートサーバーのアドレスがすべて含まれたファイルが含まれています。一部のルートサーバーの IP アドレスが変更された場合でも、すべてのネームサーバーの現在のリストを取得するには少なくとも 1 つのファイルが必要です。このアドレスファイルは、BINDネームサーバーリファレンス実装ではnamed.cacheと呼ばれています。現在の公式バージョンは、 ICANNのInterNICによって配布されています。[7]
機能している単一のルート サーバーのアドレスを使用すると、他のすべての DNS 情報を再帰的に検出でき、任意のドメイン名に関する情報を見つけることができます。
冗長性と多様性
ルート DNS サーバーはインターネットの機能に不可欠です。ワールド ワイド ウェブや電子メールなど、ほとんどのインターネット サービスはドメイン名に基づいているためです。DNS サーバーは、インターネット全体の潜在的な障害ポイントです。このため、複数のルート サーバーが世界中に分散されています。[8] 512 オクテットの DNS パケット サイズは、プロトコル拡張 ( DNS の拡張メカニズムを参照) によってこの制限が解除されるまで、DNS 応答のアドレスを 13 に制限していました。[9]ラベル圧縮を使用すると、このサイズのパケットにさらに多くのエントリを収めることができますが、13 が信頼性の高い制限として選択されました。 IPv4の後継インターネット プロトコルであるIPv6の導入以降、以前の慣行は変更され、余分なスペースが IPv6 ネーム サーバーで埋められています。
ルートネームサーバーは、トラフィック負荷に対応するために高帯域幅アクセスを備えた複数の安全なサイトでホストされています。当初、これらのインストールはすべて米国にありました。しかし、分布は変化し、現在はそうではありません。[10]通常、特定のサイトの各DNSサーバーインストールは、負荷分散ルーターを備えたコンピューターのクラスターです。[9]サーバー、その場所、およびプロパティの包括的なリストは、https：//root-servers.org /で入手できます。2023年6月24日現在[アップデート]、世界中に1708台のルートサーバーがありました。[11]
最近の傾向としては、エニーキャストアドレスとルーティングを使用して、広範囲の地理的領域にわたって復元力と負荷分散を提供することです。たとえば、Verisignが管理するj.root-servers.netサーバーは、世界中にある 104 台 (2016 年 1 月現在) の個別のサーバーシステムで構成されており、エニーキャストアドレスを使用してクエリを実行できます。[12][アップデート]
管理
インターネット ルート ゾーン ファイルの内容は、 Internet Assigned Numbers Authority (IANA) 機能を実行する ICANN の子会社によって調整されます。Verisignはゾーン ファイルを生成し、さまざまなルート サーバー オペレータに配布します。
1997年、インターネットが米国政府の管理から民間の手に移管されたとき、NTIAはルートゾーンの管理を担った。1998年の商務省の文書には、同機関は2000年までに「民間部門がDNS管理のリーダーシップを取れるように移行することを約束する」と書かれていたが、移行を実現するための措置は取られなかった。2014年3月、NTIAは管理を「グローバルな利害関係者コミュニティ」に移行すると発表した。[5]
商務省通信情報担当次官ローレンス・E・ストリックリング氏によると、2014年3月はグローバルインターネットコミュニティへの役割の移行を開始するのに適切な時期だった。この動きは、米国とその同盟国が監視を行っていたという暴露の余波による圧力を受けて行われた。しかし、ICANNの会長は両者の関係を否定し、移行プロセスは長い間続いていたと述べた。ICANN会長ファディ・チェハデ氏はこの動きを歴史的なものと呼び、ICANNはマルチステークホルダー管理へと移行すると述べた。ICANNに所属していないインターネットの歴史上のさまざまな著名人もこの動きを称賛した。[5]
NTIAの発表は、ICANNの役割の遂行方法に直ちに影響を与えることはなかった。[5] [13] 2016年3月11日、NTIAは、ルートゾーンの管理役割を移行するための計画案を受け取り、今後90日以内に検討すると発表した。[14]
この提案は採択され、ICANNのIANA機能を実行するための更新契約は2016年9月30日に失効し、その結果、ICANNのガバナンス構造内に代表される世界的な利害関係者コミュニティに監督責任が移行しました。移行計画の一環として、[15] DNSルートゾーンの管理を含むIANA機能を実行するために、Public Technical Identifiers（PTI）と呼ばれる新しい子会社が設立されました。
ルートゾーンのデータ保護
ルートゾーンの署名
2010年7月以来、ルートゾーンはDNSSEC署名で署名されており、[16]ドメインネームシステムの単一のトラストアンカーを提供し、これは他の公開鍵インフラストラクチャ（PKI）のトラストアンカーを提供するために使用できます。ルートゾーンのDNSKEYセクションは、鍵署名式で証人の前で検証可能な方法で実行されるルートゾーン鍵署名鍵で定期的に再署名されます。[17] [18] ID 20326のKSK2017は2020年現在有効です。
ZONEMDレコード
ルートゾーンファイルはDNSSECで署名されていますが、NSレコードなどの一部のDNSレコードはDNSSEC署名でカバーされていません。この弱点に対処するために、RFC 8976でZONEMDと呼ばれる新しいDNSリソースレコードが導入されました。ZONEMDはDNSSECに代わるものではありません。DNSルートゾーンファイルを完全に保護するには、ZONEMDとDNSSECを併用する必要があります。[19] [20]
DNSルートゾーンのZONEMDの展開は2023年12月6日に完了しました。[21]
TLS 経由の DNS
B-Root DNSサーバーはポート853でDNS over TLS (DoT)の実験的なサポートを提供しています。[22]
参照
参考文献
- ^ 「米国政府との契約終了に伴い、IANA 機能の管理がグローバル インターネット コミュニティに移行」 2016 年 10 月 1 日。 2017 年12 月 25 日閲覧。
- ^ ab Jerry Brito (2011 年 3 月 5 日)。「ICANN vs. 世界」Time 誌。
- ^ 「ルートサーバーは13台ではありません」。www.icann.org 。 2018年1月18日閲覧。
- ^ 「世界中の DNS ルート サーバー « stupid.domain.name」。stupid.domain.name。 2021 年 2 月 11 日時点のオリジナルよりアーカイブ。 2018 年1 月 18 日閲覧。
- ^ abcd Farivar, Cyrus (2014年3月14日). 「突然の発表で、米国はDNSルートゾーンの制御を放棄する」Ars Technica . 2014年3月15日閲覧。
- ^ ab 「ルートサーバー」。IANA 。 2020年1月17日閲覧。
- ^ "named.cache". InterNIC. 2015年11月17日. 2015年11月17日閲覧。
- ^ 「SANS Institute InfoSec Reading Room」SANS . 2014年3月17日閲覧。
- ^ ab Bradley Mitchell (2008年11月19日). 「DNSルートネームサーバーが13個しかない理由」About.com。2014年3月18日時点のオリジナルよりアーカイブ。 2014年3月17日閲覧。
- ^ 「DNS ルート サーバー: インターネット上で最も重要なインフラストラクチャ」。Slash Root。2013 年 11 月 15 日。
- ^ “Root Servers Technical Operations Assn”. 2023年6月24日時点のオリジナルよりアーカイブ。2023年6月29日閲覧。
- ^ 「ルートサーバー技術運用協会」。
- ^ 「IANA 移行に関する最新情報」。米国電気通信情報局。2015 年 8 月 17 日。2015年11 月 17 日閲覧。
- ^ Strickling, Lawrence. 「IANA 移行提案の検討」。米国電気通信情報局。米国議会。2016年5 月 26 日閲覧。
- ^ 「インターネット番号割当機関 (IANA) 機能の管理を米国商務省の国家電気通信情報局 (NTIA) からグローバルなマルチステークホルダー コミュニティに移行する提案」(PDF)。2016 年 3 月。
- ^ 「ルート DNSSEC: ルートゾーンの DNSSEC に関する情報」。Internet Corporation For Assigned Names and Numbers。2014年3 月 19 日閲覧。
- ^ 「First KSK Ceremony」。Internet Corporation For Assigned Names and Numbers。2010年4月18日。2015年4月14日時点のオリジナルよりアーカイブ。2014年10月19日閲覧。
- ^ 「ルートKSKセレモニー」。インターネット割り当て番号局。2015年11月12日。 2015年11月17日閲覧。
- ^ Wessels, Duane (2023 年 4 月 18 日)。「ルートゾーンへの ZONEMD 保護の追加」。Verisign ブログ。
- ^ D. Wessels、P. Barber、M. Weinberg、W. Kumari、W. Hardaker (2021年2月)。「RFC 8976 DNSゾーンのメッセージダイジェスト」 。 2024年3月10日閲覧。
- ^ Wessels, Duane (2023 年 12 月 6 日). 「[dns-operations] ルートゾーンの運用に関するお知らせ: ルートゾーン用の ZONEMD の導入」. 2024 年3 月 10 日閲覧。
- ^ 「B-Root が DNS over TLS の実験的なサポートを提供」
- RFC 2870 – ルートネームサーバの運用要件
- RFC 2826 – ユニーク DNS ルートに関する IAB 技術コメント
さらに読む
- 「NTIA、主要なインターネットドメイン名機能の移行の意向を発表」。米国電気通信情報局広報室。2014 年 3 月 14 日。2014年3 月 15 日に閲覧。
{{cite web}}: CS1 メンテナンス: その他 (リンク)
外部リンク
ウィキメディア・コモンズには、 DNS ルートゾーンに関連するメディアがあります。
- ルートゾーンファイル
- ルートサーバー
- IANA の DNS ルートゾーンの TLD の権威データベース
- ICANN ルートサーバーシステム諮問委員会
- CircleID.com、DNSルートサーバー上
- CAIDA.org、ルートサーバーの場所の問題に関する論文
- CircleID.com、米国外のルートサーバーインスタンスが米国内よりも多い
- パブリック DNS サーバーのリストは継続的に検証および更新されます。