DNSワイルドカードレコードとは？用途とリスク

ワイルドカードDNSレコードは、アスタリスクのラベルを使って、ゾーン内により具体的なレコードがない名前に応答します。アプリケーションが多数のテナント用サブドメインを受け付ける場合や、サービスが意図的に幅広いホスト名を扱う場合に便利です。ワイルドカードは、すべての明示的なレコードを上書きする万能のルールではなく、その挙動はDNSの名前の存在と、要求されたレコードタイプに左右されます。また、スペルミスや意図しないサブドメインが、明確に失敗せずにどこかに解決されてしまうことで、思わぬ結果を生むこともあります。アプリケーションとセキュリティモデルが、その広さを前提に設計されている場合にのみ使用してください。

ワイルドカードの一致の仕組み

ワイルドカードのラベルは、特定の名前の階層に置いたアスタリスクとして書かれ、一般的には *.example.com のようになります。より近い一致するデータがない場合に、その地点より下にある特定の名前にデータを提供できます。ファイルシステムのワイルドカードを連想させるような、あらゆる深さのすべての子孫が自動的に作られる、という意味ではありません。既存の名前、委任、空の非終端ノードが結果に影響します。レコードタイプも重要です。ワイルドカードのAレコードは、あらゆるサブドメインのMX、TXT、AAAAレコードを自動的に作るわけではありません。1つのワイルドカードがすべてのDNSの挙動をカバーすると決めつけず、アプリケーションが想定する名前とレコードタイプをテストしてください。

よくある用途は、マルチテナントのホスティングです。各顧客にサブドメインを割り当て、そのすべての名前を同じアプリケーションのエッジにルーティングします。その後、アプリケーションがホスト名を調べ、どのテナントやサイトを配信するかを決めます。DNSはリクエストをエンドポイントに届けるだけで、要求されたテナントが存在するかどうか、リクエスト元にアクセス権があるかどうかは検証しません。アプリケーションが、独自のルーティングと認可のルールを実施しなければなりません。未知のサブドメインがデフォルトのサイトに流れ込む場合は、そのデフォルトが、管理ツール、デバッグ用のコンテンツ、ほかの顧客のデータを公開しないようにしてください。

運用面とセキュリティ面の考慮事項

ワイルドカードは、スペルミスのある名前でも名前解決されてしまうことがあるため、テスト中にタイプミスを隠してしまうことがあります。また、証明書の自動化が、公開するつもりのなかった名前を要求する原因にもなります。メール関連のワイルドカードには特に注意が必要です。ワイルドカードのアドレスレコードを、意図的なメールポリシーと取り違えてはならず、キャッチオールのメールの挙動は、DNSだけで作られるものではなく、メールシステムの側にあります。ワイルドカードを導入する前に、明示的な名前と委任されたサブドメインを棚卸ししてください。その挙動を誰が所有しているか、想定外のホスト名を受け取ったアプリケーションが何をするかを、文書化しておきます。

• ワイルドカードレコードは、アプリケーションが処理する準備のある名前にのみ使います。
• 個別のルーティングやポリシーが必要なサービスには、明示的なレコードを残します。
• 想定されるテナント名だけでなく、未知の、不正な形式のサブドメインもテストします。
• ワイルドカードDNSを、アクセス制御やテナントの認可として扱ってはいけません。
• 導入前に、証明書、メール、監視への影響を確認します。

ワイルドカードの答えのトラブルシューティング

想定外のサブドメインが名前解決される場合は、該当する階層のワイルドカードがゾーンにないかを調べ、より具体的なレコードや委任が存在しないかを確認します。正確な名前とレコードタイプを問い合わせ、ワイルドカードのターゲットと比較してください。ワイルドカードが適用されていないように見える場合は、既存のノードが、DNSツリーのその枝でのワイルドカードの合成に影響していないかを調べます。プロバイダーのインターフェースはこうした詳細を抽象化していることがあるため、そのサービスがワイルドカードレコードをどう実装しているかを確認してください。ワイルドカードを削除または変更した後は、キャッシュが失効するのを待ち、以前は想定されていた名前と、今は失敗するはずの名前の両方をテストします。

ワイルドカードは目的が限定された道具であり、ホスト名の棚卸しを省くための近道ではありません。製品が意図的に可変の名前空間を提供し、アプリケーションが安全で明示的なホストのルーティングを行う場合に、最もよく機能します。基礎的な背景については、DNSレコードタイプの解説とCNAMEの役割をご覧ください。公開のDNS検索では、選んだ名前に対してリゾルバーが何を返すかを確認でき、アプリケーションのテストでは、エンドポイントがその名前を正しく扱っているかを確認できます。

想定される名前と想定外の名前の両方をテストする

ワイルドカードの導入では、正常と分かっているテナント名を1つ試すだけでは不十分です。処理されるべき名前、明示的に上書きされるべき名前、存在しないはずのランダムな名前を確認し、そのうえでDNSの答えとアプリケーションの応答の両方を調べます。ワイルドカードは未知のラベルをサービスにルーティングできますが、アプリケーションは、誤ってデフォルトのアカウントを作ったり、設定を漏らしたりせず、安全な「見つからない」応答を返すべきです。明示的なレコードや委任を追加した後は、テストを繰り返してください。DNSツリーの構造によって、どのワイルドカードのデータが適用されるかが変わることがあるからです。意図した名前のパターンを文書化しておけば、将来の運用担当者が、新しく名前解決されるようになったサブドメインが想定内なのか、設定上の予期せぬものなのかを判断できます。