ERC-7529 合约归属验证：DNS 的 TXT 记录怎么给链上合约签名背书

一个仿冒合约最常见的破绽，是它解释不了”为什么这个地址归那家公司”。项目方可以发公告，但公告会被抄进钓鱼页面；可以把地址写进官网，但官网域名本身也可能被仿冒注册。ERC-7529 把验证链拉回到互联网最古老的一套权威体系——DNS：域名持有者在 DNS 里放一条 TXT 记录，写上自己关联的合约地址；同时合约里实现一个查询函数，让外界反查这个合约声明关联了哪些域名。两头一对，域名与合约之间就形成了一条可机器复核的双向链。按照以太坊 ercs 仓库的记录，这份提案状态为 Draft（草稿），创建于 2023 年 9 月 30 日。

TXT 指针与三个合约函数

标准文本描述的做法是：eTLD+1 主域（例如 example.com 这一级）的持有者在自己域名的 DNS 设置里创建 TXT 记录，内容是指向其关联合约的指针。TXT 记录常被用于 SPF、DKIM 这类邮件反垃圾与域名所有权验证场景，提案明确说本用途与后者在原理上同源。单条 TXT 记录有字符上限，但一个 EVM 地址只有 42 个字符，多数服务商的一条记录足以装下几十个地址，而且同一主机名可以挂多条 TXT，一次查询可以全部取回。合约端，标准给出三个函数：checkDomain(domain) 返回布尔值，回答”这个合约是否声明与该域名关联”；addDomain(domain) 与 removeDomain(domain) 是需要鉴权的管理函数，负责维护合约侧的域名清单。查询端则依赖 DNS over HTTPS（DoH）：标准引用 RFC 8484 指出，DoH 让网页应用可以直接、防篡改地向权威 DNS 发查询，绕开了过去必须经过中间服务商、返回结果可能被操纵的旧链路。

一次完整的验证长什么样

钱包或安全工具拿到一个可疑合约地址后，可以这样走一遍：先调用合约的 checkDomain 或读取其声明的域名列表，得到”合约自称属于 example.com”；再通过 DoH 查询 example.com 的 TXT 记录，看返回的地址列表里是否真的包含这个合约地址。两边同时成立，归属关系才算双向闭环。任何一边缺失——合约说有关联而 DNS 没写，或者 DNS 写了地址但合约不认——都应视为验证失败，而不是”差不多是真的”。稳定币发行方、NFT 项目方这类有大量仿冒风险的角色，是标准摘要里点名的典型受益场景。

两个容易被略过的实现细节

一是为什么锚定 eTLD+1 而不是任意子域：主域是注册商体系里所有权最清晰、转让与管理权限最分明的层级，子域归属容易含糊，把验证锚在主域等于复用了几十年域名制度的确权与争议流程。二是查询端的解析纪律：同一主机的 TXT 记录往往同时装着 SPF、DKIM、站点验证等大量无关内容，验证程序必须只挑出符合标准约定格式的指针条目、其余一律忽略；域名一旦易主或业务下线，前任留下的 TXT 指针也要随 DNS 配置一并清理，否则旧资产的声明会长期悬在 DNS 里继续生效——removeDomain 管得了合约侧，管不了忘了翻 DNS 后台的人。

它能挡住什么、挡不住什么

这套机制的价值边界要说清楚。它能挡住的是”无权威背书”：仿冒者可以复制合约代码、仿制官网页面，但要让验证通过，他必须同时控制那个域名的 DNS 管理权——而 DNS 记录变更是有注册商流程和历史痕迹的，冒充成本远高于复制粘贴。它挡不住的是：域名被盗或管理权旁落后的合法记录投毒、项目方主动把钓鱼地址加进 TXT、以及 TXT 记录写完之后再也没维护的僵尸声明。因此对维护方而言，removeDomain 与轮换记录纪律和维护合约本身同样重要；对验证方而言，TXT 应当被当作”需要交叉核对的一项证据”而非”最终结论”，与区块浏览器上的合约历史、官方仓库的部署记录放在一起看。按 ercs 仓库口径，ERC-7529 停留在 Draft，实现它的项目还不多，遇到不声明域名的合约并不等于有问题，遇到声称支持该标准却查不到 TXT 记录的，才需要警觉。本文为机制说明，不构成任何投资建议。