Defaults.Exposed › 修復 › 網域名稱伺服器設定（多樣性與 SOA）

如何修復 網域名稱伺服器設定（多樣性與 SOA）

你的網域名稱伺服器是告訴整個網際網路在哪裡找到你網站和信箱的那本目錄。如果它們全都坐落在同一個網路上，而它一旦宕機，你的業務就會在同一刻從網際網路上消失——沒有網站、沒有信箱、什麼都沒有；而這些伺服器上一個草率的時鐘設定，還可能讓你做的改動卡上好幾天。

對您業務的關鍵影響： 如果你網域的每一台網域名稱伺服器都活在單一網路上，那個網路的一次宕機或攻擊，就會把你的網站和信箱一起帶下線——你照付著員工薪資和廣告費，卻沒有客戶能聯繫到你。另外，設定錯誤的 SOA 計時器會讓你的 DNS 改動（一台新伺服器、換一個郵件提供商、一次緊急重定向）傳播好幾天、而不是幾小時。

這會讓您付出什麼代價

• 你所有網域名稱伺服器所在的那個單一網路度過了糟糕的一下午——一次宕機或一次 DDoS 攻擊——於是你的網站和信箱在同一刻一起消失。客戶看到錯誤頁，你的銷售收件匣退信，而你的網站負責人除了等別人家的網路恢復，什麼也做不了。
• 一個大客戶的安全團隊做一次供應商檢查，發現你所有網域名稱伺服器都在一個提供商上、沒有備援，便把你的網域記為單點故障——給一份你本來能拿下的合約添了摩擦。
• 你換到一個新的 Web 主機或換了郵件提供商，但你 SOA 記錄裡一個錯誤的刷新計時器，讓別的 DNS 伺服器好幾天都還在派發你的舊地址——於是有些客戶落到一個已失效的網站上，你的郵件還一分為二。
• 一起安全事件迫使你緊急把流量重定向，但你的 SOA 計時器告訴全世界把你的舊記錄快取一週，於是你一小時前做的改動還沒傳到半個網際網路，而問題仍在繼續。
• 你的兩台網域名稱伺服器在名義上是兩個名字，卻解析到同一機架、同一網路上——所以你以為有的備援是個幻覺，一次故障仍會把一切帶下線。

為什麼它重要。 對你網站的每一次訪問、發給你的每一封郵件，都始於對你網域名稱伺服器的一次查詢。它們是你其餘線上存在所立足的地基。如果那個地基沒有備援，一次故障就會把一切同時打掉；如果它的計時值不對，你做的每一個改動都遲遲生效——而那恰恰是你最承受不起的時候。

一句話說清這是什麼

在任何人能聯繫到你的網站或給你發郵件之前，他們的電腦都得先問一個簡單的問題：這個網域到底住在哪裡？回答這個問題的伺服器，就是你的網域名稱伺服器（nameservers）。它們是你整個線上存在的目錄條目——是每位訪客、每封郵件最先觸及的東西，早在你的網站或收件匣捲入之前。

本頁涵蓋把那本目錄做對的兩個部分：

1. 多樣性——你是否有至少兩台網域名稱伺服器，它們是否坐落在網路中真正分開的部分，使一次故障無法把它們一次全部噤聲？
2. SOA 記錄——一條小小的權威起始（start of authority）記錄，保存著控制網際網路其餘部分把你 DNS 答案信任和快取多久的計時值。把計時器搞錯，你做的每個改動傳到全世界都要更久。

兩者都不光鮮。兩者都是地基。它們對的時候你從不會想起它們；它們錯的時候，你會在最糟糕的時刻發現。

這會讓你付出什麼代價

• **一切同時下線。**如果你所有網域名稱伺服器都活在一個網路上，而那個網路宕機或遭 DDoS 攻擊，你的網站和信箱就一起變黑。這不是理論——單一 DNS 提供商遭攻擊，曾把資源雄厚的大公司從網際網路上打掉將近一整天。有跨網路的備援，一次故障可以挺過去；沒有，那就是全軍覆沒。

• **栽在供應商檢查上的交易。**一個較大客戶的安全或採購團隊在簽約前做一次檢查，發現你所有網域名稱伺服器都集中在一個提供商上、沒有備援，便把你的網域標為單點故障。這是那種又小又可避免的污點，給一份你本來能贏的合約添了摩擦。

• **生效不了的改動。**你換 Web 主機、遷郵件提供商，或需要緊急重定向流量。你 SOA 記錄裡一個錯誤的刷新或過期計時器，讓別的 DNS 伺服器好幾天都還在提供你的舊答案。一半客戶落到新網站，一半落到已失效的；有些郵件流向舊提供商，有些流向新的。你一小時前做的改動還沒完成。

• **結束不了的緊急狀況。**安全事件期間，你需要現在就把流量從一台被攻陷的伺服器引開。如果你的 SOA 計時器告訴全世界把你的記錄快取一週，你的修復就在網際網路上慢慢爬，而問題還在不停地咬。

• **並不真實的備援。**你有兩台網域名稱伺服器，於是你以為有保障了——但兩台都解析到同一機架、同一網路。第一次硬體故障就把它們全端掉，而你指望的那張安全網從來就不存在。

它實際上是什麼

**網域名稱伺服器多樣性。**你的網域應當列出至少兩台網域名稱伺服器，理想情況下它們應坐落在真正獨立的網路路徑上——而不只是指向同一台機器的兩個名字。在幕後，每個網域名稱伺服器名都解析到一個或多個 IP 地址，而真正要緊的是那些地址是否佔據網際網路路由的不同部分。一個正經的 DNS 提供商把它的網域名稱伺服器分布在全球許多獨立的網路區塊和地點，所以即便是來自同一提供商的兩台網域名稱伺服器，也能給你真實、獨立的備援。失敗情形則相反：某個小主機，兩台網域名稱伺服器是同一台機器，於是一次故障即是全部。

**給技術讀者的說明：**我們的檢查會數你的 NS 記錄，然後看它們背後坐落著多少真實的網路多樣性。主要信號是這些網域名稱伺服器解析進的不同 IP 網路區塊的分布（大致是 IPv4 的 /16 範圍和 IPv6 的 /32），以不同提供商名稱的數量作為後備。這有意為 Anycast 超大規模提供商——Cloudflare、Google、AWS Route 53、Azure DNS——加分，它們從許多全球分開的路由路徑上宣告同一個網路身份，因而即便來自單一品牌也能提供真實的多樣性。少於兩台網域名稱伺服器在本檢查上得零分，並被當作高嚴重級，因為它是整個網域的一個未緩解的單點故障。

**SOA 記錄。**每個 DNS 區域恰好有一條權威起始記錄。它指明主網域名稱伺服器和管理聯絡人，帶著一個每次改動都會遞增的序列號，而且——對你業務最要緊的部分——保存著四個計時器：

• 刷新（Refresh）——次級網域名稱伺服器隔多久向主伺服器重新核對一次改動。良好範圍：大約 1 到 24 小時（3,600–86,400 秒）。
• 重試（Retry）——一次刷新失敗後多快再試一次。良好範圍：大約 5 到 60 分鐘（300–3,600 秒）。
• 過期（Expire）——次級伺服器在完全聯繫不上主伺服器時，還能繼續提供你記錄多久。良好範圍：大約 1 到 4 週（604,800–2,419,200 秒）。
• 最小 TTL（Minimum TTL）——答案（包括此名稱不存在這類答案）被快取時長的下限。應取一個合理的正值；300 秒是常見選擇。

良好的狀態長什麼樣：一條存在的 SOA，有一個有效的管理聯絡人，並帶著落在上述範圍內的計時器。範圍之外的值並非致命——但它們要麼拖慢你的改動（計時器太長），要麼不必要地給你的網域名稱伺服器加負載（太短）。一條缺失或確實壞掉的 SOA 是更嚴重的情形。

如何修復（免費，約 15 分鐘）

這部分給管理你網域或 DNS 的人——如果那不是你，就把這一節交給他們。修復是免費的；我們只為監控它是否一直保持修復狀態而收費。

第一步——確保你在多樣化的基礎設施上擁有至少兩台網域名稱伺服器。

1. 看看你今天有什麼。執行 dig NS yourdomain.com（或用任意 DNS 查詢網頁工具），把網域名稱伺服器讀出來。兩台或以上是最低要求。
2. 如果你只有一台、或兩台都在一個小主機上，就把你的 DNS 遷到一個預設就給你備援的提供商。幾乎每一家正經提供商都這麼做：
   • Cloudflare——你添加網域時，自動分配兩台分布在其全球 Anycast 網路上的網域名稱伺服器。
   • AWS Route 53——每個託管區域獲得四台跨獨立 Route 53 網路的網域名稱伺服器。
   • Google Cloud DNS / Microsoft 365 / Azure DNS——同樣在獨立基礎設施上設定多台網域名稱伺服器。
3. 要切換，就在你的註冊商（你買網域的地方）把你網域的網域名稱伺服器設成新 DNS 提供商給你的那些。這個改動可能要 24–48 小時才完全傳播。
4. 為求雙保險，較大或較高風險的企業可以從第二個獨立提供商跑次級 DNS（如 Cloudflare + Route 53，或 NS1 + Cloudflare）。對大多數小企業來說這是可選的——單一一家信譽良好的提供商已經給了你真實的跨網路備援。

第二步——檢查（必要時修復）你的 SOA 計時器。

1. 執行 dig SOA yourdomain.com，把刷新、重試、過期和最小 TTL 值讀出來。
2. 拿它們和上面的範圍比對。絕大多數情況下，你的 DNS 提供商已經設好了合理的預設值，沒什麼要做的。
3. 如果某個值超出範圍，就在你 DNS 託管的地方修它：
   • 在託管型提供商上（Cloudflare、Route 53、Google、Azure），SOA 基本替你處理好了；你通常透過提供商的 DNS 設定或支援來調整它，而不是手動編輯。
   • 在自運行的網域名稱伺服器上（BIND、PowerDNS），直接編輯區域檔案裡的 SOA 行並重載該區域——記得遞增序列號，好讓次級伺服器拾取改動。
4. 任何改動後，重新執行查詢，確認網域名稱伺服器列表和 SOA 計時器都看起來對。

常見錯誤

• **把兩個名字當成兩個網路。**兩個解析到同一台機器或機架的網域名稱伺服器名，是披著偽裝的單點故障。要緊的是獨立的網路路徑，不是名字的數量。
• **以為越多越好、卻無多樣性。**五台都在一個脆弱主機上的網域名稱伺服器，並不比一台更安全。多樣性勝過數量。
• **把計時器設得太激進。**把 SOA 刷新或最小 TTL 一路擰到讓改動即時生效，只會狂敲你的網域名稱伺服器，還可能讓宕機更糟，幾乎沒有真實好處。合理的預設值已經在速度和負載之間取了平衡。
• **把過期設得太低。**如果主伺服器宕機期間次級伺服器過早停止提供你的區域，一次可恢復的小故障就變成了一次徹底宕機。把過期保持在以週計的範圍。
• **手動編輯區域卻忘了序列號。**在自運行的網域名稱伺服器上，只有當 SOA 序列號增加時，次級伺服器才拾取改動。改了記錄卻不動序列號，你的修復永遠傳播不出去。
• **把 DNS 留在網域註冊商的裸預設上。**有些註冊商內建的 DNS 是單一、極簡的設定。把 DNS 遷到一個正經的提供商，通常一步就給你備援和合理的 SOA 計時器。

歸根結底

你的網域名稱伺服器及其 SOA 記錄，是其餘一切所立足的地基。兩台坐落在真正分開網路上的網域名稱伺服器，意味著一次故障無法把你整個業務一次帶下線；合理的 SOA 計時器，意味著你做的改動確實及時傳到全世界。兩者做對都免費，兩者通常在你一上一個像樣的 DNS 提供商時就已處於良好狀態，兩者都值得花兩分鐘檢查一下——因為它們重要的那一天，恰恰是你最承受不起它們出錯的那一天。

常見問題