公网DNS Server无响应导致MS业务访问故障

z36306610

Gb接口中DNS query消息中dest ip代表的是DNS域名解析服务器的地址吗？采集Gb接口时发现DNS超时比较多，就是发两条query，但始终得不到响应，两条dns间隔1s左右，可能是什么原因造成的？请高手指点！

爱卫生

回复 z36306610 的帖子

   Gb接口应该不会有DNS消息才对。因为SGSN不需要通过DNS来寻址BSC，无论是Gb Over FR还是Gb Over IP。同样，BSC也不需要通过DNS来寻址SGSN。而Gb接口又没有其他的网元了。
   倒是Gn接口有很多流程需要用到DNS。可以参考GPPS网络中哪些流程会涉及到PS网内(Gn网段)的DNS。
   但就你说的例子来看，我个人觉得可以排除是BSC和SGSN的DNS交互。
   所以我猜应该是MS已经PDP激活成功，访问外部PDN网络时用到的DNS。例如MS要去访问新浪的Server。而一般在激活成功后，GGSN可能会分配两个DNS Server地址给MS。这很好确认。只要能够提供一下抓包。或者你自己看一下，协议栈是不是从下往上，依次是ETH--IP---UDP---NS---BSSGP---LLC----SNDCP----IP---UDP---DNS，如果是这样的话，SNDCP右边即它的上层IP头部中的目的IP就应该是公网的DNS Server地址，应该是公网IP，如果第一个无响应。MS就会去尝试第2个。并且你可以看下应用层DNS里面请求解析的是什么，如果是一个网站的地址，那确认是MS发的无疑。以上就能解释你说的现象了。

z36306610

通过统计发现DNS超时比较很高，下面是超时的统计结果，附件中是信令流程，确实是访问外部PDN网络时用到的DNS。这种超时比例这么高一般是什么原因造成的，有什么优化方法，请楼主指教？

排名	DNS IP	请求次数	超时次数	超时占比
1	211.136.20.203	113000	112198	99.29%
2	211.136.17.107	54201	53549	98.80%
3	211.147.6.4	5216	5158	98.89%
4	8.8.4.4	323	317	98.14%
5	8.8.8.8	123	108	87.80%
6	125.39.102.135	94	94	100.00%
7	70.87.197.193	80	76	95.00%
8	193.138.206.157	73	73	100.00%
9	70.85.236.75	75	71	94.67%
10	193.138.247.113	73	71	97.26%

爱卫生

回复 z36306610 的帖子

  出现大面积的公网DNS Server故障，这种可能性不大。我估计有可能和Gi防火墙上的NAT会话状态有关。
  在做排查时，建议可以将Gi口防火墙作为故障定位分界点，先从Gi口防火墙去ping及traceroute这些公网的DNS Server，如果没有问题，那估计80%以上可能就是防火墙的NAT会话状态表有问题。当然也有可能是PS核心网的Gn接口经过的IP承载网有丢包。如果从Gi口防火墙检测到公网的DNS Server有问题，证明Gi口后面的IP承载网有问题，那就traceroute定位到具体的IP，提交给数据网维护的同事帮忙排查。仅供参考。

z36306610

另外一个bsc的情况跟这个差不多
排名        DNS IP        请求次数        超时次数        超时占比
1        211.136.20.203        113000        112198        99.29%
2        211.136.17.107        54201        53549        98.80%
3        211.147.6.4        5216        5158        98.89%
4        8.8.4.4        323        317        98.14%
5        8.8.8.8        123        108        87.80%
6        125.39.102.135        94        94        100.00%
7        70.87.197.193        80        76        95.00%
8        193.138.206.157        73        73        100.00%
9        70.85.236.75        75        71        94.67%
10        193.138.247.113        73        71        97.26%

z36306610

排名        DNS IP        请求次数        超时次数        超时占比
1        211.136.20.203        39151        38864        99.27%
2        211.137.191.26        36895        858        2.33%
3        211.136.17.107        11534        11424        99.05%
4        10.0.0.172        438        438        100.00%
5        210.44.144.44        351        332        94.59%
6        118.123.115.9        268        268        100.00%
7        61.135.167.182        236        13        5.51%
8        10.221.115.30        192        192        100.00%
9        10.221.165.95        168        167        99.40%

z36306610

版主你好，请问dns解析不成功，是不是用户就无法登陆相关网页，DNS成功率低还会影响哪些指标？谢谢！

爱卫生

回复 z36306610 的帖子

   是的，如果DNS Server解不出来，用户肯定就什么页面也看不到。看到的应该就是手机的浏览器始终在连接中，但过了10秒左右就会连接失败，浏览器自动退出。在你的例子里，就是用户请求解析mtalk.google.com。但解析不出来，就无法访问了。
   至于影响的指标，我想知道你关心的是哪些指标。因为站在PS核心网的角度，通常关心的指标就是附着成功率还有PDP激活成功率，还有RAU成功率等等。像这几项都不会受到影响的。因为MS既然能给外部公网的DNS Server发解析请求，代表附着和PDP激活都已经成功了。不论MS发多少个DNS解析请求以及没有得到DNS Server响应，都不涉及附着和PDP激活。所以没有任何影响。
  所以，如果你还有什么指标需要关心的，也可以列出来，大家一起分析。

z36306610

了解，谢了！{:soso_e183:}

爱卫生

回复 z36306610 的帖子

   这个案例和无Cause Code---Gi口后的应用服务器无响应这个帖子的案例还比较相似。仅供参考。

crist8308

谢谢斑竹和各位高手的解答，又学了不少。
我有一个相关的问题：
假设我遇到的情况是DNS服务器超时，那么应该我抓包的结果是在2条DNS Standard Query消息后，没有任何的流程进行(包括TCP握手、以及后续的所有流程)，是么？

但我在做MS主动测试的时候(我做测试的方式是不停地进行上网操作)，在Gi口采集数据的结果发现DNS查询确实没有响应，但后续还有TCP的建立及数据包捕捉到(我采用的方式是用PDP激活后的APN分配的地址来识别该用户)。不知这种情况是不是DNS查询成功和不成功的数据混合在一起呢？
以下附上数据包的片段。

爱卫生

回复 crist8308 的帖子

  呵呵。这个抓包确实是比较怪。感觉不应该啊。我解释不了哦。
  从抓包来看，确实是DNS没响应，确发起了后续的TCP连接。我也查了下TCP连接的目的IP，确实应该是属于sina网的。我感觉如果抓包没有漏的话，确实和正常的流程不大一样。因为发起TCP连接需要对端的目的IP，而不能根据对端域名来发起。所以手机一定要知道sina网服务器的IP地址才能发起TCP连接，但看包DNS又没有应答。那手机怎么知道sina服务器的地址的呢？
  会不会手机的应用程序里存放了sina网的IP地址呢？或者换一个网址试试呢？
  你还可以做个实验，在本地PC访问一个之前从未访问过的网站（例如www.google.com.my Google马来西亚站，这样可以保证本地没有缓存)，就会看到首先是DNS解析过程，然后再就是到google网站的TCP连接过程。

arrowbroken

回复 爱卫生 的帖子

楼主，我分析了一下 packet, 发现很多下行的包都没有，比如DNS QUERY response, ,TCP SYN ACK, FIN以及HTTP 200 OK  for HTTP GET 都没有，但是这些包肯定是有的。简单来看，整个文件里只有171.17.11.227发出的包，没有收到的包。我想楼主是不是做的镜像miror抓包，只做了一个方向的镜像，没有做另外一个方向的包。