网络攻击的防护方法及装置制造方法
【专利摘要】本发明适用于通信领域，提供了一种网络攻击的防护方法，包括：接收用户端发送的关于第一域名的第一域名解析请求，提取出其中的源地址和第一域名；基于所述第一域名生成包含所述用户端的cookie的第二域名；向所述用户端返回第一响应，该第一响应中携带了第二域名；在所述第二域名解析请求中提取源地址和所述第二域名；判断所述第二域名解析请求中的源地址与所述第二域名中包含的所述用户端的cookie是否匹配，是则向所述用户端返回第二响应，该第二响应中携带了第一域名；将所述第三域名解析请求转发给权威DNS服务器。本发明实施例在不需要强制用户端改用TCP协议进行通信的前提下，有效地保障了用户端与服务器之间的正常通信。
【专利说明】网络攻击的防护方法及装置
【技术领域】
[0001]本发明属于通信领域，尤其涉及一种网络攻击的防护方法及装置。
【背景技术】
[0002]域名服务系统(Domain Name System, DNS)洪水(Flood)攻击是一种拒绝服务(Denial of Sdrvice, DoS)攻击,通过构造大量恶意的域名解析请求发送到服务器,消耗服务器带宽或者服务器中央处理器(Central Processing Unit, CPU)资源,使之无法正常对外服务。
[0003]为了防护上述网络攻击，通常在服务器端配置安全防护设备，其在接收到用户端的域名解析请求之后，通过构造带TC标记位的DNS响应包，强制用户将非可靠的用户数据报协议(User Datagram Protocol, UDP)更改为可靠的传输控制协议(Transmiss1nControl Protocol, TCP),再次发送域名解析请求，由此来实现对正常用户端和攻击用户端的区分，为服务器过滤掉攻击用户端的域名解析请求，实现对网络攻击的阻断。
[0004]然而，由于目前大部分用户端的本地缓存域名服务器(Local Domain NameSystem, LDNS)并不支持对带TC标记位的DNS响应包的识别功能，因此，上述防护方式会导致服务器无法处理正常用户端的域名解析请求，严重影响了正常用户端与服务器之间的网络通信。
【发明内容】
[0005]本发明实施例的目的在于提供一种网络攻击的防护方法，旨在解决现有的针对DNS洪水攻击的防护方法会导致服务器无法处理正常用户端的域名解析请求的问题。
[0006]本发明实施例是这样实现的，一种网络攻击的防护方法，包括:
[0007]接收用户端发送的关于第一域名的第一域名解析请求，提取出其中的源地址和所述第一域名；
[0008]基于所述第一域名生成包含所述用户端的cookie的第二域名，所述用户端的cookie为根据预设算法计算所述第一域名解析请求中的源地址得到；
[0009]向所述用户端返回第一响应，所述第一响应中携带了所述第二域名，以使所述用户端根据所述第一响应返回关于所述第二域名的第二域名解析请求；
[0010]在所述第二域名解析请求中提取源地址和所述第二域名；
[0011]判断所述第二域名解析请求中的源地址与所述第二域名中包含的所述用户端的cookie是否匹配，是则向所述用户端返回第二响应，所述第二响应中携带了所述第一域名，以使所述用户端根据所述第二响应返回关于所述第一域名的第三域名解析请求；
[0012]将所述第三域名解析请求转发给权威域名服务系统DNS服务器。
[0013]本发明实施例的另一目的在于提供一种网络攻击的防护装置，包括:
[0014]第一接收单元，用于接收用户端发送的关于第一域名的第一域名解析请求，提取出其中的源地址和所述第一域名；
[0015]生成单元，用于基于所述第一域名生成包含所述用户端的cookie的第二域名，所述用户端的cookie为根据预设算法计算所述第一域名解析请求中的源地址得到；
[0016]第一返回单元，用于向所述用户端返回第一响应，所述第一响应中携带了所述第二域名，以使所述用户端根据所述第一响应返回关于所述第二域名的第二域名解析请求；
[0017]提取单元，用于在所述第二域名解析请求中提取源地址和所述第二域名；
[0018]第二返回单元，用于判断所述第二域名解析请求中的源地址与所述第二域名中包含的所述用户端的cookie是否匹配，是则向所述用户端返回第二响应，所述第二响应中携带了所述第一域名，以使所述用户端根据所第二响应返回第三域名解析请求；
[0019]第一转发单元，用于将所述第三域名解析请求转发给权威域名服务系统DNS服务器。
[0020]本发明实施例针对DNS洪水攻击提供了一种防护方法，在不需要强制用户端改用TCP协议的前提下，能够有效地识别出正常发送域名解析请求的用户端，为服务器过滤掉攻击用户端发送的域名解析请求，有效地保障了用户端与服务器之间的正常通信。
【专利附图】
【附图说明】
[0021]图1是本发明实施例提供的网络攻击的防护方法的实现流程图；
[0022]图2是本发明实施例提供的网络攻击的防护方法S105的具体实现流程图；
[0023]图3是本发明另一实施例提供的网络攻击的防护方法的实现流程图；
[0024]图4是本发明另一实施例提供的网络攻击的防护方法的实现流程图；
[0025]图5是本发明实施例提供的网络攻击的防护方法的交互流程图；
[0026]图6是本发明实施例提供的网络攻击的防护装置的结构框图；
[0027]图7是本发明另一实施例提供的网络攻击的防护装置的结构框图；
[0028]图8是本发明另一实施例提供的网络攻击的防护装置的结构框图。
【具体实施方式】
[0029]为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
[0030]本发明实施例针对DNS洪水攻击提供了一种防护方法，在不需要强制用户端改用TCP协议的前提下，能够有效地识别出正常发送域名解析请求的用户端，为服务器过滤掉攻击用户端发送的域名解析请求，有效地保障了用户端与服务器之间的正常通信。
[0031]本发明实施例基于“用户端-服务器”的网络架构实现，且执行网络攻击防护的可以为在用户端与服务器之间独立存在的防护设备，其在服务器处理域名解析请求之前，先对来自不同用户端的域名解析请求进行过滤，从中识别出正常发送的域名解析请求，过滤掉用于攻击服务器的域名解析请求，从而保障服务器与用户端之间的正常通信。
[0032]需要说明的是，在本发明实施例执行网络攻击防护的整个过程中，用户端和服务器均可以遵循现有的通信协议来完成通信过程，不需要更改通信协议或者通信方法。
[0033]图1示出了本发明实施例提供的网络攻击的防护方法的实现流程，详述如下:
[0034]在SlOl中，接收用户端发送的关于第一域名的第一域名解析请求，提取出其中的源地址和所述第一域名。
[0035]无论是正常用户端还是攻击用户端，都会向服务器发送域名解析请求，以使服务器在接收到该域名解析请求后，将其中要求解析的域名解析成相应的IP地址。
[0036]本实施例中，在服务器接收域名解析请求之前，相关的防护设备会先于服务器截取到用户端发送的第一域名解析请求，并从中提取出用户端的源地址和用户端请求解析的第一域名，其中，源地址为该用户端在网络中的IP地址，能够唯一标识该用户端，使之区别于其他用户端。
[0037]在S102中，基于所述第一域名生成包含所述用户端的cookie的第二域名，所述用户端的cookie为根据预设算法计算所述第一域名解析请求中的源地址得到。
[0038]通过预设算法对SlOl中提取出的源地址进行计算，得到该用户端的cookie，该cookie为一个字符串，且由于源地址是唯一的，因此，用户端的cookie也是唯一的。在本实施例中，预设算法可以为哈希算法。
[0039]在计算出用户端的cookie之后，基于SlOl中提取出的第一域名，生成包含了用户端的cookie的第二域名。
[0040]例如，第一域名为WWW.A.com,则生成的第二域名可以为cookie, www.A.com。
[0041 ] 在本实施例中，对基于第一域名生成上述第二域名的生成规则不作限定。
[0042]在S103中，向所述用户端返回第一响应，所述第一响应中携带了所述第二域名，以使所述用户端根据所述第一响应返回关于所述第二域名的第二域名解析请求。
[0043]在生成第二域名之后，向用户端返回针对第一域名解析请求的第一响应，且在第一响应中携带了第二域名，因此，正常用户端在接收到该第一响应后，会根据该第一响应的携带信息，返回第二域名解析请求，且该第二域名解析请求中请求解析的域名为第二域名。
[0044]作为本发明的一个实施例，第一响应可以为NS响应，其为用户端的LDNS能够处理的一种DNS响应类型。
[0045]而对于攻击用户端来说，由于其仅仅是采用直接发送UDP协议的域名解析请求的方式来进行攻击，因此，攻击用户端并不会针对返回的DNS响应再一次发送域名解析请求。
[0046]在S104中，在所述第二域名解析请求中提取源地址和所述第二域名。
[0047]当接收到用户端发送的第二域名解析请求之后，同样地，在该请求中提取源地址和第二域名。
[0048]在S105中，判断所述第二域名解析请求中的源地址与所述第二域名中包含的所述用户端的cookie是否匹配，是则向所述用户端返回第二响应，所述第二响应中携带了所述第一域名，以使所述用户端根据所述第二响应返回关于所述第一域名的第三域名解析请求。
[0049]在本实施例中，对于S104中提取出的第二域名解析请求中的源地址和第二域名，判断该源地址和第二域名中包含的用户端的cookie是否匹配。由于对于攻击用户端来说，其并不会发送该第二域名解析请求，因此，当判断出该源地址和第二域名中包含的用户端的cookie匹配之后，即可以认定发送该第二域名解析请求的为正常的用户端，此时，向该用户端返回针对第二域名解析请求的第二响应，并在该第二响应中携带第一域名，以使用户端再次发送请求解析第一域名的第三域名解析请求。
[0050]作为本发明的一个实施例，第二响应可以为CNAME响应，其为用户端的LDNS能够处理的一种DNS响应类型，用于提供域名别名服务。例如，防护设备在接收到用户端关于域名cookie, www.A.com的域名解析请求后,针对该域名解析请求所返回的CNAME响应中所携带的域名为www.A.com，而正常用户端在接收到该CNAME响应后，会根据该CNAME响应返回关于www.A.com的第三域名解析请求。
[0051]在S105的判断过程中，需要首先从第二域名中提取出cookie，再判断提取出的cookie与源地址是否匹配。对于cookie的提取，可以比对预存储的第一域名，根据第二域名的生成规则，从第二域名中提取出cookie。
[0052]例如,第二域名为cookie, www.A.com,而第二域名的生成规则为在第一域名的最前端增加用户端的cookie，因此，对第二域名的最前端部分进行提取，则提取出了用户端的cookie。
[0053]S105中的匹配过程可以如图2所示:
[0054]在S201中，根据所述预设算法计算所述第二域名解析请求中的源地址，得到计算结果。
[0055]在S202中，判断所述计算结果与所述第二域名中包含的所述用户端的cookie是否匹配。
[0056]在本实施例中,若第二域名解析请求与上述第一域名解析请求是由同一用户端发出的，则第二域名解析请求中的源地址与第一域名解析请求中的源地址是相同的，则显然，采用相同的预设算法，S201中的计算结果即为该用户端的cookie，那么S202中可以判断出S201的计算结果与第二域名中包含的用户端的cookie是匹配的。
[0057]在S106中，将所述第三域名解析请求转发给权威域名服务系统DNS服务器。
[0058]在本实施例中，当再次接收到用户端发送的请求解析第一域名的第三域名解析请求后，由于已认定该用户端并非攻击用户端，因此，直接将该第三域名解析请求转发给权威DNS服务器，后续的域名解析过程即可按照用户端与服务器之间常规的通信过程来完成，从而实现域名解析。
[0059]作为本发明的一个实施例，在执行SlOl至S106之前，还可以通过建立请求重传机制，来过滤掉一部分攻击用户端，如图3所示，在SlOl之前，还包括:
[0060]在S107中，接收并记录所述用户端发送的关于所述第一域名的第四域名解析请求。
[0061]在S108中，丢弃所述第四域名解析请求，以使所述用户端在预设的时间间隔内发送关于所述第一域名的所述第一域名解析请求。
[0062]由于对于正常用户端来说，其均设置有固定的重传间隔，在域名解析请求发送出去的一段时间内，若未接收到相应的响应，则会再次重新发送一遍相同的域名解析请求，以防止域名解析请求在发送过程中出现丢包现象，保障通信的可靠性。在本实施例中，根据上述机制，对用户端每一次的域名解析请求的发送行为均进行记录，并在第一次接收到用户端发送的关于第一域名的域名解析请求后，直接丢弃该域名解析请求，以使得用户端在预设的重传时间间隔内再次自动发送关于第一域名的解析请求。
[0063]则相应地，SlOl具体为:
[0064]在S109中，接收所述用户端发送的所述第一域名解析请求。
[0065]在SllO中，判断所述第一域名解析请求是否为所述用户端在所述预设的时间间隔内再次发送的关于所述第一域名的域名解析请求。
[0066]在Slll中，当判断出所述第一域名解析请求为所述用户端在所述预设的时间间隔内再次发送的关于所述第一域名的域名解析请求时，提取出所述第一域名解析请求中的源地址和所述第一域名。
[0067]在本实施例中，根据用户端的域名解析请求的发送记录，查询S108接收到的第一域名解析请求是否是该用户端在允许的重传间隔内针对同一域名再次发送的域名解析请求，是则对该域名解析请求进行相应处理，否则直接丢弃该域名解析请求，等待用户端的重传。
[0068]在本实施例中，由于攻击用户端一般采用UDP随机发包的方式进行攻击，而不支持对未接收到响应的请求进行重传的机制，因此，基于本实施例，能够在执行SlOl之前，首先过滤掉一部分攻击用户端，有效地降低了后续步骤中DNS响应的回复量。
[0069]图4示出了本发明另一实施例提供的网络攻击的防护方法的实现流程，基于本发明图1所示实施例，在S106之后,如图4所示,该方法还包括:
[0070]在S401中，将所述用户端的源地址加入至白名单中。
[0071]在S402中，当接收到所述用户端发送的第五域名解析请求时，检测所述第五域名解析请求中的源地址是否位于所述白名单中。
[0072]在S403中，当检测出所述第五域名解析请求中的源地址位于所述白名单之后，直接将所述第四域名解析请求转发至所述权威DNS服务器。
[0073]在本实施例中，通过建立白名单，一旦验证了一个用户端为非攻击用户端之后，则直接将该用户端的源地址加入到该白名单中，在后续接收到域名解析请求时，首先检测发送该域名解析请求的源地址是否位于该白名单中，若是，则无需再执行相关的验证步骤，直接将该用户端的域名解析请求转发到权利DNS服务器进行处理。
[0074]为了更好地说明本发明实施例提供的网络攻击的防护方法，图5结合具体的应用场景，示出了本发明实施例提供的网络攻击的防护方法的交互流程图，其中，交互流程涉及到的通信主体包括正常的用户端、防护设备以及权威DNS服务器，详述如下:
[0075]1、用户端向防护设备发送关于第一域名的域名解析请求。
[0076]2、防护设备判断该域名解析请求为该用户端在预设的时间间隔内针对该域名第一次发送，直接丢弃该域名解析请求。
[0077]3、用户端在预设的时间间隔内未收到任何响应，再次向防护设备发送关于第一域名的域名解析请求。
[0078]4、防护设备提取再次发送的域名解析请求中的源地址和第一域名，生成包含该用户端的cookie的第二域名。
[0079]5、防护设备向用户端返回NS响应。
[0080]6、用户端根据NS响应，向防护设备发送关于第二域名的域名解析请求。
[0081]7、防护设备在该域名解析请求中提取源地址和第二域名，并判断该域名解析请求中的源地址与第二域名中包含的用户端的cookie匹配。
[0082]8、防护设备向用户端返回CNAME响应。
[0083]9、用户端根据CNAME响应，向防护设备发送关于第一域名的第三域名解析请求。
[0084]10、防护设备直接将第三域名解析请求发送给权威DNS服务器。
[0085]本发明实施例针对DNS洪水攻击提供了一种防护方法，在不需要强制用户端改用TCP协议的前提下，能够有效地识别出正常发送域名解析请求的用户端，为服务器过滤掉攻击用户端发送的域名解析请求，有效地保障了用户端与服务器之间的正常通信。
[0086]图6示出了本发明实施例提供的网络攻击的防护装置的结构框图，该装置可以位于用户端与服务器之间的防护设备中，用于运行本发明图1至图5实施例所述的网络攻击的防护方法。为了便于说明，仅示出了与本实施例相关的部分。
[0087]参照图6，该装置包括:
[0088]第一接收单元601，接收用户端发送的关于第一域名的第一域名解析请求，提取出其中的源地址和所述第一域名。
[0089]生成单元602，基于所述第一域名生成包含所述用户端的cookie的第二域名，所述用户端的cookie为根据预设算法计算所述第一域名解析请求中的源地址得到。
[0090]第一返回单元603，向所述用户端返回第一响应，所述第一响应中携带了所述第二域名，以使所述用户端根据所述第一响应返回关于所述第二域名的第二域名解析请求。
[0091]提取单元604，在所述第二域名解析请求中提取源地址和所述第二域名。
[0092]第二返回单元605，判断所述第二域名解析请求中的源地址与所述第二域名中包含的所述用户端的cookie是否匹配，是则向所述用户端返回第二响应，所述第二响应中携带了所述第一域名，以使所述用户端根据所述第二响应返回第三域名解析请求。
[0093]第一转发单元606，将所述第三域名解析请求转发给权威DNS服务器。
[0094]可选地，如图7所示，所述装置还包括:
[0095]第二接收单元607，接收并记录所述用户端发送的关于所述第一域名的第四域名解析请求；
[0096]丢弃单元608，丢弃所述第四域名解析请求，以使所述用户端在预设的时间间隔内重新发送关于所述第一域名的所述第一域名解析请求；
[0097]则所述第一接收单元601包括:
[0098]接收子单元6011，接收所述用户端发送的所述第一域名解析请求。
[0099]第一判断子单元6012，判断所述第一域名解析请求是否为所述用户端在所述预设的时间间隔内再次发送的关于所述第一域名的域名解析请求。
[0100]提取子单元6013，当判断出所述第一域名解析请求为所述用户端在所述预设的时间间隔内再次发送的关于所述第一域名的域名解析请求时，提取出所述第一域名解析请求中的源地址和所述第一域名。
[0101]可选地，所述第二发送单元605包括:
[0102]计算子单元，根据所述预设算法计算所述第二域名解析请求中的源地址，得到计晳奸里
[0103]第二判断子单元，判断所述计算结果与所述第二域名中包含的所述用户端的cookie是否匹配。
[0104]可选地，如图8所示，所述装置还包括:
[0105]加入单元609，将所述用户端的源地址加入至白名单中。
[0106]检测单元610，当接收到所述用户端发送的第五域名解析请求时，检测所述第五域名解析请求中的源地址是否位于所述白名单中。
[0107]第二转发单元611，当检测出所述第五域名解析请求中的源地址位于所述白名单之后，直接将所述第四域名解析请求转发至所述权威DNS服务器。
[0108]可选地，所述第一响应包括NS响应，所述第二响应包括CNAME响应。
[0109]本发明实施例针对DNS洪水攻击提供了一种防护方法，在不需要强制用户端改用TCP协议的前提下，能够有效地识别出正常发送域名解析请求的用户端，为服务器过滤掉攻击用户端发送的域名解析请求，有效地保障了用户端与服务器之间的正常通信。
[0110]以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。
【权利要求】
1.一种网络攻击的防护方法，其特征在于，包括: 接收用户端发送的关于第一域名的第一域名解析请求，提取出其中的源地址和所述第一域名； 基于所述第一域名生成包含所述用户端的cookie的第二域名，所述用户端的cookie为根据预设算法计算所述第一域名解析请求中的源地址得到； 向所述用户端返回第一响应，所述第一响应中携带了所述第二域名，以使所述用户端根据所述第一响应返回关于所述第二域名的第二域名解析请求； 在所述第二域名解析请求中提取源地址和所述第二域名； 判断所述第二域名解析请求中的源地址与所述第二域名中包含的所述用户端的cookie是否匹配，是则向所述用户端返回第二响应，所述第二响应中携带了所述第一域名，以使所述用户端根据所述第二响应返回关于所述第一域名的第三域名解析请求； 将所述第三域名解析请求转发给权威域名服务系统DNS服务器。
2.如权利要求1所述的方法，其特征在于，在所述接收用户端发送的关于第一域名的第一域名解析请求之前，所述方法还包括: 接收并记录所述用户端发送的关于所述第一域名的第四域名解析请求； 丢弃所述第四域名解析请求，以使所述用户端在预设的时间间隔内发送关于所述第一域名的所述第一域名解析请求； 则所述接收用户端发送的关于第一域名的第一域名解析请求，提取出其中的源地址和所述第一域名包括: 接收所述用户端发送的所述第一域名解析请求； 判断所述第一域名解析请求是否为所述用户端在所述预设的时间间隔内再次发送的关于所述第一域名的域名解析请求； 当判断出所述第一域名解析请求为所述用户端在所述预设的时间间隔内再次发送的关于所述第一域名的域名解析请求时，提取出所述第一域名解析请求中的源地址和所述第一域名。
3.如权利要求1所述的方法，其特征在于，所述判断所述第二域名解析请求中的源地址与所述第二域名中包含的所述用户端的cookie是否匹配包括: 根据所述预设算法计算所述第二域名解析请求中的源地址，得到计算结果； 判断所述计算结果与所述第二域名中包含的所述用户端的cookie是否匹配。
4.如权利要求1所述的方法，其特征在于，所述方法还包括: 将所述用户端的源地址加入至白名单中； 当接收到所述用户端发送的第五域名解析请求时，检测所述第五域名解析请求中的源地址是否位于所述白名单中； 当检测出所述第五域名解析请求中的源地址位于所述白名单之后，直接将所述第五域名解析请求转发至所述权威DNS服务器。
5.如权利要求1?4任一项所述的方法，其特征在于，所述第一响应包括NS响应，所述第二响应包括CNAME响应。
6.一种网络攻击的防护装置，其特征在于，包括: 第一接收单元，用于接收用户端发送的关于第一域名的第一域名解析请求，提取出其中的源地址和所述第一域名； 生成单元，用于基于所述第一域名生成包含所述用户端的cookie的第二域名，所述用户端的cookie为根据预设算法计算所述第一域名解析请求中的源地址得到； 第一返回单元，用于向所述用户端返回第一响应，所述第一响应中携带了所述第二域名，以使所述用户端根据所述第一响应返回关于所述第二域名的第二域名解析请求； 提取单元，用于在所述第二域名解析请求中提取源地址和所述第二域名； 第二返回单元，用于判断所述第二域名解析请求中的源地址与所述第二域名中包含的所述用户端的cookie是否匹配，是则向所述用户端返回第二响应，所述第二响应中携带了所述第一域名，以使所述用户端根据所述第二响应返回关于所述第一域名的第三域名解析请求； 第一转发单元，用于将所述第三域名解析请求转发给权威域名服务系统DNS服务器。
7.如权利要求6所述的装置，其特征在于，所述装置还包括: 第二接收单元，用于接收并记录所述用户端发送的关于所述第一域名的第四域名解析请求； 丢弃单元，用于丢弃所述第四域名解析请求，以使所述用户端在预设的时间间隔内发送关于所述第一域名的所述第一域名解析请求； 则所述第一接收单元包括: 接收子单元，用于接收所述用户端发送的所述第一域名解析请求； 第一判断子单元，用于判断所述第一域名解析请求是否为所述用户端在所述预设的时间间隔内再次发送的关于所述第一域名的域名解析请求； 提取子单元，用于当判断出所述第一域名解析请求为所述用户端在所述预设的时间间隔内再次发送的关于所述第一域名的域名解析请求时，提取出所述第一域名解析请求中的源地址和所述第一域名。
8.如权利要求6所述的装置，其特征在于，所述第二返回单元包括: 计算子单元，用于根据所述预设算法计算所述第二域名解析请求中的源地址，得到计算结果； 第二判断子单元，用于判断所述计算结果与所述第二域名中包含的所述用户端的cookie是否匹配。
9.如权利要求6所述的装置，其特征在于，所述装置还包括: 加入单元，用于将所述用户端的源地址加入至白名单中； 检测单元，用于当接收到所述用户端发送的第五域名解析请求时，检测所述第五域名解析请求中的源地址是否位于所述白名单中； 第二转发单元，用于当检测出所述第四域名解析请求中的源地址位于所述白名单之后，直接将所述第五域名解析请求转发至所述权威DNS服务器。
10.如权利要求6?9任一项所述的装置，其特征在于，所述第一响应包括NS响应，所述第二响应包括CNAME响应。
【文档编号】H04L29/12GK104378450SQ201310350396
【公开日】2015年2月25日 申请日期:2013年8月12日 优先权日:2013年8月12日
【发明者】罗喜军, 白惊涛 申请人:深圳市腾讯计算机系统有限公司