Azure DNS 透過使用 Microsoft Azure 基礎架構來提供名稱解析。 本文聚焦於公共 DNS 區域，通常你會為自己擁有的網域建立，並用來發布網路上可用的應用程式和服務的紀錄。 你解析的主機名稱是公開可存取的 DNS 名稱，而解析的 IP 位址通常是可從網際網路存取的公共 IP 位址。
Azure DNS 是一項非區域性服務，不受特定可用性區域或 Azure 區域約束。
當您使用 Azure 時， 可靠性是共同的責任。 Microsoft 提供一系列功能以支援韌性與復原。 您有責任瞭解這些功能在您使用的所有服務中如何運作，並選取符合業務目標和正常運作時間目標所需的功能。
本文說明 Azure DNS 公有區域如何回應暫時性故障、可用性區故障、區域性故障、服務中斷、安全威脅與設定錯誤、入口網站與管理工具故障，以及服務維護。 同時說明如何保護與還原您的區域配置，並說明關鍵的服務水準協議（SLA）要求。
可靠性的生產部署建議
對於 Azure DNS 公開區域的生產部署，請遵循以下建議以提升可靠性：
委派給所有名稱伺服器：Azure DNS 會為每個公共 DNS 區域指派四個名稱伺服器。 將你的網域委派配置為使用所有四個名稱伺服器。 此配置提供故障隔離，且為符合 Azure DNS SLA 資格所必需。
設定適當的 TTL 值： 設定存活時間（TTL）值，以平衡查詢量與客戶端接收紀錄變更的速度。 較低的 TTL 值讓客戶端能更早收到變更，但同時增加查詢量。 較高的 TTL 值會降低查詢量，但在您變更記錄後，可能會導致容錯移轉延遲。
為支援的 Azure 資源使用別名紀錄：別名記錄在 DNS 解析時自動反映底層 Azure 資源的變更，並幫助防止 DNS 紀錄過時。
可靠性架構概觀
本節說明服務運作中從可靠性角度來看最為重要的部分。 本節介紹邏輯架構，包含你部署和使用的部分資源與功能。 它還討論了物理架構，其中提供了有關服務如何在幕後工作的詳細信息。
邏輯架構
你部署的主要資源是一個 區域，裡面包含了網域的 DNS 記錄集。 記錄集將 DNS 名稱與一個值（例如 IP 位址或端點）關聯起來。 公共 DNS 區域解析的名稱可透過網際網路存取。
要讓 Azure DNS 對你的網域具有權威性，請將網域委派給 Azure 在建立區域時指派的名稱伺服器。 委派建立後，你要為 Azure DNS 支援的 DNS 記錄類型建立紀錄集。 你也可以建立別名紀錄，參考 Azure 資源，例如公共 IP 位址、流量管理員設定檔和 Azure Front Door 端點，讓 DNS 紀錄與目標資源保持同步。
在 DNS 解析過程中，遞迴 DNS 解析器會依照 DNS 階層來存取你區域的 Azure DNS 權威名稱伺服器。
Important
Azure DNS 會解析名稱，但不會監控端點健康狀況或路由應用程式流量。 整體解決方案的可靠性取決於 DNS 記錄所指資源的配置，例如虛擬機和負載平衡器。
本文不涵蓋這些資源，但它們的可用性配置直接影響應用程式的韌性。 請參考 你解決方案中 Azure 服務的可靠性指南 ，了解每個服務如何支援你的可靠性需求。
實體架構
Azure DNS 作為非區域性服務運作，並在全球多個 Azure 區域的多個可用性區域部署其基礎設施。 此設計使 Azure DNS 在可用性區域或區域中斷期間仍能保持韌性，因為其他區域或區域的基礎設施持續回應解析請求。
全球網際網路協定如 Anycast、DNS 和 BGP 會自動將收到的 DNS 解析請求導向最近的健康 Azure DNS 基礎架構。
Azure DNS 服務平面採用主動-主動組態，橫跨兩個彼此獨立的服務堆疊：一個執行於 Linux，另一個執行於 Windows。 這些堆疊不共用程式碼，也沒有底層硬體。 由於這兩個堆疊彼此獨立，影響其中一個堆疊的錯誤、弱點或故障不會影響另一個堆疊。 這種獨立性降低了單點故障導致完全服務中斷的風險，並有助於防範某些類型的零時差漏洞。
對瞬態故障的彈性
暫時性錯誤是元件中的短暫間歇性失敗。 它們經常出現在雲端等分散式環境中，而且是作業的一般部分。 暫時性錯誤會在短時間內自行修正。 請務必確保您的應用程式能妥善處理暫時性錯誤，通常透過重試受影響的請求來進行。
所有雲端託管應用程式在與任何雲端託管的 API、資料庫及其他元件通訊時，都應遵循 Azure 暫態故障處理指引。 如需相關資訊，請參閱處理瞬態故障的建議。
Azure DNS 透過其全球 DNS 基礎設施處理暫時性錯誤。
若在 DNS 解析過程中發生暫時性錯誤，用戶端或中介解析器應依其設定的 DNS 重試行為重試。 對 DNS 用戶端而言，2 到 5 秒的逾時時間通常已足夠。
每個 DNS 紀錄的存活時間（TTL）也會影響你的解決方案如何處理故障。 如果 TTL 非常低，客戶端需要向 Azure DNS 發出更多請求，且出現短暫故障的可能性也增加。 如果 TTL 非常高，當後端伺服器發生真正的故障需要你重新導向到另一個 IP 位址時，客戶端可能會在故障轉移時遇到延遲，直到 TTL 到期。 請謹慎配置 TTL，以平衡可用性、延遲與回應速度。
對可用性區域故障的抵抗力
可用性區域 是 Azure 區域內物理上獨立的資料中心群組。 當某個區域發生故障時，服務可以切換至其他剩餘的區域。
Azure DNS 作為非區域性服務運作。 Microsoft 將其基礎設施分布在多個 Azure 區域的多個可用性區域，並將變更複製到你的公共 DNS 區域。 你不需要選擇可用性區或設定區塊冗餘。 在可用性區域中斷期間，其他區域或區域的基礎設施仍持續回應解決請求。
如果你部署到單一可用性區域的資源，例如虛擬機（VM），在區域故障時變得無法使用，Azure DNS 仍會回傳該資源已設定的 IP 位址，因為它不會監控端點健康狀況。 如果你切換到健康區域的資源，你必須更新 DNS 紀錄，讓客戶端使用該健康資源。 或者，將資源放在區域冗餘負載平衡器後面，將流量導向健康區域的虛擬機。
對區域範圍故障的復原能力
DNS 區域對區域中斷具有韌性，因為區域資料是全球可用的，且部署到多個 Azure 區域。 如果某個區域發生故障，你部署在該區域的資源，例如虛擬網路和虛擬機，可能會無法使用，但 Azure DNS 仍會繼續解析你區域內的紀錄。
如果你的解決方案需要在多個區域間切換，例如災難復原，可以考慮使用 Azure 流量管理員 或 Azure Front Door。 這些服務提供自動故障轉移功能，當區域狀況不佳時可以使用。
對安全威脅與錯誤配置的韌性
安全攻擊與設定錯誤是 DNS 區域中兩大最嚴重的可靠性風險。 有幾類攻擊專門針對 DNS 解析，意外設定錯誤也可能嚴重干擾你的工作負載。
如需針對公共 DNS 區域的完整安全指引，請參閱「保護你的 Azure DNS 部署」及「保護 DNS 區域與紀錄」。
服務中斷的韌性
Azure DNS 是一項高度韌性的服務，當您的應用程式符合特定條件時，服務等級協議（SLA）可達 100%。 服務中斷非常罕見，但網路問題或其他基礎設施的問題都可能中斷與 Azure DNS 服務的連線。
Azure DNS 的韌性部分來自其全球分布式、主動服務平面架構。
使用多個名稱伺服器
Azure DNS 會為每個公共 DNS 區域指派四台名稱伺服器。 當你委派網域時，設定四個名稱伺服器。 如果解析器無法連到一個名稱伺服器，它可以查詢另一個。
監視服務中斷情形
使用 Azure 服務健康狀態 來監控 Azure DNS 的健康狀況。 設定 服務健康警示 以通知您服務事件。
服務中斷測試
Azure Chaos Studio 提供錯誤，模擬某些測試工作負載中的 DNS 解析失敗。 這些錯誤不會觸發 Azure DNS 的中斷。 Chaos Studio 代理程式提供 DNS 故障錯誤，而 AKS Chaos Mesh 則提供 DNS 混亂功能。 利用這些錯誤來測試當 DNS 解析失敗時，例如部分網路故障時，你的應用程式和基礎設施的反應。
入口網站與管理工具故障的韌性
如果你在 Azure 入口網站管理公共 DNS 區域，請準備一條替代管理路徑，以應對無法存取入口網站的情況，特別是在中斷時可能需要重新設定區域時。
如果Azure入口網站無法使用，請使用Azure CLI、Azure PowerShell或基礎設施代碼（IaC），如 Bicep 或 Terraform 來管理你的公共 DNS 區域。 即使 Azure 入口網站功能受損，這些工具仍能正常運作。
備份與還原
Azure DNS 是一個無狀態服務。 它不為公用 DNS 區域提供受管備份或時間點還原。
為了保留完整的 Azure 資源配置，請使用 IaC 定義你的公共 DNS 區域，例如 Bicep 或 Terraform，並將定義儲存在原始碼控制中。 定期測試定義，這樣你才能用它們重新部署你的設定。
作為額外的記錄層級復原選項，可以 匯出一個相容 BIND 的區域檔案。 區域檔案匯入有其限制，且無法保留所有 Azure 專屬的資源設定，所以不要只用匯出的區域檔案作為唯一的復原工具。 在還原區域後，請檢視文件中的匯入限制並核實相關紀錄。
服務維護的韌性
Microsoft 定期執行服務更新及其他維護。 Azure 平台自動處理這些活動，確保維護過程對您來說無縫且透明。 除非您收到透過 Azure 服務健康狀態 計畫維護 的通知，否則維護期間將不會有停機。
服務等級協定
Azure 服務的服務層級協議（SLA）描述了每項服務的預期可用性，以及您的解決方案必須符合的條件，以達成該可用性預期。 欲了解更多資訊，請參閱線上服務的服務等級協議。
Azure DNS 提供 100% 可用性 SLA，適用於有效的 DNS 查詢回應，只要符合特定條件即可。 這些條件包括連續至少 60 秒重複嘗試失敗請求，以及使用 Azure DNS 指派給你區域的所有名稱伺服器。 請審閱SLA文件中的詳細條件。