DNS関連のトラブル事例：浸透問題編

こんにちは、m//t です。
夏真っ盛り、当社ビル前の並木では蝉の大合唱中です……

今回は DNS 関連のトラブルに関する事例の続きです。
なお、本稿には前職でDNS関連サポートを担当していた経験や個人的にもDNS関連サーバを運用している中での経験も多く含んでいます。また、DNS関連セミナーやイベント等で紹介されていた事例を含む場合もありますのでご了承ください。
前稿：移転問題編

浸透問題とは

「DNSのレコード(Aとか)を更新したのにWEB表示されん～」という状況のことです。
「世界中のDNSサーバに情報が行き渡るまで最長72時間かかります」なんてのもよく聞くお話。
さすがに「国内だけでよいので浸透もっと速くなりませんか」という質問はされたことはありませんが。

では事例を挙げていきます。
　
　
　
　
　
　
　
　
　
と、いろいろ想いを馳せてみたのですが、あまりこの 「浸透しない」問題に出くわしたことがないんですね。
実例やまとめについてはこちらが詳しいので是非参考にしてください。
http://www.e-ontap.com/dns/propagation/ 浸透いうな!

こう書いてしまうとこの記事終わってしまうので、新旧アドレス過渡期に当社が対応してきた事例を紹介しておきます。

WEBサーバ

WEBサーバを新しくする場合のことを考えてみます。

新旧どちらにアクセスされてもいい場合

何も考える必要ありませんね。権威DNSでAレコードを書換えるだけです。
旧サーバへの接続がなくなったらOFFにするなり初期化するなりすればよいかと。

旧サーバで更新をしたくない場合

WEBフォームだったり、掲示板だったり、ブログのコメント欄だったり、いまさら古い方で入力されても新しい方に引き継げないよ、ってケースはありますね。
見捨ててよいのなら前項同様放置すればいいのですが、そうもいかない場合には以下のような対応があるかと思います。

• 旧サーバでの表示を「メンテ中」ページのみにしてしまって放置。
  一番安上がりな対応ですね。
• 旧サーバの設定をいじって新サーバへリダイレクトする。
  リダイレクト先の指定にFQDNが書けない(自分自身と同じ)ので、IP指定が可能なら適用できるかと。
• 旧サーバの設定をいじって新サーバへのリバースプロキシに変える。
• 新サーバへのリバースプロキシを設定したサーバを用意して、旧サーバのIPアドレスを付け替えて引き継ぐ。

新旧サーバじゃなくて、サーバを移設(IPを変更)する場合

この場合は新旧両方にアクセスされて困るという問題はありませんが、旧IPアドレスを持つサーバがいなくなるので、その穴をどう埋めるかという検討が必要です。

• 旧IPにサーバいないままにする。
  無応答な状態で構わないということであればこれが手っ取り早いですね。他人にこのIPアドレスを利用されないことが前提ですが。
• 前項同様、新IPアドレスへのリバースプロキシを設定したサーバを用意して、旧IPアドレスで稼働させる。

MAILサーバ

これもWEBサーバ同様ですが、メールの場合は少し面倒です。

新旧どちらにアクセスされてもいい場合

「しばらくの間は旧サーバにもメールが届きます。IPアドレスを指定して受信してください」 というのがよくあるパターンかと思います。利用者に「ご面倒をおかけします」というスタンスですね。旧サーバに届かなくなったらOFFするなり初期化するなり……

旧サーバで受信したくない場合

WEBサーバのように「メンテ中」にするわけにもいきません。 メールを受け取らないメールサーバの存在は混乱の元です。
この場合、当社では以下のような対応例があります。

• 旧サーバの設定を変更して、外部からのメールはすべて新サーバに転送する。
• バウンス覚悟で旧サーバで外部向けに応答しないようにする。

ロストはイヤ、バウンスもイヤ、しばらく新旧両方に接続なんてもっとイヤ

結構手間がかかるので費用をいただいて対応するケースが多いのですが、一番オススメな方法があります。

• 現サーバの前段に MXとして中継サーバを用意して切り替える。
  以下のような手順で行います。
  1. 対象ドメイン名あてのメールを受信し、現サーバへ転送する中継サーバを用意する。
  2. DNSのMXレコードをこの中継サーバに変更する。
  3. (外部から現サーバへのメール着信が来なくなるのを待って)中継サーバでの転送先を新サーバに向ける。
  4. DNSのMXレコードを新サーバに変更する。
  5. 中継サーバへの着信がなくなったら撤去する。
     なお、この方法では中継サーバが送信元(接続元)となってしまい、送信元認証で不正メールとして扱われる可能性があるため、いろいろ配慮する必要があります。
• 前項中継サーバを当社メールフィルタガードマンサービスをご利用いただく。
  中継サーバを挟むのは同様ですが、仮設の中継サーバでなく、恒久的に機能サービスを中継する形となります。
  参考：メールフィルタガードマン
  この場合、前項手順の4,5が不要となります。

最後に

サーバ移行時における新旧アクセスへの対応についてご紹介しました。
タイトルと内容が合ってないかもしれませんが、 参考になればと思います。

サーバの再構築や移転等で当稿のようなケースがあるかと思います。
他にも、WEBサーバからのメール送信はどうなるのかとか、MAILサーバでの外部からの着信以外に社内のメールクライアントからのアクセスはどうなるのかとか、考えるべきことはいろいろありそうです。
懸念点ありましたら一度ご相談ください。

以上、昔話担当? の m//t でした。