對於多租戶應用程序，鍊式 CNAME 的更好替代方案？

假設我有一個多租戶網路伺服器，它為 500 多個域執行應用程序。我有一個 AWS Loadbalancer url，my_application.elb.eu-west-1.amazonaws.com，它有A並AAAA記錄到實際的 LB。現在我要確保我擁有的所有域都指向這個 LB。然後我會看到三個選項：

1. 從我的 LB 中讀取A和AAAA記錄，並為每個域複製它們。
2. 為每個域做一個CNAME記錄，到 LB url（AWS 建議的解決方案）
3. 註冊一個自定義域，例如 applicationdns.com，並CNAME為 LB url 創建一條記錄，例如www.applicationdns.com。然後為每個域創建一條CNAME記錄到該記錄 ( www.applicationdns.com )。

當然，選項 1 效率極低，因此立即被丟棄。

選項 2 是建議的方法，效果很好。但是，如果在任何時候我需要將負載均衡器遷移到不同的 URL，我需要修復 500 多個 DNS 記錄，這些記錄可能分佈在多個提供商上，因此很難實現自動化。

選項 3 可以解決這個問題，但是它引入了“鍊式CNAME”。從我所看到的（RFC 1034）來看，這在技術上是有效的，但不被認為是好的做法。

應對這一挑戰的最佳方法是什麼？還有另一種可能有效的方法嗎？

當您能夠註冊自定義域以指向 AWS Route53 中的負載均衡器時，您實際上可以創建別名A（和AAAA）記錄，其功能類似於CNAME記錄。這可以防止連結CNAME記錄，但仍允許您在必要時遷移 Loadbalancer url。

這也在AWS 文件中進行了解釋，如果您想支持 IPv6，您可以重複 AAAA 記錄的描述過程。

從自動化的角度來看，選項 1 和 2 自動化相同。借助模板 + 變數，可以非常迅速地擴展託管配置。

我個人更傾向於 1 而不是 2，因為CNAME在域解析方面需要額外的步驟，同時不會為配置的簡易性增加任何真正的好處，前提是（再次）您使用託管配置並且您不手動更新它們。

總而言之，關鍵是您如何管理數百個域的配置。由於您使用的是外部供應商，因此他們的 API 質量似乎是值得關注的標誌。如果您選擇自託管/託管的權威名稱伺服器，即使是舊技術也允許動態重新載入各個區域，因此實際上沒有什麼阻礙自動（推出？）部署。

引用自：https://serverfault.com/questions/1065198