DNS系统（精选9篇）
DNS系统 篇1
DNS(Domain Name System,域名系统)[1],作为将域名和IP地址相互映射的一个分布式数据库,能够使用户更方便的访问互联网,而不用去记住能够被机器直接读取的IP数串。通过域名,最终得到该域名对应的IP地址的过程叫做域名解析。DNS中常见的资源记录类型有主机记录(A记录或AAAA记录)、别名记录(CNAME记录)等。DNS会根据记录设置的TTL缓存记录。最常见的异常是因为在整个解析的环节中错误地响应了NXDOMAIN(正常响应,但为空,表示不存在该域名),而现有的技术无法判断此种响应的正确性。
本文设计并实现了DNS解析异常处理系统,基于现有的DNS系统改进,使用静态配置文件和动态分析历史解析即结果,支持主机记录、别名记录等,具有较强的异常处理能力。经过测试,Ehdns借助少量的硬件资源来获得高可用性和高可靠性。
1 相关工作
最近几年,因为DNS的问题,包括授权DNS和根DNS,导致出现了多次大范围的网民无法正常上网的现象[2]。
域名出现没法解析有多种可能,其中可能是DNS问题的情况包括本地DNS本身故障、授权DNS故障、根DNS故障[3]。
IDNA是使用基于Punycode码,可以将Unicode字符串映射为有效的DNS字符集。因此,诸如“x.中国”这样的域名可以在地址栏直接输入并可正常解析。
OpenDNS是2006年7月由David Ulevitch创建,为个人和商业提供DNS方案,加快域名解析速度,并拥有反钓鱼过滤器和输入纠正等功能[4]。
EDNS是在RFC2671中提出的一种展DNS机制,其在已有DNS消息格式的基础上增加一些字段,来支持更多的DNS请求业务。
DNSPod创建于2006年3月,可根据请求来源,将多种运营商的线路细致划分至省(国内)/ 大洲(国外),智能化返回最佳解析结果,也被称为智能动态DNS[5]。
尽管DNS周边相关产品较为繁多,但是关于DNS的异常处理的很少,现有的处理手段只是将所有的异常请求响应到一个固定的导航或错误提示ip[6],并没有起到异常处理的效果,故增加一定的异常处理显得越发必要。
2 原理概述
2.1 递归和迭代
目前绝大多数网民上网的场景是,网民会自动获取并使用接入运营商的本地DNS进行解析,解析过程分为递归和迭代两种。
网民客户端向本地DNS服务器查询,属于递归查询;如果主机所询问的本地域名服务器不知道被查询域名的IP地址,那么本地域名服务器就以DNS客户的身份,向其他根域名服务器继续发出查询请求报文;
DNS服务器之间就是的交互查询就是迭代查询,如图1所示,当根域名服务器收到本地域名服务器的迭代查询请求报文时,要么给出所要查询的IP地址,要么告诉本地域名服务器:“你下一步应当向哪一个域名服务器进行查询”。然后让本地域名服务器进行后续的查询。
2.2 缓存
每个DNS都会有缓存,缓存的时长(即TTL)由域名授权服务器设置的,发起请求方会将域名解析结果缓存TTL时长,从而减少不必要的频繁访问,也减少了服务器的压力。如图2所示,在任何解析前都会先检查缓存,如有便直接返回。
2.3 解析异常
域名出现没法解析有多种可能,其中可能是DNS问题的情况包括本地DNS本身故障、授权DNS故障、根DNS故障;故障又可能源自硬件、网络、压力等异常。如图3所示,这些异常最终会产生NXDOMAIN的响应。
于是,DNS得到错误的响应、并响应给网民和缓存很长时间,便造成了大范围的长时间的错误影响[7]。
3 系统结构
本节描述了Ehdns的系统结构及其中附加缓存和备选记录的工作原理[8]。
3.1 结构概述
如图4所示,在原DNS的基础上外围添加了域名备选记录和附加缓存模块,其在异常处理过程中会被使用。
3.2 域名备选记录
在DNS的配置文件中指定域及其相应静态记录文件的路径[9],例如下:
定义静态记录文件的内容,类似bind的zone文件[10]:
3.3 附加缓存
附加缓存中的数据结构如图5所示:
按如下方式存储,类似于JSON,用于定时在硬盘上持久化数据。
{"www.ctyun.cn": [{"record": {"type":"C","data": ["ctyun.cn.ctycdn.com"],"times":"99"}}, {"record": {"type":"A","data": [ "118.85.194.43","118.85.194.44"],"times":"31"}} ,{"record":{"type":"A","data":["118.192.68.122"],"times":"11"}}]}
其中type类型可完美支持原DNS的类型,A表示ipv4主机记录,AAAA表示ipv6主机记录,C表示CNAME别名记录。
4 关键技术
4.1 异常处理步骤
如图6所示,在本地DNS服务器上为域名添加相应的域名备选记录;当域名解析服务器无法正常获得记录时查询该配置文件,当有对应的Zone文件存在时,便给出响应。
为本地DNS服务器附加一套缓存机制,用于缓存历史解析结果及次数,默认缓存三条,当某一次解析请求在缓存中没有记录时,便会经过原始一般的递归解析:
当解析结果正常时,除了要将结果返回给用户并缓存外,还需要对结果进行附加缓存处理,从而可以动态分析;
当解析出现异常导致结果为空记录时,且备选解析文件中也没有相应的记录时,则从附加缓存中查找次数最多的记录,该记录被认为最可靠、最可能正确的记录。继而将此记录返回给客户,且将记录伴随60s的TTL写入内存,提高在异常期间的响应效率及保障在异常消失后的1分钟内能获取到真正正确的结果。
4.2 附加缓存处理
在附加缓存中,每个域名都对应一个记录结构,存放有历史解析结果,作为异常发生时的纠正参考。每个域名的记录结构实为一个有序链表,按照解析次数由高到低排序。为了高效的增删改查,本链表又设计为双向链表[11]。
当某一次解析请求在缓存中没有记录时,且解析结果正常时:除了要将结果返回给用户并正常缓存外,还需进行附加缓存处理[12],将结果和附加缓存中的历史信息进行比较:
(1)如已存在,则将对应记录次数加一;
(2)如不存在,则生成临时记录,次数为1;
(3)对记录和临时记录进行链表处理;
a.附加缓存中数据结构如图5所示,为有序的双向链表,可以高效地增删改查,节点数据结构为三元数据组{类型,值数组,次数};其中类型可以为A,AAAA,C分别对应域名的ipv4记录,ipv6记录及Cname记录;因为解析出来的ip记录可能为多个,所以值设计为普通数组;次数则是该记录为正常解析的次数。
b.链表为空时,如图7所示,临时记录会作为新节点,加入链表;
c.加入一个节点后如图8所示,当又有新节点后来时,如图9所示,会比较次数,再进行插入。
d.链表头部始终是历史正常解析次数最多的记录,该记录被认为最可靠、最可能正确的记录
e.在处理过程中,使用Head和Tail指针直接快速获取头部和尾部。
4.3 缓存刷新
因为在DNS运行过程中会需要变更域名备选记录,又因为缓存中有海量的有用缓存,那么就不能采用会丢失内存数据的冷重启,而是借鉴bind中Rndc的思想,使得配置文件可以热加载;并且可以加上域名名称作为参数,只需要热加载配置文件中某个域名,而不是所有域名,不仅不中断在线服务,并且最小影响服务和性能。
5 性能评测
5.1 实验准备
实验采用域名生成器来生成各顶级域下各类型的域名,且有一定比例的异常;相关参数见表1。另外还选取了不同配置服务器进行测试,以内存大小为参数。
5.2 性能测试
本节不但测试了EhDns在异常纠错的可用性,还测试了各种约束条件对Ehdns性能的影响,然后将其作为测试变量,与bind(版本9.2)进行对比测试。
域名重复的概率:
因为EhDns在域名解析前后的处理逻辑有所差异,故以此为变量测试。
如图10所示,EhDns的吞吐量要略小于Bind,这是因为EhDns的附加缓存链表处理需要消耗一些额外的运算,导致了吞吐量下降;但是随着域名重复概率的加大,差距在逐渐缩小,这是因为对于重复的域名,EhDns的额外处理需要的资源较少,并且对于实际DNS请求,绝大部分都会重复,甚至重复很多次。
内存大小:
因为DNS需要内存缓存数据,不同大小的内存会导致内存不够、以致影响效率,故以此为变量测试。
如图11所示:EhDns的吞吐量要略小于Bind,这是因为EhDns需要消耗一些额外的内存,导致了吞吐量下降;但是随着域名重复概率的加大,差距在逐渐缩小,这是因为对于重复的域名,EhDns占用的内存不会增加,在内存足够大的时候,几乎没有差距。并且在实际生活中,内存越来越大且越来越廉价,这使得占用额外的内存资源成为可能。
6 结论
本文设计并实现了一个域名系统解析异常处理系统 -Ehdns。本系统使用静态配置文件和动态结果分析,基于有序链表对记录进行存储和管理,再配有缓存刷新功能,使系统具有实时性、高吞吐量、可扩展性和鲁棒性等特点。
由于该系统可以很有效地处理在解析过程中发生的异常,并拥有在处理海量请求高效性能,它可被研究应用于本地DNS,授权DNS,智能DNS,根DNS等领域。
DNS系统 篇2
在linux下配置DNS服务器，下面是配置过程中设置过的一些文件，
/etc/hosts 文件的具体内容如下：
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost fc4
192.168.1.3 a.test.com a
192.168.1.1 b.test.cn b
/etc/host.conf 文件：
order hosts,bind
表示先用hosts文件做解析，在用DNS解析
/etc/resolv.conf 文件：
; generated by NetworkManager, do not edit!
search test.com
nameserver 127.0.0.1
search test.cn
nameserver 192.168.1.1
nameserver 61.144.56.100
/etc/named.conf 文件：
//
// named.conf for Red Hat caching-nameserver
//
options {
directory “/var/named”;
dump-file “/var/named/data/cache_dump.db”;
statistics-file “/var/named/data/named_stats.txt”;
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};
//
// a caching only nameserver config
//
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
zone “.” IN {
type hint;
file “named.ca”;
};
zone “test.com”IN {
type master;
file “test.com”;
allow-update { none; };
};
zone “1.168.192.in-addr.arpa”IN {
type master;
file “192.168.1.rev”;
allow-update { none; };
};
zone “test.cn”IN {
type master;
file “test.cn”;
allow-update { none; };
};
zone “0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0
DNS系统 篇3
关键词：DNS,正向解析,Linux,反向解析
1 DNS的概述
DNS是Internet和Intranet中重要的网络服务,它是一种组织成域层次结构的计算机和网络服务的命名系统。在TCP/IP网络中,主机与主机之间进行通信时,类似于“192.168.1.112”这样的IP地址的十进制表示方法虽然简单,但是这种单纯数字表示的地址非常难于记忆。为了更容易记住某个主机,我们希望用一个有意义的名字来命名主机,如将“192.168.1.112”的ftp主机命名为ftp.gaoyuan.com,这种名称容易记忆和理解。在使用ftp名称访问该主机时,需要通过某个机制将主机名转换为IP地址。这种将名称转换为IP地址的过程称之为域名解析。
DNS的实现使用了客户机/服务器模型,名称与IP地址的映射存储在专门的服务器(称为域名服务器)上,客户机通过查询域名服务器获得答案,Internet的DNS使用基于域的分层次的命名机制以及为了实现这个命名机制的分布式数据库,整个Internet上的名称解析由分布在全球的若干个域名服务器完成。即使单个域名服务器出现故障,也不会影响整个系统的运行。
在Linux中的DNS实现使用的是BIND (Berkeley Internet Name Domain),它的守护进程名称是named,它通过/etc目录与/var/named目录中的一系列配置文件,实现域名解析。
2 DNS的工作原理
以访问www.microsoft.com为例说明。
(1)客户端首先检查本地c:windowssystem32driversetchost文件,是否有对应的IP地址,若有,则直接访问Web站点,若无则转(2)。
(2)客户端检查本地缓存信息,若有,则直接访问Web站点,若无转则(3)。
(3)本地DNS检查缓存信息,若有,将IP地址返回给客户端,客户端可直接访问Web站点,若无转则(4)。
(4)本地DNS检查区域文件是否有对应的IP,若有,将IP地址返回给客户端,客户端可直接访问Web站点,若无,则转(5)。
(5)本地DNS根据cache.DNS文件中指定的根DNS服务器的IP地址,转向根DNS查询。
(6)根DNS收到查询请求后,查看区域文件记录,若无,则将其管辖范围内.com服务器的IP地址告诉本地DNS服务器。
(7).com服务器收到查询请求后,查看区域文件记录,若无,则将其管辖范围内.DNS服务器的IP地址告诉本地DNS服务器。
(8)DNS服务器收到查询请求后,分析需要解析的域名,若无,则查询失败,若有,返回www.microsoft.com的IP地址给本地服务器。
(9)本地DNS服务器将www.microsoft.com的IP地址返回给客户端,客户端通过这个IP地址与Web站点建立连接。
3 Linux下的DNS的一些基本概念
3.1 需要了解的一些符号
@——意味着域。
IN——INTERNET,与A,PTR或CNAME记录一起使用时可将域名映射为IP地址,反之一样。
NS——域名服务器指定的区域DNS服务器的域名或IP地址。
PTR——将IP地址映射为主机名,PTR记录执行与A及记录相反的过程。
A——将主机名映射为其IP地址。
MX——MX记录定义何种机器来为域或单个主机传送电子邮件。
SOA——指明其后的域名定义了主域名服务器及该域的联系点的电子邮件地址。
3.2 Linux下的DNS服务器主要配置的文件
/etc/named.conf(主配置文件)设置一般的name参数,指向该服务器使用域数据库的信息源。
/var/named/named.ca(根域名配置服务器指向文件)指向根域名配置服务器,用于缓存服务器初始化,该文件一般为默认。
/var/named/domainname.com..zone (正向域名解析文件)用于将服务器IP地址转化为回送方的域名。
/var/named/192.168.1.arpa (反向域名解析文件)用于将域名转化为服务器的IP地址。
4 Linux下DNS服务器的规划
4,1主配制文件
定义保存区域数据的文件名,每一个标准的DNS服务器都有一个保存根服务器列表的文件,它包含了INTERNET上的根服务器对应的IP地址。
4.2正向解析文件
建立正向解析DNS数据库文件,进入目录/var/named
设置序列号,可为2009090105
设置更新时间,即辅助服务器和主服务器隔多久进行一次数据复制。
设置重试时间,重新发送的时间。
设置过期时间,辅助服务器和主服务器在该时间内无联系,则放弃这个区域的数据。
设置TTL值,定义允许辅助名称服务器缓存查询数据的默认时间。
在以上的DNS数据库文件中,第一行分别指明DNS服务器的名字,DNS管理员的邮件地址,后面的数字中,第一个指明了版本号,每次修改完此文件后都要增加版本号,就是简单地在上面加1。后面的NS记录指明了域名服务器的本身的域名,MX记录指明了邮件地址转换记录,A记录就是地址记录,指明了从域名到IP地址的对应的关系。CNAME是别名记录,作用是把mail.gaoyuan.com对应于host1.gaoyuan.com,并把www.gaoyuan.com对应于host2.gaoyuan.com。
4.3反向解析文件
5 启动和测试named
启动服务器后,进入nslookup命令交换环境,nslookup www.gaoyuan.com,“回车”之后即可看到如下结果:
出现以上结果代表域名解析成功。如果您的服务器具有公网地址,就可以在互联网中作为域名服务器使用。
参考文献
[1]刘兵.Linux实用教程[M].北京:中国水利水电出版社,2004.
[2]杨建新.Red Hat Linux9入门与提高[M].北京:清华大学出版社, 2006.
[3]林慧琛.Red Hat Linux服务器配置与应用[M].北京:人民邮电出版社.2006.
DNS系统 篇4
#关闭数据包缓存，测试时开启查询时直接读缓存不经过lua preresolve
代码如下复制代码disable-packetcache=yes
forward-zones=com=108.61.242.102
local-address=0.0.0.0
lua-dns-script=/tmp/b.lua
#转发所有域到pdns server
forward-zones=.=127.0.0.1:54
lua：
代码如下复制代码
function preresolve ( remoteip, domain, qtype )
pdnslog(“a test message.. received query ”..domain..“ from ”..remoteip..“ on ”..getlocaladdress());
ret={}
if qtype ~= pdns.A then return -1, ret end --非A记录查询跳过，后端查询
local ips = {“192.168.1.1/32”, “10.1.0.0/16”, “127.0.0.0/24”}
if matchnetmask(remoteip, ips) and domain == “www.example.com.”
then
ret[1]= {qtype=pdns.A, content=“85.17.220.215”, ttl=86400}
setvariable()
return 0, ret
else
setvariable()
return -1, ret
end
DNS系统 篇5
1 体系结构
动态域名系统的体系结构如图1所示,其各个模块的功能如下:
1)终端用户通过web页面向建立在Apache之上的域名申请及管理模块提交域名注册、注销或修改密码等请求。如果符合设定的条件(如域名没有被重复注册等),则由域名申请及管理模块将用户的域名申请信息(包括用户名、密码、所申请的域名等)写入建立在My Sql数据库中的用户域名信息数据库,其中用户域名信息数据库主要包含如下的字段:用户编号、用户名、密码、域名、申请时间、注册时间、域名有效否、域名更新有效时间、当前IPv4地址、当前IPv6地址、Email、联系方式等。此外,系统管理员一方面可以通过Web页面对用户所提交的域名信息进行审核(只有审核后域名信息才能生效)、注销等处理;另一方面可以定制一些全局的系统参数,供后台监控模块调用。
2)DDNS客户端以Service方式在终端用户主机上运行,以一定的时间间隔(即域名更新有效期)提取用户计算机上的Mac地址、IPv4及可聚集的全球IPv6地址,并将它们和用户所输入的用户名、密码、所申请的域名、域名更新有效期发送给域名更新模块。当然,DDNS客户端在退出时,将发送注销域名的请求。
3)域名更新模块收到DDNS客户端发来的注册信息后,比对域名信息数据库中的信息(用户名、密码、域名)进行认证,如果不一致则返回错误信息给客户端,否则存在这么几种情况:(1)向域名服务器发起更新域名信息的请求,更新域名成功则域名更新模块修改域名信息数据库中相关记录的信息(域名有效否、注册时间、域名更新有效时间、当前IPv4地址、当前IPv6地址),并返回更新成功的信息给客户端;(2)向域名服务器发起更新域名信息的请求,更新域名不成功则域名更新模块返回错误信息给客户端;(3)通过认证后,如果对应记录中的域名有效否为真(即域名已经在域名服务器中生效),还需检查IPv6地址是否相同,如果地址没有改变则只需要在域名数据库中更新该记录的部分信息(注册时间、域名更新有效时间)即可;(4)还有一种情况是,如果发现IPv6地址已经被注册,即出现一个IPv6地址对应两个域名的情况,这时需要向域名服务器发起两个请求,一个是删除原先已经注册的记录的请求,一个是增加一条新记录的请求。
4)后台监控模块以Service的方式在服务器端运行,以一定的时间间隔轮询域名信息数据库,将已经超过域名更新有效时间域名信息的从域名服务器中删除,并修改相关的数据库记录。这样可以避免DDNS客户端不正常退出,而导致域名信息超过域名有效期后,仍然在域名服务器中启用的情况。
5)为了确保上述信息在网络传输过程中被监听和篡改,从而导致DNS域名劫持、DNS拒绝服务攻击等问题出现,系统采取了如下的安全措施:web客户端与域名申请及管理模块之间采用https协议进行传输;DDNS客户端与域名更新模块之间所传输的信息采用MD5进行加密与解密;域名服务器只授权域名更新模块所在的主机对其进行动态域名更新,而不允许其他主机直接去更新其域名信息,同时两者之间安全则采用事务签名TSIG[3]来加以保证。
2 部分关键实现
限于文章篇幅,本文主要讨论IPv6的实现方法。
2.1 DDNS客户端的实现
客户端实现的一个很重要的问题是如何感知IP地址的变化并确保该地址是有效的、合法的(即没有冲突)。对此,H.Kitamura提出在本地网络设置一个detector和register[4],然后利用IPv6重复地址检测机制来发现新地址。北京邮电大学的科研小组则采用一种简单的方法来发现新地址[2]——周期性读取读取节点的IP地址,然后与上一次的结果进行比较,若发生变化则认为发现新地址。这两种方法都存在一些问题,对于前者,由于节点的重复地址检测机制是可选,例如在有状态地址自动配置时该模块就不一定启用,因此该方法存在一定的局限性;对于后者,如果时间间隔比较小可以及时发现地址的变化,但是缺乏检测地址有效性这一环节,可能会导致出现一个地址分配给两个域名的情况,即DNS欺骗。
借鉴这两种方法的优点,本文提出一种与地址自动配置无关的、基于Win Pcap4.0[5]网络编程的检测方法:主线程周期性地调用函数pcap_findalldevs_ex()获取本地主机网络适配器列表(pcap_if结构);如果某个指定适配器前后两次IP地址没有变化,则立即返回准备下一个循环,否则首先调用函数pcap_open_live()打开该适配器并将其工作模式设为混杂模式(Promiscuous),接着调用函数pcap_comp ile()、pcap_setfilter()来编译和设置过滤器以缩小捕获数据包的范围,调用函数pcap_sendpacket()发送1个源地址类型为IPV6_ADDR_ANY(全0地址)的NS(邻机请求报文),最后在创建一个子线程后返回准备下一个循环;子线程在一定时间(一般为1秒)内不断地调用函数pcap_next_ex()来捕获收到的报文,如果遇到下面两种情况:(1)当收到目标地址为正在检测的地址且源地址类型为IPV6_ADDR_ANY(全0地址)的NS;(2)当收到目标地址为其正在检测的地址的NA(邻机公告报文),则认为该地址不是有效地址,不向域名更新模块发送更新请求,否则向域名更新模块发送更新请求。
2.2 更新服务模块的实现
更新服务模块建立在Linux的双协议栈平台上,主要采用Berkley Sockets(又称为“套接口”)网络编程进行实现[6]。主线程采用socket()、bind()、listen()在通配地址(::)和某个指定端口上监听DDNS客户端的IPv4和IPv6连接,并使用fork()产生一个子线程来处理客户端的域名更新请求。在子线程中,一个关键点是如何实现更新模块与域名服务器之间的域名动态更新。一般来说,编程实现更新Bind9的域名信息有三种方法:1)shell脚本,即调用nsupdate命令来更新域名,这种方法简单好用、开发周期短,但是效率不高、缺乏足够的错误消息控制。2)用解析器和名字服务器的库例程进行C编程,这种方法功能强大、效率较高,但是实现复杂、所需开发周期较长。3)用Net::DNS模块[7]进行Perl编程,虽然Perl这种解释语言的运行比C语言慢,但是对大多数网络应用程序(瓶颈往往是I/O)来说,Perl运行和编译程序是一样的快(慢);另一方面,Perl面向对象扩展可大大简化开发过程。综合上述比较,本文采用第3种方法来实现更新过程,这里给出与AAAA记录更新相关的一些代码:
3 结束语
本系统具有终端用户易于使用(如通过web界面来管理域名的申请、审核和注销;域名更新与地址配置无关仅需安装客户端即可)、兼容IPv4/IPv6(基于双协议栈的网络编程)、安全性高(如更新请求不是直接发给域名服务器而是经过更新模块认证后才转发给域名服务器、域名更新信息采用数字签名进行了认证)、稳定性好(基于bind9来进行二次开发)等特点,经过在海南师范大学校园网上的试用,证明该系统无论是功能还是性能都能够满足应用需求。考虑到客户端已采用具有网络底层访问能力的winpcap来进行编程,下一步我们将在该系统中加入AAA(认证授权与计费协议)模块,这样每个校园网用户在获得相应域名的同时可完成上网认证、计费等功能,届时随着IPv6的全面部署,越来越多的终端设备要求加入互联网,该系统会越来越显得重要。
参考文献
[1]王萧,马严,梁利军,等.IPv6 DNS自动更新系统的研究[J].微计算机应用,2006,27(4):385-388.
DNS系统 篇6
DNS是互联网中的一项核心基础服务, 是域名URL和IP地址互相映射的分布式数据库。为人们访问互联网业务和应用提供了便利性, 我们不必再去记忆复杂的IP地址, 而是通过简单域名就可以更方便的访问互联网。
随着互联网应用的普及, DNS系统逐渐成为黑客们关注焦点, DNS在实现域名解析这一基础功能, 由于其开放性, 面临来自互联网的各种安全威胁。本文首先对运营商DNS系统面临的安全威胁, 从内部自身缺陷、外部网络攻击和运营管理等方面进行分析, 并提出这些威胁的应对防护技术和措施, 并已在现有DNS系统中进行部署。
DNS:Domain Name System域名系统;
URL:Uniform Resoure Locator:统一资源定位器;
2 运营商DNS安全威胁分析
经过多年运营维护DNS的遇到问题和经验总结, 运营商DNS安全威胁主要来自三个方面:内部自身缺陷、外部网络攻击和运营管理风险。
2.1 内部自身缺陷
DNS内部自身缺陷主要从DNS网络架构缺陷和DNS软件漏洞两个方面分析。
2.1.1 DNS系统组网架构问题
运营商前期部署DNS系统架构时都采用四层交换机负载均衡技术实现服务器群对外提供集中式的域名解析服务。
这种组网方式一般以省为单位, 在两个核心节点建设两套互备的DNS系统, 每套系统都采用四层交换机技术建立DNS服务器集群, 两套DNS分别采用不同的DNS服务IP地址, 通过告知客户主备DNS服务器地址的IP来实现冗灾。
每个DNS节点采用防火墙、四层交换机、DNS服务器群三层架构:防火墙用来保护整个系统的安全防止外部的攻击, 四层交换机用来将用户DNS请求平均分配到集群内每台DNS服务器上, 完成流量负载均衡作用, DNS服务器用来完成最终的递归和解析。
四层交换机组网方式的特点是:建设强大的服务节点, 依靠系统的健壮性保障服务的可靠性, 用系统的高可用性弥补体系设计上的不足。经过多年的运行, 四层交换机组网方式的缺点也日益显现:
1) 四层交换机能力不足:四层交换机的业务流量分配主要是通过设备内部的软件系统和硬件芯片, 进行针对数据包的查看、重组和分发等负载工作。虽然目前四层交换机适合各种复杂协议的应用, 但DNS服务是一种比较简单的UDP协议应用, 具有流量带宽占用很小, 包交换量巨大的特点, 因此四层交换机的优势在DNS系统中无法体现。四层交换机的包交换能力无法与三层交换机相比, 在包交换能力上的欠缺使其成为负载分担DNS服务中的一个瓶颈。
2) 系统容灾能力不强:由于是集中式服务, 一但遭到外部异常流量的DDOS攻击, 防火墙却成为瓶颈, 很容易造成系统超载的情况, 影响全网用户业务。
2.1.2 DNS软件漏洞
BIND (Berkeley Internet Name Domain) 是现今互联网上最常使用的DNS服务器软件, 据统计, 全球使用BIND的DNS服务器约占90%, 其中包括DNS根服务器等重要系统。
BIND现在由互联网系统协会 (Internet Systems Consortium) 负责开发与维护, 有四个重大的版本系列, 分别是BIND4、BIND8、BIND9以及最新发布的BIND10, 各系列之间的变动很大, 配置也非常不同, 目前业界普通使用的是BIND9, BIND9较之前版本更改了底层代码, 加入了大量的安全性防护措施, 安全性大幅提升。虽然BIND已经是DNS服务器的事实标准, 但由于BIND是开源软件, 也持续出现了不少的安全漏洞, 近年影响比较大的漏洞包括ISC BIND9远程动态更新消息拒绝服务漏洞、多家厂商DNS实现缓存中毒漏洞、dnsmasq DNS缓存中毒和拒绝服务漏洞等。
2.2 外部网络攻击
DNS遭受外部攻击类型有很多, 目前主要攻击有两类:拒绝服务攻击和DNS欺骗攻击。
2.2.1 拒绝服务攻击
拒绝服务攻击 (简称DOS攻击) 就是利用合理的服务请求占用过多的服务资源, 从而使合法用户无法得到服务的响应。单一的DOS攻击由于是一对一的资源消耗, 很容易发现和封堵, 所以一般不会造成太大威胁, 当前威胁最大的是分布式拒绝服务攻击 (DDOS) 。
DDOS攻击指攻击者利用大量的傀儡主机向目标发起大规模的资源消耗攻击, 在遭受到DOS攻击时, 如果DNS系统本身性能不够强大, 或者网络带宽资源不足, 都会导致DNS无法响应正常用户的域名解析请求, 从而导致服务瘫痪。如果发起的DDOS攻击涉及大量需要递归到某个使用面很广的域名所在的DNS授权服务器, 或者需要追寻到DNS根域名服务器时, 可能会导致相应服务器瘫痪, 从而使得其他有同样解析请求的DNS系统产生大量解析不成功问题, 负荷快速增高, 影响会进一步扩散。
2.2.2 DNS欺骗攻击
DNS欺骗攻击指攻击者冒充DNS的一种攻击行为, 通过各种手段, 让DNS反馈给用户错误的解析信息, 在用户不知情的情况下, 将用户引向黑客指定的网站。主要包括缓存投毒和域名劫持2种。
1) 缓存投毒又叫域名欺骗, 攻击者欺骗DNS服务器, 让其相信一个伪造DNS响应是真实的, 从而将错误的解析结果传递给用户, 将用户引向黑客指定的网页。缓存投毒有很多手段, 下面列举几个比较典型的方法:
方法一:直接控制一个域名服务器, 利用它向其他服务器发起域名解析请求, 请求的域名都是这个服务器负责的域名, 且采取递归请求, 这样其他域名服务器就会都学习到这台已经被黑客控制的服务器上错误的域名解析, 并且传播给所有访问的用户。
方法二:通过ARP欺骗手段, 如果DNS系统网络设计不严谨, 虽然DNS系统本身没有被黑客控制, 但是和它同一局域网的其他设备存在漏洞被黑客控制, 黑客可以利用ARP欺骗来实现Transaction ID欺骗。
方法三:利用概率手段, 也就是业界说的“生日攻击”, 如23个人在一起时, 两个人相同生日的概率达到50%以上这一概率特点, 攻击者向域名服务器针对同一个域名发起大量的查询请求的同时, 也发送大量回应报文, 由于transaction ID不相同, 当发送报文量很大时, 就有很大可能会使得该域名服务器被欺骗。
方法四:黑客侦听DNS服务器发出的查询请求, 猜测其transaction ID, 从而在用户发出某个请求后, 在DNS服务器之前将虚假的响应交给用户, 从而欺骗客户端去访问恶意的网站。
2) 域名劫持是攻击者通过技术手段控制域名服务器 (有可能直接获取域名管理帐号密码, 或者控制域名管理邮箱) , 从而将该域名的DNS解析指向黑客控制的DNS服务器, 然后通过在该DNS服务器上添加相应的域名记录, 这样, 当用户访问这个网页时, 就会在不知情的情况下链接到黑客指定的网站, 从而用户在该网站上所有行为都被黑客完全掌握, 产生危害。
2.3 运营管理风险
2.3.1 DNS安全策略不完善
DNS系统部署上线前, 应从服务范围、协议端口开放、防护工具等安全策略方面有完整的规划和配置。早期的DNS系统只关注域名解析应用功能的实现, 对于上述安全问题很少关注, 给黑客打开方便之门。
2.3.1 DNS网管安全问题
DNS网管为DNS系统维护提供了便利的手段, 它可以实时监控DNS告警、配置DNS安全防护策略、远程控制DNS服务器等。虽然DNS安全问题已被重视, 实施了各种防护策略保障它的安全, 但是DNS网管自身的安全常常被忽略, 它已成为DNS安全问题的另一突破口。
近两年, DNS网管已多次曝出存在跨站、目录遍历、JBOSS页面可访问且存在空口令或弱口令等问题, 有的漏洞可以让黑客利用直接控制网管服务器, 从而达到控制DNS系统的目的。
3 DNS安全防护关键措施
针对以上3方面的威胁分析, 下面从解决内部组网和系统缺陷、积极防护外部主要攻击和完善运营管理等方面采取合理防护技术和措施, 确保运营商级DNS的安全稳定运行。
3.1 内部自身缺陷的关键防护措施
首先内部组网架构由四层交换机负载方式调整为Anycast组网方式。
Anycast是一种网络技术, 它借助于网络中动态路由协议实现服务的负载均衡和冗余。以Anycast架构组建的DNS系统由三层交换机+DNS服务器群二层结构组成, 相对于传统的四层交换机组网方式, Anycast组网中三层交换机取代四层交换机, 通过anycast方式的等价路由实现四层交换机的负载均衡功能, 因为三层交换机的包交换能力远远大于四层交换机, 几乎不存在瓶颈问题, 分布式的部署方式让DNS的安全性大幅提高, 低于DDOS攻击能力增强, 近两年Anycast组网模式在DNS架构中逐渐得到广泛应用, 并在各类攻击中经受住实践的检验。
该方式实现关键点如下, 具体如图1所示。
1) 接入路由器通过BGP向上层网络宣告服务器群IP地址段。
2) 缓存器服务器安装主机路由软件, 与接入路由器之间运行IGP (建议使用OSPF, 所有节点同属于area0) , 发布相同的Anycast虚地址, 用户域名解析请求网络内通过OSPF的多条等价路由自动选择缓存服务器提供服务, 实现缓存服务器间的流量分担。
3) 缓存服务器和递归服务器硬件分开:递归服务器只接受本节点内缓存服务器的递归查询请求, 不对普通用户提供DNS查询服务, 这样可以降低递归型攻击对节点的影响。
4) 隐藏服务器实地址:缓存服务器Anycast虚地址与节点内缓存服务器实地址、递归服务器实地址应使用相关性较小的地址段, 防止关联攻击。
5) 增加Cache设备, 降低缓存服务器压力:建议在缓存服务器前增加一级Cache设备, 存储大部分的域名解析样本, 在用户域名解析请求落在样本范围内时, 直接通过Cache应答用户, 减轻缓存服务器压力, Cache和缓存服务器之间保持定期同步, 以维持样本的准确性。
其次在DNS软件漏洞方面, 首选解决措施是采用非开源DNS解析软件, 减少漏洞发生的可能性, 比如Nominum的CNS, CNS在安全性上大大强于BIND, 在解析性能上也好于BIND。
经过现网实际测试, 相同的服务器硬件条件下, CNS的解析能力约为BIND的4倍, 运行几年未发生一起软件问题。CNS软件虽然有很多优点, 但是它存在最大的缺点是:价格昂贵, 除购买时价格较高外, 每年还需支持很高的维护费。一般来说, 运营商购买CNS软件也仅会作为多台BIND服务器的补充, 如果要全部使用CNS为全省DNS服务, 成本非常高。
多数情况, 并没有足够资金支持非开源软件采购和使用, 仍需要采用BIND, 防范BIND的漏洞是主要有以下方法:
(1) 密切跟进BIND漏洞信息, 及时升级补丁。
(2) 隐藏版本号:BIND软件的BUG信息一般和特定版本相关, 因此版本号是黑客寻求最有价值的信息。黑客使用dig命令可以查询到BIND版本号, 就可以知道这个软件有那些漏洞, 所以, 应隐藏BIND版本号, 通过修改配置文件:/etc/named.conf, 在option部分添加version声明将BIND的版本号信息覆盖, 即可实现。
(3) 隐藏服务器信息:和版本号一样, 尽量隐藏服务器信息, 建议不要在DNS配置文件中使用HINFO和TXT两个资源记录, 让潜在黑客更难得手。
3.2 外部网络工具关键防护措施
首先, 针对拒绝服务攻击类型, 它们显著特征是对攻击目标大量的资源消耗, 防范的关键在于如何阻止无谓的资源消耗。虽然没有完全彻底的DDOS攻击解决方案, 但是很多措施可以让我们减少攻击带来的危害, 除了采用Anycast组网方式可以从架构上较好抵御攻击外, 还有如下防护措施:
1) 使用SYN cookie。SYN Cookie是对TCP服务器端的三次握手协议作一些修改, 专门用来防范SYN Flood攻击的一种手段。它的原理是, 在TCP服务器收到TCP SYN包并返回TCP SYN+ACK包时, 不分配一个专门的数据区, 而是根据这个SYN包计算出一个cookie值。在收到TCP ACK包时, TCP服务器在根据那个cookie值检查这个TCP ACK包的合法性。如果合法, 再分配专门的数据区进行处理未来的TCP连接。
2) 增大backlog。通过增加backlog数值, 可以一定程度减缓大量SYN请求导致的TCP连接阻塞情况, backlog数值系统默认是1024, 建议增设为1280至2048, 这样在强度不是很高的攻击下, 系统响应能力可以提高。
3) 缩短retries次数。Linux系统默认的tcp_synack_retries是5次, 将这个数值减少可以提高系统响应能力, 建议改为2次。修改后, SYN_RECV的数量有了少量减少, 系统响应速度可以加快。
4) 限制SYN频率。目前比较有效的是对SYN的频率和次数进行限制, 这样最大限度的控制了单个IP地址发动攻击的能力。例如将SYN请求的次数限制在30次/min, 系统默认是5次/min可以将burst从默认的5个降低到2个。进行此操作后正常的用户无任何感觉上的差异, 而并发的SYN请求量下降了不少, 服务响应基本正常了
5) 单IP域名请求限制。对于单一IP的DOS攻击, 单IP域名请求限制是一个非常有效的防范手段, 根据绝大多数用户日常上网习惯, 建议对单个IP限速300QPS, 当有超出此请求量时, 一方面会拒绝超出的解析请求;另一方面会自动出告警提示管理员有异常行为需关注。
6) 单域名请求限制。对于针对某几个域名的DDOS攻击, 单域名请求限制是很有效的防范方法, 按照绝大多数域名访问量统计, 建议对单域名限速2万QPS, 超出则视为异常, 一方面会拒绝超出部门的解析请求;另一方面会自动出告警提示管理员。其次, 针对DNS欺骗攻击类型, 最好的防护在用户自身, 如禁用客户端DNS缓存、记录重要网站IP地址做比对等等。在DNS服务器侧, 主要有以下防范措施:
1) 请求session限制, 对重要网站做请求session数限制, 防止过多的递归报文对授权服务器造成欺骗攻击。
2) 关闭DNS服务器的glue fetching选项, 当DNS服务器返回一个域的域名服务器记录且记录中没有相应记录, DNS服务器会尝试获取一个记录, 就称为glue fetching, 攻击者可以利用它进行DNS欺骗, 关闭glue fetching可以避免此类问题。
3) 缓存投毒检测与联动措施, 依靠UDP随机源端口、DNS的ID字段, 判断是否为投毒, 如果投毒, 对该域名进行锁定。
4) 域名监控, 对重要域名的A记录进行监控, 如果变动则产生告警信息, 提示管理员查处。
5) ARP攻击防范, 在接入交换机上局域网内的每台服务器都做MAC和IP的绑定, 可有效阻止ARP欺骗引起的DNS欺骗攻击。
3.3 安全运营管理防护策略
以下列出DNS系统基础运营管理防护策略, 建议在系统上线时作为安全基线和安全三同步原则进行部署。
1) 限制DNS服务范围:以省为单位建设的DNS系统, 建议将DNS对外提供域名解析服务的范围控制在本省电信地址段内, 这样可以抵御来自外网的DDOS攻击, 如果攻击来自本省电信网内, 对攻击源的查处会比较容易。
2) 限制对外服务协议端口:在接入路由器上做访问控制策略, 只允许本省电信用户地址段且源协议端口号1023以上访问缓存服务器Anycast虚地址的UDP/TCP53端口, 只允许源端口UDP/TCP53访问递归服务器实地址的1023以上端口。
3) 最小化系统配置:对承载DNS软件的操作系统实施功能最小化配置, 内核安全优化, 升级操作系统的漏洞补丁等, 关闭主机不必要的服务, 目前电信的DNS服务器基本为UNIX系统, 通过关闭finger、rlogin、shell、smtp、nfs等无关服务, 减低安全风险。
4) 异常包过滤策略:按一定规则对异常包进行过滤, 如:非法IP、非法查询包 (长度异常、格式异常或者内容异常) , 能够防范DNS缓存投毒、防止错误域名以及能够对DNS Flood、UDP Flood等常见DDOS攻击进行过滤。
5) 业务限速:前面在讨论拒绝服务攻击的防护手段时也讲到这点, 对单IP以及单域名的业务请求实施QPS限速, 将有效防范普通的DDo S攻击, 建议对单IP限300QPS, 对单域名限2万QOS。
6) 网管安全策略:DNS网管应比照WEB安全防护来部署相应安全策略, 规范网页代码的严谨性、杜绝弱口令、及时打补丁等。同时避免网管暴露在公网上。
7) 部署异常流量监控和流量清洗系统:针对去往DNS的所有流量实施监控, 检测到异常流量时, 自动启动清洗系统清洗, 或预警通知管理员手工处理, 业界使用较多的两款IP流量监控系统是Genie ATM系统和Arbor系统, 均可较好的监视到大部分的攻击流量。
8) 部署DNS带外网管:建议部署DNS带外网管, 在DNS遭受外部攻击从网络无法登录时, 可做应急使用。
4 结束语
DNS系统面临网络威胁和防护是一个永无止尽的话题, 尽管DNS的各种安全威胁日益增多, 安全风险越来越大, 但DNS安全防护技术也在不断更新, 魔高一尺道高一丈, 每种安全问题和威胁都一定有应对防护措施。本文探讨的DNS安全防护关键技术和措施多数已在现网环境中应用和部署, 可以抵御大多数的安全问题。但仍有很多安全手段有待进一步研究, 比如面对DDOS攻击, 目前只能缓解攻击影响, 不能彻底的解决, 当前业界流量清洗系统对DNS业务的清洗效果不十分理想, 自动清洗可能导致误伤等。但我们相信办法总比问题多。
摘要：DNS作为运营商为用户提供访问互联网应用和业务的基础设施, 其IP地址信息暴露在公网上, 随着网络安全受到社会普遍的关注和黑客产业链的快速发展, DNS系统逐渐成为黑客们关注焦点, 本文从运营商DNS系统面临的安全威胁分析入手, 并对这些威胁的应对策略进行探讨, 提出现网DNS安全防护措施。
DNS系统 篇7
关键词：网络安全,网页挂马,云安全,检测
1 网页挂马解决方案比较
针对挂马网页, 目前常见的解决方案有3类:浏览器内置过滤功能;浏览器插件过滤;反病毒软件提供过滤功能。
1.1 浏览器内置过滤功能
目前常用的浏览器软件, 包括Internet Explorer 7.0、Firefox 2.0、Opera 9.1、Safari 3.2及其之后的版本均内置挂马网页过滤功能。其中, Firefox使用Google提供的反挂马数据, Opera使用PhishTank和GeoTrust提供的数据。
浏览器实现的挂马网页过滤具有以下两个缺点:挂马网页过滤依赖于浏览器实现, 与其支持的操作系统有关, 并且不能为计算机上安装的其他网络软件或浏览器提供保护;浏览器需要将用户访问的页面地址发送给服务器进行比对, 增加了网络带宽消耗、页面处理延迟, 并且可能泄露用户的隐私。
1.2 浏览器插件过滤
基于浏览器插件的反挂马解决方案, 典型应用有AVG LinkScanner、McAfee SiteAdvisor, 除了提供挂马网页过滤, 还包括了对搜索引擎搜索结果安全性的标注, 帮助用户甄别搜索引擎结果中的有害网页。
浏览器插件提供的挂马网页过滤和浏览器内置功能相比, 提供更强的安全保护能力, 然而, 此类插件对于浏览器的依赖更强, 一般只能安装于Internet Explorer和Firefox浏览器, 并且同样存在需联网检查用户访问内容的问题。
1.3 反病毒软件提供过滤功能
目前越来越多的反病毒软件具有包括反挂马网页在内的网络威胁过滤能力。此类软件对挂马网页过滤的实现方法与其查杀网页恶意代码的做法相似杀毒软件的Web监控通常在本地提供HTTP透明代理, 应用程序访问网页HTTP服务的流量都会经过杀毒软件的Web监控扫描。在此过程中, 杀毒软件可以对网页的URL地址进行过滤, 以屏蔽挂马网页。
与浏览器或浏览器插件提供的反挂马功能不同, 反病毒软件过滤挂马网页的功能可以适用于计算机上安装的各类软件, 并且, 挂马网址数据库一般在反病毒软件更新病毒定义时同时下载, 检测网址过程在本地即可完成。但是, 此类实现方法对系统资源的消耗较大, 依赖于操作系统 (通常为Windows设计) , 且挂马网址数据库需频繁更新以应对最新的威胁。
2 融合云计算及多扫描引擎技术的DNS挂马网页过滤系统
针对以上反挂马过滤实现方法存在的弊端, 基于DNS的挂马网页过滤系统可以提供一个较好的解决方案。域名解析是用户访问网页所必须经历的过程, 在DNS服务器上实现挂马网页过滤不会对用户的网络访问过程增加额外的步骤或产生任何影响。
基于DNS的实现适合任何接入网络的计算机或设备, 与客户端运行的操作系统和浏览器无关, 无需安装任何客户端程序或插件, 适用范围广。挂马网页识别过程由DNS服务器完成, 减轻客户端对资源消耗的压力。通过云计算技术, 客户端无需下载保存任何挂马网址数据, 所有的数据更新过程在DNS端完成, 省去客户端数据库下载和更新, 也避免了客户端数据库更新不及时造成的安全隐患, 同时, 通过多扫描引擎查杀, 可向客户端提供针对最新威胁的及时保护。
总结以上4种反挂马解决方案, 对比其性能特点如表1所示, 基于DNS的挂马网页过滤系统在提供同样的保护能力的同时可解决过滤系统对客户端的依赖部署和维护更为简便。
3 多扫描引擎技术
在当今的网络安全解决方案中没有一款使用单个杀毒引擎能最快最有效地识别木马及其他威胁。利用多引擎反病毒能有效地减少病毒感染的几率。
每一个病毒实验室所研制的扫描引擎是不一样的, 没有一种可以称得上在各方面是最优
秀的, 它们都有各自的优势与劣势。防病毒软件产品一般会使用混合式的技术去检测及击败病毒。以下是最主要的3种方法:特征文件、启发式检测、沙箱。
每一种技术方法都能十分有效地检测到病毒, 但都不能百分之百成功检测。没有任何一个方法是最佳的检测病毒的解决方案, 所以一些反病毒产品集合了两个或者更多的这些检测技术方法。最有效并且是唯一的方式保证上网用户拥有最高等级的防护就是通过使用多扫描病毒引擎, 采用多层深度防御。
值得注意的是, 多扫描引擎是一个很好的解决方案, 但重要的是明白我们获得了什么。当我们拥有5个反病毒扫描引擎时, 并不意味着能提供给我们5倍的网络防御能力, 它只不过给我们提供了5次正确应对网络威胁的机会, 更恰当的来说, 这是5次独立的判断、作出应对的事件。这就好比我们在机场通过5道安检, 每一道安检的内容或方式都会有些微的不同, 这样能增加发现威胁情况的几率。在此系统中我们引入了多个防病毒扫描引擎的使用, 以此增强扫描的可靠性。
4 Hadoop分布式计算平台
Hadoop是一个能够分布式处理大规模海量数据的软件框架。它的长期目标是提供世界级的分布式计算工具, 也是对下一代业务 (如搜索结果分析等) 提供支持的Web扩展 (Web-scale) 服务。
Hadoop主要由HDFS (HadoopDistributedFileSystem) 和MapReduce引擎两部分组成。最底部是HDFS, 它存储Hadoop集群中所有存储节点上的文件。HDFS的上一层是MapReduce引擎, 该引擎由JobTrackers和TaskTrackers组成。
HDFS可以执行的操作有创建、删除、移动或重命名文件等, 架构类似于传统的分级文件系统。需要注意的是, HDFS的架构基于一组特定的节点而构建 (见图1) , 这是它自身的特点。HDFS包括唯一的NameNode, 它在HDFS内部提供元数据服务;DataNode为HDFS提供存储块。
JobTracker (Google称为Master) 是负责管理调度所有作业, 它是整个系统分配任务的核心。它也是唯一的。
TaskTracker具体负责执行用户定义操作, 每个作业被分割为任务集, 包括Map任务和Reduce任务。任务是具体执行的基本单元, TaskTracker执行过程中需要向JobTracker发送心跳信息, 汇报每个任务的执行状态, 帮助JobTracker收集作业执行的整体情况, 为下次任务分配提供依据。
Map操作是独立的对每个元素进行操作, 在函数式编程中, 操作是没有副作用的, 换句话说, Map操作将产生一组全新的数据, 而原来的数据保持不变。因此, 它是高度并行的。Reduce操作虽然不如Map操作并行性那么好, 但是它总会得到一个相对简单的结果, 大规模运算也相对独立, 因此也是比较适合并行的。
5 系统分析与设计
当用户访问一个网站时, 向DNS服务器发送的域名查询仅包含该网址的域名部分, 考虑到一些网站只有部分页面存在挂马和欺诈信息, 以及一些允许用户发布页面或内容的大型网站上可能存在少量有害页面, 对域名的过滤容易造成误报, 影响网站正常内容的访问。
为了解决这个问题, 我们设计了基于DNS服务器、HTTP透明代理服务器和Web服务器以及数据库群的挂马网站过滤系统架构 (图2) , 以提供基于域名和基于URL的两种过滤方式。
我们通过实现BIND服务器的反挂马模块, 作为挂马网站过滤系统的基础。挂马网站记录在内存中以哈希表的链式结构存储以提高查询效率, 反挂马模块提供域名查询数据文件读入数据重新载入等接口函数
查询函数返回3类结果:被查询的域名不是挂马网站、域名被拦截和域名需进行URL过滤。定义如下:
及时有效的挂马网址数据是挂马网站过滤系统使用效果的基本保障。通过提供一个数据转换和整合程序, 将不同来源的挂马网站数据转换为便于DNS服务器和代理服务器读取的统一的数据格式。我们也可以使用防病毒软件公司的扫描接口直接为数据进行过滤服务。
数据整合程序负责将不同来源的数据转换为统一的格式, 供DNS服务器和代理服务器读取。数据整合程序由5个模块组成:
pdb file数据文件写入模块以指定的格式将挂马网站记录写入文件;
pdb hash哈希表模块用于检索并去除重复项;
pdb text模块读取文本格式存储的数据;
pdb mysql模块连接并读取MySQL数据库中的数据, 使用libmysqlclient库;
pdb phishtank模块处理PhishTank格式的数据, 使用libxml2库以解析XML数据。
由于DNS服务器和代理服务器使用的数据文件格式不同, 因此设计有两个数据整合程序, 两者只有数据文件写入模块pdb file不同。
pdb file模块提供文件创建、写入域名记录、写入URL记录和关闭文件的接口函数。
数据整合程序允许通过配置文件方便地定义、添加数据来源。main函数解析配置文件, 并根据配置选项调用各模块的接口函数, 读取相应的数据。
挂马网站内容过滤的警告页面由Web服务器提供, 实现基于Apache HTTP Server和PHP。对网页中不同文件类型的处理通过mod rewrite根据路径中的文件后缀进行URL重写。
文件中的主要规则如下:
此系统为用户提供针对网页挂马网站、网页恶意代码和有害信息的防护, 如果用户无意间访问了这些网站, 系统将禁止访问。
6 结束语
基于云安全的DNS网页挂马探测系统为用户提供及时有效的反挂马网站保护, 且不依赖于操作系统和浏览器, 可适用于各类计算机和设备。
本文对挂马网站过滤系统的实现方法同样适用于其他互联网内容过滤的应用要求, 可作为基于DNS的内容过滤系统使用, 具备基于域名和基于URL地址的过滤能力, 可灵活地过滤网页挂马、违法信息等各类互联网威胁, 应用范围较广。
参考文献
[1]胡双双, 秦杰.搜索引擎技术及其发展趋势[J].福建电脑, 2008 (3) .
DNS系统 篇8
关键词：业务支撑系统,DNS,高可用技术,跨数据中心
1 引言
1.1 DNS技术在BOSS系统中的重要性
随着DNS技术在BOSS系统中的应用越来越广泛, 其在简化BOSS系统管理和维护工作、提高BOSS系统应急容灾切换效率等方面的效果日趋显著, 同时, DNS自身的容灾和高可用保护手段也越来越重要。
目前, DNS技术广泛应用在BOSS系统的外部接入上, 用于提供对外服务的域名。在BOSS系统内部, 由于系统规模越来越庞大、结构越来越复杂, 因此对DNS技术的需求也越来越迫切。以某运营商为例, 经过几年的高速发展, 目前已经拥有600台小型机分区、400台PC SERVER、60套数据库;从结构上又分为接入层、web层、应用层、数据库层等, 每层之间存在大量的连接关系, 需要进行相关的管理配置和维护。如果采用传统基于IP的配置连接方式, 需要分散到很多设备中进行管理连接关系, 造成IT架构复杂, 配置变更时工作量很大;在BOSS系统进行应急容灾切换时, 由于涉及大量系统配置变更, 造成切换时间过长等问题。
采用DNS技术后, 由于可以实现将分散的IP复杂连接关系变为域名方式进行集中的管理、维护, 因此能很好地解决上述问题, 但另一方面也造成DNS本身变为BOSS系统的一个非常核心、重要的部件, 所以必须充分考虑其自身容灾和高可用保护手段。
1.2 当前DNS技术的局限性
传统DNS自身保护手段存在较大弊端, 出现故障时接管延时较长或需要较多配置修改, 难以实现跨数据中心的高可用。
为解决DNS本身的高可用问题, 目前一般采用主/备模式或数据中心内部高可用模式, 能在一定程度上获得高可用性, 但仍然存在问题。譬如, 当首选DNS无法提供解析服务时, 每次系统仍会首先尝试通过首选DNS服务器获取服务;只有解析操作失败后, 才会从备用DNS服务器进行解析。这就造成当主用DNS服务器失效时, 每次解析都会有一定时间的延时;当业务量比较大时, 尤其是短连接类业务可能会出现大量超时。再如, 采用数据中心内部的高可用模式, 能在数据中心内部出现单点故障时获得DNS的高可用保护;但在整个数据中心出现故障的情况下, 则没有保护或者只能采用主/备模式, 存在较大的运行风险。如图1所示。
2 解决方案
为解决上述问题, 某运营商BOSS系统使用跨中心DNS集群方式以实现高可靠性DNS组网。在DNS故障时, 无需做任何干预, 首先在同数据中心实现本地接管;如有问题则自动跨中心接管, 中间几乎无数据丢包。
在此基础上, 将BOSS系统内部IP的配置统一修改为域名方式, 结合少量应用的优化改造, 实现在DNS集群中对域名、IP进行集中管理, 包括外部接入、主机连接、数据库连接等。同时, 在BOSS系统应急容灾切换过程中, 不需要直接修改每个应用的连接配置, 只需在DNS中修改域名和IP的对应关系, 从而避免了应用的重启, 使应急容灾切换时长大大缩短。
2.1 跨数据中心DNS集群搭建
利用4台硬件负载均衡器, 构建跨数据中心的DNS集群, 基于VRRP协议, 实现实时切换和BOSS系统连接关系的集中化管理维护, 在共青团和开发区中心分别部署2台负载均衡设备。其中, 开发区的2台负载均衡和共青団的其中1台负载均衡形成一个VRRP组, VRRP组的虚地址是提供DNS服务的IP地址, 该跨站点集群, 作为主用DNS;另一台共青团中心的作为单独的备用DNS服务器。如图2所示。
DNS设备集群通过浮动IP提供DNS解析服务。平时浮动IP位于开发区中心主用设备。当开发区中心主用设备出现故障时, 服务由开发区中心另一台备用设备接管;当开发区中心两台设备不可用或中心网络无法访问时, 共青团中心的备用设备接管服务, 从而实现了跨中心的负载均衡冗余。
发生故障时, 先切换到本中心备用设备;如果数据中心故障, 就切换到另一中心的备用设备, 切换过程中IP保持不变, 使客户端应用无感知。备用DNS可提供极端情况下的应急, 也可以手工修改IP代替主用集群工作。
实际测试证明:
(1) 切换测试中, 浮动IP切换时间在4秒内;
(2) 切换后, DNS服务正常;
(3) 随切换测试进行压力测试, 业务未受影响。如图3所示。
2.2 应用进行适应性改造
结合构建跨中心DNS集群, 进行BOSS系统适应性改造, 实现内、外部链接关系由IP方式修改为域名方式。
(1) BOSS系统内部连接关系梳理
进行BOSS系统内部连接关系梳理, 共涉及302个改造点, 见表1.
(2) BOSS系统的配置修改
需要对BOSS系统主机进行配置修改, 包括对主机配置、解析顺序等进行变更。
对UNIX主机, 需要配置/etc/resolv.conf和/etc/netsvc.conf文件;对LINUX主机, 需要配置/etc/resolv.conf和/etc/nsswitch.conf文件。以AIX主机为例:
修改/etc/netsvc.conf时, 需注意=号旁边需留空格
nameserver后面配置的IP为DNS集群VIP。所有客户端2个nameserver配置的顺序为先主后备。
【配置文件权限修改】
用以下命令修改刚才配置的DNS配置文件的权限, 否则会导致数据库联接异常。
(3) 对BOSS应用的改造和修改
对应用的修改和适应性改造部分, 主要包括:
1) 修改web服务器jdbc配置文件, 将IP访问改为域名访问;
2) 修改交易中间件和应用服务器等主机上的配置文件tnsnames.ora, 将其中通过IP方式访问数据库的部分修改为通过域名访问;
3) 修改应用内部相关配置文件如*.conf, *.xml等, 将其中通过IP访问数据库改为域名方式;
4) 对应用进行适应性改造, 支持自动重连技术, 即:在因各种故障下连接失效的情况下, 能支持一定间隔后的再次尝试连接。
另外, 应用实现了自动重连后, 可实现在DNS服务器上IP变更后应用无需重启, 从而大大简化维护复杂度, 有效节省容灾切换时间。当然, 需要梳理出不支持自动重连的应用和中间件, 然后逐一改造。
2.3 本方案技术关键点
主要是跨数据中心二层网络打通和心跳技术考虑。首先, 由于是跨站点集群, 要求能够使用如网络心跳等可以远距离连接的心跳技术, 而不能使用串口等心跳。其次, 多节点集群考虑。考虑到跨中心网络、传输等的可靠性低于本地连接, 因此应使用至少3个节点, 这样既保障本地热备可靠性, 又能实现跨中心切换。第三, 需要跨中心二层网络打通。因为一般网络心跳技术要求集群内设备在同一子网, 如图4所示。
2.4 脑裂现象考虑
由于集群跨数据中心, 因此需要采取手段以防止集群出现脑裂现象。本方案通过几种方式进行规避:一是将DNS集群部署在单独的VLAN子网中, 对外通过路由访问。二是在网络设备层, 通过技术手段 (如优先级设置) 保证网关唯一。当发生类似跨中心间网络中断故障、出现“双主”情况时, 因为整个网络路由网关唯一, 所以保证了只会有一个站点的DNS服务器仍能对外提供服务。三是通过构建多中心互联环状全冗余架构, 实现网络稳定性, 避免脑裂现象, 如图5所示。
3 运行效果
通过构建跨数据中心DNS集群, 在BOSS系统运维方面效果显著。
(1) 实现跨数据中心的DNS无缝切换机制
基于VRRP协议构建的跨数据中心DNS集群, 实现了数据中心内部和跨数据中心的DNS自动保护机制, 无需客户端做任何配置修改, 且零时延。
而传统DNS方案, 由于缺乏跨数据中心保护功能且无缓存功能, 在主用DNS故障下链接备用DNS时, 每次都要尝试链接主用DNS, 导致等待超时, 短链接效率很低, 且配置维护复杂。
本方案支持跨数据中心实时切换, 全自动、效率高, 且基于硬件, 时延几乎为零, 维护工作量低。
(2) 实现BOSS内、外部连接关系的集中简单管理
通过将BOSS系统内、外部连接关系改造为DNS方式集中管理, 实现了系统变更、设备入网等场景下的“一点维护、全局生效”功能, 解决了庞大系统架构下的运维复杂难题;在进行配置变更时, 需要维护的主机、应用、中间件等变更点大幅减少。如图6所示。
(3) 实现应急容灾系统的快速接管和切换
BOSS系统通过DNS集群建设, 结合应用适应性改造, 在应急容灾切换场景下大幅缩短了容灾切换时长, 简化了操作步骤。
1) 无需应用重新启动:可通过DNS集中切换IP, 新链接直接连到容灾端;
2) 无需应用修改配置:DNS集群中集中修改IP, 无需专门在每个主机上修改;
3) 容灾切换时长大幅缩短:由于无需上述步骤, 由原来的22分钟缩短到5分钟之内。如图7所示。
4 结束语
某运营商通过构建跨数据中心的DNS集群, 实现了BOSS系统内、外部连接关系的简单集中化管理, 目前已将关键主机、数据库、前台接入等纳入, 下一步计划将全部连接关系均纳入该系统;同时实现了跨数据中心基于VRRP协议的高可用机制, 做到了故障情况下的几乎零时间切换、零人工干预。
通过本文方案, 实现了BOSS系统故障下容灾切换恢复时间的大幅度缩短, 避免了传统IP模式下需要修改IP、重启服务的弊端, 容灾切换时间由22分钟降到了5分钟之内, 大大降低了对客户服务的影响, 提高了系统的可维护能力, 对系统做到了可控。
本文方案适合所有省份的BOSS系统, 建议购买硬件的DNS服务器至少4台, 3台集群为主DNS, 1台为备DNS。
参考文献
[1]路海燕.容灾系统建设中的主备中心切换问题探讨.中国传媒科技, 2011 (09)
[2]刘跃, 宋兵.信息系统异地容灾技术探讨.中国传媒科技, 2012 (23)
[3]潘亮, 宫钦.云计算技术在网管系统容灾中的应用.山东通信技术, 2012 (03)
[4]中原.数据容灾技术的应用与实现.互联网天地, 2012 (10)
[5]万锋.江西移动基于远程扩展集群技术的高效容灾体系建设.电信技术, 2010 (02)
[6]郭亚杰, 李华, 敖腾河, 吴承勇, 夏兴行.DNS服务器解析性能测试方案设计.广西大学学报 (自然科学版) , 2011 (S1)
[7]陈启锋.Redhat9.0Linux操作系统DNS服务器搭建方法.科技风, 2012 (18)
DNS系统 篇9
关键词：DNS,Internet,WindowsServer2003
0 引言
域名是internet上用来寻找网站所用的名字, 是internet上的重要标识, 相当于主机的门牌号码。每一台主机都对应一个IP地址, 每一个IP地址由一连串的数字组成, 如101.25.11.34。人们为了方便记忆就用域名来代替这些数字来寻找主机, 如mydomain.com。每一个域名与IP地址是一一对应的, 人们输入域名, 再由域名服务器 (DNS) 解析成IP地址, 从而找到相应的网站。每一个网址和EMAIL都要用到域名。在英文国际域名中, 域名可以英文字母和阿拉伯数字以及横杠"-"组成, 最长可达67个字符 (包括后缀) , 并且字母的大小写没有区别, 每个层次最长不能超过22个字母。在国内域名中, 三级域名长度不得超过20个字。DNS在互联网的作用是:把域名转换成为网络可以识别的ip地址.比如:我们上网时输入的www.163.com会自动转换成为202.108.42.72。这样访问网站时就可以不用记住容易混淆的IP地址, 只需要记住形象易记的域名就可以了。
在Windows Server2003中就可以安装DNS服务器, 配置Inte rne t访问。首先需要为该服务器分配一个静态IP地址。DNS服务器不应该使用动态分配的IP地址, 因为地址的动态更改会使客户端与DNS服务器失去联系。
1 配置TCP/IP
在桌面上选择网上邻居, 右键单击鼠标选择属性, 出现网络连接的界面, 然后单击本地连接。单击属性, 单击Internet协议 (TCP/IP) , 然后单击属性, 单击常规选项卡。单击使用下面的IP地址, 然后在相应的框中键入IP地址、子网掩码和默认网关地址 (具体由ISP服务商提供) 。单击高级, 然后单击DNS选项卡。单击附加主要的和连接特定的DNS后缀。单击以选中附加主DNS后缀的父后缀复选框。单击以选中在DNS中注册此连接的地址复选框。
2 安装MicrosoftDNS服务器
打开控制面板, 然后单击添加或删除程序, 选择添加或删除Window s组件。在组件列表中, 单击网络服务 (但不要选中或清除该复选框) , 然后单击详细信息。单击以选中域名系统 (DNS) 复选框, 然后单击确定。单击下一步。得到提示后, 将Windows Server2003系统安装盘插入计算机的CD-ROM或DVD-ROM驱动器。安装完成时, 在完成Windows组件向导页上单击完成。单击关闭关闭添加或删除程序窗口。
3 配置DNS服务器
3.1 收集信息:
在真正开始配置DNS服务器前, 您需要一些基本信息。其中的一些信息必须经过Internic批准才能用于Internet, 但如果服务器仅配置为内部使用, 可以决定使用的名称和IP地址。需要:域名 (必须由Internic批准) , 希望提供名称解析的每台服务器的IP地址。上一步中的每台服务器的主机名。注意:上一步中的服务器可以是邮件服务器、所有公用访问服务器、FTP服务器、WWW服务器等等。例:
域名:
3.2 创建DNS服务器:
使用以上信息, 通过以下步骤配置Micros oftDNS服务器:单击“开始”按钮, 指向“程序”, 指向“管理工具”, 然后单击“DNS管理器”。在“DNS”菜单上, 单击“新建服务器”。在“添加DNS服务器”对话框中, 键入DNS服务器的IP地址 (在文中示例为192.168.1.4) , 然后单击“确定”。在“DNS管理器”中, 用鼠标右键单击“DNS服务器”, 然后单击“更新服务器数据文件”。
3.3创建反向搜索区域:
当DDNNSS服务器有计算机的IIPP地址时, 某些应用程序对DNS服务器使用反向查询, 以查找主机的主机名。您必须配置反向搜索区域来提供这一功能。反向搜索区域在网络中不是必须的, 但推荐进行配置。如果没有配置反向搜索区域, 在DNS服务器上运行的NSLOOKUP将会失败。
按照以下步骤创建反向搜索区域:在DNS管理器中, 用鼠标右键单击“DNS服务器”, 然后单击“新建区域”。在“创建新区域”对话框中单击“主要”, 然后单击“下一步”。“区域名称”来自IP网络地址。在示例中, “区域名称”是“58.168.192.in-addr.arpa”。键入反向搜索区域名 (IP地址中最不重要的部分, 一直到地址中最重要的部分) 。例如:如果您的网络ID是:则反向区域为:
当键入反向搜索区域名后, 按下“Tab”键, 反向搜索区域文件名将会使用步骤 (3) 中的区域名并以扩展名“.dns” (没有引号) 自动填入。单击“下一步”, 然后单击“完成”。
3.4 创建正向搜索区域:
在DNS管理器中, 用鼠标右键单击“DNS服务器”, 然后单击“新建区域”。单击“主要区域”, 然后单击“下一步”。键入DNS域的“区域名称”。这是一个在Internic注册的域名 (在示例中为
3.5 在正向搜索区域中添加主机记录:
DNS服务器的A记录应该已经自动创建。但是, DNS管理器不会自动创建DNS服务器反向区域中的PTR记录。对此进行修改的最简单方法如下:用鼠标右键单击DNS服务器的“A记录”, 然后单击“删除记录”。在确认对话框中单击“是”。用鼠标右键单击正向区域,
为验证PTR记录已经成功创建, 用鼠标右键单击反向搜索区58.168.192.in-addr.arpa, 然后单击“刷新”。
3.6 配置其它记录类型:
DNS服务器支持几种不同的记录类型。其中包括, 但不局限于:A、CNAME、HINFO、MX、NS和SOA。有关这些记录类型和其它记录类型的详细信息, 请参见上文提到的DNS白皮书。
【DNS系统】推荐阅读：
直流系统管理信息系统08-28
ubuntu系统怎么修改系统语言？10-21
医院信息系统灾备系统07-21
税务系统灾备系统设计10-08
强行卸载文件系统Windows系统06-04
生态系统系统的稳定性08-31
播控系统中存储子系统07-14
JQ正本-系统简介《居民健康档案系统》05-21
论ERP系统对会计信息系统的影响05-21