摘要

  • ENUM 将 E.164 号码变成 DNS 键，并依次处理 NAPTR 规则，直至产生 URI；这个结果是可供选择的服务联系地址，不是已经完成的通信会话。
  • 可信的通话记录必须把号码控制权验证、DNSSEC 状态、所选 NAPTR、生成的 URI、下游对端认证、信令与实际双向媒体分开保存。

设想一块运维屏幕：输入 E.164 号码之后，系统去掉分隔符、倒排数字、拼出 e164.arpa 名称，收到通过 DNSSEC 验证的 NAPTR RRSet，随后生成一个 SIP URI。屏幕于是亮起“成功”。可下一层解析指向旧主机，服务商拒绝邀请，远端从未振铃，或者信令已经接受、语音却只有单向。

前面的 ENUM 结果未必有错。错误在于屏幕把“找到地址”压缩成了“已经接通”。

RFC 3761 由 Patrik Fältström 与 Michael Mealling 共同署名，2004 年以标准轨文件发布。2011 年，Scott Bradner、Lawrence Conroy 与 Kazunori Fujiwara 的 RFC 6116 取代了它，并明确称自己更新了 Fältström 与 Mealling 编辑的旧文本。ENUM 是多人、跨版本修订的标准工作，不能被写成一个人的发明或现实运营决定。

它兑现的是一项严格限定的能力：应用可以从电话号码出发，经 DNS 找到 URI。DNS 并未因此变成电话交换机、号码分配机关，也不会替系统证明人类已经交谈。

精确的 DNS 键没有证明号码归属

RFC 6116 先构造 Application Unique String。完整 E.164 号码会去除空格、括号和短横线等视觉符号，只保留开头的加号与数字。第一条既知规则再去掉加号、反转数字、逐位加点，最后追加 .e164.arpa.。这样得到 ENUM 规则数据库中的初始键。

这个步骤只能证明客户端按规则提问。它没有认证提出查询的人，也没有证明当前号码使用权仍属于最初登记者。号码可能已经携转，复核可能尚未同步，输入也可能来自没有授权的名单。语法正确不能补上制度证据。

客户端用该键查询 NAPTR。终结规则可以给出最后结果；非终结规则则生成另一个域名，触发下一轮查询。DDDS 最后一轮的预期输出是绝对 URI。换言之，ENUM 的终点是一段地址表达式，而不是“电话接通”状态。

RFC 3403 把规则字段拆得很清楚：ORDER 决定先处理哪个规则层级，PREFERENCE 在同一层级内排列可用候选，FLAGS、SERVICES、REGEXP 与 REPLACEMENT 说明怎样解释或改写。日志若只留下最终 URI，就同时丢掉了选择理由。

“返回一条规则”仍然不是执行裁决

RFC 6116 说 ENUM 算法总是返回一条规则。这句话描述算法出口，不是电话结果。应用可能只支持部分 Enumservice，可能丢弃私有或格式错误的记录，也可能把多个可行 URL 展示给用户，再由用户按自己的情境选择。

客户端必须先按 ORDER、再按 PREFERENCE 排列 RRSet。若两条记录数值相同，DNS 响应中的到达次序并不是稳定偏好。两个解析器返回相同集合但顺序不同，不代表其中一个伪造了数据。

登记人的偏好也不是强制命令。RFC 6116 提醒，区域中只能放入愿意支持的联系地址，因为即使排序最差的记录也可能被终端用户选中。这只说明选择有可能发生，不保证端点此刻在线、客户端理解 URI 方案，或后续服务商允许该请求。

因此要保存完整分母：全部 NAPTR、TTL、排序、偏好、服务、标志、改写式，以及客户端支持的 Enumservice。每个候选为何保留、跳过或拒绝，也必须进入审计记录。孤立的 URI 无法说明客户端是否遵守政策、是否遭遇平局、是否使用陈旧缓存，或者根本没有兼容方案。

号码控制权属于上游验证链

ENUM 名称不是普通的先到先得域名，它必须跟随 E.164 分配。RFC 4725 因此把号码分配实体、号码使用权人、ENUM 登记人、验证实体、注册局、注册商、DNS 服务商与应用服务商区分开来。

号码使用权人拥有该号码的使用权。验证实体需要核对 ENUM 登记人就是使用权人，或者确实得到其授权。初次验证不足以覆盖整个委派生命周期；号码状态或权属改变后，还要重复验证，并在条件不再满足时撤销委派。

这些来源信息不会自动装进每个 NAPTR 回答。解析器可以确认 DNS 数据来自签名链，却不知道最近一次号码携转、验证方法或本地授权决定。“这个名称存在”与“这个登记人此刻仍控制号码”是两个命题。

反过来，过时记录也不能直接被定性为欺诈。TTL 尚未届满、不同区域更新时钟不一致、撤销尚在传递，都可能造成暂态。可靠调查需要连接号码分配版本、验证时间与方式、到期状态、委派变更，以及客户端当时真正看到的 DNS 字节。

DNSSEC 的权威止于 DNS 数据

RFC 6116 的安全章节没有把 DNSSEC 神化。DNSSEC 能认证 DNS 数据，化解许多针对 ENUM 的攻击；但即使查询通过验证，得到的地址也不能保证其背后的实体就是用户想联系的服务对端。

规范要求服务在建立阶段再次认证真正连接的实体，不可依赖服务外部取得的地址或身份数据。DNSSEC 回答“这些数据是否属于受签名保护的 DNS 链”，不会预先回答“随后在该地址响应的软件是谁”。

缓存让这条边界更长。规范以 SIP 为例：ENUM 先给出 URI，客户端又查询 SIP 域名的 NAPTR，再查 SRV，最后查主机地址，然后才尝试发起会话。不同记录由不同区域维护，有不同 TTL，也可能在不同时间改变。一组各自真实的回答，未必描述同一个一致时刻。

所以绿色 DNSSEC 标识不能覆盖后续回执。日志还要保存签名有效期、解析器、缓存年龄、否定回答与全部下游解析，并把实际信令尝试绑定到经过认证的服务对端。

语音 URI 只是另一套协议的入口

RFC 4415 注册了 voice:tel Enumservice。它的表述是：生成的 tel: URI 可以用来发起交互式语音通话。拨号器可能直连 PSTN/PLMN，也可能通过 IP 服务商和远端网关转接。

“可以发起”是一条能力边界。客户端要支持相应类型与子类型，服务商还会认证、授权、路由、接受或拒绝。远端可能振铃、重定向、超时或应答，媒体随后还要协商并穿过自己的路径。这些状态没有写入先前的 NAPTR 结果。

如果 ENUM 生成 SIP URI，控制权会交给 RFC 3261。SIP 是另一套用于寻找潜在参与者、创建、修改和结束会话的协议，有自己的认证、授权、邀请、临时与最终响应、确认和对话状态。ENUM 提供输入 URI，不会提前执行 SIP 状态机。

即使界面显示“SIP 成功”，也仍需限定问题。被接受的邀请不能单独证明双向音频、真人参与、可用时长或计费符合预期。媒体与应用证据应单独采集，并受隐私和最小留存规则约束。

通话回执必须按顺序拼接

第一段从原始号码开始：规范化规则、派生 DNS 键、解析器、查询时间、DNSSEC 状态、完整 RRSet、TTL 与每次非终结改写。随后记录客户端支持哪些 Enumservice、候选集合、选择原因和最终 URI。

第二段属于别的控制面：下游解析、真实对端认证、服务商授权、信令请求、事务标识、响应、确认与结束原因。完成这些步骤之后，系统才能说明预期媒体端点是否双向收发、应用在多长窗口内认为会话可用。

前一步成功而后一步失败，是正常且有用的事实。分层记录可以区分失效委派与旧缓存、不兼容服务与主机不可达、错误对端与呼叫者被拒，也能区分信令建立与单向无声。

来源