クライアントエピソード15:DNSレコードの変更に失敗してメールが動かなくなった件

クライアントエピソード15:DNSレコードの変更に失敗してメールが動かなくなった件

クライアントエピソード15:DNSレコードの変更に失敗してメールが動かなくなった件

一般公開されたDNSレコード情報を鵜呑みにしたため、DNSレコードの切替時にメールが動かなくなってクライアントに多大な迷惑をかけてしまいました。

DNSレコードに通常と違うサーバー名が記載してあったら、どこのサーバーなのかを細かく調べるべきです。

今回はVPSサーバー側で直接、Aレコードだけを別サーバーへ向けてもらいます。

WEBサーバー先を別サーバーへ向けるレコード変更案件

クライアントからのご依頼で、以下の様なDNSレコード切替案件がありました。

ドメインの指すWEBサーバー先を、別のサーバー先へ変更するというものです。

現在は、WEBサイト本体の稼働するサーバーと、ブログ(Wordpress)の稼働するサーバーとが分かれているのですね。

WEBサーバーのみ別サーバーへ向ける案件

当然ブログ部分は、本体とは別のドメインになっています。

本体がブログ側のサーバーへ移動してくれば、1つのドメインで本体とブログを統一できます。

これがクライアントの要望です。

現状

ドメイン:レンタルサーバーAのドメイン管理部門
WEB:レンタルサーバーA
BLOG:レンタルサーバーB
メール:別メールサーバー(利用中)

目的

ドメイン:お名前.com
WEB:レンタルサーバーB
BLOG:レンタルサーバーB
メール:別メールサーバー(利用中)

他は一切触らない

今回はWEBサーバー先のみを変更するだけで、メール関連は一切動かしません。

現状メールサーバーは別サーバーを指している様です。

ですので、MXレコードはそのまま何ら変更なしで維持します。

・WEBサイト先をサーバーBに向けてブログ部分と統合する
・メールサーバー(MX)やTXTレコード設定はそのまま

ドメインのDNSを確認

早速ドメインのDNS情報を確認すると、以下の様な状態でした。

タイプターゲット
AAのIPアドレス
MX別メールサーバー1
別メールサーバー2
NSAのネームサーバー1
Aのネームサーバー2
TXTSPFレコードの記述

ターゲットの欄のAは、レンタルサーバーA社の事です。

確かにMXレコードのみAとは違うサーバーを向いているのがわかります。

クライアントからの連絡を鵜呑みに

クライアントからも「メールは別サーバーで動いているから」と説明を受けていましたのでお話は一致します。

今思えば、ここでこのメールサーバー先などを調べたり、社内情報を細かくヒアリングしておくべきでした。

しかし今回はそれをしないまま、作業に入ってしまいます。

実はここに大きなミスが潜んでいました。

ドメインをお名前.comに移管する

まずはサーバーAで管理されていたドメインを、お名前.comにドメイン移管します。

これは問題なく完了しました。

後は、お名前.comのDNSレコード情報を設定すればOKになります。

お名前.comで同じレコード情報を再現

Aレコード:レンタルサーバーBのIPアドレス
MXレコード:現状のメールサーバーと同じ
TXTレコード:現状のレコードと同じ
NSレコード:お名前.comのDNSサーバー

現在のDNSレコードの情報をデータ保存しておき、それと同じものを入れる予定です。

Aレコードは今までと違い、レンタルサーバーBのIPアドレスを入れる事になりますね。

ネームサーバーも変わる

DNSサーバーはお名前.comのものを使うので、今のネームサーバーとは違うものになります。

ネームサーバーを変えても、それぞれ正確にレコードが指定されていればきちんと稼働します。

何も不安を感じずに当日に挑みました。

レコード変更後にメールが送受信できないトラブル

レコード変更後にメールが送受信できないトラブル

予定通り、当日の朝から上記の情報にDNSレコードを変更しました。

程なくしてWEBサイトの方は、きちんとレンタルサーバーBのデータを表示していました。

ところが2時間程してから、クライアントから電話連絡があります。

「メールが送受信できなくなった」との事。

緊急事態トラブル

想定外の事にパニックになります。同じMXレコードを入れているのになぜメールが動かないのか。

取り急ぎお名前.comに電話を入れますが、これが全然つながらない状態。

とにかく「落ち着け」と自分に言い聞かせて、うろうろ歩き回りながら対処方法を考えます。

ふと「元に戻せばいい」と思いつき、クライアントに提案して早速実施をする事に。

元のネームサーバーに戻す

今のドメインのネームサーバーは、個別に入れたDNSレコードを反映させるため、01~04.dnsv.jpの4つが軸になっている状態です。

これを、早急に元のネームサーバーに戻す必要がある訳です。

入れているDNSレコード情報は一旦そのまま放置して、あらためて元のネームサーバー情報(2行)を設定しました。

設定が正解かどうか確証が欲しい

本当にこれで元に戻ってくれるのか…?心配で心配でたまりません。

DNSレコードを追加したままの状態で別途ネームサーバーを設定した場合、きちんと向いてくれるのか不安だった訳です。

変更したからといってそれが合っているか(メールが復旧するかどうか)は、しばらく様子見ないとわからないですし。

もし間違っていたら後からまた設定をし直して、反映されるまでの間クライアントを待たせる事になるためです。

この間はずっと、メールが送受信できないままですからね。

このタイムラグが本当にストレスです。

お名前.comとTELがつながらない

お名前.comとTELがつながらない

お名前.comのTELサポートへ何度も何度も掛けました。

これがなかなかつがならないのです。

「しばらくお待ちください」のガイダンスの時は、10分以上そのまま放置したりしました。

ようやく確認が取れ、あとは復旧を待つだけ

ようやくつながった担当者に事情を説明して「ネームサーバーを最後に設定したがこれで良いのか?」を確認。

担当者は「それで大丈夫です」と言ってくれました。

後はそれを信じて待つだけですね。

レコード情報自体を消す

電話を切った後、設定済みのDNSレコードは削除しておいた方が良いのかを聞き忘れたことに気づきました。

ですがやはりまた電話はつながらなくなります。

ネームサーバーがきちんと向いている事を信じてDNSレコードは全削除しました。

何となく消していた方が良いと思った訳です。

メールが復旧し始める

すると2時間程度してから、メールが復旧し始めたことを報告受けました。

ホット一安心しました。力が抜ける感じがします。

本当によかった。ごめんなさいでした。

ネームサーバーを向けた事で元に戻った事は間違いありませんが、DNSレコードの全削除が必要だったかどうかはわかりません。

今回の原因

後日リモート面談で、今回のトラブルに対する以下の様な報告をしていく事になります。

・当日の動きの振り返り
・なぜ起きたのかの原因
・再発防止策
・具体的な段取り

このリモート面談に臨む前に、クライアントの担当者とヒアリングを重ねて大体の事がわかってきました。

メールはIMAPでAサーバーの中にあった

まずメールは全て「IMAPメール」だった事です。

今回メールの設定には触らない事になっていたとは言え、これを聞いていなかったのは完全にこちらのミスですね。

IMAPメールであれば、ではそのメールの保存先がどこなのかは確認していたはずです。

保存先は「レンタルサーバーAの中」でにある、とクライアントから説明を受けました。

MXのメールサーバー名は?

つまり、DNSレコードに記載されていた「MXレコードのメールサーバーの中」では無い訳です。

※後からこのメールサーバー名は、送信メールのSPF対策様に設定されたサービスの名前である事がわかりました。

つまり本来のメールサーバー先は「レンタルサーバーA」を向いていないといけない訳です。

それを知らずに、MXをSPF対策用のメールサーバーに向けていた訳です。

公開されているDNSレコードが正しいとは限らないという良い例であり、教訓になりました。

専用VPSサーバーの存在

クライアントは、レンタルサーバーAから個別に運営できるVPSサーバーを提供されていました。

ドメインのDNSを管理しているサーバーで、AレコードやMXレコードなど、複数のレコード情報が指定されていた様です。

このVPSサーバーに登録された一連のDNSレコード情報を無視してしまったので、メールが動かなくなったと思っています。

完全に「レコード情報の設定不足」と言えますね。

私はこのVPSサーバーに現状触る事ができないため、これ以上細かくはわかりません。

対応策となる2つの手段

これを踏まえて2パターンで対抗策を練る事になります。

・VPSサーバーのレコード情報をお名前.comDNSサーバーで全て再現する
・VPSサーバーのAレコード情報をサーバーへB向ける

1つ目は予算オーバー

まずVPSサーバーの設定をお名前.comで再現するのは、正直現実的ではありません。

そもそも当初の作業仕様は「お名前.comドメインのAレコードを別サーバーに向ける」事でした。

ドメイン移管費用も込みでしたので、実質1万円程度の予算です。

この予算で上のVPSサーバーの権限を預かって全て調べて、お名前.comで再現して、テストして報告して…なんて不可能です。

これは明らかに追加費用が発生する作業です。

確かにミスはしましたが、それはそれ、これはこれですよね。

現実的なのは2つ目

ですので2番目の方法を実施する事になります。

クライアントにIPアドレスを案内して、クライアント側でレコード変更をしてもらうしかありません。

理論上、現在向いているAレコードをレンタルサーバーBの方に向ければWEBサイト先だけが変わるはずです。

もちろんMXレコードなど他の一連の情報には触りませんから、問題は無いはずです。

お名前.comで再現するよりも非常に簡単で済みます。

わざわざ、VPSサーバーを扱う権限をもらわずに済むメリットもあります。

将来環境を大幅に変える予定あり

そもそもクライアントは、今年中にメールサーバーを新たにMicrosoftのメールサービスに移行しようと計画されています。

その際はこのVPSサーバーを完全に離れる訳ですから、その際レコード設定は一式変わる訳です。

各PC端末のメーラー設定情報も変わる事でしょう。

であればこのWEBサイトのサーバー先を変えるためだけに、VPSサーバーの情報を丸ごとお名前.comで再現する必要は無いと言えますね。

このGWにテスト予定です

もちろんそれで本当に大丈夫かどうかのテストは必要ですよね。

前回の様に営業日ではなく休日に実施したいという要望を、私は了承しました。

ミスした責任がありますので、これは仕方ありません。

今度のGWにテストをする事になっています。

これについてはまた報告したいと思います。

この記事をシェアする

一押し人気コーナー紹介

フリーランス体験談カテゴリの関連記事