DNS

# DNS解析问题
## 前情提要
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2024.11.22周五，学校网络出口带宽扩容，[专线][0]网络升级，于是需要进行一次紧张刺激的[网络割接][1]操作，说大白话就是要大改一次，所以苗同学同时提出要解决一个历史遗留的小问题需要一并解决：微信的头像和视频号加载有问题，怀疑是[DNS][2]的解析问题，遂趁着这次改动一并解决掉这个小小的小问题。
## 跌宕起伏，惊心动魄的正文
### 第一次改动
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;由于前期也收集到了一些关键信息，怀疑DNS被[策略路由][4]强制引流到教育网出口线路上，导致DNS解析地址为教育网[CDN][3]地址，移动网无法访问该CDN地址，从而引发了前期微信相关的一些访问异常的问题。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;于是，苗同学和锐捷网络的一线工程师彭老师商讨了一下解决方案，==不使用策略路由的方式强制让校内的DNS，即，将DNS视为普通用户，用户怎么上网，DNS也怎么上网。==
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;那么理论上我们到此应该解决了该问题，或者说，已经解决了大部分问题：我们修改完后测试微信的访问的确正常了，这也验证了我们的猜想。但是......
### 第二次改动
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;在Part1后的第二天，也就是周六上午九点多，刚睡醒的苗同学突然接到了来自隋老师的电话，被告知了一个严重却又不那么严重的消息：校外网络打不开[堡垒机][5]和[SSL VPN][6]了。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;刚刚还沉浸在睡梦中没有完全醒过来的苗同学立马精神了起来，着手处理这个问题，隋老师认为是DNS的改动导致了这个问题，所以让苗同学==恢复到第一次改动之前的状态==进行测试。很遗憾，测试结果是改动之后，上述两个设备就可以正常访问了。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;于是决定周一正常上班的时候再深入的讨论和解决DNS的问题。
### 第三次改动
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;愉快的周末假期就这么水灵灵的过去了，苗同学和他的朋友们也开始正式的，严肃的修理DNS，实际上DNS到校园网外只有两条线路（仅限周一）：移动专线和教育网专线，目前出现的现象是如果DNS强制走教育网专线出门到教育网解析，则内网会出现一些访问问题，比如某些网站打不开，微信的一些服务加载出现问题。如果不强制走教育网出口，可以根据[路由][8]出门，则内网的一些对外提供的解析服务则会出现问题，即内网的DNS无法作为[权威DNS][7]对外提供服务。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;然后着手从现在已经收集到的现象进行讨论，思考可能的解决方案，然后对方案进行实际的评估，最后进行测试和部署，清楚明了工作流程之后就可以顺着这个套路继续解决眼下的问题。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;周一的时候由于还有上周末的割接残留工作，所以周一的时候首先处理，真正开始处理DNS问题的时候实际上已经是周二了，==DNS此时还是强制走教育网专线，可以正常提供权威解析服务，修改后DNS不强制走教育网==，进行测试，其实按照预期，DNS应当是可以正常提供解析服务的，从外网测试其实还是可以打开学校内部对外提供的外网服务的，比如官网，堡垒机，SSL VPN。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;苗同学在翻找设备配置的时候发现DNS的NAT配置并未绑定出接口，说明DNS无论走哪个出口，都会NAT为教育网的公网地址（教育网站提供权威DNS只能使用教育网的公网地址），这样是不符合服务器的工作逻辑的，服务器要求来回路径一致，否则无法正常建立通信会话。所以苗同学==从路由器上添加了绑定出接口NAT，这样DNS只有在选择教育网出口的时候才会NAT为教育网的公网地址，其他出口则保持和内网普通上网用户相同。==
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;但是史老师在外网测试DNS的53端口是不通的，DNS是通过TCP和UDP的53端口提供DNS服务，外网测试53端口不通，但是内网是通的，服务肯定是未正常提供的，怀疑是外网存在DNS缓存，所以仍能在短期内提供解析服务，这个缓存一般存在一小时左右，也就是说一小时后外网就无法解析学校内网的服务了。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;对DNS进行[traceroute][9]端口测试，外网正常，到学校路由器出口的时候发现回包地址为移动或者联通地址，并非教育网地址，此时时间也已经不早了，并未对该现象做出反应，也并未修改DNS强制引流至教育网。
### 第四次改动
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;下班回到家的苗同学翻找了一些锐捷网络的一些故障案例，发现也没有及其相似的。然后找了外地的朋友进行测试，也如预想的一样，官网在外地其实已经打不开了，所以苗同学又==将DNS恢复了强制引流策略，让DNS强制走教育网，保证校内对外提供的服务正常。==
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;==其实到了这一步又回到了第一次改动前的状态，实际上唯一的有效操作就是NAT绑定了出接口，也不完全算没有任何进展。==
### 第五次改动
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;其实到周三的时候已经没有特别好的思路继续解决问题了，已经开始怀疑路由器是否出现了BUG，之前其实也偶发这种情况，但目前我们从设备正常的状态无法解释目前已经出现的各种现象。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;于是麻烦锐捷彭老师联系锐捷的二线技术支持查找设备底层的一些问题，查看设备的接口流是否正常，我们也尝试在防火墙和DNS上[抓包][10]查看交互是否正常，但其实都一无所获，锐捷二线排查了一天最后给到的答复是一切正常，设备并未出现BUG。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;时间转眼已经到了周四，上午的时候又换了一个其他的二线支持进行了一上午设备的底层排查，得到的最后结果仍旧是设备没有问题，所以我们之后进行了一些奇怪现象的交流，当聊到不强制引流的时候，DNS无法正常对外网提供解析服务的时候，苗同学询问二线技术支持为什么回包的时候会出现回包地址不符合预期情况的现象，二线的一句话点出了一个问题的根源：如果路由器的接口上配置了[源进源出][11]的话，就应该是这样的。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;苗同学好像想到了什么，随即去路由器上查找接口下的源进源出配置，结果是教育网专线的接口并未配置源进源出。发现了这点的苗同学终于如释重负，一切问题的根源似乎就在这个点上，==配置上源进源出和排除强制引流后，测试一切服务均正常。==
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;但是下午测试京东的网站仍旧是打不开，发现无法解析京东官网的地址，但此时其他业务都是正常的，但此时我们已经完全没有了任何头绪，只是对解析现象一遍一遍的进行测试，这个问题还是上午不正常的时候其他老师报的，我们甚至怀疑我们是否漏了什么策略导致这个现象，但这并不能解释为什么腾讯的业务是正常的。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;于是在测试了一段时间后，我们发现京东的CDN地址是电信的，而此时我们电信的公网其实是不通的，因为前两天电信更换了学校的互联公网地址，而我们没有收到消息更改，其实这本来也不是什么大问题，访问电信的地址理应从其他出口也是可以到达的，但当远端CDN之间的互联出现拥塞或者连通性故障的时候，就会出现无法访问解析到的CDN资源，从而导致无法打开网站。
## 最终定论
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;目前即使是一些国内的大厂，即使像腾讯，京东这样，它们的CDN优化其实也没有做到特别好的程度，所以我们以前从教育网拿到的CDN地址是不能通过三大运营商网络正常访问的，所以我们需要让DNS去三大运营商的网络去递归查询，解析到的地址才能从三大运营商出口正常访问。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;最重要的一点其实还是源进源出的配置问题，在排查问题的时候所有人都理所应当的认为这个配置是存在的，实际上是没有配置的，仔细检查和思考也是相当重要的一点，否则就会出现这样的疏漏，一条看起来并不怎么起眼的配置漏掉，就导致了那么多的资源浪费。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;目前我们也并不能完全认为外网一切就是正常的，实际上京东在周四(2024.11.28)晚出现的问题就是个很好的例子，实际上就是京东的CDN网络出现了问题，与我们内网出现的问题叠加在了一起，导致无法准确判断原因。
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;其实DNS的问题并未完全解决，仍旧留下了一个坑，但这是目前业界都没有好办法去解决的问题，思考一下，这次问题留下了什么坑，这个坑埋着什么样的雷，会导致什么问题？

[1]: https://blog.csdn.net/qq_38891369/article/details/106444280 "网络割接"
[2]: https://baike.baidu.com/item/%E5%9F%9F%E5%90%8D%E7%B3%BB%E7%BB%9F/2251573 "DNS"
[3]: https://baike.baidu.com/item/%E5%86%85%E5%AE%B9%E5%88%86%E5%8F%91%E7%BD%91%E7%BB%9C/4034265 "CDN"
[4]: https://baike.baidu.com/item/%E7%AD%96%E7%95%A5%E8%B7%AF%E7%94%B1 "策略路由"
[5]: https://baike.baidu.com/item/%E5%A0%A1%E5%9E%92%E6%9C%BA "堡垒机"
[6]: https://baike.baidu.com/item/SSL%20VPN/198325?fromtitle=SSLVPN&fromid=9212058 "SSL VPN"
[7]: https://www.digicert.com/cn/faq/dns/recursive-and-authoritative-dns-differences "权威DNS"
[8]: https://baike.baidu.com/item/%E8%B7%AF%E7%94%B1/363497 "路由"
[9]: https://blog.csdn.net/qq_40507857/article/details/120448132 "traceroute"
[10]: https://baike.baidu.com/item/%E6%8A%93%E5%8C%85/9929103 "抓包"
[11]: https://www.cnblogs.com/xxllx/p/16666680.html "源进源出"
[0]: https://baike.baidu.com/item/%E7%BD%91%E7%BB%9C%E4%B8%93%E7%BA%BF/3251519 "专线"