利用AX产品提升DNS服务器可用性和安全性的一种有效解决方案

最近用AX 64位ADC产品做了一个DNS服务器的解决方案,共享给大家参考。DNS服务器是做什么用的这里就不啰嗦了,大家应该还记得2009年国内出现了一次大规模的DNS服务器中断服务的状况吧,那次故障让很多网管人员和决策者意识到了DNS服务在整个Internet接入服务过程中的重要性,也充分体会到了UDP Flooding攻击,尤其是DNS flooding攻击的危害性!本人最近利用AX产品所提供的DNS Cache、PBSLB(Policy based Server Load Banlance)功能,结合IP anycast做了一个提高DNS可用性和安全性的解决方案,简单描述我的方案思路:

1、 利用AX产品基于DNS应用层的健康监测机制,对DNS服务器提供最准确的应用可用性探测;

2、 利用AX产品对DNS服务器群提供高效的负载分担算法,保障每台服务器的访问压力比较均衡,任何一台服务器出现故障都不会影响整个DNS系统的可用性;

3、 利用AX产品极高的QPS处理能力,无论在访问高峰期还是在发生异常DNS攻击时,都能够最大限度的保障DNS应答的时效性和抵御攻击的能力;

4、 利用AX产品提供的DNS Cache功能,通过在AX系统内存中缓存DNS服务器的应答数据,可以极大的降低DNS服务器的访问压力;同时,还可按照灵活的策略缓存或不缓存指定域名,提供不同的缓存策略;

5、 利用AX产品提供的DNS应用策略,实现非法DNS请求的过滤、速率限制、连接数限制等安全策略,例如可基于源IP地址、基于DNS域名等实现连接数和连接速率限制等;

根据以上五点思路,简单阐述一下我为什么选择这五个功能,和其它IP anycast方案相比有什么优势:

1、要充分利用ADC产品提供的应用层健康检查机制,不仅定期检查网络层可达性,还能通过探测DNS服务器是否应答DNS请求来判断DNS应用的可用性,当出现问题时,AX产品会主动在OSPF域中停止广播有问题的DNS IP路由,彻底避免当DNS进程出现问题或者应用挂死时,仍然向有问题的DNS服务器发送DNS请求。通常在服务器或网络层设备上启用IP anycast是无法做到应用层的健康监测的,只要网络层可达,IP anycast的OSPF路由就有效,这样就会出现当DNS进程或应用层出现问题时,依然会有DNS请求被分配到这些有问题的服务器上,造成客户端的DNS请求服务无法应答。

2、ADC产品本身具有多种不同的负载分担算法,利用这些算法可以有效的在服务器群中实现负载的均衡分担;网络层设备只能基于源IP地址hash的方式来给DNS服务器分配流量,算法过于单一,且容易出现负载不均衡的情况。

3、通常无论是DNS缓存服务器,还是授权DNS服务器,都无法提供高性能的QPS处理能力,根据经验,一般一台DNS服务器只能提供20万~30万左右的QPS处理能力,这样就会造成出现大量DNS请求或者攻击时,这些服务器会成为性能瓶颈,影响整个DNS服务系统的性能,且容易在服务器间出现故障的雪崩效应;而AX产品可以提供至少百万级的QPS处理能力,这一点相对于服务器来说,性能优势比较明显。

4、在AX产品上启用DNS Cache,除了有效降低DNS服务器的访问压力,减少DNS服务器的递归查询外,由于AX产品自身具备高性能的QPS处理能力,因此,能够更大限度的保障DSN系统的整体处理能力,提升系统的安全性,解决方案更加简单,集成度更高。

5、启用DNS应用安全策略,可以有效的防范非法DNS查询请求,对于大量伪装成合法DNS递归查询的攻击,除了采用DNS Cache+高性能QPS应答外,还可以根据攻击源IP地址或者攻击的域名进行速率限制,或启用黑白名单等,充分保障其它合法用户的DNS服务请求。

 

以上就是我做的这个方案的整体思路,以及方案的优势所在。具体设备配置结合这个思路去实现即可,有机会我再结合具体的部署方案把配置发布到Blog上。

 

S.G



本文转自 virtualadc 51CTO博客,原文链接:http://blog.51cto.com/virtualadc/655729

上一篇:java中this关键字的使用


下一篇:解决gdb报错:Failed to import the site module,No module named '_sysconfigdata_m'