对“断网”讨论的一个重点被聚焦在域名根服务器,一些“科普”的方式,某些“脑补”的形式,众口一词地认为“不用担心”。其信誓旦旦的理由是:“我国已拥有域名根镜像服务器”。事实上,这是一个悖逆科学真相的严重认知误区。换句话说,应对“断网”的风险和隐患,镜像的域名根服务器不仅无济于事,而且于事无补。
本文可供网络信息领域的专业技术人员、从业人员和监管、监察、审计、执法人员作为科学论证的依据与参考。
域名空间是一个生态系统(ecosystem),其服务体系如图 1 所示,其中“递归域名解析服务器”是域名空间的入口:
虽然域名根服务器在域名解析服务中是一个重要的环节,但在域名空间中仅当各个环节相互依存,方能构成一个能够可靠运行的生态系统。反之,任何一个环节出现安全问题,都可能导致域名解析服务中断(“断服”),或是网络瘫痪(“断网”)。
据美国国防部术语词典的定义,“供应链”(Supply Chain)是:从原材料到向最终用户提供成品和服务相关联的(人的)活动。域名空间的生态系统可以被简化为一个“供应链”(图 2)。
从图 1 和图 2 可见,域名空间是一个复杂的生态系统。而应对“断网”的风险和隐患的本质是:供应链的安全和保障问题。因此,有必要澄清域名空间供应链中的五个重要的关联事实:
事实1:镜像的域名根服务器不能替代13个域名根系统;
事实2:镜像的域名根服务器采集的数据绝大多数是“垃圾”;
事实3:镜像的域名根服务器采集的是不完整和不确定数据;
事实4:镜像的域名根服务器没有指挥和控制的能力;
事实5:镜像的域名根服务器受制于服务系统软件。
结论:域名空间的应用和服务是网络通信的本源及指挥和控制的中枢,一旦发生“断服”,即是“断网”。应对“断服”的风险和隐患,镜像的域名根服务器不仅无济于事,而且于事无补。
事实1:基于域名空间生态系统的基本配置,镜像的域名根服务器不能替代 13 个域名根系统
1)根提示文件
当前,最终用户设备通常将所有 DNS 查询发送到递归解析服务器,该解析服务器在加入网络时通过 DHCP 配置。或者,用户可以将其设备配置为利用公共递归域名解析服务器(例如 Google 的 8.8.8.8 服务器)。递归域名解析服务器查询授权的域名服务器,使用所谓的“根提示文件”(Root Hints File)引导查找授权域名服务器的过程。根提示文件包含所有 13 个命名的授权域名根服务器的列表,它们表示为 A 根 到 M 根。对于每个命名的根,文件都包括域名服务器(NS 记录),以及域名服务器的 IPv4 地址(A 记录)和 IPv6 地址(AAAA 记录)。因此,根提示文件共有 39 个条目,大约 3KB(3000字节)。例如,A 根:
有了这些信息,递归解析服务器可以从根开始查询过程,并按照 DNS 响应中的指示进行。例如,来自根名称服务器的响应将指示递归解析服务器联系指定的顶级域名(TLD)服务器。根提示文件中的每个记录的缓存时间(TTL)为 360 万秒(约 42天)。该文件在很大程度上是静态的,但在某些情况下确实会发生变化,并且递归解析程序应在根提示文件缓存时间到期后获得一个新副本。分析表明,大量的递归域名解析服务器不会及时地更新其根提示文件。
2)根区文件
每个域名根服务器均根据根区文件(Root Zone File)的副本响应查询。该副本由因特网域名与数字地址分配机构(ICANN)官方提供,由 Verisign 公司分发。域名根服务器不会直接响应查询请求,而是会将域名查询的请求引导向顶级域名服务器,以获取查询域名中顶级域名的主机。例如,对“www.ccb.com”的查询请求,域名根服务器将请求引导向“.com”的授权顶级域名服务器,继而将请求引导向“ccb.com”的权威域名服务器。
自 2009 年 4 月 28 日以来,研究人员每天在根区文件中存档一个记录。图 3 显示了每月 15 号在根区中的记录数。该图显示,经过一段时间的稳定之后,根区文件中的记录数量在 2014 年初至 2017 年初之间增长了五倍。这是由于顶级域名(TLD)数量增加所致,而 2013 年 6 月 15 日为 317 个 TLD,在 2017 年 6 月 15 日达到 1,534 个 TLD。经过这段时期的增长,规模已稳定到大约 22,000 个。当前的根区文件大约为 2.1MB(兆字节)。目前, 根区文件中的 NS、A 和 AAAA 记录的 TTL 为两天(172,800 秒)。因此,递归解析服务器可以缓存来自域名根服务器的响应,并在两天之内继续使用,以响应来自终端用户设备的域名查询请求,而无须访问顶级域名服务器,故不存在所谓的域名解析服务的“加速”。
根区文件是公开的,可以下载(约 2.1 兆字节)。其中的顶级域名(TLD)包括:国家/地区顶级域名(ccTLD)、通用顶级域名(gTLD)、新通用顶级域名(ngTLD),会经常发生变化,或更改域名服务器集(域名或 IP 地址)。相应的问题是:如何确定根区文件是更新的?
此外,DNSSEC 规范的主要作用是,当对根区文件中的所有记录进行验证时,需要一个根区 DNSSEC 密钥的副本,密钥随着时间而改变。故另一个问题是:如何确保根区文件内容的真实性?
因此,获取根区文件并不难,而重要的是:根区文件内容的合规性和可用性受到验证和约束,不允许“为所欲为”。
3)域名根服务器的范围
虽然只有 13 个命名的授权域名根服务器系统, 但是每个命名的域名根服务器系统都通过任播(Anycast)路由设置,由多个“副本”(设置的站点和节点)组成。
在 2019 年 5 月 15 日,统计了 985 个域名根服务器节点。图 4 显示了自 2015 年 3 月以来每个月 15 日的节点数量。由 E 根和 F 根引起的节点数量有几次大跳跃:
- 在 2016 年 1 月至 2 月之间,E 根增加了 45 个节点,
- 在 2017 年 4 月至 5 月之间,F 根添加了 81 个节点,
- 在 2017 年 11 月至 12 月之间,E 根添加了 85 个节点,F 根添加了 43 个节点。
除了这些大的跳跃之外,该图还表明:伴随域名根服务器节点的数量增加,成本也随着时间的推移稳步增长。
域名根系统的“副本”由“站点”(Site)和“节点”(Instance)组成,在同一个站点中可以有多个节点。例如:A 根有 16 个站点及 53 个节点。截至 2020 年 12 月 21 日,13 个域名根系统在全球共有 1143 个站点,1367 个节点。
请注意,由十二个不同的机构或企业运营的 13 个域名根服务器,每个机构或企业都有各自设置站点(和节点)的策略和意图。同时,在全球各地设置的站点和节点,需要满足前提条件,以及受到签署和承诺的相关协议条款的约束,而并不是所属地的“自治系统”(即不是域名根系统的所属权被转移或让渡)。
因此,在中国大陆不断增加域名根系统的站点(和节点),在应用上有助于提高因特网域名根系统的稳定性和可用性,也以增加自身的成本为因特网作出了贡献,但是作为“副本”没有替代域名根的可能性。
事实 2:基于对域名根服务器数据流量的研究和分析,域名根服务器镜像的数据绝大多数是“垃圾”
相关的研究和分析表明,在到达域名根服务器的查询请求中有 95% 以上是虚假的。例如,在 2008 年,专家们研究了八个域名根服务器的服务数据,分析结论是:只有 1.8% 的域名查询请求是有效的。国际计算机科学研究院(ICSI,位于美国加利福尼亚州伯克利,是一个独立的非营利性研究机构),在 2019 年 10 月对该结论进行了验证。为此,利用了由 J 根提供的数据集:分布在世界各地的 142 个 J 根的节点,2018 年 4 月 11 日的 24 小时流量。虽然这个分析仅是 13 个根服务器系统之一的数据,但之前大量研究和分析表明,到达域名根系统的数据流量类型在各个域名根系统之间是相当一致(均匀)的。
- J 根 在 24 小时内接收了约 57 亿个域名查询请求,即平均每秒约有 6.6 万个域名查询请求。
- 域名查询请求来自 410 万个递归解析服务器(不同的 IP 地址)。但是有 72.3 万个递归解析服务器仅查询虚假的顶级域名,这意味着最多只有 340 万递归解析服务器进行有用的工作。
- 与之前的研究结论相同,分析发现大部分请求都是“垃圾”,有 35 亿条是虚假顶级域名查询,占比 61.0%。此外,假设递归解析服务器具有理想的缓存(故,递归解析服务器对同一顶级域名的查询请求在 24 小时的数据集中仅应出现一次),所以另外的 22 亿条查询请求(占比 38.4%)是无效的。这种情况下,虚假的查询(61.0%)和无效的请求(38.4%),表明有效的域名查询请求仅有0.5%。
- 如果放宽对理想缓存的假设,而是允许递归解析服务器每 15 分钟可以重复对相同顶级域名的有效查询请求,则无效请求的数量为 20 亿条(35.7%)。在这种情况下,对虚假的查询(61.0%)和无效的请求(35.7%),表明有效的域名查询请求仅有 3.3%。或,在 57 亿条域名查询请求中,仅有 1.87 亿条域名查询请求是有效的。这意味着,J 根的每个节点平均每秒处理大约 15 个有效域名查询请求。
这证明了,之前多源研究的结论仍然成立:到达域名根服务器(包括所设置的站点和节点)的绝大多数数据流量都是垃圾。
事实 3:基于域名解析的不可逆过程,镜像的域名根服务器采集的是不完整和不确定数据
如事实 1 所述,递归域名解析服务器配置了根提示文件,并根据具体(或不同的)算法,在 13 个根域名系统(及其站点和节点)之间轮询。
这就是说,域名根服务器所接收的域名查询请求,来自于递归域名解析服务器(图 1),也是域名空间的入口。
根据对全球因特网公共(递归)域名服务器的监测统计,截至 2020 年 12 月 21 日(4:03),中国大陆拥有公共递归域名解析服务器(仅仅监测和统计端口 53/UDP)的数量为 768,103 台,占全球总数的 40.35%。而且,这个数量是在动态变化的,例如:10 月 22 日的数量为 1,106,552 台,占全球总数的 46.18%。
因此,不得不必须面对一个严峻的事实:中国域名空间的入口是完全敞开的,处于良莠不齐的混沌状况和监管缺失的状态。
是谁以及为谁提供如此(异常)大规模及动态变化的公共递归域名解析服务?
换句话说,镜像的域名根服务器的响应和服务是被动的(依赖于递归域名解析服务),在开放的域名空间入口,有多少有效的域名查询请求会指向镜像的域名根服务器,完全未知;因而其采集(和存储)的是不完整和不确定数据,故其作为应急备份也是盲目的!那么,为“公共”服务的动机和意图又是什么?
事实 4:基于域名解析的层次化结构,镜像的域名根服务器没有指挥和控制的能力
域名根服务器的应用功能是,按根区文件把接收到的域名查询请求,推送(referral)到顶级域名服务器(图 1)。
根据中国信息通信研究院的报告(信通院 2020-6),截至 2019 年 12 月,我国域名注册市场规模为 5,108.8 万个,其中,国家顶级域“.CN”域名 2,300 万个;“.COM”域名 1,566 万个;合计占我国域名市场的 75.7%。活跃域名数量分布:
从图 5 可见,我国活跃域名的解析超过 91% 依赖于境外服务。其中,运营顶级域名“.COM、.NET、.CC、.TV、.NAME”的 Verisign 公司,也是管理域名 A 根和 J 根的运营商,并且是作为美国国家电信和信息管理局(NTIA)管理域名空间的合约代理商。
这就是说,在应急响应时,镜像的域名根服务器不得不把绝大多数接收到的有效域名查询请求,“推送”到境外的顶级域名服务器(如 .COM)。显然,假设境外的域名根服务器对中国“断服”了,而顶级域名服务器却仍然提供对中国的“服务”,怎么可能?近乎荒谬。
所以,镜像的域名根服务器没有实用性和实战性!
事实 5:基于经验和教训以及现状,镜像的域名根服务器受制于服务系统软件
据了解,中国大陆的域名系统服务软件以采用开源和免费的模式为主,包括以“自研代码”包围“开源代码”的“马甲”式二次开发。
最近,Solarwinds 网管软件被认为遭到“供应链攻击”,迫使全球各国重新认识在网信安全领域中的“供应链安全”。虽然“供应链”的表面形式是有形的物(包括技术),但是其本质和实质是人的因素(包括政治和意识形态使然)。
以开源和免费的 DNS 软件 BIND 为例。2000 年由美国国土安全部资助开发的 BIND 版本 9(BIND9),从 2004 年 1 月 28 日的第一个版本(BIND 9.0.0)到 2020 年 9 月 17 日(BIND 9.17.5),共计发布了 634 个版本,其中 2020 年(至 9 月 17 日)发布了 15 个版本。
BIND 软件版本的生命周期一般为 1 年。但是,已知国内有相当多的单位和企业仍然在使用已被废弃的BIND软件版本,甚至所使用的 BIND 软件(数年前)版本号仍在网络中裸露着。
另一方面,BIND 软件版本不断地被发现高危的安全漏洞,仅 2019 年公开发布的漏洞补丁(CVE)就是 17 个,不包括一般性的代码错误。如果没有及时下载补丁,等同于开放被入侵的大门。但是,投入和花费资源维护“免费”DNS 软件的单位和企业却并不多见。必要和必须的技术、行政、执法监管普遍不及时、不完善、不严谨或原本就不落实。
尤其是,并不能排除软件中固有的“暗桩”、尚未公开的漏洞,或在下载开源软件的过程中被植入或夹带了病毒。在这样的域名应用和服务环境中,镜像的域名根服务器怎么可能“独善其身”!
综上,从知彼(和对标)的角度,2014 年 7 月,美国国家安全局(NSA)发起了“安全的科学”(简称 SOS)计划,持续至今。SOS 计划明确界定:网信安全领域是一门新兴的、跨学科的、整体的知识体系,旨在作为一项持续发展的长期研究工作。因此,(网信)“安全的科学”既没有唯一的路径,也没有任何捷径。
科学是证伪的过程。所述的五个事实都可以充分证明,镜像的域名根服务器,不能也无法应对潜在的“断服”(或“断网”)风险。重新审视应对“断服”(“断网”)的方案和措施,对于坚持维护国家主权、安全、发展利益十分迫切、至关重要。
悖逆科学事实和常识的“镜像替代”论,“早有准备”和“不用担心”说,当休矣!
(作者:邱实,网络信息安全和工程技术专家;牟承晋,中国移动通信联合会国际战略研究中心主任,昆仑策研究院高级研究员,浙江省北斗未来网际网络空间研究院首席研究员。来源:昆仑策网)
给力项目:资源之家会员可免费下载 加入会员友情提醒: 请尽量登录购买,防止付款了不发货!
QQ交流群:226333560 站长微信:qgzmt2