Amazon 路線 53 的最佳實踐 DNS

Route 53 的資料平面 (包括運作狀態檢查) 和 Amazon 應用程式復原控制器 (ARC) 路由控制在全球分佈，即使在嚴重事件發生時也能提供 100% 的可用性和功能。它們互相整合，且不依賴於控制平面功能。這些服務的控制平面 (包括其主控台) 通常非常可靠，但它們的設計方式更集中，並優先考慮耐用性和一致性，而不是高可用性。對於災難復原期間容錯移轉等案例，建議您使用 Route 53 健全狀況檢查和ARC路由控制等功能，這些功能依賴資料層功能進行更新DNS。如需詳細資訊，請參閱 控制和資料平面概念 和部落格：使用 Amazon Route 53 建立災難復原機制。

這DNSTTL是DNS解析器用來決定記錄可以緩存多長時間而不對 Route 53 進行另一個查詢的數值（以秒為單位）。所有DNS記錄都必須為其TTL指定。建議的TTL數值範圍為 60 到 172,800 秒。

A 的選擇TTL是在延遲和可靠性以及對變化的響應能力之間的權衡。由TTLs於記錄較短，DNS解析器會更快地注意到更新記錄，因為它們必須更頻繁地查詢。這會增加查詢量 (以及成本)。隨著延長TTL，DNS解析器會更頻繁地回答緩存中的查詢，這通常更快，更便宜，並且在某些情況下，更可靠，因為它避免了 Internet 上的查詢。沒有正確的值，但值得考慮的是，對您來說更重要的是否是回應能力或可靠性。

設定TTL值時要考慮的事項包括：

如需詳細資訊，請參閱 TTL (秒)。

DNSCNAME記錄是一種將一個域名指向另一個域名的方法。如果解析DNS器解析 domain-1.example.com 並找到CNAME指向，則解析DNS器必須繼續解析domain-2.example.com，然後才能響應。domain-2.example.com這些記錄在許多情況下都很有用，例如，可用於在網站具有多個網域名稱時確保一致性。

但是，DNS解析器必須進行更多查詢才能回答CNAMEs，這會增加延遲和成本。在可能的情況下，更快且更便宜的替代方案是使用 Route 53 別名記錄。別名記錄可讓 Route 53 以 AWS 資源 (例如負載平衡器) 和相同託管區域內其他網域的直接回應回應。

如需詳細資訊，請參閱將互聯網流量路由到您的 AWS 資源。

如需詳細資訊，請參閱地理位置路由、Geoproximity 路由及以延遲為基礎的路由。

當您使用 Route 53 主控台建立或更新記錄或託管區域時API，或者需要一些時間才能在網際網路上反映變更。這就是所謂的變更傳播。雖然全域性的傳播通常需要不到一分鐘的時間，但偶爾會出現延遲的情況，例如，由於同步到一個位置的問題，或者在極少數情況下，中央控制平面內出現問題。如果您正在建立自動佈建工作流程，並且在繼續下一個工作流程步驟之前等待變更傳播完成很重要，請使用GetChangeAPI來確認您的DNS變更是否已生效 (Status =INSYNC)。

當您在中委派多個層級的子網域時DNS，務必從父區域委派。例如，如果您正在委派 www.dept.example.com，您應該從 dept.example.com 區域而不是從 example.com 區域執行此操作。從祖父至子區域的委派可能根本無法運作，或只能在不一致的情況下運作。如需詳細資訊，請參閱路由傳送子網域的流量。

避免建立大型單一回應。如果響應大於 512 字節，則許多DNS解析器必須重試TCP而不是重試UDP，這可能會降低可靠性並導致響應速度較慢。我們建議使用多值回答路由，此會選擇 8 個運作正常的隨機 IP 地址，以將回應保持在 512 位元組的界線內。

如需詳細資訊，請參閱多值回答路由和DNS回覆大小測試伺服器。