@eary 如果你觉得有必要的话，确实可以……

@eary 接入点 4x4 了客户端呢？客户端 3x3 瓶颈就还是 1300 Mbps 的 PHY 速率。

11ac Wave 2 都够呛，何况你客户端网卡是瓶颈，现在内置网卡 3x3 顶天了吧？

要我说，没必要，拖个外置无线网卡带着大天线，还不如直接接电口以太网呢。

而且，楼主的 NAT 设备大包性能能到 1 Gbps 吗？如果不能的话先解决 NAT 吧。

这个……我还是持怀疑态度，个人建议题主再排查下其他环节，或者只是 CDN 那边出问题了。

是不是装了测试版系统？

@coek 400G 白金估计一个月几百万吧。

Nissan 恐成最大赢家。

楼主这是「真 · MI-MO 」……

@Cipool 不是，这回是无脑污染，包括具有 ICP 备案的境内网站。

@kernel 你的意思应该是 DoS，但问题有三：你在明处、你只有一个 IP （即使是动态的）、法律合规。

@zclHIT 你本地的 DNS 客户端只要没有经过特殊配制，在查询时永远是递归的，也就是说 114.114.114.114 要么返回最终解析结果，要么返回错误 /超时，所以如果这个 IP 不返回解析记录，客户端在这个 IP 就查询不到结果。至于返回的是不是权威解析记录，客户端并不关心也不需要关心。

对于 114DNS，它本身是由多个前后端节点构成的 DNS 系统，并通过 BGP Global AnyCast 技术对外广播统一 IPv4 地址。这个系统内部对客户端是透明的，也就是说客户端没必要也没能力关心 114DNS 内部的查询过程。客户端向具体哪一个 114DNS 前端节点进行递归查询是由路由技术决定的、向最优节点查询是由路由技术实现并保证的。至于收到请求的前端节点没有记录怎么办，这是 114DNS 系统内部的事情。

而 114DNS 返回的结果和本地 DNS 的不一样，是因为其内部在向权威 DNS 查询时使用了在权威 DNS 看来和本地 DNS 来自不同逻辑片区的前端节点。至于为什么会来自不同的逻辑片区，这既涉及到路由问题又涉及到逻辑片区的划分逻辑问题——比如 114DNS 在你本地运营商没有前端节点或者路由表将你错误地路由到了不在你本地运营商的前端节点。

😳楼主这指向的不是权威 DNS 吧，解析结果不同应该只是单纯的智能解析，因为从不同的节点递归到了权威 DNS。

P.S. 内网 DNS 缓存自 114.114.114.114, 114.114.115.115

; <<>> DiG 9.10.6 <<>> www.qq.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39302
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.qq.com. IN A

;; ANSWER SECTION:
www.qq.com. 81 IN CNAME https.qq.com.
https.qq.com. 47 IN A 183.3.226.35

;; Query time: 3 msec
;; SERVER: 10.0.1.1#53(10.0.1.1)
;; WHEN: Sat Aug 18 21:28:19 CST 2018
;; MSG SIZE rcvd: 81

高通的但不是特别新的还行吧。

@bclerdx 是的。虽然从技术上不能直接证明，但常识和经验告诉我：不可能这么快。

青云 - qingcloud.com
面向未来的企业级云计算服务商

@bclerdx OpenDNS 最近的 BGP Global AnyCast 节点在日本，但 dig 返回结果只花了 30+ ms。

大约从周一（ 20180813 ）开始，内蒙古电信 OpenDNS 一主一备均遭遇抢答，抢答目标包括拥有 ICP 备案的境内大网站，抢答结果包括脸书在全球的服务器和 CDN 地址（主要为美、韩、新加坡、台湾）以及 127.0.0.1。

这一问题直接污染了我家的内网 DNS 缓存，搞得盒子连 GITV 的服务器都连不上了……