こんにちは。インフラストラクチャーグループの宝田です。
DNS 運用で気を付けるべき名前衝突問題に出くわしたので、事象の発生経緯と今後の対策を記しておきます。DNS の名前衝突問題とは、組織が内部的に使う Top Level Domain（TLD）と インターネットで利用できる TLD が重複してしまうことにより、DNSの動作が期待するものとは違った動作になることを指します。
経緯
サービスで使用中のとある AWS アカウントで AWS ClientVPN（以降 VPN と記載します） を構築し利用していたところ、VPN を接続している時に Slack の通話ができないという現象が発生しました。他の通話アプリ、例えば Google Meet や Zoom 等は問題なく使用できるが Slack だけ通話機能が一切使えないという状態でした。
とりあえず VPN を接続した状態で Slack チャンネルで /call --test と打って通話機能のテストを試したところ、以下のように音声接続がうまくいっていないことが分かりました。
Slack 通話のどのフェーズで失敗しているか把握したいので Slack のサポートに問い合わせてみると下記の方法で通話ログを取得できることを教えてもらいました。
Slack アプリの上部のメニューバーで、「ヘルプ」>「トラブルシューティング」>「再起動してネットワークログを取得」を選択します（Windows 10 の場合は、左上の 3 本の横線をクリックして、「ヘルプ」>「トラブルシューティング」>「再起動してネットワークログを取得」を選択します）
再起動を求めるポップアップが表示されます。「Slack を再起動する」 をクリックします
デスクトップアプリが自動的に再起動し、「ログの進行中です」というポップアップが表示されます
調査したい内容を再現します
ロギングを 2 分間実行して、問題がキャプチャされたことを確認してから、ポップアップにある「ロギングを停止」をクリックします
Slack のダウンロード先のフォルダに表示される .zip ファイルを解凍した中にある net.log がネットログになります
ただし、通話ログの見方は公開されていないようなので自ら解析するなら雰囲気で理解する必要があります。今回はサポートにお願いして通話ログの中身を解析してもらいました。
解析してもらったところ、Slack 通話で発生する signal.m1.an1.app.chime.aws や nearest-media-region.l.chime.aws の名前解決が失敗していることが分かりました。余談にはなりますが、上記の URL からも分かる通り Slack は Amazon Chime SDK を使っているようです。
ここまでくると、aws ドメインの名前解決が失敗する理由はすぐ分かりました。原因は、VPN の DNS 設定でプライベートホストゾーンの名前解決を可能にしており、そのプライベートホストゾーンに aws というホストゾーンが存在しているからでした。つまり、 VPN を繋いだ状態で aws ドメインを名前解決するとプライベートホストゾーンを参照してしまい、そのプライベートホストゾーンには signal.m1.an1.app.chime.aws や nearest-media-region.l.chime.aws はレコードとして当然登録されていないので名前解決が失敗していたということです。
上記の事象は、AWS が管理している aws ドメインを内部向けドメインに使用してしまったという名前衝突が根本的な原因となります。
対策
今回は弊社の内部向けで使っているドメインが他組織で管理しているドメインと重複してしまい、名前解決に不具合が起きた結果、外部のサービスが利用できなくなる現象がおきました。
名前衝突の対策としては JPNIC の記事にある通り、ドメインを取得してそのドメインを内部向け DNS のドメインとして利用することにしました。これで他組織で管理されているドメインと重複することが原理的になくなります。
まとめ
DNS の名前衝突の事例について紹介しました。内部向けドメインは組織で取得したものを利用しましょう。
最後に補足として、DNS のサーチリスト2と呼ばれるドメイン名の補完機能を使うと、ローカルネットワークのドメイン名を名前解決するつもりがインターネット上の TLD に対して名前解決してしまうという今回の事例とは反対の現象も起こり得ますので、サーチリストも極力使わないということも合わせて押さえておくといいと思います。
