背景
上一篇的空间模型里出现了两类域名：正式的 devops.example.com，和两字母的个人短域。这一篇讲这个短域是怎么来的、风险评估怎么做，以及让全公司能解析它时踩过的坑。
（脱敏起见，下文用 xx 代替实际使用的两字母短域，example.com 代替公司真实域名。）
一个真实的需求：域名太长
设计之初，域名方案顺理成章：服务用 devops.example.com 的子域。但把它给"人"用的时候，问题立刻出现——公司真实域名有十好几个字符，个人空间的全名会变成：
api.zhangsan.user.devops.example.com
这条名字打完手都酸了。个人空间的核心场景是临时联调、随手起名，名字长到这个程度，自助体验就死了。
内网的一个自由度：自定义顶级域
内网有一个公网没有的自由度：可以自己发明顶级域。
公网里你只能从注册商买域名；内网的解析完全在自己的权威 DNS 手里，你想让 xx 成为顶级域，它就能成为顶级域。解析不出外网——但内网名字本来就不需要出外网。
于是给个人空间申请了一个两字母短域 xx。个人名字立刻清爽了：
这不是替换 devops.example.com，是并列的另一条轨：稳定服务走正式域名，临时试验走短域。双轨各有各的规则，上一篇已经写过。
插曲：私有 TLD 的沟通成本
短域要在全公司生效，需要管理员在公司的递归 DNS 上加一条转发。沟通时出了个小插曲：管理员第一反应是"你要用 xx 替换 devops 域名？"——替换没有意义，他无法理解这个需求。
解释清楚"不是替换，是并列的另一个域"之后，事情立刻就办了。这个插曲给我提了个醒：私有 TLD 对很多网络管理员来说是个陌生概念。他们的经验里域名都是买来的、有注册商的，“自己发明一个顶级域"听起来像违规操作。后来我把解释话术固定下来：内网解析归自己管，这个域只在公司网络里存在，出了公司就查不到——就这三句。
风险评估：撞名怎么办
自定义 TLD 不是免费的，最大的风险是冲突：万一哪天 ICANN 把 xx 分配成真实的公网 TLD，内网和外网就有两个 xx，内外解析会打架。
评估的过程比结果有意思：
- 两字母 TLD 在现行规则下只可能是国家代码域（ccTLD），通用顶级域（gTLD）要求至少三个字母；
- 而 ccTLD 来自 ISO 3166 国家代码表，我们用的两字母组合恰好不在表里；
- 所以冲突风险从"现实风险"降为"理论风险”——理论上 ISO 可以给新国家分配这个代码，但这个概率和"公司网络撞名"相比可以忽略。
真实剩下的风险只有一个：多 VPN 撞名。如果合作方的内网也用了同一个短域，员工同时拨两个 VPN 时会解析错乱。这是自定义 TLD 的通病，防不住，只能记着。
风险对冲：让短域承载的东西本来就该死
评估完我又想了一层：为什么敢用一个有理论风险的域？
因为短域承载的记录本来就短命。个人空间的定位是临时试验场，记录默认过期回收；域随人走，人走域空。即使最坏情况发生（短域真的撞了名要换掉），换域的成本也就是改一条递归转发、通知一遍用户——上面没有沉淀任何长期资产。
反过来，真正需要长期稳定的名字（正式服务），全都走 devops.example.com，那是公司自己持有的公网域名，永远不会有冲突问题。
这个对冲逻辑可以一般化：风险高的命名方案，只承载短命的东西；长命的资产，必须放在可控性最高的命名空间里。
另一个选项为什么不行：.internal
写到这里必须提一下业界的标准答案。2024 年 7 月，ICANN 正式把 .internal 保留为私有用途 TLD，专供内网使用，承诺永不在公网分配——这不就是为我们这种场景准备的吗？
问题还是长：
api.zhangsan.user.xx.internal
.internal 八个字符，加上用户名和服务名，个人名字又回到"打一遍手酸"的水平。
有意思的是，ICANN 自己的论证文件（SAC113）在制定选择标准时，第四条写着：保留的名字要"相对短、好记、有意义"，并且直言"ICANN 可以保留一个字符串，但不能强迫人们使用它——太长或易忘的标签不太可能被使用，因此不会成功"。而最终选定的 .internal，恰好就踩在自己这条标准的边上。
为什么不是 .local 或 .lan？因为都被占了：.local 早在 2004 年就被 RFC 6762 分给了 mDNS（Bonjour 那套零配置发现），几亿台设备在用；.lan 被大量路由器的出厂默认域占用。短而干净的名字，在私有命名野蛮生长的几十年里已经全被占完了，只剩 .internal 这种长但无歧义的。
所以对个人短域这个场景，官方答案解不了我的问题。自定义短域 + 短命承载，仍然是务实的选择。但如果是给"整个企业内网"选正式私有域，.internal 是标准答案——场景不同，答案不同。
让全公司解析到它：递归转发
权威 DNS 建好后，全公司能解析的前提是公司的递归 DNS 知道去哪里问。技术上只需要一件事：
递归 DNS 上不需要创建 SOA——SOA 是权威的事，递归只要一条转发。
这是沟通过程中第二个概念障碍。管理员习惯的思维是"加一个域名 = 建一个 zone"，于是准备在递归上配置一堆东西。其实递归的角色只是"看到 xx 结尾的查询，转给内网权威"，一条 forward 规则就够了：
| 递归软件 | 配置写法 |
|---|
| dnsmasq | server=/xx/10.42.0.53 |
| unbound | forward-zone: name: "xx." forward-addr: 10.42.0.53 |
| BIND | zone "xx" { type forward; forwarders { 10.42.0.53; }; }; |
| Windows DNS | 新建条件转发器（Conditional Forwarder），填域名和 IP |
权威这边自己把 zone 里的 SOA 和 NS 记录补齐。严格按规范，内网域名还需要在递归侧有正确的委托链（NS 记录），但实际上一条转发规则就能工作——这是规范性和实用性的平衡，内网场景我选实用。
找管理员之前，我给自己列了个 checklist：权威的 53 端口可达、SOA/NS/测试记录都建好、当场 dig @递归 测试名 验证。一次沟通一次到位，不扯皮。
插曲：53 端口被占
测试部署时踩了一个值得记录的坑：权威 DNS 起不来，因为测试机的 53 端口被 systemd-resolved 占着（很多发行版默认开本地 stub resolver）。最后测试环境只能把权威跑在 5354 上。
这件事的教训不在测试环境，在生产：如果权威 DNS 真的跑在非 53 端口，转发目标端口要提前和管理员对齐——很多企业的 DNS 管理 GUI 里，条件转发器根本不让填非标端口。我的解决办法是：生产权威无论如何占住 53，把"端口对齐"这件事从沟通清单里删掉。
最后
域名的故事讲完了，回顾几条结论：
域名资产的命名要趁早：没铺开时换域成本最低，铺开后换域几乎不可能。
风险高的命名只承载短命资产；长命资产放在最可控的命名空间。
递归 DNS 上不需要 SOA，一条转发就够——概念对齐比技术实现更花时间。
有了名字，下一个问题立刻跟上来：浏览器访问这些名字时，HTTPS 证书怎么办？这是下一篇。