症状
只有 IPv6 的终端打不开仅有 A 记录的服务
先确认问题范围：同一服务在双栈电脑可访问、在 IPv6-only 访客 VLAN 或移动热点失败；目标域名没有原生 AAAA 记录，或客户端看到的是由解析器返回的合成 AAAA。这个现象不能仅凭“IPv6 已获取地址”解释，也不应先关闭 IPv6。
DNS64 的职责是为仅有 IPv4 地址的名称合成 AAAA；NAT64 的职责是把该 IPv6 流量转换到 IPv4。RFC 6147 同时指出，DNS64 对某些本地名称或本地可达目的地址的合成必须谨慎处理。因此要把 原始 A/AAAA 记录、使用的解析器、合成地址前缀和 IPv6 默认路由 分开观察。
判断层级
先按 原始 A/AAAA 记录 → 使用的解析器 → 合成地址前缀 → IPv6 默认路由 → NAT64 网关 收敛；不要直接把应用失败解释为 DNS64 失效。
只读诊断命令
在不记录订阅、令牌或家庭公网地址的前提下，用同一个公开测试名称比较不同解析器的回答。dig 不存在时可用系统自带的 nslookup，不要为了本页安装工具。
# 记录 A 与 AAAA 是否原生存在；<resolver> 替换为已获授权的本地解析器
dig A ipv4only.arpa @<resolver> +short
dig AAAA ipv4only.arpa @<resolver> +short
# Linux/OpenWrt：确认 IPv6 默认路由与到合成地址的下一跳
ip -6 route show default
ip -6 route get <synthesized-ipv6-address>
# macOS：观察当前解析器与 IPv6 路由，不修改网络设置
scutil --dns
netstat -rn -f inet6ipv4only.arpa 是 RFC 7050 定义的发现用途名称；它适合判断解析器是否在提供 DNS64 信号，不是业务可用性的单独证明。业务名称若已有原生 AAAA，应优先检查该 AAAA 的实际 IPv6 路径，而不是把它当成 DNS64 故障。
判断分支
- A 有结果、AAAA 为空，且网络明确只提供 IPv6：检查该网络是否设计为使用 DNS64/NAT64；没有 NAT64 的 IPv6-only 网络无法仅靠客户端规则访问 IPv4-only 目标。
- AAAA 是合成地址、IPv6 路由缺失或下一跳错误：问题在本地 IPv6 路由、访客 VLAN、上游 NAT64 前缀宣告或防火墙边界，先恢复预期 IPv6 默认路由。
- 同一解析器给出合成 AAAA，但连接仍失败：在获得网络管理授权后检查 NAT64 网关的可达性与策略；不要以修改应用代理规则替代网络层验证。
- 只有一个设备失败：比较该设备的 DHCPv6/RA 获取结果、私有 DNS 或 VPN 状态。它可能没有使用和其他终端相同的解析器。
配置边界与可回滚修复
DNS64/NAT64 的前缀、上游递归器和转发策略由网络边界设备或上游运营网络决定。不要把下列关系误写成通用客户端 YAML：
IPv6-only client
-> approved DNS64 resolver (synthesizes AAAA only when appropriate)
-> approved NAT64 gateway (translates the IPv6 flow)
-> IPv4-only origin修复时一次只处理一个层级：若 RA/DHCPv6 下发错误，先回滚该 VLAN 的地址或路由下发；若解析器选错，先让测试设备恢复到预期的本地解析器；若 NAT64 服务本身不可用，应由拥有该网关的网络管理员恢复服务。不要把 Wi-Fi 信号、网线质量或设备 CPU 不足归因于 NAT64。
验证
使用同一测试设备重复 A/AAAA 查询，确认默认 IPv6 路由仍存在，再对一个已获授权的 IPv4-only 测试目标进行应用层访问。记录解析器名称、是否得到合成 AAAA、路由是否命中预期下一跳和回滚点；不要记录家庭公网地址或完整抓包。
证据与边界
本页的 DNS64 合成职责与限制以 RFC 6147 为准，Research Engine 已通过静态抓取保存证据哈希。它不证明任何特定运营商、设备或服务必然提供 NAT64，也不承诺某个应用在 IPv6-only 网络可用。