摘要

  • RFC 1123 允许 Internet 主机名以数字开头，RFC 1178 仍建议不要采用，因为一些已部署程序会把长得像数字的名称误判成地址。
  • RFC 1178 把名称视为任意标签；人的姓名、项目职责、地理暗示和特殊拼写都会随着机器、组织和语境变化而失真。
  • 合法标签不能证明程序走了哪条解析分支、本地搜索域补出了什么、DNS 返回了哪类记录、当前是谁在运行，也不能证明改名已经覆盖所有依赖。

“允许”与“好用”回答的不是同一道题

RFC 1178 是一份很克制的文件。它以 FYI 5 的身份在 1990 年 8 月发布，重刊一篇更早的文章，并明确说明自己不是标准。RFC Editor 记录与 IETF Datatracker 记录固定了出版身份；正文讨论的不是 DNS 怎样工作，而是一个名称怎样才不至于妨碍人和程序协作。

与它相邻的 RFC 1123 属于另一种文件。其第 2.1 节修改了从 RFC 952 继承的主机名规则：首字符不再只能是字母，也可以是数字；主机软件必须支持这种更宽松的语法。RFC Editor 的 RFC 1123 页面保留了它在 Host Requirements 中的标准身份。

RFC 1178 随后仍劝管理员不要用数字开头。原因不在 DNS 语法，而在入口程序：有些软件同时接受主机名和数值 Internet 地址，却不能可靠地区分二者；全由十六进制字符组成的名称也会制造类似歧义。标准说明“合规实现应当接受什么”，现场指南则追问“混杂的新旧程序会怎样理解它”。

因此，合法并不是一次端到端验证。它只完成了第一道门槛。部署中的程序是否更新、用户界面是否先把字符串归类为地址、后续是否真的发出 DNS 查询，都需要单独观察。

名称只是标签，不是机器简历

RFC 1178 最耐久的判断是：不要期待名称可靠描述机器。文件把名称称作任意标签，并用项目名说明语义为何会过期。一台最初服务车间的机器，后来可能增加同伴、拆分任务，再被调去无关项目。原本显得准确的标签会变成假说明；在后面追加 2、3，也只是把编号伪装成含义。

用人的姓名给桌面计算机命名同样会产生耦合。口头交流必须额外说明是在说人还是机器；人员和设备更换后，名称可能跟错对象。某个程序如果默认特殊外设或数据库还在旧机器上，即使“名字”被移给新机器，它依赖的事实也不会一起搬过去。

这给证据边界定下了很严格的线：主机名最多证明某个标签被配置、登记或发布。它不能证明机器现在承担什么职责、由谁保管、是否具备某外设、运行哪个服务，也不能证明这些事实在时间上连续。

DNS 查询之前，输入可能已经走错路

RFC 1123 不只放宽首字符。它还建议用户输入界面同时接受主机域名与点分十进制 IP 地址，并在查询 DNS 之前先做点分十进制语法判断。于是，名称解析之前就出现了一个程序决策点。

同一串字符，在程序甲中可能被归类为地址，根本不进入 DNS；在程序乙中可能被归类为名称，随后由解析器处理。RFC 1178 针对的正是这种不一致，而不是否定新语法本身。

更早的 RFC 952 曾要求 DoD 主机表名称以字母开头；其 RFC Editor 信息页记录了 RFC 1123 的更新关系。这段历史显示的是兼容迁移：规范先扩大了许可范围，所有程序与使用习惯却不可能在同一时刻收敛。

调查一个真实输入时，至少要保留原始字符串、接收它的应用和版本、它选择的解析分支、是否发出查询、查询类型、解析器与搜索域、当时缓存、返回结果以及后续连接。“这个名称合法”无法替代这些记录。

短名称从本地环境借来意义

RFC 1034 把完整域名与相对名称分开。完整名称抵达根；相对名称则由本地软件根据原点或搜索列表补全，而且用户界面的解释可以因实现而异。RFC Editor 信息页确认的是 DNS 概念文件的身份，不会替某个站点选择搜索路径。

RFC 1178 把这一架构问题写成日常风险：在某个站点输入单段邮件目的名，邮件程序可能把它补成本地域内的名称，也可能把它理解成另一个域中的名称。真正生效的目的地来自“输入字符串 + 本地规则”，并不只来自屏幕上看见的那几个字符。

同一个标签也可以出现在不同父域下。RFC 1034 只禁止同一父节点下的兄弟重名，并不要求整棵树中的标签全局唯一。因此，裸露的单段名称不是全球身份；父路径与请求的记录类型共同决定问题在问哪个节点、哪类数据。

即使使用完整域名，名称、地址、机器和服务也不能被压成一个事实。DNS 节点可以关联多种资源记录，甚至没有记录。一次查询只能回答当时针对某名称、某类型发布了什么数据，不能证明机器所有权、运营者身份、端点可达性或应用行为。

好名字减少误解，却不会创造事实

RFC 1178 的不少建议刻意面向人。超过八个字符会让使用者厌烦，这是经验性可用性意见，不是 DNS 长度上限。奇怪拼写会增加口述、听写和故障处置成本；大小写不应被当成区分身份的可靠手段；带侮辱意味的名称会在演示和跨团队协作中制造无关干扰；有限主题会随着设备增加而耗尽。

这些都不是另一本语法标准。名称会穿过对话、工单、命令、邮件、日志、告警和纸面标签。字符串在协议层被接受，不等于它在每次人机交接中都清楚。

“合法”因此只是一种很窄的质量判断：字符满足适用语法。运营质量还要问，它在口语中是否明确、不同解析器是否一致、本地域是否显式、职责变化后是否仍准确、故障时是否容易核对。这些问题相关，却不相等。

改名暴露的是隐藏依赖清单

RFC 1178 对未来改名的警告最接近今天的配置债务。到那时，隐蔽软件可能已经写死旧名称，外部通信者还在使用它，旧备份介质的标签也保留着过去的“名字—机器”关系。权威记录更新，只改变了一处状态，不会自动重写这些远端副本。

RFC 952 已经承认过渡成本。它通常不鼓励主机昵称，却允许改名时让新旧名称在一段合适时期内并存。别名是迁移工具，不是迁移完成证明。

可靠的事件链应当逐步记录：谁批准新名称，权威记录何时生效，临时别名是否工作，缓存何时过期，程序、证书、访问规则、监控、备份与外部联系人是否迁移，旧名称使用量是否下降，剩余例外由谁接受，最后何时退役旧绑定。RFC 1178 没有给出这套现代清单，但它准确指出了为何需要清单。

证据链从查询之前开始

面对一次真实的主机名输入，首先要保存字面字符串与适用语法；其次记录程序把它识别成名称还是数值地址。如果它是相对名称，还要保存补全它的原点和搜索列表。之后才是解析器、查询时间、缓存、记录类型和应答。

再往后才轮到地址选择、连接、服务协商、机器或服务身份、权限、应用接纳和结果。一个好记的名称可以帮助人沿着这条链工作，但不会替代任何一环。

来源