在 如何为你的私有网络选择 TLD(顶级域名) 中，描述了 TLD 的选择。这篇文章算是续集，讲讲服务器的命名。
mnx.io 主张的最佳实践 #
mnx.io 是一家主机托管商，其官网的公开博客上有一篇发表于 2014-06-10 的关于服务器命名的最佳实践博文：A Proper Server Naming Scheme。按文章的说法，这套最佳实践适合大多数的中小企业，可以轻松管理 1500+ 的服务器。我将通过下面的几个子章节简要概述一下文章的主张。
使用 FQDN #
使用 DNS 系统，给主机设置真正的 FQDN。
这意味着你需要有一个配置了 TLD 的本地 DNS 服务器。
选择合适的 Label 设置 A 记录 #
选择好合适的 Label 后直接设置 A 记录。例如使用 crimson：
crimson.example.com. A 192.0.2.11
不理解
Label这个术语的可以自行阅读 RFC 1035 2.3.1. Preferred name syntax，或者简单参考 Route 53 DNS domain name format 的文档摘抄：Domain names (including the names of domains, hosted zones, and records) consist of a series of labels separated by dots.
通常情况下，Label 不应该表示出含有真正的目的或功能的词，而只是一个代表了唯一 ID 的名字、一个代号、一个标识符。
应该如何选择具体的 Label，文章给出了一个词典：Oren Tirosh’s mnemonic encoding project，建议从其中随机挑选。这份词典中精心挑选的 1633 个单词具备以下特征：
- 极短 (4 - 7 letters)，简洁明了
- 发音上容易区别，可以轻松通过语音交流识别（例如电话讨论），国际化交流无障碍
- 书面不易出现混淆问题，如拼写错误，字符互换等
字符互换的典型例子就是数字
0和字母O
设置 CNAME 来附加信息 #
有了最基础的 FQDN，你就可以给它设置一个或多个别名 (CNAME) 来丰富这个服务器的功能详细信息，典型的有：
- 地理位置
- 环境 (
dev、test、prod) - 组织架构
- 业务能力、代号
总之，在此处将附加信息保持规范、结构化就易于将其与 CMDB 关联，可以有效降低使用人员的脑力负担。并且得益于 DNS 的分层设计，在 DNS 记录上这些信息可以非常清晰的以层层递进的方式展现，例如：
-
先使用 5 个字符的 联合国贸易和运输地点代码 UN / LOCODE 表示地理位置：
<wip>.nyc.example.com. CNAME crimson.example.com. -
接下来标识上环境：
<wip>.prd.nyc.example.com. CNAME crimson.example.com. -
最后，附上具体功能及序号：
web01.prd.nyc.example.com. CNAME crimson.example.com.
针对特殊情况的策略变化 #
当然, 总是存在一些特殊情况, 需要违反上述的准则进行灵活的调整。常见的情况有以下几种:
-
专用网络和电力设备。由于此类设备硬件跟用途牢牢绑定, 可以在 Label 中使用功能单词的缩写直接指向 A 记录：
vpn01.nyc.example.com. A 192.0.2.1 -
辅助 IP 和虚拟 IP。这类对象从本质上来说也是与功能/用途绑定的, 也建议与上述一样处理：
sql01.nyc.example.com. A 192.0.2.1 -
邮件或 DNS 服务器。在 RFC 2181 的 10.3. MX and NS records 中明确提到, MX/NS 记录中配置的值不能是 CNAME 类型的 DNS 记录。这也就意味着邮件或 DNS 用途的服务器也只能使用 A 记录：
mta01.example.com. A 192.0.2.20
配置 Domain Name Search #
最后，可以在每个机器上配置 搜索域，来方便在服务器间使用短名进行通信。例如配置 NY 地区的 prd 环境使用：
search prd.nyc.example.com example.com
之后在其他服务器上发起的与这台服务器的网络通信（比如 ping、ssh 等命令）中就可以直接使用 sql01，而不是使用完整的 sql01.prd.nyc.example.com。
结语 #
虽然方案看起来不会有多复杂，只是稍微需要有结构性的思考和使用/配置本地 DNS 服务的前提条件，有一点门槛。但正如 mnx.io 的文章所指出的那样，它在可用性、可维护性和对长期增长的支持之间取得了很好的平衡。建议在实践过程中可以尽量参考使用他们的 Tips & Tricks 作为指导。
从理论上说，如果你的服务器数量超过了词典中的总词数 (1633)，那么在 Label 的选择上词典就没什么帮助了。我个人觉得，服务器数量超过 800 的话，或许可以考虑逐步转向使用特殊 ID 以适应未来的变化，也可以抛弃这个方案探索一条全新的道路。
在 OpenWrt 上的实践 #
理论有了，接下来简单聊聊我在家庭网络中通过 OpenWrt 主路由上的 Dnsmasq 实现的具体实践。全部操作均通过 LuCI Web 页面进行。
OpenWrt 版本是
v22.03.0。
进入 网络 -> DHCP/DNS，在默认的 常规设置 标签页，可以看见配置的 TLD 是 .lan。
进入 主机名映射 标签页，配置基础名字。
我使用的主机名单词都是从上述提到的那个词典中挑选的，对应节点的详情是:
| Hostname | Motherboard | OS | Description |
|---|---|---|---|
| unicorn | Supermicro X10SLM-F | PVE | OpenWrt 的 VM 所在的宿主机 |
| fiber | ASUS P9A-I | Debian | 一台冷备用途的存储机器 |
| axis | Supermicro X10DRL-i | PVE | 家中主要的 Homelab 设备 |
接下来，转到 CNAME 标签页进行配置日常使用的真正名字.
由于是家庭网络，就无需在 CNAME 的记录中使用地理位置、环境等信息，而是尽量选择个人易于记忆的，能显著代表功能的别名。例如 unicorn 实际使用的别名 netbox，就是因为它的主要用途是家里的主力网络处理设备，而 axis 的则是 homelab。
除了本地的 .lan TLD 之外，图上也可看出，我还使用了真实的，目前由我持有的 .z10n0110.men 这个 TLD。因为有 Let’s Encrypt 签发来的免费证书，我选择将这个域名用在各个服务的 HTTPS 端点上，比如 PVE 的 WEB 控制台：
配置完成后，使用 ping 测试一下：
$ ping -c 2 axis
PING axis.lan (192.168.15.6): 56 data bytes
64 bytes from 192.168.15.6: icmp_seq=0 ttl=64 time=10.607 ms
64 bytes from 192.168.15.6: icmp_seq=1 ttl=64 time=12.834 ms
--- axis.lan ping statistics ---
2 packets transmitted，2 packets received，0.0% packet loss
round-trip min/avg/max/stddev = 10.607/11.720/12.834/1.113 ms
$ ping -c 2 homelab
PING axis.lan (192.168.15.6): 56 data bytes
64 bytes from 192.168.15.6: icmp_seq=0 ttl=64 time=5.552 ms
64 bytes from 192.168.15.6: icmp_seq=1 ttl=64 time=5.422 ms
--- axis.lan ping statistics ---
2 packets transmitted，2 packets received，0.0% packet loss
round-trip min/avg/max/stddev = 5.422/5.487/5.552/0.065 ms
一切就绪后，只需要使用便宜的热敏打印机给每个机器贴上标签，标明最基础的/最关心的信息方便管理即可。
