说起来都是老故事了——二十年前，互联网刚刚起步时，整个行业曾面临一个巨大的难题：邮件服务器实在太过“开放”了。
简单来说，当时绝大多数邮件服务器几乎来者不拒：任何人都能连上去，随意给任何人发送邮件。你甚至不需要是它的注册用户，稍微伪装一下就能蒙混过关。
攻击者只需通过SMTP的接收端口（TCP 25）建立连接，模仿那些内部命令——使用telnet、脚本或其他工具——就能发号施令。结果就是，他们可以伪造邮件，假装成服务器上的合法用户，将任意内容发送给任何人。
垃圾邮件发送者正是盯上了这些“开放转发”服务器，把数以亿计的垃圾邮件撒向全球。于是，全球的技术团队和邮件服务器厂商花费了近二十年时间，才逐步强制要求所有外发邮件都必须验证真实来源、必须由经过认证的用户发送。
然而，多年以后，类似的开放转发问题又在另一项互联网基石上重演——DNS。攻击者利用配置错误的DNS服务器，要么向查询客户端返回虚假IP地址，要么用海量虚假流量发动DDoS攻击。
利用DNS实施DDoS攻击
攻击者利用DNS发起DDoS攻击早已不是什么新鲜事，但近年来愈演愈烈。近些年，大部分大规模DDoS事件都采用了DNS反射放大技术。想了解具体细节的话，不少安全机构都有相关文档可供查阅。
最终，DNS服务器厂商和协议开发者不得不跟进——这与当年SMTP邮件供应商保护自身安全的路径如出一辙。例如，采用更合理的默认配置、引入新的防御机制。但遗憾的是，许多DNS服务器看似运转正常，实际上却被忽视，隐藏着一堆攻击者乐于见到的安全漏洞。
禁用开放转发DNS服务器
每家企业的运维团队都能轻松实现的一个保护措施：限制自己的DNS服务器只对特定来源的请求做出响应。内部DNS服务器只回应内部机器或其他认证DNS服务器的查询。
即使是对外提供服务的DNS服务器，也不能无脑回应所有请求。如果你的DNS服务器只托管*.example.com，那么合法用户绝不会跑来查询其他域名。如果它对任何来源、任何域名的查询都来者不拒，那就是一台开放转发DNS服务器——这绝对是一场灾难，必须立即处理。
要确保你的DNS服务器不是开放转发，可以利用Open Resolver Project、Open DNS Resolver Check Site、DNS Expertise和DNS Inspect等在线检测工具进行验证。
DNS响应速率限制
防止自己的DNS服务器被用于DDoS攻击，最好的方法之一就是启用响应速率限制（RRL）。RRL主要针对权威DNS服务器，能让管理员有效限制响应流量。它默认没有开启（但绝对应该开启！），在BIND 9.9及后续版本中就已经内置，微软的Windows Server 2016 DNS服务也包含此功能。
如果DNS服务器不支持RRL，也可以通过防火墙速率过滤或其他反DDoS服务来实现类似效果。
禁用向上转介响应
大多数非递归权威DNS服务器在收到未经认证的查询时，会礼貌地让客户端去顶级域DNS服务器试试——就像在说“我不知道答案，但你可以去那边问问”。这种向上转介（使用root hints）在DNS放大攻击中成了帮凶。BIND一直建议禁用这个行为。微软在Windows Server 2016中默认禁用了向上转介，早期版本可以通过删除 c:\windows\system32\DNS\cache.dns 文件来禁用。
检查所有DNS服务
扫描网络设备的TCP/UDP 53端口，找出所有运行DNS服务的设备，并检查其安全配置。通常会发现一些计划外的DNS服务器，比如无线路由器上无意间开启的DNS服务。
开门揖盗最为愚蠢
DNS协议自1983年诞生以来一直表现良好，虽然也经历过滥用和修补，但至今仍是互联网核心基础设施。不过，绝不能对现有的安全水平自满，尤其是在DNS方面。
最后提醒一句：千万别让自己的DNS服务器重蹈当年邮件服务器的覆辙。现代IT行业不可能再花十年去修补那些早就该堵上的漏洞。
