本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon Route 53 的最佳實務
本節提供 Amazon Route 53 各種元件的最佳實務，包括：
1. **DNS 最佳實務：**
+ 了解存留時間 (TTL) 值和回應能力與可靠性之間的權衡。
+ 盡可能使用別名記錄而非 CNAME 記錄，以提高效能並節省成本。
+ 設定預設路由政策，確保所有用戶端都收到回應。
+ 利用以延遲為基礎的路由，將應用程式延遲和地理位置/地理位置鄰近性路由降至最低，以實現穩定性和可預測性。
+ 使用自動化工作流程的 `GetChange` API 驗證變更傳播。
+ 從父區域委派子網域以進行一致的路由。
+ 使用多值答案路由來避免大型單一回應。
1. **解析程式最佳實務：**
+ 避免將相同的 VPC 與解析程式規則及其傳入端點建立關聯，以防止路由迴圈。
+ 實作安全群組規則，以減少連線追蹤開銷並最大化查詢輸送量。
+ 使用多個可用區域中的 IP 地址設定傳入端點以進行備援。
+ 請注意潛在的 DNS 區域行走攻擊，並在端點遇到限流時聯絡 AWS Support。
1. **運作狀態檢查最佳實務：**
+ 遵循最佳化 Amazon Route 53 運作狀態檢查的建議，以確保可靠監控您的資源
透過遵循這些最佳實務，您可以最佳化 DNS 基礎設施的效能、可靠性和安全性，確保將流量有效率地路由至應用程式和服務
**Topics**
+ [Amazon Route 53 DNS 的最佳實務](best-practices-dns.md)
+ [VPC Resolver 的最佳實務](best-practices-resolver.md)
+ [Amazon Route 53 運作狀態檢查的最佳實務](best-practices-healthchecks.md)
# 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/)。
# VPC Resolver 的最佳實務
本節提供最佳化 Amazon Route 53 VPC Resolver 的最佳實務，涵蓋下列主題：
1. **使用解析程式端點避免迴圈組態：**
+ 確保相同的 VPC 未與解析程式規則及其傳入端點建立關聯，以防止路由迴圈。
+ 利用 AWS RAM 跨帳戶共用 VPCs同時維護適當的路由組態。
如需詳細資訊，請參閱[避免對 Resolver 端點使用迴圈組態](best-practices-resolver-endpoints.md)
1. **擴展解析程式端點：**
+ 實作安全群組規則，以允許以連線狀態為基礎的流量減少連線追蹤開銷
+ 遵循傳入和傳出解析程式端點的建議安全群組規則，將查詢輸送量最大化。
+ 監控產生 DNS 流量的唯一 IP 地址和連接埠組合，以避免容量限制。
如需詳細資訊，請參閱[Resolver 端點擴展](best-practices-resolver-endpoint-scaling.md)
1. **Resolver 端點的高可用性：**
+ 在至少兩個可用區域中建立 IP 地址的傳入端點以進行備援。
+ 佈建其他網路介面，以確保在維護或流量激增期間可用性
如需詳細資訊，請參閱[Resolver 端點的高可用性](best-practices-resolver-endpoint-high-availability.md)
1. **防止 DNS 區域行走攻擊：**
+ 請注意潛在的 DNS 區域行走攻擊，攻擊者會嘗試從 DNSSEC 簽署的 DNS 區域擷取所有內容。
+ 如果您的端點因為可疑的區域行走而遇到限流，請聯絡 AWS Support 尋求協助。
如需詳細資訊，請參閱[DNS 區域遍歷](best-practices-resolver-zone-walking.md)
透過遵循這些最佳實務，您可以最佳化 VPC Resolver 部署的效能、可擴展性和安全性，確保應用程式和資源的可靠且有效率 DNS 解析。
# 避免對 Resolver 端點使用迴圈組態
請勿將相同的 VPC 與 Resolver 規則及其傳入端點建立關聯 (無論是端點的直接目標，還是透過內部部署 DNS 伺服器)。當 Resolver 規則中的傳出端點指向與規則共用 VPC 的傳入端點時，可能會造成迴圈，其中查詢會持續在傳入端點和傳出端點之間傳遞。
轉送規則仍然可以使用 AWS Resource Access Manager () 與其他 帳戶共用的其他 VPCs 建立關聯AWS RAM。與樞紐或中央 VPC 相關聯的私有託管區域仍會從查詢解析到傳入端點，因為轉送解析程式規則不會變更此解決方案。
# Resolver 端點擴展
Resolver 端點安全群組使用連線追蹤來來收集傳入和流出端點的相關資訊。每個端點截面都有可以追蹤的連線數目上限，而且大量的 DNS 查詢可能會超過連線數，引發調節和查詢丟失。連線追蹤是監控流經安全群組 (SGs) 之流量狀態 AWS的預設行為。在 SGs 中使用連線追蹤將降低流量的輸送量，不過，您可以實作未追蹤的連線，以減少額外負荷並改善效能。如需詳細資訊，請參閱[未追蹤連線](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections)。
如果使用限制性安全群組規則強制執行連線追蹤，或透過 Network Load Balancer 路由查詢 （請參閱[自動追蹤連線](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#automatic-tracking))，端點的每個 IP 地址每秒的整體查詢上限可能低至 1500。
**傳入解析程式端點的傳入和傳出安全群組規則建議**
****
|
|
| **傳入規則** |
| --- |
| 通訊協定類型 | 連接埠號碼 | 來源 IP |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
| **輸出規則** |
| --- |
| 通訊協定類型 | 連接埠號碼 | 目標 IP |
| TCP | All | 0.0.0.0/0 |
| UDP | All | 0.0.0.0/0 |
**傳出解析程式端點的傳入和傳出安全群組規則建議**
****
|
|
| **傳入規則** |
| --- |
| 通訊協定類型 | 連接埠號碼 | 來源 IP |
| TCP | All | 0.0.0.0/0 |
| UDP | All | 0.0.0.0/0 |
| **輸出規則** |
| --- |
| 通訊協定類型 | 連接埠號碼 | 目標 IP |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
**注意**
**安全群組連接埠需求：**
**傳入端點**需要輸入規則，允許連接埠 53 上的 TCP 和 UDP 從網路接收 DNS 查詢。輸出規則可以允許所有連接埠，因為端點可能需要回應來自各種來源連接埠的查詢。
**傳出端點**需要輸出規則，允許 TCP 和 UDP 存取您用於網路上 DNS 查詢的連接埠。連接埠 53 如上述範例所示，因為它是最常見的 DNS 連接埠，但您的網路可能會使用不同的連接埠。輸入規則可以允許所有連接埠容納來自 DNS 伺服器的回應。
**傳入 Resolver 端點**
對於使用傳入 Resolver 端點的用戶端，如果您有超過 40,000 個唯一 IP 地址和連接埠組合產生 DNS 流量，彈性網路介面的容量就將受到影響。
# Resolver 端點的高可用性
當您建立 VPC Resolver 傳入端點時，Route 53 會要求您建立至少兩個 IP 地址，以便網路上的 DNS 解析程式將查詢轉送到這些地址。您也應該在至少兩個可用區域中指定 IP 地址以進行備援。
如果您需要多個始終可用的彈性網路介面端點，建議您至少建立一個超過所需的網路介面，以確保有額外的容量可用於處理可能的流量激增。額外的網路介面也可確保維護或升級等維修作業期間的可用性。
如需詳細資訊，請參閱此詳細的部落格文章：[如何使用 Resolver 端點和 實現 DNS 高可用性](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/)[當您建立或編輯傳入端點時所指定的值](resolver-forwarding-inbound-queries-values.md)。
# DNS 區域遍歷
DNS 區域遍歷攻擊會嘗試從 DNSEC 簽署的 DNS 區域取得所有內容。如果 VPC Resolver 團隊偵測到流量模式符合在端點上行走 DNS 區域時產生的流量模式，服務團隊會調節端點上的流量。因此，您可能會觀察到高百分比的 DNS 查詢逾時。
如果您觀察到端點上的容量降低，並且認為端點已錯誤地進行調節，請前往 https://console.aws.amazon.com/support/home\$1/ 建立支援案例。
# Amazon Route 53 運作狀態檢查的最佳實務
有效的運作狀態檢查組態對於維護高可用性和彈性基礎設施至關重要。以下是設定和管理 Amazon Route 53 運作狀態檢查時應考慮的一些最佳實務：
1. **將彈性 IP 地址用於運作狀態檢查端點：**
+ 為您的運作狀態檢查端點使用彈性 IP 地址，以確保一致的監控。
+ 如果您不再使用 Amazon EC2 執行個體，請記得刪除任何相關聯的運作狀態檢查，以避免潛在的安全風險或資料洩露。
如需詳細資訊，請參閱 [您在建立或更新運作狀態檢查時指定的值](health-checks-creating-values.md)。
1. **設定適當的運作狀態檢查間隔：**
+ 根據您的應用程式需求和受監控資源的重要性，設定運作狀態檢查間隔。
+ 較短的間隔可提供更快速的故障偵測，但可能會增加 Route 53 成本並載入您的資源。
+ 較長的間隔可降低成本和資源負載，但可能會延遲故障偵測。
如需詳細資訊，請參閱 [進階組態 (僅限 "Monitor an endpoint")](health-checks-creating-values.md#health-checks-creating-values-advanced)。
1. **實作警示通知：**
+ 設定 Amazon CloudWatchalarms 在運作狀態檢查失敗或復原時接收通知。
+ 根據您的應用程式需求和 資源的預期行為，設定適當的警示閾值。
+ 將通知與您的監控和事件回應程序整合。
如需詳細資訊，請參閱 [使用 CloudWatch 監控運作狀態檢查](monitoring-health-checks.md)。
1. **策略性地利用運作狀態檢查區域：**
+ 根據使用者和資源的地理分佈選擇運作狀態檢查區域。
+ 考慮對關鍵資源使用多個運作狀態檢查區域，以提高可靠性並減少區域中斷的影響。
1. **監控運作狀態檢查日誌和指標：**
+ 定期檢閱 Route 53 運作狀態檢查日誌和 CloudWatch 指標，以識別潛在問題或效能瓶頸
+ 分析運作狀態檢查失敗原因，並採取適當的動作來解決基礎問題。
1. **實作容錯移轉和容錯回復策略：**
+ 利用 Route 53 的容錯移轉路由政策，在發生故障時自動將流量路由至運作狀態良好的資源。
+ 規劃和測試容錯移轉和容錯回復程序，以確保在中斷和復原期間無縫轉換。
如需詳細資訊，請參閱 [設定 DNS 備援](dns-failover-configuring.md)。
1. **定期檢閱和更新運作狀態檢查：**
+ 視需要更新運作狀態檢查端點、間隔和警示閾值，以維持最佳監控和效能。
透過遵循這些最佳實務，您可以有效利用 Amazon Route 53 運作狀態檢查來監控 資源的運作狀態和可用性，確保應用程式和服務具有可靠且高效能的基礎設施。