CN102035809A - 缓存中毒的防护方法和防护设备及防护系统 - Google Patents
缓存中毒的防护方法和防护设备及防护系统 Download PDFInfo
- Publication number
- CN102035809A CN102035809A CN2009101799152A CN200910179915A CN102035809A CN 102035809 A CN102035809 A CN 102035809A CN 2009101799152 A CN2009101799152 A CN 2009101799152A CN 200910179915 A CN200910179915 A CN 200910179915A CN 102035809 A CN102035809 A CN 102035809A
- Authority
- CN
- China
- Prior art keywords
- domain name
- inquiry
- name
- address
- response message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 32
- 239000002574 poison Substances 0.000 title abstract description 5
- 231100000614 poison Toxicity 0.000 title abstract description 5
- 230000004044 response Effects 0.000 claims abstract description 158
- 238000013507 mapping Methods 0.000 claims description 106
- 231100000572 poisoning Toxicity 0.000 claims description 54
- 230000000607 poisoning effect Effects 0.000 claims description 54
- 230000005540 biological transmission Effects 0.000 claims description 29
- 238000011835 investigation Methods 0.000 claims description 11
- 230000004048 modification Effects 0.000 claims description 3
- 238000012986 modification Methods 0.000 claims description 3
- 238000012795 verification Methods 0.000 abstract description 7
- 208000005374 Poisoning Diseases 0.000 description 52
- 239000000872 buffer Substances 0.000 description 19
- 238000012545 processing Methods 0.000 description 11
- 238000010586 diagram Methods 0.000 description 6
- 238000012797 qualification Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 238000010200 validation analysis Methods 0.000 description 3
- 241000700605 Viruses Species 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 206010011409 Cross infection Diseases 0.000 description 1
- 206010029803 Nosocomial infection Diseases 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000001524 infective effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明实施例公开了缓存中毒的防护方法和防护设备及防护系统。其中的一种缓存中毒的防护方法，包括：接收第一域名服务器发送的第一域名查询请求消息，该第一域名查询请求消息携带有第一域名信息；向第二域名服务器发送携带有第一域名的域名查询请求消息；接收第二域名服务器发送的域名查询应答消息，该域名查询应答消息携带有根据第一域名解析出的网际协议IP地址；利用至少一个第三域名服务器验证上述IP地址的可靠性；在上述可靠性验证通过后，向第一域名服务器发送携带有上述IP地址的第一域名查询应答消息。本发明实施例的技术方案能够有效可靠的防护DNS服务器缓存中毒。
Description
技术领域
本发明涉及网络安全技术领域，具体涉及缓存中毒的防护方法和防护设备及防护系统。
背景技术
随着互联网技术的深入发展，网络安全变得非常的重要。网络中的域名系统(DNS，Domain Name System)服务器主要用于进行域名解析。DNS服务器可以将用户请求解析的域名转换为对应的IP地址，也可以将用户请求解析的IP地址转换为对应的域名。
DNS服务器感染缓存中毒(cache poison)将影响整个网络的安全，所谓DNS服务器缓存中毒，主要是指该DNS服务器缓存了虚假的IP地址和域名的映射关系。
例如客户机向缓存中毒的DNS服务器发起对应网站A的域名查询，缓存中毒的DNS服务器可能返回一个虚假的IP地址，客户机若根据该虚假的IP地址进行网站A访问，可能获得一个酷似网站A界面的假界面，若用户在该假界面上进行相关操作，将泄露自己的安全信息，甚至蒙受经济损失。
若其它的DNS服务器向缓存中毒的DNS服务器请求域名查询，也可能从缓存中毒的DNS服务器获得一个虚假的IP地址，导致该DNS服务器也会感染缓存中毒。可以理解，若网络中有一个DNS服务器感染缓存中毒，网络中的其它DNS服务器可能因交叉感染而全部缓存中毒。
基于网络安全的考虑，有必要对DNS服务器进行缓存中毒防护，在现有技术中，通常是通过层三防护技术对DNS服务器进行缓存中毒防护的，但层三防护的可靠性通常比较低。
发明内容
本发明实施例提供缓存中毒的防护方法和防护设备及防护系统，能够有效可靠的防护DNS服务器缓存中毒。
为解决上述技术问题，本发明实施例提供以下技术方案：
一种缓存中毒的防护方法，包括：
接收第一域名服务器发送的第一域名查询请求消息，所述第一域名查询请求消息携带有第一域名信息；向第二域名服务器发送携带有第一域名的域名查询请求消息；接收第二域名服务器发送的域名查询应答消息，所述域名查询应答消息携带有根据第一域名解析出的网际协议IP地址；利用至少一个第三域名服务器验证所述IP地址的可靠性；在所述可靠性验证通过后，向第一域名服务器发送携带有所述IP地址的第一域名查询应答消息。
一种缓存中毒的防护方法，包括：
接收第一域名服务器发送的第一域名查询请求消息，所述第一域名查询请求消息携带有第一域名信息；向至少两个第二域名服务器发送携带有第一域名的域名查询请求消息；接收至少两个第二域名服务器发送的域名查询应答消息，所述域名查询应答消息中携带有根据第一域名解析出的IP地址；将所述至少两个第二域名服务器发送的域名查询应答消息中携带的根据第一域名解析出的IP地址进行比较；若超过设定比例的第二域名服务器发送的域名查询应答消息中携带的根据第一域名解析出的IP地址相同，向第一域名服务器发送携带有所述相同的IP地址的第一域名查询应答消息。
一种防护设备，包括：
第一接收模块，用于接收第一域名服务器发送的第一域名查询请求消息，所述第一域名查询请求消息携带有第一域名信息；第一发送模块，用于向第二域名服务器发送携带有第一域名的域名查询请求消息；第二接收模块，用于接收第二域名服务器发送的域名查询应答消息，所述域名查询应答消息携带有根据第一域名解析出的IP地址；可靠性验证模块，用于利用至少一个第三域名服务器验证所述IP地址的可靠性；第二发送模块，用于在所述可靠性验证模块的可靠性验证通过后，向第一域名服务器发送携带有所述IP地址的第一域名查询应答消息。
一种防护系统，包括：如上述实施例中的防护设备。
一种防护设备，包括：
第一接收模块，用于接收第一域名服务器发送的第一域名查询请求消息，所述第一域名查询请求消息携带有第一域名信息；第一发送模块，用于向至少两个第二域名服务器发送携带有第一域名的域名查询请求消息；第二接收模块，用于接收至少两个第二域名服务器发送的域名查询应答消息，所述域名查询应答消息携带根据第一域名解析出的IP地址；比较模块，用于将第二接收模块接收的至少两个第二域名服务器发送的域名查询应答消息中携带的根据第一域名解析出的IP地址进行比较；第二发送模块，用于在超过设定比例的第二域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址相同时，向第一域名服务器发送携带有所述相同的IP地址的第一域名查询应答消息。
一种防护系统，包括：如上述实施例中的防护设备。
由上可见，本发明实施例采用的技术方案具有如下有益效果：
本发明实施例利用至少两个DNS服务器协助解析第一域名服务器请求解析的域名，并利用至少两个DNS服务器反馈的域名解析结果，相互验证域名解析结果的可靠性，在可靠性验证通过后，再向第一域名服务器反馈域名解析结果，使得第一域名服务器能够获得真实的域名和IP地址的映射关系，进而实现有效的防护第一域名服务器感染缓存中毒；由于是在应用层进行第一域名服务器的缓存中毒保护，实现方式十分的可靠。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例一提供的一种缓存中毒的防护方法流程图；
图2是本发明实施例二提供的一种缓存中毒的防护方法流程图；
图3是本发明实施例三提供的一种缓存中毒的防护方法流程图；
图4是本发明实施例四提供的一种缓存中毒的防护方法流程图；
图5-a是本发明实施例五提供的一种防护设备示意图；
图5-b是本发明实施例五提供的一种可靠性验证模块示意图；
图5-c是本发明实施例五提供的另一种可靠性验证模块示意图；
图6是本发明实施例六提供的一种防护设备示意图；
图7是本发明实施例七提供的一种防护系统示意图；
图8是本发明实施例八提供的一种防护系统示意图。
具体实施方式
本发明实施例提供一种缓存中毒的防护方法和防护设备及防护系统，能够有效可靠的防护DNS服务器缓存中毒。
为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而非全部实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
其中，为描述方便，本发明实施例中域名系统服务器(DNS服务器)可简称为域名服务器。
实施例一、
参见图1、本发明实施例一的一种缓存中毒的防护方法，可以包括：
110、接收第一域名服务器发送的第一域名查询请求消息，该第一域名查询请求消息携带有第一域名信息。
其中，例如若第一域名服务器当前没有缓存第一域名和对应IP地址的映射关系，第一域名服务器就无法直接解析出第一域名的IP地址，此时第一域名服务器可以发送携带有请求解析的第一域名的域名查询请求消息，以请求其它DNS服务器协助解析第一域名的IP地址。
120、向第二域名服务器发送携带有第一域名的域名查询请求消息。
在实际应用中，例如可以直接向第二域名服务器发送第一域名查询请求消息；也可以先对第一域名查询请求消息携带的部分参数进行修改，然后再向第二域名服务器发送修改了参数的携带有第一域名的第一域名查询请求消息；当然也可以选择重新生成一个携带第一域名的域名查询请求消息，然后向第二域名服务器发送重新生成的携带有第一域名的域名查询请求消息。并且，上述的第二域名服务器可以是一个DNS服务器，也可以是多个DNS服务器。
130、接收第二域名服务器发送的域名查询应答消息，该域名查询应答消息携带有根据第一域名解析出的IP地址。
其中，第二域名服务器在接收到携带第一域名的域名查询请求消息后，可以解析第一域名的IP地址，并回复携带有其根据第一域名解析出的IP地址的域名查询应答消息。
140、利用至少一个第三域名服务器验证上述IP地址的可靠性，若可靠性验证通过，执行步骤150，若可靠性验证未通过，执行步骤160。
在一种应用场景下，例如可以向至少一个第三域名服务器发送携带上述IP地址的域名反查请求消息，根据至少一个第三域名服务器反馈的根据上述IP地址解析出的域名，验证第二域名服务器反馈的上述IP地址的可靠性；其中，验证方式具体可以是，将第三域名服务器反馈的根据上述IP地址解析出的域名和第一域名进行比较，若超过设定比例(设定比例例如可以是90％、100％或根据需要设定的其它值，当然可以理解的是，设定的比例越高，可靠性验证结果的准确度也就越高。)的第三域名服务器反馈的根据上述IP地址解析出的域名和第一域名相同，可以确定上述IP地址的可靠性验证通过，若超过设定比例的第三域名服务器反馈的根据上述IP地址解析出的域名和第一域名不相同，可以确定上述IP地址的可靠性验证未通过。
在另一种应用场景下，也可以选择向至少一个第三域名服务器发送携带第一域名的域名查询请求消息，根据至少一个第三域名服务器反馈的根据第一域名解析出的IP地址，验证第二域名服务器反馈的IP地址的可靠性，其中，验证方式具体可以是，将上述至少一个第三域名服务器反馈的根据第一域名解析出的IP地址和第二域名服务器反馈的根据第一域名解析出的IP地址进行比较，若超过设定比例的第三域名服务器反馈的根据第一域名解析出的IP地址和第二域名服务器反馈的根据第一域名解析出的IP地址相同，确定上述可靠性验证通过，若超过设定比例的第三域名服务器反馈的根据第一域名解析出的IP地址和第二域名服务器反馈的根据第一域名解析出的IP地址不相同，确定上述可靠性验证未通过。其中，可以选择在向第二域名服务器发送携带第一域名的域名查询请求消息的同时，向第三域名服务器发送携带第一域名的域名查询请求消息，当然也可以选择先向第二域名服务器发送或先向第三域名服务器发送。
当然也可以通过其它方式，利用至少一个第三域名服务器验证上述IP地址的可靠性，此处不做限定。
150、在上述可靠性验证通过后，向第一域名服务器发送携带有上述IP地址的第一域名查询应答消息。
其中，第一域名服务器在接收到第一域名查询应答消息后，例如可以刷新其缓存，记录第一域名和IP地址的映射关系。
160、若上述可靠性验证未通过，进行告警处理。
在实际应用中，若上述可靠性验证未通过，说明请求协助解析第一域名的其它服务器中的部分或全部可能已经缓存中毒，此时可以进行告警处理，例如可以发出告警日志、向网管中心通报情况等等。
需要说明的是，上述技术方案可以在防护设备上具体实施，该防护设备可以直接位于第一域名服务器上，也可以是与第一域名服务器连接的防火墙设备、网关或其它设备，本发明不做限定。
由上述技术方案可以看出，本发明实施例利用至少两个DNS服务器协助解析第一域名服务器请求解析的域名，并利用至少两个DNS服务器反馈的域名解析结果，相互验证域名解析结果的可靠性，在可靠性验证通过后，再向第一域名服务器反馈域名解析结果，使得第一域名服务器能够获得真实的域名和IP地址的映射关系，进而实现有效的防护第一域名服务器感染缓存中毒；由于是在应用层进行第一域名服务器的缓存中毒保护，实现方式十分的可靠。
实施例二、
为更好的理解本发明的技术方案，下面通过更为具体的实施例对本发明实施例的上述技术方案做进一步详细的描述。
其中，本实施例以DNS服务器(DNS1)向其它DNS服务器请求协助解析域名，DNS1的防护设备SD1利用其它至少两个DNS服务器反馈的IP地址，对解析结果的可靠性进行验证为例，进行举例说明。
参见图2、本发明实施例二的一种缓存中毒的防护方法，可以包括：
201、客户机A1向DNS1发送域名查询请求消息，该域名查询请求消息携带请求解析的域名da1。
在实际应用中，客户机A1在需要获得例如域名da1对应的IP地址时，客户机A1例如可以向DNS1发送携带域名da1的域名查询请求消息，请求DNS1解析域名da1对应的IP地址。
其中，客户机A1例如可以是计算机、便携机、手机、智能终端、车载设备、电话等，或其它的终端设备。
202、DNS1发送域名查询请求消息，其中，该域名查询请求消息携带请求解析的域名da1。
在一种应用场景下，DNS1可以接收上述客户机A1发送的域名查询请求消息，并在自身缓存中进行查找，以求解析域名da1对应的IP地址。
本实施例以DNS1自身没有缓存域名da1和IP地址的映射关系为例，此时DNS1可以进一步向其它DNS服务器发送携带域名da1的域名查询请求消息，请求其它域名服务器协助解析出域名da1对应的IP地址。
203、防护设备SD1接收DNS1发送的上述域名查询请求消息，向其它至少两个域名服务器发送域名查询请求消息，该域名查询请求消息携带请求解析的域名da1信息。
在实际应用中，防护设备SD1可以是DNS1中的一个功能模块，也可以是与DNS1连接的防火墙设备、网关或其它设备，本发明不做限定。
在一种应用场景下，防护设备SD1可以接收DNS1发送的上述域名查询请求消息，并可以向其它至少两个域名服务器发送携带有请求解析的域名da1的域名查询请求消息。
其中，防护设备SD1可以选择同时向其它至少两个域名服务器发送携带有请求解析的域名da1的域名查询请求消息，也可以选择分时向其它至少两个域名服务器发送携带有请求解析的域名da1的域名查询请求消息。
本实施例以防护设备SD1向DNS2和DNS3发送携带域名da1的域名查询请求消息，请求DNS2和DNS3协助解析出域名da1对应的IP地址为例，进行进一步的说明。
具体的，DNS2例如可以是主用DNS服务器(或权威DNS服务器)、DNS3例如可以是备用DNS服务器。
在实际应用中，域名查询请求消息和域名查询响应消息中还可以携带有端口号(或其它端口标识)、以及与该域名查询请求对应的应用层ID，其中，应用层ID主要用于标识域名查询请求和应答。
进一步的，为防止被攻击者恶意猜测，防护设备SD1可以先按照预置的某种策略，修改来自DNS1的域名查询请求消息的应用层ID和/或端口号；向DNS2和DNS3发送上述修改了应用层ID和/或端口号的域名查询请求消息。
其中，防护设备SD1当然也可以向DNS2发送上述修改了应用层ID和/或端口号的域名查询请求消息；而向DNS3转发来自DNS1的域名查询请求消息(即没有修改应用层ID和/或端口号)，或者也可以重新生成携带域名da1的域名查询请求消息，并向DNS3发送。
防护设备SD1例如可以采用预置的多种随机数生成算法，生成随机的应用层ID和/或端口号，以尽可能避免被攻击者暴力猜测到。
在实际应用中，防护设备SD1可以建立会话表，并可以在会话表中记录上述域名查询请求消息携带的初始的应用层ID和修改后的应用层ID，以及初始的端口号和修改后的端口号。后续向DNS1回复域名查询应答消息时，需要在该域名查询应答消息中携带上述初始的应用层ID和初始的端口号。
为便于描述，下面以来自DNS1的域名查询请求消息携带的初始的应用层ID为ID1、初始的端口号为Port1；防护设备SD1修改后的应用层ID为ID2，修改后的端口号为Port2为例。防护设备SD1在会话表中关联记录ID1和ID2，Port1和Port2。
204、防护设备SD1分别接收DNS2和DNS3发送的域名查询应答消息，该域名查询应答消息携带根据域名da1解析出的IP地址。
在一种应用场景下，DNS2和DNS3在接收到防护设备SD1发送的携带域名da1的域名查询请求消息后，可以根据域名da1在其自身的缓存中(或向其它DNS服务器)查询，以解析出域名da1的IP地址；DNS2和DNS3在解析出域名da1的IP地址后，可以分别向防护设备SD1发送携带根据域名da1解析出的IP地址的域名查询应答消息。
根据协议规定，DNS2和DNS3回复的域名查询应答消息携带的应用层ID和端口号，需要与之前对应接收到的防护设备SD1发送的域名查询请求消息携带的应用层ID和端口号相同。
205、防护设备SD1确认接收到的域名查询应答消息携带的应用层ID和端口号是否真实，若真实，则执行步骤206；若不真实；则执行步骤209。
在一种应用场景下，若防护设备SD1没有修改来自DNS1的域名查询请求消息携带的初始的应用层ID和端口号(即防护设备SD1向DNS2和DNS3发送的域名查询请求消息携带的应用层ID为ID1、端口号为Port1)，防护设备SD1可以检测对应接收到的域名查询应答消息携带的应用层ID是否为ID1、端口号是否为Port1，若检测出对应接收到的域名查询应答消息携带的应用层ID不为ID1，和/或端口号不为Port1，则表明该域名查询应答消息携带的应用层ID和/或端口号不真实(此时可以认为，该域名查询应答消息可能来自被感染病毒的DNS2和/或DNS3，也可能是攻击者仿冒发送的)，可以执行步骤209；若检测出对应接收到的域名查询应答消息携带的应用层ID为ID1、端口号为Port1，则表明该域名查询应答消息携带的应用层ID和端口号真实，防护设备SD1可以执行步骤206。
类似的，若防护设备SD1修改了来自DNS1的域名查询请求消息携带的初始的应用层ID和端口号(即防护设备SD1向DNS2和DNS3发送的域名查询请求消息携带的应用层ID为ID2、端口号为Port2)，防护设备SD1可以检测对应接收到的域名查询应答消息携带的应用层ID是否为ID2、端口号是否为Port2，若检测出对应接收到的域名查询应答消息携带的应用层ID不为ID2、和/或端口号不为Port2，则表明该域名查询应答消息携带的应用层ID和/或端口号不真实(此时可以认为，该域名查询应答消息可能来自感染病毒的DNS2和/或DNS3，也可能是攻击者仿冒发送的)，可以执行步骤209；若检测出对应接收到的域名查询应答消息携带的应用层ID为ID2、端口号为Port2，则表明该域名查询应答消息携带的应用层ID和端口号真实，防护设备SD1可以执行步骤206。
可以看出，防护设备SD1通过对域名查询应答消息携带的应用层ID和端口号的真实性进行检测确认，可以比较有效的过滤攻击者仿冒的域名查询应答消息，有利于提高安全性。
206、防护设备SD1比较DNS2和DNS3发送的域名查询应答消息携带的根据域名da1解析出的IP地址是否相同，若相同，则执行步骤207、若不同，则执行步骤209。
可以理解，若比较出分别来自DNS2和DNS3的域名查询应答消息携带的根据域名da1解析出的IP地址相同，表明该IP地址是比较可靠的，该IP地址的可靠性验证通过；若比较出分别来自DNS2和DNS3的域名查询应答消息携带的根据域名da1解析出的IP地址不同，表明DNS2和/或DNS3很可能已经缓存中毒，其已经缓存了虚假的域名da1和IP地址的映射关系，该IP地址是不可靠的，该IP地址的可靠性验证未通过。
可以理解，若防护设备SD1向多个DNS服务器发送携带请求解析的域名da1的域名查询请求消息，则可以接收来自多个DNS服务器的携带有根据域名da1解析出的IP地址的域名查询应答消息，此时防护设备SD1可以将多个DNS服务器反馈的根据域名da1解析出的IP地址一起进行比较，若超过设定比例的DNS服务器反馈的根据域名da1解析出的IP地址相同，此时可以认为，该相同的IP地址比较可靠，该IP地址的可靠性验证通过，执行步骤207；若超过设定比例的DNS服务器反馈的根据域名da1解析出的IP地址不全相同，此时可以认为，DNS服务器反馈根据域名da1解析出的IP地址的可靠性验证未通过，执行步骤209。
举例来说，例如防护设备SD1向其它10个DNS服务器发送携带请求解析的域名da1的域名查询请求消息，并接收到来自上述10个DNS服务器发送的携带有根据域名da1解析出的IP地址的域名查询应答消息，例如设定相同比例为80％，此时若超过80％的DNS服务器(即8个)反馈的根据域名da1解析出的IP地址相同，此时可以认为，该相同的IP地址比较可靠，该IP地址的可靠性验证通过，可以执行步骤207；反之，若超过80％的DNS服务器反馈的根据域名da1解析出的IP地址不全相同，此时可以认为，各个DNS服务器反馈的根据域名da1解析出的IP地址的可靠性验证未通过，执行步骤209。
207、防护设备SD1向DNS1发送的域名查询应答消息，该域名查询应答消息携带上述根据域名da1解析出的IP地址。
在实际应用中，若DNS2和DNS3回复的域名查询应答消息携带的应用层ID为ID2，且端口号为Port2，防护设备SD1可以先根据会话表中的相应记录，修改DNS2或DNS3回复的域名查询应答消息携带的应用层ID和端口号，即将DNS2或DNS3回复的域名查询应答消息携带的应用层ID修改为ID1，端口号修改为Port1；然后向DNS1发送上述修改了应用层ID和端口号的域名查询应答消息。
208、DNS1向客户机A1发送域名查询应答消息，该域名查询应答消息携带上述根据域名da1解析出的IP地址。
其中，DNS1可以根据反馈的域名查询应答消息携带上述根据域名da1解析出的IP地址，刷新缓存，即在缓存中记录域名da1和IP地址的映射关系。
DNS1可以向客户机A1对应的发送携带根据域名da1解析出的IP地址的域名查询应答消息。客户机A1则可以根据DNS1反馈的根据域名da1解析出的IP地址，进行相应的访问。
由上可以看出，防护设备SD1利用至少两个DNS服务器反馈的域名解析结果，相互验证域名解析结果的可靠性，DNS1能够通过防护设备SD1获得真实的域名和IP地址的映射关系，进而实现有效的防护DNS1感染缓存中毒。
209、防护设备SD1通知DNS1域名查询失败，并进行告警处理。
在实际应用中，防护设备SD1若发现DNS2和/或DNS3可能缓存中毒，防护设备SD1可以通知DNS1域名查询失败，并可以发出告警日志、向网管中心通报情况、丢弃DNS2和DNS3发送的域名查询应答消息等。
DNS1可以进一步通知客户机A1域名查询失败，客户机A1可以重新向其它的DNS服务器请求解析域名da1。
由上可见，本实施例中，防护设备利用至少两个DNS服务器协助解析DNS1请求解析的域名，并利用至少两个DNS服务器反馈的域名解析结果，相互验证域名解析结果的可靠性；在可靠性验证通过后，防护设备再向DNS1反馈域名解析结果，使得DNS1能够获得真实的域名和IP地址的映射关系，进而实现有效的防护DNS1感染缓存中毒。
进一步的，防护设备修改来自DNS1的域名查询请求消息携带的应用层ID和端口号，并对接收到的域名查询应答消息携带的应用层ID和端口号进行真实性确认，能够有效的过滤掉攻击者仿冒的域名查询应答消息，有利于进一步提高网络的安全性；防护设备在应用层进行DNS1缓存中毒保护，实现方式十分的可靠。
实施例三、
参见图3，本发明实施例三的一种缓存中毒的防护方法，可以包括：
310、接收第一域名服务器发送的第一域名查询请求消息，该第一域名查询请求消息携带有第一域名信息。
其中，例如若第一域名服务器当前没有缓存第一域名和对应IP地址的映射关系，第一域名服务器就无法直接解析出第一域名的IP地址，此时第一域名服务器可以发送携带请求解析的第一域名的域名查询请求消息，以请求其它DNS服务器协助解析第一域名的IP地址。
320、向至少两个第二域名服务器发送携带有第一域名的域名查询请求消息。
在实际应用中，例如可以直接向第二域名服务器发送第一域名查询请求消息；也可以先对第一域名查询请求消息携带的部分参数进行修改，然后再向至少两个第二域名服务器发送修改了参数的携带第一域名的第一域名查询请求消息；当然也可以选择重新生成一个携带第一域名的域名查询请求消息，然后向至少两个第二域名服务器发送重新生成的携带第一域名的域名查询请求消息。
其中，可以选择同时向各个第二域名服务器发送携带第一域名的域名查询请求消息，也可以选择分时向各个第二域名服务器发送携带第一域名的域名查询请求消息。
330、接收至少两个第二域名服务器发送的域名查询应答消息，该域名查询应答消息携带根据第一域名解析出的IP地址。
340、将上述至少两个第二域名服务器发送的域名查询应答消息中携带的根据第一域名解析出的IP地址进行比较。
350、若超过设定比例的第二域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址相同，向第一域名服务器发送携带有上述相同的IP地址的第一域名查询应答消息。
进一步的，若超过设定比例的第二域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址不全相同，进行告警处理。
由上述技术方案可以看出，本发明实施例利用至少两个DNS服务器协助解析第一域名服务器请求解析的域名，并利用至少两个DNS服务器反馈的域名解析结果，相互验证域名解析结果的可靠性，在可靠性验证通过后，再向第一域名服务器反馈域名解析结果，使得第一域名服务器能够获得真实的域名和IP地址的映射关系，进而实现有效的防护第一域名服务器感染缓存中毒；由于是在应用层进行第一域名服务器的缓存中毒保护，实现方式十分的可靠。
实施例四、
为更好的理解本发明的技术方案，下面通过更为具体的实施例对本发明实施例的上述技术方案做进一步详细的描述。
其中，本实施例以DNS服务器(DNS1)向其它DNS服务器请求协助解析域名，DNS1的防护设备SD1利用其它至少两个DNS服务器反馈的IP地址和域名，对解析结果的可靠性进行验证为例，进行举例说明。
参见图4、本发明实施例四的一种缓存中毒的防护方法，可以包括：
401、客户机A1向DNS1发送域名查询请求消息，该域名查询请求消息携带请求解析的域名da1。
在实际应用中，客户机A1在需要获得例如域名da1对应的IP地址时，客户机A1例如可以向DNS1发送携带域名da1的域名查询请求消息，请求DNS1解析域名da1对应的IP地址。
402、DNS1发送域名查询请求消息，其中，该域名查询请求消息携带请求解析的域名da1。
在一种应用场景下，DNS1可以接收上述客户机A1发送的域名查询请求消息，并在自身缓存中进行查找，以求解析域名da1对应的IP地址。
本实施例以DNS1自身没有缓存域名da1和IP地址的映射关系为例，此时DNS1可以进一步向其它DNS服务器发送携带域名da1的域名查询请求消息，请求其它域名服务器协助解析出域名da1对应的IP地址。
403、防护设备SD1接收DNS1发送的域名查询请求消息，向域名服务器DNS2发送域名查询请求消息，其中携带请求解析的域名da1。
在实际应用中，防护设备SD1可以是DNS1中的一个功能模块，也可以是与DNS1连接的防火墙设备、网关或其它设备，本发明不做限定。
在一种应用场景下，防护设备SD1可以接收DNS1发送的上述域名查询请求消息，并可以先向其它至少一个域名服务器发送携带请求解析的域名da1的域名查询请求消息。
本实施例以防护设备SD1先向DNS2发送携带域名da1的域名查询请求消息，请求DNS2协助解析域名da1的IP地址为例，进一步的说明。
具体的，DNS2例如可以是主用DNS服务器(或权威DNS服务器)。
进一步的，为防止被攻击者恶意猜测，防护设备SD1可以先按照预置的某种策略，修改来自DNS1的域名查询请求消息的应用层ID和/或端口号；然后向DNS2发送修改了应用层ID和/或端口号的域名查询请求消息。
防护设备SD1例如可以采用预置的多种随机数生成算法，生成随机的应用层ID和/或端口号，以尽可能避免被攻击者暴力猜测到。
在实际应用中，防护设备SD1可以建立会话表，并可以在会话表中记录上述域名查询请求消息携带的初始的应用层ID和修改后的应用层ID，以及初始的端口号和修改后的端口号。
为便于描述，下面以来自DNS1的域名查询请求消息携带的初始的应用层ID为ID1、初始的端口号为Port1；防护设备SD1修改后的应用层ID为ID2，修改后的端口号为Port2为例。防护设备SD1在会话表中关联记录ID1和ID2，Port1和Port2。
404、防护设备SD1接收DNS2发送的域名查询应答消息，该域名查询应答消息携带根据域名da1解析出的IP地址。
在一种应用场景下，DNS2在接收到防护设备SD1发送的上述携带域名da1的域名查询请求消息后，可以根据域名da1在其自身的缓存中(或向其它DNS服务器)查询，以解析出域名da1的IP地址；在解析出域名da1的IP地址(为便于描述，下面将DNS2解析的域名da1的IP地址表示为IPa2)后，DNS2可以向防护设备SD1发送域名查询应答消息，该域名查询应答消息携带根据域名da1解析出的IP地址IPa2。
在一种应用场景下，防护设备SD1接收并解析DNS2发送的域名查询应答消息，获得其携带的根据域名da1解析出的IP地址IPa2。
405、防护设备SD1确认接收的域名查询应答消息携带的应用层ID和端口号是否真实，若真实，则执行步骤406；若不真实；则执行步骤412。
其中，防护设备SD1确认域名查询应答消息携带的应用层ID和端口号是否真实的方式，可以和实施例二步骤205中的方式相同或相似，此处不再赘述。
406、防护设备SD1向域名服务器DNS3发送域名反查请求消息，该域名反查请求消息携带请求解析的DNS2反馈的IP地址IPa2。
在一种应用场景下，防护设备SD1可以进一步利用其它至少一个DNS服务器验证DNS2反馈的IPa2的可靠性。
在实际应用中，DNS3在接收到防护设备SD1发送的携带请求解析的IP地址IPa2的域名反查请求消息后，可以根据IP地址IPa2，在其自身缓存中(或向其它DNS服务器)查询，以解析出IP地址IPa2的域名；在解析出IP地址IPa2的域名后，DNS3可以向防护设备SD1发送携带有根据的IP地址IPa2解析出的域名的域名反查应答消息。
407、防护设备SD1接收DNS3发送的域名反查应答消息，该域名反查应答消息携带根据IP地址IPa2解析出的域名。
408、防护设备SD1确认DNS3发送的域名反查应答消息携带的应用层ID和端口号是否真实，若真实，则执行步骤409；若不真实；则执行步骤412。
其中，防护设备SD1确认域名反查应答消息携带的应用层ID和端口号是否真实的方式，可以和实施例二步骤205中的方式相同或相似，此处不再赘述。
409、防护设备SD1比较DNS3发送的域名反查应答消息携带的根据IP地址IPa2解析出的域名和DNS1请求解析的域名da1是否相同，若相同，则执行步骤410、若不同，则执行步骤412。
可以理解，若比较出DNS3反馈的根据IP地址IPa2解析出的域名和DNS1请求解析的域名da1相同，表明DNS2反馈的根据域名da1解析出的IP地址是比较可靠的，该IP地址的可靠性验证通过；若比较出DNS3和DNS3反馈的根据IP地址IPa2解析出的域名和DNS1请求解析的域名da1不同，表明DNS2和/或DNS3很可能已经缓存中毒，其可能已经缓存了虚假的域名da1和IP地址的映射关系，DNS2反馈的根据域名da1解析出的IP地址是不可靠的，该IP地址的可靠性验证通过。
可以理解，若防护设备SD1向多个DNS服务器发送携带请求解析的IP地址IPa2的域名反查应答消息，则可以接收来自多个DNS服务器的携带根据IP地址IPa2解析出的域名的域名反查应答消息，此时防护设备SD1可以将多个DNS服务器反馈的携带根据IP地址IPa2解析出的域名和DNS1请求解析的域名da1一起进行比较，若超过设定比例的DNS服务器反馈的根据IP地址IPa2解析出的域名和DNS1请求解析的域名da1相同，此时可以认为，该IP地址的可靠性验证通过，执行步骤410、若超过设定比例的DNS服务器反馈的根据IP地址IPa2解析出的域名和DNS1请求解析的域名da1不同，此时可以认为，该IP地址的可靠性验证未通过，执行步骤412。
410、防护设备SD1向DNS1发送的域名查询应答消息，该域名查询应答消息携带上述根据域名da1解析出的IP地址IPa2。
411、DNS1向客户机A1发送域名查询应答消息，该域名查询应答消息携带上述根据域名da1解析出的IP地址IPa2。
其中，DNS1可以根据反馈的域名查询应答消息携带上述根据域名da1解析出的IP地址IPa2，刷新缓存，在缓存中记录域名da1和IP地址IPa2的映射关系。
DNS1可以向客户机A1对应的发送携带根据域名da1解析出的IP地址的域名查询应答消息。客户机A1则可以根据DNS1反馈的根据域名da1解析出的IP地址，进行相应的访问。
可以看出，防护设备SD1在获得至少一个DNS服务器的域名解析结果，利用其它至少一个DNS服务器验证获得的域名解析结果的可靠性，DNS1能够通过防护设备SD1获得真实的域名和IP地址的映射关系，进而实现有效的防护DNS1感染缓存中毒。
412、防护设备SD1通知DNS1域名查询应失败，并进行告警处理。
在实际应用中，防护设备SD1若发现DNS2和/或DNS3可能缓存中毒，防护设备SD1可以通知DNS1域名查询失败，并可以发出告警日志、向网管中心通报情况、丢弃DNS2和DNS3发送的消息等。
DNS1可以进一步通知客户机A1域名查询失败，客户机A1可以重新向其它的DNS服务器请求解析域名da1。
由上可见，本实施例中，防护设备利用至少一个DNS服务器协助解析第一域名服务器请求解析的域名，在获得域名解析结果后，再利用其它至少一个DNS服务器验证获得的域名解析结果的可靠性，在可靠性验证通过后，防护设备再向DNS1反馈域名解析结果，使得DNS1能够获得真实的域名和IP地址的映射关系，进而实现有效的防护DNS1感染缓存中毒。
进一步的，防护设备修改来自DNS1的域名查询请求消息携带的应用层ID和端口号，并对接收到的域名查询应答消息携带的应用层ID和端口号进行真实性确认，能够有效的过滤掉攻击者仿冒的域名查询应答消息，有利于进一步提高网络的安全性；防护设备在应用层对DNS1进行缓存中毒保护，实现方式十分的可靠。
为便于更好的实施本发明实施例的上述技术方案，本发明实施例中还提供一种防护设备。
实施例五、
参见图5-a、本发明实施例五的一种防护设备500，可以包括：第一接收模块510、第一发送模块520、第二接收模块530、可靠性验证模块540和第二发送模块550。
其中，第一接收模块510，用于接收第一域名服务器发送的第一域名查询请求消息，该第一域名查询请求消息携带有第一域名信息。
第一发送模块520，用于向第二域名服务器发送携带有第一域名的域名查询请求消息。
第二接收模块530，用于接收第二域名服务器发送的域名查询应答消息，该域名查询应答消息携带有根据第一域名解析出的IP地址。
可靠性验证模块540，用于利用至少一个第三域名服务器验证上述IP地址的可靠性。
在一种应用场景下，可靠性验证模块540可以向至少一个第三域名服务器发送携带上述IP地址的域名反查请求消息，根据至少一个第三域名服务器反馈的根据上述IP地址解析出的域名，验证第二域名服务器反馈的上述IP地址的可靠性；其中，验证方式具体可以是，将第三域名服务器反馈的根据上述IP地址解析出的域名和第一域名进行比较，若超过设定比例的第三域名服务器反馈的根据上述IP地址解析出的域名和第一域名相同，可以确定上述IP地址的可靠性验证通过，若超过设定比例的第三域名服务器反馈的根据上述IP地址解析出的域名和第一域名不相同，可以确定上述IP地址的可靠性验证未通过。
在另一种应用场景下，可靠性验证模块540可以选择向至少一个第三域名服务器发送携带第一域名的域名查询请求消息，根据至少一个第三域名服务器反馈的根据第一域名解析出的IP地址，验证第二域名服务器反馈的IP地址的可靠性，其中，验证方式具体可以是，将上述至少一个第三域名服务器反馈的根据第一域名解析出的IP地址和第二域名服务器反馈的根据第一域名解析出的IP地址进行比较，若超过设定比例的第三域名服务器反馈的根据第一域名解析出的IP地址和第二域名服务器反馈的根据第一域名解析出的IP地址相同，确定上述可靠性验证通过，若超过设定比例的第三域名服务器反馈的根据第一域名解析出的IP地址和第二域名服务器反馈的根据第一域名解析出的IP地址不相同，确定上述可靠性验证未通过。其中，可以选择在向第二域名服务器发送携带第一域名的域名查询请求消息的同时，向第三域名服务器发送携带第一域名的域名查询请求消息，当然也可以选择先向第二域名服务器发送或先向第三域名服务器发送。
当然可靠性验证模块540也可以通过其它方式，利用至少一个第三域名服务器验证上述IP地址的可靠性，此处不做限定。
第二发送模块550，用于在可靠性验证模块550的可靠性验证通过后，向第一域名服务器发送携带上述IP地址的第一域名查询应答消息。
参见图5-b，在一种应用场景下，可靠性验证模块540可以包括：
第一发送子模块541，用于向至少一个第三域名服务器发送携带有第一域名的域名查询请求消息。
第一接收子模块542，用于接收至少一个第三域名服务器发送的域名查询应答消息，该域名查询应答消息携带有根据第一域名解析出的IP地址。
第一验证子模块543，用于当超过设定比例的第三域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址与第二域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址相同时，确定该IP地址的可靠性验证通过。
第一验证子模块543还可以用于，当超过设定比例的第三域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址与第二域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址不相同时，确定该IP地址的可靠性验证未通过。
参见图5-c，在一种应用场景下，可靠性验证模块540可以包括：
第二发送子模块544，用于向至少一个第三域名服务器发送携带有上述IP地址的域名反查请求消息。
第二接收子模块545，用于接收至少一个第三域名服务器发送的域名反查应答消息，该域名反查应答消息携带有根据上述IP地址解析出的域名；
第二验证子模块546，用于当超过设定比例的第三域名服务器发送的域名反查应答消息中携带的根据上述IP地址解析出的域名与第一域名相同时，确定上述IP地址的可靠性验证通过。
第二验证子模块546还可以用于当超过设定比例的第三域名服务器发送的域名反查应答消息中携带的根据上述IP地址解析出的域名与第一域名不全相同时，确定上述IP地址的可靠性验证未通过。
在一种应用场景下，防护设备500还可以包括：
告警模块560，用于在可靠性验证模块550进行的可靠性验证未通过时，进行告警处理。
举例来说，告警模块560可以通知第一域名服务器本次域名查询失败，并可以发出告警日志。
在一种应用场景下，防护设备500还可以包括：
修改模块，用于按照预置策略，修改第一域名查询请求消息携带的应用层标识和/或端口号。
第一发送模块520具体可以用于，向至少向第二域名服务器发送修改了应用层标识和/或端口号的第一域名查询请求消息。
第一发送子模块541具体可以用于，向至少一个第三域名服务器发送携带有修改了应用层标识和/或端口号的第一域名查询请求消息。
在一种应用场景下，修改模块还可以用于，按照预置策略，修改域名反查请求消息携带的应用层标识和/或端口号。
第二发送子模块545具体可以用于，向至少一个第三域名服务器发送修改了应用层标识和/或端口号的携带有上述IP地址的域名反查请求消息。
在一种应用场景下，防护设备500还可以包括：
确定模块，用于确认第二接收模块530接收到的域名查询应答消息携带的应用层标识和/或端口号是否真实。
告警模块560，可以在确定模块确定出应用层标识和/或端口号不真实时，进行告警处理，例如可以直接丢弃该域名查询应答消息。
可以理解是的，本实施例的防护设备500可以如上述方法实施例中的防护设备SD1，其各个功能模块的功能可以根据上述方法实施例中的方法具体实现，其具体实现过程可参照上述实施例中的相关描述，此处不再赘述。
由上可见，本实施例防护设备500利用至少1个DNS服务器协助解析第一域名服务器请求解析的域名，在获得域名解析结果后，再利用其它至少1个DNS服务器验证获得的域名解析结果的可靠性，在可靠性验证通过后，再向第一域名服务器反馈域名解析结果，使得第一域名服务器能够获得真实的域名和IP地址的映射关系，进而实现有效的防护第一域名服务器感染缓存中毒；在应用层进行第一域名服务器缓存中毒保护，实现方式十分的可靠。
为便于更好的实施本发明实施例的技术方案，本发明实施例中还提供一种防护设备。
实施例六、
参见图六、本发明实施例六的一种防护设备600，可以包括：第一接收模块610、第一发送模块620、第二接收模块630和第二发送模块640。
其中，第一接收模块610，用于接收第一域名服务器发送的第一域名查询请求消息，该第一域名查询请求消息携带有第一域名信息。
第一发送模块620，用于向至少两个第二域名服务器发送携带有第一域名的域名查询请求消息。
第二接收模块630，用于接收至少两个第二域名服务器发送的域名查询应答消息，该域名查询应答消息携带根据第一域名解析出的IP地址。
比较模块640，用于将第二接收模块630接收的至少两个第二域名服务器发送的域名查询应答消息中携带的根据第一域名解析出的IP地址进行比较；
第二发送模块650，用于在比较模块640比较出超过设定比例的第二域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址相同时，向第一域名服务器发送携带有该相同的IP地址的第一域名查询应答消息。
在一种应用场景下，防护设备600还可以包括：
告警模块660，用于在超过设定比例的第二域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址不全相同时，进行告警处理。
举例来说，告警模块660例如可以通知第一域名服务器本次域名查询应失败，并可以发出告警日志。
在一种应用场景下，防护设备600还可以包括：
修改模块，用于按照预置策略，修改第一域名查询请求消息携带的应用层标识和/或端口号；
第一发送模块620具体可以用于，向至少两个第二域名服务器发送修改模块修改了应用层标识和/或端口号的第一域名查询请求。
在一种应用场景下，防护设备600还可以包括：
确定模块，用于确认第二接收模块630接收到的域名查询应答消息携带的应用层标识和/或端口号是否真实。
告警模块660，可以在确定模块确定出应用层标识和/或端口号不真实时，进行告警处理，例如可以直接丢弃该域名查询应答消息。
可以理解是的，本实施例的防护设备600可以如上述方法实施例中的防护设备SD1，其各个功能模块的功能可以根据上述方法实施例中的方法具体实现，其具体实现过程可参照上述实施例中的相关描述，此处不再赘述。
由上可见，本实施例防护设备600利用至少1个DNS服务器协助解析第一域名服务器请求解析的域名，在获得域名解析结果后，再利用其它至少1个DNS服务器验证获得的域名解析结果的可靠性，在可靠性验证通过后，再向第一域名服务器反馈域名解析结果，使得第一域名服务器能够获得真实的域名和IP地址的映射关系，进而实现有效的防护第一域名服务器感染缓存中毒；在应用层进行第一域名服务器缓存中毒保护，实现方式十分的可靠。
为便于更好的实施本发明实施例的技术方案，本发明实施例中还提供一种防护系统。
实施例七、
参见图7、本发明实施例七的一种防护系统，可以包括：第一域名服务器710和防护设备720。
第一域名服务器710，用于发送第一域名查询请求消息，该第一域名查询请求消息中携带有第一域名信息；
防护设备720，用于接收第一域名服务器发送的第一域名查询请求消息；向第二域名服务器发送携带有第一域名的域名查询请求消息；接收第二域名服务器发送的域名查询应答消息，该域名查询应答消息携带有根据第一域名解析出的IP地址；利用至少一个第三域名服务器验证上述IP地址的可靠性；在上述IP地址的可靠性验证通过后，向第一域名服务器发送携带有所述IP地址的第一域名查询应答消息。
在一种应用场景下，防护设备720还可以用于，在上述IP地址的可靠性验证未通过时，进行告警处理。
在一种应用场景下，防护设备720例如可以向至少一个第三域名服务器发送携带上述IP地址的域名反查请求消息，根据至少一个第三域名服务器反馈的根据上述IP地址解析出的域名，验证第二域名服务器反馈的上述IP地址的可靠性；其中，验证方式具体可以是，将第三域名服务器反馈的根据上述IP地址解析出的域名和第一域名进行比较，若超过设定比例(设定比例例如可以是90％、100％或根据需要设定的其它值)的第三域名服务器反馈的根据上述IP地址解析出的域名和第一域名相同，可以确定上述IP地址的可靠性验证通过，若超过设定比例的第三域名服务器反馈的根据上述IP地址解析出的域名和第一域名不相同，可以确定上述IP地址的可靠性验证未通过。
在另一种应用场景下，防护设备720也可以选择向至少一个第三域名服务器发送携带第一域名的域名查询请求消息，根据至少一个第三域名服务器反馈的根据第一域名解析出的IP地址，验证第二域名服务器反馈的IP地址的可靠性，其中，验证方式具体可以是，将上述至少一个第三域名服务器反馈的根据第一域名解析出的IP地址和第二域名服务器反馈的根据第一域名解析出的IP地址进行比较，若超过设定比例的第三域名服务器反馈的根据第一域名解析出的IP地址和第二域名服务器反馈的根据第一域名解析出的IP地址相同，确定上述可靠性验证通过，若超过设定比例的第三域名服务器反馈的根据第一域名解析出的IP地址和第二域名服务器反馈的根据第一域名解析出的IP地址不相同，确定上述可靠性验证未通过。其中，可以选择在向第二域名服务器发送携带第一域名的域名查询请求消息的同时，向第三域名服务器发送携带第一域名的域名查询请求消息，当然也可以选择先向第二域名服务器发送或先向第三域名服务器发送。
当然防护设备720也可以通过其它方式，利用至少一个第三域名服务器验证上述IP地址的可靠性，此处不做限定。
第一域名服务器710可以进一步接收携带上述IP地址的第一域名查询应答消息，并刷新缓存，记录上述IP地址和第一域名的映射关系。
可以理解是的，本实施例的防护设备720可以如上述方法实施例中的防护设备SD1，其各个功能模块的功能可以根据上述方法实施例中的方法具体实现，其具体实现过程可参照上述实施例中的相关描述，此处不再赘述。
为便于更好的实施本发明实施例的技术方案，本发明实施例中还提供一种防护系统。
实施例八、
参见图8、本发明实施例八的一种防护系统，可以包括：第一域名服务器810和防护设备820。
其中，第一域名服务器810，用于发送第一域名查询请求消息，该第一域名查询请求消息中携带有第一域名信息
防护设备820，用于接收第一域名服务器发送的第一域名查询请求消息；向至少两个第二域名服务器发送携带有第一域名的域名查询请求消息；接收至少两个第二域名服务器发送的域名查询应答消息，该域名查询应答消息携带根据第一域名解析出的IP地址；若超过设定比例的第二域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址相同，向第一域名服务器发送携带有所述相同的IP地址的第一域名查询应答消息。
在一种应用场景下，防护设备720还可以用于，若超过设定比例的第二域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址不全相同，执行告警处理。
第一域名服务器810可以进一步接收携带上述IP地址的第一域名查询应答消息，并刷新缓存，记录上述IP地址和第一域名的映射关系。
可以理解是的，本实施例的防护设备820可以如上述方法实施例中的防护设备SD1，其各个功能模块的功能可以根据上述方法实施例中的方法具体实现，其具体实现过程可参照上述实施例中的相关描述，此处不再赘述。
本发明还提供一种防护系统，包括如实施例七中的防护设备720。
本发明还提供一种防护系统，包括如实施例八中的防护设备820。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
综上所述，本发明实施例中，防护设备利用至少两个DNS服务器协助解析第一域名服务器请求解析的域名，并利用至少两个DNS服务器反馈的域名解析结果，相互验证域名解析结果的可靠性，在可靠性验证通过后，再向第一域名服务器反馈域名解析结果，使得第一域名服务器能够获得真实的域名和IP地址的映射关系，进而实现有效的防护第一域名服务器感染缓存中毒；在应用层进行第一域名服务器缓存中毒保护，实现方式十分的可靠。
进一步的，防护设备修改来自DNS1的域名查询请求消息携带的应用层ID和端口号，并对接收到的域名查询应答消息携带的应用层ID和端口号进行真实性确认，能够有效的过滤掉攻击者仿冒的域名查询应答消息，有利于进一步提高网络的安全性；防护设备在应用层对DNS1进行缓存中毒保护，实现方式十分的可靠。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read-Only Memory)、随机存储器(RAM，Random Access Memory)、磁盘或光盘等。。
以上对本发明实施例所提供的一种缓存中毒的防护方法和防护设备及防护系统进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。
Claims (13)
1.一种缓存中毒的防护方法，其特征在于，包括：
接收第一域名服务器发送的第一域名查询请求消息，所述第一域名查询请求消息携带有第一域名信息；
向第二域名服务器发送携带有第一域名的域名查询请求消息；
接收第二域名服务器发送的域名查询应答消息，所述域名查询应答消息携带有根据第一域名解析出的网际协议IP地址；
利用至少一个第三域名服务器验证所述IP地址的可靠性；
在所述可靠性验证通过后，向第一域名服务器发送携带有所述IP地址的第一域名查询应答消息。
2.根据权利要求1所述的方法，其特征在于，所述利用至少一个第三域名服务器验证所述IP地址的可靠性，包括：
向至少一个第三域名服务器发送携带有第一域名的域名查询请求消息；
接收至少一个第三域名服务器发送的域名查询应答消息，该域名查询应答消息中携带有根据第一域名解析出的IP地址；
当超过设定比例的第三域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址，与第二域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址相同时，确定所述IP地址的可靠性验证通过。
3.根据权利要求1所述的方法，其特征在于，所述利用至少一个第三域名服务器验证所述IP地址的可靠性，包括：
向至少一个第三域名服务器发送携带有所述IP地址的域名反查请求消息；
接收至少一个第三域名服务器发送的域名反查应答消息，所述域名反查应答消息中携带有根据所述IP地址解析出的域名；
当超过设定比例的第三域名服务器发送的域名反查应答消息中携带的根据所述IP地址解析出的域名与第一域名相同时，确定所述IP地址的可靠性验证通过。
4.根据权利要求1至3任一项所述方法，其特征在于，所述方法还包括：
按照预置策略修改所述第一域名查询请求消息携带的应用层标识和/或端口号；
所述向第二域名服务器发送携带有第一域名的域名查询请求消息，包括：
向第二域名服务器发送修改了应用层标识和/或端口号的第一域名查询请求消息。
5.根据权利要求4所述方法，其特征在于，所述向至少一个第三域名服务器发送携带有第一域名的域名查询请求消息，包括：
向至少一个第三域名服务器发送修改了应用层标识和/或端口号的第一域名查询请求消息。
6.一种缓存中毒的防护方法，其特征在于，包括：
接收第一域名服务器发送的第一域名查询请求消息，所述第一域名查询请求消息携带有第一域名信息；
向至少两个第二域名服务器发送携带有第一域名的域名查询请求消息；
接收至少两个第二域名服务器发送的域名查询应答消息，所述域名查询应答消息中携带有根据第一域名解析出的IP地址；
将所述至少两个第二域名服务器发送的域名查询应答消息中携带的根据第一域名解析出的IP地址进行比较；
若超过设定比例的第二域名服务器发送的域名查询应答消息中携带的根据第一域名解析出的IP地址相同，向第一域名服务器发送携带有所述相同的IP地址的第一域名查询应答消息。
7.一种防护设备，其特征在于，包括：
第一接收模块，用于接收第一域名服务器发送的第一域名查询请求消息，所述第一域名查询请求消息携带有第一域名信息；
第一发送模块，用于向第二域名服务器发送携带有第一域名的域名查询请求消息；
第二接收模块，用于接收第二域名服务器发送的域名查询应答消息，所述域名查询应答消息携带有根据第一域名解析出的IP地址；
可靠性验证模块，用于利用至少一个第三域名服务器验证所述IP地址的可靠性；
第二发送模块，用于在所述可靠性验证模块的可靠性验证通过后，向第一域名服务器发送携带有所述IP地址的第一域名查询应答消息。
8.根据权利要求7所述的防护设备，其特征在于，所述可靠性验证模块包括：
第一发送子模块，用于向至少一个第三域名服务器发送携带有第一域名的域名查询请求消息；
第一接收子模块，用于接收至少一个第三域名服务器发送的域名查询应答消息，该域名查询应答消息携带有根据第一域名解析出的IP地址；
第一验证子模块，用于当超过设定比例的第三域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址与第二域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址相同时，确定所述IP地址的可靠性验证通过。
9.根据权利要求7所述的防护设备，其特征在于，
所述可靠性验证模块包括：
第二发送子模块，用于向至少一个第三域名服务器发送携带有所述IP地址的域名反查请求消息；
第二接收子模块，用于接收至少一个第三域名服务器发送的域名反查应答消息，所述域名反查应答消息携带有根据所述IP地址解析出的域名；
第二验证子模块，用于当超过设定比例的第三域名服务器发送的域名反查应答消息中携带的根据所述IP地址解析出的域名与第一域名相同时，确定所述IP地址的可靠性验证通过。
10.根据权利要求7至9任一项所述的防护设备，其特征在于，所述防护设备还包括：
修改模块，用于按照预置策略修改所述第一域名查询请求消息携带的应用层标识和/或端口号；
所述第一发送模块，用于向第二域名服务器发送修改了应用层标识和/或端口号的第一域名查询请求消息。
11.一种防护设备，其特征在于，包括：
第一接收模块，用于接收第一域名服务器发送的第一域名查询请求消息，所述第一域名查询请求消息携带有第一域名信息；
第一发送模块，用于向至少两个第二域名服务器发送携带有第一域名的域名查询请求消息；
第二接收模块，用于接收至少两个第二域名服务器发送的域名查询应答消息，所述域名查询应答消息携带根据第一域名解析出的IP地址；
比较模块，用于将第二接收模块接收的至少两个第二域名服务器发送的域名查询应答消息中携带的根据第一域名解析出的IP地址进行比较；
第二发送模块，用于在超过设定比例的第二域名服务器发送的域名查询应答消息携带的根据第一域名解析出的IP地址相同时，向第一域名服务器发送携带有所述相同的IP地址的第一域名查询应答消息。
12.一种防护系统，其特征在于，包括如权利要求7至10任一项所述的防护设备。
13.一种防护系统，其特征在于，包括如权利要求11所述的防护设备。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910179915.2A CN102035809B (zh) | 2009-09-29 | 2009-09-29 | 缓存中毒的防护方法和防护设备及防护系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910179915.2A CN102035809B (zh) | 2009-09-29 | 2009-09-29 | 缓存中毒的防护方法和防护设备及防护系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102035809A true CN102035809A (zh) | 2011-04-27 |
| CN102035809B CN102035809B (zh) | 2013-04-24 |
Family
ID=43888145
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200910179915.2A Expired - Fee Related CN102035809B (zh) | 2009-09-29 | 2009-09-29 | 缓存中毒的防护方法和防护设备及防护系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102035809B (zh) |
Cited By (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102231766A (zh) * | 2011-07-28 | 2011-11-02 | 北京蓝汛通信技术有限责任公司 | 一种域名解析验证的方法及系统 |
| CN102404318A (zh) * | 2011-10-31 | 2012-04-04 | 杭州迪普科技有限公司 | 一种防范dns缓存攻击的方法及装置 |
| CN102404317A (zh) * | 2011-10-31 | 2012-04-04 | 杭州迪普科技有限公司 | 一种防范dns缓存攻击的方法及装置 |
| CN103685168A (zh) * | 2012-09-07 | 2014-03-26 | 中国科学院计算机网络信息中心 | 一种dns递归服务器的查询请求服务方法 |
| CN104052755A (zh) * | 2014-06-26 | 2014-09-17 | 国家计算机网络与信息安全管理中心 | 基于云平台的dns欺骗攻击探测及定位的系统和方法 |
| CN104219200A (zh) * | 2013-05-30 | 2014-12-17 | 杭州迪普科技有限公司 | 一种防范dns缓存攻击的装置和方法 |
| CN104348924A (zh) * | 2013-07-30 | 2015-02-11 | 深圳市腾讯计算机系统有限公司 | 一种域名解析方法、系统及装置 |
| CN105338126A (zh) * | 2014-07-17 | 2016-02-17 | 阿里巴巴集团控股有限公司 | 远程查询信息的方法及服务器 |
| CN105939346A (zh) * | 2016-05-04 | 2016-09-14 | 杭州迪普科技有限公司 | 阻止dns缓存攻击方法及装置 |
| CN105939337A (zh) * | 2016-03-09 | 2016-09-14 | 杭州迪普科技有限公司 | Dns缓存投毒的防护方法及装置 |
| WO2016177282A1 (zh) * | 2015-05-06 | 2016-11-10 | 阿里巴巴集团控股有限公司 | 域名解析生效的检测方法、浏览器、服务端和系统 |
| CN106302384A (zh) * | 2016-07-25 | 2017-01-04 | 中国联合网络通信集团有限公司 | Dns报文处理方法及装置 |
| CN107528817A (zh) * | 2016-06-22 | 2017-12-29 | 广州市动景计算机科技有限公司 | 域名劫持的探测方法和装置 |
| CN103747005B (zh) * | 2014-01-17 | 2018-01-05 | 山石网科通信技术有限公司 | Dns缓存投毒的防护方法和设备 |
| WO2018115647A1 (fr) * | 2016-12-23 | 2018-06-28 | Orange | Validation de livraison de contenu et de verification d'une delegation de livraison d'un contenu |
| CN113014687A (zh) * | 2021-02-20 | 2021-06-22 | 上海牙木通讯技术有限公司 | Dns迭代查询方法、dns服务器、系统及计算机可读存储介质 |
| CN116436705A (zh) * | 2023-06-13 | 2023-07-14 | 武汉绿色网络信息服务有限责任公司 | 网络安全检测方法、装置、电子设备及存储介质 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100663546B1 (ko) * | 2005-07-08 | 2007-01-02 | 주식회사 케이티 | 악성 봇 대응 방법 및 그 시스템 |
| CN101277257B (zh) * | 2007-03-26 | 2012-02-01 | 华为技术有限公司 | 一种dns动态更新的方法、装置和系统 |
| CN101321055A (zh) * | 2008-06-28 | 2008-12-10 | 华为技术有限公司 | 一种攻击防范方法和装置 |
| CN101478553B (zh) * | 2009-02-10 | 2012-07-04 | 中国联合网络通信集团有限公司 | 动态域名管理系统和方法 |
-
2009
- 2009-09-29 CN CN200910179915.2A patent/CN102035809B/zh not_active Expired - Fee Related
Cited By (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102231766B (zh) * | 2011-07-28 | 2013-10-09 | 北京蓝汛通信技术有限责任公司 | 一种域名解析验证的方法及系统 |
| CN102231766A (zh) * | 2011-07-28 | 2011-11-02 | 北京蓝汛通信技术有限责任公司 | 一种域名解析验证的方法及系统 |
| CN102404318B (zh) * | 2011-10-31 | 2015-09-09 | 杭州迪普科技有限公司 | 一种防范dns缓存攻击的方法及装置 |
| CN102404318A (zh) * | 2011-10-31 | 2012-04-04 | 杭州迪普科技有限公司 | 一种防范dns缓存攻击的方法及装置 |
| CN102404317A (zh) * | 2011-10-31 | 2012-04-04 | 杭州迪普科技有限公司 | 一种防范dns缓存攻击的方法及装置 |
| CN103685168A (zh) * | 2012-09-07 | 2014-03-26 | 中国科学院计算机网络信息中心 | 一种dns递归服务器的查询请求服务方法 |
| CN103685168B (zh) * | 2012-09-07 | 2016-12-07 | 中国科学院计算机网络信息中心 | 一种dns递归服务器的查询请求服务方法 |
| CN104219200A (zh) * | 2013-05-30 | 2014-12-17 | 杭州迪普科技有限公司 | 一种防范dns缓存攻击的装置和方法 |
| CN104219200B (zh) * | 2013-05-30 | 2017-10-17 | 杭州迪普科技股份有限公司 | 一种防范dns缓存攻击的装置和方法 |
| CN104348924A (zh) * | 2013-07-30 | 2015-02-11 | 深圳市腾讯计算机系统有限公司 | 一种域名解析方法、系统及装置 |
| US10419387B2 (en) | 2013-07-30 | 2019-09-17 | Tencent Technology (Shenzhen) Company Limited | Domain name resolution method, system, and device |
| CN103747005B (zh) * | 2014-01-17 | 2018-01-05 | 山石网科通信技术有限公司 | Dns缓存投毒的防护方法和设备 |
| CN104052755B (zh) * | 2014-06-26 | 2018-01-19 | 国家计算机网络与信息安全管理中心 | 基于云平台的dns欺骗攻击探测及定位的系统和方法 |
| CN104052755A (zh) * | 2014-06-26 | 2014-09-17 | 国家计算机网络与信息安全管理中心 | 基于云平台的dns欺骗攻击探测及定位的系统和方法 |
| US10225231B2 (en) | 2014-07-17 | 2019-03-05 | Alibaba Group Holding Limited | Method and server of remote information query |
| CN105338126A (zh) * | 2014-07-17 | 2016-02-17 | 阿里巴巴集团控股有限公司 | 远程查询信息的方法及服务器 |
| CN105338126B (zh) * | 2014-07-17 | 2018-10-23 | 阿里巴巴集团控股有限公司 | 远程查询信息的方法及服务器 |
| CN106209486A (zh) * | 2015-05-06 | 2016-12-07 | 阿里巴巴集团控股有限公司 | 域名解析生效的检测方法、浏览器、服务端和系统 |
| WO2016177282A1 (zh) * | 2015-05-06 | 2016-11-10 | 阿里巴巴集团控股有限公司 | 域名解析生效的检测方法、浏览器、服务端和系统 |
| CN106209486B (zh) * | 2015-05-06 | 2019-08-20 | 阿里巴巴集团控股有限公司 | 域名解析生效的检测方法、浏览器、服务端和系统 |
| CN105939337B (zh) * | 2016-03-09 | 2019-08-06 | 杭州迪普科技股份有限公司 | Dns缓存投毒的防护方法及装置 |
| CN105939337A (zh) * | 2016-03-09 | 2016-09-14 | 杭州迪普科技有限公司 | Dns缓存投毒的防护方法及装置 |
| US10469532B2 (en) | 2016-03-09 | 2019-11-05 | Hangzhou Dptech Technologies Co., Ltd. | Preventing DNS cache poisoning |
| US20170264590A1 (en) * | 2016-03-09 | 2017-09-14 | Hangzhou Dptech Technologies Co., Ltd. | Preventing dns cache poisoning |
| CN105939346A (zh) * | 2016-05-04 | 2016-09-14 | 杭州迪普科技有限公司 | 阻止dns缓存攻击方法及装置 |
| CN107528817B (zh) * | 2016-06-22 | 2021-05-18 | 阿里巴巴（中国）有限公司 | 域名劫持的探测方法和装置 |
| CN107528817A (zh) * | 2016-06-22 | 2017-12-29 | 广州市动景计算机科技有限公司 | 域名劫持的探测方法和装置 |
| CN106302384A (zh) * | 2016-07-25 | 2017-01-04 | 中国联合网络通信集团有限公司 | Dns报文处理方法及装置 |
| FR3061388A1 (fr) * | 2016-12-23 | 2018-06-29 | Orange | Procedes de validation de livraison de contenu et de verification d'une delegation de livraison d'un contenu, dispositifs et produits programme d'ordinateur correspondants. |
| WO2018115647A1 (fr) * | 2016-12-23 | 2018-06-28 | Orange | Validation de livraison de contenu et de verification d'une delegation de livraison d'un contenu |
| US11394723B2 (en) | 2016-12-23 | 2022-07-19 | Orange | Validation of content delivery and verification of a delegation of delivery of a content |
| CN113014687A (zh) * | 2021-02-20 | 2021-06-22 | 上海牙木通讯技术有限公司 | Dns迭代查询方法、dns服务器、系统及计算机可读存储介质 |
| CN116436705A (zh) * | 2023-06-13 | 2023-07-14 | 武汉绿色网络信息服务有限责任公司 | 网络安全检测方法、装置、电子设备及存储介质 |
| CN116436705B (zh) * | 2023-06-13 | 2023-08-11 | 武汉绿色网络信息服务有限责任公司 | 网络安全检测方法、装置、电子设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102035809B (zh) | 2013-04-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102035809B (zh) | 缓存中毒的防护方法和防护设备及防护系统 | |
| US11216514B2 (en) | Secure DNS query | |
| US7895319B2 (en) | Variable DNS responses based on client identity | |
| CN106302308B (zh) | 一种信任登录方法和装置 | |
| CN101370019B (zh) | 防止地址解析协议报文欺骗攻击的方法及交换机 | |
| CN101540676B (zh) | 一种适合三元对等鉴别可信网络连接架构的平台鉴别方法 | |
| US9967269B2 (en) | Method, device and system for processing DNS behavior | |
| CN108650211A (zh) | 一种dns劫持的检测方法和装置 | |
| CN103634786A (zh) | 一种无线网络的安全检测和修复的方法与系统 | |
| CN101789947A (zh) | 防范http post泛洪攻击的方法及防火墙 | |
| CN101252584B (zh) | 双向转发检测协议会话的认证方法、系统和设备 | |
| MX2008015235A (es) | Zonas habilitadas por requisicion de nombre. | |
| US11620272B2 (en) | Trusted ledger management systems and methods | |
| Ng et al. | Applying data mining techniques to intrusion detection | |
| CN106209907B (zh) | 一种检测恶意攻击的方法及装置 | |
| Gupta et al. | Prevention of cross-site scripting vulnerabilities using dynamic hash generation technique on the server side | |
| US20230231864A1 (en) | Intrusion monitoring system, method and related products | |
| AU2021361150A9 (en) | Trusted ledger management systems and methods | |
| Biswas et al. | An intrusion detection system based secured electronic service delivery model | |
| CN101471878A (zh) | 对等会话起始协议网络的安全路由方法、网络系统及设备 | |
| CN104618176A (zh) | 网站安全检测方法及装置 | |
| CN111416887A (zh) | 地址检测的方法、装置、交换机及存储介质 | |
| CN108768853B (zh) | 基于域名路由器的分布式混合域名系统及方法 | |
| Rafiee et al. | A flexible framework for detecting ipv6 vulnerabilities | |
| Randall et al. | The Challenges of Blockchain-Based Naming Systems for Malware Defenders |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| C56 | Change in the name or address of the patentee |
Owner name: HUAWEI DIGITAL TECHNOLOGY (CHENGDU) CO., LTD. Free format text: FORMER NAME: CHENGDU HUAWEI SYMANTEC TECHNOLOGIES CO., LTD. |
|
| CP01 | Change in the name or title of a patent holder |
Address after: 611731 Chengdu high tech Zone, Sichuan, West Park, Qingshui River Patentee after: HUAWEI DIGITAL TECHNOLOGIES (CHENG DU) Co.,Ltd. Address before: 611731 Chengdu high tech Zone, Sichuan, West Park, Qingshui River Patentee before: CHENGDU HUAWEI SYMANTEC TECHNOLOGIES Co.,Ltd. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20220902 Address after: No. 1899 Xiyuan Avenue, high tech Zone (West District), Chengdu, Sichuan 610041 Patentee after: Chengdu Huawei Technologies Co.,Ltd. Address before: 611731 Qingshui River District, Chengdu hi tech Zone, Sichuan, China Patentee before: HUAWEI DIGITAL TECHNOLOGIES (CHENG DU) Co.,Ltd. |
|
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20130424 |