インシデントの話なのでせっかくだから私が体験した1番ゾッとするインシデントの話に参加してみたのですが、正直なところ1番
ではないですね。
やっぱ一番はコレですよ。
というわけで先日起こした事故の紹介です。
まあタイトルどおりなのですが。
どういうこと?
; OK
IN A 192.168.0.1
www IN A 192.168.0.2
; 死!!!!!
www IN A 192.168.0.2
IN A 192.168.0.1
なにをやった?
弊社サービスの一部について、ドメインをDoレジで提供しているわけです。
ここzoneファイルをそのままアップできて自由度が高いので便利です。
ということでこんなかんじの運用をしていました。
example.jp.
; DNS
IN NS NS1.DO-REG.JP.
IN NS NS2.DO-REG.JP.
; 本番環境
IN A 10.0.0.1
; 開発環境
dev IN A 10.0.0.2
example.jp
が本番環境で、dev.example.jp
が開発環境という、まあよくある構成です。
NSx.DO-REG.JP
は変更するなとDoレジから言われているところなので常に固定です。
実際はこれ以外にも色々レコードが書かれているのですがそのあたりは省略しています。
ある日、開発環境のIPアドレスが10.0.0.2
から10.0.0.3
に変更になったので書き替えました。
ついでにちょっと他のところも色々と整理しました。
ここで嫌な予感のした人は鋭いですね。
最終的なzoneファイルはこのようになりました。
example.jp.
; DNS
IN NS NS1.DO-REG.JP.
IN NS NS2.DO-REG.JP.
; 開発環境
dev IN A 10.0.0.3
; 本番環境
IN A 10.0.0.1
意気揚々と設定変更した数分後、口々にクレームが上がり始める。
「「「本番環境に繋がらなくなった!!」」」
実際ブラウザから見てみるとexample.jp
ドメインが見つかりません。
えーなんで本番環境のAレコードなんて変えてないよ?開発環境しか変えてないよ??どうして???
意味がわからねーと毒付きながらも慌ててzoneファイルを切り戻したところ、しばらくして再びアクセス可能になりました。
結果として、数十分本番サーバに接続できない状態になってしまいましたとさ。
幸いDNS変更時の作法に従って数日前からTTLを短くしていたのでまだよかったものの、うっかり86400とかのままだったら大惨事になっていたところでした。
対策
サブドメインのないドメインのAレコードは真っ先に書きましょう。
決して順番を入れ替えてはいけません。
本当の原因
嘘です。
本当の原因は、一番上に書かなかったことではありません。
サブドメイン部分を省略した場合は、前行の設定が引き継がれるという仕様のためです。
即ち、上で順番を並び替えたDNSレコードは、実際にはこう解釈されます。
example.jp.
; DNS
IN NS NS1.DO-REG.JP.
IN NS NS2.DO-REG.JP.
; 開発環境
dev IN A 10.0.0.3
; 本番環境
dev IN A 10.0.0.1
example.jp
のAレコードなくなったやん。
どうしてこんな恐ろしい仕様なんですか。
そんなわけで、省略せずに常にフルパスで書いておけばどんな順番であろうが問題ありません。
example.jp.
; DNS
IN NS NS1.DO-REG.JP.
IN NS NS2.DO-REG.JP.
; 開発環境
dev.example.jp. IN A 10.0.0.3
; 本番環境
example.jp. IN A 10.0.0.1
こっちのほうが面倒だけど安全ですね。
面倒だけど。
@使えよ
これでいいらしい。OMG
www IN A 192.168.0.2
@ IN A 192.168.0.1