-
摘要:
在域名系统(domain name system, DNS)中,DNS递归解析服务消除了用户与根域名服务器等上游DNS服务器之间的复杂交互,使得互联网用户可以方便地通过本地DNS服务器完成全球范围的域名解析. 作为直接与用户通信的第一门户,DNS递归解析服务过程已成为互联网基础设施攻击的一个重要目标. 由于DNS递归解析服务规模庞大且部署方式繁多,现有的DNS安全拓展机制在DNS递归解析服务器中存在部署复杂、兼容性差等问题,但是目前还缺少对安全防护机制的部署测量方法的研究与总结工作,缺乏针对DNS递归解析服务安全风险的系统全面的评估工作. 针对上述现状,将DNS递归解析服务存在的安全风险分为5大类,对DNS递归解析服务安全威胁,DNS安全拓展机制和DNS递归解析服务安全风险评估与测量等方面的现状与最新研究成果进行了归纳与总结,并对DNS递归解析服务安全监测与治理的潜在研究方向进行了展望.
Abstract:The Domain Name System (DNS) recursive resolving service acts as a bridge between users and upstream DNS authoritative servers to enable users conveniently resolving domain names through local DNS servers. However, as the first gateway for communication with users, DNS recursive resolving services have become a significant target for attacks on Internet infrastructure. Given the vast scale and variety of DNS recursive service deployments, current DNS security enhancements struggle with implementation complexity and compatibility issues. Despite its importance, there is a noticeable lack of research focused on the deployment of security protection mechanisms for DNS recursive services, as well as the comprehensive assessment of the associated security threats. To bridge this gap, we categorize the security risks associated with DNS recursive services into five main types: cache poisoning, DNS hijacking, direct attacks on recursive servers, leveraging recursive servers to target other servers, and exploiting software vulnerabilities. Additionally, we provide a summary of the latest research on DNS recursive service security threats and DNS security enhancement mechanisms. Our review also summarizes measurement methods for assessing the security risks. Finally, we analyze the current state of DNS recursive service security and offer insights into future research directions for improving the security monitoring and governance of DNS recursive services.
-
随着人类日益增长的能源需求和不可再生资源的枯竭,核聚变能源由于其清洁性和安全性作为解决长期能源需求的解决方案,越来越受到人类社会的关注,目前正在建设中的国际热核实验反应堆(international thermonuclear experimental reactor,ITER)是实现核聚变能和平应用的重要里程碑. 磁约束核聚变是产生热核聚变能的最重要方法之一[1-2]. 在反应堆中实现和维持等离子体聚变过程具有巨大的科学和技术挑战,其中针对等离子体稳定性的研究有助于理解、预测、控制和减轻等离子体破坏的威胁,是优化燃烧等离子体运行模式,改善等离子体约束和输运的重要保障,是设计和制造先进的核聚变装置的重要依据.
数值模拟是等离子体稳定性研究中的关键方法之一,相比理论研究,它能够分析复杂的物理过程,而相比实验研究,它更加经济和灵活. 在等离子体物理数值模拟研究中,回旋动理学理论经常被用来研究在拉莫尔半径空间尺度下的动理学不稳定性和湍流传输[3-5]. 在回旋动理学理论中,通过回旋平均方法将描述分布函数的方程维度从6维降低到5维,使得其特别适用于研究更长时间尺度下的等离子体不稳定性和湍流传输物理过程.
粒子网格法(particle in cell,PIC)由于其良好的可扩展性、物理守恒性、波粒相互作用描述准确性等优势,在众多回旋动理学模拟算法中具有广泛适用度和应用前景[6-8]. 基于PIC算法的突出特点,科研学者在解决特定时空尺度物理问题的同时,逐步向多时空尺度耦合的非线性复杂物理模拟演进. 其对磁约束核聚变高性能数值模拟中涉及的程序架构、计算性能、算法优化、并行效率都提出了前所未有的挑战. 许多科研学者尝试借助异构平台的计算性能满足回旋动理学PIC代码日益增长的算力需求,在移植优化和数值算法上作出了诸多努力.
GTC代码是早期受益于异构并行计算的代码之一,基于CUDA在天河一号上展示2~3倍的加速[9]. 基于OPENACC在Titan上展示了2~3倍的加速,在Summit上展示了3~4倍的加速[10]. 基于Intel Xeon Phi加速器,在天河二号上展示了2~5倍的加速[11]. ORB5代码基于OPENACC,在Tesla P100 GPU和Tesla V100 GPU的Summit中分别获得了4倍和5倍的加速[12].
在上述研究中,通常着重考虑了等离子体中电子对模型的贡献,针对电子的模拟,凭借访存规则等优势可以获得较高的计算性能加速. 而聚变产物Alpha粒子与动理学离子类似,回旋半径较大,必须在回旋运动轨迹上进行回旋平均,从而带来大量非规则的网格数据访存,对访存性能提出了很高的要求. 文献显示在只有动理学离子和绝热电子的情况下,异构移植给整体性能带来了负面的优化[13]. 考虑到聚变产物Alpha粒子的约束和输运是磁约束聚变能否成功的关键. 本文重点聚焦于以Alpha粒子为代表的回旋动理学代码的异构移植和性能优化.
1. 实验平台:天河新一代超算系统
本文的移植优化及分析测试在天河新一代超级计算机上进行. 天河新一代超级计算机使用异构处理器MT-
3000 [14],它包含16个CPU,4个加速集群(簇),96个控制核心和1 536个加速核心,理论计算密度高达145FLOPB. 每个加速核心以超长指令字(very long instruction word, VLIW)方式工作,每16个加速器核心和1个控制核心被组织成1个加速阵列,以SIMD指令控制. MT-3000 具有混合的存储器层次结构,包括每个集群的GSM(6MB),HBSM(48MB),DDR(32GB)存储器,每个加速阵列的AM(768KB)和SM(64KB)片上存储器为加速核供给数据. 其架构如图1所示.在异构处理器MT-
3000 上移植程序时有2个挑战:一方面,如何高效使用复杂的内存结构高效的将数据传递到加速阵列;另一方面,如何充分发挥高计算密度特性. 这2方面的挑战需要在程序移植优化时打破传统基于CPU的程序设计结构更多地强调计算性能的作用,从而实现整体性能的提高.2. VirtEx代码热点分析及异构开发
VirtEx是基于PIC算法开发的回旋动理学模拟代码,已成功用于分析线性电阻撕裂不稳定性[15]. 代码按照PIC方法,将带电粒子以拉格朗日法描述,对应在连续相空间的分布函数采样点;而场信息以欧拉法描述,采用结构化网格描述平衡场,采用非结构化网格描述扰动场[16]. VirtEx代码的并行化策略是通过在环形方向上将模拟区域划分为不同的子域实现空间并行化,每个子域由1组进程管理. 该组中的每个进程拥有子区域内的场信息副本,并在该子域内将粒子按照进程编号进行并行划分.
VirtEx代码的主要结构如图2所示,其主循环使用2阶龙格-库塔算法,在每个循环中,通过函数Push更新粒子在相空间的位置,其可以更加细致的分为粒子对场信息的回旋平均函数PG(push gather)和粒子位置更新函数PI(push interpolation);通过函数Locate计算粒子位置和扰动场网格之间插值的权重系数;通过函数Charge计算在非结构化扰动网格上的分布函数矩. 而其他热点部分主要是对非结构化网格上的扰动场更新和粒子MPI通信等操作. 其中3个函数Push,Locate,Charge为代码的热点,共占主循环时间的85%以上.
3个热点函数中涉及的算法如下所示:
算法1. 函数PushGather回旋平均算法.
输入:环向格点权重wzpart, 径向格点权重wppart, 极向格点权重wtpart, 格点编号jtpart, 扰动电场gradphi;
输出:回旋平均扰动场wpgc.
for (mp=0; mp<mpmax; mp++)/*粒子循环*/
for(igyro=0;igyro<ngyro;igyro++) /*回旋平均 循环*/
读取粒子所在的格点权重及索引;
以索引读取gradphi;
计算临时变量e;
end for
累加计算wpgc,供函数PI使用*/
end for
算法2. 函数PushInterpolation粒子位置更新算法.
输入:相空间坐标zpart, 历史相空间坐标zpart0,回旋平均扰动场wpgc;
输出:相空间坐标zpart.
for (mp=0; mp<mpmax; mp++)/*粒子循环*/
读取粒子信息 zpart ,wpgc;
插值获取网格信息、电场、磁场等;
计算场对粒子的作用;
推动粒子更新速度位置信息;
end for
算法3. 函数Locate粒子到场的插值权重系数算法.
输入:相空间坐标zpart;
输出:环向格点权重wzpart, 径向格点权重wppart, 极向格点权重wtpart, 格点编号jtpart.
for (mp=0; mp<mpmax; mp++)/*粒子循环*/
for(igyro=0; igyro<ngyro; igyro++)/*回旋平均 循环*/
读取粒子信息zpart;
读取网格信息;
计算粒子插值权重;
end for
end for
算法4. 函数Charge非结构化扰动网格上的分布函数矩算法.
输入:环向格点权重wzpart, 径向格点权重wppart, 极向格点权重wtpart, 格点编号jtpart;
输出:电流密度density.
for (mp=0; mp<mpmax; mp++)/*粒子循环*/
插值获取网格信息、电场、磁场;
for(igyro=0; igyro<ngyro; igyro++)/*回旋平均 循环*/
读取粒子插值权重;
计算粒子对于周围格点的扰动量;
粒子信息向网格上规约到density;
end for
end for
上述3个热点函数中的4个算法外层循环体均围绕粒子展开,且粒子间具有良好的独立性,面向异构处理器MT-
3000 异构移植工作主要围绕粒子循环的向量指令集改写展开.同时,为了更好适配向量指令集的访存特性,在数据结构上做了改写,将粒子数据使用SOA(struct of array)数据结构标识,网格数据使用AOS(array of struct)数据结构. 粒子数据具有数量多,独立性好的特性,配合SOA数据结构更适用于发挥向量指令运算的优势;而网格数据数量远远小于粒子数,访存量巨大,AOS的数据结构能够充分发挥内存局部性. 针对数据结构的改写工作为后续程序的性能优化提供了重要的保障.
3. 面向高计算密度异构设备的性能优化策略
基于上述对于程序热点函数的分析,回旋动理学PIC数值模拟算法涉及粒子与网格数据间的大量访存,尤其在面向扰动场网格数据的访存操作中存在非规则访问和原子写操作,二者对于访存性能提出了艰难的挑战,几个热点函数的访存与计算量统计如表1所示.
表 1 VirtEx热点函数的初始计算密度统计Table 1. Initial calculated density statistics of VirtEx hot spot function函数 浮点计算量/FLO 访存量/B 计算密度/FLOPB PG 269mp 232mp 1.15 PI 462mp 224mp 1.98 Locate 238mp 200mp 1.17 Charge 158mp 200mp 0.75 注:变量mp表示粒子数量,变量前系数为热点函数中每个粒子计算访存量的统计值. 因此,如何将计算密度在1~2 FLOPB的访存密集型模块,通过性能优化策略发挥高计算密度型异构设备的计算性能,是关键性的研究内容,也是本文的研究重点. 在本章中通过中间变量的即时计算,基于SM片上存储的软件缓存设计,热点函数合并3种优化方法展开介绍.
3.1 中间变量的即时计算
在传统基于CPU的程序设计中,开发者更倾向于主动寻找公用数据预先计算并暂存于内存中,利用多级高速缓存,通过索引获取数据,通过增加访存量换取计算量的减少. 然而,这种优化方法并不适合于基于宽向量计算的高计算密度型异构设备,大量引入访存会限制计算能力的发挥,同时使用索引的非规则访存模式也不适用于向量计算. 因此,考虑到新架构的特点,本文采用了与传统方法截然相反的优化方法来提高计算性能.
在VirtEx中,磁场、温度、密度、安全因子等中间变量可以将预计算转换为即时计算,引入热点函数中,按照每个粒子对中间变量的需求完成计算. 该操作可以有效减少热点函数中的规则访存和非规则访存,降低流水线中断次数,避免由于按索引访问所带来的向量重组操作.
通过热点函数分析,可以进行优化的中间变量重要分为2类. 一类以每个径向网格上的极向网格点数mtheta为例,该函数可以在热点函数中完成即时计算:
mthetai=2Floor(πriΔl+0.5). (1) 另一类中间变量却难以直接解析化表达,例如粒子在非结构化扰动场网格中的位置索引信息igrid,其形式为
igridi=1+i−1∑j=0mthetai, (2) mthetai=2πrΔl+δi=ai+b+δi. (3) 如式(2)所示,变量igrid的计算基于变量mtheta的累加式,而由于函数Floor引入的不连续性,导致变量igrid的数学公式不能通过简单的变换和积分得出.
由于极向格点数远大于1,且径向格点在r坐标描述下是均匀的,当残差δi≪1,igrid同样可以表示为
igridi=ai2+bi+c+ri, (4) 其中残差r远小于二次函数部分. 为了能够构建igrid的解析表达式,采用多项式来拟合二次函数的部分,而残差可以通过周期函数f来降低到0.5以下,如图3所示. 从而igrid的解析表达式可以表示为如下的形式:
igridi=Round[ai2+bi+c+f(i)]. (5) 得益于对平衡剖面信息的解析化表达和即时计算,函数PushInterpolation和函数Locate中的随机内存访问过程得到减少. 只有热点函数PushGather中存在针对扰动场回旋平均的随机内存访问,在下面的章节中会论述相应的优化方法.
3.2 基于SM片上存储的软件缓存设计
在基于CPU的通用架构中,内置的缓存机制允许开发者在编程时无需关注高速缓存,更多的是将其视为自动化的访存系统. 而在MT-
3000 处理器中,考虑到性能,内存和SM/AM之间,以及SM/AM和向量寄存器之间的数据交换需要由程序员手动控制. 在处理内存的随机访问时,依赖DMA接口操作需要依赖索引和数据,造成了内存带宽的浪费. 为了解决这个问题,本文针对加速阵列内部片上存储SM设计软缓存机制,充分发挥内存结构和内存局部性的优势.在VirtEx热点函数中有2个非规则访问,其中一个是在函数Push中涉及到对扰动场网格数据的非规则访问,另一个是在函数Charge中涉及到对扰动场网格数据更新的原子写操作.
函数Charge通过累加操作(+=)将粒子信息到网格上,由于粒子分散在子域内的多个进程,且网格数远小于粒子数,这将涉及到原子操作. 读/写锁是MT-3000处理器中解决数据竞争的重要方法,因此基于读/写锁设计了1种多级同步的软件缓存机制,首先在SM中进行细粒度(如单字)更新,不涉及任何同步操作;其次,使用读写锁保证缓存块在被换出时不会受到数据竞争. 同时完成缓存块从SM到主存储器的累加操作.
函数PushGaher主要通过4点回旋平均算法获取粒子在回旋运动轨迹上的扰动场信息. 由于片上缓存空间有限,回旋平均算法的随机访问性质会对主存带来巨大的访存开销. 因此基于片上SM存储设计了1种软件缓存机制,该机制通过粒子索引将网格数据按照缓存块读入,如果向量宽度内所有粒子的索引均在缓存块内命中,组装网格数据向量传到向量寄存器完成向量计算;如果索引未在缓存块命中,按照所需索引完成缓存块数据的更新. 同时考虑到性能和局部性的平衡,设计64个缓存块并使用哈希作为缓存块的标识.
在软件缓存机制的实施后,非规则访存被有效转化,访存带宽的压力得到了缓解. 为缓存命中问题. 进一步地,考虑到回旋平均算法需获取轨迹上每1点的扰动场信息,由于粒子在速度空间分布的随机性,在更新粒子位置后,极坐标方向的粒子分布会被分散,从而扰乱粒子在非结构化扰动场网格上的分布. 程序现有的基于粒子所在径向网格点的排序算法,由于加速阵列中的片上存储空间有限,该算法不足以支撑高计算密度的异构设备,导致缓存命中率的降低.
图4显示了排序算法优化前后,粒子序号与相应的非结构化网格序号之间的关系,其中psi排序是原始的径向排序算法,igrid排序是改进的排序算法,按照粒子所在的网格点排序,增强了空间局部性. 优化后的排序采用桶式排序算法,每个桶对应于粒子所属的网格点,由于粒子运动的对称性,每个桶的容量总是与每个网格的粒子数同序,因此该算法的复杂性与原来的psi排序同样是O(N).
不同排序算法下针对扰动场变量gradphi的缓存命中率,如表2所示,在64个缓存块和1 024 B缓存块大小的情况下,扰动场变量gradphi在没有粒子排序的情况下命中率为77.99%,接近于psi排序下的84.47%,而采用igrid排序可以获得99.15%的缓存命中率,得益于超高的缓存命中率,针对变量gradphi的非规则访问可以被近似视作规则访问.
表 2 不同排序算法下针对扰动场变量gradphi的缓存命中率Table 2. Cache Hit Rate for Disturbance Field Variable gradphi Under Different Sorting Algorithms排序算法 缓存命中率/% 不排序 77.99 psi排序 84.47 igrid排序 99.15 3.3 热点函数合并
通过热点函数面向异构加速器MT-
3000 的移植以及上述几种优化方式的应用. 非规则访存操作已经被近似消除,减轻了访存带宽的压力. 在经过优化后,热点函数PG,PI,Locate的浮点计算量、访存量以及计算密度的统计数据如表3所示,其中mp表示粒子数量,考虑到每个粒子相同的操作,其在统计中作为系数表示. 从数据上可以看出,由于函数PG中的回旋平均操作主要涉及内存访问,其计算密度仅为1.39;而时间占比最高的函数PI,考虑到基于粒子的计算特点,计算密度仅为12.4;而函数Locate在经过变量即时计算优化后,计算密度达到56.3. 综上所述,时间占比高达40%的函数Push的计算密度需要进一步提高计算访存比.表 3 热点函数合并优化后计算密度统计Table 3. Hot Spot Function is Merged and Optimized to Calculate the Density Statistics函数 浮点计算量/FLO 访存量/B 计算密度/FLOPB PG 277mp 198.64mp 1.39 PI 1 888mp 152mp 12.4 Locate 12 161mp 216mp 56.3 PushOpt 14 326mp 134.64mp 106.4 注:变量mp表示粒子数量,变量前系数为热点函数中每个粒子计算访存量的统计值. 函数PG,PI,Locate在PIC算法中是计算粒子运动的3个相关函数,函数Locate负责计算插值系数,函数PG负责获取网格数据,函数PI负责推动粒子,三者在算法上具备可合并性. 将函数Locate引入到函数Push中,并将函数PG和PI合并,合并后输入仅为粒子信息和网格信息,输出为粒子信息,减少了对于大量中间变量的读写. 优化函数PushOpt的计算密度达到106.4 FLOPB,进一步缩小了与理论值的差距.
4. 优化性能测试及分析
4.1 中等规模基准算例性能测试
在该这个基准算例测试中,我们用1个MPI进程控制1个MT-3000加速集群(簇),在天河新一代超算系统上使用120个节点上的480个MPI进程和480个簇. 该基准测试使用了1.23 × 106个网格,模拟了2.5 × 109个粒子.
表4显示了CPU版本和优化版本之间在主循环和热点函数上的性能对比,CPU版本的3个主要的热点函数的占比达到86.06%. 结果显示,基于MT-
3000 处理器的应用加速效果良好,总体速度提高了4.2倍,其中函数Push和函数Locate分别实现了10.9倍和13.3倍的加速,在具有原子操作的函数Charge实现了16.2倍的性能提升.表 4 基准算例的性能表现Table 4. The Performance of Benchmark Examples热点函数 CPU版本 优化后版本 加速比 计算时间/s 占比/% 计算时间/s 占比/% 主循环 845.63 100 201.46 100 4.2 Push 323.86 38.30 29.64 14.71 10.9 Locate 128.69 15.22 9.67 4.80 13.3 Charge 275.19 32.54 16.98 8.43 16.2 4.2 扩展性测试
本节展示了优化后的VirtEx程序的弱扩展性测试结果. 在弱扩展性测试中,基准测试为120个节点,使用了3.86 × 105个网格,模拟了3.7 × 109个粒子. 随着节点数增加至3 840个,模拟的粒子数也相应的增加到了1.18 × 1011. 经过多轮测试取平均后的并行效率,如图5所示,在天河新一代超算系统的3 840个节点5 898 240个加速器核心上,其并行效率为88.4%,展示了良好的弱扩展性.
5. 结 论
基于天河新一代超算系统的异构加速器MT-
3000 对大规模并行磁约束聚变回旋动理学模拟代码VirtEx进行代码移植和性能优化,围绕高计算密度型系统和访存密集型应用间存在的矛盾. 通过中间变量的即时计算、定制化的软件缓存设计、空间局部性优化、热点函数合并等优化策略,并通过数据分析验证了优化的合理性. 同时在基准测试中,VirtEx的优化显示了良好的加速效果,其中函数Push提速10.9倍,函数Locate提速13.3倍,函数Charge提速16.2倍,从而使整个程序提速4.2倍. 并且在3 840个节点的5 898 240个加速器核心上展示了良好的可扩展性,并行效率为88.4%.作者贡献声明:李青峰负责程序设计、移植、测试,并撰写论文;李跃岩负责设计并实现优化算法;栾钟治负责程序瓶颈分析和解决方案提供;张文禄提供了针对程序原理和算法方面的指导;龚春叶提供了针对异构加速设备的优化指导;郑刚提供了系统测试环境及保障工作;康波提供了共性技术的指导;孟祥飞负责设计研究方案并把控研究进度.
-
表 1 缓存污染攻击类型
Table 1 Types of Cache Poisoning Attacks
实现方法 伪造字段 代表性攻击 TXID与源端口号去随机化 ANSWER字段 侧信道攻击 伪造权威区和附加区的信息 NS记录 Kaminsky攻击
MaginotLine攻击递归解析服务器中实现分片嫁接 ANSWER字段 分片重组攻击 BGP前缀劫持 ANSWER字段 BGP劫持攻击 表 2 DNS软件漏洞类型
Table 2 Types of DNS Software Vulnerabilities
漏洞类型 危害威胁 任意代码执行 攻击者能够在目标主机或目标进程中执行任意命令或代码 访问控制绕过 攻击者绕过身份验证,获得访问权限 攻击提权 获取系统或应用的额外权限 信息泄露 用户或系统敏感数据泄露 程序崩溃 扰乱服务器功能,致使其不能正常为用户提供服务 表 3 DNS软件漏洞详细信息
Table 3 Details of DNS Software Vulnerabilities
软件名称 漏洞总数
(141个)漏洞攻击类型 任意代码执行 访问控制绕过 攻击提权 信息泄露 程序崩溃 最新版本 平均水平/% 最新版本 平均水平/% 最新版本 平均水平/% 最新版本 平均水平/% 最新版本 平均水平/% ISC BIND 36 - 5.60 - 2.80 - 5.60 - 2.80 1, 7.5 83.20 Unbound 7 - - - - - - - - 2, 7.5 100 DNSmasq 17 - 17.60 - - - - - 5.90 - 76.50 Knot DNS 5 - - - - - - - - 1, 7.5 100 PowerDNS 28 - - - 3.60 - 3.60 - 3.60 1, 7.5 89.20 Mikrotik 48 - 14.60 - - - 2.10 - - - 83.30 软件名称 漏洞分数 高危漏洞占比/% 中危漏洞占比/% 低危漏洞占比/% ISC BIND 45.20 48.40 6.40 Unbound 70.00 30.00 - DNSmasq 66.60 33.40 - Knot DNS 78.60 21.40 - PowerDNS 50.00 48.50 1.50 Mikrotik 43 57 - 注:漏洞攻击类型中,平均水平一栏中所示数字为该漏洞类型在所有漏洞类型中的分布比例. 最新版本一栏中所示数字为最新版本中该类型漏洞数量及平均漏洞分数(漏洞数量,平均漏洞分数);表格中标明“-”处代表软件在当前版本情况下不存在该类漏洞. 表 4 DNSCurve防御原理与相关攻击
Table 4 DNSCurve Defense Principles and Related Attacks
使用方法 针对攻击 加密DNS请求与响应 DNS伪造、DNS信息窥探收集 加密身份验证 DNS记录伪造 过滤攻击者伪造的恶意DNS数据包 DNS拒绝服务攻击 使用96位随机数、密文传输 重放攻击 表 5 DNSSEC记录类型与密钥类型
Table 5 DNSSEC Record Types and Key Types
类型 标记 意义 记录类型 DNSKEY 记录保存ZSK,KSK的公钥 DS record 由父域ZSK私钥签名,用以保护子域
KSK公钥完整性RRSIG KSK私钥对ZSK公钥的签名,
保护ZSK公钥完整性密钥类型 ZSK 区域签署密钥,于对域内各类型数据进行签名 KSK 密钥签署密钥,于对ZSK公钥签名 表 6 安全机制与DNS递归解析服务安全攻击的关系
Table 6 The Relationship Between the Security Mechanism and the Security Attack of the DNS Recursive Resolution Service
DNS安全扩展机制 攻击类型 缓存污染 DNS劫持 直接破坏DNS
递归解析服务器利用DNS递归解析服务器
攻击其他服务器软件漏洞利用 ① ② ① ② ④ ⑤ ④ ⑤ ⑥ ③ 机密性 DoT ○ ● ○ ● ○ ○ ○ ○ ○ ○ DoH ○ ● ○ ● ○ ○ ○ ○ ○ ○ DoQ ○ ● ○ ● ○ ○ ○ ○ ○ ○ DNSCurve ○ ● ○ ● ○ ○ ○ ○ ○ ○ DNSCrypt ○ ○ ○ ● ○ ○ ○ ○ ● ○ QNAME最小化 ○ ● ○ ○ ○ ○ ○ ○ ○ ○ 完整性 DNS cookie ● ○ ○ ○ ○ ○ ○ ● ● ○ DNSSEC ● ○ ● ○ ○ ● ○ ● ○ ○ 源地址认证 ○ ○ ● ○ ● ● ● ● ● ○ DNS-0x20 encoding ● ○ ○ ○ ○ ○ ○ ○ ○ ○ TXID与源端口随机化 ● ○ ○ ○ ○ ○ ○ ○ ○ ○ 可用性 DNS响应速率限制 ○ ○ ○ ○ ○ ○ ○ ● ○ ○ DNS递归解析服务池 ○ ○ ○ ○ ● ○ ○ ○ ○ ○ 规则匹配 ● ○ ● ○ ○ ○ ○ ○ ○ ○ 版本隐藏 ○ ○ ○ ○ ○ ○ ○ ○ ○ ● 软件维护与升级 ○ ○ ○ ○ ○ ○ ○ ○ ○ ● 注:利用漏洞:①缺乏身份认证机制/完整性保护;②数据明文传输;③软件系统存在安全漏洞;④缺乏流量访问控制;⑤ 对异常流量缺乏鉴别能力;⑥具有被利用为放大器的潜力.符号:○几乎不具备防御能力;●可以作为主要的防御缓解措施;●存在一定的辅助性缓解作用. 表 7 3类常见攻击的防御手段
Table 7 Defenses Against Three Common Types of Attacks
DNS安全扩展机制 NXDOMAIN攻击 幻域攻击 泛洪攻击 DNSSEC cache-validation √ √ × nxdomain cut √ √ × 源地址认证 √ √ √ 递归解析服务器池 × × √ 注:“√”表示DNS安全扩展机制可以缓解该攻击;“×”表示DNS安全扩展机制不能缓解该攻击. 表 8 不同信道下攻击的防御手段比较
Table 8 Comparison of Defenses Against Attacks in Different Channels
攻击信道 不同部署位置下存在
区别的防御机制通用防御
机制客户端与递归
解析服务器端DNSCrypt 源地址认证 DNS cookie 递归解析服务器端与
权威服务器端DNSSEC cache-validation 响应速率限制 -
[1] Mockapetris P V. RFC1034 Domain Names-Concepts and Facilities[S]. Fremont, CA: IETF Community, 1987
[2] Mockapetris P V. RFC1035 Domain Names-Implementation and Specification[S]. Fremont, CA: IETF Community, 1987
[3] Callejo P, Cuevas R, Vallina-Rodriguez N, et al. Measuring the global recursive DNS infrastructure: A view from the edge[J]. IEEE Access, 2019, 7: 168020−168028 doi: 10.1109/ACCESS.2019.2950325
[4] Khormali A, Park J, Alasmary H, et al. Domain name system security and privacy: A contemporary survey[J]. Computer Networks, 2021, 185: 107699 doi: 10.1016/j.comnet.2020.107699
[5] Van Der Toorn O, Müller M, Dickinson S, et al. Addressing the challenges of modern DNS a comprehensive tutorial[J]. Computer Science Review, 2022, 45(1): 100−469
[6] Grothoff C, Wachs M, Ermert M, et al. Toward secure name resolution on the internet[J]. Computers & Security, 2018, 77: 694−708
[7] Zou Futai, Zhang Siyu, Pei Bei, et al. Survey on domain name system security C]//Proc of the 1st IEEE Int Conf on Data Science in Cyberspace (DSC). Piscataway, NJ: IEEE, 2016: 602−607
[8] Kim T H, Reeves D. A survey of domain name system vulnerabilities and attacks[J]. Journal of Surveillance, Security and Safety, 2020, 1(1): 34−60
[9] Schmid G. Thirty years of DNS insecurity: Current issues and perspectives[J]. IEEE Communications Surveys & Tutorials, 2021, 23(4): 2429−2459
[10] 王文通,胡宁,刘波,等. DNS 安全防护技术研究综述[J]. 软件学报,2020,31(7):2205−2220 Wang Wentong, Hu Ning, Liu Bo. Survey on technology of security enhancement for DNS[J]. Journal of Software, 2020, 31(7): 2205−2220(in Chinese)
[11] 张曼,姚健康,李洪涛,等. DNS 信道传输加密技术:现状,趋势和挑战[J]. 软件学报,2024,35(1):309−332 Zhang Man, Yao Jiankang, Li Hongtao. Encryption technologies for DNS channel transmission: Status, trends and challenges[J]. Journal of Software, 2024, 35(1): 309−332(in Chinese)
[12] 张宾,张宇,张伟哲. 递归侧 DNS 安全研究与分析[J/OL]. 软件学报[2024-03-05]. https://jos.org.cn/jos/article/abstract/6987 Zhang Bing, Zhang Yu, Zhang Weizhe. Study and analysis of recursive side DNS security [J/OL]. Journal of Software[2024-03-05]. https://jos.org.cn/jos/article/abstract/6987(in Chinese)
[13] Moura G C M, Castro S, Hardaker W, et al. Clouding up the internet: How centralized is dns traffic becoming?[C]//Proc of the 20th ACM Internet Measurement Conf. New York: ACM, 2020: 42−49
[14] Li Xiang, Lu Chaoyi, Liu Baojun, et al. The maginot line: Attacking the boundary of DNS caching protection [C]//Proc of the 32nd USENIX Security Symp. Berkeley, CA: USENIX Association, 2023: 3153−3170
[15] Schomp K, Callahan T, Rabinovich M, et al. On measuring the client-side DNS infrastructure[C]//Proc of the 13th Conf on Int measurement Conf. New York: ACM, 2013: 77−90
[16] Romain Fouchereau. Securing anywhere networking[EB/OL]. [2024−03-05]. https://efficientip.com/wp-content/uploads/2022/10/IDC-EUR149048522-EfficientIP-infobrief_FINAL.pdf
[17] (本刊综合. 2014年中国网络安全大事记 [J/OL]. 保密工作,2015[2024- Journal Synthesis. China's cybersecurity events in 2014 [J/OL]. Secrecy, 2015[2024-01-01]. http: //sdghasgdas (in Chinese) 01-01]. http://sdghasgdas
[18] Ameet Naik. Anatomy of a BGP hijack on Amazon's route 53 DNS service [EB/OL]. (2018-04-25)[2024-03-05]. https://www.thousandeyes.com/blog/amazon-route-53-dns-and-bgp-hijack
[19] Operation Team. October 6th: DNS security incident statement & guide [EB/OL]. [2023-10-06]. https://help.galxe.com/en/articles/8452958-october-6th-dns-security-incident-statement-guide
[20] Alharbi F, Chang Jie, Zhou Yuchen, et al. Collaborative client-side DNS cache poisoning attack [C]//Proc of the IEEE Conf on Computer Communications(INFOCOM 2019). Piscataway, NJ: IEEE, 2019: 1153−1161
[21] Wikipedia Contributors. Dan Kaminsky[EB/OL]. [2024-03-05]. https:// en.wikipedia.org/wiki/Dan Kaminsky
[22] Sun Hungmin, Chang Wenhsuan, Chang Shihying, et al. DepenDNS: Dependable mechanism against DNS cache poisoning [C]//Proc of the 8th Int Conf on Cryptology and Network Security (CANS 2009). Berlin: Springer, 2009: 174−188
[23] Man Keyu, Qian Zhiyun, Wang Zhongjie, et al. Dns cache poisoning attack reloaded: Revolutions with side channels [C]//Proc of the 2020 ACM SIGSAC Conf on Computer and Communications Security. New York: ACM, 2020: 1337−1350
[24] Zheng Xiaofeng, Lu Chaoyi, Peng Jian, et al. Poison over troubled forwarders: A cache poisoning attack targeting DNS forwarding devices [C]// Proc of the 29th USENIX Security Symp (USENIX Security 20). Berkeley, CA: USENIX Association, 2020: 577−593
[25] Brandt M, Dai Tianxiang, Klein A, et al. Domain validation++ for mitm- resilient pki[C]//Proc of the Conf on Computer and Communications Security (ACM SIGSAC 2018). New York: ACM, 2018: 2060−2076
[26] Cho S, Fontugne R, Cho K, et al. BGP hijacking classification [C]//Proc of the 2019 Network Traffic Measurement and Analysis Conf (TMA 2019). Piscataway, NJ: IEEE, 2019: 25−32
[27] Wikipedia Contributors. DNS hijacking[EB/OL]. [2024-03-05]. https://en. wikipedia.org/wiki/DNS_hijacking
[28] Braun B. Investigating dns hijacking through high frequency measurements[D]. San Diego: UC San Diego, 2016
[29] Weaver N, Kreibich C, Paxson V. Redirecting DNS for ads and profit [C/OL]//Proc of the USENIX Workshop on Free and Open Communications on the Internet (FOCI 11). Berkeley, CA: USENIX Association, 2011[2024−03−05]. https://www.usenix.org/legacy/events/foci11/tech/final_files/ Weaver.pdf
[30] Tsai E, Kumar D, Raman R S, et al. CERTainty: Detecting DNS manipulation at scale using TLS certificates[J]. arXiv preprint, arXiv: 2305.08189, 2023
[31] Pearce P, Jones B, Li F, et al. Global measurement of DNS manipulation [C]//Proc of the 26th USENIX Security Symp (USENIX Security 17). Berkeley, CA: USENIX Association, 2017: 307−323
[32] Fejrskov M, Pedersen J M, Vasilomanolakis E. Detecting DNS hijacking by using NetFlow data [C]//Proc of the 2022 IEEE Conf on Communications and Network Security (CNS). Piscataway, NJ: IEEE, 2022: 273−280
[33] Liu Baojun, Lu Chaoyi, Duan Haixin, et al. Who is answering my queries: Understanding and characterizing interception of the DNS resolution path [C]// Proc of the 27th USENIX Security Symp (USENIX Security 18). Berkeley, CA: USENIX Association, 2018: 1113−1128
[34] Randall A, Liu Enze, Padmanabhan R, et al. Home is where the hijacking is: Understanding DNS interception by residential routers [C]//Proc of the 21st ACM Internet Measurement Conf. New York: ACM, 2021: 390−397
[35] Radware. What is DNS flood attack (DNS flooding)[EB/OL]. [2024−03-05]. https://www.radware.com/security/DDOS-knowledge-center/DDOSpedia/dns-flood/
[36] Bortzmeyer S, Huque S. RFC8020: NXDOMAIN: There Really is Nothing Underneath[S]. Fremont, CA: IETF Community, 2016
[37] whatsmydns. net. NXDOMAIN attacks[EB/OL]. [2024-03-05]. https://www.whatsmydns.net/dns-security/dns-attacks/nxdomain-attacks
[38] Li Weimin, Chen Luying, Lei Zhenming. Alleviating the impact of DNS DDOS attacks [C]//Proc of the 2nd Int Conf on Networks Security, Wireless Communications and Trusted Computing. Piscataway, NJ: IEEE, 2010: 240−243
[39] Alieyan K, Kadhum M M, Anbar M, et al. An overview of DDOS attacks based on DNS [C]//Proc of the 2016 Int Conf on Information and Communication Technology Convergence (ICTC). Piscataway, NJ: IEEE, 2016: 276−280
[40] Yazdani R, van Rijswijk-Deij R, Jonker M, et al. A matter of degree: Characterizing the amplification power of open DNS resolvers [C]//Proc of the 23rd Int Conf on Passive and Active Network Measurement(PAM 2022). Berlin: Springer, 2022: 293−318
[41] Duan Huaiyi, Bearzi M, Vieli J, et al. CAMP: Compositional amplification attacks against DNS [C]//Proc of the 33rd USENIX Security Symp (USENIX Security 24). Berkeley, CA: USENIX Association, 2024: 5769−5786
[42] Anagnostopoulos M, Kambourakis G, Gritzalis S, et al. Never say never: Authoritative TLD nameserver-powered DNS amplification[C/OL]//Proc of the 2018 IEEE/IFIP Network Operations and Management Symp. Piscataway, NJ: IEEE, 2018[2024-03-05]. https://ieeexplore.ieee.org/stamp/stamp.jsp? arnumber=8406224&casa_token=i0ocXejqPzYAAAAA:7FixmD7NWvuKbHLvZrqk7tIisTx0whU-ZayJOiGDI5ZxdwehPvop1x1S9QOqMRZ8wb2WdtYrVFo
[43] Nawrocki M, Jonker M, Schmidt T C, et al. The far side of DNS amplification: Tracing the DDoS attack ecosystem from the internet core[C]// Proc of the 21st ACM Internet Measurement Conf. New York: 2021: 419−434
[44] Nosyk Y, Korczyński M, Duda A. Routing loops as mega amplifiers for dns-based ddos attacks[C]//Proc of the 23rd Int Conf on Passive and Active Network Measurement. Berlin: Springer, 2022: 629−644
[45] Wikipedia Contributors. DNS flood[EB/OL]. [2024-03-05]. https://en.wikipedia.org/wiki/DNS_Flood
[46] rsd attack. cyberattack[EB/OL]. [2024-03-05]. https://cybatk.com/2017 /03/25/rsd-attack/
[47] Afek Y, Bremler-Barr A, Shafir L. NXNSAttack: Recursive DNS inefficiencies and vulnerabilities [C]//Proc of the 29th USENIX Security Symp (USENIX Security 20). Berkeley, CA: USENIX Association, 2020: 631−648
[48] Sommese R, Claffy K C, van Rijswijk-Deij R, et al. Investigating the impact of DDOS attacks on DNS infrastructure [C]//Proc of the 22nd ACM Internet Measurement Conf. New York: ACM, 2022: 51−64
[49] Allor P, Armstrong K, Beardsley T, et al. CVE[EB/OL]. [2024-03-05]. https://cve.mitre.org/
[50] somebody. DNSpooq series vulnerability analysis and reproof[EB/OL]. [ 2024-03-05]. https://www.venustech.com.cn/new_type/aqldfx/20210201/22352.html
[51] somebody. Vulnerability details : CVE−2020−8616[EB/OL]. [ 2024-03-05]. https://www.cvedetails.com/cve/CVE-2020-8616/?q=CVE-2020-8616
[52] somebody. Nginx DNS resolver vulnerability (CVE−2021−23017) problem fix[EB/OL]. [2024-03-05]. https://blog.csdn.net/qq_42534026/article/details/117354728
[53] somebody. Vulnerability details : CVE−2022−0635[EB/OL]. [ 2024-03-05]. https://www.cvedetails.com/cve/CVE-2022-0635/?q=CVE-2022-0635
[54] Zhu Liang, Hu Zi, Heidemann J, et al. Connection-oriented DNS to improve privacy and security [C]//Proc of the 2015 IEEE Symp on Security and Privacy. Piscataway, NJ: IEEE, 2015: 171−186
[55] Hu Zi, Zhu Liang, Heidemann J, et al. RFC7858: Specification for DNS over transport layer security (TLS)[S]. Fremont, CA: IETF Community, 2016
[56] Reddy T, Wing D, Patil P. RFC8094 DNS over Datagram Tansport Layer Security (DTLS)[S]. Fremont, CA: IETF Community, 2017
[57] Houser R, Li Zhou, Cotton C, et al. An investigation on information leakage of DNS over TLS [C]//Proc of the 15th Int Conf on Emerging Networking Experiments And Technologies. New York: ACM, 2019: 123−137
[58] Hoffman P, McManus P. RFC8484 DNS Queries over HTTPS (DOH)[S]. Fremont, CA: IETF Community, 2018
[59] Hounsel A, Borgolte K, Schmitt P, et al. Comparing the effects of DNS, DoT, and DoH on web performance [C]//Proc of the Web Conf 2020. New York: ACM, 2020: 562−572
[60] Huitema C, Dickinson S, Mankin A. RFC9250 DNS over Dedicated QUIC connections[S]. Fremont, CA: IETF Community, 2022
[61] Batenburg B. Performance of DNS over QUIC[D]. Enschede: University of Twente, 2022
[62] Lyu M, Gharakheili H H, Sivaraman V. A survey on DNS encryption: Current development, malware misuse, and inference techniques[J/OL]. ACM Computing Surveys, 2022, 55(8)[2024-03-05]. https://dl.acm.org/doi/pdf/10.1145/3547331?casa_token=lSpIfqwii5cAAAAA:b9JvXsifAG6JD0bwupjGOEE2GuWpXrCY14LLrRf5tZ34d7rOYG2NJx1CNQjyw1EDqF97QhnznCDC2A
[63] Badhwar R. Domain name system (DNS) security [M]//The CISO’s Next Frontier: AI, Post-Quantum Cryptography and Advanced Security Paradigms. Berlin: Springer, 2021: 207−212
[64] Hu Guannan, Fukuda K. An analysis of privacy leakage in DoQ traffic [C]//Proc of the CoNEXT Student Workshop. New York: ACM, 2021: 7−8
[65] hvt. DNSCrypt[EB/OL]. [2024-03-05]. https://github.com/DNSCrypt/ dnscrypt-protocol/blob/master/DNSCRYPT-V2-PROTOCOL.txt
[66] Andrews M. RFC7873 Domain Name System (DNS) Cookies[S]. Fremont, CA: IETF Community, 2016
[67] Sury O, Toorop W, Eastlake 3rd D, et al. RFC9018 Interoperable Domain Name System (DNS) Server Cookies[S]. Fremont, CA: IETF Community, 2021
[68] Dickson B. Authenticated DNS over TLS to authoritative servers[EB/OL]. [2024-03-05]. https://www.ietf.org/archive/id/draft-dickson-dprive-aDoTauth-06.html
[69] Bernstein D. Curve25519: High-speed elliptic-curve cryptography[EB/OL]. [2024-03-05]. https://cr.yp.to/ecdh.html
[70] Wikipedia Contributors. DNSCurve[EB/OL]. [2024-03-05]. https://en.wikipedia.org/wiki/DNSCurve
[71] DNSCurve. org. Introduction to DNSCurve[EB/OL]. [2024-03-05]. https:// dnscurve.org/
[72] Cooper A, Tschofenig H, Aboba B, et al. RFC6973 Privacy Considerations for Internet Protocols[S]. Fremont, CA: IETF Community, 2013
[73] Bortzmeyer S, Dolmans R, Hoffman P. RFC9156 DNS Query Name Minimisation to Improve Privacy[S]. Fremont, CA: IETF Community, 2021
[74] Bortzmeyer S. RFC7816: DNS Query Name Minimisation to Improve Privacy[S]. Fremont, CA: IETF Community, 2016
[75] Verisign Labs. Query name minimization and authoritative DNS server behavior[EB/OL]. [2024-03-05]. https://indico.dns-oarc.net/event/21/ contributions/298/attachments/267/487/qname-min.pdf
[76] Arends R, Austein R, Larson M, et al. RFC4033 DNS Security Introduction and Requirements[S]. Fremont, CA: IETF Community, 2005
[77] Laurie B, Sisson G, Arends R, et al. RFC5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence[S]. Fremont, CA: IETF Community, 2008
[78] van Adrichem N L M, Blenn N, Lúa A R, et al. A measurement study of DNSSEC misconfigurations[J/OL]. Security Informatics, 2015, 4(1)[2024-03-05]. https://link.springer.com/content/pdf/10.1186/s13388-015-0023-y.pdf
[79] Herzberg A, Shulman H. DNSSEC: Security and availability challenges [C]//Proc of the 2013 IEEE Conf on Communications and Network Security (CNS). Piscataway, NJ: IEEE, 2013: 365−366
[80] Dagon D, Antonakakis M, Day K, et al. Recursive DNS Architectures and Vulnerability Implications [C/OL]//Proc of the NDSS. Reston, VA, USA: The Internet Society, 2009[2024-03-05]. https://coeus-center.com/articles/ recursive_dns_architectures.pdf
[81] Hubert A, van Mook R. RFC 5452 Measures for Making DNS More Resilient Against Forged Answers[S]. Fremont, CA: IETF Community, 2009
[82] Chandramouli R, Rose S. Secure domain name system (DNS) deployment guide[J/OL]. NIST Special Publication, 2006, 800[2024-03-05]. https://nvlpubs. nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf
[83] Senie D. RFC2827 Network Ingress Filtering: Defeating Denial of Service Attacks which Employ IP Source Address Spoofing[S]. Fremont, CA: IETF Community, 2000
[84] Baker F, Savola P. RFC3704 Ingress Filtering for Multihomed Networks [S]. Fremont, CA: IETF Community, 2004
[85] Vixie P, Schryver V. Dns response rate limiting (dns rrl)[EB/OL]. [2024-03-05]. http://ss.vix.su/~ vixie/isc-tn-2012-1.txt
[86] Rossow C. Amplification hell: Revisiting network protocols for DDOS abuse [C/OL]//Proc of the NDSS. Reston, VA, USA: The Internet Society, 2014[2024-03-05]. https://dud.inf.tu-dresden.de/~strufe/rn_lit/ rossow14amplification.pdf
[87] BlueKrypt. Cryptographic key length recommendation[EB/OL]. [2024-03-05]. https://www.keylength.com/en/4/
[88] BlueKrypt. Cryptographic key length recommendation[EB/OL]. [2024-03-05]. https://www.keylength.com/en/3/
[89] Perdisci R, Antonakakis M, Luo Xiapu, et al. WSEC DNS: Protecting recursive DNS resolvers from poisoning attacks [C]//Proc of the 2009 IEEE/IFIP Int Conf on Dependable Systems & Networks. Piscataway, NJ: IEEE, 2009: 3−12
[90] Nosyk Y, Lone Q, Zhauniarovich Y, et al. Intercept and inject: DNS response manipulation in the wild [C]//Proc of the 24th Int Conf on Passive and Active Network Measurement. Berlin: Springer, 2023: 461−478
[91] Hardaker W. Analyzing and mitigating privacy with the DNS root service [C/OL]//Proc of the NDSS: DNS Privacy Workshop. Reston, VA, USA: The Internet Society, 2018[2024-03-05]. https://ant.isi.edu/~hardaker/papers/ 2018-02-ndss-analyzing-root-privacy.pdf
[92] Dai Tianxiang, Jeitner P, Shulman H, et al. From IP to transport and beyond: Cross-layer attacks against applications [C]//Proc of the 2021 ACM SIGCOMM. New York: ACM, 2021: 836−849
[93] Kaminsky D. Black ops 2008: It’s the end of the cache as we know it[EB/OL]. [2024-03-05]. https://www.blackhat.com/presentations/bh-jp-08/ bh-jp-08-Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf
[94] Trostle J, Van Besien B, Pujari A. Protecting against DNS cache poisoning attacks [C]//Proc of the 6th IEEE Workshop on Secure Network Protocols. Piscataway, NJ: IEEE, 2010: 25−30
[95] Luo Jing. The latest DGA malicious domain name detection method in 2021 (with Python code)[EB/OL]. [2024-03-05]. https://bbs.huaweicloud.com/ blogs/detail/264516
[96] Turner A, Athapathu R, Kharbanda C. Evaluating QUIC for privacy improvements over its predecessors[EB/OL]. [2024-03-05]. https://allison- turner.github.io
[97] Hoang N P, Polychronakis M, Gill P. Measuring the accessibility of domain name encryption and its impact on internet filtering [C]//Proc of the 23rd Int Conf on Passive and Active Network Measurement. Berlin: Springer, 2022: 518−536
[98] Alowaisheq E, Tang Siyuan, Wang Zhihao, et al. Zombie awakening: Stealthy hijacking of active domains through DNS hosting referral [C]//Proc of the 2020 ACM SIGSAC Conf on Computer and Communications Security. New York: ACM, 2020: 1307−1322
[99] Akiwate G, Sommese R, Jonker M, et al. Retroactive identification of targeted DNS infrastructure hijacking [C]//Proc of the 22nd ACM Internet Measurement Conf. New York: ACM, 2022: 14−32
[100] Fujiwara K, Kato A, Kumari W. RFC8198 Aggressive Use of DNSSEC-Validated Cache[S]. Fremont, CA: IETF Community, 2017
[101] Damas J, Neves F. RFC5358 Preventing Use of Recursive Nameservers in Reflector Attacks[S]. Fremont, CA: IETF Community, 2008
[102] Wikipedia Contributors. DNSCrypt[EB/OL]. [2024-03-05]. https://en. wikipedia.org/wiki/DNSCrypt
[103] Davis J. The DNS bake sale: Advertising DNS cookie support for DDOS protection[D]. Provo: Brigham Young University, 2021
[104] Rajendran B. DNS amplification & DNS tunneling attacks simulation, detection and mitigation approaches [C]//Proc of the 2020 Int Conf on Inventive Computation Technologies (ICICT). Piscataway, NJ: IEEE, 2020: 230−236
[105] Lu Keyu, Li Zhengmin, Zhang Zhaoxin, et al. DNS recursive server health evaluation model [C/OL]//Proc of the 18th Asia-Pacific Network Operations and Management Symp (APNOMS). Piscataway, NJ: IEEE, 2016[2024-03-05]. https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7737281&casa_token=wnW5NSnV4hUAAAAA:xF6Bq9m9tzUywItG08EBiTdzZKpKRNbD6zPlXxR-10vbnKUUdX476jQBkeAfb2aPExMIRIbMeFc
[106] Goldlust S, Almond C. How do I restrict only remote users from looking up the server version?[EB/OL]. [2024-03-05]. https://kb.isc.org/docs/aa-00308
[107] Davis J, Deccio C. A peek into the DNS cookie jar: An analysis of DNS cookie use [C]//Proc of the 22nd Int Conf on Passive and Active Network Measurement. Berlin: Springer, 2021: 302−316
[108] Lu Chaoyi, Liu Baojun, Li Zhou, et al. An end-to-end, large-scale measurement of dns-over-encryption: How far have we come? [C]//Proc of the 19th Internet Measurement Conf. New York: ACM, 2019: 22−35
[109] Chhabra R, Murley P, Kumar D, et al. Measuring DNS-over-HTTPS performance around the world [C]//Proc of the 21st ACM Internet Measurement Conf. New York: ACM, 2021: 351−365
[110] Kosek M, Doan T V, Granderath M, et al. One to rule them all? A first look at dns over quic [C]//Proc of the 22nd Int Conf on Passive and Active Network Measurement. Berlin: Springer, 2022: 537−551
[111] Koshy A M, Yellur G, Kammachi H J, et al. An insight into encrypted DNS protocol: DNS over TLS [C]//Proc of the 4th Int Conf on Recent Developments in Control, Automation & Power Engineering (RDCAPE). Piscataway, NJ: IEEE, 2021: 379−383
[112] Vekshin D, Hynek K, Cejka T. DoH insight: Detecting dns over https by machine learning [C]//Proc of the 15th Int Conf on Availability, Reliability and Security. New York: ACM, 2020[2024-03-05]. https://dl.acm.org/doi/pdf/10.1145/3407023.3409192?casa_token=5zTRxSHZ40YAAAAA:o9HHbXL9KKClSwL07f_UkFrmCKXK7Ev-8bJ4B-Td3TukMOvhkPTCqOf6HzIMUZ72yQ5xHdFN0-AWMQ
[113] Takano Y, Ando R, Takahashi T, et al. A measurement study of open resolvers and DNS server version [C/OL]//Proc of the Internet Conf IEICE. Piscataway, NJ: IEEE, 2013[2024-03-05]. https://www.internetconference.org /ic2013/PDF/ic2013-paper01.pdf
[114] 陆柯羽. DNS递归解析服务器推荐系统设计与实现 [D]. 哈尔滨:哈尔滨工业大学,2015 Lu Keyu. Design and implementation of a DNS recursive server recommendation system [D]. Harbin: Harbin Institute of Technology, 2015 (in Chinese)
[115] MacFarland D C, Shue C A, Kalafut A J. Characterizing optimal DNS amplification attacks and effective mitigation [C]//Proc of the 16th Int Conf on Passive and Active Measurement. Berlin: Springer, 2015: 15−27
[116] Deccio C, Argueta D, Demke J. A quantitative study of the deployment of DNS rate limiting [C]//Proc of the 2019 Int Conf on Computing, Networking and Communications (ICNC). Piscataway, NJ: IEEE, 2019: 442−447
[117] 陈怡丹 李馥娟. 数字证书安全性研究[J]. 信息安全研究,2021,7(9):836-843 Chen Yidan, Li Fujuan. Research on security of digital certificate[J]. Journal of information research, 2021, 7(9): 836-843)(in Chinese)
[118] Wander M. Measurement survey of server-side DNSSEC adoption [C/OL]//Proc of the 2017 Network Traffic Measurement and Analysis Conf. Piscataway, NJ: IEEE, 2017[2024-03-05]. https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8002913&casa_token=LgIpHGNSwPgAAAAA:2YFrNJv2Bp8T5n0J6PiN214AbOask5jtPpFzWTZHzirxSko7NN2FZP6iZvM9TFj9EIkEo3jZwRw
[119] de Vries W B, Scheitle Q, Müller M, et al. A first look at QNAME minimization in the domain name system [C]//Proc of the 20th Int Conf on Passive and Active Measurement. Berlin: Springer, 2019: 147−160
[120] Hilton A, Deccio C, Davis J. Fourteen years in the life: A root server’s perspective on DNS resolver security [C]//Proc of the 32nd USENIX Security Symp. Berkeley, CA: USENIX Association, 2023[2024-03-05]. https://www.usenix.org/system/files/usenixsecurity23-hilton.pdf
[121] Dagon D, Antonakakis M, Vixie P, et al. Increased DNS forgery resistance through 0x20-bit encoding: Security via leet queries [C]//Proc of the 15th ACM Conf on Computer and Communications Security. New York: ACM, 2008: 211−222
[122] Vyshnevskyi I. DNS and the bit 0x20[EB/OL]. [2024-03-05]. https:// hypothetical.me/short/dns-0x20/
[123] Vyshnevskyi I. DNS resolver advanced options[EB/OL]. [2024-03-05]. https://hypothetical.me/short/dns-0x20/
[124] CZ. NIC. Knot resolver 1.1. 0 release, August 2016[EB/OL]. [2024-03-05]. https://knotresolver.readthedocs.io/en/stable/NEWS.html#knotresolver-1-1-0-2016-08-12
[125] Rukhin A, Soto J, Nechvatal J, et al. A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications[M]. Gaithersburg: US Department of Commerce, Technology Administration, National Institute of Standards and Technology, 2001
[126] Wang Yongge, Nicol T. Statistical properties of pseudo random sequences and experiments with PHP and Debian OpenSSL [C]//Proc of the 19th Computer European Symp on Research in Computer Security. Berlin: Springer, 2014: 454−471
[127] Wikipedia Contributors. Wald–Wolfowitz runs test[EB/OL]. [2024-03-05]. https://en.wikipedia.org/wiki/Wald-Wolfowitz_runs_test
[128] Wikipedia Contributors. Spectral test[EB/OL]. [2024-03-05]. https://en. wikipedia.org/wiki/Spectral_test
[129] Wikipedia Contributors. Pearson's chi-squared test[EB/OL]. [2024-03-05]. https://en.wikipedia.org/wiki/Pearson%27s_chi-squared_test
[130] Korczy´nski M, Nosyk Y, Lone Q, et al. Inferring the deployment of inbound source address validation using DNS resolvers [C]//Proc of the Applied Networking Research Workshop. New York: ACM, 2020: 9–11
[131] MANRS. Mutually agreed norms for routing security[EB/OL]. [2024−03 −05]. https://www.manrs.org/
[132] Lone Q, Luckie M, Korczyński M, et al. Using loops observed in traceroute to infer the ability to spoof [C]//Proc of the 18th Int Conf on Passive and Active Measurement. Berlin: Springer, 2017: 229−241
[133] Korczyński M, Nosyk Y, Lone Q, et al. Don’t forget to lock the front door! inferring the deployment of source address validation of inbound traffic [C]//Proc of the 21st Int Conf on Passive and Active Measurement(PAM 2020). Berlin: Springer, 2020: 107−121
[134] Spoofer Project. The spoofer project[EB/OL]. [2024-03-05]. https://www. caida.org/projects/spoofer/