我的笔记本联网的时候显示dns服务器异常，这是网络服务商的问题还是我的本设置有问题？

Posted 2023-05-16

用360 网络检测是显示：dns服务异常，可能可以登录QQ聊天软件，但是打不开网页。
用W7系统自带的疑难问题检测是显示：DNS服务未响应。
另需说明的是宿舍网线这些都是没问题的。其他舍友都可以连接，我们用的是铁通网，连不上网这个问题尤其是在网比较卡的时候容易出现，我感觉是网络服务商主动关闭了我的网络连接。

、背景

域名系统(Domain Name System，DNS)是互联网的重要基础设施之一，负责提供域名和IP地址之间的映射和解析，是网页浏览、电子邮件等几乎所有互联网应用中的关键环节。因此，域名系统的稳定运行是实现互联网正常服务的前提。近年来，针对域名系统的网络攻击行为日益猖獗，DNS滥用现象层出不穷，再加上DNS协议本身固有的局限性，域名系统的安全问题正面临着严峻的考验。如何快速有效的检测域名系统的行为异常，避免灾难性事件的发生，是当今域名系统乃至整个互联网所面临的一个重要议题。

DNS服务器通过对其所接收的DNS查询请求进行应答来实现对外域名解析服务，因此DNS查询数据流直接反映了DNS服务器对外服务的整个过程，通过对DNS流量异常情况的检测可以对DNS服务器服务状况进行有效的评估。由于导致DNS流量异常的原因是多方面的，有些是由针对DNS服务器的网络攻击导致的，有些是由于DNS服务系统的软件缺陷或配置错误造成的。不同的原因所引起的DNS流量异常所具备的特征也各不相同，这给DNS流量异常检测带来了诸多困难。

目前，在DNS异常流量检测方面，比较传统的方法是对发往DNS服务器端的DNS查询请求数据流中的一个或多个测量指标进行实时检测，一旦某时刻某一指标超过规定的阈值，即做出流量异常报警。这种方法虽然实现简单，但是仅仅通过对这些指标的独立测量来判定流量是否异常过于片面，误报率通常也很高，不能有效的实现异常流量的检测。

近年来，随着模式识别、数据挖掘技术的发展，开始有越来越多的数据模型被引入到DNS异常流量检测领域，如在[Tracking]中，研究人员通过一种基于关联特征分析的检测方法，来实现对异常DNS服务器的识别和定位；[Context]则引入了一种上下文相关聚类的方法，用于DNS数据流的不同类别的划分；此外，像贝叶斯分类[Bayesian]、时间序列分析[Similarity]等方法也被先后引入到DNS异常流量检测中来。

不难发现，目前在DNS异常流量检测方面，已有诸多可供参考利用的方法。但是，每种方法所对应的应用场合往往各不相同，通常都是面向某种特定的网络攻击活动的检测。此外，每种方法所采用的数据模型往往也比较复杂，存在计算代价大，部署成本高的弊端。基于目前DNS异常流量检测领域的技术现状，本文给出了两种新型的DNS流量异常检测方法。该两种方法能够有效的克服目前DNS异常流量检测技术所存在的弊端，经验证，它们都能够对DNS流量异常实施有效的检测。

2、具体技术方案

1）利用Heap’sLaw检测DNS流量异常

第一种方法是通过利用Heap’s定律来实现DNS流量异常检测。该方法创新性的将DNS数据流的多个测量指标进行联合分析，发现它们在正常网络状况下所表现出来的堆积定律的特性，然后根据这种特性对未来的流量特征进行预测，通过预测值和实际观测值的比较，实现网络异常流量实时检测的目的。该方法避免了因为采用某些独立测量指标进行检测所导致的片面性和误报率高的缺点，同时，该方法具有计算量小，部署成本低的特点，特别适合部署在大型DNS服务器上。

堆积定律(Heap’sLaw)[Heap’s]最早起源于计算语言学中，用于描述文档集合中所含单词总量与不同单词个数之间的关系：即通过对大量的英文文档进行统计发现，对于给定的语料，其独立的单词数（vocabulary的size）V大致是语料大小N的一个指数函数。随着文本数量的增加，其中涉及的独立单词（vocabulary）的个数占语料大小的比例先是突然增大然后增速放缓但是一直在提高，即随着观察到的文本越来越多，新单词一直在出现，但发现整个字典的可能性在降低。

DNS服务器通过对其所接收的DNS查询请求进行应答来实现对外域名解析服务。一个典型的DNS查询请求包由时间戳，来源IP地址，端口号，查询域名，资源类型等字段构成。我们发现，在正常网络状况下，某时间段内DNS服务器端所接收的DNS查询请求数和查询域名集合的大小两者间遵循堆积定律的特性，同样的，DNS查询请求数和来源IP地址集合的大小两者间也存在这种特性。因此，如果在某个时刻这种增长关系发生突变，那么网络流量发生异常的概率也会比较高。由于在正常网络状况下DNS服务器端所接收的查询域名集合的大小可以根据这种增长关系由DNS查询请求数推算得到。通过将推算得到的查询域名集合大小与实际观测到的查询域名集合的大小进行对比，如果两者的差值超过一定的阈值，则可以认为有流量异常情况的发生，从而做出预警。类似的，通过将推算得到的来源IP地址集合大小与实际观测到的来源IP地址集合的大小进行对比，同样可以达到异常流量检测的目的。

由于DNS流量异常发生时，DNS服务器端接收的DNS查询请求通常会异常增多，但是单纯凭此就做出流量异常的警报很可能会导致误报的发生。此时就可以根据观测查询域名空间大小的相应变化情况来做出判断。如果观测到的域名空间大小与推算得到的预测值的差值在允许的阈值范围之内，则可以认定DNS查询请求量的增多是由于DNS业务量的正常增长所致。相反，如果观测到的域名空间大小未发生相应比例的增长，或者增长的幅度异常加大，则做出流量异常报警。例如，当拒绝服务攻击(DenialofService)发生时，攻击方为了降低本地DNS缓存命中率，提高攻击效果，发往攻击对象的查询域名往往是随机生成的任意域名，这些域名通常情况下不存在。因此当该类攻击发生时，会导致所攻击的DNS服务器端当前实际查询域名空间大小异常增大，与根据堆积定律所推算出预测值会存在较大的差距，即原先的增长关系会发生突变。如果两者间的差距超过一定的阈值，就可以据此做出流量异常报警。

通过在真实数据上的测试和网络攻击实验的模拟验证得知，该方法能够对常见的流量异常情况进行实时高效的检测。

2）利用熵分析检测DDoS攻击

通过分析各种网络攻击数据包的特征，我们可以看出：不论DDoS攻击的手段如何改进，一般来说，各种DDoS工具软件所制造出的攻击都要符合如下两个基本规律：

1、攻击者制造的攻击数据包会或多或少地修改包中的信息；

2、攻击手段产生的攻击流量的统计特征不可能与正常流量一模一样。

因此，我们可以做出一个大胆的假设：利用一些相对比较简单的统计方法，可以检测出专门针对DNS服务器的DDoS攻击，并且这中检测方法也可以具有比较理想的精确度。

“熵”（Entropy）是德国物理学家克劳修斯(RudolfClausius，1822～1888)在1850年提出的一个术语，用来表示任何一种能量在空间中分布的均匀程度，也可以用来表示系统的混乱、无序程度。信息理论创始人香农（ClaudeElwoodShannon，1916～2001）在1948年将熵的概念引入到信息论中，并在其经典著作《通信的数学原理》中提出了建立在概率统计模型上的信息度量，也就是“信息熵”。熵在信息论中的定义如下：

如果在一个系统S中存在一个事件集合E=E1,E2,…,En，且每个事件的概率分布P=P1,P2,…,Pn，则每个事件本身所具有的信息量可由公式（1）表示如下：　　　　

熵表示整个系统S的平均信息量，其计算方法如公式（2）所示：　　　　

在信息论中，熵表示的是信息的不确定性，具有高信息度的系统信息熵是很低的，反过来低信息度系统则具有较高的熵值。具体说来，凡是导致随机事件集合的肯定性，组织性，法则性或有序性等增加或减少的活动过程，都可以用信息熵的改变量这个统一的标尺来度量。熵值表示了系统的稳定情况，熵值越小，表示系统越稳定，反之，当系统中出现的不确定因素增多时，熵值也会升高。如果某个随机变量的取值与系统的异常情况具有很强的相关性，那么系统异常时刻该随机变量的平均信息量就会与系统稳定时刻不同。如果某一时刻该异常情况大量出现，则系统的熵值会出现较大幅度的变化。这就使我们有可能通过系统熵值的变化情况检测系统中是否存在异常现象，而且这种强相关性也使得检测方法能够具有相对较高的准确度。

将熵的理论运用到DNS系统的DDoS攻击检测中来，就是通过测量DNS数据包的某些特定属性的统计特性（熵），从而判断系统是否正在遭受攻击。这里的熵值提供了一种对DNS的查询数据属性的描述。这些属性包括目标域名长度、查询类型、各种错误查询的分布以及源IP地址的分布，等等。熵值越大，表示这些属性的分布越随机；相反，熵值越小，属性分布范围越小，某些属性值出现的概率高。在正常稳定运行的DNS系统中，如果把查询数据作为信息流，以每条DNS查询请求中的某种查询类型的出现作为随机事件，那么在一段时间之内，查询类型这个随机变量的熵应该是一个比较稳定的值，当攻击者利用DNS查询发起DDoS攻击时，网络中会出现大量的攻击数据包，势必引起与查询类型、查询源地址等相关属性的统计特性发生变化。即便是黑客在发动攻击时，对于发送的查询请求的类型和数量进行过精心设计，可以使从攻击者到目标服务器之间某一路径上的熵值维持在稳定的水平，但绝不可能在所有的路径上都做到这一点。因此通过检测熵值的变化情况来检测DNS系统中异常状况的发生，不仅是一种简便可行的方案，而且还可以具有很好的检测效果。

DNS系统是通过资源记录（ResourceRecord，RR）来记录域名和IP地址信息的，每个资源记录都有一个记录类型（QType），用来标识资源记录所包含的信息种类，如A记录表示该资源记录是域名到IP地址的映射，PTR记录IP地址到域名的映射，NS记录表示域名的授权信息等，用户在查询DNS相关信息时，需要指定相应的查询类型。按照前述思想，我们可以采用DNS查询数据中查询类型的出现情况作为随机事件来计算熵的变化情况，从而检测DDoS攻击是否存在。检测方法的主要内容如图1所示。可以看出，通过比较H1和H2之间的差别是否大于某一个设定的阈值，可以判定系统是否正在遭受DDoS攻击。随着查询量窗口的不断滑动，这种比较会随着数据的不断更新而不断继续下去。检测算法的具体步骤如下所示：

1、设定一个查询量窗口，大小为W，表示窗口覆盖了W条记录。

2、统计窗口中出现的所有查询类型及其在所属窗口中出现的概率，根据公式（2）计算出该窗口的熵H1。　

图1熵分析检测方法

3、获取当前窗口中第一条查询记录所属的查询类型出现的概率，求出该类型所对应的增量

4、将窗口向后滑动一条记录，此时新窗口中的第一条记录为窗口滑动前的第二条记录。

5、获得窗口移动过程中加入的最后一条记录所代表的查询类型在原窗口中出现的概率以及对应的增量

6、计算新窗口中第一条记录所对应的查询类型出现在新窗口中出现的概率，以及对应的增量

7、计算新窗口中最后一条记录所属的查询类型在当前窗口出现的概率以及对应的增量

8、根据前面的结果计算窗口移动后的熵：

重复步骤2至步骤8的过程，得到一系列的熵值，观察熵值的变化曲线，当熵值曲线出现剧烈波动时，可以断定此时的DNS查询中出现了异常。

窗口的设定是影响检测算法的一个重要因素，窗口越大，熵值的变化越平缓，能够有效降低误检测的情况发生，但同时也降低了对异常的敏感度，漏检率上升；反之，能够增加检测的灵敏度，但准确性相应的会降低。因此，窗口大小的选择，需要根据实际中查询速率的大小进行调整。

2009年5月19日，多省市的递归服务器由于收到超负荷的DNS查询而失效，中国互联网出现了大范围的网络瘫痪事故，这起事故可以看作是一起典型的利用DNS查询发起的分布式拒绝服务攻击，这种突发的大量异常查询混入到正常的DNS查询中，必然会使DNS查询中查询类型的组成发生变化。我们利用从某顶级结点的DNS权威服务器上采集到的2009年5月19日9:00-24:00之间的查询日志，来检验算法是否能够对DNS中的异常行为做出反应。图2和图3分别是窗口大小为1,000和10,000时所得到的熵变化曲线，图4是该节点的查询率曲线。　

图2窗口大小为1,000时熵的变化情况　　

图3窗口大小为10,000时熵的变化情况　　

图4查询率曲线

从图2和图3中可以发现，大约从16:00时开始，熵值剧烈上升，这是由于此时系统中查询类型为A和NS的查询请求大量涌入，打破了系统原有的稳定态势，在经历较大的波动之后，又回复到一个稳定值。随着系统中缓存失效的递归服务器不断增多，该根服务器收到的异常数据量逐渐增大，在16:45左右熵值达到一个较低点，此时系统中已经混入了大量的异常查询数据。由于各省递归服务器的缓存设置的不一致，不断的有递归服务器崩溃，同时不断缓存失效的递归服务器加入，一直到21:00左右，这种异常查询量到达峰值，表现为熵值到达一个极低的位置，随着大批递归服务器在巨大的压力下瘫痪，查询数据的组成再次发生剧烈波动，接下来随着大面积断网的发生，异常查询无法到达该根服务器，熵值在经历波动之后又重新回到较稳定的状态，图4中的流量变化也证实了这一点。

图2和图3分别将查询窗口设为1,000和10,000，对比两图可以看出，图2中的熵值变化较为频繁，反映出对DNS异常更加敏感，但同时误检测的几率也较高，图3中熵值的变化相对平缓，对异常情况敏感程度较低，同时误检率也相对较低。

上述例子表明该方法能够及时发现DNS查询中针对DNS服务器的DDoS攻击。将该算法应用到DNS查询流量的实时监测中，可以做到准实时的发现DNS异常从而能够及早采取应对措施。此外，结合使用错误查询类型或者源IP地址等其他属性的分布来计算熵，或是采用时间窗口划分流量等，可以进一步提高异常检测的准确率。

3）利用人工神经网络分类器检测DDoS攻击

针对DDoS攻击检测这样一个典型的入侵检测问题，可以转换为模式识别中的二元分类问题。利用人工神经网络分类器和DNS查询数据可以有效检测针对DNS名字服务器的DDoS攻击。通过分析DNS权威或者递归服务器的查询数据，针对DDoS攻击在日志中所表现出来的特性，提取出若干特征向量，这些特征向量用作分类器的输入向量。分类器选择使用多层感知器，属于神经网络中的多层前馈神经网络。人工神经网络在用于DDoS攻击检测时具有以下显著优点：

1、灵活性。能够处理不完整的、畸变的、甚至非线性数据。由于DDoS攻击是由许多攻击者联手实施的，因此以非线性的方式处理来自多个数据源的数据显得尤其重要；

2、处理速度。神经网络方法的这一固有优势使得入侵响应可以在被保护系统遭到毁灭性破坏之前发出，甚至对入侵行为进行预测；

3、学习性。该分类器的最大优点是能够通过学习总结各种攻击行为的特征，并能识别出与当前正常行为模式不匹配的各种行为。

由于多层感知器具有上述不可替代的优点，因此选择它作为分类器。分类器的输出分为“服务正常”和“遭受攻击”两个结果，这个结果直接反应出DNS服务器是否将要或者正在遭受DDoS攻击。如果检测结果是“遭受攻击”，则相关人员可以及时采取措施，避免攻击行为的进一步发展。

图5DDoS攻击检测

如图5所示，本检测方法主要分为特征提取、模型训练和线上分类三个阶段。在特征提取阶段，需要利用DNS查询数据中已有的信息，结合各种DNSDDoS攻击的特点，提取出对分类有用的特征。模型训练阶段是通过大量的特征数据，模拟出上百甚至上千的DDoS攻击序列，对多层感知器进行训练，多层感知器在训练过程中学习攻击行为的特征，增强识别率。线上分类属于应用阶段，利用软件实现将本方法部署在DNS权威或递归服务器上。通过实时读取DNS查询数据，并将经过提取的特征输入到多层感知器中，就可以快速地识别出本服务器是否将要或正在遭受DDoS攻击，以便采取进一步防范措施。

多层感知器分类的精确率，在很大程度上取决于作为输入的特征向量是否能够真正概括、体现出DDoS攻击的特征。本方法通过仔细分析各种DNSDDoS攻击，以分钟为时间粒度提取出八种能够单独或者联合反映出攻击的特征：

1、每秒钟DNS查询量。这个特征通过对每分钟查询量进行平均获得；

2、每分钟时间窗口内查询率的标准差。公式如下：　　　　

其中，n表示每分钟内查询数据中记录的秒数，Xi表示某一秒钟的查询量，m表示一分钟内每秒钟查询量的均值；

3、IP空间大小。表示一分钟内有多少个主机发出了DNS查询请求；

4、域名空间大小。表示一分钟内有多少域名被访问；

5、源端口设置为53的查询数量。由于某些针对DNS的DDoS攻击将源端口设置为53，因此对这一设置进行跟踪十分必要；

6、查询记录类型的熵的变化情况。公式如下：　　　　

其中n表示时间窗口内记录类型的种类数，Pi表示某种记录类型出现的概率，Xi表示某种记录类型。

7、设置递归查询的比例。由于某些DDoS攻击会通过将查询设置为递归查询来增大攻击效果，因此对这一设置进行跟踪十分必要；

8、域名的平均长度。由于某些DDoS攻击所查询的域名是由程序随机产生的，这必然在查询数据上引起域名平均长度的变化，因此对域名的平均长度进行跟踪也很有意义。　　

图6人工神经网络分类器的结构

神经网络分类器的大致结构如图6所示。如图中所示，本分类器分为三个层次，一个输入层，一个隐藏层，一个输出层。输入层包含八个单元，隐藏层包含20个单元，按照神经网络理论[3]，隐藏层的单元数和输入层的单元数应满足以下关系：

　

H表示隐藏层单元数，N表示输入层单元数。输出层只含有一个单元，输出值包含两个：“1”表示“遭受攻击”，“0”表示“服务正常”。

本检测方法的关键技术点包括以下两个方面：

1、特征的抽取。这些特征必须能够充分、足够地反映DDos攻击发生时带来的查询状况的改变；

2、学习、分类方法。选取多层感知器作为分类器，设计调整了该分类器的具体结构和相关参数，并利用后向传播算法对分类器进行训练。通过将DDoS攻击检测问题转化为包含“服务正常”和“遭受攻击”两种类别的二元分类问题，能够有效地对DNSDDoS攻击进行实时检测。 参考技术A 你们用的是不是通过学校机房分配的网络？有没有用路由器？如果是铁通网线直接接入的，有路由器，在路由设置时，选中自动分配地址选项；电脑不要设IP地址，就不会存在这个问题了。如果要设IP地址，可用211.98.4.1这个DNS地址试试。追问

嗯啊是学校班里的铁通网，宿舍用了交换机。设置上全是自动啊。。。。

追答

还是检查一下路由器的设置是否正确。另外，以前是否正常使用过？我估计，很有可能是和学校的路由产生冲突造成的。

本回答被提问者采纳

笔记： 移动互联网时代 , 如何优化你的网络 —— HttpDNS

笔记： 移动互联网时代 , 如何优化你的网络 —— HttpDNS

• 1.域名解析是什么？

  • 域名通过DNS（Domain Name System）系统转化为服务器的IP地址，以方便机器通过IP 进行寻址和通信

• 2.专用名词

  • 根域、顶级域、二级域 :DNS系统一般采用树状结构进行组织，以ru.wikipedia.org为例，org为顶级域名，wikipedia为二级域名，ru为三级域名

  • 权威DNS:权威DNS即最终决定域名解析结果的服务器，开发者可以在权威DNS上配置、变更、删除具体域名的对应解析结果信息。阿里云云解析（https://wanwang.aliyun.com/domain/dns ）即权威DNS服务提供商。

  • 递归DNS：递归DNS又称为Local DNS，它没有域名解析结果的决定权，但代理了用户向权威DNS获取域名解析结果的过程,递归DNS上有缓存模块(结果缓存的时间超过TTL，即过期)，递归DNS会一级一级地查询各个层级域名的权威DNS直至获取最终完整域名的解析结果

  • 公共DNS：公共DNS是递归DNS的一种特例，它是一种全网开放的递归DNS服务，而传统的递归DNS信息一般由运营商分发给用户。一个比较典型的公共DNS即Google的8.8.8.8，我们可以通过在操作系统配置文件中配置公共DNS来代替Local DNS完成域名解析流程

• 3.解析流程

  • 以访问www.taobao.com为例，一次完整的域名解析流程包括：

    • 终端向Local DNS发起域名解析请求；
    • Local DNS在获取到域名解析请求后首先从Root hints获取根域名服务器的地址（Root hints包含了互联网DNS根服务器的地址信息）；
    • 获取了根域名服务器地址后Local DNS向根域名服务器发起DNS解析请求，根域名服务器返回com顶级域名服务器地址；
    • 随后Local DNS向com域名服务器发起解析请求，并得到taobao.com二级域名服务器的地址；
    • Local DNS向taobao.com二级域名服务器发起解析请求，并最终获得了www.taobao.com的IP地址信息；
    • Local DNS将递归查询获得的IP地址信息缓存并返回给客户端；

• 4.传统的域名解析面临的问题

  • 域名劫持

    • 例如域名A应该返回的DNS解析结果IP1被恶意替换为了IP2，导致A的访问失败或访问了一个不安全的站点,常见的域名劫持场景

      • 黑客侵入了宽带路由器并对终端用户的Local DNS进行篡改，指向黑客自己伪造的Local DNS，进而通过控制Local DNS的逻辑返回错误的IP信息进行域名劫持

      • 由于DNS解析主要是基于UDP协议，攻击者还可以监听终端用户的域名解析请求，并在Local DNS返回正确结果之前将伪造的DNS解析响应传递给终端用户，进而控制终端用户的域名访问行为

      • 最常碰到的域名劫持现象是缓存污染

        • 在接收到域名解析请求时，Local DNS首先会查找缓存，如果缓存命中则返回缓存结果，不再进行递归DNS查询。如果Local DNS针对部分域名的缓存进行更改，比如将缓存结果指向第三方的广告页，就会导致用户的访问请求被引导到这些广告页地址上

      • 备注: Https并不能避免域名劫持的问题，域名解析是发生在网络加密请求交互之前，得先进行域名解析，之后才会有网络加密请求交互， https = http + ssl，SSL只是对服务端进行身份确认，而域名解析是发生在ssl握手之前，所以https并不能解决域名劫持的问题

  • 调度不精准

    • 解析转发

      • Local DNS供应商将请求到自己Local DNS的域名解析请求转发给其他供应商的Local DNS节点，而最终的权威DNS在进行域名解析时会根据Local DNS的IP信息进行智能调度(分配于请求方最近最优相同运营商的CDN节点)，导致Local DNS分配的不是最佳的CDN节点,由于请求是被转发的，从而也延迟用户业务访问时间

    • Local DNS的布署情况

      • 由于Local DNS的资源有限，Local DNS的分配甚至并非遵循就近原则。比如有实际案例显示西藏的用户甚至被分配了北京的Local DNS节点C，导致西藏的用户在进行CDN资源访问时被调度到了北京的CDN节点C上，类似的由于调度精度的缺失带来的访问体验的影响是非常严重的

  • 解析生效滞后

    • 权威DNS变更的解析结果生效滞后: Local DNS的部署是由各个地区的各个运营商独立部署的, 因此各个Local DNS的服务质量参差不齐. 在对域名解析缓存的处理上，各个独立节点的实现策略也有区别，比如部分节点为了节省开支忽略了域名解析结果的TTL时间限制，导致用户在权威DNS变更的解析结果全网生效的周期非常漫长。这类延迟生效可能直接导致用户业务访问的异常

  • 延迟大

    • DNS首次查询或缓存过期后的查询，需要递归遍历多个DNS服务器以获取最终的解析结果，这增加了网络请求的前置延时时间。特别在弱网环境下，往往导致解析超时、解析失败

• 5.HTTPDNS

  通过HTTPDNS服务，我们可以实现包括防止域名劫持、精准调度、实时解析生效等功能，但在DNS解析开销的优化上，我们需要客户端一起配合

  • 防域名劫持

    • HTTPDNS使用HTTP协议进行域名解析，代替现有基于UDP的DNS协议，域名解析请求直接发送到HTTPDNS服务端，从而绕过运营商的Local DNS

    • 商业化的HTTPDNS服务（https://www.aliyun.com/product/httpdns）缓存管理有严格的SLA保障，避免了类似Local DNS的缓存污染的问题

  • 精准调度

    • HTTPDNS在递归解析实现上优化了与权威DNS的交互，通过edns-client-subnet协议（https://datatracker.ietf.org/doc/rfc7871）将终端用户的IP信息直接交付给权威DNS，这样权威DNS就可以忽略Local DNS IP信息，根据终端用户的IP信息进行精准调度，避免LocalDNS的坐标干扰

  • 实时生效

    商业化的HTTPDNS服务上不会存在解析变更全网生效滞后的问题

    • HTTPDNS在快速生效方面有专有的方案，配合阿里云的权威DNS服务云解析（https://wanwang.aliyun.com/domain/dns），用户在权威DNS变更的解析结果将快速同步给HTTPDNS，覆盖原有的缓存记录，帮助用户实现秒级的域名解析切换

  • 备注： 在DNS解析延迟方面，由于HTTPDNS基于HTTP协议，而HTTP基于TCP协议，对比传统的UDP传输多了一些冗余的握手环节，因此从原理上而言网络请求方面的开销并没有降低。但在实际使用过程中，我们可以通过端上的策略来实现一个零延迟DNS解析的方案,下面从客户端角度实现零延迟DNS解析

• 6.域名解析最佳实践

  • 预解析

    在App启动时，针对业务的热点域名在后台发起异步的HttpDNS解析请求，这部分预解析结果在后续的业务请求中可以直接使用，进而消除首次业务请求的DNS解析开销，提升APP首页的加载速度

  • 智能缓存

    通过预解析获取的IP有一定的TTL有效时间，我们需要合理地缓存下来进行管理。操作系统本身的DNS缓存粒度比较粗，在客户端我们可以应用更细粒度的缓存管理来提升解析效率.

    比如当手机网络切换不同的运营商时(比如移动/联通/电信)，对CDN域名的解析结果会发生变化(返回就近的运营商CDN节点IP). 由于本地有缓存，可以避免在网络切换时减少DNS解析带来的额外开销. 当下一次APP启动时直接读取缓存用于网络访问，以提升首屏加载的速度

  • 懒加载

    • 核心的实现思路: 业务层的域名解析请求只和缓存进行交互，不实际发生网络解析请求。如果缓存中存在记录，不论过期与否，先返回业务层缓存中的记录,如果缓存中的记录已过期，则异步网络请求进行HttpDNS解析结果并刷新缓存

    • 业务场景： 后端IP是固定的若干个节点，因此连续的解析结果在环境不变的情况下有很大概率是保持一致的

    • 不适用场景：业务场景下IP变化频繁，并且TTL过期的IP访问不可用，是不建议应用懒加载策略的

    • 提个问题，如何快速将权威DNS变更的解析结果同步给HttpDNS

      HTTPDNS在快速生效方面有专有的方案，配合阿里云的权威DNS服务云解析（https://wanwang.aliyun.com/domain/dns），用户在权威DNS变更的解析结果将快速同步给HTTPDNS，覆盖原有的缓存记录，帮助用户实现秒级的域名解析切换( 查看上面HttpDNS功能 ---- 实时生效 )

• 7.HttpDNS接入的注意点

  • 客户端接入HttpDNS的过程中，要注意手动设置http请求头的host值，原因是HttpDNS中需要将请求的URL的Host值替换为HttpDNS解析获得的ip,而一般网络库(例如HttpUrlConnection)都会将URL中的Host值赋值给Http请求头中的host头，由于服务端会将http请求头的host值作为请求的域名信息进行处理，这将导致服务器解析出现问题

• 8.学习链接:

  移动互联网时代，如何优化你的网络 —— 域名解析篇