打开终端，名解敲下 dig AAAA example.com，名解返回的名解那串 2408:8207:… 就是 IPv6 地址。整个过程跟查 IPv4 的名解 A 记录没太大区别，但底下发生的名解事，比表面看到的名解要绕一些。

DNS 本身对 IPv6 的名解支持分两个层面，很多人搞混。名解一个是名解传输层——DNS 查询走 IPv6 网络；另一个是数据层——DNS 里存 IPv6 地址。这是名解两回事。你完全可以用 IPv4 网络去查一个 AAAA 记录，名解也可以让 DNS 服务器通过 IPv6 来响应 A 记录的名解查询。实际部署中，名解运营商递归服务器大多已经双栈，名解但权威服务器这边，名解IPv6 传输的覆盖率远没有想象中高。

AAAA 记录是核心。名字来源是 IPv6 地址 128 位，是 IPv4 的 4 倍，A 加四个 A，就这么来的。格式上跟 A 记录平行，一个域名可以同时挂 A 和 AAAA，客户端根据自身网络能力选择。RFC 3596 定义了这套机制，1995 年就有了，比很多人以为的要早得多。

有意思的是 AAAA 记录的数量分布。我查过一批国内站点的 AAAA 解析情况，大厂基本都配了，但中小站点覆盖率不高。原因不复杂——很多站长用的虚拟主机或者 CDN 还没完整支持 IPv6 回源，配了 AAAA 反而可能出问题。有个做外贸的朋友，给站点加了 AAAA 记录之后，部分移动用户访问变慢，排查半天发现是 CDN 节点的 IPv6 回源链路质量差。最后他把 AAAA 撤了，等 CDN 那边升级再说。

解析过程中的一个细节：当客户端同时拿到 A 和 AAAA 记录时，选择哪个？RFC 6724 给了一套地址选择算法，考虑前缀策略、源地址匹配、 scope 等因素。简单说，如果客户端自己有 IPv6 地址，优先走 IPv6。但现实里 Happy Eyeballs 算法更常见——同时尝试 IPv4 和 IPv6 连接，谁先通就用谁。Chrome 和 Firefox 都实现了这套机制，延迟控制在 250ms 左右。这个设计很务实，避免了 IPv6 链路不通时用户干等。

AAAA 记录还有个坑：有些域名配了 AAAA 但实际服务没监听 IPv6，客户端拿到地址后连接超时。这种“假 AAAA”比没有 AAAA 更糟糕。没有 AAAA，客户端直接走 IPv4；有 AAAA 但连不上，得等超时才会回退。排查这类问题时，dig 看记录、ping6 测连通、curl -6 验证服务，三步基本能定位。

DNSSEC 跟 IPv6 解析的关系也值得提一句。AAAA 记录的签名验证跟 A 记录走同一套机制，但有些老旧的 DNS 解析库在处理 AAAA 的 DNSSEC 验证时存在兼容性问题。我遇到过一例，某域名 A 记录验证通过，AAAA 记录却报 SERVFAIL，换了个解析器就好了。这种问题隐蔽，抓包才能看清。

自建 DNS 的话，BIND 和 Unbound 对 AAAA 的支持都很成熟。配置上没什么特别的，zone 文件里加一行 AAAA 记录就行。真正要留意的是防火墙——53 端口的 UDP 和 TCP 都得放行 IPv6 流量，有些环境只开了 IPv4 的规则，AAAA 查询直接就被挡了。

IPv6 域名解析不是新话题，但落地过程中的细节比协议文档里写的要琐碎。配一条 AAAA 记录只要几秒钟，保证它真正可用，涉及的东西不少。