验证IPv6域名解析是否生效，最可靠的办法是分三层核对：权威DNS里AAAA记录是否写对、各地递归DNS能否查到、真实IPv6网络里能否连通，三层全部通过才算真正生效。只盯着一条查询结果就下结论,很容易被缓存和双栈回退带偏。
先把“生效”这个概念拆开
不少人以为在DNS服务商后台点下保存，解析就算生效了，真实的解析链路要跨过权威服务器、递归服务器、客户端三道关，任何一环卡住，用户感知到的都是“没生效”。
三个层次缺一不可
- 权威层：你自己域名的NS服务器上，AAAA记录是否写对、TTL设了多少、有没有把IPv6地址填进A记录里。
- 递归层：运营商Local DNS和公共DNS会把结果缓存起来,缓存期内查到的仍是旧数据。
- 客户端与连通层：终端拿到IPv6地址之后,能不能真正建立连接。
TTL和负缓存是两个容易踩的坑
TTL决定了旧记录在递归服务器里还能活多久，改记录前把TTL调小是常规操作，另一个坑是负缓存：查询一个不存在的AAAA记录时，递归服务器会按SOA里的MINIMUM字段缓存一段“没有记录”的结果，这期间你补上记录,照样查不到。
用dig命令验证AAAA记录：IPv6域名解析怎么验证是否生效
dig是排查解析问题最趁手的工具，Linux和macOS一般自带,Windows可以借助WSL或者在线dig页面。
第一步：看权威服务器怎么答
先找到域名的权威NS：
dig NS www.example.com +short
拿到NS主机名后,直接向它查询AAAA记录：
dig AAAA www.example.com @ns1.example.com +short
返回2001:db8::1这样的IPv6地址，说明权威层配置没问题，返回空、SERVFAIL或者NXDOMAIN，就要回头检查记录是否保存成功、NS是否指向了正确的服务商。
第二步：换几个递归DNS交叉验证
dig AAAA www.example.com @223.5.5.5 +short dig AAAA www.example.com @2400:3200::1 +short dig AAAA www.example.com @8.8.8.8 +short
同一个域名在多个递归服务器上返回一致，基本可以判断记录已经扩散开，只有某台DNS查不到,多半是它的缓存还没过期。
第三步：dig +trace看清整条链路
dig +trace AAAA www.example.com
它从根服务器一路问到权威服务器，能直观看到在哪一跳断掉，委托关系异常、NS记录缺失,都会在这一步暴露出来。
Windows和Linux下的本地验证命令
Windows环境
nslookup -qt=AAAA www.example.com nslookup -qt=AAAA www.example.com 223.5.5.5 Resolve-DnsName www.example.com -Type AAAA -Server 2400:3200::1
Resolve-DnsName比nslookup信息更全，能直接看到TTL和记录类型,排查时优先用它。
Linux和macOS环境
dig AAAA www.example.com +short host -t AAAA www.example.com getent hosts www.example.com
getent hosts走的是系统解析器，反映的是应用真实拿到的结果,比单独跑dig更贴近实际访问场景。
连通性才是最后一关
查到地址不等于能用,还要确认IPv6链路通不通：
ping -6 www.example.com curl -6 -I https://www.example.com mtr -6 www.example.com
curl返回200或301、302，说明IPv6侧的应用层已经通了，连接超时但IPv4正常，问题通常出在防火墙或安全组没放行IPv6,或者服务器压根没配IPv6地址。
| 验证层级 | 常用命令 | 关注点 |
|---|---|---|
| 权威层 | dig AAAA @权威NS |
记录是否存在、地址拼写是否正确 |
| 递归层 | dig AAAA @公共DNS |
多节点结果是否一致 |
| 客户端层 | Resolve-DnsName、getent hosts |
本机实际拿到的地址 |
| 连通层 | curl -6、ping -6 |
能否建立IPv6连接 |
IPv6 DNS解析失败常见原因排查
记录加了但查不到
- 记录类型选错，把AAAA写成了A,或者地址填成了IPv4格式。
- 主机记录填错，
www和混用。 - 修改后TTL没到,旧记录还在缓存里。
- 域名接入了CDN或托管DNS，得去对应平台改,而不是在域名注册商处改。
能查到但访问不了
- 服务器只监听了IPv4，比如Nginx配置写的是
listen 80;而不是listen [::]:80;。 - 云服务器安全组只放了IPv4规则。
- 本机没有IPv6出口,或者所在网络是IPv6孤岛。
- 证书只签了域名没签IP,用IPv6字面量直连会报证书错误。
双栈环境下的优先级问题
业内专家指出，双栈客户端普遍采用优先尝试IPv6、超时再回退IPv4的策略，网页能打开”根本不能证明IPv6解析生效，要确认，就得用curl -6强制走IPv6,或者在不支持IPv4的网络环境里实测一次。
电信联通移动IPv6 DNS解析差异对比
同一域名结果不一样的原因
不同运营商使用的Local DNS不同，缓存策略、递归路径、对EDNS Client Subnet的支持程度也有差异，再加上部分CDN会按来源IP返回不同的AAAA地址，同一时间在不同网络里查到的结果本来就可能不同，行业共识认为，判断解析是否生效要看多个网络下结果是否指向正确的服务节点，而不是要求所有结果完全一致，据工信部近年推进IPv6规模部署的相关文件，国内网络基础设施的IPv6承载能力在持续提升,但仍存在地域和运营商之间的差异。
跨运营商怎么验证
最省事的办法是用多地拨测平台，选电信、联通、移动的IPv6节点分别发起DNS查询和HTTP请求，手头没有拨测资源，也可以用手机分别连三家运营商的移动数据,访问在线检测页面做对比。
| 公共DNS | IPv4地址 | IPv6地址 |
|---|---|---|
| 阿里公共DNS | 5.5.5 | 2400:3200::1 |
| 腾讯公共DNS | 29.29.29 | 2402:4e00:: |
| Google Public DNS | 8.8.8 | 2001:4860:4860::8888 |
| Cloudflare | 1.1.1 | 2606:4700:4700::1111 |
| CFIEC公共DNS | 240C::6666 |
网站开启IPv6访问后的完整验收步骤
- 在DNS控制台确认AAAA记录已保存,上线前先把TTL调小。
- 用
dig NS确认权威服务器,再向权威服务器查AAAA。 - 换至少三个公共DNS递归查询,确认结果一致。
- 用
dig +trace确认解析链路没有断点。 - 在服务器上确认服务监听
[::],防火墙和云安全组放行IPv6。 - 本机用
curl -6请求首页,确认状态码正常。 - 用手机移动数据访问站点,观察实际是否走了IPv6。
- 用多地拨测平台做一轮跨运营商验证并留存结果。
免费IPv6解析在线检测工具怎么用
不想敲命令，可以借助公共DNS服务商的在线检测页和免费IPv6解析在线检测工具：输入域名，看是否返回AAAA记录、响应时间多少、不同地域节点是否一致，这类工具适合快速初筛，结论仍要回到命令行复核,因为在线工具展示的往往只是某一个节点的缓存结果。
关于IPv6域名解析验证的常见问题
Q1：AAAA记录添加后多久生效？
取决于TTL设置，递归DNS在TTL到期前会一直返回旧结果，所以变更前把TTL调到几分钟，能让改动更快扩散，如果之前查询过不存在的AAAA记录,还要等负缓存过期。
Q2：域名只有A记录没有AAAA记录，算不算IPv6解析失败？
算，纯IPv6网络下的客户端无法通过域名访问该站点，只能依赖NAT64、DNS64等过渡机制，要做到双栈访问,AAAA记录是必要前提。
Q3：在线工具查到AAAA记录，是不是就说明配置正确？
不等同，它只证明某个节点能查到记录，还要确认记录指向的是当前服务的真实IPv6地址、服务器监听正常、防火墙放行,三项都成立才算配置正确并生效。
验证IPv6解析没有捷径，权威层、递归层、连通层逐层核对，比反复刷新后台页面有效得多，把上面这套命令和清单固化成上线流程,每次变更都能在几分钟内确认结果。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/771352.html
