AWS Route 53 / アプリケーションロードバランサーがマルチレベルサブドメインを解決する理由

AWS Route 53 / アプリケーションロードバランサーがマルチレベルサブドメインを解決する理由

AWS 内では、Application Load Balancer で TLS を終了します。AWS の Certificate Manager (ACM) を使用してワイルドカード TLS 証明書を構成しました。たとえば、*.example.com.AWS Route 53 を解決していますが、これは必要がないため、*.example.com何もありません。*.*.example.com

などのマルチレベルドメインに対してワイルドカード証明書を構成することはできないことは承知しています*.*.example.com

https://x.example.comはすべて正常で、有効な証明書で応答します。 では証明書エラーが発生しますhttps://y.x.example.comが、これは当然のことです。 などのマルチレベル サブドメインを提供する必要はありません*.*.example.com

すべてのマルチレベル ドメイン リクエスト (例: 404 を返す、またはホストを解決しないようにする) をブロックできるようにしたいと思います。基本的に、すべてのホストに対して404 を返すか、ホストを解決しないようにするhttps://y.x.example.comルールが必要です。https://*.*.example.com

アプリケーション ロード バランサーには、ポート 80 とポート 443 の 2 つのリスナーがあります。

ポート 80 リスナーのルールを構成すると正常に動作しhttp://x.y.example.com、404 を返すことができますが、同じルールをポート 443 に構成すると動作しません。これは、ブラウザーが TLS ハンドシェイクを完了できないため、当然のことだと思います。

nslookupを完了しx.example.comて同じネームサーバーを取得した場合y.x.example.com、Route 53 が を解決するとは予想されませんy.x.example.com

そこで、私は次の 2 つの質問のいずれかに対する答えを探しています。

  1. ポート 443 上のすべてのワイルドカードのマルチレベルサブドメインをブロックするように AWS ロードバランサーを構成するにはどうすればよいですか?
  2. Route 53 が同じ解決をするのはなぜですかy.x.example.com/ Route 53 が同じ解決をしないようにするにはどうすればよいですか?

答え1

  1. これがHTTPS/TLSの場合に限った話であれば、意味のある方法ではこれが可能だとは思えません。
    クライアントが接続しようとしている名前の有効な証明書がない場合、サーバー側の設定に関係なく、そもそも有効な応答(質問で言及されている404応答など)を送信する
    手段がありません。プレーンHTTPの場合、宿主の状態しかし、実際に単一レベルと複数レベルのケースを区別できるかどうかはわかりません。いずれにしても、プレーン HTTP のケースが今日ではそれほど興味深いものであるかどうかはわかりません。

  2. DNS でのワイルドカードの動作は、このようになっています。ツリーの既存のブランチに含まれない DNS 名を検索すると (1 つ以上のラベルが欠落しているかどうかに関係なく)、その上にあるワイルドカード レコードと一致します。 は、左端のラベルである場合にのみワイルドカードとして機能する
    ことにも注意してください。はワイルドカードとして機能しますが、、はDNS ではワイルドカードではありません。 要求している「1 つのレベルのみ」の機能を実現しながらワイルドカードを使用する実用的な方法はないと思います (DNS ワイルドカード全般、または Route53 に固有の機能)。代わりに、実際に必要な特定の名前を追加することを検討するか (必要に応じて動的に)、それ以外の場合は通常のワイルドカードの動作で我慢してください。**.example.com*.foo.example.comfoo.*.example.comfoo*.example.com*foo.example.com

全体的に、DNS でワイルドカードを使用しないことが最善の選択肢であり、そうすればクライアントがこれらの望ましくない名前を使用して ELB に接続するという問題が発生しないのではないかと思います。

関連情報