如何設定自動 DNS 解析切換

自動解析切換解決了一個常見問題。你可以透過基於 DNS 的容錯移轉和健康檢查來設定自動 DNS 解析切換。這種方法能夠減少停機時間和人工干預，同時增強伺服器叢集的高可用性。

你將學習如何完成前置準備、選擇自建或雲端方案、定義健康檢查探針，然後控制記錄更新。你也將測試容錯移轉行為，並驗證在網路事件發生後，流量是否會到達正確的伺服器。每一步都建立在前一步之上，因此你可以從準備到驗證，掌握一套完整的工作流程。本指南將提供實作步驟，協助你達成這個目標。

DNS 容錯移轉的前置條件

準備伺服器與 DNS 存取權限

你需要一個已註冊的網域，並由支援自動健康檢查和 API 驅動更新的服務商進行管理。建議至少規劃兩台位於不同區域或資料中心的伺服器。一台作為主要伺服器，另一台在主要伺服器發生問題時接手服務。你也需要存取服務商的管理控制台或 API，並對 A 記錄、CNAME 記錄以及 TTL 值有基本了解。

在容錯移轉生效之前，你可能需要修改某個 DNS 伺服器項目，或驗證現有記錄。請檢查你的路由器管理介面，例如 192.168.1.1，並查看 Windows 11、macOS 和 Linux 上作業系統層級的 DNS 設定。在 Windows 11 中，Dnscache\Parameters 登錄機碼下的四個 DWORD 值可以收緊容錯移轉行為：

重新開機後，這些變更才會生效。之後，當主要 DNS 伺服器停止回應時，次要 DNS 伺服器幾乎可以立即接手。

定義健康檢查端點

一個可靠的健康檢查端點應驗證真實的應用程式健康狀態，而不只是回傳一個 200 狀態碼。它應確認資料庫連線、快取可用性以及關鍵相依項是否正常。對於 HTTP 檢查，請求類似 /health 的特定路徑，預期回傳 2xx 或 3xx 狀態碼，並將逾時時間設為 5–10 秒。對於 HTTPS，請驗證 TLS 握手，並可選擇強制驗證憑證有效性。對於 TCP，請確認連接埠能在逾時時間內接受連線。

使用多個健康檢查位置可以避免因網路問題導致誤判。請在容錯移轉觸發前先監控狀態並對故障發出警示。定期測試容錯移轉，例如每季進行一次演練，並記錄人工處理程序。如果你計畫之後變更 DNS 伺服器設定，請保持這些記錄為最新，以確保你的自訂 DNS 伺服器和 DNS 伺服器位址在整個網路中始終準確。

如何設定自動 DNS 解析切換

自建 DNS 方案

當你在自己的硬體上設定自動 DNS 解析切換時，BIND 可以提供完整控制。首先使用 rndc-confgen -a -b 512 -r /dev/urandom 產生 rndc 驗證金鑰，該指令會將金鑰寫入 /etc/rndc.key。可透過將該檔案的擁有者設定為 root:named、權限設定為 0640 來強化其安全性。在主要設定檔 named.conf 中，載入 rndc 金鑰檔，並定義一個 controls 區塊，允許在 127.0.0.1 的 953 連接埠上使用 rndc-key 進行 rndc 管理。定義主區域時，使用 allow-update { key rndc-key; }; 和 notify yes;，以便動態更新通過驗證。在從屬伺服器上，接受來自主伺服器的區域傳送，並使用相同金鑰允許更新。編輯動態區域檔前，先執行 rndc freeze <zone>，然後執行 rndc reload <zone> 和 rndc thaw <zone> 以重新啟用更新。使用 nsupdate -k /etc/rndc.key 可在無需重新啟動的情況下進行即時修改，並透過 named-checkconf、named-checkzone 和 rndc status 驗證一切是否正常。

「Hi Tarwan，也許 failover 不是描述它的最佳詞彙。用 master-slave replication 可能更貼切。你仍然能從更高的可用性中受益，因為如果你的 master 當機，slave 擁有所有記錄，並且可以繼續提供服務。」

對於更輕量的部署，dnsmasq 搭配健康檢查腳本也很適合。你的腳本會探測主要伺服器，然後在探測失敗時重寫 dnsmasq 的 hosts 項目並發送 SIGHUP 訊號。這樣可以讓切換過程保持在本機端且足夠迅速。

雲端 DNS 容錯移轉路由

AWS Route 53 以不同方式處理容錯移轉。它不會重寫已儲存的記錄，而是在查詢時做出路由決策。你可以為每個資源建立健康檢查，或者對別名記錄將 Evaluate Target Health 設為 Yes。接著建立主要記錄和備援記錄，它們需要具備相同的名稱、類型和路由策略，並分別綁定各自的健康檢查。將 Routing Policy 設為 Failover，並指定 Primary 與 Secondary 記錄類型。當健康檢查回報主要資源不健康時，Route 53 會以健康的備援記錄回應查詢。你可以透過 CloudWatch 指標（例如 HealthCheckStatus 和 HealthCheckPercentageHealthy）以及警示、Lambda 檢查和 EventBridge 規則來監控這個流程。

Azure 將這項工作拆開處理。Azure DNS 本身不提供健康檢查，因此你需要再搭配 Traffic Manager 作為第二項服務來實現容錯移轉路由。

如果你在用戶端變更某個 DNS 伺服器項目或變更 DNS 伺服器設定，解析優先順序也取決於介面度量值以及 DNS 伺服器順序。在正式環境中變更 DNS 伺服器之前，請先規劃好這些因素，並記錄整個網路中每一項與變更 DNS 伺服器相關的調整。

健康檢查與切換邏輯

選擇 DNS 健康檢查探針

你選擇的探針類型決定了健康檢查實際能發現什麼問題。Ping（ICMP）可以確認主機的基本可達性，但防火牆經常會阻擋它，而且它無法證明應用程式本身正常運作。連接埠（TCP）檢查可以確認某個服務連接埠是否接受連線，但無法判斷應用程式邏輯是否正常。HTTP(S) 探針會請求像 /health 這樣的路徑，並預期獲得 2xx 或 3xx 狀態碼，因此它是 Web 服務最有力的健康訊號。將 ICMP 與 TCP 或 HTTP(S) 結合使用，你就能同時捕捉網路層與服務層的故障。

時間參數決定了檢測速度。請根據你期望的恢復時間來設定健康檢查間隔，以及觸發容錯移轉前所需的連續失敗次數。常見做法是設定一個在快速檢測與減少誤判之間取得平衡的失敗閾值。

探針會透過 HTTP、HTTPS、TCP 或 ICMP，以可設定的間隔測試每個端點，並可提供更快的檢查間隔。檢查會同時從多個區域發起，因此單一路徑上的網路不穩不會觸發誤切換。

重試機制還增加了一層保障。你可以設定多少次連續失敗後將裝置標記為離線，以及多少次連續成功後將其恢復上線。這些參數將決定容錯移轉與恢復所需的時間。

自動化記錄更新與 TTL

自動化會用 API 呼叫取代人工在控制台中的修改，因此每一次變更都能同步到所有平台。請使用 DNS 服務商提供的 API（REST、Terraform 或 SDK）來自動修改記錄，並套用以角色為基礎的存取控制，同時保留稽核日誌。在各個權威副本之間複寫區域內容，以確保在容錯移轉發生前，備援回應已經準備就緒。

TTL 決定了解析器會信任一個回應多久。較低的 TTL 有助於更快完成容錯移轉。在計畫中的變更之前，應提前足夠時間降低 TTL，以便舊的快取回應過期。某些解析器會強制執行 30 秒的最小下限，因此低於這個值並不能被穩定遵循。

介面度量值和 DNS 伺服器順序也會決定解析優先順序。當你設定自動 DNS 解析切換時，請在投入正式環境前規劃好這些因素。一個設定了兩個 DNS 項目的用戶端會優先查詢清單中的第一個伺服器，而在多宿主主機上，介面度量值會用來打破優先順序平手。請記錄每一項變更 DNS 伺服器所需的調整，並在整個網路中保持連線記錄為最新狀態。

測試並驗證容錯移轉

模擬故障並查看日誌

如果你從未真正觸發過容錯移轉，就不能真正信任這套方案。停止主要服務、阻擋其健康檢查連接埠，或拔掉它的網路連線。觀察 DNS 記錄需要多久才會切換到備援伺服器。然後檢查服務商日誌或 BIND 查詢日誌，確認切換發生的準確時間點。

接著查看健康檢查歷史。留意失敗次數、時間戳記以及恢復事件。乾淨的日誌應只顯示一次清楚的狀態轉換；而混亂的日誌則表示出現抖動，這代表你的閾值設定過於敏感。請依計畫重複演練，並記錄每個步驟花了多少時間。

驗證變更 DNS 伺服器設定

用戶端行為決定了容錯移轉是否真的能幫助使用者。在 Windows 11 上，手動指定一個 DNS 項目，並確認解析器確實使用了新的 DNS 伺服器位址。在 macOS 上，可以透過終端機中的 networksetup 指令設定 DNS 伺服器並驗證變更。

你也可以在 Cisco 交換器上變更 DNS 伺服器，並將記錄對應到正確的主機。每次變更後，都應清除快取並再次查詢該名稱。確認回傳結果指向健康的伺服器，同時檢查那些仍由 DHCP 管理的用戶端是否依舊自動取得 DNS 伺服器位址。在宣告測試完成之前，請從多個網路路徑驗證連通性。

現在你已經掌握完整流程：準備伺服器與 DNS 存取權限、選擇自建或雲端方案、定義健康檢查探針、調整切換邏輯，然後驗證結果。自動化能讓你的 DNS 回應保持準確，並加快事故應變速度。

請透過以下習慣來維護這套設定：

• 每次故障後重新檢視健康檢查閾值。
• 關注 TTL 對傳播速度的影響。
• 保護 DNS 憑證與 API 金鑰安全。
• 在基礎架構變更後重新測試容錯移轉。

在你的解析器設定中加入多個解析器，並使用虛擬 IP 容錯移轉工具，在健康檢查腳本失敗時移轉虛擬 IP。監控 DNS 解析器狀態。務必先在預備環境中設定自動 DNS 解析切換，再部署到正式環境，這樣你的伺服器與網路才能保持韌性。

常見問題

自動容錯移轉究竟多快可以切換流量？

檢測時間取決於你的探針設定，例如健康檢查間隔，以及觸發容錯移轉所需的連續失敗次數。降低檢查間隔和失敗閾值可以更快偵測到問題，但也要防範因單一封包遺失造成誤判。

不使用雲端服務商也能執行容錯移轉嗎？

可以。你可以在自有硬體上使用 BIND 搭配 rndc，或使用健康檢查腳本。腳本會探測主要伺服器，在探測失敗時重寫 hosts 項目並發送 SIGHUP 訊號。這能讓切換保持在本機端且足夠迅速。

為什麼容錯移轉後，用戶端仍然連到已當機的伺服器？

很可能是解析器快取了舊的回應。請檢查該記錄的 TTL。標準 A 記錄可能有預設 TTL，這會讓快取資料在切換後仍保留很長時間。清除快取後重新查詢該名稱，以確認結果是否已更新。

在計畫切換前，我應該將 TTL 設定為多少？

應在計畫變更前足夠早地降低 TTL，以便舊的快取回應能夠過期。某些解析器會強制執行 30 秒的最小下限，因此低於這個值並不能被穩定採用。

兩台伺服器都需要健康檢查嗎？

需要。只檢查主要伺服器並不能確認備援伺服器是否真正可用。請同時探測兩個端點，使用多個檢查位置，並在容錯移轉觸發前對異常發出警示。每季測試一次完整鏈路，這樣你才能真正信任結果。