Comment Sought on DNS Root Zone Glue Policy
翻訳文
社団法人日本ネットワークインフォメーションセンター
最終更新2007年2月22日
この文書は2006年12月5日に公開された
http://www.icann.org/announcements/announcement-3-05dec06.htm
を翻訳したものです。
JPNICはこの翻訳を参考のために提供しますが、その品質に責任を負いません。
DNSルートゾーングルーポリシーに関するコメントを募集
2006年12月5日
米国政府との契約に基づく義務に従いICANNが機能を遂行するThe Internet Assigned Numbers Authority (IANA)は、 DNSルートにおけるトップレベルドメインの委任に責務を負っています。
IANAは、一般に『グルー』として知られる、 ルートゾーン内のIPアドレス情報をどう維持するかに関する方法についてレビューを行おうとしています。
背景
DNSルートゾーンへの変更の管理において、各トップレベルドメイン運用者は、 ルートゾーンにグルーレコードを挿入できるよう、 IANAに権威ネームサーバの一覧をIPアドレスと共に提供します。 グルーの目的は、 RFC1034 の中で、section 4.2.1.以降で定義されています。
DNSにおける権威ネームサーバのIPアドレス(あるいはIPアドレス群)の表示は、 そのホストについて権威あるゾーンにおいて特定されたIPアドレス、 そしてそれがグルーとして一覧化されたものと一致しなければなりません。 グルーデータに一貫性が無いとDNSの技術的な不安定をもたらし得ます。
IANAは、 トップレベルドメイン運用者が変更のリクエストについて正しいグルーデータを提出することに依存しています。 IANAは、 新たに提案されたIPアドレスが適切な技術テストを通過することを確認します。 このテストが完了したならば、 そのドメインの管理担当者および技術連絡担当者は変更を承認しなければならず、 承認されたならば、 IANAはルートゾーンのグルーデータの修正を行うか、あるいは挿入を行います。
状況によっては、 権威ネームサーバは二つ以上のトップレベルによって共有されています。 こうした状況では、もしグルーデータを変更しようとする動きがあった場合、 IANAは影響を受ける全てのトップレベルドメインの運用者に変更に積極的に同意するよう要請することにより、 用心深く交渉を行います。
実際のところは、この手続きは、 ルートゾーンデータへの幾つかの変更への厳しい妨害となりました。 権威ネームサーバの中には、 30以上の異なるトップレベルドメインによって共有されているものもあります。 それらのグルーデータへの変更は、 恐らくは60名に上るそれらのドメインの管理担当者および技術連絡担当者それぞれからの積極的な同意を必要とします。 そのグループの中で無反応だったトップレベルドメイン管理者が一人でもいれば変更はできなくなるのであり、 そして実際、こうしたことは何回も起こっています。 IANAのスタッフは、これらの状況を解決するために最善を尽くしていますが、 通常これは何ヶ月にもおよぶリサーチと相当な干渉を生じます。
TLD運用者の注意義務
現行の能動的な承認では、 TLD運用者がその権威ネームサーバのうちの一つがリナンバされることを完全に認識していることを求めています。 これは、彼らにとって、彼らがサービスの継続性を保障するために必要な、 可能な設定変更を特定する機会となっています。 この役割を変更するには、TLD運用者における影響や、 彼らに影響する差し迫った変更をTLDに通知する IANAの注意義務とは何であるかを検討する必要があります。
可能なアプローチ
挙げられた可能なアプローチのうち幾つかには以下が含まれています。
同じアプローチを維持する。 IANAは、これが望ましいとは考えていませんが、 コミュニティは現行のアプローチは維持するのにふさわしいものだと感じているかも知れません。
受容閾値を下げる。 すべての管理担当者および技術連絡担当者の承認を必要とする代わりに、 求められる管理担当者および技術連絡担当者を最小限のものとする、 あるいは閾値を100%よりも低い値とすることが可能です。 例えば、仮に基準は、 『影響を受ける2つのTLD運用者のいずれかの管理および技術的な連絡先あるいは、 影響を受けるTLD運用者の20%のいずれか高い方から承認されなければならない』 となり得るかも知れません。
義務的な考慮・猶予期間への変更を認める。 受容基準が満たされたならば、 もしそれが影響を受ける当事者の100%により受け入れられなかった場合には、 ルートゾーンに変更が加えられる前に必要な変更を行うよう、 IANAは全ての管理および技術的な連絡先に対して変更の内容を通知し、 一定の期間(つまり30日)を付与することができます。
ネームサーバの運用者をプロセスの参加者として組み込む。 変更は、申請がなされ、ドメインの管理および技術的な連絡先と調整されます。 これらは、 必ずしもドメインの権威ネームサーバを運用する者と同じ当事者とは限りません。 これらの運用者は、 そのようなアプローチが現行の運用からの根本的な乖離となるものの代わりに変更を認めることはできますが、 これらの当事者を認証するIANAの手続き同様、 これらの運用者の役割や責任について取り扱う新たな手続きを必要とします。
この一覧は網羅的なものではなく、 IANAは実行可能な解決策におけるどのような意見も歓迎いたします。 DNSルートゾーンへの定期的な変更に関連するプロセスを自動化しようとする IANAの活動に沿う、自動化が可能な解決策については、特に評価されます。
参考となる質問事項
- IANAは、ルートゾーングルー(一般的な、あるいは特に共有されるグルーのいずれも)への変更の要請をどのように受け付けるべきでしょうか？
- 共有されるルートゾーンの変更の承認にはどのような基準が用いられるべきでしょうか？
- 影響を受ける当事者が変更に異議を唱える場合、この対立はどのようにして解決されるべきで、その場合でもどのような根拠により変更を進めることができるでしょうか？
- 共有されるネームサーバをリナンバした結果で予想外だったもののうち、まだ検討されていないものはあるでしょうか？
提示された質問事項あるいは一般的な課題のいずれについてのコメントも、 root-glue-comments@icann.org にemailを送ることにより提出することができます。 コメントは、 http://forum.icann.org/lists/root-glue-comments/ で見ることができます。
コメント期間は、2007年1月31日まで継続されます。 このコメント期間の終了時に、スタッフはコメントについて報告を行い、 推奨される運用手続きが策定されます。
参考
グルーの技術的問題を明確化しようとするドキュメントは、 現在IETFの中で作成されています。 これは現在ドラフト中ですが、 この議論において有益なものであることが分るかも知れません。 現在のドラフトは以下で見ることができます。 http://www.ietf.org/internet-drafts/draft-koch-dns-glue-clarifications-02.txt
