こんにちは。日々是発見が楽しみな西山です。
今回はちょっと前、弊社エンジニアメンバーにとって未知のトラブルが起こった日のことを振り返ってみたいと思います。
それは年末、世界中が休暇に入る直前のとある日
ちょっと変わったトップレベルドメインをご利用のお客様がおられました。
このブログでは、そのTLDを仮に「.hoge」と呼びます。
お客様が利用されていたドメインは「example.hoge」と呼びます。
「お宅で契約している example.hoge サーバーにメールが届かないんですけど……」
年の瀬も押し詰まった12月27日、そんな問い合わせで始まったトラブルシュートは難航しました。
メールが届かない原因は、DNSサーバーでMXレコードが引けなかったためでした。
ですが不思議なことに、他社が運営するパブリックDNSの中にはレコードが引けるものもありました。
引けるキャッシュDNSと引けないキャッシュDNSが世の中に混在していたのです。
「どういうこと？」
未経験の状況が誰も理解できず、一同首をひねりました。
弊社内に複数あるキャッシュDNSでも、引けるサーバーと引けないサーバーがてんでばらばらに存在していました。
DNSサーバーはすべてunboundを使用していましたが、導入時期によってバージョンも複数あり、障害要因がつかめません。
分かんないなぁ……と思いながらキャッシュDNSのログを眺めた時、不思議な1行が目に入りました。
Dec 27 17:32:08 n******1 unbound: [2982:3] info: validation failure hoge. NS IN
「トップレベルドメイン .hoge のDNSSECが検証失敗した」と言ってます。
「もしかしてこれ？」
「けど example.hoge はDNSSEC未署名だぞ」
whois example.hoge
Domain Name: example.hoge
...
DNSSEC: unsigned
それもそうなんだよな……と思ったのですが、
dig example.hoge mx
example.hoge. 3600 IN MX
dig +cd example.hoge mx
example.hoge. 3600 IN MX 10 203.0.113.1
digコマンドにDNSSEC検証無効で問い合わせる「cd」オプションを付けると応答が返ってくるのです。
さらに、ネット上でDNSSEC署名の状態を検査できるサイトを見つけて「.hoge」のDNSSECを検査させると、こんな結果がビジュアルで表示されました。
「.hoge」のDNSSEC署名に何か不具合が起きているようです。
「トップレベルドメイン .hoge がDNSSEC署名をしくじると、セカンドレベルドメイン example.hoge がDNSSEC未署名でも検証エラーでfailする……？」
私たちが今まで知らなかった現象でした。
DNSサーバーソフトやバージョンによっても挙動が違うようで、DNSSEC検証有効でも応答を返せるキャッシュDNSもあり、完全な再現条件はつかめませんでした。
原因追及はさておき、今まさに、DNSが引けないせいでお客様のビジネスが止まってしまっています。
メンバー間で協議の上、弊社キャッシュDNSのDNSSEC検証を無効化して対処することになりました。
「検証無効化はしたくないけどなぁ……」
キャッシュポイズニングのようなDNS攻撃に対して脆弱になるのを懸念する意見も出ました。
しかし、まずはお客様のビジネスを回復させなければなりません。
また「.hoge」の管理団体は海外にあり、レスポンスがどのぐらいかかるかも分からないため、弊社環境の機能回復を優先させることになりました。
DNSSEC検証を無効化すると、キャッシュDNSは元通りゾーン情報を応答し始めました。
example.hoge サーバーの疎通が回復したのを確認し、弊社の対応は完了となりました。
その後、個人的に時々「.hoge」のDNSSEC署名の状態を見ていたのですが、エラー表示が消えたのは年が明けた1月の14日頃でした。
セキュリティ設定を操作する責任
「セキュリティ設定を操作する管理者の責任、重大過ぎる……」
それが私の感想でした。
DNSならばDNSSEC、メールならばSPF・DKIM・DMARCなど、多様化するサイバー攻撃に対抗する技術が数多く導入されています。
それらはユーザーを攻撃や詐欺から守ってくれる盾ですが、管理者が設定をミスった瞬間、全機能を停止させてユーザーを困惑に陥れるブラックホールでもあります。
「.hoge」の管理者は、決められた手順通り作業したのかも知れません。
DNSSECチェックツールはネット上に複数ありますが、あの時「.hoge」は正常だ、と表示したツールもありました。
「.hoge」の管理者はそれを参照して作業ヨシ！ としたのかも知れません。
しかし結果は「.hoge」配下のセカンドレベルドメインでDNS名前解決が全滅という惨事でした。
全銀、Cloudflare、CARDNET……ITインフラが障害で停止し、多くの人々の暮らしやビジネスを止めてしまう事故が絶えません。
私たちも、残念ながら管理下のシステムで障害を起こしてしまうことはあります。
「チェック内容が漏れていて障害に至った」
それはその通り。大体それが原因です。
「じゃああの時、正しいチェック手順を出せる人は誰かいたの？」
……答えに窮することが多々あります。
※このブログ記事にきれいなオチはないです。残念ながら。
