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 提供商时就已处于良好状态，两者都值得花两分钟检查一下——因为它们重要的那一天，恰恰是你最承受不起它们出错的那一天。

常见问题