摘要

  • RFC 2219 汇集了当时人们和程序用来猜测网络服务入口的 DNS 标签，让服务名称有机会在服务器迁移后继续不变。
  • 文件也说明这些标签不能证明什么：它不能保证地址存在、进程正在监听、端口符合预期、服务器愿意接待该客户端，更不是完整的服务目录。

名称听起来像承诺，DNS 回答却不是

在浏览器里输入 www.example.org，仿佛这个名字已经告诉你目的地。但它没有做到那么多。DNS 可能不给出任何地址；地址可能指向一台没有 HTTP 服务的机器；即使有进程监听，也未必使用 80 端口；服务运行正常，仍可能拒绝某个请求。1997 年 10 月，RFC 2219 把这个落差明说出来，并试图整理人们早已学会猜测的服务名称。

这套惯例有直观好处。用户不知道机器叫什么，仍可试试 www、ftp 或 mail。程序也能做相同的猜测。对域名管理员更重要的是，服务入口的名称可以保持稳定，底下的主机或地址却能更换。搬迁不必要求访客记住新名字。RFC 2219 将这种间接指向视为迁移服务的办法，也把它看成判断某组织可能提供某种服务的线索。

这份 Best Current Practice 没有发明新的 DNS 记录类型，也没有建立通用服务目录。作者说这些别名惯例当时已近乎普遍，但这是 RFC 内的同期判断，并非本文独立测量的采用率。文件整理了一组常用名称：www、ftp、gopher、ldap、mail、news、ntp、pop、whois 等；未列出的协议应由自己的规范提出名称。它规范的是词汇，不是能核实词汇背后运行状态的事务。

核心限制并非脚注。RFC 2219 明确指出，DNS 中有 www 记录不等于注册了 Web 服务。该名称不必解析到 IP 地址；没有主机必须监听 HTTP；监听服务也不一定在 80 端口。即使前述条件都成立，服务器仍不必接受任意客户端。文件称这些名称是有用的“提示”，要求实现者按提示来理解。域名区域里有一条记录，和服务是否实际运行，是两种不同证据。

这个提示在发现链中出现得比表面上更晚：使用者必须先知道组织的域名。RFC 2219 并没有教程序如何从机构名称、地点或业务推导出域名。它也没有解决服务需要主机名以外参数的情况。文件举 LDAP 为例：客户端还需要知道目录树的搜索基点，交互才有意义。别名能让一个已知域名更容易接近，却不能把 DNS 变成通用检索目录。

名称迁移也带来维护取舍

RFC 2219 展示了两种发布服务名称的方式。CNAME 可以让 ph.example.org 指向一台主机的规范名称，管理员迁移机器时不用重复维护地址。但按照 DNS 规则，CNAME 所在的名称不能同时拥有其他数据，例如 MX。另一种方法是在服务名称下直接发布一个或多个 A 记录；地址更直观，却要负责与真实主机保持同步。RFC 没有规定哪种方式普遍更好，选择取决于站点需要。

方便背后有运维负担。使用别名，就必须维护目标，目标主机退役后还要删除记录。过时的指针不会自动变成健康检查。直接放 A 记录，则要在机器变化时同步整组地址。多个地址有时用于镜像站点；RFC 提到 DNS 可能轮换顺序，客户端也可能自行使用启发式选择。但顺序变化和客户端选择都不能证明主机可用，更不能证明内容相同。文件只在镜像确为精确副本时才认为这种做法合适。

安全警告也是同一条边界。DNS 回答可能被伪造，既可以指向不存在的地址造成拒绝服务，也可能把访问者带到冒充正规服务的主机。别名惯例本身没有认证功能。因此，一个令人放心的名称不能替代端点核验，也不能保护敏感交互。

RFC 2219 还承认，常见标签不是长期服务发现问题的完整答案。它提到当时有关 Server Location Resource Record 的工作，即 RFC 2052。时间顺序很重要：SRV 提案早于 RFC 2219，而后者把它作为应对更大问题的另一项工作。RFC 2782 后来取代 RFC 2052，定义了包含服务、协议、优先级、权重、端口和目标的记录；但客户端是否使用它，仍取决于相应应用协议是否要求。后来的规范并没有追溯性地把 www 变成服务注册凭证。

RFC 2219 的贡献更有限，也更可信：一个熟悉的名称可以让运维者的意图容易被发现，也让底层主机更容易替换。它没有越权替远端事实背书。区域管理员发布线索，主机运营者控制监听进程，客户端仍需连接并判断响应。符号化的入口可以迁移；那里是否真的有人接待，依旧是运行层的问题。

来源：RFC 2219；RFC Editor 的 RFC 2219 记录；IETF Datatracker：BCP 17；RFC 1912；RFC 1034；RFC 1035；RFC 2052；RFC 2782；RFC 1123。