Windows Server 2012 R2DNSマネージャーのApexANAME / ALIASレコード
一部のDNSホストは、バックグラウンドで他のホスト名を解決することにより、オンザフライで（またはスケジュールされたジョブを介して十分頻繁に）決定されるIPアドレスを提供するAレコードを持つ方法を提供します。これは、example.com（www.example.comのようなサブドメインではない）が、IPアドレスが変更されるたびに人間の介入を必要とせずに、IPアドレスが時々変更されるホストをポイントする必要がある場合に使用されます。その結果、example.comを解決するとAレコードが生成され、そのAレコードのIPアドレスは、それ自体がCNAMEである可能性のあるanother.example.comのIPアドレスを検索することにより、ネームサーバーによって動的に決定されます。
DNS Made EasyとeasyDNSはそれを「ANAMEレコード」と呼び、Route 53はそれを「エイリアスリソースレコード」と呼び、CloudFlareはそれを「CNAMEフラットニング」と呼び、DNSimpleはそれを「ALIASレコード」と呼びます。彼らがそれを何と呼んでいるかに関係なく、ホスト名を解決するときに標準のAレコードが返されます。
かなり明白な概念ですが、これをどのように実装するかについての出版物に出くわしたことはありません。この動作をネームサーバー（Windows Server 2012 R2のDNSマネージャー）で複製する予定です。これを行うためのDNSマネージャーのプラグインはありますか？
編集：回避するために XY問題 症状の観点から問題から始めて、依存関係をたどって、解決策が何を持っているか、持っていないかを示しているので、完全な背景を提供します。試されました。
症状
Apexドメイン（example.com）へのSSL/TLS接続は、証明書の不一致を生成します。このような接続はあまり頻繁に試行されませんが、電子メールクライアントによる自動ホスト検出などにより、ますます試行されています。たとえば、クライアント向けのメールサーバーとしてExchangeを配置し、AndroidまたはMacMailで[email protected]をExchangeアカウントとして追加すると、自動ホスト検出によって「一般的な」ホスト名が取得されるようです。 example.com、mail.example.com、exchange.example.comなどのように、example.comの証明書のCNがexample.comではないことをユーザーに警告します。実際には、一致する証明書を持つexchange.example.comを使用していますが、自動検出では最初にexample.comを試行する必要があります。
不一致の警告は、Webブラウザが https://example.com を指している場合にも発生しますが、これは、ほとんどの人がhttpsのプレフィックスではなくexample.comをアドレスバーに入力することで軽減されます。 ：//なので、必要に応じてリダイレクトして https://www.example.com にアップグレードされます。 www.example.comにはCNAMEがあるため、CNの不一致がないホストを指すことができます。
一致する証明書のみがwww.example.comにあり、example.comにはないのはなぜですか？
一致する証明書を持つサーバー（ちなみに、example.comと* .example.comの両方に一致するSANエントリを簡単に持つことができます。問題はありません）は、AWS ELB（弾性負荷）にありますバランサー）IPアドレスはいつでも変更される可能性があることをAmazonが警告します。動的IPアドレスにより、ELBはそのホスト名を介してのみ参照されます。つまり、CNAME/ANAME/Flattening/etcです。そのため、www.example.comをELBにポイントすることはできますが、example.comをポイントすることはできません。 Amazonは、Route53を使用して制限を克服することをお勧めします。それが不可能な場合、唯一の解決策は、example.comのAレコードポイントをELBではなく、通常はELBがリバースプロキシするアップストリームサーバーにポイントすることです。
一致する証明書をそのアップストリームサーバーに配置してみませんか？
ELB自体だけが私に捧げられているので、ELBだけが私のワイルドカード証明書をインストールできます。アップストリームサーバーは、ホスティングプロバイダーの顧客間で共有されます。ホスティング会社にexample.comを証明書のSANのランドリーリストに追加してもらうこともできますが、不一致はありませんが、さまざまな理由でELBを最大限に活用することに興味があります。
制約
Win2012R2でDNSを社内で実行することに固定されていますが、復元力を得るには、すべてのWWWホストがAWS上にある必要があります。
問題の正確な状況を考えると、理想的な解決策は、example.comのHTTP要求をwww.example.comにリダイレクトするWebサーバーに頂点を向けることです。 www.example.comは、AWSが管理するDNSレコードのCNAMEにすることができます。
- サーバー上にapexAレコードを自動的に更新してAWSを「追跡」するソリューションをセットアップすることは可能ですが、これにより多くの不必要に複雑になり、期待どおりに機能するために内部インフラストラクチャに追加の依存関係が作成されます。私はこれを避けるために一生懸命努力します。
- このWebサーバーを自分で実行すると、明らかに独自の課題と依存関係が発生するため、注意を向けるのは自然なことです。問題（httpsを含む）を解決する商用サービスのexampleは wwwizer.com になります。私は彼らの無料の非SSL製品にリンクしているnotであることに注意してください。
- シンプルさと可用性の間の妥協点は、このリダイレクトを実行する、自分で実行するクラウドにシンプルなWebサーバーをセットアップすることです。あなたはまだウェブサーバーの実行に固執していますが、少なくともあなたの会社のローカルインフラストラクチャへの依存関係はなく、その可用性のためにSLAがあります。
一日の終わりに、あなたはあなたの頂点の記録が常に正しく機能していることがどれほど重要であるかを自問する必要があります。あなたの状況では、それはそのレコードを手で入力するユーザーのための安全策にすぎないはずです。サーバーとアプリケーションがこれを念頭に置いて構成されていることを確認してください。リスクを大幅に軽減する必要があります。物事がそのように維持されることを保証するために、設計ドキュメント（該当する場合）にも注意する必要があります。
アンドリューの答えは絶対に正しいものです。人々をWWWにプッシュすることを唯一の目的とする小さなウェブサーバーは、問題のウェブブラウザ側をうまく解決します。
メールの自動検出について、SRVレコードを調査しましたか？あなたがWindowsを実行していることを考えると、私は飛躍して、あなたがExchangeを実行していると推測します。その場合、OutlookはSRVに基づいて自動構成するため、証明書CNの不一致のシナリオは無視されます。
直交オプションに移ると、より良いクラウドを使用すると、この愚かさを完全になくすことができます（エニーキャスト固定IPの処理方法を知っているため）が、上位層のCDNを使用すると、その機能が組み込まれます。[N.b。私はHAサービスを提供するクラウドプロバイダーで働いています。]