今日は、お客様のDNSが動作しなくなった事例です。
お客様はごく一般的なメールサーバーや、ウエブサーバを、いわゆるホスティングサービスで運用しています。商品紹介・通販など、ウエブもメールともに、お客様とのミュニケーション基盤として極めて重要です。
ですが、DNSを誤って書き換える事故が発生。メールが使えなくなったのです。偶然にも、当方は未明の運用支援を既定のこととして行い、報告をメールしてもエラーが繰り返されることに気づきました。
digでDNSのMX情報を確認すると、なんとMXレコードのホスト名が空欄で取得できません。もちろん、先のメールのエラーと合致しています。このような事態は初めての経験です。
メールが使えなくなったことは、メールではお知らせできないので、スマホで着歴を残し、事態を伝えようとしました。
夜が明け皆が出社すると「送信はできるが、新しいメールが着かない」状況で、てんやわんやです。もちろん、お客様もメールに障害が起きたことをメールで連絡できません。
DNSを書き換えたのはウエブコンテンツの会社だったそうで「消したけど、元に戻せない」とのこと。早々の業務回復に向け、当方がお手伝いすることにしました。早速DNSのコントロールパネルを見ると、ドメインが指すサーバを示すAレコードがありません。
それに紐づくメールサーバを示すレコードはあるものの、参照すべき情報がないので、サーバのIPを確定できないのです。
これではメールの仕組みは動きません。急いで復旧させようとしますが、TTLは一日なので、伝搬に時間がかかります。DNS設定を変更する際は、事前に十分前にTTLを短縮し、DNS変更が短時間に伝搬するようにします。DNSサービスで最短のTTLである5分に設定してドメインを指すサーバを復旧しました。
この復旧の伝搬はlinux上でdigコマンドで、パブリックDNSの1.1.1.1,8.8.8.8を使って確認。期待より速く伝わっていることを確認し、一件落着。
DNSはインターネットを正しく動かすための最も重要な情報の一つです。
DNSについて十分な理解がある方のみが触るようにしないと、壊したDNSを復旧することは、とても大変です。自信がない方は触らない方が良いです。専門家に頼むとともに、現状の設定をしっかりと記録しておきます。今回のような思わぬ障害も、避けるか軽減することができる完全な人災です。
いつもアクセスありがとうございます。DNSの障害が、会社様の業務を止めてしまいました。もはやネットインフラは止められません。引き続きよろしくお願いします。
アクセス
トータル
ランキング
