那一夜，DNSPod的大神经历了什么

当问起凤梨叔

两年前全网热议的

DNSPod解析遭到攻击的那天。

关于当晚的每一个的细节，他依旧了然于心。

将时间线拉回到2018年11月9号当晚

当收到告警时，

出现在凤梨叔的脑海里的第一个念头是：

坏了，被攻击了！

凤梨叔第一件做的不是去排查问题

而是先手动重启B地的部分DNS服务器

多年的从业经验告诉他

外部攻击很多时候是分地域的

不同地区受影响可能不同

A地的服务器启动异常不表示其他地区会马上异常

这个决定

能在保证服务持续提供的同时

也留出找到原因的时间

同时

凤梨叔立即联系腾讯安平团队排查

怀疑是有异常包攻击导致。

23:07左右 

B地的机器的服务重启后

外网确实如凤梨叔判断的一样，可以对外提供服务

但此时异常包并没有排除。

凤梨叔决定：

一边逐步使用万能的重启大法保持服务的稳定提供

为排除故障服务器争取时间；

一边联系其他同事继续准备扩容

意外的是

凤梨叔发现DKDNS解析程序运行仍旧是正常的

那么问题出在哪里呢？

就在这时，B地的服务器也沦陷

它并没有为凤梨叔争取太多排查的时间

必须尽快找出原因，保证服务的稳定性。

”这是一场和时间的赛跑“

一番思索，他心中已有眉目

可能是畸形请求包导致队列阻塞

凤梨叔立刻联系安平团队

决定设置ACL策略，仅保留53端口对外开放

此外经过排查，发现由于其他DKDNS（万兆外网）不通，

所有现网流量

压到了一台低配单节点千兆服务器上

这台服务器承载的流量

大大超出了该服务器的解析能力

导致解析失败率非常高

终于，B地服务器恢复服务能力

安平也在短短几分钟内完成了ACL的设置

总算短暂的把风险控制住了

凤梨叔仍然没有掉以轻心

经过对从故障服务器的内存中导出的

网卡发包队列中的数据包进行分析

终于确认了凤梨叔一开始的推断

正是异常TCP大包

导致网卡发包队列阻塞，外网中断

最终，

第一次触发告警时部署的

新扩容服务器经测试正常

也加入到线上服务

风险正式消除。

到这时，他才真正的松了一口气。

有人问阿 D

你家的解析为啥这么稳定？

稳定的解析背后是

共计5 TB 的总带宽

60个境内外云集群节点

数十亿QPS的线上总容量

14年来，我们除了技术的不断进步和更新

还有像凤梨叔这样的人

用他的行业经验，专业度和使命感

多年如一日的守护着你在DNSPod

每一次“稳定”的解析体验。

回到一开始的问题

阿D，为什么你家的解析那么稳定？

把话筒递给凤梨叔

他只会摸摸脑袋笑一笑说:

我只是做好我应该做的事情罢了。

                                                           添加阿D微信

                                          加入DNSPod官方交流群

                               内有罩哥大大，凤梨叔。