摘要

  • RFC 3490 保持 DNS 的 ASCII 基础不变，把 IDNA 放在应用内部。ToASCII 可以拒绝标签；ToUnicode 则被设计为永不报错，任何步骤失败都立即返回原输入。
  • 因而，一个字符串能被返回和显示，并不能证明它是有效 IDNA 标签，更不能证明注册机构接纳、区域已写入、DNS 可解析、DNSSEC 已认证或某人拥有控制权。

“ToUnicode 从不失败”是 RFC 3490 中最容易被读反的一句话。它不是说任意输入都能成为有效的国际化域名，而是说显示函数总要给应用一个结果。只要解码、准备或最后的往返核验有一步失败，函数就把原输入原样交还。界面不至于失去对象，但协议也没有给这个对象盖章。

要理解这项选择，必须回到 2003 年的结构。IDNA 没有修改 DNS 服务器、解析器或线上报文。它完全运行在应用内部，像一层夹在用户界面与解析库之间的薄垫片。面向用户的一边可以输入和呈现 Unicode；面向既有基础设施的一边仍然使用 ASCII。国际化发生在边缘，DNS 核心继续做精确匹配。

RFC 3490 还专门定义了“域名槽位”：DNS 查询里的 QNAME、解析函数的参数或返回值、邮件头中 @ 之后的部分、URI 的主机字段。普通文章里碰巧出现的域名，不因此成为域名槽位。这一限定很重要：字符串的规则由用途决定，而不是由外观决定。

通往 DNS 的方向允许失败。ToASCII 逐标签处理。非 ASCII 输入先经过 Nameprep；应用还可以要求传统的字母、数字和连字符规则；已经以保留前缀开头的非 ASCII 序列会被拒绝；随后才用 Punycode 编码、加上 xn--，并检查结果长度是否在一到 63 个码点之间。任何一步失败都使操作失败。一个标签失败，整个域名就不得作为国际化域名使用。

通往人的方向承担的是另一个任务。ToUnicode 识别 ACE 前缀，去掉前缀，解码 Punycode，再把得到的 Unicode 结果送回 ToASCII。只有重新生成的 ASCII 形式与先前保存的输入在不区分 ASCII 大小写时一致，才返回解码后的 Unicode。这个往返检查证明两种表示确实对应，而不是某个看似带前缀的字符串偶然解出一些字符。

若检查失败，ToUnicode 不会把中间结果包装成成功。它返回最初输入。RFC 3490 进一步说明：经过 ToUnicode 后仍以 ACE 前缀开头的标签，不是有效 ACE 标签，也不等价于处理中出现的 Unicode 中间串。原样返回只是显示通道的连续性策略，不是有效性结论。

这里形成了一条应当逐级保存的证据链。字符串可以显示，是一件事；能通过 ToASCII，是另一件事；注册局按照自己的文字与语言政策接纳它，又是一件事；A-label 被写进区域、查询得到回答、DNSSEC 验证该回答、用户把可见名称认成预期主体，还各有自己的证明。前一张收据不会自动生成后一张。

RFC 3490 对 DNSSEC 的界定尤其锋利：签名和验证对象是 DNS 中的 ASCII 域名，不是 Unicode 显示形式，也不是两种形式之间映射的社会含义。密码学可以证明某份 DNS 数据来自受信链，却不能证明一个人如何理解屏幕上的拼写，更不能替注册权或身份背书。

这份标准同样没有承诺解决语言本身。Unicode 扩大了可用字符范围，但 DNS 仍是精确匹配。相似字形、不同语言的等价拼写、繁简体中文以及听觉上接近的名称，并不会自动合并。区域管理者还可以设置比 IDNA 更严格的政策。编码解决兼容，不裁决谁理应拥有某个名字。

2006 年的 RFC 4690 记录了混淆字符、注册政策、Unicode 演进与迁移的复杂性。2010 年，RFC 5890 和 RFC 5891 用 A-label 与 U-label 重写术语，并明确拆分注册协议与查询协议。注册可要求两种形式逐字一致，不符即拒绝；查询虽然更宽容，仍有核验规则。RFC 5891 还直白指出：比较成功不意味着有效。

RFC 5895 则把用户输入的本地映射放在共同协议之前，作为本地决定。这与 Heng Lu 所说的“最小初始规范”高度一致：全球层只标准化互操作所必需的窄接口，把语言、呈现和注册政策留给拥有上下文的本地参与者。协调的力量来自边界清楚，而不是把每一层都收归一个中心判断。

因此，RFC 3490 的历史价值不只在 Punycode 或一个著名前缀。它把两个常被混淆的动作分开：显示通道可以为了连续性始终返回，接纳通道必须保留拒绝能力。看见字符串，只能证明应用展示了什么；要说域名有效、已注册、可解析或由谁控制，还必须拿出下一层的证据。

来源