ICANN 批准的一项变更，将允许 Verisign 停止受理和维护使用量持续下降的三级 .name 域名注册。Neil Fraser 的披露让这项看似普通的产品下线受到关注：约 22,000 名注册者可能受到影响，而部分二级域名如果随后被释放并重新分配，新持有人便可能重建原有三级域名，从而制造身份冒用、邮件劫持和账户找回风险。
这并不等于 ICANN 直接“允许身份盗窃”。真正的问题在于，域名退出机制是否充分考虑了一个事实：域名早已不只是网站地址，它还是许多系统默认采用的身份锚点。
三级注册为什么会形成特殊风险
传统域名通常由注册者直接控制二级域名，例如 example.name。三级 .name 注册则可能表现为：
alice.smith.name
在这种结构中，用户持有的是 alice.smith.name，但并不一定拥有其父级 smith.name。一旦三级注册终止，而 smith.name 又被释放给其他人，新持有人理论上可以重新创建：
alice.smith.name
www.alice.smith.name
mail.alice.smith.name
如果历史用户曾把这些名称用于网站、邮件或登录身份，攻击面就不止是“旧网页被别人接手”：
- 新持有人可以发布一个外观相似的网站，诱导访客继续信任旧地址。
- 如果旧地址曾接收邮件，攻击者可能配置 MX 记录或全域收件规则，捕获仍发送到旧地址的消息。
- 某些账户可能仍把旧邮箱用于密码重置、账单通知或管理员验证。
- 文档、代码仓库、名片、软件包元数据和历史论坛帖子中的链接不会自动更新。
- 新控制者可以正常完成 DNS 或 HTTP 域名验证，并为重建的主机名申请新证书。HTTPS 证明的是当前域名控制权，而不是历史身份连续性。
风险是否真正出现，取决于 Verisign 的具体释放流程、保留期、命名冲突处理以及二级域名是否会开放给新注册者。现有摘要没有给出这些实施细节，因此不能假设每一个受影响名称都会立即落入第三方手中。不过，只要父级名称存在重新分配的可能，就应按潜在的身份接管事件处理，而不是普通续费失败。
先找出组织对旧域名的隐性依赖
受影响的团队不应只检查主页。真正难迁移的通常是散落在其他系统中的身份引用：
- DNS 与流量入口：A、AAAA、CNAME、MX、NS、TXT 和 CAA 记录。
- 邮件身份：收件地址、转发规则、邮件列表、SPF、DKIM 与 DMARC。
- 账户恢复：云平台、代码托管、域名注册商、支付和社交账号中的恢复邮箱。
- 软件供应链：包维护者邮箱、签名身份、容器镜像说明、Webhook 与 OAuth 回调地址。
- 公开历史记录：README、PDF、博客、会议资料、名片和搜索引擎缓存。
- 证书与密钥：当前 TLS 证书、自动签发任务，以及绑定域名的应用配置。
下面的脚本可以为一个恰好包含三个标签的 .name 域名生成 DNS 快照，同时检查它的二级父域。运行前安装 dig；Debian/Ubuntu 可以执行 sudo apt-get install dnsutils，macOS 可以执行 brew install bind。把示例域名换成自己的域名：
#!/usr/bin/env bash
set -euo pipefail
DOMAIN="${1:?用法: $0 alice.smith.name}"
IFS='.' read -r -a LABELS <<< "$DOMAIN"
if (( ${#LABELS[@]} != 3 )) || [[ "${LABELS[2]}" != "name" ]]; then
echo "错误：请输入类似 alice.smith.name 的三级 .name 域名" >&2
exit 1
fi
PARENT="${LABELS[1]}.${LABELS[2]}"
snapshot() {
local name="$1"
echo "## $name"
for type in A AAAA CNAME MX NS TXT CAA SOA; do
echo "### $type"
dig +noall +answer "$name" "$type" \
| awk '{$2="<TTL>"; print}' \
| sort
done
echo
}
snapshot "$DOMAIN"
snapshot "$PARENT"
保存为 audit-name.sh 后运行：
chmod +x audit-name.sh
./audit-name.sh alice.smith.name | tee dns-baseline.txt
在迁移期间可以再次执行并比较结果：
./audit-name.sh alice.smith.name > dns-current.txt
diff -u dns-baseline.txt dns-current.txt || true
这个脚本只能记录公开 DNS 状态，不能证明注册权，也不能判断域名是否已经进入删除、保留或重新开放阶段。注册状态、到期日期和争议政策仍应直接向注册商或注册局确认，并保存书面回复。
迁移不能只做一次 DNS 切换
如果组织仍能控制旧名称，可以这样实践迁移：
- 先注册并长期持有一个由自己直接控制的二级域名。
- 在新域名上部署网站与邮箱，验证 TLS、SPF、DKIM 和 DMARC 后再切换业务。
- 更新所有重要账户的登录邮箱、恢复邮箱、OAuth 回调地址和 Webhook。
- 在仍可控制旧域名时保留 HTTP 跳转与邮件转发，但不要把它当成永久保障。
- 主动通知客户、合作方和员工，并说明准确的新域名与生效时间。
- 搜索代码和配置中的旧域名，例如：
grep -RIn --exclude-dir=.git --exclude='*.lock' \
'alice\.smith\.name' .
- 检查公开代码托管平台、软件包索引和搜索引擎中是否仍展示旧地址。
- 为旧域名的 DNS 变化、证书透明度记录和疑似钓鱼页面设置持续监测。
需要特别注意的是，301 跳转和邮件转发只有在旧域名仍由原用户控制时才有意义。一旦父域被重新分配，这些配置可能全部由新持有人重写。HSTS、旧证书或浏览器书签也无法证明新站点仍属于原来的个人或组织。
注册者、平台和治理方分别该做什么
受影响注册者应尽快确认自己的域名是否在范围内，并向注册商索取终止时间表、续费安排、数据迁移方式以及父级二级域名的后续处置规则。如果域名曾承载重要身份，还应保存注册凭证、付款记录、DNS 快照、邮件配置和对外使用证据。已有用户考虑通过法律途径挑战决定，但具体行动应咨询熟悉域名政策和当地法律的专业人士。
平台运营者也需要修正“邮箱或域名永久属于同一主体”的假设。对于高价值操作，不应仅凭发送到历史域名的邮件完成账户恢复；更稳妥的做法是结合 MFA、恢复码、人工审核和已验证设备。
从治理角度看，停止低使用量产品可以降低运营复杂度，但域名回收不能照搬普通资源清理流程。更安全的方案通常需要较长通知期、明确的迁移支持，以及针对历史名称的永久保留、不可重新注册或受限分配策略。否则，节省下来的注册局维护成本，可能转化为数万名用户长期承担的身份安全成本。
一份可执行的下线检查表
- [ ] 确认三级
.name注册是否受影响，以及准确的终止日期。 - [ ] 导出 DNS、邮件、证书和付款记录。
- [ ] 盘点所有使用旧域名的网站、账户、仓库和文档。
- [ ] 建立独立控制的新二级域名并完成并行验证。
- [ ] 更新登录与恢复邮箱，而不只是公开联系地址。
- [ ] 通知用户和合作方，给出唯一、明确的新域名。
- [ ] 持续监控旧名称及其父域的 DNS、证书和钓鱼活动。
- [ ] 对关键身份或品牌名称评估政策申诉与法律选项。
三级 .name 注册的退场提醒我们：域名可以作为产品被停止，却不能轻易从互联网的历史记忆中删除。只要旧名称仍留在收件箱、账户数据库和用户习惯里，它就仍然是一份需要妥善移交或永久封存的安全凭证。