我正在参与「启航计划」

导言

作为客户端开发者，DNS的相关的范畴常识，一般都不太重视，可是跟着你App用户增长的必定量级，而你又是那个cover整个App的人，你就必定会开端留意它，它自身的安全性问题常常会引发一些问题。

别的，作为客户端开发者，从你发起恳求那一刻到页面烘托出来所经历的进程，你最好都清楚掌握。

什么是DNS

DNS 即域名体系，全称是 Domain Name System。当咱们访问一个 URL 地址时，浏览器要向这个 URL 的主机名对应的服务器发送恳求，就得知道服务器的 IP，关于浏览器来说，DNS 的效果便是将主机名转换成 IP 地址。也便是，DNS 是一个应用层协议，运用的是53端口，咱们发送一个恳求，其中包括咱们要查询的主机名，它就会给咱们回来这个主机名对应的 IP。

其次，DNS 是一个分布式数据库，整个 DNS 体系由涣散在世界各地的许多台 DNS 服务器组成，每台 DNS 服务器上都保存了一些数据，这些数据能够让咱们终究查到主机名对应的 IP。

所以 DNS 的查询进程，说白了，便是去向这些 DNS 服务器问询，你知道这个主机名的 IP 是多少吗，不知道？那你知道去哪台 DNS 服务器上能够查到吗？直到查到我想要的 IP 为止。

DNS的层次结构

DNS 服务器有 3 种类型：根 DNS 服务器、尖端域（Top-Level Domain, TLD）DNS 服务器和威望 DNS 服务器。它们的层次结构咱们能够看一张session中的图

WWDC22 - DNS安全：DNSSEC

  • 根DNS服务器

    • 以www.baidu.com为例，它的完好写法应该：www.baidu.com``.，终究的 . 便是根域名。根DNS服务器的效果便是办理它的下一级—–尖端域DNS服务器。
    • 经过问询跟DNS服务器，咱们能够知道一个主机名对应的尖端域DNS服务器的IP是多少，然后持续向尖端域DNS服务器发起查询恳求。

  • 尖端域DNS服务器

    • 除了上面提到的www.baidu.com中的 com 是尖端域名，常见的尖端域名还有 cn、org、edu 等。尖端域 DNS 服务器，也便是 TLD，提供了它的下一级，也便是威望 DNS 服务器的 IP 地址。

  • 威望DNS服务器

    • 威望 DNS 服务器回来主机 – IP 的终究映射

还有另一类重要的DNS服务器，称为本地DNS服务器(local DNS server)。严格说来，一个本地DNS服务器并不属于该DNS的层次结构，但它对DNS层次结构是至关重要的。本地DNS服务器通常与主机相隔不超越几台路由器。当主机发岀 DNS恳求时，该恳求被发往本地DNS服务器，它起着署理的效果，并将该恳求转发到DNS服务器层次结构中，下面的流程图，完好展示了DNS服务器解析IP的全进程，如下图所示：

WWDC22 - DNS安全：DNSSEC

DNS安全问题

互联网协议，如 TCP 、TLS 和 QUIC ，依赖于 IP 地址，因而一切都是从 DNS 开端。今天 TLS 被广泛用于维护互联网通讯安全，但作为基础层的 DNS 存在一些安全问题。DNS 有史以来并不安全，它是在 1983 年设计的，当时几乎没有什么安全考虑，从那以后的几年里，现已产生了许多 DNS 进犯。

WWDC22 - DNS安全：DNSSEC

DNS 缓存中毒

进犯者运用 DNS 解析的缺点，使他们缓存不正确的 IP 地址，导致客户端衔接到恶意主机。这揭示了 DNS 的一个漏洞：它没有身份验证。如今传统的 DNS 客户端无法验证应对者，因而很容易被诈骗。

主要的操作进程有：

  1. 进犯机器向 DNS 转发器发送大量查询报文

  2. DNS 转发器向 DNS 域名服务器解析查询域名

  3. 进犯机器伪装成 DNS 域名解析服务器，向转发器回复假造的呼应报文，并完成投毒

WWDC22 - DNS安全：DNSSEC

DNS嗅探

网络流量是透明的，默许状况下 DNS 的报文是没有加密的，因而在传输的进程中，进犯者能够监听客户端和 DNS 解析服务器之间的 DNS 流量，收集客户端的历史记载。关于用户隐私来说，这是一个严峻的问题。而让这种进犯成为或许的原因是 DNS 流量开端是未加密的。

为了成为安全起点，在此之上构建其他的协议，DNS 需求经过身份验证和加密。

  • 当咱们运用 DNSSEC 对 DNS 呼应进行签名时，它提供了身份验证

  • 当我运用 TLS 和 HTTPS 加密 DNS 解析成果时，它能够确保隐私

TLS咱们在后面一篇共享中再着重讲，接下来咱们先看DNSSEC。

DNSSEC

DNSSEC是DNS安全扩展，主要思维是经过在DNS记载中增加加密签名，然后为DNS解析流程提供来源可认证和数据完好性的保证。

iOS16 和 macOS Ventura 现在支撑客户端 DNSSEC 验证。DNSSEC 经过在呼应中附加签名来维护数据完好性。假如呼应被进犯者篡改了，那么篡改后的数据签名将与原始数据不匹配。这种状况下，客户端能够检测到呼应现已被篡改然后将其丢弃。

DNSSEC 还经过运用特殊类型的 DNS 记载（例如 NSEC 记载）来断言区域中记载是否存在。NSEC 记载按字母次序安全地告诉您下一个记载称号是什么。只要它列出的称号才是存在的，任何未列出的称号都是不存在的。

WWDC22 - DNS安全：DNSSEC

例如，现在这里有三个 NSEC 记载。记载调集中显示区域 org 只要三个记载称号，A.org、C.org 和 E.org。假如有进犯者说 A.org 不存在，客户端能够检测到这种进犯。确认 A.org 的确存在，由于它列在第一个 NSEC 记载中。相同的，假如进犯者说 D.org 存在，客户端也能够检测到，由于根据第二个 NSEC 记载，D.org 位于 C.org 和 E.org 之间，可是这两个称号之间并不存在 D.org。

WWDC22 - DNS安全：DNSSEC

DNSSEC 经过树立信赖链来验证记载，举个比如：设备想要解析 www.example.org 并启用 DNSSEC 验证，进程如下：

  1. 发送问询 IP 地址、签名和密钥的查询，经过呼应能够树立从 IP 地址到密钥 1 的信赖联系

  2. 客户端向父区域 org 发送查询，问询可用于验证密钥 1 的记载，树立从密钥 1 到密钥 2 的信赖联系

  3. 设备递归地重复这个进程，直到它抵达根域

WWDC22 - DNS安全：DNSSEC

现在假如根密钥（图中的密钥 3 ）能够信赖，则能够验证从 IP 地址到密钥 3 的信赖联系。根密钥的哈希值一直安全地存储在设备中。在 DNSSEC 中，它被称为根信赖锚。假如密钥 3 的哈希值与预先装置的锚匹配，则能够安全地树立信赖链。经过信赖链，www.example.org 的 IP 地址现在现已经过了身份验证。

支撑 DNSSEC

假如你想在你的应用程序中要求 DNSSEC 验证，那么你需求如下操作：

  • 域名支撑 IPV6

  • 对域名进行签名

  • 选用相应架构的 APIs

在只要 IPV6 的环境中，IPV4 地址被转换为组成 IPV6 地址。假如域名被签名，组成地址无法经过 DNSSEC 验证； 启用 DNSSEC 后，它们无法访问。因而，请确保域支撑 IPv6。

确保你的 DNS 服务提供商运用 DNSSEC 对你的域名进行签名。假如你在您的应用程序中启用了 DNSSEC 可是没有对你的域名进行签名，为了测验对没有签名的域名进行身份验证，DNS解析时间会增加。

获得相应的基础架构支撑后，以下是为你的应用选用 DNSSEC 所需求的代码。

 //  Require DNSSEC validation in your URL request at session level.
let configuration = URLSessionConfiguration.default
configuration.requiresDNSSECValidation = true
let session = URLSession(configuration: configuration)

假如你是 URLSession 客户端，你能够要求对你的 URL 恳求进行 DNSSEC 验证。举个比如：

var request = URLRequest(url: URL(string: "https://www.xxx.com")!)
request.requiresDNSSECValidation = true
let (data, response) = try await URLSession.shared.data(for: request)

先创立一个默许会话装备，设置需求 DNSSEC 验证。接下来将运用修改后的装备来创立会话。它会为从此会话创立的所有 URL 恳求启用 DNSSEC。假如你不想在整个会话启用 DNSSEC，你也能够在恳求级别执行此操作。

假如你是 Network.framework 客户端，你还能够要求对衔接进行 DNSSEC 验证。创立参数目标时，需求进行 DNSSEC 验证，然后运用参数目标创立 NWConnection

 //  Require DNSSEC validation in your network request.
let parameters = NWParameters.tls
parameters.requiresDNSSECValidation = true
let connection = NWConnection(host: "www.example.org", port: .https, using: parameters)

当你开端衔接时，只要在 DNSSEC 验证完成而且与经过验证的 IP 地址树立衔接时，它才会进入安排妥当状态。启用 DNSSEC 后，将仅运用经过验证的地址来树立衔接。

在 DNSSEC 中，验证失利不会回来任何错误。收到验证失利的呼应等于没有收到任何呼应。

假如存在篡改呼应的 DNS 提供者，地址将无法经过身份验证检查，因而将直接丢弃。当设备参加 DNS 提供商未篡改呼应的新网络时，验证将再次进行，解析将主动恢复正常。

以下是一些或许导致 DNSSEC 失利的状况。

  • 当原始 DNS 呼应被修改了，不匹配的签名将无法经过 DNSSEC 检查，然后导致验证失利

  • 当设备无法访问任何预装置的信赖锚而且无法与其树立信赖链时

  • 网络不支撑 DNSSEC 所需的必要协议，例如 DNS over TCP 和 EDNS0 选项

  • 当签名的域名不支撑 IPv6 时，由互联网服务提供商提供的组成 IPv6 地址将无法经过验证

这便是运用 DNSSEC 对 DNS 呼应进行身份验证的方法，但假如它们仍未加密，网络上的任何人都能够看到它们。

DDR 对 DNS 加密

iOS 14引入了加密 DNS 以协助维护隐私。能够运用应用程序中的 NEDNSSettingsManager 或装备文件中的 DNSSettings 手动装备加密的 DNS 体系规模。还能够运用 NWParameters 上的 PrivacyContext 为您的应用程序挑选加密 DNS。在 iOS 16 中新增了能够主动运用加密的 DNS的新功用。

假如您的网络支撑发现指定解析器（也称为 DDR ），则 DNS 查询将主动运用 TLS 或 HTTPS。要运用加密的 DNS，您的设备需求知道解析器支撑 TLS 或 HTTPS，而且或许还需求学习端口或 URL 途径。比如 DHCP 或路由器播发等常见机制仅提供普通 IP 地址。DDR 是 Apple 与其他职业合作伙伴在 IETF 中开发的一种新协议。

它为 DNS 客户端提供了一种经过运用特殊 DNS 查询来了解这些必要信息的方法。当你的设备参加新网络时，它将发出“_dns.resolver.arpa”的服务绑定查询。假如 DNS 服务器支撑 DDR，它会回复一个或多个装备。然后，设备运用此信息树立与指定解析器的加密衔接。它验证未加密解析器的 IP 地址是否包括在指定解析器的 TLS 证书中。这样做是为了确保未加密的解析器和加密的解析器属于同一实体。

WWDC22 - DNS安全：DNSSEC

假如一切正常，设备现在默许运用加密的 DNS。DDR 一次适用于单个网络。只要在当前网络支撑时，你的设备才会主动运用加密的 DNS。相同重要的是要留意，假如 DNS 服务器的 IP 地址是私有 IP 地址，则 DDR 不起效果。这是由于 TLS 证书中不允许此类 IP 地址，由于它们的所有权无法验证。

在 iOS 16还支撑在运用加密 DNS 进行装备设置时运用 NEDNSSettingsManager 或 DNSSettings 装备文件，指定客户端身份验证的功用。

WWDC22 - DNS安全：DNSSEC

现在能够运用 NEDNSSettings 的 identityReference 属性装备客户端证书。就像 VPN 的客户端证书相同。这些能够应用于 DNS over TLS 和 DNS over HTTPS。这是维护 DNS 的途径。

写到终究

我在招聘面试的时候，问一些好像非客户端的常识问题时，偶然会遇到以下的反诘：

  • 作为一个客户端开发，或者说前端开发，咱们为什么要去了解这些内容呢？

  • 这些内容好像在咱们的工作中不曾遇到，咱们了解不了解，清楚不清楚又有什么联系呢？

当然还有一些没反诘的，或许仅仅是缺了反诘的勇气，心里的主意仍是相同的。关于这类问题，我不好断定他们主意对不对。

在我看来，许多常识点看起来好像在咱们日常工作中用不到，可是能协助咱们从一个更微观更大局的角度去了解咱们面对的需求或者说工程项目。

跳出单个事务，跳出单个团队看问题，其实是非常重要的，而这些才能素质，其实便是在更加全面的常识堆集中萌发出来的。

参考文献

  • Enable encrypted DNS

  • developer.apple.com/videos/play…

  • blog.csdn.net/bangshao198…

  • blogs.cisco.com/networking/…

  • xiaozhuanlan.com/topic/48025…