1 技术背景
域名系统（DNS）是互联网基础设施的核心组件，负责将人类可读的域名映射为机器可寻址的IP地址。然而，原始DNS协议设计之初并未考虑安全性，解析过程中的查询与响应均以明文传输，且缺乏来源验证机制。这一缺陷使得DNS缓存投毒（cache poisoning）和中间人攻击成为现实威胁——2008年的Kaminsky漏洞将这一问题的严重性推到了台前。
DNSSEC（Domain Name System Security Extensions）通过为DNS资源记录添加数字签名来解决这一问题。其核心工作链路为：签名生成（RRSIG）→ 公钥发布（DNSKEY）→ 委派锚定（DS），形成从信任锚点至末端记录的可验证签名链。解析器在收到应答时，沿签名链逐级验证，任何篡改均因签名不匹配而被拒绝。
CBDC（Central Bank Digital Currency，央行数字货币）的跨境支付场景对域名安全提出了远超一般Web浏览的要求。当两家央行或商业银行节点通过域名寻址对方API端点时，一次成功的DNS劫持可直接导致支付请求被路由至恶意节点，造成不可逆的资金损失。DNSSEC在这一场景下不再是可选增强，而是跨境支付路由安全的基础保障。
2 DNSSEC在CBDC跨境支付中的验证机制
CBDC跨境支付的域名验证需求可从三个层面分析：节点寻址、证书锚定和路由完整性。
在节点寻址层面，mBridge项目中的参与央行需要通过域名定位彼此的支付网关。DNSSEC确保这些域名解析结果不被篡改，防止支付请求被导向非预期节点。当前mBridge的架构文档中虽未明文规定DNSSEC部署要求，但其依赖的TLS通信隐含了域名验证的安全前提。
在证书锚定层面，DANE（DNS-Based Authentication of Named Entities，RFC 6698）协议将TLS证书的信任锚从CA体系扩展至DNSSEC签名链。通过TLSA记录，CBDC运营机构可自行声明其支付端点应信任的证书指纹，避免因CA妥协或误发证书导致的安全事件。2011年DigiNotar事件与2023年多起证书误发事件表明，纯CA体系在高安全场景下存在结构性信任缺口。
在路由完整性层面，DNSSEC的NSEC/NSEC3机制提供了区域遍历检测能力。当某CBDC节点的域名记录被删除或篡改时，DNSSEC签名失效，解析器返回验证失败而非被篡改的NXDOMAIN响应，防止攻击者通过域名消失实现拒绝服务。
3 mBridge与数字人民币的域名安全现状
mBridge（Multiple CBDC Bridge）项目由BIS创新 hub牵头，中国、香港、泰国、阿联酋及沙特央行参与。其技术架构采用分布式账本实现多边CBDC桥接，支付节点间通信依赖域名寻址。公开资料显示，mBridge的节点发现机制尚未强制要求DNSSEC验证，这在跨境多信任域环境下构成潜在风险点。
数字人民币（e-CNY）的跨境应用场景主要通过mBridge通道实现。中国人民银行数字货币研究所在技术白皮书中强调了端到端加密与节点认证的重要性，但对域名解析层的安全保障未做详尽讨论。实际部署中，e-CNY跨境支付节点的域名解析若未受DNSSEC保护，面临被劫持至钓鱼节点的风险。
根据ICANN的DNSSEC部署统计，截至2026年初，全球顶级域名（TLD）的DNSSEC签名率约为28%，而二级域名的有效验证部署率更低。CBDC支付节点所使用的域名若位于未签名区域，解析器无法对其进行DNSSEC验证，DNSSEC的保护覆盖因此存在盲区。
4 DNSSEC部署率低的系统性风险
全球DNSSEC部署率偏低对CBDC跨境结算构成三层风险：
第一层为直接劫持风险。未部署DNSSEC的域名解析可被中间人攻击篡改，支付请求可能被路由至恶意节点。在跨境场景下，攻击者位于不同司法管辖区，事后追溯与法律救济难度极大。
第二层为DANE可用性受限。DANE协议的有效性完全依赖DNSSEC签名链。当目标域名未部署DNSSEC时，其TLSA记录无法被验证，DANE保护机制失效。这意味着即使CBDC运营机构希望采用DANE增强证书验证，也受制于对端部署状况。
第三层为级联故障风险。CBDC跨境支付涉及多节点链式调用——付款方央行节点→mBridge验证节点→收款方央行节点。链路中任一节点的域名解析若不受DNSSEC保护，该节点即成为整条支付链路的薄弱环节，攻击者可沿此缺口横向渗透。
5 DANE协议与CBDC证书验证的结合路径
DANE协议为CBDC跨境支付提供了超越传统CA体系的证书验证方案。其核心优势在于将证书信任锚从集中式CA转移至分布式DNSSEC签名链，使域名所有者对自身证书的有效性拥有声明权。
在CBDC场景下，DANE的部署模式可分为三类：
模式一为PKIX-CA增强，对应TLSA证书用法2（TA约束）。CBDC运营机构在TLSA记录中声明应信任的CA指纹，即使其他CA为同域名签发了证书，解析器也仅认可TLSA指定的CA所签发者。这一模式对现有CA体系改动最小，适合过渡期部署。
模式二为PKIX-EE锁定，对应TLSA证书用法1（EE证书约束）。直接在TLSA记录中发布终端证书指纹，绕过CA层级。适用于CBDC节点间已建立证书交换机制的点对点通信场景。
模式三为DANE-EE直接信任，对应TLSA证书用法3（服务证书约束）。完全跳过PKIX验证链，仅依赖DNSSEC签名链验证证书有效性。安全性最高但运维要求也最高——证书轮换需同步更新TLSA记录，任何不一致都会导致验证失败。
6 CBDC跨境支付域名安全框架建议
基于上述分析，本文提出面向CBDC跨境支付场景的域名安全框架，包含五项核心建议：
强制DNSSEC签名与验证。 CBDC跨境支付参与方应强制为其支付端点域名部署DNSSEC签名，解析器配置为验证模式。对于mBridge等正式项目，可将DNSSEC部署作为参与准入条件。
DANE证书锚定。 采用DANE TLSA记录为支付端点证书增加域名级验证层。初期可使用PKIX-CA增强模式降低部署复杂度，后续过渡至DANE-EE直接信任模式。
OCSP实时证书状态检查。 在TLS握手阶段强制执行OCSP Stapling，确保证书未被吊销。DNSSEC与DANE仅验证证书绑定性，不覆盖证书生命周期中的吊销事件。
多级监控与告警。 对CBDC支付相关域名建立持续DNSSEC监控，包括签名过期预警、DS记录变更检测和解析路径异常告警。关键支付域名的签名过期余量应不少于72小时。
区域覆盖要求。 CBDC跨境支付通道的两端域名均须部署DNSSEC，任何一端未签名均应触发安全降级或通道熔断，防止未保护端成为攻击入口。
7 结论
DNSSEC在CBDC跨境支付中的角色并非简单的安全增强扩展，而是CBDC跨境支付体系中不可或缺的安全底座。通过为域名解析提供数学可证的真实性，DNSSEC有效弥补了互联网开放架构与金融级安全需求之间的鸿沟。尽管当前面临全球部署不均及运维复杂性等挑战，但通过结合DANE协议与强化运维框架，CBDC运营机构能够构建起一套自主可控、抗劫持的跨境支付路由体系。在未来全球CBDC互联互通的蓝图中，域名验证机制的标准化与安全化将成为保障国际资金流动安全的基石。
相关研究
常见问题
DNSSEC与普通DNS安全机制有什么区别？
普通DNS协议不提供来源验证和数据完整性保护，攻击者可通过缓存投毒或中间人攻击篡改域名解析结果。DNSSEC通过数字签名链（RRSIG→DNSKEY→DS）为每条资源记录提供密码学可验证的真实性证明，使解析器能够检测并拒绝被篡改的响应。
CBDC跨境支付为何特别依赖DNSSEC？
CBDC跨境支付涉及不同司法管辖区的支付节点间通信，域名解析的可靠性直接决定资金路由的正确性。一次DNS劫持可能导致支付请求被导向恶意节点，造成资金损失且难以追溯。DNSSEC为这种跨信任域的场景提供了不依赖单一CA的验证路径。
DANE协议能否替代传统CA体系？
DANE并非完全替代CA，而是在CA基础上增加一层基于DNSSEC的域名级证书验证。通过TLSA记录，DANE允许域名所有者自行声明应信任的证书指纹，绕过被攻陷或滥发证书的CA。对于CBDC等高安全场景，DANE提供了比纯CA体系更细粒度的信任控制。
DNSSEC部署率低对CBDC有何实际影响？
截至2026年，全球顶级域名DNSSEC部署率不足30%。CBDC支付节点若解析未签名的域名，将无法验证响应真实性，面临缓存投毒与域名劫持风险。部署率低还限制了DANE等上层协议的可用性，使CBDC跨境通道的安全保障存在覆盖盲区。
本文提出的域名安全框架适用于哪些场景？
该框架适用于所有依赖域名解析进行节点寻址的CBDC跨境支付场景，包括mBridge多边桥、双边CBDC直连通道以及央行数字货币与商业银行系统的对接接口。框架中的强制DNSSEC验证、DANE证书锚定和OCSP实时检查等建议，可根据具体部署规模灵活裁剪。