## page was renamed from DNSSEC/移転手順 ## page was renamed from DNS/DNSSEC/移転手順 == DNS/DNSSEC/移転手順 == DNSSEC対応ドメインはDNSプロバイダ(兼レジストラ）を移転できないと思った方がいい。 　つまり、自前でDNSサーバを用意できないドメインはDNSSECを使うとしたら 　　ずっと特定のレジストラ/プロバイダと付き合い続ける 　という覚悟が必要だ、ということ。 == 非協力的な運用者 == DNSSECにかぎらず、DNS移転には移転前後のDNSプロバイダの協力が必須である。[[DNS/浸透いうな!]] DNS関係者がこのことを理解しないで、DNSSECを推進しているとしたら、間違いである。 非協力的な運用者はインターネットの一部ではない。 dnssec.jp とは非協力的プロバイダの集まりなのか。 [[DNS/DNSSEC/移転]] レジストラ移転ガイドライン 　協力的プロバイダを排除するための団体にみえてしまう。 ---- {{{ [PDF] JPRS トピックス＆コラム ファイルタイプ: PDF/Adobe Acrobat - クイック ビュー 検証エラーを避ける方法として、 　①いったんDNSSECを解除してから移転する、 　②移転元・移転先の共同作業により、信頼の連鎖を維持したまま移転する、 の二つが検討されています。 ■DNSSEC の安定運用の実現に向けて. このように DNSSEC の安定運用の ... jpinfo.jp/topics-column/015.pdf }}} 現在は(1)の方法が推奨されているという。(dnssec.jp) DNSSECの解除により検証エラーを避けるのではなんのためのDNSSECなのか。 共同作業は望めないということであれば、そういう業者はDNSSEC対応しないということを明言すべき。 ------ http://jpinfo.jp/event/2010/0423IETF.html DNSSEC運用ガイドラインの改良に向けた取り組み {{{ 現在のDNSSEC運用ガイドラインはRFC 4641で定義 インターネットにおいてDNSゾーンの運用者がDNSSECを円滑に運用するための運用上の慣習（Operational Practices）は、 2006年に発行されたRFC 4641としてまとめられています。 RFC 4641には鍵の生成・保管、署名の生成、鍵の移転など、 実運用において考慮すべき課題とその対応がそれぞれの項目ごとに記述されており、 DNSSECの運用ガイドラインとしての役割を担っています。 しかし、DNSSECの導入が具体化していく中で、 現行のRFC 4641では不十分な点、特に、 レジストラ間においてドメイン名を移転する際に考慮すべき点が不十分であることが顕在化してきました。 }}} == DNSSECとドメイン名の移転 == {{{ レジストラが顧客のドメイン名とともに権威DNSサーバーも受け持っている場合、 レジストラ間においてドメイン名を移転する際の権威DNSサーバーの変更における大まかな流れは、以下のようになります（*7）。 1. 移転先レジストラが新しい権威DNSサーバーを設定する 2. 移転先レジストラが新しい権威DNSサーバーの情報をレジストリに登録（変更）する このように従来のDNSでは、基本的に顧客を受け入れる移転先レジストラ側の作業により、 DNSの権限委任構造が切れない形で作業を進めることが可能です。 }}} ここでも、[[DNS/浸透いうな！]]問題は見過ごされている。 　つまり、従来のDNSでも移転先だけの作業では移行は困難であることが見過ごされている。 {{{ しかし、DNSSECが導入されたドメイン名について同様の移転を行う場合、 従来のDNSの権限委任構造に加え、 DNSSECによる信頼の連鎖（chain of trust）の取り扱いにも配慮する必要があります。 そのため、移転作業をより慎重に進める必要があり、従来の移転作業に比べ、手順が複雑になります。 このため、DNSの運用について議論するDNSOP WGでは現在作成中のRFC 4641の改訂版（以下、4641bis）において、 DNS運用者の変更の際に新たに「協力的なDNS運用者（Cooperating DNS Operators）」と 「非協力的なDNS運用者（Non Cooperating DNS Operators）」という概念を導入し、 それぞれの場合の移転の標準的な運用手法をまとめるための提案が行われました。 （*7）レジストラの変更手続きなど、権威DNSサーバーの設定や登録変更に直接関係しない作業については、本稿では省略しています。 }}} {{{ 「協力的なDNS運用者」間によるドメイン名移転〜公開鍵と署名情報を共有 現在検討中の4641bisでは「協力的なDNS運用者」間におけるドメイン名の移転の際の手順の典型的な流れを、以下のように定めています。 1. 移転先レジストラが新しい権威DNSサーバーと新しい鍵を設定する 2. 移転元レジストラは移転先レジストラから、 そのドメイン名の公開鍵（DNSKEYレコード）、 及びその公開鍵に対する署名情報（RRSIGレコード）の提供を受ける （注）相手のレジストラに渡す必要があるのは公開鍵と公開鍵に対する署名情報のみであり、秘密鍵の情報を渡す必要はない 3. 双方のレジストラが自分と相手の双方の公開鍵、及び公開鍵に対する署名情報を、それぞれの権威DNSサーバーで公開する 4. 移転元レジストラにおいて、移転先レジストラのDNSサーバーホストをNSレコードに追加する （注）作業後に移転元レジストラのNSレコードは、移転元レジストラの鍵で署名される必要がある 5. 移転先レジストラが新しい権威DNSサーバーとDSの情報をレジストリに登録（変更）する 6. 移転先レジストラが移転元レジストラの公開鍵と署名情報を、自分の権威DNSサーバーから削除する このように4641bisでは、移転元と移転先のDNS運用者が互いに協力することで 該当ドメイン名の新旧の公開鍵とその公開鍵に対する署名情報を双方の権威DNSサーバーで公開し、 DNSSECによる信頼の連鎖が切れない形でドメイン名を移転するという手法を定めています。 }}} {{{ 「非協力的な運用者」間によるドメイン名移転〜手法標準化が今後の課題に しかし、商用化が進んだ現在のインターネットにおいて このような協力が実際に成立するのかについては、 単に技術的要件や運用的要件のみにとどまらず、 ドメイン名移転の際の具体的な業務の流れ、 ひいてはレジストラやDNS運用サービスプロバイダといった各関係者における業務形態や利害関係をも含んだ、 総合的な検討が必要になります。 そのような状況から4641bisでは、 DNS運用者が変更作業に際し協力的ではなく、 鍵情報の共有や相手方の鍵を用いた署名などが期待できない「非協力的なDNS運用者」という概念を新たに導入し、 このような場合のドメイン名移転における運用の手法をどのように標準化すればよいかについて、今後の検討を進めていくこととなりました。 }}} ------ dnssec.jp での案は「非協力的な運用者」しか言及していない。 　この団体に参加する業者は「非協力的な運用者」しか参加していないことを自認しているようだ。 「商用化が進んだ」のはともかく、非協力的な運用者を前提にしていてはもはやインターネットとは呼べない。 -- ToshinoriMaeno <>