一个域名，两个名字空间
BIP353 的核心设计极简：收款人在自己的 DNS 区里放一条 TXT 记录，付款方把”用户名加域名”翻译成一次 DNS 查询，就能拿到完整的收款指令。要付给 example 域的 alice，钱包实际查询的名字是 alice.user._bitcoin-payment.example.com，TXT 记录的内容是一条标准 BIP21 支付字符串，可以同时携带链上地址或闪电网络报价。展示时规范建议用比特币符号前缀写成类似比特币名字的形式，与电子邮件地址在视觉上拉开距离。选择 DNS 的理由不是新颖，而是复用：这个全球命名系统已有成熟的注册、授权与密钥签名体系，钱包不需要再发明一套身份基础设施。
没有 DNSSEC 就没有名字
规范用强制措辞写明所有支付指令记录必须带 DNSSEC 签名，且解析方要一路验证到根区，不接受 SHA-1 签名，也不接受短于 1024 比特的 RSA 密钥。这条硬性要求决定了它和早期”普通 DNS 记录指向收款码”式土办法的本质差别：TXT 应答在密码学上可验证，中间人无法在解析链路上偷换收款地址。风险被转移到了域名生命周期上。DNSSEC 私钥与密钥轮换由域名持有者负责，注册商流程失误、密钥撤销失当都可能让名字突然失效；域名到期被重新注册后，新持有者可以合法地把自己的收款指令挂到这个名字之下。任何依赖名字收款的人都要把域名续期、密钥轮换当成与钱包备份同等级的例行动作，付款方则在金额较大时把域名注册归属一并核对。
与 Lightning Address：同一个问题，两条路
两者都解决”不用贴长地址”的体验问题，差别在信任与隐私结构。Lightning Address 走 HTTPS，付款方钱包向收款方服务器直接发起请求，对方至少能看到你的 IP 与请求行为，并且必须维持一台在线服务器。BIP353 把查询交给 DNS 递归解析器中转，收款方服务器可以完全不存在，解析请求经过开放解析器中转后通常不直接暴露付款方 IP；配套要求也更接近公共基础设施——验证依赖 DNSSEC 签名体系而不是站点 TLS 证书。规范同时给出一条重要限制：当钱包已经拿到明确地址或其他更直接的收款信息时，不得优先改用 DNS 解析。这防止收款路径在链路中被动升级到低信任渠道。托管服务想给海量子用户发名字时，可以发布一条通配符记录，用携带盲化路径的 omlookup 参数引导钱包经由闪电洋葱消息为具体用户生成专属报价，服务端不必为每个用户名单独挂记录。
硬件钱包为什么欢迎它
硬件设备最缺的是”在有限屏幕上确认付款目标”的可信手段。DNS 名字短、可读，且验证逻辑不依赖任何一家第三方服务器：设备或配合它的主机软件自己校验 DNSSEC 链，就能把”这串字符对应这个收款指令”变成可回显核对的断言。规范还特意建议避免使用非 ASCII 字符：非 ASCII 名字必须用 punycode 编码，而不同文字形近的仿冒字符历来是钓鱼重灾区，解析器若要支持非 ASCII 名字就必须采取同形字防御，钱包若做不到则必须直接显示 punycode 原文。对中文用户来说，实操结论是：看到 xn— 开头的 punycode 时不要凭直觉判断它”像不像”某个熟悉域名，逐字符核对域名本体最稳妥。
缓存与过期的时间耦合
规则对缓存同样苛刻：钱包不得以超出解析器给出的 TTL 的时长缓存支付指令。闪电报价自带有效期时还要多加小心——如果 DNS 记录比报价本身活得更久，付款方本地可能长期缓存着一个已经过期的收款指令，导致付款失败或退回低信任的备用路径。收款方的正确姿势是让 DNS 记录的 TTL 明显短于报价有效期，改版或撤名时先动记录再动报价。
使用前逐项确认
付款侧：确认你的钱包真的在做 DNSSEC 校验而不是随手抓取；大额转账即使名字解析成功，也值得再核一次域名注册信息；不要手工输入带 punycode 的名字。收款侧：域名续期与密钥轮换设置提醒；发布闪电报价时同步检查 TTL 与报价有效期匹配；不要假设所有钱包都支持 BIP353，把传统收款方式并排放置。截至本文写作时，对 BIP353 的支持仍集中在部分钱包与硬件设备，具体名单以各软件发布说明为准，未支持软件看到这类名字只会原样处理，不会替你发明验证。
风险提示：本文仅介绍协议机制与安全边界，不构成投资建议；名字解析失败或域名易主可能导致资金转入非预期地址，大额支付前请先小额测试并核对域名归属。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。