1 DNS高防需求
很多年前的需求，仅供参考
DNS作为网络服务的入口，面临攻击的风险越来越大，传统的DNS服务基本不具备DDOS之类的防御能力，同时互联网上持续发生的DDOS攻击事件在不断的刷新着最大流量攻击纪录。所以提供可靠有效的DNS高防服务，其市场前景非常好。
整体上，DNS高防必需满足几个硬需求：
- 对于同一个用户提供联通、电信两条线路的高防节点；
- 支持大流量攻击下的防御，目标防御50G+
- 实现较低误拦截率，减少正常请求被拦截的比例，目标1%；
- 实现较低的透过率，减少回源站请求的比例，避免源站被打跨，支持设定源站QPS阈值；
- 支持缓存响应，减少回源服务器的QPS；
- 支持对域名服务商提供域名防护，这类用户拥有几万甚至几十万的主域名，源服务器众多，需要提供独立的高防IP；
- 支持对大企业的权威DNS防护，可选独立IP或共享IP模式。
2 当前的DNS防御基础
现有环境下，自建的DNS权威服务器集群具备一定的DDOS防御能力，基本上10G是个瓶颈。同时针对希望被保护的而且暂不具备为其他的DNS权威直接提供服务，除非用户采用NS切入的方式
2.1 安全宝DNS防御
建设有多组NS服务器，同时在抗D机房有一组NS，当其它的优质线路上的NS因被攻击无法提供服务时，抗D机房内的NS自动提供服务，总体情况下通过该机房的防御主要是为进一步防御提供处理时间。
目前的防御手段是暂停对被攻击域名的解析，或协助114dns进行防御。
2.2 云加速2.0 DNS防御
2.0的DNS服务器放置在系统部管理的一个机房内，该机房支持10G带宽，主要的防御手段是统计ip和dns query的频率，超过一定的阈值后，启用ipfilter来拦截该IP的请求，该组服务的性能处理能力在200wqps。
存在的问题也是明显的，即带宽有限，仅10Gbps；同时清洗方案漏过率高，直接影响DNS服务的处理性能。
2.3 云加速3.0 DNS防御方案
云加速3.0系统采用CF解决方案，CF提供近千个NS，可以把域名分散到不同的NS服务器上，减小因攻击带来的影响范围。对于NS本身启用了缓存加清洗功能，也会针对ip来拦截，使用bfp进行高效拦截。
由于启用了国外的NS服务器，解析延迟增大了，同时还存在很大的风险，即当攻击的目标是国外IP时，电信等运营商会从跨国境的流量中封堵存在超大流量的IP，这种情况会严重影响对其它域名的解析。
3 114DNS高防方案
114DNS具备现成的DNS缓存+清洗的方案，通过ECMP集群的方式来扩展防御性能，能够比较快的搭建起防御平台。
3.1 方案概述
本方案要求在电信和联通两个机房分别部署防御集群，在每个集群上为用户提供独立的IP用于NS解析。
在114DNS防御技术支撑下，部署模式如下图：
用户提供其ns列表和相应的服务器IP，由防御集群清洗后，转交到DNS代理分发上，DNS代理会根据请求域名和ns的映射关系找到真实的服务器IP去请求解析数据。
114DNS防御集群如下部署：
由防御集群清洗后，需要回源请求的数据交给DNS代理分发集群，这个集群两台即可，主要用于冗余负载，到这里的请求基本上要转发到源站的，所以要求防御集群的透过率要较低。
3.2 方案实施
本方案依托114DNS的防御系统进行部署，外加DNS代理分发程序的开发和部署，同时需要114DNS提供攻击数据输出，协助收集攻击报表数据。
3.2.1 防御集群部署
目前据114DNS提供的数据，其单机的处理能力大概在200万QPS，按每请求包80字节、响应包140字节计算，单机处理带宽在上行1.2G下行2G的数量级，需要114DNS提供清洗比例的数据指标，以便于计算下行带宽的使用情况。
预估50G的DNS流量防御，需要ECMP64的集群，即需要部署64台设备建立集群，这样的集群处理的效果应该达到上行70G和下行130G的防御能力。
所需设备：
- 万兆48口交换机2台，带ECMP功能
- 64台服务器，2台同类型备用
- 电信、联通机房各一套
上述系统由114DNS协助安装。
114DNS提供技术支持相关未尽事宜：
1） 拦截率指标，即200万的接收QPS，最多只响应多少QPS？
2） 透过率指标，即防御系统上没有缓存的请求，最多发出多少比例或是阈值的QPS到源NS（DNS代理）？
3.2.2 代理集群部署
所需设备:
- 与防御服务器同类型3台（2台为一个集群，1台备用，交换机可以共用）
- 电信、联通机房各一套
3.2.3 DNS代理分发程序开发
1. 后台处理程序
支持用户在界面上配置NS名称与源站IP的对应关系，实时更新到redis中心，通过redis的同步功能实时同步到代理分发各server上；
2. 代理分发程序
- 接收防御集群过来的请求，获取请求域名的ns名称，并做缓存，定时从redis中获取该ns名称对应的IP，把请求转发到该IP上
- 源站回应没有查到的结果不要返回给防御集群
- 支持缓存功能，启用缓存延迟失效模式，即被缓存的结果在缓存失效时没有获取有效响应时不失效
3.2.4 报表数据收集
114DNS支持按各IP每秒输出数据，统计秒周期内的相关数据：
1） 上行包数和字节
2） 下行包数和字节
3） 请求次数
4） 响应次数
DNS代理程序支持按用户每秒统计回源情况：
1） 请求次数
2） 响应次数
3） 响应结果中为未找到的次数
4） 发送流量
5） 接收流量
3.3 稳定性设计
**通过稳定性分析，发现还存在两个方面的未知信息：
- DNS防御系统的稳定性建设方案
- 如前我们设计了联通、电信两个DNS高防接入的方案，以此实现分区解析，如果某个机房因攻击超大而停止服务的情况下，会影响所有服务的分区解析问题，这类稳定性是否需要考虑？**
4 自建DNS高防方案
高防建设的总体框架方案是分层防御，构建的防御集群支持在网络层防御掉协议栈上的非正常流量，具体到应用层上的攻击则需要具体的应用清洗模块来进一步清洗，所以DNS的高防方案也可以融入到自建的高防方案中来，这种情况下，在同一个机房内防御时可以充分利用同一个集群的硬件资源，节约防御成本。
集群的构建模式相同，都是在ECMP模式下堆叠机器来扩展处理性能，这种情况下就是需要不断的完善我们的server防御能力，在这里只是简单阐述。
Server的清洗模块组成图如下：
网络层清洗
- 维护自动白名单，通过观察正常连接，确定真实存在的IP，并维护好该IP的指纹（TTL特征）
- 定位非国内IP进行丢弃
- 丢弃与白名单IP特征严重不匹配的数据包
- 非DNS的流量还可以通过确定首包丢弃和一定间隔内只允许通过单包的机制进行丢包
- 非DNS的流量还可以限制上行到协议栈的个数
- Syn代理等
DNS清洗 - 建立分区（电信、联通）缓存
- 追踪IP同时查询的域名个数，查询较多的为常规IP多一些
- 追踪常规IP及其查询主域的hash分组，统计查询频率，对于非正常频率下的请求丢弃没有缓存结果的查询
- 对于非常规IP限制速率
- 提高单台设备的清洗及吞吐能力，清洗比例达50%
HTTP清洗
完成代理连接，具体做CC方面的清洗
其它TCP清洗
完成代理连接，视具体的应用做进一步的开发
