系统设计 / DNS · 层级、委任、缓存，以及不存在的「浸透」 / 注册一个域名：谁在管，之后该做什么 待审核 10 / 11
registry · registrar · 基线

注册一个域名：谁在管，之后该做什么

前面各页讲的都是技术机制。域名还有一条行政链，而它决定了几件技术上无从解释的事——比如为什么改 NS 要去注册商的面板，而不是改自己的 zone。

1 · 域名的管理链

ICANN 是一个多方参与的协调机构，负责根 zone 的内容与顶级域的分配。它不直接卖域名，也不运营根服务器（那是 12 家运营组织的事，见第 4 讲）。

registry（注册局）是某个 TLD 的运营方，持有该 TLD 的 zone 并对它有权威。通常一个 TLD 一家，例如 .com 由 Verisign 运营、.dev 由 Google Registry 运营。

registrar（注册商）受理最终用户的注册请求并转交给 registry。一个 TLD 可以有很多家 registrar；用户与 registrar 之间还可能隔着一层 reseller（代理）。

用户下单的对象是 registrar，而数据落地的地方是 registry。这解释了那件事：vega.dev 的委任 NS 存在 dev 这个 zone 里，而那个 zone 归 registry 管——所以只能通过 registrar 把「请把我的委任改成这两台服务器」这个请求提交上去，不能自己改。

注 · 由此也能看出「域名归属」的实际形态：它不是一份产权，而是父 zone 里一条委任加一份注册记录。两者都由别人持有。这不是比喻——注册记录被劫持（registrar 账号被攻破）与父 zone 的委任被改，两者中任何一个都足以让域名易手，而技术上 zone 数据一点没变。所以 registrar 账号的安全（强认证、注册商锁 registry lock）与 zone 本身的配置至少同等重要。

2 · 选 registrar 时值得看的

价格之外有几项在出事时才显出差别：

首年价与续费价。域名是长期持有的，首年折扣对总成本影响很小，而续费价差别可以是数倍。

账号安全的支持程度。是否支持强认证、是否提供 registry lock（在 registry 一侧加锁，改动需要额外的带外确认）、以及支持渠道在半夜是否有人。

是否在 DNSSEC 的路上添堵。DS 记录必须经 registrar 提交给 registry。有些 registrar 不提供这个入口，或者只支持部分算法——那就等于该域名无法签名。要签 DNSSEC 就得先确认这一项。

权威服务器不必用它的。registrar 通常附带一套 DNS 托管，但完全可以用别家、或者自建。区别在于：自建要自己保证可用性与 RFC 合规（第 3 讲那些计时器、第 2 讲那些结构约束），托管则要接受对方的实现——包括面板写入与实际生效之间那段不受协议约束的延迟（第 9 讲 §4）。

3 · 注册之后的基线

有一组记录与「这个域名在不在用」无关，注册了就该写。

图 3-1 · 按用途生成的 zone 片段与基线检查。片段由本系列的 zone 解析器真实解析并做结构检查；可把「收发邮件」关掉观察 null MX 那一组。

DNSSEC 签名。让应答可验证。它不提供机密性，也不解决全部问题（第 7 讲），但没有它，缓存投毒无从察觉。签完还要把 DS 提交给 registrar，否则这一环没建立、zone 在验证方眼里仍是未签名的。

null MX（RFC 7505）。不收邮件的域名应显式写 MX 0 .。它的作用是让发送方立刻失败，而不是按邮件重试策略反复投递到超时——后者通常要几天。

SPF 与 DMARC。真在用邮件的域名要各自配好，且 DMARC 应从 p=none 起步观察一段再收紧。而不用邮件的域名更需要写：v=spf1 -all 加 p=reject 明确宣告「本域名不发信」。什么都不写等于宣告策略未定，于是这个域名成了冒用发信的低成本素材。

CAA（RFC 8659）。限定哪些 CA 可以为本域名签发证书。它不能撤销已签发的证书，但收窄了误签与滥签的面，而这一条的成本几乎为零。

警示 · 上面这几条里，只有 DNSSEC 是「不做也能正常工作」的。其余四条的共同特征是：不做的代价由别人承担，而后果记在该域名上。缺 null MX 让发信方白等几天，缺 SPF / DMARC 让域名被拿去冒用，缺 CAA 扩大了误签的面。这是它们与一般性能优化的区别，也是为什么它们应当在注册当天就做完，而不是等到「开始用这个域名」的时候。

4 · 一件与技术无关但会咬人的事

域名到期不续会被放回可注册状态，而市场上有专门抢注过期域名的服务（drop catching），针对的正是那些有历史流量与外链的名字。

这件事对本系列有个直接推论：域名一旦公开使用过，就不宜再让它过期。曾经指向过某个服务的名字被别人拿到之后，历史链接、老客户端的硬编码、以及仍在缓存里的记录都会把流量送到新持有者那里——而 §3 那几条基线记录里，v=spf1 -all 与 DMARC 保护的也仅仅是持有它的这段期间。

5 · 参考文献

  1. Levine, J., & Delany, M. (2015). A Null MX Resource Record for Sites That Accept No Mail (RFC 7505). IETF.
  2. Kitterman, S. (2014). Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (RFC 7208). IETF.
  3. Kucherawy, M., & Zwicky, E. (Eds.). (2015). Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 9989). IETF.（RFC 7489 已于 2026 年被 9989–9991 一组取代并升为 Proposed Standard。）
  4. Hallam-Baker, P., Stradling, R., & Hoffman-Andrews, J. (2019). DNS Certification Authority Authorization (CAA) Resource Record (RFC 8659). IETF.
  5. Gudmundsson, O., & Huque, S. (2017). Managing DS Records from the Parent via CDS/CDNSKEY (RFC 8078). IETF.（把 DS 的提交自动化，减少对 registrar 面板的依赖。）
  6. ICANN. (2013). Beginner's Guide to Participating in ICANN. https://www.icann.org/en/system/files/files/participating-08nov13-en.pdf （经底本转引。）
  7. 大谷亘. DNS の基礎の基礎. 慶應義塾大学 SFC. 本地副本，Why DNS? 的 ICANN / registry / registrar 三层（p11–13）与附录一 ドメイン名を登録したら（p64–67）。 §1、§2 与 §3 的前三条（DNSSEC 签名、null MX、SPF 与 DMARC）出自该附录的 p65–66； §3 的 CAA 与 §4 的过期抢注不在其中，是另补的。