DNS是非常简单的系统。您向其发送查询，然后返回答案。在系统内部，您会看到完全一样的简单性：接收查询的DNS解析器可能不知道答案，因此，它将依次将查询发送到系统更深的位置并收集答案。查询和响应过程是相同的，以递归方式应用。简单。
但是，DNS很简单，就像Chess或Go一样简单。它们都是受一小组严格规则约束的受限环境，但是它们都具有惊人的复杂性。
简单的系统可能具有非常深的复杂性。这是形式系统研究的主要主题。
19世纪的数学研究进入了令人反省的高度。他们试图回答的问题是：构成整个数学上层建筑的正式假设是什么？用于自然数的Peano公理是一个很好的例子。如果您采用这些公理并且仅从受约束且定义明确的集合中进行了应用运算，那么是否有可能在数学中得出每个已知的真值（证明正确）语句？这个问题促使怀特海和罗素开始从事20世纪初期具有里程碑意义的三卷著作《数学原理》的研究，该论文旨在仅使用第一原理和符号逻辑来构建整个数学大厦。他们的工作部分是出于对逻辑主义的兴趣，所有数学真理都是逻辑真理的观点。数学被视为哲学研究的“纯粹”形式，其真理独立于任何观察者或任何自然系统。这项研究导致了KurtGödel的工作，探讨了这种方法的局限性。他的不完全性定理是两个数学逻辑定理，它们证明了每个能够建模基本算术的形式公理系统的固有局限性。这些结果对数学逻辑和数学哲学都很重要。第一个不完备性定理指出，不能由有效程序列出其定理的一致公理系统能够证明关于自然数算术的所有真相。对于任何这种一致的形式系统，总会有关于自然数的陈述，但是在系统内无法证明。第二个不完备性定理是第一个不完备定理的扩展，它表明系统无法证明其自身的一致性。
我们始终相信基于规则的自动化系统将在当今的数字世界中广泛运作，因此我们清醒地意识到，这种世界观的局限性是库尔特·哥德尔1931年明确提出的。
我为什么要谈论这个？好吧，哥德尔作品的非正式表达是，任何功能强大到可以使用的正式系统也都可以足够强大地表达悖论。或者，更非正式地说，任何足以表达复合概念的受约束简单系统也都具有难以理解的复杂性。这就是DNS出现的地方！
根区
DNS并不是任何自然语言的词典，尽管如今，当我们使用诸如“ facebook.com”之类的名词作为专有名词时，我们可能会因为混淆这两个概念而感到抱歉！DNS是分层的名称空间。域名是使用标签的有序序列构造的。标签的此有序序列具有许多功能，但也许最有用的是，它可以用作通过DNS名称解析协议将域名转换为关联属性的隐式过程。
例如，我操作一个使用DNS名称www.potaroo.net访问的Web服务器。如果将浏览器定向到该DNS名称，则浏览器首先需要将此DNS名称转换为IP地址，以知道将IP数据包发送到何处以与我的服务器进行交易。这是使用名称结构的地方。在这种情况下，DNS系统将查询根服务器以将此名称转换为相应的IP地址，并且响应将是对.net区域具有权威性的解析器集。向这些.net服务器中的任何一个询问相同的名称，响应将是对potaroo.net区域具有权威性的服务器。询问任何这些potaroo.net相同名称的服务器，您将获得想要的IP地址。每个DNS名称都可以用相同的方式分解。名称本身定义了名称解析处理的顺序。
每个DNS解析操作都有一个起点：根区域。
有一种思想流派拒绝对DNS根域进行任何特殊处理。就像其他区域一样，它只是另一个区域。与其他区域一样，它的一组权威服务器可以接收查询并回答查询。根区域没有魔力，所有这些注意都是完全没有必要的。
但是，我认为这低估了DNS中根区域的重要性。DNS可以看作是一个庞大的分布式数据库。确实，它是如此之大，以至于没有一个单一的静态地图可以识别每一个权威的信息源和权威的数据点集合。取而代之的是，我们使用动态发现的过程，其中DNS名称的解析首先被定向到查找具有与我们要解析的名称相关的数据的权威服务器，然后在该服务器中查询该数据。该系统的优点在于，这些发现查询和最终查询在每种情况下都是完全相同的查询。
但是每个人都必须从某个地方开始。DNS递归解析器不会事先知道所有DNS的权威服务器，而且永远不会。但是它确实知道一件事。它知道至少一台根服务器的IP地址。从这个起点开始，一切都可以即时构建。解析程序可以向根服务器询问所有其他根服务器的名称和IP地址（所谓的启动查询），并且可以将答案存储在本地缓存中。给解析器指定要解析的名称后，它可以从查询根服务器开始，以在名称委托层次结构中查找下一个点，然后从那里继续。
如果这实际上是DNS的工作方式，那么很显然DNS系统将在几秒钟内崩溃。使这种方法可行的是本地缓存。DNS解析器会将答案存储在本地缓存中，并使用此本地保存的信息来回答有关缓存条目有效期的后续查询。对根服务器角色的更精确的陈述可能是，每个DNS解析操作都以对根区域的缓存状态的查询开始。如果无法从本地缓存中回答查询，则查询根服务器。
但是，此声明背后隐藏着令人不舒服的观察。如果根服务器不可访问，则整个DNS将停止运行。在某些方面，这可能是一个夸大的声明，因为DNS和Internet不会突然崩溃。在无法访问根服务器的所有实例的假设情况下，DNS解析器将继续使用本地缓存的信息来工作。但是，由于这些缓存条目超时，它们将被从这些本地解析器中丢弃，因为无法通过重新查询根服务器来刷新它们。随着缓存条目的超时，DNS中的指示灯将逐渐变为黑色。因此，DNS根区域不同于其他所有区域。该区域是其他所有区域的主查询。
由于本地缓存，并非每个DNS查找都使用根区域服务器。从理论上讲，由于缓存未命中，根服务器只会看到查询。如果根区域相对较小且DNS解析程序相对较小，则根区域查询负载应较小。即使Internet扩展了其用户群，查询负载也不一定会增加。如果我们相信根在DNS中的操作这一理论，则由DNS解析器确定根服务器查询负载。
但是，该理论在操作经验中并不成立。为什么我们看到根服务器集合看到查询的持续增长模式？根服务器每天记录的查询总数如图1所示。
图1 –每天的根服务器查询总数（RSSAC002数据）
在过去的4年中，根服务器集合看到的查询量似乎增长了两倍。
我们在做什么呢？
根服务器发布的数据使用RSSAC002中发布的框架，该框架由大多数根服务运营商独立生成。（术语“大多数”表示我无法从B，E或G根目录中找到总查询计数的数据，而无法从A，B，E，F，G或J根目录中找到每日响应代码的计数数据。发布率不完全是每天）。
关于整个根服务，我们能说些什么？令人沮丧的答案是不完整的。我们可以一目了然地了解根系统，还不清楚发布的数据在多长时间内保持一致，也不清楚发布的数据与整体有什么关联。发布的数据占总数的70％吗？还是95％？还是介于两者之间？没人知道。在断言过去四年中查询量“似乎增加了两倍”的断言中，我对这个相当不完整的数据集表示了极大的自由。
遗憾的是，如果没有扎实的数据基础，就很难对根系统的特性做出一些重要的判断。例如，NSEC缓存如何影响根查询卷？还是使用本地根？查询量增长速度有多快？为什么会增长？我们该如何回应？
就像我们世界上的许多事物一样，我们得到了所要付出的代价。根服务是基于利他主义提供的免费服务，而不是作为合同资助的服务。因此，也许有了这个相当嘈杂和不完整的数据集，我们已经获得了比所支付的更多的钱！
根区缩放
增大根区域容量的工作是一项永无止境的任务。图1显示，2018年中期大多数根服务器每天看到600亿个查询，到2020年中期已增长到每天1200亿个查询。根服务器操作员如何响应？
对这些扩展问题的第一组响应是构建具有更大网络容量和更大处理吞吐量的根服务器。但是，只有13台服务器可以使用，因此它永远无法随着Internet的发展而扩展，我们还需要更多。下一个扩展步骤是从单播服务到任意播服务的转换。根服务器可能有26个唯一的IP地址（IPv4中为13个，IPv6中为13个），但是这些服务运营商现在都使用任播在不同位置复制根服务。当前的根服务器站点数在root-servers.org中进行了描述（表1）
| 根 | 任播网站 |
|---|---|
| 一种 | 16 |
| 乙 | 6 |
| C | 10 |
| d | 149 |
| Ë | 254 |
| F | 242 |
| G | 6 |
| H | 8 |
| 一世 | 64 |
| Ĵ | 118 |
| ķ | 73 |
| 大号 | 147 |
| 中号 | 5 |
总共有1,098个站点，其中有根服务器实例。
服务器引擎的数量大于站点数量的计数器，这是因为如今常见的是在一个站点内使用多个服务器引擎，并使用某种形式的查询分发前端在多个反向站点之间分配传入的查询负载。终端引擎。
但是，即使这种形式的分布式服务工程也可能不够。从现在开始的两年后，我们可能需要将根服务能力从当前水平提高一倍，再过两年，我们将需要再次将其增加一倍。一遍又一遍。指数增长是一个非常苛刻的大师。
但是，该任务可能比简单缩放更具挑战性。我们还需要考虑金钱。
威尼斯互联网上的无私奉献精神
根服务使用的模型无疑是当今Internet的不合时宜之处。
操作根服务器实例的12个组织无需任何直接付款或补偿即可这样做。当IANA首次招募组织来担当此角色时，它是在Internet很大程度上是一项研究项目的环境中，这是迈向全球服务的第一步。根服务器运营商的选择基于一种愿望，即以与当时的用户数量相匹配的模式来定位服务器，并且是在很大程度上不自治的模式下，不提供中央融资义务。当时，运营根目录服务的承诺是基于这样的理解，即没有资金可以担当此角色。
那是30多年前，自那时以来，互联网已经发生了许多变化。但是，一件事没有改变。根服务仍然没有组织化的融资模式。根区域中列出的顶级域的管理员不会直接或间接为支持根区域查询的基础结构付费。将查询传递到根区域服务器的各种解析器都不直接或间接付费。没有人付款。它仍然是一种无私的服务。
根服务运营商的总容量需要每两年左右增加一倍，但是这样做必须没有任何共同的或结构化的资金安排。并且，除非我们使用DNS的方式发生其他变化，否则这种加倍的趋势将继续下去，因此随着时间的推移，满足这种查询负载的能力任务将变得越来越昂贵。
但是，请允许我补充一点，这当然不是一个无法解决的问题，目前还没有立即出现的危机。根服务仍然能够充分满足当前的查询负载并吸收针对它的大多数DDOS攻击。但是，这种对服务进行过度工程化的方法似乎更像是蛮力饱和响应，需要不断增加的容量。也许还有其他方法可以减轻传递到根服务器的通信量？我们对传递给根的这些查询了解什么？不同的方法可以缓解其中的部分流量吗？
若要查看如何回答这样的问题，查看传递到根服务器的查询流量可能很有用。
根查询
在过去的几十年中，已经有很多关于根服务和DNS行为的研究。如果根服务器只是为了收集DNS解析器的缓存未命中，那么根上发生的一切与解析器缓存未命中模型并不完全一致。确实，目前尚不清楚到底发生了什么！
据报道，对根服务器的大多数查询都会导致NXDOMAIN响应。在查看已发布的响应代码数据时，似乎有75％的根区域查询导致NXDOMAIN响应（图2），并且这一相对比例在过去几年中一直在增长。
图2 –每天根区NXDOMAIN响应的比例（RSSAC002数据）
此行为的一个非常奇怪的方面是，每个根服务字母所看到的查询流量的百分比似乎相差很大（最多可达20％）。在许多方面，根服务器是故意相同的，并且从每个根服务看到的根区域查询配置文件中的这种变化是不寻常的。
正如Versign的Duane Wessels在2020年6月的DNSOARC 32会议上报告的那样，Chrome浏览器会生成三个单标签DNS查询，其中标签的长度在7到15个字符之间，由字母字符组成。在2015年2月之前，此浏览器使用的代码仅生成10个字符的标签，并且在2015年2月的代码版本中切换到了随机长度和随机标签。浏览器引擎会在启动时进行这些查询，本地IP地址何时更改以及本地DNS服务器是否更改。
Google的Chrome浏览器执行此操作的动机非常明显。许多ISP在其DNS解析器中执行NXDOMAIN替换，并使用指向其自己搜索页面的综合指针来替换“无此类域”响应，这使它们可以从所有那些“无此类域”用户的错字中获利。从Google的角度来看，这种NXDOMAIN替代是搜索是广告投放的主要途径，而广告是Google的核心收入，那么Google的Chrome浏览器平台如何检测NXDOMAIN替换正在发生的网络环境？简单。用自己的随机数随机字符串查询测试DNS，看看如果正在执行NXDOMAIN替换。
据说对DNS的这种无害探测应该是无害的。但是最近有很多Chrome。据报道，当今互联网上所有浏览器使用的三分之二都是使用Chrome浏览器，而当您包含基于Chrome引擎的Edge之类的产品时，使用该浏览器的人数会增加。因此，了解到根据此报告，这些探测现在占据了根服务器总流量的大约50％也许并不奇怪（图3）。
图3 – Chrome查询见根。摘自“ 内部网重定向检测器或伪随机子域攻击？ ”，Duane Wessels，Verisign，2020年6月
互联网的部分优势在于网络基础架构的分离性质，其中许多组件服务提供商在其所选择的活动领域内开展业务，而集体努力的总体流程则由市场力量来决定。没有人负责。但是，尽管这是优点，但也可能是缺点，尤其是在成本降低的情况下。Chrome的设计决定是通过一次性标签查询来探查NXDOMAIN替换，这一决定给Chrome或Chrome用户带来了微不足道的边际成本。但是，由于根服务运营商总查询负载的一半来自此行为，因此确实给根服务运营商带来了巨大的成本。
但是，以同样的方式取代成本和收益，补救这种情况的工具掌握在第三类行为者手中。如果所有递归解析器及其前端负载平衡器执行了有效的NSEC缓存（并且也可能进行了DNSSEC验证），则这些随机不存在的顶级标签Chrome查询将被递归解析器中的NSEC缓存吸收。
在集中协调的环境中，可以直接比较成本和收益，并且可以在成本有利的地方部署此类解决方案。如果没有这样的编排，则无法激励Google内的Chrome小组或递归解析器运营商花费时间和精力来解决如何减轻此类查询的问题，因此，根服务器不存在问题。激励任何其他方提供补救措施的手段。
但是，将整个查询流量直接归因于Chrome可能是不公平的。当我们研究DNS中NXDOMAIN响应的处理方式时，我们发现DNS本身就是问题的一部分。我们查看了当浏览器将查询传递给响应为NXDOMAIN的DNS并在Internet上对大约700万用户执行此测试时DNS的行为（https://www.potaroo.net/ispcol/2019- 02 / nxd.html）。在该域名的权威服务器上，每个原始浏览器查询平均看到2.2条查询，是我们最初期望的两倍多。因此，也许Chrome仅占根服务器负载的25％，而DNS解析器基础结构负责使呈现给根服务器的查询量增加一倍。
这里还有一个额外的放大系数。DNS还具有相当大的“僵尸”流量比例。APNIC实验室使用包含标签创建时间的动态DNS标签进行的一项研究发现，在我们的权威服务器上看到的所有DNS查询中，约有25％是与该DNS标签最初使用无关的查询（https：// www。 potaroo.net/ispcol/2016-03/zombies.pdf）。在DNS中重播“旧”查询有多种原因。在很多地方都捕获并记录了查询，对这些日志的分析似乎涉及重新查询。在其他情况下，解析器似乎陷入了紧密的代码循环，并且对同一个DNS名称进行了大量的查询（数周之内数十亿次重复）。
尽管这并不是直接由于Chrome浏览器引擎而引起的，但如果Chrome使用DNS层次结构中比根区域更深的区域执行此查询，则原始查询负载和放大后的负载将从根区域掉落。根服务器将摆脱目前查询负载的一半以上。
除了这个重要的流量组成部分之外，还存在名称泄漏的因素。许多环境使用本地定义的DNS区域来标记服务，并且当设备移出这些本地域时，它们仍然可以查询这些本地定义的名称。未授权区域的根目录查询包括顶级标签.home，.corp，.local和.mail，以及许多常见的CPE供应商名称（https://www.potaroo.net/presentations/2014 -06-24-namecollide.pdf）。这些标签的委派将使此类查询远离根区域，但同时可能会引发一系列安全问题，其中打算在一个网络上下文中解析的名称随后在不同的上下文中解析，这令人惊讶且可能会受到损害结果。尽管在个别情况下，可以通过通过字段更新来更改应用程序或设备的行为来减轻此类查询到根的泄漏，但在其他情况下，该行为更加根深蒂固，更难以停止。
查询偏向
即使在私有上下文中，更改设备和应用程序的行为以使用委托域，也可以将查询推离根，这是减轻根查询量指数增长的一种可能方法。我不太乐观这会非常有效，因为DNS中当前的成本分配与此相反。使用根是快速和免费的选项，并且根服务器非常注意数据隐私。在使用Chrome的情况下，使用未委派的私有使用域或随机名称是一种免费的选择，因此查询数据在很大程度上是私有的。任何其他方法都会将负载推到其他服务器，这可能会给应用程序或设备供应商带来成本。使用根区域是免费，快速且有效的！有什么问题？
因此，也许我们需要研究其他方法。我们还能如何将这些查询偏离根服务器系统？
两种方法可能会有所帮助。
NSEC缓存
第一个在RFC8198或NSEC缓存中描述。如果在DNSSEC签名的区域中不存在顶级标签，并且查询启用了DNSSEC EDNS（0）标志，则来自根服务器的NXDOMAIN响应将包括一个签名的NSEC记录，该记录给出了两个确实存在的标签根区域，“环绕”不存在的标签。NSEC记录说的不只是“此标签不在此区域中”。它说在字典上这两个标签之间的每个标签都不存在。如果递归解析器缓存此NSEC记录，则它可以使用该相同的缓存记录来响应此标签范围内名称的所有后续查询，其方式与传统上使用“正”缓存记录的方式相同。
如果所有递归解析器都执行NSEC缓存，则从递归解析器在根目录中看到的查询量（包括与Chrome查询关联的查询量）将消失。
因此NSEC缓存对于递归解析器很重要。从9.12版本开始，Bind支持此功能。从1.7.0版开始，Unbound支持此功能。从2.0.0版本开始，结解析器支持此功能。但是根区域的查询不断增长。
在APNIC实验室，我们对NSEC缓存进行了评估，并在2019年10月的DNS OARC会议上报告了此工作的结果。这项运动并不十分令人振奋。我们使用的方法使用了两个查询，如果解析器在查询中设置了DNSSEC标志，则第一个查询将生成NXDOMAIN响应和NSEC记录，然后等待2秒，然后对NSEC范围执行第二个查询。从理论上讲，我们应该看到第一个查询而不是第二个查询。大约30％的用户坐在DNS解析器的后面，DNS解析器在查询中设置DNSSEC标志并被观察到执行DNSSEC验证，因此我们可以预期，这样的实验将揭示30％的用户对NSEC缓存的吸收程度。我们观察到的是7％的用户的测量值要低得多（图4）。
图4 – NSEC缓存的测量，2019年4月
可能还为时过早。当我们在2019年8月测量查询名称最小化时，我们看到3％的部署，而一年后的2020年8月，相同的测量结果显示18％的部署。因此，也许我们没有耐心并且测量得太早，如果我们今天重复测量，这个数字可能会更高。但是，也存在这种情况，即测量技术不能很好地适应当今使用的DNS基础结构模型。如今，许多DNS解析器基础结构都位于“服务器场”中，前端查询分发程序将每个传入的查询传递给后端服务器场中的一组DNS解析器引擎之一。尽管前端可能会尝试针对相同域名的查询优化缓存性能，并将所有此类查询定向到同一引擎，对于名称范围而言，相同的方法不一定有效，并且针对不同的标签查询可能会针对不同的解析器引擎。最后，NSEC缓存很可能已经可以正常工作了！在过去的12个月中，NXDOMAIN响应的相对比例一直稳定在所有响应的75％，并且在过去的四个月中，根查询的总量一直保持相对稳定。也许NSEC缓存已经在起作用（不幸的是，关于根服务器报告的质量和一致性的警告在这里适用，并且我们可以做很多事情，而无需进行大量的固态数据验证就可以进行猜测。）我们只是不这样做从可用数据中了解。NSEC缓存可能已经在DNS中工作了，
但是，NSEC缓存是对根区域扩展问题的战术响应，与策略响应不同。它仍然依赖于根服务器基础结构，并使用基于查询的方法来发布根区域的内容。根服务模型并没有真正改变。NSEC缓存的作用是使解析程序能够充分利用NSEC响应中的信息。没有其他改变。
本地根
另一个选择是跳出查询/响应模型来学习根区域的内容，并将整个根区域加载到递归解析器中。这个想法是，如果递归解析器加载了根区域的副本，则它可以在根区域内容的本地副本的有效期内相对于根服务器自主运行。它将不向根服务器发送任何进一步的查询。加载本地根区域所遵循的过程在RFC8806中有详细记录，我还应该注意LocalRoot服务（https://localroot.isi.edu/），该服务在根区域发生变化时提供DNS NOTIFY消息。
目前，这种方法有其缺点。使用起来很笨拙。您如何知道您所服务的区域是当前的正版根区域？是的，对区域进行了签名，但并非对区域中的每个元素都进行了签名（例如，NS记录），并且让客户端执行对区域中的每个数字签名进行验证的任务，目前，有一些其中1,376。在整个根区域签署之前（该提议目前仍是IETF流程中的草案：https : //tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-09），那么您不能确定根区域就是根区域。
但是，与NSEC缓存不同，此模型可以更改根服务的性质。如果最近有一件事情我们学得很好，那就是内容的分发。确实，我们对这项活动的关注程度如此之大，以至于整个互联网似乎不过是一小部分内容分发网络。如果根区域完全使用区域签名进行签名，从而允许递归解析器确认其有效性和通行性，并且仅作为另一个对象提交给这些分发系统，则CDN基础结构完全有能力将该区域馈送到以下区域的整个集合：递归解析器。也许，如果我们更改了根区域的管理机制，以按照严格的时间表每24小时生成一个新的区域文件，我们可以消除整个通知上层结构。根区域内容的每次迭代都会提前2个小时发布，并且例如在24小时内有效。
选项？全部挑选！
我们以目前的名义来运作根目录服务，因为到目前为止，它已经足够好了。但是我们不必继续这样做。目前，我们有关于服务如何发展的选项。
通过将一些当前负载转移到域层次结构中较低的委派点，我们可以对当前根查询负载进行重大更改。
通过让解析器更好地利用已签名的NSEC记录，我们可以避免与根系统的进一步扩展有关的一些更为紧迫的紧迫问题。
但这可能还不够。我们可以等待系统崩溃，然后尝试从破碎的混乱中挽救DNS，或者我们现在可以探索一些替代方法，并研究如何突破基于查询的根目录内容传播模型并查看根目录区域只是更大的内容分发生态系统中的另一个内容。如果我们能够以成本有效的方式向每个递归解析器加载根区域的当前副本，而如今这甚至不是一个遥不可及的目标，那么也许我们可以抛开如何扩展根服务器系统以服务于更大范围的问题。数量为“否！” 给越来越苛刻的客户！
