我们曾经认为计算机网络是使用两个基本的通用基础结构组件构建的：名称和地址。每个连接的设备都有一个稳定的协议地址，以允许所有其他设备通过将数据包寻址到该协议地址来发起与此设备的通信事务。而且每个设备都与一个名称相关联，从而使人类用户和人类应用程序可以为这些协议地址使用更方便的别名。通过将名称映射到协议地址，人类使用领域可以通过使用符号名称来导航网络的服务。同时，在数据包级别，数据流由网络根据这些设备地址所在的拓扑信息进行定向。

 

但这就是1980年代的思想和1980年代的网络体系结构。

 

体系结构已经发生了发展，令人惊讶的是，当今的Internet体系结构已经不再使用地址的作用了。如今，由于IPv4地址池已用尽，但同样由于架构的发展而不得不应对网络中大量设备的激增，我们已转向客户端/服务器网络模型客户端启动连接，服务器响应的位置。这意味着客户不需要永久分配的地址。相反，他们只能在通讯时使用地址，否则将其传递回共享地址池。同样，在服务器端，我们已经看到将唯一命名的服务点聚合到服务交付平台中，将客户端引导到适当的服务集合点的多路复用功能是在应用程序级别执行的功能，而不是作为基础结构功能执行的功能。现在，我们使用地址基础结构的方式与1980年代所设想的方式大不相同。互联网的命名基础架构也承受着相同的发展压力，而这些压力正是我想在这里探讨的。DNS如何响应？该调查分为三个部分：信任，隐私和所有其他内容！我想在这里看看这些压力。DNS如何响应？该调查分为三个部分：信任，隐私和所有其他内容！我想在这里看看这些压力。DNS如何响应？该调查分为三个部分：信任，隐私和所有其他内容！

 

1.信任

您可以相信DNS会告诉您什么吗？

 

答案是你可能做不到！

 

信任模型中的这种明显失败已被许多各方以多种方式利用。DNS被视为一个公开的控制通道。例如，如果在DNS中无法解析对命名服务的访问，则该名称可能会被阻止。因此，我们已经看到故意增加了DNS，通过保留DNS中的相关名称解析，将被归类为有害的内容和服务从访问中删除。许多开放的解析器已将对DNS的这种过滤转变为肯定属性。存在许多所谓的“纯净提要”解析器，它们无法解析以某种方式被视为有害或犯罪的服务名称集合。选择性地对DNS进行过滤不仅是竞争性开放解决方案领域的一项显着特征，而且我们 我们还看到许多国家体制将ISP的责任放在阻止某些服务上，并且鉴于地址不再与单个服务唯一相关，因此这些国家法规的实施总是通过DNS阻止来执行。还进行了一些尝试，以尝试通过DNS货币化，其中重写了“无此类域”的NXDOMAIN DNS响应，以通过响应重写将用户发送到赞助者搜索站点。DNS谎言也已用于IPv6过渡环境中，在该环境中，DNS记录（协议地址）被合成以允许用户通过IPv4-IPv6过渡环境。所有这些练习的动机可能会有所不同，但结果是一样的，只要DNS答案是谎言。然后，人们进行了恶意的努力，用谎言代替真实的回答，以误导用户。有一种响应猜测技术，可以尝试在“正常”响应之前插入伪响应，例如在UDP中，第一个响应就是使用的响应。有操纵的胶水记录，甚至攻击零散的数据包。这些攻击形式的阴险性质是，它们依赖于运行正常的主机系统。这里是名称系统本身的基础结构，并且应用程序完全不知道这种操作。有操纵的胶水记录，甚至攻击零散的数据包。这些攻击形式的阴险性质是，它们依赖于运行正常的主机系统。这里是名称系统本身的基础结构，并且应用程序完全不知道这种操作。有操纵的胶水记录，甚至攻击零散的数据包。这些攻击形式的阴险性质是，它们依赖于运行正常的主机系统。这里是名称系统本身的基础结构，并且应用程序完全不知道这种操作。

 

对此的响应需要检测到某种形式的操纵已经发生。更好的是，要阻止向用户展示谎言，请向DNS添加信任机制以向DNS响应添加数字签名。这个想法是，附加到DNS响应的数字签名可以使响应的接收者确信DNS信息是最新的，真实的，尚未被操纵或更改的，并且无法否认。用于将数字签名添加到DNS中的框架DNSSEC大约需要十年的时间。可以将一个或多个密钥对与DNS中的委派区域相关联，并且在此框架中定义了一组五个另外的DNS资源记录（RR），以对每个条目进行签名并帮助验证签名。

 

有关DNSSEC部署的评论差异很大。如果无法验证DNSSEC签名，则全球约25％的用户无法使用DNS命名服务。这是2014年初水平的三倍，因此，采用验证（https://stats.labs.apnic.net/dnssec）的势头肯定会有所增强。但是同时，DNSSEC签名区域的数量似乎很少。在DNS的亿万个授权区域（如今可能数十亿个）中，在一项此类调查（https://www.secspider.net）中，我们看到了约800万个签名区域。也许更相关的指标是按使用情况对域名排名以及该集中DNSSEC签名区域的比率。Alexa排名前25位的列表是一个不错的起点。这些都不是DNSSEC签名的名称。2016年末对Alexa前100万个名称的研究发现，这些名称中只有1％是DNSSEC签名的。对所有.com，.org和.net二级域的类似研究发现，这三个区域中所有域的0.75％至1.0％之间发布了DNSKEY RR。似乎在递归解析器中启用DNS查询验证几乎没有什么缺点，因为很少有流行的DNS名称最初看起来是DNSSEC签名的！

 

为什么DNSSEC区域签名如此罕见？这些DNS名称后面的内容和服务提供商是否对用户的潜在误导无关？当然不是！他们非常担心，因为最终，这完全取决于他们的潜在收入。这是对DNSSEC的无知吗？同样，一点也不！这是一个选择。这些提供者希望防止用户被误导。同样，他们同样希望减少对中介的依赖，并且希望用户服务体验尽可能高效。如果DNSSEC可用，那么内容和服务提供商将使用它。但这不是镇上唯一的表演。这些天，服务供应使用TLS。几乎每个服务URL都有一个HTTPS URL。TLS是否可以将用户误导？不正常。误导或欺骗要求服务提供商的私钥泄漏，或者要求Web PKI证书系统损坏。TLS也很快，因为在TLS握手中提供了验证证书所需的所有凭据。

 

DNSSEC验证速度一样快吗？好吧 DNSSEC验证是一个串行查询序列，一直备份到名称委托路径。DNSSEC区域签名是否易于部署？否。它具有本地密钥管理，ZSK / KSK密钥拆分，有限的自动化功能，对高弹性托管的有限支持。最根本的批评是，所有这些额外的努力都不会阻止递归解析器传回位于DNSSEC中的DNSSEC签名区域！

 

什么？整个问题是，DNSSEC根本无法使用DNSSEC，不是吗？好吧，是的，但是到目前为止，这还不是我们部署它的方式。递归解析器执行DNSSEC验证。与用户坐在那儿的存根解析器不执行DNSSEC验证。相反，如果DNSSEC验证失败，则递归解析器将保留响应。但是，如果递归解析器首先是在撒谎呢？鉴于存根解析器未通过验证，因此它不是更明智的选择，所以谎言是成立的。如果ISP阻止了某些名称，执行NXDOMAIN替换或重定向实际名称，则存根解析器就被藏在谎言中。签署区域的所有努力，以及验证DNS响应的所有努力，但是绝对没有强有力的保护措施来防止被误导吗？TLS似乎只是提供了一种更快，更简单，更强大的解决方案。难怪没有人在服务领域使用DNSSEC。这只是更多痛苦而没有实际收获的情况。

 

DNSSEC是否还有其他用途？只要75％的用户位于未通过验证的DNS解析器系统后面，并且估计有99.9％的用户在任何情况下都不会直接验证DNS响应，那么我们就无法以安全的方式将关键信息放入DNS中，并期望每个人都能受DNSSEC保护。这意味着将关键信息放入DNS并使用DNSSEC保护信息的动机似乎并不十分令人信服。根本没有基于市场的自然动机来部署DNSSEC。这是一个令人沮丧的结论，因为如果其名称系统值得信赖，它对于网络及其俘虏的用户群肯定会更有用。

 

曾经多次说过，DNS的许多问题的核心在于选择DNS的传输协议。将UDP用作首选的主要协议以及TCP的后备功能，意味着要在DNS答案中放置大量信息，同时仍要在速度和鲁棒性参数范围内运行，这是一个挑战。验证是一个非常低效的过程，DNS模型会增加验证的效率，因为DNS模型的责任在于请求信息的客户端，而不是请求信息源的服务器。最终客户端不进行验证，因为每个验证操作都将需要进一步的DNS查询来构造验证链。就用户期望而言，增加的时间惩罚将是不可接受的。

 

令人沮丧的是，我们知道如何使DNSSEC验证更快，并且该方法是预先提供验证答案。我们可以打包DNSSEC验证链构造查询的所有答案，然后将其他信息添加到原始签名的答案（RFC7901）中。但是，在DNS-over-UDP框架中这不太可能实现。如果我们想走类似TLS的道路并将验证链打包到DNSSEC签名的响应中，那么我们不可避免地要考虑基于TCP的DNS（或基于TLS的DNS）。这种信任解决方案的价格非常昂贵，并且为DNS中的信任答复可以提供的收益创造了更高的门槛。如果所有这些都是为了保护用户免受卡明斯基式攻击，那么这还远远不够。

 

2.隐私权

大家都在看DNS。大家 因为Internet由其用户资助，所以用户在Internet上进行的操作对于向用户出售服务的人们来说是至关重要的。由于这些天的所有犯罪活动都是网络犯罪，因此对于那些负责监管此类行为的机构而言，互联网上的犯罪和虐待行为至关重要。由于这些天的互联网主要涉及个人如何选择生活以及与他人互动的方式和原因，因此我们了解到，用户的行为至关重要。您如何找出用户的行为？简单。查看DNS。网上的每笔交易都以DNS查询开始，DNS公开了每项操作。但这比那更糟。DNS毫无用处。DNS过度暴露信息。在DNS的所有方面，

 

我们如何才能使DNS成为不向企业和政府公开用户和用户行为的首选系统？我们如何改善其隐私？

 

多年来，几乎没有动力对这个问题做任何事情。毕竟，如果互联网参与者正忙于建立基于监视资本主义的全球经济，那么进行监视的当事方为什么要使这项任务变得比必要的更加困难呢？改变立场的分水岭是爱德华·斯诺登收集材料的那一刻。政府机构已花费大量资金为互联网提供武器，并将其转变为在全国人口规模上运作的高效监视工具。他们的动机不是太在意您未来的购买，而是在更多地关注您的个人资料。在所有Internet组件中，以明文预打包格式列出所有这些信息的系统是DNS。

 

作为响应，我们一直在改变DNS行为的方面，以尝试阻止最公然的信息泄漏形式。

 

这组增强隐私的响应中的第一个是所谓的查询名称最小化。所做的更改是为了防止DNS名称解析过程成为不受限制的无关信息泄漏。这在很大程度上与递归解析器和权威名称服务器之间的交互有关。递归解析器的任务是找到要询问的正确名称服务器，它从根开始并询问查询。根域服务器的响应会将查询定向到相关委派的顶级域名的名称服务器，并且在解析程序遍历委派层次结构直到解析程序获得答案之前，此过程会重复进行。但是在此过程中，此顺序中的每个名称服务器（从根服务器开始）现在都知道要解析的完整DNS名称。查询名称最小化会修剪这些查询中的名称，以便只有下一个标签才会显示给每个名称服务器。根服务器将仅看到顶级域名查询；顶级域名服务器将仅看到第二级名称查询，依此类推。

 

还需要做一些进一步的工作来了解此发现过程中最可靠的查询类型。根据这种方法的经验，NS查询的最初建议已被A查询所取代。CNAME重写问题以及“空非终端”域同样令人不安的问题以及这种情况下名称服务器的可变行为使该问题更加复杂。现在，这种方法的这种技术被广泛使用。但是，某些实现已在规范中获得了一定许可，并使用了它们自己对该技术的重新解释。某些解析器（显然包括Google的公共解析器服务）仅将查询名称最小化到DNS名称的前三个级别。似乎递归解析器故意从根服务器以及顶级和第二级域名服务中保留完整的查询名称信息，但是很愿意向服务器公开更深区域中的完整查询名称信息。名称层次结构。这种方法是出于保护用户利益的动机，还是出于拒绝信息到位于名称层次结构高层的权威服务器的动机？

 

当然，如果我们认真对待用户隐私，那么就永远不会指定客户端子网扩展名。递归解析器发出的完整查询名称的知识在一定程度上由于无法将此类查询最终与最终用户相关联而得到缓解。但是，如果查询中还加载了最终客户端的IP地址，甚至最终客户端的网络子网，那么所有的隐私保护功能都将被粉碎！虽然将查询名称最小化视为在DNS中提供更高级别的隐藏无关信息的积极步骤，但在查询中使用客户端子网是一个巨大的飞跃！

 

互联网上对隐私注意事项的一般响应是通道加密。Telnet被ssh取代，因为它明确地通过Internet运行会话。同样，出于相同的原因，HTTP已在很大程度上被HTTPS取代。DNS仍然明显地传递查询和响应，这已成为一种过时的做法。它不仅允许窃听，而且还使得能够做出努力来操纵响应，而这一切都损害了用户。

 

但是，要重复先前的观察，DNS的许多问题的核心在于DNS的传输协议的选择。加密通常涉及许多步骤，包括凭证的呈现和验证，以确认客户端正在与他们打算与之交谈的一方通话，还建立会话加密密钥以允许后续数据交换在客户端中进行加密。双方都知道的方式，但其他所有人都不知道。这在UDP中具有挑战性。在UDP上实现TLS的努力，即数据报TLS（DTLS，RFC 6347），具有凭据交换和会话密码建立的开销，因此与查询和响应的单个数据包交换相距很远。DTLS还应避免IP级别碎片，但是它无法避免与此会话建立过程相关的大量有效负载。结果是将碎片推到了应用程序层，并且DTLS需要处理跨多个DTLS数据报扩展的有效负载。看起来，DTLS的额外开销大约等于TCP上的TLS开销，但是还增加了一些与数据包分段有关的脆弱性，这些脆弱性无法在TCP中复制。DTLS如此脆弱的结果意味着，当我们指的是基于TLS的DNS时，实际上是指基于TCP的TLS之上的DNS（DoT）。TLS的这种基于TCP的实现已在存根解析器和递归解析器之间的路径上实现和部署。DTLS需要处理跨越多个DTLS数据报的有效负载。看起来，DTLS的额外开销大约等于TCP上的TLS开销，但是还增加了一些与数据包分段有关的脆弱性，这些脆弱性无法在TCP中复制。DTLS如此脆弱的结果意味着，当我们指的是基于TLS的DNS时，实际上是指基于TCP的TLS之上的DNS（DoT）。TLS的这种基于TCP的实现已在存根解析器和递归解析器之间的路径上实现和部署。DTLS需要处理跨越多个DTLS数据报的有效负载。看起来，DTLS的额外开销大约等于TCP上的TLS开销，但是还增加了一些与数据包分段有关的脆弱性，这些脆弱性无法在TCP中复制。DTLS如此脆弱的结果意味着，当我们指的是基于TLS的DNS时，实际上是指基于TCP的TLS之上的DNS（DoT）。TLS的这种基于TCP的实现已在存根解析器和递归解析器之间的路径上实现和部署。DTLS如此脆弱的结果意味着，当我们指的是基于TLS的DNS时，实际上是指基于TCP的TLS之上的DNS（DoT）。TLS的这种基于TCP的实现已在存根解析器和递归解析器之间的路径上实现和部署。DTLS如此脆弱的结果意味着，当我们指的是基于TLS的DNS时，实际上是指基于TCP的TLS之上的DNS（DoT）。TLS的这种基于TCP的实现已在存根解析器和递归解析器之间的路径上实现和部署。

 

DoT将加密添加到存根到解析器路径，加密不仅对窃听者隐藏查询和响应流，而且DoT防止第三方更改或操纵响应。递归解析器仍然可以对响应撒谎，除非存根解析器正在执行DNSSEC验证（很可能不是！）并且域名已签名（很可能不是！），则任何DNS都来自递归解析器无论从递归解析器到存根解析器的传输通道是否使用TLS，都会被忽略。谎言仍然是谎言，无论用来携带谎言的箱子有多安全。DoT不会消除对DNS信息进行操作的可能性，但会限制可以执行此类操作的实体的数量以及执行操作的位置和方式。

 

通道隐身应该走多远？是否应掩盖另一方的身份？这些是DNS交易的事实是否应该被掩盖？DoT不会掩饰其使用。将TCP端口853用于DoT是可见信号，表明存在有效的DoT连接。使用新的端口号可能会导致许多防火墙配置触发其丢弃过滤器。TCP头也清晰可见远端的IP地址。TLS握手可能会在将来的某个时候使用ECH并加密服务器名称，但是对于DoT，考虑到当今DoT中不会发生基于名称的服务IP地址重载，这可能是一个小问题。而且将来不太可能这样做。

 

DoT会去哪里吗？我认为这不太可能。目前，它要求用户使用其DNS设置，这是广泛使用的巨大障碍。一些用户可能会将其用作跳过一组递归解析器的DNS过滤器（例如由其ISP提供的DNS过滤器）以与另一DNS提供商进行连接的方法，但是公开信号表明这种情况正在发生，这意味着ISP可以如果有这种感觉，请立即阻止。从理论上讲，TCP的使用允许更大的DNS有效负载，并且一线希望是，我们可以使用DNS链接来在使用DoT的最终系统上快速高效地进行DNSSEC验证。但是，还有许多其他前提条件，包括DNS链式响应的服务器配置以及DNS管理大型响应的可靠方法，这意味着它仍然遥不可及，仅此而已。

 

DoT被视为现有DNS基础结构服务的替代，其中DNS是位于通用平台上的服务，并且应用程序使用与往常相同的对平台的DNS解析调用。这是一种确保DNS安全的平台方法。采用可能需要某种形式的自动配置，通常会涉及本地访问服务提供商。鉴于这里的主要威胁威胁参与者是同一个访问ISP，并且ISP在任何情况下都在运行递归解析器，因此了解DoT部署到ISP的增量收益是非常困难的。也许它的好处可能会成为本地网络中其他主机的障碍。许多供应商提供的IP堆栈使本地住宅和企业环境杂乱无章。受损的堆栈位于外部防火墙内部，并且仅受其物理位置信任。DoT将DNS主机的会话切换到受保护的通道，在该通道中，该保护不受本地网络上的其他主机的攻击！

 

HTTPS上的DNS（DoH）使用相同的TCP和TLS基础，但在事务中添加了HTTP上下文。这里有一些有趣的更改。第一个是到TCP端口443的切换。它看起来像任何其他HTTPS通信一样，并且在网络中不太容易识别。其次，DoH服务器不需要使用专用IP地址。像网络本身一样，HTTP协议允许命名服务点。借助带有ECH的TLS 1.3，甚至服务器名称也可以隐藏在加密的信封中。但是还有更多。HTTPS是应用程序级别的协议，该方法允许应用程序绕过平台提供的DNS服务。这意味着不需要基于ISP的平台级配置。该应用程序不仅可以从本地和远程网络隐藏其DNS事务，还可以从平台和其他应用程序隐藏这些相同的事务。如果使用QUIC转到HTTPS / 3，则许多功能将被解锁。不仅传输控制协议隐藏在QUIC中的加密信封后面，而且还可以在单​​个传输通道上同时发出多个DNS请求。

 

我们可以在多大程度上推进DNS的隐私议程？一旦我们部署了QName最小化，丢弃了Explicit Client Subnet，并采用了HTTPS / 3上的DoH作为应用程序到递归解析器协议，并通过链接的DNSSEC响应将DNSSEC验证推送到应用程序，那么可以实现的大部分信任和隐私议程已经实现。到那时，围观者将终端实体身份与DNS请求相关联的许多能力被严重削弱，尽管递归解析器仍然不适合这些用户事务，但是DNSSEC一直到边缘的使用使得解析器的响应操作特别具有挑战性。我们是否应该加密递归解析器和权威服务器之间的路径？假设ECS已被废除，这样的交易几乎没有直接揭示出最终用户的身份。递归解析器服务的客户池越大，每个人的查询可以隐藏的人群就越大。

 

3.其他主题

DNS的技术发展还有许多其他方面，我将把它们全部放在本节中！

 

DNS传统上使用7位ASCII码作为名称。大写和小写是等效的，除了拉丁字符外，DNS标签还可以使用连字符和数字字符。在某些情况下，也可以使用下划线。将DNS扩展为更大的字符库并不是一个成功的案例。设计决定是保留DNS系统的功能，并使用编码将较大的字符集映射到此受限字母中。选择Unicode作为基本字符库并不是一个很好的选择。Unicode是应用程序和打印机之间的合同。Unicode有多种方法可以在打印机上打印相同的字形，这并不重要。打印机不在乎！但是DNS很重要。DNS没有“含义”的概念，以及在屏幕上以相同方式呈现的备用Unicode字符串映射到不同的DNS名称。因此，在DNS中使用Unicode的努力一直是尝试将Unicode标志符号集推回框中并尝试指定最小化显示相似性的Unicode规范子集之一。这是一个棘手的问题，而且由于用于显示同一Unicode代码点的显示字形的变化越来越大，这一问题变得更加棘手。这在表情符号字符中最明显。为什么这是个问题？因为Internet仍在您所见即所得的相当粗糙的模型上运行。如果存在编码同一视觉结果的替代方法，则这些是DNS中的不同标签，并且可以与不同服务点关联。欺骗毫无戒心的用户的可能性当然是此过程的自然而不可避免的结果。在DNS中使用Unicode的努力一直是尝试将Unicode字形集推回框中并尝试指定最小化显示相似性的Unicode规范子集之一。这是一个棘手的问题，而且由于用于显示相同Unicode代码点的显示字形的变化越来越大，这一问题变得更加棘手。这在表情符号字符中最明显。为什么这是个问题？因为Internet仍在您所见即所得的相当粗糙的模型上运行。如果存在编码同一视觉结果的替代方法，则这些是DNS中的不同标签，并且可以与不同服务点关联。欺骗毫无戒心的用户的可能性当然是此过程的自然而不可避免的结果。在DNS中使用Unicode的努力一直是尝试将Unicode字形集推回框中并尝试指定最小化显示相似性的Unicode规范子集之一。这是一个棘手的问题，而且由于用于显示同一Unicode代码点的显示字形的变化越来越大，这一问题变得更加棘手。这在表情符号字符中最明显。为什么这是个问题？因为Internet仍在您所见即所得的相当粗糙的模型上运行。如果存在编码同一视觉结果的替代方法，则这些是DNS中的不同标签，并且可以与不同服务点关联。骗取毫无戒心的用户的可能性当然是此过程的自然而不可避免的结果。这是一个棘手的问题，而且由于用于显示同一Unicode代码点的显示字形的变化越来越大，这一问题变得更加棘手。这在表情符号字符中最明显。为什么这是个问题？因为Internet仍在您所见即所得的相当粗糙的模型上运行。如果存在编码同一视觉结果的替代方法，则这些是DNS中的不同标签，并且可以与不同服务点关联。欺骗毫无戒心的用户的可能性当然是此过程的自然而不可避免的结果。这是一个棘手的问题，而且由于用于显示同一Unicode代码点的显示字形的变化越来越大，这一问题变得更加棘手。这在表情符号字符中最明显。为什么这是个问题？因为Internet仍在您所见即所得的相当粗糙的模型上运行。如果存在编码同一视觉结果的替代方法，则这些是DNS中的不同标签，并且可以与不同服务点关联。骗取毫无戒心的用户的可能性当然是此过程的自然而不可避免的结果。如果存在编码同一视觉结果的替代方法，则这些是DNS中的不同标签，并且可以与不同服务点关联。骗取毫无戒心的用户的可能性当然是此过程的自然而不可避免的结果。如果存在编码同一视觉结果的替代方法，则这些是DNS中的不同标签，并且可以与不同服务点关联。骗取毫无戒心的用户的可能性当然是此过程的自然而不可避免的结果。

 

如今，“ DNS滥用”已成为当前话题，尤其是在ICANN世界中。该短语描述了在DNS供应行业中实现某种程度的自我监管的工作，在这些行业中，行为主要由注册人与注册服务商之间以及注册服务商与普通注册管理人之间的合同条款支配。它允许各种形式的滥用行为，包括犯罪活动，这些行为利用DNS受到合同强制执行（包括DNS名称的删除）的制裁。这很像金融业中常见的自我监管措施，但是没有报告框架，没有任何共同的法律实施框架，也没有对违规行为的惩罚。我的怀疑是，它最终将不会比在金融部门进行自我监管的类似措施更有效，而且可能比银行部门所发表的令人印象深刻的结果更为无效。减少利用DNS和Internet的滥用和犯罪行为的水平不太可能成功。

 

DNS碎片也是名称空间演变中的一个长期主题。单个一致名称空间的压力嵌入在单个网络的概念中。通信系统依赖于引用完整性假设，并且引用完整性通常意味着相同的DNS名称引用相同的资源。从几十年前的备用根系统到如今企业环境中的私有名称空间，我们已经看到了对该概念进行过多次测试。关于碎片的一个很好的例子是使用搜索词代替DNS。搜索引擎的目的是尝试自定义响应，使其与查询器的已知首选项最匹配，当我尝试向您传递有关数字资源的指针时，那么当您在上下文中输入相同的搜索字词时，可能不会暴露我将使用的可显示该资源的搜索字词。但是，DoH还支持其他形式的名称分段。DoH使名称空间可以脱离通用网络基础结构，并放置在应用程序属性的上下文中。该应用程序可以将DoH查询定向到其自己选择的服务器基础结构，并提供与该应用程序有关的响应，这与在公共分布式数据库中的查找不同。HTTPS中将对象推送到应用程序客户端的功能还允许使用所谓的无解析DNS，该应用程序可以通过在需要时提前执行名称解析功能来提高其性能。DoH使名称空间可以脱离通用网络基础结构，并放置在应用程序属性的上下文中。该应用程序可以将DoH查询定向到自己选择的服务器基础结构，并提供与该应用程序有关的响应，这与在公共分布式数据库中的查找不同。HTTPS中将对象推送到应用程序客户端的功能还允许使用所谓的无解析DNS，该应用程序可以通过在需要时提前执行名称解析功能来提高其性能。DoH使名称空间可以脱离通用网络基础结构，并放置在应用程序属性的上下文中。该应用程序可以将DoH查询定向到自己选择的服务器基础结构，并提供与该应用程序有关的响应，这与在公共分布式数据库中的查找不同。HTTPS中将对象推送到应用程序客户端的功能还允许使用所谓的无解析DNS，该应用程序可以通过在需要时提前执行名称解析功能来提高其性能。该应用程序可以将DoH查询定向到自己选择的服务器基础结构，并提供与该应用程序有关的响应，这与在公共分布式数据库中的查找不同。HTTPS中将对象推送到应用程序客户端的功能还允许使用所谓的无解析DNS，该应用程序可以通过在需要时提前执行名称解析功能来提高其性能。该应用程序可以将DoH查询定向到自己选择的服务器基础结构，并提供与该应用程序有关的响应，这与在公共分布式数据库中的查找不同。HTTPS中将对象推送到应用程序客户端的功能还允许使用所谓的无解析DNS，该应用程序可以通过在需要时提前执行名称解析功能来提高其性能。

 

DNS“名称变平”一直是DNS面临的持续压力。没有人希望将其关键服务名称隐藏在其他名称下的dns中。这样的名称不仅需要花费更长的时间来解析，而且还以相同的方式增加了依赖性集，因为在名称层次结构中可能一直存在着更多的服务提供商的想法。DNS用户想要短名称。越短越好。结果是，名称空间处于不断缩小的压力之下。最终降落的位置是DNS的顶级区域，即根区域。随着顶级域名的价格溢价下降，以更大数量的条目扩大该区域的压力是不可避免的结果。

 

但是，进化压力的力量也许更根本，并且与互联网本身的进化力量平行。硅产业的确是惊人的，这个世界上的处理器比人多得多。尽管我们已经使用自然语言术语的类似物来构造DNS名称空间，以便利人类使用，但这已不再是DNS的主要使用模式。如今，DNS的一种观点是通用的信令和隧道协议，并且将DNS用作僵尸部队的命令和控制通道证明了这种DNS的有效性！随着此类设备数量的增加，使用DNS作为命令和控制机制的重要性可能会增加，并且人类使用也越来越边缘化。人工DNS很可能成为深奥的奢侈品业务。在从人为使用到高度自动化的使用的转变中，DNS名称管理的紧密联系是不可持续的，并且填充此空间的商业模型和机构将需要调整为提供名称而不是作为品牌属性但没有区别的名称业务。商品活动。就像我们将IP地址从端点标识符转换为临时会话令牌一样，我们很可能会将DNS视为高度分布式自动化系统的命令和控制的代码库，这与我们在分布式数据库查找中相去甚远最初是为DNS的人类使用模型构建的。当我们将DNS查询视为指向DNS服务器的一组指令并将DNS服务器视为分布式处理环境时，然后DNS从分布式数据库更改为分布式计算和信令环境。这样的DNS中的标签组成不再从已知单词的字典中大致得出。相反，它们是标签有效的编码指令，是名称解析程序要执行的程序。正如我们所知道的，对于DNS来说无疑是一个不同的未来，但是其将来可能的商品化与Internet的运输，交换和内容的困境是一致的！从这个角度来看，DNS的发展与Internet本身的更大发展并驾齐驱，后者的基础架构不再是人类可用的框架。相反，它专注于提供高度自动化的环境，其中元素本身就是程序和自动机。这样的DNS中的标签组成不再从已知单词的字典中大致得出。相反，它们是有效标签的编码指令，是名称解析器要执行的程序。正如我们所知道的，对于DNS来说无疑是一个不同的未来，但是其将来可能的商品化与Internet的运输，交换和内容的困境是一致的！从这个角度看，DNS的发展与Internet本身的更大发展并驾齐驱，后者的基础架构不再是人类可用的框架。相反，它专注于提供高度自动化的环境，其中元素本身就是程序和自动机。这样的DNS中的标签组成不再从已知单词的字典中大致得出。相反，它们是有效标签的编码指令，是名称解析器要执行的程序。正如我们所知，对于DNS来说，无疑是一个不同的未来，但是其将来可能的商品化与Internet上传输，交换和内容的困境是一致的！从这个角度看，DNS的发展与Internet本身的更大发展并驾齐驱，后者的基础架构不再是人类可用的框架。相反，它专注于提供高度自动化的环境，其中元素本身就是程序和自动机。一个用于名称解析程序执行的程序。正如我们所知，对于DNS来说，无疑是一个不同的未来，但是其将来可能的商品化与Internet上传输，交换和内容的困境是一致的！从这个角度来看，DNS的发展与Internet本身的更大发展并驾齐驱，后者的基础架构不再是人类可用的框架。相反，它专注于提供高度自动化的环境，其中元素本身就是程序和自动机。要执行名称解析器的程序。正如我们所知，对于DNS来说，无疑是一个不同的未来，但是其将来可能的商品化与Internet上传输，交换和内容的困境是一致的！从这个角度来看，DNS的发展与Internet本身的更大发展并驾齐驱，后者的基础架构不再是人类可用的框架。相反，它专注于提供高度自动化的环境，其中元素本身就是程序和自动机。基础设施不再是人类可用的框架。相反，它专注于提供高度自动化的环境，其中元素本身就是程序和自动机。基础设施不再是人类可用的框架。相反，它专注于提供高度自动化的环境，其中元素本身就是程序和自动机。

 

这并不意味着人类对DNS的使用将消失。众所周知，DNS最终可能会变成一小组高端奢侈品精品活动，这些活动以管理持久名称的自定义程序的奢华为特征。同时，其余的DNS进入商品实用程序世界，其中包含大量算法生成的瞬态名称，这些瞬态名称将完全自动进行管理并量身定制，以供其他进程一次性使用。可能明天的DNS的大量使用与人名无关，而将集中于提供一个很大程度上自动化的框架，该框架利用DNS来支持通用的命令和控制信令框架。临时名称与持久名称一样好，甚至更好。注册和归属过程基本上无关紧要。DNS可能仍然很有价值，但是个人名称将完全毫无价值！