在Azure上配置子域（通配符CNAME或基於Route 53的基於API的DNS）哪個更好？

Question

我正在Azure上構建一個需要為每個客戶使用子域的應用程序。 子域名將在注冊過程中提供。 由於Azure 需要使用CNAME來進行DNS解析 ，因此我必須在通配符CNAME之間進行選擇，還是應該使用諸如Amazon Route 53之類的API手動添加每個條目

我擔心通配符CName，因為存在一個問題 ，即所有DNS系統是否都完全支持它們。 我看到它是RFC規范的一部分，但我擔心所有DNS系統的最新情況。

另外，我擔心會為客戶實時設置新的CNAME DNS條目。 他們是否必須等待TTL過期，還是會立即提取新的子域CNAME條目？

謝謝，道格

Answer 1

DNS通配符就像您的DNS服務器的元信息。 它永遠不會離開名稱服務器，而只是指示您的服務器以某種方式對待DNS查詢。

您的DNS客戶端或其遞歸解析器不知道，不需要知道，也無法告訴*您正在使用帶通配符的CNAME。

您擁有的Serverfault鏈接僅意味着您將很難找到可以添加通配符的主機。

如果Amazon Route 53支持CNAMES的通配符，則假定生產服務器的其余部分符合其他DNS RFC，那么就可以進行生產。 您唯一需要關心通配符支持的其他時間是，如果您在其他提供商處使用輔助NS記錄。

關於TTL，需要注意兩個TTL：您創建的通配符CNAME或靜態CNAME的TTL。 然后是存儲在Microsoft名稱服務器中的A記錄TTL，您將無法控制它。 （您也無法控制SOA記錄中MSFT的NXDOMAIN到期，但這是一個切線）您需要考慮到，當在Prod和DEV之間切換時，將有客戶端將前者的A記錄緩存到A記錄到期之前。 如果您使用的是移動應用程序，那么我已經看到蜂窩ISP的緩存此條目的時間比預期的要長，有些手機的A記錄的緩存也要更長。 有時解決此問題的方法是重新啟動手機。

底線是不用擔心CNAME TTL，這是重要的A記錄，MSFT擁有此記錄。 進行挖掘或NSlookup來查看值。 如果找到支持通配符的NameServer，請繼續使用它，但是我擔心與其他RFC的安全性和兼容性。 我真的只信任我的ISP（ATT），UltraDNS和Dynect的DNS提供程序。 亞馬遜和UltraDNS有很好的關系。 除ATT之外的所有其他都有SOAP API。

如果要使用ATT，則可以將它們（或另一個ISP）用作輔助DNS服務器，並使其成為主要的NameServer。 然后，對隱藏的主DNS進行所有更改。

我討厭DNS，因此隨時可以提出后續問題。

*注：他們可以通過查詢RandomGUID.domain.com來判斷您是否正在使用CNAME。如果他們獲得相同的答案，那么他們可以假設您正在使用通配符CNAME。

Answer 2

我不知道有多少DNS系統支持通配符，但我確實知道DNS緩存失敗。 因此，如果用戶在您配置新域之前請求了新域（或者可能從基本域請求任何內容 ），那么他將需要等待TTL才能看到新條目。