CN106210165B - 基于ns记录分层授权缓解域名权威记录劫持影响的方法 - Google Patents
基于ns记录分层授权缓解域名权威记录劫持影响的方法 Download PDFInfo
- Publication number
- CN106210165B CN106210165B CN201610537040.9A CN201610537040A CN106210165B CN 106210165 B CN106210165 B CN 106210165B CN 201610537040 A CN201610537040 A CN 201610537040A CN 106210165 B CN106210165 B CN 106210165B
- Authority
- CN
- China
- Prior art keywords
- domain name
- service
- record
- emergency
- authoritative
- 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.)
- Active
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/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本发明公开了一种基于NS记录分层授权缓解域名权威记录劫持影响的方法。本方法为:1)在域名解析服务系统中设置一业务应急权威域名服务器组件;该组件中设有若干业务应急子域名;2)当域名NS记录被劫持,顶级权威域名服务器返回错误NS记录时,启动该组件,将业务权威域名服务器的业务域名解析配置信息存储到该组件;3)对于缓存了域名NS记录的递归服务器向业务权威域名服务器查询业务域名的IP地址信息,业务权威域名服务器将该业务域名的CNAME记录指向该组件中一业务应急子域名,并指定其所在的子域的NS记录为该组件的地址,并将对应CNAME记录和NS记录的TTL设置为设定值返回给递归服务器。本发明有效提升用户体验。
Description
技术领域
本发明涉及一种基于NS记录分层授权缓解域名权威记录劫持影响的方法,属于计算机网络技术领域。
背景技术
域名解析服务是互联网的一项关键基础服务,负责帮助用户实现域名和IP地址间的解析过程。互联网业务的域名解析服务通常需要三类组件的参与,即域名注册商、递归域名服务器、权威域名服务器。
如附图1所示,(1)互联网业务在域名注册商处登记业务权威域名服务器的地址信息(即NS记录),域名注册商将该记录信息同步到该业务域名所在的顶级权威域名服务器(例如.com、.net、.cn等等都是顶级域);(2)用户向递归服务器查询业务域名的IP地址;(3)如果递归服务器拥有业务权威域名服务器的NS记录缓存信息,则直接转到(5),否则递归服务器向根权威域名服务器查询,获取该业务域名所在的顶级域名的NS记录;(4)递归服务器向顶级权威域名服务器查询,获取业务域名的NS记录;(5)递归服务器向业务权威域名服务器查询,获取该业务域名的IP地址信息,返回给用户;(6)用户根据获取的IP地址访问该互联网业务。
按照现有的域名解析服务过程,顶级权威域名服务器负责接收域名注册商提供的业务域名的NS记录,并提供给递归服务器。如果域名注册商被入侵,将导致业务域名的NS记录被劫持篡改,并同步到顶级权威域名服务器。根据现有的域名注册以及NS记录更新机制,互联网业务域名的所有者无法阻止上述篡改和同步的风险。在劫持期间内,如果递归服务器的NS记录缓存到期,则递归服务器无法从顶级权威域名服务器获取正确的业务域名的NS记录,从而会导致用户访问失败。2010年1月12日百度域名曾经出现上述类型的劫持事件。根据百度官方报道(http://dudns.baidu.com/support/knowledge/Security/),baidu.com的NS记录被劫持,然后导致www.baidu.com无法访问。事件持续时间8小时,是百度成立以来最严重的故障事件,直接经济损失700万人民币。
发明内容
针对现有技术中存在的技术问题,本发明目的在于提供一种基于NS记录分层授权缓解域名权威记录劫持影响的方法,该方法能够实现在业务域名的NS记录被劫持期间,减少因为递归服务器缓存记录到期导致用户无法访问的影响,从而有效提升用户体验。
本发明的技术方案为:
一种基于NS记录分层授权缓解域名权威记录劫持影响的方法,其步骤为:
1)在域名解析服务系统中设置一业务应急权威域名服务器组件;该业务应急权威域名服务器组件中设有若干业务应急子域名;
2)当域名NS记录被劫持,顶级权威域名服务器返回错误NS记录时,启动该应急权威域名服务器组件,将业务权威域名服务器的业务域名解析配置信息存储到该业务应急权威域名服务器组件;
3)该业务权威域名服务器为每个业务域名CNAME指向该业务应急权威域名服务器组件中的一业务应急子域名,并指定该业务应急子域名所在的子域的NS记录为应急权威域名服务器组件的地址;
4)对于缓存了域名NS记录的递归服务器,该递归服务器向业务权威域名服务器查询业务域名的IP地址信息,业务权威域名服务器将该业务域名的CNAME记录指向该业务应急权威域名服务器组件中的一业务应急子域名,并指定该业务应急子域名所在的子域的NS记录为应急权威域名服务器组件的地址,并将该业务域名的CNAME记录和该业务应急子域名所在的子域的NS记录的TTL设置为设定值,然后返回给该递归服务器。
进一步的,将业务权威域名服务器的业务域名解析配置信息存储到该业务应急权威域名服务器组件的方法为:将业务权威域名服务器中的业务域名通过CNAME记录转移到该应急权威域名服务器组件,再通过该应急权威域名服务器组件进行业务应急子域名的应急子域分层解析,得到与业务权威域名服务器中相同的业务域名解析配置信息。
进一步的,该业务域名权威解析服务的提供方维护该业务应急权威域名服务器组件和该业务权威域名服务器。
进一步的,每一业务域指向的业务应急子域名为该业务域名CNAME下的一子域名。
进一步的,每一业务域指向的业务应急子域名为设定业务域下的一子域名。
进一步的,该递归服务器收到一指定业务域名的IP地址查询请求时,如果已缓存有业务域名到业务应急子域名的CNAME记录以及该业务应急子域的NS记录(即应急权威域名服务器组件的地址),则该递归服务器将在TTL缓存期间内直接向该应急权威域名服务器组件查询业务应急子域名的IP地址,该应急权威域名服务器组件将该业务应急子域名的IP地址返回给该递归服务器。
进一步的,所述设定值为比CNAME记录的TTL默认值长的值。
进一步的,所述设定值为比NS记录的TTL默认值长的值。
本发明引入了业务应急权威域名服务器组件;当域名NS记录被劫持时,业务权威域名服务器临时将每一业务域名CNAME指向其对应的一个业务应急子域名,并指定应急子域名的NS记录为应急权威域名服务器组件的地址;业务应急子域名可以是与业务域名在相同域下的特殊子域名,也可以是其他域下的子域名;业务域名的CNAME记录以及业务应急子域名的NS记录均设置较长的TTL,目的在于确保在该TTL过期后,顶级域上的域名NS劫持记录已被清除。
在业务域名的NS记录在被劫持,导致上层顶级权威域名服务器返回错误信息期间,传统缓解劫持影响的方法是临时延长业务域名A记录的TTL时长。
本发明所提供的缓解域名权威记录劫持影响的解析服务方案如附图2所示。和传统的互联网业务的域名解析过程相比,本发明新增了一类业务应急权威域名服务器组件,该组件与业务权威域名服务器一起部署,两者均由业务域名权威解析服务的提供方负责维护。业务权威域名服务器为每个业务域名配置了一个特定的业务应急域名(具体见后面实施例),业务应急域名的所有解析配置信息与原始业务域名完全相同,并存储在业务应急权威服务器组件上。
当用户向递归服务器查询业务域名的IP地址,由于域名NS记录被劫持,上层顶级权威域名服务器返回错误NS记录时,业务域名权威解析服务的提供方将启动该应急权威域名服务器组件。如果递归服务器缓存了业务域名权威服务器的正确NS记录,递归服务器向业务权威域名服务器查询业务域名的IP地址信息;为了避免该递归服务器后续缓存到期导致受到域名NS劫持的影响,业务权威域名服务器临时设置用户查询的业务域名的CNAME记录,将该业务域名指向一个该域名对应的特定的业务应急子域名,并指定该业务应急子域名的NS记录为应急权威域名服务器组件的地址,上述CNAME记录以及NS记录均设置较长的TTL;业务权威域名服务器将上述CNAME记录以及NS记录返回给递归服务器,递归服务器将自动向应急权威域名服务器组件查询业务应急子域名的IP地址(与之前业务权威域名服务器配置的业务域名IP地址信息完全相同),返回给用户;用户根据获取的IP地址访问该互联网业务。
上述方案根据域名NS记录分层授权的原理,将热点业务域名的权威域名服务器转移到TTL较长的应急权威域名服务器组件,并且由于业务应急域名的所有解析配置信息与原始业务域名完全相同,该应急权威域名服务器组件支持原业务权威域名服务器的所有业务域名解析的优化策略。后面会给出相应实施例。
在域名NS劫持期间,通过本发明的应急权威域名服务器组件实现域名NS记录分层授权方案,能够有效缓解原有递归域名服务器缓存域名NS记录即将到期的影响,尽可能保证用户对于热点业务域名的正常访问。传统的方案一般是临时延长业务域名A记录的TTL时长,其副作用是该TTL延长期间内无法修改A记录,导致业务权威域名服务器无法快速切换用户实际访问的IP地址,某些A记录频繁变动的热点在线视频、文件下载类型的CDN业务域名将会受到影响。本发明首先将业务域名CNAME到特定的业务应急域名,再通过应急权威域名服务器组件负责解析业务应急域名,与之前配置的业务域名IP地址信息完全相同,因此能够保留原有的业务域名解析的优化策略,支持与业务权威域名服务器完全一致的A记录快速切换功能,对于上述A记录频繁变动的热点在线视频、文件下载类型的CDN业务域名的支持更具灵活性。
与现有技术相比,本发明的积极效果为:
(1)业务应急权威域名服务器组件独立于已有的业务权威域名服务器,在顶级域恢复正确的域名NS记录之后,能够快速切换回原有的解析服务模式;
(2)能够延长用户访问热点业务域名正确IP地址(而非错误IP地址)的时间,并且支持与业务权威域名服务器完全一致的A记录快速切换功能,有效保证了用户访问体验;
(3)业务应急子域名可以是相同业务域下的特殊子域名,也可以是其他域下的子域名,具体实施配置灵活多变;
(4)不需要在短时间内迅速联系大量递归域名服务器运行厂商处理,即本发明能够不在短时间引入大量人工联系处理资源的情况下,尽可能保证域名NS记录劫持期间,用户持续正常访问热点业务域名。对于上文背景技术中介绍的百度域名NS记录劫持导致www.baidu.com热点业务域名8小时无法正常访问的风险事件,本发明能够有较好的主动缓解效果。
附图说明
图1为互联网业务的域名解析过程;
图2为缓解域名权威记录劫持影响的方法流程图;
具体实施方式
下面结合附图对本发明的具体实施方法进行进一步详细描述。
以foo.com域名为例,假设该域名NS记录在注册商处被劫持篡改,并将劫持记录同步到.com顶级域。本发明的实施例如下:
(1)当foo.com的权威解析服务的提供方发现.com顶级域返回了错误的NS记录,为缓解域名劫持的影响,foo.com的业务域名权威解析服务的提供方立即在foo.com的权威域名服务器ns.foo.com启动应急调整,设置foo.com域下的每一业务域名的CNAME记录到一对应的特定业务应急域名(例如某个业务域名www.foo.com被CNAME到其对应的特定业务应急域名www.rescue.foo.com);同时开启foo.com的应急权威域名服务器组件ns.rescue.foo.com的解析服务。
(2)假设用户使用的递归域名服务器为222.222.222.222,用户准备访问www.foo.com,则用户向222.222.222.222查询www.foo.com的IP地址。
(3)假设递归域名服务器222.222.222.222缓存了foo.com的正确NS记录ns.foo.com,则222.222.222.222向ns.foo.com查询www.foo.com的IP地址。
(4)ns.foo.com向递归域名服务器222.222.222.222返回应答,应答示例如附表1所示,其中ANSWER部分是www.foo.com域名CNAME到应急子域名www.rescue.foo.com的信息,AUTHORITY部分是应急子域名的NS记录信息,ADDITIONAL部分是应急权威域名服务器组件的IP地址信息:111.111.111.111。该应答是在上面(1)中描述的ns.foo.com的CNAME调整的基础上,通过国际上已标准化的DNS应答协议自动生成的。
附表1权威域名服务器向递归返回应急信息
(5)递归域名服务器222.222.222.222向应急权威域名服务器组件111.111.111.111查询www.rescue.foo.com的IP地址,应急权威域名服务器组件111.111.111.111向递归域名服务器222.222.222.222返回原始www.foo.com配置的IP地址
(6)递归域名服务器222.222.222.222向用户返回www.foo.com的IP地址信息,用户根据获得的IP地址访问www.foo.com业务。
此外,本方案还可以使用其他域下的子域名作为应急子域名,假设应急子域名为bar.net,则上述(4)中ns.foo.com向递归域名服务器222.222.222.222返回应答示例如附表2所示,用户通过查询应急域名www.bar.net获取www.foo.com的IP地址信息。
附表2权威域名服务器向递归返回应急信息(跨域)
Claims (8)
1.一种基于NS记录分层授权缓解域名权威记录劫持影响的方法,其步骤为:
1)在域名解析服务系统中设置一业务应急权威域名服务器组件;该业务应急权威域名服务器组件中设有若干业务应急子域名;
2)当域名的NS记录被劫持,顶级权威域名服务器返回错误NS记录时,该域名的业务权威域名服务器启动该业务应急权威域名服务器组件,将业务权威域名服务器的业务域名解析配置信息存储到该业务应急权威域名服务器组件;
3)该业务权威域名服务器为该域名下的每个业务域名CNAME指向该业务应急权威域名服务器组件中的一业务应急子域名,并指定该业务应急子域名所在的子域的NS记录为业务应急权威域名服务器组件的地址;
4)对于缓存了域名NS记录的递归服务器,该递归服务器向业务权威域名服务器查询业务域名的IP地址信息,业务权威域名服务器将该业务域名的CNAME记录指向该业务应急权威域名服务器组件中的一业务应急子域名,并指定该业务应急子域名所在的子域的NS记录为业务应急权威域名服务器组件的地址,并将该业务域名的CNAME记录和该业务应急子域名所在的子域的NS记录的TTL设置为设定值,然后返回给该递归服务器。
2.如权利要求1所述的方法,其特征在于,将业务权威域名服务器的业务域名解析配置信息存储到该业务应急权威域名服务器组件的方法为:将业务权威域名服务器中的业务域名通过CNAME记录转移到该业务应急权威域名服务器组件,再通过该业务应急权威域名服务器组件进行业务应急子域名的应急子域分层解析,得到与业务权威域名服务器中相同的业务域名解析配置信息。
3.如权利要求1或2所述的方法,其特征在于,业务域名权威解析服务的提供方维护该业务应急权威域名服务器组件和该业务权威域名服务器。
4.如权利要求1或2所述的方法,其特征在于,每一业务域指向的业务应急子域名为该业务域名CNAME下的一子域名。
5.如权利要求1或2所述的方法,其特征在于,每一业务域指向的业务应急子域名为设定业务域下的一子域名。
6.如权利要求1或2所述的方法,其特征在于,该递归服务器收到一指定业务域名的IP地址查询请求时,如果已缓存有业务域名到业务应急子域名的CNAME记录以及该业务应急子域的NS记录,则该递归服务器将在TTL缓存期间内直接向该业务应急权威域名服务器组件查询业务应急子域名的IP地址,该业务应急权威域名服务器组件将该业务应急子域名的IP地址返回给该递归服务器。
7.如权利要求1或2所述的方法,其特征在于,所述设定值为比CNAME记录的TTL默认值长的值。
8.如权利要求1或2所述的方法,其特征在于,所述设定值为比NS记录的TTL默认值长的值。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610537040.9A CN106210165B (zh) | 2016-07-08 | 2016-07-08 | 基于ns记录分层授权缓解域名权威记录劫持影响的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610537040.9A CN106210165B (zh) | 2016-07-08 | 2016-07-08 | 基于ns记录分层授权缓解域名权威记录劫持影响的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN106210165A CN106210165A (zh) | 2016-12-07 |
CN106210165B true CN106210165B (zh) | 2020-01-21 |
Family
ID=57473657
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610537040.9A Active CN106210165B (zh) | 2016-07-08 | 2016-07-08 | 基于ns记录分层授权缓解域名权威记录劫持影响的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN106210165B (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106790704B (zh) * | 2017-02-27 | 2019-09-13 | 网宿科技股份有限公司 | 一种访问云存储文件的方法及系统 |
CN108574660B (zh) * | 2017-03-09 | 2021-01-01 | 武汉斗鱼网络科技有限公司 | 一种获取ip地址的方法及系统 |
CN111200667B (zh) * | 2019-12-18 | 2021-08-10 | 网宿科技股份有限公司 | 一种域名解析方法、权威域名服务器和本地域名服务器 |
CN111953802A (zh) * | 2020-07-06 | 2020-11-17 | 网宿科技股份有限公司 | 一种域名的解析方法、系统、设备及存储介质 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7707314B2 (en) * | 2005-11-21 | 2010-04-27 | Limelight Networks, Inc. | Domain name resolution resource allocation |
CN103248725B (zh) * | 2013-05-23 | 2017-08-11 | 中国科学院计算机网络信息中心 | 一种安全可靠的域名解析修复方法和系统 |
CN103747005B (zh) * | 2014-01-17 | 2018-01-05 | 山石网科通信技术有限公司 | Dns缓存投毒的防护方法和设备 |
CN104113447B (zh) * | 2014-07-10 | 2017-11-10 | 北京蓝汛通信技术有限责任公司 | 监测域名解析污染的方法、装置及系统 |
CN105357328B (zh) * | 2015-09-28 | 2018-10-02 | 互联网域名系统北京市工程研究中心有限公司 | 域名解析方法、dns递归服务器及域名解析系统 |
-
2016
- 2016-07-08 CN CN201610537040.9A patent/CN106210165B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN106210165A (zh) | 2016-12-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10911399B2 (en) | Robust domain name resolution | |
US20230421449A1 (en) | Dns package in a network | |
US9444781B2 (en) | Recursive DNS nameserver | |
CN111245972B (zh) | 一种域名解析方法、装置、介质及设备 | |
CN106210165B (zh) | 基于ns记录分层授权缓解域名权威记录劫持影响的方法 | |
US11706197B2 (en) | DNS proxy that automatically clears IP addresses in firewall according to DNS queries of cleared domain names | |
Ramasubramanian et al. | The design and implementation of a next generation name service for the internet | |
US20080162724A1 (en) | Direct domain name service query | |
Ballani et al. | Mitigating dns dos attacks | |
Yuan et al. | DoX: A peer-to-peer antidote for DNS cache poisoning attacks | |
US20100049982A1 (en) | Dnssec base rollout | |
Wang | Analysis of DNS cache effects on query distribution | |
Allman | On eliminating root nameservers from the DNS | |
CN106209832A (zh) | 基于ns记录转移授权缓解域名权威记录劫持影响的方法 | |
US10193853B1 (en) | Web browser or web service based detection of internet facing DNS server | |
Hardaker | Analyzing and mitigating privacy with the DNS root service | |
Cisco | Release Notes for Cisco DistributedDirector System Software | |
Nikkel | Domain name forensics: a systematic approach to investigating an internet presence | |
Li et al. | Improving DNS cache to alleviate the impact of DNS DDoS attack | |
Pan et al. | Measuring the resolution resiliency of second-level domain name | |
Ballani et al. | A simple approach to DNS DoS mitigation | |
Dannewitz et al. | Report on locality in DNS requests–evaluation and impact on future Internet architectures | |
Wang et al. | ActiveDNS: Is There Room for DNS Optimization Beyond CDNs? | |
Matotek et al. | Infrastructure Services: NTP, DNS, DHCP, and SSH: By Peter Lieverdink and Dennis Matotek | |
Malone | The root of the matter: hints or slaves |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |