CN115174518A - 一种基于rpz的递归侧域名保全方法及系统 - Google Patents

一种基于rpz的递归侧域名保全方法及系统 Download PDF

Info

Publication number
CN115174518A
CN115174518A CN202210671803.4A CN202210671803A CN115174518A CN 115174518 A CN115174518 A CN 115174518A CN 202210671803 A CN202210671803 A CN 202210671803A CN 115174518 A CN115174518 A CN 115174518A
Authority
CN
China
Prior art keywords
rpz
domain name
zone
server
file
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
Application number
CN202210671803.4A
Other languages
English (en)
Other versions
CN115174518B (zh
Inventor
张宇
尚卓群
宫宛莹
方滨兴
张伟哲
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Harbin Institute of Technology
Peng Cheng Laboratory
Original Assignee
Harbin Institute of Technology
Peng Cheng Laboratory
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Harbin Institute of Technology, Peng Cheng Laboratory filed Critical Harbin Institute of Technology
Priority to CN202210671803.4A priority Critical patent/CN115174518B/zh
Publication of CN115174518A publication Critical patent/CN115174518A/zh
Application granted granted Critical
Publication of CN115174518B publication Critical patent/CN115174518B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H04L61/103—Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/11—File system administration, e.g. details of archiving or snapshots
    • G06F16/122—File system administration, e.g. details of archiving or snapshots using management policies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/14—Details of searching files based on file metadata
    • G06F16/148—File search processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/172—Caching, prefetching or hoarding of files
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • H04L61/3015—Name registration, generation or assignment
    • H04L61/3025—Domain name generation or assignment

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Human Computer Interaction (AREA)
  • Library & Information Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请公开了一种基于RPZ的递归侧域名保全方法及系统。其中方法包括：配置递归服务器，包括：添加RPZ区；为DNS软件启用RPZ选项；在RPZ区文件中增加指定域名相关的可信记录；将RPZ区下的域名解析转发给RPZ服务器；所述递归服务器用于应答客户端对任意域名的解析请求；配置RPZ服务器，包括：添加可信区；在可信区文件中增加指定域名相关的可信记录；所述RPZ服务器是指网络中支持下发RPZ规则的服务器；递归服务器和RPZ服务器在网络上连通，且二者的DNS软件配置文件可修改；所述RPZ区是指包含被保护域名的别名记录的一个可信区；可信区是指存放可信记录的区域。本发明可用于为互联网用户提供使用互联网时的安全保障，以防止域名无法被正确解析。

Description

一种基于RPZ的递归侧域名保全方法及系统
技术领域
本发明涉及域名保全技术领域，具体涉及一种基于RPZ的递归侧域名保全方法及系统。
背景技术
当前的DNS(Domain Name System)体系中存在权力滥用的风险。在RFC7720中规定：所有的根服务器都要使用IANA(The Internet Assigned Numbers Authority，互联网数字分配机构)提供的根区，那么这样存在的风险就是：如果因为IANA的职能受到破坏，而在根区中删除或篡改了一个ccTLD(Country Code Top-level Domain，国家代码顶级域)，那么就会导致该ccTLD下的域名无法被解析或者被错误地解析，也就会导致互联网用户无法正常地访问该ccTLD下的域名对应的服务。
发明内容
本申请的目的在于克服上述问题或者至少部分地解决或缓减解决上述问题。
根据本发明的一方面，提供一种基于RPZ的递归侧域名保全方法，该方法包括：
配置递归服务器，包括：添加RPZ区；为DNS软件启用RPZ选项；在RPZ区文件中增加指定域名相关的可信记录；将RPZ区下的域名解析转发给RPZ服务器；所述递归服务器用于应答客户端对任意域名的解析请求；
配置RPZ服务器，包括：添加可信区；在可信区文件中增加指定域名相关的可信记录；所述RPZ服务器是指网络中支持下发RPZ规则的服务器；
所述递归服务器和所述RPZ服务器在网络上连通，且二者的DNS软件配置文件可修改；
所述RPZ区是指包含被保护域名的别名记录的一个可信区；所述可信区是指存放可信记录的区域；所述RPZ区文件和所述可信区文件是指可信区中由DNS名称空间中的单个区域或紧密相邻的多个子域组成的管理单位所对应的内容文件。
进一步地，所述添加RPZ区或所述添加可信区的具体步骤包括：对输入的区域信息进行格式处理；寻找目的本地区域配置文件所在路径；对目的本地区域配置文件进行修改，追加该区域信息；输出目的本地区域配置文件。
进一步地，所述在RPZ区文件中增加指定域名相关的可信记录或所述在可信区文件中增加指定域名相关的可信记录的具体步骤包括：获取该指定域名相关的资源记录；在DNS软件配置文件中搜索是否存在该指定域名的相关资源记录，若存在且相同则直接保存；若存在但矛盾则将原有资源记录覆盖；若不存在则将该指定域名相关的资源记录添加到DNS软件配置文件的末尾，不做其他修改。
根据本发明的另一方面，提供一种基于RPZ的递归侧域名保全系统，该系统包括递归服务器和RPZ服务器，所述递归服务器和所述RPZ服务器在网络上连通，且二者的DNS软件配置文件可修改；
所述递归服务器用于应答客户端对任意域名的解析请求；所述递归服务器包括第一区添加模块、RPZ启用模块、转发配置模块和RPZ配置模块；其中，
所述第一区添加模块用于添加RPZ区；所述RPZ启用模块用于为DNS软件启用RPZ选项；所述转发配置模块用于将RPZ区下的域名解析转发给RPZ服务器；所述RPZ配置模块用于在RPZ区文件中增加指定域名相关的可信记录；
所述RPZ服务器是指网络中支持下发RPZ规则的服务器；所述RPZ服务器包括第二区添加模块、可信区配置模块；其中，所述第二区添加模块用于添加可信区；所述可信区配置模块用于在可信区文件中增加指定域名相关的可信记录；
所述RPZ区是指包含被保护域名的别名记录的一个可信区；所述可信区是指存放可信记录的区域；所述RPZ区文件和所述可信区文件是指可信区中由DNS名称空间中的单个区域或紧密相邻的多个子域组成的管理单位所对应的内容文件。
进一步地，所述第一区添加模块和所述第二区添加模块中添加RPZ区或添加可信区的具体步骤包括：对输入的区域信息进行格式处理；寻找目的本地区域配置文件所在路径；对目的本地区域配置文件进行修改，追加该区域信息；输出目的本地区域配置文件。
进一步地，所述RPZ配置模块和所述可信区配置模块中在RPZ区文件或在可信区文件中增加指定域名相关的可信记录的具体步骤包括：获取该指定域名相关的资源记录；在DNS软件配置文件中搜索是否存在该指定域名的相关资源记录，若存在且相同则直接保存；若存在但矛盾则将原有资源记录覆盖；若不存在则将该指定域名相关的资源记录添加到DNS软件配置文件的末尾，不做其他修改。
根据本发明的另一方面，还提供一种计算机设备，包括存储器、处理器和存储在所述存储器内并能由所述处理器运行的计算机程序，其中，所述处理器执行所述计算机程序时实现上述的基于RPZ的递归侧域名保全方法。
根据本发明的另一方面，还提供一种计算机程序产品，包括计算机可读代码，当所述计算机可读代码由计算机设备执行时，导致所述计算机设备执行上述的基于RPZ的递归侧域名保全方法。
本发明的有益技术效果是：
在当前DNS体系下，本发明提供一种基于RPZ的递归侧域名保全方法及系统，用于为互联网用户提供使用互联网时的安全保障，以防止在IANA由于其职能遭到破坏而对某些TLD的记录进行篡改的情况下，该TLD下的域名无法被正确解析的情况发生。
附图说明
本发明可以通过参考下文中结合附图所给出的描述而得到更好的理解，所述附图连同下面的详细说明一起包含在本说明书中并且形成本说明书的一部分，而且用来进一步举例说明本发明的优选实施例和解释本发明的原理和优点。
图1是RPZ原理示意图；
图2是本发明一种基于RPZ的递归侧域名保全方法的原理示意图；
图3是本发明一种基于RPZ的递归侧域名保全系统的结构示意图；
图4是本发明实施例中转发配置模块的转发流程示意图；
图5是本发明实施例中不同数据量下方案性能对比图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案，在下文中将结合附图对本发明的示范性实施方式或实施例进行描述。显然，所描述的实施方式或实施例仅仅是本发明一部分的实施方式或实施例，而不是全部的。基于本发明中的实施方式或实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施方式或实施例，都应当属于本发明保护的范围。
RPZ(Response Policy Zones，应答策略区)是由Paul Vixie主导的ISC(internetsystems consortium，互联网系统联盟)机构在2010年提出的互联网草案，是一种针对DNS的网络安全解决方案，利用已知的恶意域名或IP干预域名解析过程影响域名解析结果，可以将正常的解析请求响应以域不存在(NXDOMAIN)、IP地址不存在(NODATA)或使用其他IP地址或数据的方式防止互联网用户访问。RPZ本质是一种描述和传递DNS防火墙配置数据的方法，它使用特殊格式的DNS区域文件完成，该文件的编辑或生成方式与其他DNS区域文件相同，并且使用相同的DNS区域传输协议。由于DNS区域传输是增量式的，且目前可以对DNS区域进行实时更改，使得RPZ所用区域文件的同步既高效又可靠。
RPZ原理图如图1所示，当客户端试图请求启用RPZ的DNS服务器对恶意站点域名进行解析时，启用RPZ的DNS服务器会以近乎实时的效率从RPZ规则清单提供点更新RPZ规则，其中RPZ规则一般由ISP(Internet Service Provider，互联网服务提供商)从各方收集，然后给启用RPZ的DNS服务器提供RPZ规则清单；如果客户端请求解析的域名是清单中的恶意域名或IP是恶意IP，则会根据设定对本次解析进行阻止；启用RPZ的DNS服务器会返回给客户端一个解析失败的应答报文或给出一个ISP提供的警示页面，最终避免客户端访问恶意站点。
基于RPZ的DNS防火墙与其他防火墙是具有相似性的，只是过滤的位置在路径上而不是在内容上。DNS防火墙不会阻止解析动作，而是改变了原来的解析路径从而对解析答案进行了改变。在RPZ规则提供商的策略中，这种改变主要有以下三种表现：
1)如果检测到域名是恶意的，可以阻止客户端访问或将恶意站点重定向；
2)如果检测到恶意的IP地址或子网，可以阻止客户端访问其下的主机；
3)如果检测到一个只有恶意域的名称服务器，可以阻止客户端获取由该服务器托管的DNS信息。
RPZ的初衷是保护用户免受互联网上与已知的恶意全局标识符(如主机名、域名、IP地址或名称服务器)相关的不良影响，在此之前，RPZ多用于恶意站点过滤，在递归服务器上以区文件的形式来实现对应答的定制，通常作为“防火墙”来过滤恶意域名。
本发明提出一种基于RPZ的递归侧域名保全方法，通过建立可控的RPZ服务器，为启用RPZ的递归解析器提供包含指定域名的RPZ规则，从而达到保全域名的目的。基于RPZ实现递归侧的域名保全有两个优点：一是不改变原有的DNS服务逻辑，不会影响到其它域名的正常解析；二是没有对域名具体的限制，可以对任意域名执行保全操作。通过在递归服务器上使用基于RPZ的域名保全技术，不改变递归服务器对根服务器的指向，直接操作递归服务器解析结果，达到域名保全目的。基于RPZ的域名保全通过在递归服务器配置RPZ来自定义区文件，绕过对不可信域名服务器的查询。
如图2所示，具体技术原理为：本地RPZ区文件(db.rpz.local)中将被保护的域名的CNAME(代表域名与其别名的对应关系的记录类型)设置在一个可信区中(correct)，并将correct区设置为转发模式，指向RPZ服务器(correct的权威服务器)，从而“绕过”不可信的域名服务器。RPZ区是指包含被保护域名的别名记录的一个可信区；可信区是指存放可信记录的区域。
本发明还提出一种基于RPZ的递归侧域名保全系统，该系统涉及RPZ服务器和递归服务器，如图3所示，主要包括：
1)区添加模块：为RPZ服务器(对应第二区添加模块)和递归服务器(对应第一区添加模块)增加correct区(可信区)；
2)correct区配置模块(可信区配置模块)：位于RPZ服务器上，负责为RPZ服务器增加本地correct解析内容，即用于在可信区文件中增加指定域名相关的可信记录；
3)RPZ启用模块：位于递归服务器上，负责为BIND启用RPZ选项；
4)转发配置模块：位于递归服务器上，负责在RPZ服务器上对correct区声明查询转发模式，即用于将RPZ区下的域名解析转发给RPZ服务器；
5)RPZ配置模块：负责为递归服务器增加RPZ解析内容，即用于在RPZ区文件中增加指定域名相关的可信记录；
其中概念解释如下：
a.RPZ服务器是指网络中支持下发RPZ规则的服务器；RPZ规则在现实网络中有众多提供源，如：DissectCyber提供的rpzone.us、FarsightSecurity提供的Newly ObservedDomains and example、InfoBlox提供的DNS firewall、SURBL提供的Data Feed、SWITCH提供的SWITCHDNS FireWall等等，本发明实施例中RPZ规则由管理人员在RPZ服务器上制定；
b.递归服务器负责应答客户端对任意域名的解析请求，在接收客户端发送的DNS查询后，递归解析器优先使用缓存的数据进行响应，在缓存命中失败时向根服务器发送请求，在此过程中，递归服务器会缓存从权威服务器得到的每个解析结果，接着递归地向名称服务器发送解析请求，直至收到域名解析结果，最后将向客户端发送响应。
c.区文件是指由DNS名称空间中的单个区域或紧密相邻的多个子域组成的管理单位所对应的内容文件，其格式应满足ISC制定的要求：(https://bind9.readthedocs.io/en/latest/reference.html？highlight＝zone#zone-types)；
d.BIND是一个开源的DNS软件，用于实现DNS服务器的域名解析服务，是目前世界上使用最为广泛的DNS软件。
本发明第一实施例提供一种基于RPZ的递归侧域名保全方法，该方法的具体流程如下：
步骤一、准备一台可控的RPZ服务器和一台可控的递归服务器，二者在网络上连通，且其DNS软件配置可供修改；
步骤二、启动区添加模块，修改named.conf.local文件在RPZ服务器和递归服务器上的BIND配置文件添加RPZ区；
步骤三、在RPZ服务器上启动correct区配置模块，修改db.correct文件在correct区文件中增加指定域名相关的可信记录，后续解析将以该记录为解析结果；
步骤四、在递归服务器上启动RPZ启用模块，修改named.conf.options文件，选择启用RPZ选项；
步骤五、在递归服务器上启动RPZ配置模块，修改db.rpz.local文件，在RPZ区文件中增加指定域名的相关记录，而后将针对这些记录进行解析请求转发；
步骤六、在递归服务器上启动转发配置模块，修改named.conf.default-zones文件，将correct区下的域名解析转发给RPZ服务器进行解析。
在客户端向递归服务器发起对RPZ保全域名的解析请求时，递归服务器会查找保全域名所对应的RPZ域名，并根据递归服务器配置的转发规则，将该解析请求转发给RPZ服务器，RPZ服务器会在本地找到该域名的记录，将其返回给递归服务器，最后由递归服务器返回给客户端。如此，客户端对RPZ保全域名的解析结果不再是源于该域名所对应的权威服务器，而是源于可控的RPZ服务器。
下面以DNS软件-BIND为例说明各个模块的实现细节。
1.区添加模块：用于修改DNS软件的本地区域配置文件，在该文件中进行区域的增加。
根据本发明实施例，该模块是域名保全程序的一部分，以区域信息为输入，经过数据处理后输出修改好的本地区域配置文件。区添加模块的具体工作流程如下：
步骤二一、对输入的区域信息进行格式处理；
步骤二二、寻找目的本地区域配置文件所在路径；
步骤二三、对目的本地区域配置文件进行修改，追加该区域信息；具体地，在目的本地区域配置文件中查询是否该区域已经存在，如果存在发出警告，并撤销操作；如果不存在则将区域信息追加至该文件的末尾处；
步骤二四、输出目的本地区域配置文件。
其中，named.conf.local文件格式如下：
Figure BDA0003694926790000061
其中：string字段为该区域的名称，为字符串形式；class字段为该区域的类别，可以选填IN(Internet)、HS(hesiod)、CHAOS等，默认为IN类别；type关键字的配置是必需的，primary(也写作master)，包含相应DNS命名空间所有的资源记录，是区域中所包含的所有DNS域的权威DNS服务器；allow-query字段表示允许那些主机进行DNS查询，如未指定，则默认允许来自所有主机的查询；allow-query-on字段表示允许接受DNS查询的本地地址列表，这可以运行于在面向内部的接口上进行查询；allow-transfer字段表示允许进行区域传输的主机列表，如未指定，则默认允许所有主机进行区域传输；allow-update字段表示允许进行DNS动态更新提交的主机列表，若未指定，则默认拒绝来自所有主机的更新请求；also-notify字段表示当发生新的区域载入时需要通知的所有服务器的列表，若未指定，则默认无需向任何主机推送更新通知；alt-transfer-source字段表示服务器用于接收TCP/UDP连接的IPv4地址，若未指定，则默认使用系统推荐值；alt-transfer-source-v6字段表示服务器用于接收TCP/UDP连接的IPv6地址，若未指定，则默认使用系统推荐值；auto-dnssec字段表示允许动态DNS配置的不同级别的DNSSEC密钥管理，可选值有allow(用户发出命令时允许更新密钥和数据重签)、maintain(在allow的基础上根据密钥的时间元数据自动调整区域DNSSEC密钥)、off(不允许用户进行密钥管理)，若未指定，则默认设置为off；file字段表示该区域所对应的区域文件所在的路径。
DNS服务器可以对区域中所有资源记录进行读写，即可以修改此区域中的数据，默认情况下区域数据均以文本文件格式存放。
本实施例中，第一区添加模块对递归服务器的named.conf.local文件内容修改为：在区添加模块修改的named.conf.local文件中添加一个名为“rpz.local”的区，在该区的描述字段中需要声明的有type、file、allow-query、allow-transfer，其中：type取值为master；file为实际系统中区域文件所在路径；allow-query取值为any，允许任何主机的DNS查询；allow-transfer取值为any，允许任何主机的区域传输。
本实施例中，第二区添加模块对RPZ服务器的named.conf.local文件内容修改为：在区添加模块修改的named.conf.local文件中添加一个名为“correct”的区，在该区的描述字段中需要声明的有type、file、allow-query、allow-transfer，其中：type取值为master；file为实际系统中区域文件所在路径；allow-query取值为any，允许任何主机的DNS查询；allow-transfer取值为any，允许任何主机的区域传输。
本实施例中，区添加模块对named.conf.local文件内容修改的步骤如下：
步骤二三一、由管理人员确定或者从可信数据源获取该区域信息；
步骤二三二、在该文件中搜索是否存在该区域信息，如果存在则执行步骤二三三，否则执行步骤二三五；
步骤二三三、将文件中原有的区域记录与步骤二三一中得到的区域信息相同则无需操作，执行步骤二三六；
步骤二三四、如果文件中原有的区域信息与步骤二三一中的区域信息存相互矛盾，则使用步骤二三一中的区域信息将原有的区域信息覆盖，执行步骤二三六；
步骤二三五、只需将该域对应的区域信息添加到该文件的末尾，而无需对其它内容做出修改；
步骤二三六、保存修改的内容。
2.correct区配置模块：用于修改db.correct文件在correct区文件中增加指定域名相关的可信记录。
根据本发明实施例，首先说明BIND的数据文件格式。BIND数据文件一般以“db”为前缀，由数条资源记录组成，资源记录类型的定义及功能[见IETF RFC1034](SOA、NS、A、AAAA)和[IETF RFC4034](DNSKEY、NSEC、DS、RRSIG)及表1。资源记录条目之间以换行符“\n”结束，每个资源记录条目中各字段之间以制表符“\t”分隔，字段内各项以空格分割。
表1 资源记录类型表
Figure BDA0003694926790000081
RPZ服务器的db.correct文件作为BIND数据文件，在满足BIND数据文件的格式前提下，还要包含correct.的SOA记录、NS记录及其胶水记录，需要注意的是该域的权威服务器应使用127.0.0.1作为其IP地址。
本实施例中，correct区配置模块对RPZ服务器的db.correct文件内容修改的步骤如下：
步骤三一、db.correct中应包含目的保护域名的CNAME记录，A记录。每次增加保护域名时由管理人员确定或者从可信数据源获取该域相关的资源记录；
步骤三二、在该文件中搜索是否存在该域名的相关资源记录，如果存在则执行步骤三三，否则执行步骤三五；
步骤三三、将文件中原有的资源记录与步骤三一中得到的资源记录相同则无需操作，执行步骤三六；
步骤三四、如果文件中原有的资源记录与步骤三一中的资源记录存相互矛盾，则使用步骤三一中的资源记录将原有的资源记录覆盖，执行步骤三六；
步骤三五、只需将该域名所对应的资源记录添加到该文件的末尾，而无需对其它内容做出修改；
步骤三六、保存修改的内容。
3.RPZ启用模块：负责为BIND启用RPZ，修改named.conf.options文件，选择启用RPZ选项。
根据本发明实施例，named.conf.options文件格式如下：
Figure BDA0003694926790000092
其中：allow-new-zones字段可取yes或no，yes表示允许在BIND运行时通过rndcaddzone添加新区，no表示不允许，如未指定，则默认为no；allow-query字段表示允许进行DNS查询的主机列表，如未指定，则默认允许来自所有主机的查询；allow-query-cache字段表示允许从缓存中获取DNS查询答案的主机列表，如未指定，则默认允许来自所有主机的查询；allow-query-cache-on字段指定了允许使用缓存数据发送DNS查询答案的本地IP地址列表；allow-query-on字段表示允许接受DNS查询的本地地址列表，这可以运行于在面向内部的接口上进行查询；allow-recursion字段表示允许通过此服务器进行递归查询的主机列表，如果没有设置这些参数，则使用默认值(localnets；localhost；)response-policy字段中：string字段为该区域的名称，为字符串形式；add-soa选项表示是否将RPZ的SOA记录添加以追溯该区的更改，默认值为yes；Log选项表示可以选择性针对一个特定区域关闭重写日志，默认为开启。
4.转发配置模块：用于修改named.conf.default-zones文件，将correct区下的域名解析转发给RPZ服务器进行解析。
根据本发明实施例，named.conf.default-zones文件格式如下：
Figure BDA0003694926790000091
Figure BDA0003694926790000101
其中：type字段设为forward代表这是一个“转发域”。一个”转发域”是一种在每个域基础上进行配置转发的一种方式；delegation-only字段用于执行基础设施区(比如：COM，NET，ORG)的delegation-only的状态。任何接收到的在AUTHORITY SECTION字段没有显性或隐性的代理的应答都会被视为NXDOMAIN。这不能应用于区顶点，并且不应该被用于叶区；forward字段，此选项只有当forwarders列表中有内容的时候才有意义。当值是First时，服务器先查询设置的forwarders，如果它没有得到回答，服务器就会自己寻找答案。如果设定的是only，服务器就只会把请求转发到其它服务器上去；forwarders字段用于设定转发使用的ip地址，默认的列表是空的，即不转发给任何机器。其中port是端口号，dscp是区分服务代码点(differentiated services code point)。
如图4所示，转发的具体流程为：
假设递归解析器A上配置了域“cn.”为一个转发域，将对cn.下域名从查询抓发给IP地址为10.10.11.11的机器B。当客户机向解析器A发起了一个对cn.下的域名的查询时(比如是www.test.cn.的A记录)，递归解析器A就会根据转发域“cn.”的配置将此查询转发给forwarders中的某个IP地址的机器(这里是IP地址为10.10.11.11的解析器B)，解析器B收到这条查询后，根据其内部配置，有可能继续转发(在解析器B中也将cn.配置成了一个“转发域”)，也有可能进行递归或迭代查询，也有可能其本身就记录了这条查询的结果(解析器B配置为cn.的权威服务器，其本身就记录了cn.下域名的记录)，无论采用哪种方式，解析器B最终都会将这条查询的结果返回给解析器A，在解析器A收到解析器B返回给它的结果记录后，再将此条查询的结果记录返回给客户机。
5.RPZ配置模块：用于修改db.rpz.local文件，在RPZ区文件中增加指定域名的相关记录。
根据本发明实施例，db.rpz.local文件格式如下：
Figure BDA0003694926790000102
Figure BDA0003694926790000111
针对一个要采用RPZ方案来进行保全的域名，在db.rpz.local中为其增加一条如下的记录：“${domain}IN CNAME*.correct.”，其中${domain}是要保全的域名，这样做的好处是对于所有要保全的域名，经过RPZ后，其别名都变成了以correct.结尾的域名，这样只需要在correct.的权威服务器中配置相应的域名的可信记录即可完成域名保全，具体方案如下。
需要机器的个数为2，一台为递归解析器，一台为RPZ服务器。
递归解析器的配置：在递归解析器上完成RPZ的配置(named.conf.options以及db.rpz.local的配置)，并添加转发域“correct.”(在named.conf.default-zones中配置)，转发域配置中forwarders中应该填写RPZ服务器的信息。
RPZ服务器的配置：在RPZ服务器上配置correct区(参考上述的“correct区配置模块”)。
对于一个要保全的域名，需要进行两部操作。
第一步：在递归解析器中，将此域名添加到db.rpz.loacl中。比如：要保全的域名为www.test.cn.，那么在db.rpz.local要添加的一条记录就是“www.test.cn IN CNAME*.correct.”。然后重启DNS软件(以BIND9为例，sudo service bind9 restart)。之后，对递归解析器进行查询www.test.cn.，就会变成对www.test.cn.correct.的查询。
第二步：在RPZ服务器中，添加此域名的可信记录。由于在递归解析器中已经将此域名的别名设为*.correct.，所以在RPZ服务器中，应该在correct.区中配置可信记录。比如：实际的可信记录为：“www.test.cn.12400IN A 123.123.123.123”，那么在correct.区中配置的记录应该为“www.test.cn.correct.12400IN A 123.123.123.123”。
完成上述步骤后，用户对一个被保全的域名(以www.test.cn.为例)查询的实际流程为：用户向递归解析器发起一个查询，查询内容为www.test.cn.的A记录；递归解析器接收到用户对www.test.cn.的A记录的查询，发现www.test.cn.在RPZ区中，然后对www.test.cn.的A记录的查询变为对www.test.cn.correct.的A记录的查询。递归解析器中将correct.区配置为了“转发区”，(forwarders列表中存放了RPZ服务器的信息)，递归解析器将对www.test.cn.correct.的A记录的查询转发给了RPZ服务器。RPZ服务器接收到递归解析器对其发起的www.test.cn.correct.的A记录的查询，发现其本身就是correct.的权威服务器，所以RPZ服务器就会检索自己的correct.区中是否有www.test.cn.correct.的A记录，由于在第二步中已经将此条可信记录加入到RPZ服务器的correct.区中，所以RPZ服务器直接就会在correct.区中找到对www.test.cn.correct.的A记录查询的结果记录。RPZ服务器将结果记录返回给递归解析器。递归解析器在收到RPZ服务器发来的结果记录后，将此记录返回给用户。用户收到递归解析发来的查询的结果，此次查询完成。
进一步通过实验验证本发明的技术效果。
实验需要递归侧配合开启RPZ，并允许对其配置文件进行修改，且需要在网络上允许与RPZ服务器的连接；RPZ有最大的策略区数量限制，不可以超过64个。
目前支持RPZ的DNS软件如表2所示。
表2 支持RPZ的DNS软件列表
提供商 软件名称
Akamai AnswerX
BlueCat BlueCat DNS
EfficientIP SolidServer
InfoBlox DNS Firewall
ISC BIND 9
Knot policy.rpz module
NLnet Labs NLnet Labs Unbound
PowerDNS PowerDNS Recursor 4.0.0 and higher
RPZ会影响服务器性能。每个配置的响应策略区要求服务器在可以回答查询之前执行一到四次额外的数据库查找。例如，具有四个策略区域的DNS服务器，每个具有所有四种响应触发器(QNAME、IP、NSIP和NSDNAME)，所需的数据库查找次数是没有响应策略区域DNS服务器的17倍.具有足够内存和一个具有QNAME和IP触发器的响应策略区域的BIND 9服务器的最大每秒查询(QPS)率降低约20％。具有四个具有QNAME和IP触发器的响应策略区域的服务器的QPS可能会降低约50％。
域名解析速度对比见表3所示。
表3
Figure BDA0003694926790000121
RPZ规则中一个区域的内容量为262时与263时的查询延迟对比如图5所示，可以看出本发明对于数据量的敏感度并不高，基本可以满足一般数据量下的性能保证。
综上，本发明使用RPZ无需修改原根提示，所以并不影响其它域名的正常解析；使用RPZ可以最小细粒度控制域名解析，可以针对单个域名级别进行管控；使用RPZ可以保护任何域名，无论是国家顶级域还是通用顶级域等其它类型顶级域下的子域中的任何域名都可以应用该方案；不会因模块程序带来额外的安全问题，所有模块程序都独立于DNS软件之外，只是修改了部分域名的解析逻辑，所有通信过程仍由DNS软件进行。
本发明第二实施例还提供了一种计算设备，该计算设备包括存储器、处理器和存储在所述存储器内并能由所述处理器运行的计算机程序，该计算机程序存储于存储器中的用于程序代码的空间，该计算机程序在由处理器执行时实现用于执行任一项根据本发明的方法步骤。
本申请第三实施例还提供了一种计算机可读存储介质，该计算机可读存储介质包括用于程序代码的存储单元，该存储单元设置有用于执行根据本发明的方法步骤的程序，该程序被处理器执行。
本申请第四实施例还提供了一种包含指令的计算机程序产品，包括计算机可读代码，当所述计算机可读代码由计算设备执行时，导致所述计算设备执行如上所述的方法。
尽管根据有限数量的实施例描述了本发明，但是受益于上面的描述，本技术领域内的技术人员明白，在由此描述的本发明的范围内，可以设想其它实施例。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。

Claims (8)

1.一种基于RPZ的递归侧域名保全方法，其特征在于：
配置递归服务器，包括：添加RPZ区；为DNS软件启用RPZ选项；在RPZ区文件中增加指定域名相关的可信记录；将RPZ区下的域名解析转发给RPZ服务器；所述递归服务器用于应答客户端对任意域名的解析请求；
配置RPZ服务器，包括：添加可信区；在可信区文件中增加指定域名相关的可信记录；所述RPZ服务器是指网络中支持下发RPZ规则的服务器；
所述递归服务器和所述RPZ服务器在网络上连通，且二者的DNS软件配置文件可修改；
所述RPZ区是指包含被保护域名的别名记录的一个可信区；所述可信区是指存放可信记录的区域；所述RPZ区文件和所述可信区文件是指可信区中由DNS名称空间中的单个区域或紧密相邻的多个子域组成的管理单位所对应的内容文件。
2.根据权利要求1所述的一种基于RPZ的递归侧域名保全方法，其特征在于：所述添加RPZ区或所述添加可信区的具体步骤包括：对输入的区域信息进行格式处理；寻找目的本地区域配置文件所在路径；对目的本地区域配置文件进行修改，追加该区域信息；输出目的本地区域配置文件。
3.根据权利要求2所述的一种基于RPZ的递归侧域名保全方法，其特征在于：所述在RPZ区文件中增加指定域名相关的可信记录或所述在可信区文件中增加指定域名相关的可信记录的具体步骤包括：获取该指定域名相关的资源记录；在DNS软件配置文件中搜索是否存在该指定域名的相关资源记录，若存在且相同则直接保存；若存在但矛盾则将原有资源记录覆盖；若不存在则将该指定域名相关的资源记录添加到DNS软件配置文件的末尾，不做其他修改。
4.一种基于RPZ的递归侧域名保全系统，其特征在于：包括递归服务器和RPZ服务器，所述递归服务器和所述RPZ服务器在网络上连通，且二者的DNS软件配置文件可修改；
所述递归服务器用于应答客户端对任意域名的解析请求；所述递归服务器包括第一区添加模块、RPZ启用模块、转发配置模块和RPZ配置模块；其中，
所述第一区添加模块用于添加RPZ区；所述RPZ启用模块用于为DNS软件启用RPZ选项；所述转发配置模块用于将RPZ区下的域名解析转发给RPZ服务器；所述RPZ配置模块用于在RPZ区文件中增加指定域名相关的可信记录；
所述RPZ服务器是指网络中支持下发RPZ规则的服务器；所述RPZ服务器包括第二区添加模块、可信区配置模块；其中，所述第二区添加模块用于添加可信区；所述可信区配置模块用于在可信区文件中增加指定域名相关的可信记录；
所述RPZ区是指包含被保护域名的别名记录的一个可信区；所述可信区是指存放可信记录的区域；所述RPZ区文件和所述可信区文件是指可信区中由DNS名称空间中的单个区域或紧密相邻的多个子域组成的管理单位所对应的内容文件。
5.根据权利要求4所述的一种基于RPZ的递归侧域名保全系统，其特征在于：所述第一区添加模块和所述第二区添加模块中添加RPZ区或添加可信区的具体步骤包括：对输入的区域信息进行格式处理；寻找目的本地区域配置文件所在路径；对目的本地区域配置文件进行修改，追加该区域信息；输出目的本地区域配置文件。
6.根据权利要求5所述的一种基于RPZ的递归侧域名保全系统，其特征在于：所述RPZ配置模块中在RPZ区文件中增加指定域名相关的可信记录或所述可信区配置模块中在可信区文件中增加指定域名相关的可信记录的具体步骤包括：获取该指定域名相关的资源记录；在DNS软件配置文件中搜索是否存在该指定域名的相关资源记录，若存在且相同则直接保存；若存在但矛盾则将原有资源记录覆盖；若不存在则将该指定域名相关的资源记录添加到DNS软件配置文件的末尾，不做其他修改。
7.一种计算机设备，其特征在于：包括存储器、处理器和存储在所述存储器内并能由所述处理器运行的计算机程序，其中，所述处理器执行所述计算机程序时实现权利要求1-3中任一项所述的基于RPZ的递归侧域名保全方法。
8.一种计算机程序产品，其特征在于：包括计算机可读代码，当所述计算机可读代码由计算机设备执行时，导致所述计算机设备执行权利要求1-3中任一项所述的基于RPZ的递归侧域名保全方法。
CN202210671803.4A 2022-06-15 2022-06-15 一种基于rpz的递归侧域名保全方法及系统 Active CN115174518B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210671803.4A CN115174518B (zh) 2022-06-15 2022-06-15 一种基于rpz的递归侧域名保全方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210671803.4A CN115174518B (zh) 2022-06-15 2022-06-15 一种基于rpz的递归侧域名保全方法及系统

Publications (2)

Publication Number Publication Date
CN115174518A true CN115174518A (zh) 2022-10-11
CN115174518B CN115174518B (zh) 2023-11-21

Family

ID=83485570

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210671803.4A Active CN115174518B (zh) 2022-06-15 2022-06-15 一种基于rpz的递归侧域名保全方法及系统

Country Status (1)

Country Link
CN (1) CN115174518B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116074082A (zh) * 2023-01-28 2023-05-05 鹏城实验室 域名保全方法、域名保全装置及可读存储介质

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104065766A (zh) * 2014-07-14 2014-09-24 北京快易博科技有限公司 一种旁路缓存域名解析方法和系统
US20150207812A1 (en) * 2014-01-17 2015-07-23 Gregory Thomas BACK Systems and methods for identifying and performing an action in response to identified malicious network traffic
US20170041292A1 (en) * 2015-08-04 2017-02-09 Farsight Security, Inc Parallel detection of updates to a domain name system record system using a common filter
US20170054761A1 (en) * 2015-08-18 2017-02-23 Farsight Security, Inc. Lock-free updates to a domain name blacklist
CN106790747A (zh) * 2016-12-13 2017-05-31 北京网瑞达科技有限公司 一种域名系统dns二次递归解析的方法
WO2017173766A1 (zh) * 2016-04-08 2017-10-12 网宿科技股份有限公司 一种域名解析加速方法、系统和装置
US10440059B1 (en) * 2017-03-22 2019-10-08 Verisign, Inc. Embedding contexts for on-line threats into response policy zones
US20210037047A1 (en) * 2019-07-31 2021-02-04 Arbor Networks, Inc. Real time management of botnet attacks
US20210392159A1 (en) * 2020-06-11 2021-12-16 T-Mobile Usa, Inc. Harvesting fully qualified domain names from malicious data packets

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150207812A1 (en) * 2014-01-17 2015-07-23 Gregory Thomas BACK Systems and methods for identifying and performing an action in response to identified malicious network traffic
CN104065766A (zh) * 2014-07-14 2014-09-24 北京快易博科技有限公司 一种旁路缓存域名解析方法和系统
US20170041292A1 (en) * 2015-08-04 2017-02-09 Farsight Security, Inc Parallel detection of updates to a domain name system record system using a common filter
US20170054761A1 (en) * 2015-08-18 2017-02-23 Farsight Security, Inc. Lock-free updates to a domain name blacklist
WO2017173766A1 (zh) * 2016-04-08 2017-10-12 网宿科技股份有限公司 一种域名解析加速方法、系统和装置
CN106790747A (zh) * 2016-12-13 2017-05-31 北京网瑞达科技有限公司 一种域名系统dns二次递归解析的方法
US10440059B1 (en) * 2017-03-22 2019-10-08 Verisign, Inc. Embedding contexts for on-line threats into response policy zones
US20210037047A1 (en) * 2019-07-31 2021-02-04 Arbor Networks, Inc. Real time management of botnet attacks
US20210392159A1 (en) * 2020-06-11 2021-12-16 T-Mobile Usa, Inc. Harvesting fully qualified domain names from malicious data packets

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
戴云伟，沈春苗: "DNS的RPZ安全防护系统的构建、配置与验证", 计算机系统应用 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116074082A (zh) * 2023-01-28 2023-05-05 鹏城实验室 域名保全方法、域名保全装置及可读存储介质
CN116074082B (zh) * 2023-01-28 2023-06-16 鹏城实验室 域名保全方法、域名保全装置及可读存储介质

Also Published As

Publication number Publication date
CN115174518B (zh) 2023-11-21

Similar Documents

Publication Publication Date Title
US10666608B2 (en) Transparent proxy authentication via DNS processing
US10148612B2 (en) Method and system for increasing speed of domain name system resolution within a computing device
US9444781B2 (en) Recursive DNS nameserver
US11606388B2 (en) Method for minimizing the risk and exposure duration of improper or hijacked DNS records
US8762573B2 (en) Reverse DNS lookup with modified reverse mappings
US9807050B2 (en) Protocol addressing for client and destination identification across computer networks
US7558880B2 (en) Dynamic DNS registration method, domain name solution method, DNS proxy server, and address translation device
US20060265516A1 (en) Generic top-level domain re-routing system
US20060218289A1 (en) Systems and methods of registering and utilizing domain names
CN109905496A (zh) 一种基于用户策略的dns智能调度方法
CN115174518B (zh) 一种基于rpz的递归侧域名保全方法及系统
Aitchison Pro DNS and Bind
US11218326B1 (en) System and method for generating current live and test versions of DNS data for rollover
US11297033B2 (en) System and method for generating current live and test versions of DNS data for HSM changes
US20220021639A1 (en) System and method for generating concurrently live and test versions of dns data
Bauer Securing dns and bind
Howser et al. Domain Name Service
US20220006774A1 (en) System and method for publishing dns records of a domain including either signed or unsigned records
Both Name Services
CN115665086A (zh) 基于网管设备的域名解析方法及其装置、电子设备
Belkner et al. 10-Domain Name System

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant