背景：
当我们需要访问www.baidu.com这个站点时，我们就会在浏览器地址栏中输入http://www.baidu.com这样一个url。实际上我们想要浏览的网页内容都存放在互联网的某台服务器上，而 DNS 的任务就是找到我们想要访问的这台服务器的 IP 地址，然后向它请求内容。 DNS 地址解析是在 HTTP 连接建立之前的一个过程。 本地 DNS 服务器得到浏览器的域名解析请求后，会采用递归查询方式或者迭代查询方式向 DNS 系统中的其他远程域名服务器提出查询要求。
问题描述：
客户反馈广东电信IDC访问至腾讯云CDN节点，出现丢包现象。
原因分析：
问题相关信息梳理：
1、查看广东电信的调度，发现客户通过PING返回的IP并不在调度节点ip列表里；
2、按理PING返回的IP应该为广东电信，但实际是腾讯网络，与预期不符；
3、三大运营商访问腾讯云网络的CAP节点会限速，出现丢包是正常现象。
此时需要确认，为何电信用户访问到腾讯云CAP节点。分析思路如下：
该域名的调度策略是DNS解析，和客户确认测试环境配置的DNS为119.29.29.29（智能dns），支持根据客户端IP归属进行解析。客户反馈的客户端IP归属广东电信运营商。同时也引导客户配合在测试环境CURL测试，通过CDN侧查询日志发现记录的客户端来源信息与反馈的吻合。结合获取的信息，以及智能DNS解析的原理，请求应该调度至广东电信节点，但实际并不是。那么，是否客户提供的DNSIP信息不对呢？带着这个疑问，我们联合客户进行了测试验证。
客户测试环境运行dig @119.29.29.29 xxx，返回的为广东电信的CDN节点IP。再运行如下2个命令，发现返回的DNSIP归属为腾讯云网络。此时客户反馈他们配置的是内网LDNS，且在该DNS上做了特殊的转发策略，预期的是转发到119.29.29.29。但通过腾讯云dns同事协助确认，转发的配置存在问题，实际是将域名递归转发到了腾讯递归网络出口，导致最终解析到腾讯云的CAP节点。
cat /etc/resolv.conf
for i in {1..30};do dig short $i.ip.dnspod.net ;done |sort -u
解决方案：
修改用户Local DNS配置，保证发起域名解析的环境与客户端ip的环境相同，即走电信出口。
ps：智能dns解析原理
例如8.8.8.8、119.29.29.29等采用了bgp anycast edns的技术。
其中anycast是多个主机使用相同ip地址的技术，该地址即为这一组主机的共享单播地址。当发送方发送报文给这个共享单播地址时，报文会根据路由协议路由到这一组主机中距离发送方最近的一台。比如谷歌在全球部署了多套DNS服务器，只是对外ip均为8.8.8.8，运营商会根据路由将用户导到距离最近的dns服务器。
8.8.8.8虽然可以做到全球任播来尽量将自己的出口IP靠近真实访客，但是一个个地区部署节点成本还是非常惊人，而且调度效果并不好。因此谷歌设计了一个协议 EDNS0（edns-client-subnet），允许递归服务器在查询包中加上访客的实际IP地址供权威服务器精准调度。即可以实现根据客户端IP归属进行解析。
