Comments Sought on Technical Checks Used for DNS Root Zone Changes
翻訳文

社団法人日本ネットワークインフォメーションセンター
最終更新2006年10月2日

この文書は2006年8月18日に公開された
http://www.icann.org/announcements/announcement-18aug06.htm
を翻訳したものです。
JPNICはこの翻訳を参考のために提供しますが、その品質に責任を負いません。

ICANNがDNSルートゾーンの変更の際の
技術的チェックに対するコメントを募集

2006年8月18日

　米国商務省との契約上の義務に従いICANNが遂行するThe Internet Assigned Numbers Authority（IANA）の機能は、 DNSルートにおけるトップレベルドメインの委任について責務を負っています。

　IANAは、ルートゾーンへの追加を行う際に提供されるデータに対してトップレベルドメインの運用者が行う技術的チェックについて、実装のレビューを行おうとしています。これらのチェックは、権威ネームサーバがDNSの安定性を保つために要求される最低限の基準に達していることを確実にするために設計されています。

　このレビューの目的は、IANAによるテストが、明確かつ客観的で妥当な方法により実装されるようにすると同時に、確実に技術コミュニティの推奨する実装に沿ったものとすることにあります。

背景

　現在、トップレベルドメイン（TLD）の運用者がルートゾーン内に記載されている権威ネームサーバの変更を申請する場合は、その申請に対して正当な管理者が確実に同意しているかの検証をIANAが行っています。この最初の段階で、記載されるネームサーバは様々な特性の有無もテストされます。

　IANAによる申請の検証と評価のプロセスが終了すると、 IANAはネームサーバが正しく設定され、利用可能であることを確認するためにテストを繰り返します。この2回目のテストは、同意を得る際の大きな遅延や、申請を評価する際に費やした時間（TLDオペレータの再委任の場合において）が、ネームサーバの状態に変化を及ぼしていないことを確認するためのものです。

　IANAの運用基準に合致すると、次に申請は米国商務省にレビューのため送られ、ルートサーバネットワークに反映されるべく、最終的にはベリサインに送られます。この段階でベリサインは、ルートゾーンへの実装の前に追加的に独自のチェックを行います。

　テストは大きく分けて二つのカテゴリーに分類されます。一つは必須要件であり、ネームサーバはそのプロパティを提示する必要があります。さもなければ申請は却下されます。もう一つは推奨要件であり、申請が正しいのかどうかIANAと申請者との間で対話を行うことです。ここでの必須要件は、権威ネームサーバ群の重要な特性をチェックするためのものです。一方、推奨要件はその申請が何らかの形かで不完全であるかもしれない兆候に関するものです。

　IANAが現在行っているテストは以下のとおりです：

1. ネームサーバの最低数: 少なくとも、最低2つのネームサーバが提供されなければならず、それらは同じIPアドレスを共有してはならない。
2. ネームサーバの最高数: 供給されるネームサーバの数は、13を超えてはならない。
3. ホストネームの妥当性: 権威ネームサーバに与えられるホストネームは、ラベルが63オクテットを超えない完全ドメイン名でなければならない。
4. ネームサーバの到達性: 供給される権威ネームサーバは、パブリックなインターネット上で検証可能な到達性を持たなければならない。IANAは、トップレベルドメインのSOAレコードに対しUDPのDNSクエリを送り、DNSの応答を待つ。IANAはアメリカの設備からクエリを送り、失敗した場合はヨーロッパ及びアジア太平洋のサイトからテストを行う。IANAがどのサイトからもDNSの応答パケットを受け取れなかった場合、もしくはテストを行っているIPアドレスが限られた接続性しか持たず信頼に欠けるように見える場合は、IANAは申請者の状況を明確にする。
5. ネームサーバの権威: トップレベルドメインのSOAレコードに対するクエリについては、供給される個々の権威ネームサーバは"AA"ビットが立った状態でDNS応答しなければならない。
（参照：RFC1035、Section 4.1.1）
6. ネームサーバの一貫性: IANAは申請のあったネームサーバが、子にセットされたNS資源レコードと一致しているかをチェックする。IANAは権威ネームサーバから返されたNS資源レコードへのクエリを行い、ルートゾーンに与えられたNSレコードと比較を行う。
7. グルーとホスト名との一貫性: IANAは権威ネームサーバのA及びAAAAレコードをチェックし、ルートゾーン内のグルーレコードと比較する。これらは一致しなければならない。
8. グルーと、既存のグルーとの一貫性: IANAは、申請がネームサーバのIPアドレスを変更するものである場合、他のトップレベルドメインが当該グルーを使用していないかチェックする。ネームサーバのホスト名が共有されていた場合、それ自体は技術的には問題ないが、IANAは申請者に対して、影響を受ける全ての当事者の同意を得て当該申請を進めるか否かのチェックを行うために対話を始めるよう、助言している。
（注：この実装は、これとは別に近々出されるIANAディスカッションペーパーの対象です。）
9. シリアル番号の一貫性: IANAはそれぞれの権威サーバのSOAレコードのシリアル番号をチェックする。これらは一致しなければならない。
10. 最小限のネットワーク冗長性: IANAは、ネームサーバは地理的にもネットワークトポロジ的にも分離されたネットワーク上に配されるよう要請する。IANAは現在、申請者がネットワークを構築する際に、全てのネームサーバが同じ/24のIPv4アドレスレンジにあるかどうかを問い合わせることで、緩やかな形でテストを行っている。
11. ネームサーバの継続性: 申請がルートの各NSレコードを完全に変更するようなものである場合、IANAは申請者に対し、不慮の障害が軽減されるよう、申請を2回に分けて行うことを検討するよう要請する。

　ベリサインは、プライマリルートネームサーバに対してIANA承認済みの変更を反映させる実装者の役割として、 IANAがその手続き内ではテストされなかった以下の特性について、追加的にテストを行います。

ネームサーバが（IPv4とIPv6双方において）同じPTRレコードを持っているか。
ネームサーバがRFC1918に則ったアドレスを保持していないか。（注：そうしたアドレスが与えられると、到達性が無いためIANAのテストに通常は通りません。）
IPアドレスが予約済みIPアドレスのリストに掲載されていないか。
ネームサーバのIPアドレスの最終オクテットが0あるいは255ではないか。
ネームサーバのホストネーム全体の長さが128文字より少ないか。

　IANAによるテストは、申請者の潜在的な問題を明確化することにより、警告の意味でエラーを起します。この議論の後、IANAは基本的に、問題を起すことが明らかでない限り、管理者が申請したとおりの変更を行うと主張することを認めています。しかしながら、実際には、殆ど全てのケースにおいて、申請者が進んで修正する設定上の問題でした。中には、申請者が、彼ら自身既に気付いている問題であるものの、申請が実装されるまでは修正する立場にないと明らかにしたケース（TLDの完全な再委任や、技術運用者の変更など）もありました。

　検討すべき関連事項は以下のとおりです：

IANAのルートゾーン管理プロセスの要素は、自動化できない限り手動で行う必要がありますが、自動化に向けた努力の一環としてIANAは技術的テストを自動化して行えるよう目指しています。運用者が規定の遵守のため自動化されたテストを行ったり、客観的基準に対して独自のテストを行ったりする能力は、非常に貴重なものです。
応答のサイズの計算や、それが特定のサイズ（つまり512バイト）に収まっていることや、権威ネームサーバが再帰検索不可に設定されているか等、技術的なチェックで追加されるべきものがあるかも知れません。
ネットワークの冗長性テストが維持されるのであれば、そのテストのため、もしかするとネットワークのASパスのテストを含む、より適切なメカニズムを探りたいと思います。
IANAは、IANAの技術的要件を、ベリサインといった他の当事者のそれと理想的には調和させ、要件の差異によって不必要な遅れが出ないようにしたいと思っています。
IANAは変更の申請があって初めてテストを行います。規定を遵守しているかどうかのテストは現在行っていません。
現在の手続きの下では、あるネームサーバへの変更は別のネームサーバに欠陥があった場合、変更を止めることが可能となっています。これは欠陥のあるサーバが既にルートゾーンに記述されており、申請によって変更が加えられない場合も同様です。

　これらを念頭に置いて、 IANAはルートゾーンにデータを投入する際にどのような技術的基準が要求されるべきか、また、それらの基準に合致していることをどうテストすれば良いかについて、コミュニティからの助言を求めています。

　参考となる質問事項：

DNSルートにおける変更が受け入れられるためには、TLD運用者が従うべき技術的基準のうちどのようなものが義務的であるべきでしょうか？
技術的なレビューの過程において、どの問題を警告として強調されるべきでしょうか？
TLD運用者がそれでも進めたいと考えた場合、これらの警告が発せられるのはどのような状況下においてでしょうか？
こうした技術要件は、自動的な環境においてはどのように実行されるべきでしょうか？
最低限の技術標準に準拠しているかどうかについて、TLD運用者が行う継続的な遵守に関する検証において、IANAにもし果たすべき役割があるとしたら、それはどのようなものでしょうか？

　techcheck-comments@icann.org 宛にメールを送ることにより、コメントを提出することができます。コメントは、 http://forum.icann.org/lists/techcheck-commentsで見ることができます。

　コメント期間は、2006年9月30日までです。