背景环境
由于企业防火墙的缘故，所有通过wifi连接的设备是只能访问特定的物理机的。而手机又不能插网线。所以我手机上网就必须通过指定的物理机转发所有的流量。
这个特定的物理机显然不是路由器。因此手机的DNS解析其实也是要走这个物理机去转发。
当然如果是HTTP请求的话，其实本身就该物理机去解析。
对于DNS，我是有两个DNS server。一个内网的DNS server，一个是外网的DNS server。外网的DNS server负责对接114或者阿里DNS，内网的DNS从我外网的DNS上拿结果，并缓存。
也就是说，外网DNS server负责和第三方DNS集成，内网DNS负责缓存加速。
外网的DNS server部署在云服务器，内网的DNS server部署在路由器和k8s集群。
现象描述
打开某乎某宝手机APP，然后随便刷刷。不超过3分钟，整个内网瘫痪，无法继续访问外网。
（这里说明一下：物理机位于成都。无法访问外网指的是位于成都的物理机无法访问百度）
而相反，使用某信，某博或某东等其他APP就不会有这个问题，刷多久都没事。
原因分析
一开始，我以为是某乎有什么奇怪的网络探测。当发现是流量被转发时就主动出击，干掉对方的IP。（至于怎么干掉，谁动手干掉，为什么干掉，我只能说懂得都懂）
但最近某宝也开始闹这个毛病了，我觉得就有些解释不通了。于是开始仔细的查日志。
首先，我观察到，每次断网，都会伴随着大量的DNS查询超时，超时发生在内网DNS和外网DNS之间。
这也是为什么我一开始会解读成IP被干掉了。因为理论上外网DNS的可靠性是非常高的，毕竟部署在云上。那么我只能解读为网络不通，导致内网DNS连不上外网DNS才导致超时。
然后，每次断网前，外网的DNS服务器会收到海量关于根域名的NS查询。也就是nslookup -type=ns .的查询。
日志里也出现大量NS IN .相关的查询，其中NS表示查询的类型是查nameserver，IN不重要，我记得是表示input，.表示查询的域名就是一个点。
以www.baidu.com为例，查询的时候其实查的是www.baidu.com.。（注意最后的点）
又看了内网DNS server的日志之后才发现，内网的DNS server在被这个查询疯狂刷屏。而且，这些查询其实都是非法查询。
于是整个崩溃流程就是：
用户打开某乎APP -> 某乎APP开始疯狂的查NS . -> 查询被转发到内网DNS -> 内网DNS发现cache里没有，于是转发外网DNS -> 外网DNS发现请求非法，报错 -> 内网DNS得知出错，选择不缓存（只有拒绝会缓存） -> 海量的查询全部都转发外网DNS -> 外网DNS来不及处理其他查询 -> 内网DNS缓存开始过期，最终导致内网无法访问外网（因为域名无法解析），内网DNS开始报超时
其中某乎的这种查询的数量远高于其他，所以某乎是最早也是最稳定出现这个问题的APP。
解决方案
对于这些APP，我表示：你别管我从哪里查到的DNS结果，给你IP你就拿着好好用。不该问的别问。
但是CoreDNS对于.的语义多少有点歧义，加上CoreDNS的ACL比较的基础，我这里的处理就是直接在内网DNS server把.污染成localhost。
内网DNS一方面是网络非常快，二方面是计算资源非常充足。所以爱怎么查就怎么查。
目的分析
问题来了，为什么有些app有这个毛病，有些app没有这个毛病呢？
这里我联想到了我最初调查的时候的一个发现：某乎会通过DOH查询DNS。
所以往好了想，是这些APP有特殊处理，为避免用户的DNS被污染尽可能验证清楚DNS查询的结果。
但往坏了想呢？
首先，就算要确认安全，那为什么要发送如此海量的DNS查询呢？
其次就算解析到了什么奇怪的IP，难道2023年了都还没实现对外全HTTPS？
就算失败重试，但这个量也太大了。
于是我就有了一个阴暗的想法。
他觉得我的DNS server可能是恶贯满盈，人人得而诛之，于是爆一波流量。如果这个DNS server是公共的，如果大家都用这些APP，那么这个DNS server就会被无数人在无意识的状态下DDOS的体无完肤。
这种操作，我愿称之为“大炮”。
至于哪些DNS server恶贯满盈？哪些DNS server德高望重？谁来评价？“大炮”要不要开火？什么时候开火？谁下令开火？
我觉得懂得都懂，答案自然是：只是这些app的一个技术失误，用了某个公共的依赖，只是这个依赖有一个bug而已。
所以，没有阴谋，就是这些厂技术菜。