## page was renamed from DNS/DNSSEC/移転 == Describe DNS/DNSSEC/移転 == テスト運用がはじまったばかりの段階で移転は気が早いと思われるかもしれないが、DNSの移転には問題が山積です。 DNSSECなしの[[DNS/移転]]でもいろいろトラブルが起きています。「非協力的な運用者」にご注意を。 上位サーバとの関係がより深くなるDNSSECでは慎重に移転のことを検討しておく必要があります。 [[/Verisign]] == DNSSECドメインの移転問題 == そもそもなにを移転するのか、そこをはっきりしておかないと、議論もできません。 　レジストラ（指定事業者）の移転にはDNSレコードは関係ありませんから、 　DNSサーバ（プロバイダ）の移転だということになります。 DNSプロバイダがレジストラを兼ねていることが多いようで、よく混同されているいます。（意図的かもしれません。） === DNSSECなしのドメインの移転とどう違うのか === NSレコードの変更があるのは当然としておきます。 DNSKEYを誰が生成、管理しているかにもよりますが、DNSKEYと上位サーバ上のDSレコードの変更が必要になります。 この違いがどう手順に影響するのでしょう。 　DNSKEY+DSの変更は簡単ではありません。 　（dnssec.jp ガイドにはいったんDNSSECをやめる案しか説明されていない。これだと移転とは呼べません。） RFC 4641 DNSSEC Operational Practices http://tools.ietf.org/html/rfc4641 (古い） draft 段階だが、 4641bis の日本語訳(JPRS): http://jprs.jp/tech/material/id/draft-ietf-dnsop-rfc4641bis-04-ja.txt === レジストラ移転ガイドライン === まずは [[http://dnssec.jp/wp-content/uploads/2010/11/20101122-techwg-registrar-transfer-guideline.pdf|DNSSECレジストラ移転ガイドライン]] を出発点にします。 いきなり、こうあります。 {{{ 中でもレジストラ移転・DNS プロバイダ移転は、複雑な鍵更新作業を実施しながら事業者 間をまたがった作業が必要なため、信頼の連鎖を維持したままの移転が非常に難しいもの となっています。 }}} いまごろ、「DNSSECは移転に配慮しない設計になっている」と言っているのです。 　それなら、なぜDNSSECを推進するのですか。 1.4　本ガイドラインにおける前提条件 {{{ 1. 一般的な商用ドメインサービスにおいてレジストラ移転が行われるとき、顧客との 契約が解除されることになる移転元のレジストラおよび DNS プロバイダは追加の 作業を行うモチベーションが低いと考えられる。そのため移転元レジストラには作 業を課さない。 2. 既存のドメイン名登録・DNS 運用のフローを大きく変更するものは対応が困難と考 えられる。そのため既存の運用フローに則った作業を想定する。 3. あるゾーンが DNSSEC 対応リゾルバにおいて検証失敗となる状況(Bogus)は、 未署名状況検出または検証対象外となる状況(Insecure/Indeterminate)より問題が大き いと考える。そのため検証失敗(Bogus)な状況になることを避ける。 4. 2 章において展開するレジストラ移転方法は、移転元・移転先の事業者がともにレ ジストラ、DNS プロバイダの両方を兼ねている場合とする。それ以外、即ちレジス トラと DNS プロバイダが異なる場合(DNS プロバイダをドメイン名登録者が行っ ている場合も含む)は、ドメイン名登録者自身が移行手順を実施する必要があるだろう }}} レジストラとDNSプロバイダを兼ねている業者から同様の別の業者へ移転するケースしか扱っていない。 　これでは移転できる範囲が狭すぎる。(dnssec.jp 会員の業者しか相手にしていないと読める。） 　この条件でしか、考えたくない理由はなんでしょうか。 [[/非協力的運用者]]しか考慮しない。 しかも、この前提条件では、DNSSECでなくとも移転時にトラブルが発生する。 　[[DNS/浸透いうな!]]の原因を作っているのは[[DNS/プロバイダ]]だということにならないか。 そして、この資料はまだ検討中のものです。これで、DNSSECを勧めるのは無理というものです。 ---- ２章には移転の手順がながなが書いてある。 レジストラの手続きとプロバイダの手続きが混じっていて、わかりづらい。 業者のための手順書なら、DNSを理解していなくても作業できるようにしておく必要があるからだろう。 要約すれば、 DNSSECが矛盾すると、ドメインが見えなくなってしまう（Bogus)ので、 それを避けるために： 　* いったん、DNSSECを無効(Insecure)にする。無効期間として十分な期間をとる。 * Insecureの状態でこれまで通りの移転をする。 * 移転後、移転先で新たにDNSSECを設定する。 となる。 これは {{{ DNSSECを動かしたままでは移転できない }}} と言っていることになります。 　この間に毒盛されてもしかたがない、と。これでも現状よりはましということですね。 こんなに手間をかけてもその程度のことしか実現できないなら、ほかの移転方法を検討すべきです。 あるいはDNSSECが使い物にならないといいたいのか。（直接は書けないけど、そうも受け取れる。） ==== 実験台募集中か ==== トラブル覚悟でテストするドメインがでてくることを期待したドキュメントでしかないと思う。 ==== DNS浸透問題を知らないのか ==== DNSSECなしの運用であっても、DNSサーバの移転がきちんとできる手順になっていれば、 このガイドの存在意義はあったのだが、これでは間違ったガイドでしかない。 {{{ 　移転元には作業させないと書いてあるので、トラブルは発生するであろう。 }}} [[DNS/浸透いうな！]]問題を知らないで、DNS移転の手順を書いているとしたら、DNSの勉強・経験不足だ。 そんな団体のガイドを信じてはならない。 こういう団体がインターネットを崩壊させている。 == RFC 4641 == RFC4641 にはDNSSEC運用を途切れることなく移転する方法が書かれている。 DNSSEC Operational Practices http://tools.ietf.org/html/rfc4641 draft 段階だが、 4641bis の日本語訳(JPRS): http://jprs.jp/tech/material/id/draft-ietf-dnsop-rfc4641bis-04-ja.txt ガイドラインでは使い物にならないと書かれているが、理由は前提条件が異なることだろう。 わがままとも言える条件をつけて結果を求めるのでは、解がなくてもしかたがない。 求める解がないなら、前提条件を変えてみるしかない。 　特に前提条件の１がよくない。 == 代案 == 移転をともなわない鍵の変更([[DNS/DNSSEC/運用/鍵の更新]])が比較的簡単であるなら、 Insecureな期間を作らないでも、確実に移転できそうな方法がある。 移転元の協力が必要であるので、前提条件１は成り立たない。 DNSSECエキスパートなら、このヒントだけで、すぐに思いつくはずである。:-) 　鍵の受け渡しが面倒というような言い訳はして欲しくない。 （分からなければ、このwikiで連絡してください。） -- ToshinoriMaeno <> == 協力的業者はいない == DNS推進団体は非協力的業者のあつまりだと自認している。 DNSSECを採用するドメインは自前でDNSSEC(DNSサーバを含む）を運用する覚悟が必要である。 　いったん業者にまかせたら、そのドメインはその業者に与えたものだと考えるべきで、移転はできないと思うべきだ。 -- ToshinoriMaeno <> 今、DNSSECを入れようというドメインは移転する必要を感じていないとも言える。 -- ToshinoriMaeno <> DNSサーバの移転を考えているドメインはDNSSECはやめておいた方がいい。