正しいDNSホスティングサービスの切り替え方

tech

自分でDNS権威サーバを運用してる人は自分でちゃんとやんなさい、と思うのでここでは扱いません。

以下の手順は、自分のドメインのDNS権威サーバに、DNSホスティングサービスを使っている人向けの情報です。

移転先のDNSホスティングサービスと契約する

どこかを探してまずは契約。

将来またどこかに乗り換える時に備えて、NSレコードを設定変更可能なところをオススメします。旧サービスの契約終了前までに、新サービスが利用開始できていることが必須です。
たいして高いサービスでもないので、1〜2か月ぐらい両方契約しておくぐらいのつもりでいると、何かで困っても慌てなくて良いと思います。

移転先のDNSホスティングサービスで、ゾーン情報を整備

必要なTXT/MX/A/CNAME等を登録します。

旧DNSホスティングサービスで設定しているものと、基本的に同じ内容を用意して下さい。
変更の必要が確定しているレコードについては、TTLを短くしておくと良いでしょう。
短く、といっても10分ぐらいで良いんじゃないかと思います。僕は5分より短く設定したことはありません。

このタイミングでwwwサーバも移転をとか、そんなことは考えないほうが無難です。

移転元でNSレコードを変更

通常メニューではNSレコードの設定変更ができないDNSホスティングサービスもあるみたいですが、ここはサービス提供者に掛け合ってでもやりたいところ。

example.com IN NS 新DNSホスティングサービスのDNS権威サーバ1
example.com IN NS 新DNSホスティングサービスのDNS権威サーバ2

こんな具合に。
このNSレコードのTTLは普通で良いです。(10分とかにしないという意味で。)

だけど、もう解約してしまうユーザに特別対応してくれる事ってあまり期待できそうにないですね。

ドメインの登録情報を変更

ネームサーバの設定を、新DNSホスティングサービスのDNS権威サーバに変更して下さい。

待つ。

ドメインの登録情報変更が反映されてから、以下の時間だけ待ちます。(※ドメインの登録情報は申請から設定完了までにタイムラグがあります。)

.jpドメイン: 1日
.orgドメイン: 1日
.comドメイン: 2日
.netドメイン: 2日
.infoドメイン: 1日
.bizドメイン: 2時間
.mobiドメイン: 1日
こんだけ書けばもういいか。

これらは、それぞれのドメインの権威サーバ(親)が標準で設定しているNSレコードのTTLです。
通常のDNSホスティングサービスがDNS権威サーバ(子)で設定しているNSレコードのTTLはこれより短い場合がほとんどなので、意識して長いTTLを設定するような事をしていなければ、上記の時間待てば良いです。

便宜上これを平行期間とでも呼びましょうか。

旧DNSホスティングサービスを解約(利用停止)

平行期間を経たら、古いDNS権威サーバ(子)は残して置いても良い事がないどころか悪い場合があるので、設定を削除してもらって下さい。

ゆっくりとその他レコードの変更

www.example.jp のAを変えるとかね。このとき、前述のようにTTLを短くしていると、きっとそのTTLの時間内に切り替わってくれることでしょう。

旧DNSホスティングサービスでの利用期間がまだ残っている場合は、旧側でも同様の変更をしておくと良いでしょう。
これは行儀の悪いDNSキャッシュサーバ対策で、平行期間を経ていれば本来不要であるはずのものです。

検討

どんなDNSホスティングサービスを選ぶべき？
  • 浸透って言わないところｗ
  • NSレコードが指定できるところ(TTLは指定できなくて良い)

あと、TTLはレコードごとに設定できるものなので、ゾーン全体で一律のTTLしか設定出来ないサービスはダサいなって思います。

旧DNSホスティングサービスでNSレコードが変更できないんだけど？

こんなこともありますよね。
そのときは、平行期間を過ぎたらすぐにでも旧環境を停止して下さい。

この場合、旧DNSホスティングサービスで設定していたNSレコードのTTL値の時間だけ、「あれ？名前？あれ？」ってことがあるかもしれませんが、これは待つほかありません。

(NSレコードのTTLを5分にしてるお名前.comってコレを狙ってたのかしら…と、新たな発見。これは驚いた。)

まとめ

  • DNSホスティングサービスにはNSレコード設定変更が可能なところを選びましょう。
  • NSレコードのTTLを5分にするDNSホスティングサービスは、意外なところで問題収束を早めているようで驚きます。

DNSホスティングサービスの切り替えと、NSレコードのTTLについて

移転手順を書いてみたきっかけは、↓これなんだけど
http://d.hatena.ne.jp/inuz/20120308/p1
この文章を書いてみたら、新しくわかった事があるので、元の主張を一部訂正します。

これを書く前に思っていたこと
  • 移転元のDNSホスティングサービスで設定しているDNS権威サーバ(子)のNSレコードのTTL値は、移転開始から終了までにかかる期間に影響しない。これは通常DNS権威サーバ(親)のNSレコードのTTL値がより長いものに設定されているためである。
  • 移転終了とは、一般のDNSキャッシュサーバ全てで古いNSレコードのキャッシュが消えて、新しいDNS権威サーバ(子)が参照されるようになるまでを指す。
  • 旧権威サーバ(子)においてNSレコードを新権威サーバ(子)に変更出来ない場合において、旧権威サーバ(子)の応答に付随するAuthority Sectionの内容を以って、当該ドメインのNSレコードについてキャッシュのTTLを更新しをてしまうDNSキャッシュサーバがある問題に対応するには、旧権威サーバ(子)においてNSレコードを新権威サーバ(子)に変更する以外には、旧権威サーバ(子)を停止する他なく、旧権威サーバ(子)のNSレコードのTTL値の長短とは関連しない。
  • 旧権威サーバ(子)においてNSレコードを新権威サーバ(子)に変更出来る場合においても、TTL値の長短は移転終了と関連しない。

(の、ばっかりだな。読みにくい。)

これを書いた後に思っていること
  • 移転元のDNSホスティングサービスで設定しているDNS権威サーバ(子)のNSレコードのTTL値は、移転開始から終了までにかかる期間に影響しない。これは通常DNS権威サーバ(親)のNSレコードのTTL値がより長いものに設定されているためである。
  • 移転終了とは、一般のDNSキャッシュサーバ全てで古いNSレコードのキャッシュが消えて、新しいDNS権威サーバ(子)が参照されるようになるまでを指す。
  • 旧権威サーバ(子)においてNSレコードを新権威サーバ(子)に変更出来ない場合において、旧権威サーバ(子)の応答に付随するAuthority Sectionの内容を以って、当該ドメインのNSレコードについてキャッシュのTTLを更新しをてしまうDNSキャッシュサーバがある問題に対応するには、旧権威サーバ(子)においてNSレコードを新権威サーバ(子)に変更する以外には、旧権威サーバ(子)を停止する他ないが、旧権威サーバ(子)のNSレコードのTTL値を短く設定することで、旧権威サーバ(子)の停止から正常化までの期間を短縮できる。
  • 旧権威サーバ(子)においてNSレコードを新権威サーバ(子)に変更出来る場合においても、TTL値の長短は移転終了と関連しない。


考えを変えたところを赤文字にしました。


DNSって難しいね。

おしまい。