AWS Route 53 で IP ベースのルーティングに /32 CIDR ブロックを設定できないのはなぜですか?

AWS Route 53 で IP ベースのルーティングに /32 CIDR ブロックを設定できないのはなぜですか?

次の簡単なシナリオを考えてみましょう。

NAT 設定

オフィス ネットワークがあり、そこには HTTPS などを通じて何らかのサービスを提供するサーバーがあります。 という名前でこのサーバーにアクセスできるようにしservice.example.com、インターネット経由だけでなくオフィス ネットワーク内からもアクセスできるようにしたいと考えています。

これを実現するために、インターネット側に静的 IP を持つルーターを設置し、TCP ポート 443 を内部サーバーにリダイレクトするように設定します。

クエリを実行すると次の結果が返されるように DNS を構成したいと思いますservice.example.com

  • 10.0.0.2(内部IP)オフィスネットワーク内から照会された場合
  • 123.45.67.89(外部IP)オフィスネットワークの外部から照会された場合

私はすでにAmazon Route 53をDNSのあらゆるニーズに使用していますが、新しい機能があることに気付きました。IPベースのルーティングこれにより、クエリ元の IP に基づいて動的に返される複数の DNS レコードを作成できます。したがって、原則として、DNS レコードを次のように設定する必要があります。

  • service.example.com10.0.0.2クエリされたときに返される123.45.67.89
  • service.example.com123.45.67.89他の場所からクエリを実行したときに返される

ただし、Route 53 では個別の IP アドレスを設定できません。代わりに、最大 までのマスクしか持てない CIDR ブロックを登録する必要があります。したがって、個別の IP アドレス (マスク付き)/24を設定することはできません。/32

これには何か理由があるのでしょうか? 私の見方は間違っているのでしょうか? 私が考えた代替解決策は次のとおりです:

  • に、すべての社内 PC の手動ルートを書き留めます/etc/hosts。ただし、この設定は、社内ネットワーク上にあるときもあれば、外部にあるときもあるようなラップトップでも機能するようにします。ラップトップを家に持ち帰るたびに、ユーザーにルートを変更するように求めるのは合理的ではないと思います/etc/hosts
  • このためだけに、ネットワーク内に DNS サーバーをセットアップします。この 1 つのユースケースのためだけに、これは非常に負荷の高い操作になると思います。この内部サーバーへのトラフィックは最小限であることを考えると、オフィス ネットワーク内のすべての DNS クエリを処理するサーバーをセットアップしたくありません。
  • NAT の使用をやめて、/24静的 IP のブロック全体を取得します。これは私のニーズには過剰だと思います。
  • どこからでもアクセスできる IPv6 を使用すれば、この問題は発生しません。これは私が現在行っていることですが、多くの人はまだ自宅のネットワークに IPv6 を導入していないため、IPv6 のない人にはサービスがまったく利用できません。

これを設定する正しい方法は何でしょうか?

関連情報