Bug：Azure DNS向手机返回非预期IPv6地址问题排查咨询

返回的2607:7700:0:1a::682c:1742地址属于微软Azure官方DNS64/NAT64服务地址段，既不是DNS区域被篡改，也不是恶意解析结果。
该记录是Azure DNS递归服务自动合成的：当IPv6优先的客户端向Azure DNS发起AAAA查询，而对应权威域未配置AAAA记录时，如果VM所在VNet开启了IPv6功能，Azure默认DNS会自动将域名对应A记录的IPv4地址嵌入NAT64前缀，生成合成AAAA记录返回，设计目的是让IPv6-only客户端通过NAT64网关访问IPv4-only资源。
重启VM前服务正常，是因为当时VNet未启用IPv6相关配置，Azure DNS不会返回合成AAAA记录，手机客户端会自动降级使用A记录的IPv4地址连接；VM重启过程中Azure平台侧可能自动为VNet追加了默认IPv6地址段，触发DNS64自动合成逻辑，而未配置对应NAT64入站转发规则，导致IPv6客户端拿到地址后无法连通。

• 验证解析差异：分别执行dig <你的业务域名> AAAA @168.63.129.16（Azure默认DNS）和dig <你的业务域名> AAAA @8.8.8.8（公共DNS）查询，若只有Azure默认DNS返回上述IPv6地址、其他公共DNS返回无AAAA记录结果，可直接排除权威DNS区域被篡改的可能。
• 检查VNet配置：进入VM所属虚拟网络的配置页，查看地址空间段是否被自动追加了IPv6网段。已有大量用户反馈Azure在VM重启、平台维护窗口期会自动为存量VNet追加IPv6地址段，无需用户手动操作。
• 检查DNS关联配置：确认VNet关联的DNS服务是否为Azure默认DNS（168.63.129.16），开启IPv6的VNet默认启用DNS64功能，无需用户在权威DNS区域配置任何条目就会返回合成记录。
• 检查关联云资源：确认业务域名没有绑定Azure Front Door、CDN、应用网关等自带IPv6接入的资源，这类资源绑定域名时也可能自动生成AAAA记录。

• 紧急恢复（10分钟内生效）：
  暂时不需要IPv6接入的场景下，直接在VNet配置页删除自动添加的IPv6地址段，关闭VNet的IPv6功能，刷新客户端DNS缓存后测试，Azure DNS将不再返回合成的AAAA记录，手机客户端会自动回退到IPv4连接。
• 长期方案：
  • 无IPv6接入需求：显式在VNet配置中关闭IPv6功能，同时将VNet的DNS服务器从Azure默认DNS调整为指定公共DNS或自建DNS，避免后续平台自动更新配置触发同类问题。
  • 有IPv6接入规划：要么为VM网卡分配公网IPv6地址，在DNS区域添加对应AAAA记录，同时配置网络安全组入站规则放行业务端口；要么显式配置NAT64网关的入站端口转发规则，确保合成IPv6地址的流量能正确转发到VM的IPv4地址。
  • 计划切换DNS服务商：迁移前先在新服务商处全量同步所有DNS记录，将域名TTL调整为30s等待24小时，待全球递归DNS缓存过期后再修改NS记录，避免解析中断。注意切换DNS服务商仅能解决公网客户端的解析问题，如果VNet内资源仍使用Azure默认DNS，内网解析依然可能返回合成AAAA记录，需要同步调整VNet的DNS配置。

避坑提醒：不要通过在权威DNS区域添加空AAAA记录或无效AAAA记录的方式屏蔽IPv6解析，这种操作会导致IPv6客户端直接判定地址不可达，不会自动回退到IPv4，反而会扩大故障范围。

内容的提问来源于stack exchange，提问作者BigTFromAZ