IPv6-only网络正在成为移动运营商和企业内网的真实部署形态，但互联网上仍有大量源站只提供IPv4地址。CDN边缘节点夹在客户端与源站之间，既要对外响应IPv6-only客户端的AAAA查询，又要在回源时与IPv4-only源站通信。这种地址族不对称恰恰需要NAT64与DNS64来弥合。然而，CDN边缘节点对这两种机制的支持并非理所当然，不同厂商和配置方式会产生截然不同的结果。本文将围绕边缘节点的实际行为展开讨论。
理解IPv6-only与NAT64/DNS64的工作机制
在纯IPv6网络中，主机只配置了IPv6地址和IPv6 DNS服务器，无法直接向IPv4地址发起连接。DNS64的作用是在DNS解析阶段把IPv4的A记录合成为IPv6的AAAA记录，通常使用知名前缀64:ff9b::/96。例如源站地址192.0.2.1会被转换成64:ff9b::c000:201，其中c000:201是IPv4地址的十六进制表示。客户端随后向这个合成地址发送IPv6数据包，数据包会被路由到NAT64网关。
NAT64网关维护IPv6与IPv4之间的状态化映射，把IPv6源地址和端口翻译成IPv4源地址和端口，再将目标地址从合成IPv6地址还原为真实IPv4地址，最后把响应流量反向翻译回来。这种转换对应用层基本透明，但会引入MTU、分片、DNS缓存以及状态表老化等一系列工程问题。对于CDN来说，边缘节点可能同时扮演客户端和递归解析器的角色，因此理解它在DNS64查询和NAT64数据面中的位置非常关键。
# 在IPv6-only客户端上查询一个只有A记录的域名 $ dig AAAA ipipp.com +short 64:ff9b::c000:201 # 查看反向地址是否为真实IPv4 $ ip -6 route get 64:ff9b::c000:201 64:ff9b::c000:201 via 2001:db8::1 dev eth0 src 2001:db8::100 metric 1024
上面的命令展示了DNS64合成结果以及本机路由如何将流量引向NAT64网关。值得注意的是，DNS64只合成AAAA记录，如果域名本身已经有真实的AAAA记录，DNS64服务器通常不会覆盖它，这就避免了双重转换。
CDN边缘节点对NAT64/DNS64的支持现状
CDN边缘节点对外提供服务时，通常同时发布A和AAAA记录，因此IPv6-only客户端可以正常解析到边缘节点的IPv6地址。问题主要集中在回源阶段。如果源站只有IPv4地址，CDN边缘节点作为回源客户端，必须能够访问IPv4网络。多数大型CDN的边缘节点部署在双栈网络中，节点自身拥有IPv4地址，可以直接通过IPv4回源，此时不需要NAT64。这种架构下，IPv6-only客户端到CDN边缘节点的连接是纯IPv6，边缘节点到IPv4源站的连接是纯IPv4，CDN在中间完成了地址族切换。
但当CDN边缘节点本身也处于IPv6-only网络时，情况就完全不同了。边缘节点没有IPv4地址，要访问IPv4-only源站就必须依赖NAT64。这要求节点操作系统具备NAT64客户端能力，即能够识别64:ff9b::/96等合成前缀并将数据包路由到正确的NAT64网关。一些CDN厂商通过在边缘节点上部署本地的NAT64网关或隧道集中器来解决这个问题，另一些则要求源站提供IPv6地址以直接建立IPv6回源连接。
不同CDN平台的支持策略差异明显。部分云厂商的CDN产品允许用户将源站配置为IPv6地址，并优先使用IPv6回源；如果源站只有IPv4，则默认通过双栈节点回源，不涉及NAT64。而一些专门面向运营商IPv6-only场景的CDN方案，会内置DNS64解析逻辑，在边缘节点上直接使用合成地址访问源站，并由平台负责维护NAT64转换。要判断某个CDN是否真正支持IPv6-only回源，不能只看其对外是否提供AAAA记录，还要确认回源链路是否具备IPv6连接能力或NAT64路径。
| CDN能力项 | 双栈节点 | IPv6-only边缘节点 |
|---|---|---|
| 对外提供AAAA记录 | 支持 | 支持 |
| 直接IPv4回源 | 支持 | 不支持，需NAT64 |
| 直接IPv6回源 | 按源站配置 | 按源站配置 |
| 依赖DNS64解析 | 通常不需要 | 需要 |
这张表简要概括了两种边缘节点形态下的能力差异。实际部署中，边缘节点可能是双栈但回源网络被防火墙限制为仅IPv6，这种情况等同于IPv6-only边缘节点，必须启用NAT64或确保源站有IPv6地址。
在CDN架构中实施NAT64/DNS64的关键配置与注意事项
如果要让CDN边缘节点在IPv6-only环境中通过NAT64访问IPv4-only源站，首先需要在边缘节点所在网络内配置DNS64解析服务器。BIND是常用的实现，其配置片段如下所示，核心是dns64选项，指定合成前缀并排除某些不应合成的域名。
options {
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
allow-query { any; };
dns64 64:ff9b::/96 {
clients { any; };
exclude { any; };
};
};
上述配置会让BIND对没有AAAA记录的域名自动合成AAAA记录。需要注意的是，exclude块中的any表示排除所有真实的AAAA记录，也就是只要域名有真实AAAA记录就不做合成，这是常见的默认行为。如果某些内部域名不希望走NAT64，可以在exclude中指定具体域名或地址前缀。
接下来是NAT64网关的配置。Jool是一个广泛使用的开源NAT64实现，它运行在Linux内核中。以下示例展示了如何添加一个NAT64实例，并将IPv6前缀64:ff9b::/96映射到IPv4地址池。
# 加载Jool内核模块 modprobe jool # 创建NAT64实例，使用默认网络命名空间 jool instance add "nat64-instance" --netfilter --pool6 64:ff9b::/96 # 配置IPv4地址池 jool pool4 add 192.0.2.10
在边缘节点上，还需要确保IPv6路由能够将合成前缀的流量送到NAT64网关。如果NAT64网关地址是2001:db8::1，可以在节点上添加静态路由：ip -6 route add 64:ff9b::/96 via 2001:db8::1。否则边缘节点即使拿到了合成AAAA记录，也会因为没有到达该前缀的路由而无法建立连接。
对于CDN平台而言，如果用户希望启用IPv6-only回源，通常需要在源站配置中填写IPv6地址，或者选择平台提供的IPv6回源选项。部分平台允许用户指定源站域名，边缘节点会使用平台内部的DNS64解析该域名，从而自动获得合成地址。无论哪种方式，都必须确认边缘节点到NAT64网关的MTU足够大，建议设置为至少1280字节，以避免IPv6最小MTU限制下的分片问题。
故障排查与性能优化建议
当CDN在IPv6-only环境中出现回源失败时，最常见的表现是客户端能解析到边缘节点IPv6地址，但边缘节点回源超时。排查时首先应确认DNS解析结果。在边缘节点上执行dig AAAA 源站域名，观察返回的是合成地址还是真实AAAA地址。如果返回为空，说明DNS64没有生效，需要检查边缘节点配置的DNS服务器是否为DNS64服务器。如果返回了合成地址，但连接失败，则检查边缘节点是否有到64:ff9b::/96的路由，以及NAT64网关是否可达。
# 在边缘节点上测试到合成地址的连通性 $ ping6 -c 3 64:ff9b::c000:201 # 跟踪到NAT64网关的路径 $ traceroute6 64:ff9b::c000:201 # 查看NAT64转换状态（在NAT64网关上执行） $ jool instance display
另一个容易被忽视的问题是MTU。NAT64转换会增加少量开销，如果IPv6路径MTU小于1280字节，或者IPv4侧有DF位导致无法分片，就会出现黑洞。建议在边缘节点和NAT64网关之间启用路径MTU发现，并对关键业务开启TCP MSS调整，例如在NAT64网关上设置ip6tables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu。
性能方面，NAT64是有状态转换，高并发下状态表可能成为瓶颈。应合理配置状态表大小和超时时间，避免频繁创建和销毁映射。对于CDN场景，边缘节点的连接复用和Keep-Alive机制能够有效减少NAT64状态压力。此外，尽量让边缘节点优先使用真实IPv6回源，只有源站确实不支持IPv6时才启用NAT64，这样既能降低转换开销，也能减少因为合成前缀变化导致的DNS缓存问题。最终的目标是在IPv6迁移过渡期内，让IPv6-only客户端能够获得与双栈环境一致的访问体验，同时不牺牲CDN的加速效果和稳定性。