DNSルートサーバーの要件定義 -RFC7720(BCP40)の紹介-
dom_gov_team ICANN技術政策文書今回はIETFが公開しているBCP140ことRFC77202について説明します。RFC7720はDNSルートサーバーが満たすべき最小要件を定めた文書です。
実は、RFC7720とは別にRSSAC0013という文書も公開されています。これはDNSルートサーバー運用者(RSO: Root Server Operator)に対する推奨事項をまとめたもので、ICANN内のRoot Server System Advisory Committee(RSSAC: ルートサーバーシステム諮問委員会)によって作成されています。RSSAC001は2015年の公開後、改訂を経て2023年にRSSAC001v2が発行されました4。現在はさらに変更を加えたRSSAC001v3の公開に向けて協議が進められています。今回の改訂ではRSSAC001の本文内でRFC7720への言及箇所を増やすことが大きな変更点となる見込みです。
そこで、今回はRFC7720の内容とRSSAC001との関係性について説明していきます。
RFC7720の内容
はじめに
[RFC2870]5はインターネットのDomain Name System(DNS) [RFC1035]6のルートネームサーバーのプロトコル要件と運用要件について説明していました。公開以降、プロトコル要件と運用要件の両方が進化してきています。よって、現在では二つの要件セットを個別のドキュメントに分離する方が理にかなっています。このドキュメントではプロトコル要件と一部の展開要件のみを定義しています。[RFC2870]で定義されていた運用要件は削除されました。運用要件に関してはICANNのRoot Server System Advisory Committee(RSSAC: ルートサーバーシステム諮問委員会)によって定義され、[RSSAC001]に文書化されています。
ルートサーバーは[RFC2826]7で定義される一意のルートゾーン(“.”)の権威サーバーです。現在これらはroot-servers.netゾーンも提供しています。また、一部のサーバーは[RFC3172]8に示された .arpaトップレベルドメインのゾーンも提供しています。このドキュメントではサービスのプロトコル観点からルートネームサーバーの外部インターフェースについて説明します。これはパブリックインターネット上でルートネームサービスとやり取りする際に、DNSクライアントが満たすべき基本的な要件を定めています。
なお、[RFC2870]は廃止され、このドキュメントと[RSSAC001]が機能的に[RFC2870]を置き換えます。
プロトコル要件
プロトコルの最小要件について説明します。運用上の詳細は[RSSAC001]に文書化されています。
ルートネームサービスは
- コアDNS [RFC1035]9とDNSの補足規定 [RFC2181]10を実装する必要があります。
- DNSクエリおよび応答に対してIPv4 [RFC791]11とIPv6 [RFC2460]12のトランスポートをサポートする必要があります。
- DNSクエリおよび応答に対してUDP[RFC768]13とTCP[RFC793]14のトランスポートをサポートする必要があります。
- UDPデータグラムを送信する際にはチェックサムを生成する必要があり、ゼロ以外のチェックサムを含むUDPデータグラムを受信した際にはチェックサムを検証する必要があります。
- 権威ネームサーバーとしてDNSSEC[RFC4035]15を実装する必要があります。
- DNSの拡張メカニズム(EDNS(0))[RFC6891]16を実装する必要があります。
展開要件
ルートネームサービスは
- [RFC1122]17に準拠し有効なIPアドレスを持つ任意のエンティティからのクエリに対して必ず応答する必要があります。
- [RFC2826]で定義される一意のルートゾーンを提供する必要があります。
セキュリティ上の留意点
このドキュメントは新たなプロトコルを示しているものではありません。しかし、[RFC2826]で論じられているようにルートネームサービスはインターネットアーキテクチャの主要コンポーネントであり、インターネット全体のセキュリティにおいて重要な役割を果たしています。
DNSプロトコルに関する具体的なセキュリティに関する留意点はそれぞれの仕様書で説明されています。ルートネームサーバーの運用面におけるセキュリティ上の留意点については[RSSAC001]で説明されています。
RSSAC001とRFC7720の関係性
RFC7720本文内で記述されていたように、以前はルートサーバーの技術要件だけでなく運用要件などについてもRFC2870で示されていました。しかしルートサーバーシステムを取り巻く技術や運用形態の変化に伴い、技術側面についてはRFC7720で、運用側面についてはRSSAC001で要件や推奨事項を指定し直し、RFC2870は廃止されました。
RFC7720はIETFから公開されているドキュメントですが、RSSAC001の発行元はICANN内の組織でルートサーバーシステムの運用・運営管理・セキュリティ・完全性に関して助言を行うRSSACです。つまり、発行元の組織が異なります。IETFはインターネット技術の標準化などを行う技術コミュニティであり、ICANNはドメイン名やIPアドレスなどのインターネット上の資源に関する調整・管理を行う組織であると考えると、発行元の違いにも納得がいくのではないでしょうか。
また、二つのドキュメントのスタンスの違いについて、原文を見ながら確認してみましょう。
RFC7720では以下のような形で要件が示されています。
The root name service:
o MUST implement core DNS [RFC1035] and clarifications to the DNS [RFC2181].
(以下略)
一方で、RSSAC001v2では以下のように推奨事項が記述されています。
[E.3.1-A] Each RSO is expected to publish operationally relevant details of their infrastructure, including service-delivery locations, addressing information and routing (e.g., origin autonomous system) information.
(以下略)
注目していただきたいのは主語と助動詞・動詞です。RFC7720は主語が”The root name service”で、助動詞としてMUSTが使われています。RFCにおけるMUSTは仕様における絶対的な要件を示す18ため、DNSルートサーバーの相互運用性を保証するための最小条件を提示しているといえます。次に、RSSAC001v2を確認してみましょう。提示した例文では主語がRSO、動詞はis expectedとなっており、今回記載していない他の推奨事項に関してもほぼ同じ形で記述されています。つまり、提示された事項は強制力を伴う規則ではなく、あくまでRSSACの提示するRSOに対する推奨事項であるというスタンスが文章の形式にも表されているといえるでしょう。
まとめ
今回はRSSAC001の改訂にあたって、大きく取り上げられる予定のRFC7720について、その内容とRSSAC001との関係性を紹介しました。RFC7720では、DNSルートサーバーが破綻することなく継続して機能するための最小要件が定義されています。一見すると当然の内容に思えるかもしれませんが、こういった要件を明文化することによって、世界中に分散配置されたルートサーバーインスタンスが同様の機能を提供できるようになっていると考えられます。また、DNSルートサーバーの運用に関するRSOへの推奨事項をまとめた RSSAC001がv3へ改訂されることで、より高い正確性や可用性を備えたルートネームサービスの実現に繋がっていくことが期待されます。