作者介绍
林伟壕，网络安全devops新司机，先后在中国电信和网易游戏从事数据网络、网络安全和游戏运维工作。对linux运维、虚拟化和网络安全防护等研究颇多，目前专注于网络安全自动化检测、防御系统构建。
众所周知，随着“微信红包”等热门应用的红火，微信支付在我们的生活中已无处不在。今天我要分享的内容，正是关于微信支付面向商户的api 在ipv6支持上的一个问题。关注点不仅在于问题本身，更在排查故障过程中一些思路和方法论。
故障简述
故障详情
发现故障，在处理的第一步经常是做故障重现，先使用shell脚本进行测试：
测试结果如下：
可以看到，第一次连接花费了15秒+的时间，之后都是毫秒级的返回。所以如何定位首次连接耗时过长的问题是当前重点。
处理过程
节点1
由于发生这个问题之前，我们有一个内部应用也有类似问题，比如第一次访问网页需要加载超过10s才能出来，之后访问就非常快了。当时通过抓包的方式定位到同一网络中有其他ip劫持了流量，增加了中间建立连接的时间，后来去除劫持源头后才恢复正常。于是，受过往经验影响，我首先猜想是可能是网络原因或者劫持。按照这个思路，先排查发起请求的客户端所在网络，发现是独立的外网ip，没有nat等相对复杂的网络环境。同时，切换了一个网络环境进行测试，又发现每次请求响应都很快，测试结果如下：
因此网络问题仍无法彻底排查，于是决定在curl的同时抓包。
tcpdump -w test.pcap
抓包下来，用wireshark打开，看看是怎么连接建立过程是怎样的。
发现第一次请求有tcp重传，于是更加怀疑是网络问题，但从这里又无法直观看到是具体原因。所以开始往客户端所在服务器环境进行排查。
节点2
处理过程中同样是想起，之前遇到一个iptables规则配置不合理导致数据包梳理效率很低的问题，所以一开始在服务器环境排查时优先检查了iptables配置规则，发现也挺合理的，对于首次建立的连接没有set tag，也没有对new有特别设置，然后又临时清除了所有iptables规则发现问题依旧，于是跳过iptables。
节点3
到了这里，我开始怀疑dns解析异常也会引起首次建立连接耗时过长的问题。于是开始检查/etc/resolve.conf，不管是检查配置，还是更换dns服务器问题都是一样的。但是，“有心栽花花不开，无心栽柳柳成荫”，这个过程中我还是抓了包，这么一来，发现ipv6地址解析异常了！
可以看到，dns服务器返回的ipv6解析结果是”server failure aaaa”，而且耗时超过5s，这里就有问题了。
节点4
下面开始把焦点集中到微信支付域名api.mch.weixin.qq.com的ipv6解析上，发现有servfail，而且重现率很高。
同时指定了ipv4的解析，发现a的查询很快：
既然确定了ipv6解析有问题，ipv4解析正常，于是修改了相关代码，确认强制域名解析ipv4的话，都是正常的。
原因分析
从dns原理看问题
1、整个dns解析过程
如上图，当一个客户端发起dns解析请求时，会有一个优先级的，按照本地dns缓存->/etc/hosts的dns配置->isp或本地域名解析缓存服务器->根域名服务器->顶级域名服务器->...->目标站点权威服务器的顺序一路解析下来。
结合本次故障来看，问题应该是在权威服务器这里。究竟如何，且看下文解说。
先来看看对比的解析结果：
a.api.mch.weixin.qq.com的ipv4解析结果
b.api2.mch.weixin.qq.com的ipv4解析结果
c.api.mch.weixin.qq.com的ipv6解析结果
d.api2.mch.weixin.qq.com的ipv6解析结果
从上面的测试结果可看出，api2.mch.weixin.qq.com ipv6解析正常，api.mch.weixin.qq.com.ipv6解析失败是因为多了一层：
api.mch.weixin.qq.com. 600 in cname forward.qq.com.，然后 forward.qq.com aaaa 的解析返回是错误的，这里是权威服务器处理失败了。
为什么客户端解析的是 api.mch.weixin.qq.com aaaa，而缓存回去查询 forward.qq.com aaaa 呢？
这是因为 api.mch.weixin.qq.com. 600 in cname forward.qq.com. 这条记录被缓存了，导致后边后续的查询都会变成查 forward.qq.com 对应的记录。
下面再对比一下解析www.163.com和api.mch.weixin.qq.com看看在权威服务器层面有何不同。
这里api.mch.weixin.qq.com的aaaa 解析返回有问题，是soa，按协议应该还是返回 cname 记录；可以对比 www.163.com 的解析结果发现后者就是返回的soa。
从上文可以看到 forward.qq.com. 实际上是做了一层 ns，虽然没有真正的授权出去（ns-os1.qq.com. 上没有 forward.qq.com soa 记录），但缓存看来，它已经授权了一层，而返回的 soa 有误，因此缓存服务器无法判定该 nodata 返回的类型，所以认为该返回不合法，最终导致了api.mch.weixin.qq.com和forward.qq.com 的aaaa记录一直返回 servfail，所以缓存服务器会尝试继续解析，从而导致首次解析时间过长。等到之后解析成功后，就使用的本地缓存，所以解析很快，等到缓存失效后，问题就会重现。
2、关于curl的dns解析顺序
一般来说，如果服务器开启了ipv6，curl默认会优先解析 ipv6，在对应域名没有 ipv6 的情况下，会等待 ipv6 dns解析失败 timeout 之后才按以前的正常流程去找 ipv4。dns服务都是支持解析ipv6的，如果没有设置ipv6解析，查询结果就是空，不会是serverfail。
3、关于nslookup和dig的工作原理
不同操作系统nslookup和dig的原理并不同，比如win7的nslookup每发一次ipv4请求就会产生2个a记录请求，换到win xp下nslookup没发一次ipv4请求则只会产生一个a记录请求，所以在抓包分析时需要根据不同操作系统的应用特性进行区分。
微信原来已有解决方案
针对这个问题，其实微信官方文档
商户访问微信支付
商户侧使用api.mch.weixin.qq.com(主)和api2.mch.weixin.qq.com(备)这两个支付api域名访问微信支付，这两个域名功能完全一样。
这两个域名分别配hosts绑定专线访问微信的两个131开头的策略ip,具体电信ip和联通ip那个绑定到api和api2, 商户侧可以测速后自己决定。
商户侧的访问支付接口的代码逻辑需具备失败换域名重试的机制,即访问api.mch.weixin.qq.com不通的话,就换成api2.mch.weixin.qq.com重试。
商户侧访问微信支付时，若两条专线都不通，要有能切回走公网访问的能力。若无法走公网，则商户侧需要知晓这里的风险。
可行的解决办法
关闭服务器ipv6功能
1、使用ifconfig验证是否开启ipv6：
2、查看服务监听的ip验证是否开启ipv6：
3、使用lsmod验证是否开启ipv6：
关闭ipv6：修改/etc/modprobe.conf加入如下的两条，重启系统即可。
alias net-pf-10 off
alias ipv6 off
开启ipv6：ipv6是默认支持的，所以只需将/etc/modprobe.conf中的上面两条指令注释掉即可。
在/etc/hosts文件中指定域名ip解析记录
按照下面格式配置，但是如果指定的服务器故障了，业务也会受牵连，这不是很稳妥的方法。
api.mch.weixin.qq.com 183.3.235.18
在代码中指定域名解析使用ipv4结果
比如php：
使用微信官方方案，设置主备域名进行冗余，支持域名解析失败切换。
经验教训
熟读用户文档
很多人学习技术知识时喜欢在搜索引擎找别人的博客或者问题解答来作为知识学习的入口，其实这里有个问题，博客或者问题答案经过别人的消化，一方面提高了易读性，另外也引入了偏见误解，同时无法保证完整性。反观官方的用户文档，特别是外文的，易读性相对差，不过很权威也很全面，很多细节问题都有。但很多人不愿意好好看用户文档，而是通过网络上很零碎的知识去学，这样难免有遗漏。像这次我们使用微信支付api过程中用户文档没有看到这一块，绕了一圈，反而增加了学习成本。因此，学习或者使用新系统新技术，熟读用户文档反而是一个很基础的地方呢。
不能思维固化
从上面的处理过程来看，可以发现由于之前有类似问题的处理经验，一开始我往网络或劫持，或iptables等方向去定位问题，并没有带来太大作用。很多时候有相关经验起码能提供思路，不失为一种优势。而有时候，太重视经验也会导致思维固化，没能把基础的信息全面收集后再做定性，后做定位，就会事倍功半。
原文发布时间为：2017-02-28
本文来自云栖社区合作伙伴dbaplus