概要
ある日、ステージング環境で動作確認をしていたところ、意図しない挙動が確認されました。調査の結果、ステージング用ドメインがdevサーバーのIPにも名前解決されていたことが判明しました。
この記事では、その原因と得られた学びについて記録します。
前提
私たちの開発体制では、以下のように環境を明確に分離しています：
-
dev環境：開発者が個別に動作確認・検証を行うための環境。主に内部向け。
ドメイン:develop.example.net -
ステージング環境：本番相当の構成で、リリース前の総合テストやクライアント確認に使用する環境。
ドメイン:staging.example.net
これらの環境は別々のサーバーおよび異なるIPアドレスで運用されています。
また、各環境ごとに専用のドメインを割り当てており、アクセス経路の混在が起きないように設計しています。
起こった事象
dev環境 develop.example.net にアクセスしたところ、stagingのデータが表示された。
chromeの検証ツールで、ネットワークタブを確認したら、staging.example.net/api向けのGETリクエストが行われていた
いろいろ確認してみる
- dev環境向けのenvファイルがおかしい？=> 変更なし
- 環境ごとに分けているenvファイルの記載も変更なし
- Jenkinsのジョブのログを見てみても、dev環境用のenvファイルを反映していることが確認できた
さらに
ブラウザでdevelop.example.netを表示すると、毎回staging環境が表示される訳でもなく、dev環境が表示されることもありました
=> ドメインとIPの対応付がおかしい？？
結論
ドメインに対して、複数のIPが対応していた
-
nslookupの結果、2つのIPアドレスが返却されました：
$ nslookup develop.example.net
Server: [DNSサーバーアドレス]
Address: [DNSサーバーアドレス]#53
Non-authoritative answer:
Name: develop.example.net
Address: xx.xx.xxx.101
Name: develop.example.net
Address: xx.xx.xxx.102
xx.xx.xxx.101：dev環境のサーバー（正しい）
xx.xx.xxx.102：staging環境のサーバー（意図しない）
その結果、クライアントからのアクセスが staging環境にも到達していたことが判明しました。
原因
インフラ担当者に確認したところ、以下の点が原因でした：
開発用ドメイン develop.example.net に対して、誤って staging環境のIP（xx.xx.xxx.102）もDNSレコードに含めてしまっていた。
その結果、名前解決時に ラウンドロビン的に2つのIPのどちらかに振り分けられる状態になっていた。
まとめ
DNSは一見地味な構成要素ですが、名前解決ミスによって開発や検証環境の境界が曖昧になるというリスクを改めて実感しました。
環境ごとのアクセスが不安定な場合は、nslookupを実行して、ドメインとIPの対応付を確認するようにしよう.
もっと早くシェル叩けばよかった...