本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Amazon Route 53 DNS 的最佳實務 使用 Amazon Route 53 DNS 服務時，請遵循以下最佳實務以獲得最佳結果。 **使用資料平面功能進行 DNS 備援和應用程式復原** Route 53 的資料平面，包括運作狀態檢查和 Amazon Application Recovery Controller (ARC) 路由控制是全域分佈的，專為 100% 可用性和功能而設計，即使在嚴重事件期間也是如此。它們互相整合，且不依賴於控制平面功能。這些服務的控制平面 (包括其主控台) 通常非常可靠，但它們的設計方式更集中，並優先考慮耐用性和一致性，而不是高可用性。對於災難復原期間的容錯移轉等案例，我們建議您使用 Route 53 運作狀態檢查和依賴資料平面功能更新 DNS 的 ARC 路由控制等功能。如需詳細資訊，請參閱 [控制和資料平面概念](route-53-concepts.md#route-53-concepts-control-and-data-plane) 和[部落格：使用 Amazon Route 53 建立災難復原機制](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)。 **為 DNS 記錄選擇 TTL 值** DNS TTL 是數值 (以秒為單位)，DNS 解析程式用來判斷在不對 Route 53 進行另一個查詢的情況下，可以快取多長時間的記錄。所有 DNS 記錄都必須具有為其指定的 TTL。TTL 值的建議範圍為 60 秒到 172,800 秒。 選擇 TTL 是為了在延遲和可靠性以及對變化的回應能力之間進行權衡。如果記錄上的 TTL 較短，DNS 解析程式會更快地注意到記錄的更新，因其必須更頻繁地查詢。這會增加查詢量 (以及成本)。當您延長 TTL 時，DNS 解析程式會更頻繁地從快取中回答查詢，這樣通常更快、更便宜，而且在某些情況下更可靠，因為這樣可以避免透過網際網路進行查詢。沒有正確的值，但值得考慮的是，對您來說更重要的是否是回應能力或可靠性。 設定 TTL 值時需要考慮的項目包括： + 將 DNS 記錄 TTL 設定為您能夠等待變更生效的時間長度。在委派 (NS 記錄集) 或其他很少變更的記錄 (例如 MX 記錄) 上更是如此。對於這些記錄，建議選擇較長的 TTL。通常可選擇介於一小時 (3,600 秒) 到一天 (86,400 秒) 之間的值。 + 對於作為快速容錯移轉機制的一部分而需要更改的記錄 (特別是經過運作狀態檢查的記錄)，較短的 TTL 更為合適。在這種情況下，將 TTL 設為 60 秒或 120 秒是常見的選擇。 + 當您想要變更關鍵 DNS 條目時，我們建議您暫時縮短 TTL。然後，如果有需要，您就可以快速進行變更、觀察和回復。在最終確定變更並如預期運作之後，您可以增加 TTL。 如需詳細資訊，請參閱 [TTL (秒)](resource-record-sets-values-shared.md#rrsets-values-common-ttl)。 **CNAME 記錄** DNS CNAME 記錄是一種將一個網域名稱指向另一個網域名稱的方法。如果 DNS 解析程式解析 domain-1.example.com 並找到指向 domain-2.example.com 的 CNAME，則 DNS 解析程式必須繼續解析 domain-2.example.com，之後才能做出回應。這些記錄在許多情況下都很有用，例如，可用於在網站具有多個網域名稱時確保一致性。 但是，DNS 解析程式必須進行更多查詢才能回答 CNAME，這會增加延遲和成本。在可能的情況下，更快且更便宜的替代方案是使用 Route 53 別名記錄。別名記錄允許 Route 53 直接回應 AWS 資源 （例如負載平衡器） 和相同託管區域內的其他網域。 如需詳細資訊，請參閱[將網際網路流量路由到您的 AWS 資源](routing-to-aws-resources.md)。 **進階 DNS 路由** + 使用地理位置、地理位置鄰近性或以延遲為基礎的路由時，請務必設定預設值，除非您想要某些用戶端收到*無回答*的回應。 + 若要最大限度地減少應用程式延遲，請使用以延遲為基礎的路由。這種類型的路由資料可能會經常變更。 + 若要提供路由穩定性和可預測性，請使用地理位置或地理位置鄰近性路由。 如需詳細資訊，請參閱[地理位置路由](routing-policy-geo.md)、[地緣臨近度路由](routing-policy-geoproximity.md)及[以延遲為基礎的路由](routing-policy-latency.md)。 **DNS 變更傳播** 當您使用 Route 53 主控台或 API 建立或更新記錄或託管區域時，需要一些時間才能在網際網路上反映變更。這就是所謂的*變更傳播*。雖然全域性的傳播通常需要不到一分鐘的時間，但偶爾會出現延遲的情況，例如，由於同步到一個位置的問題，或者在極少數情況下，中央控制平面內出現問題。如果您正在建置自動佈建工作流程，重要的一點是要等待變更傳播完成，才能繼續執行下一個工作流程步驟，使用 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API 驗證您的 DNS 變更是否已生效 (`Status =INSYNC`)。 **DNS 委派** 當您在 DNS 中委派多個級別的子網域時，務必始終從父區域委派。例如，如果您正在委派 www.dept.example.com，您應該從 dept.example.com 區域而不是從 example.com 區域執行此操作。從*祖父*至*子*區域的委派可能根本無法運作，或只能在不一致的情況下運作。如需詳細資訊，請參閱[路由傳送子網域的流量](dns-routing-traffic-for-subdomains.md)。 **DNS 回答大小** 避免建立大型單一回應。如果回應大於 512 位元組，許多 DNS 解析程式必須透過 TCP (而不是 UDP) 重試，這可能會降低可靠性並導致回應速度較慢。我們建議使用多值回答路由，此會選擇 8 個運作正常的隨機 IP 地址，以將回應保持在 512 位元組的界線內。 如需詳細資訊，請參閱 [多值答案路由](routing-policy-multivalue.md) 和 [DNS 回覆大小測試伺服器](https://www.dns-oarc.net/oarc/services/replysizetest/)。