网络通信的核心难题是：如何确认对端真的是预期的服务？澳洲四大银行的 DNS 解析均指向 Akamai、CloudFront、Incapsula 等 CDN 平台，而非自有命名空间。RFC 9102 指出，单纯依赖 CA 签发证书易陷入“轻信”，需引入 DANE 将信任锚定在 DNSSEC 上。
银行服务的 DNS 解析链：
Commonwealth Bank 解析为 www.commbank.com.au → CNAME prd.akamai.cba.commbank.edgekey.net → CNAME e7049.x.akamaiedge.net → A 104.98.23.23；Westpac 解析为 www.westpac.com.au → CNAME dplenhq18279.cloudfront.net → 4 条 A 记录（13.224.175.48/62/22/58）；ANZ 解析为 www.anz.com.au → CNAME jtyncho.x.incapdns.net → A 45.60.126.46；NAB 解析为 www.nab.com.au → CNAME www.nab.com.au.edgekey.net → CNAME e11252.x.akamaiedge.net → A 23.12.68.183。四家银行均未直接映射到自有 IP 地址空间，均通过 CNAME 链委托给第三方平台，原文指出这是为了 DDoS 防护与成本效益的弹性考量。
证书信任模型的缺口：
现行模型下，服务提供商生成密钥对并提交证书签名请求（CSR）给 CA，浏览器信任根 CA 存储库中的根证书。但 CA 可能被攻破、误签或被强制签发伪造证书，且 DNS 与证书体系割裂，域名持有者无法在 DNS 层面直接约束哪个证书合法。原文强调：这种“信任”实质是盲目接受 CA 的背书，而非可验证的技术绑定。
DANE 与 RFC 9102 的定位：
DANE（DNS-based Authentication of Named Entities）在 DNSSEC 签名区中引入 TLSA 记录，将证书指纹或公钥哈希直接写入权威 DNS。RFC 9102《Trust versus credulity》将此定性为从“轻信 CA”转向“可验证信任”：验证器可同时校验 DNSSEC 签名链与 TLSA 记录，绕过 CA 单点风险。前提是区域已部署 DNSSEC，且解析器执行验证；若区未签名，DANE 无法生效。
运维工程师应在权威 DNS 区部署 DNSSEC 并添加 TLSA 记录，将证书的 SHA-256 指纹或 SPKI 哈希写入。浏览器与验证库可直接核对，拦截 CA 误签或伪造证书。若上游区未签名，需推动注册商与注册局完成 DNSSEC 部署链路，否则 DANE 保护无法落地。
原文: APNIC Blog（2021-08-31）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog