我无法理解 DNS 服务及其底层结构的某个特定部分。最好通过展示恶意 ISP（互联网服务提供商）可能引发的特定问题来描述它。
假设我的 ISP 修改了它向用户提供的 DNS 记录的 SOA。如果我无法访问其他 DNS 服务器，我该如何验证 SOA 的正确性。
我目前对这些流程的了解：
- 当我向注册商注册 DNS 时，我会输入负责域名的 DNS 服务器，该服务器定义了权威 DNS 服务器。这定义了域名查找的 SOA 条目。
- 这是我遗漏了一些信息的地方。注册商的信息（soa、权威 DNS 服务器 IP 等）是如何推送到 DNS 服务系统的。或者客户端如何检查域的 SOA 真实性？
- 一旦通过 dns 结构在 DNS 服务器内部定义了 DNS 服务器的权威，权威服务器就可以返回某个域的 dns 条目。
我希望我的问题尽可能容易理解。如果可能的话，请参考专门针对此主题的 RFC，并总结其背后的逻辑。
谢谢
答案1
当我向注册商注册 DNS 时，我会输入负责域名的 DNS 服务器，该服务器定义了权威 DNS 服务器。这定义了域名查找的 SOA 条目。这是我缺少一些信息的地方。注册商的信息（soa、权威 DNS 服务器 ip 等）是如何推送到 DNS 服务系统的。或者客户端如何检查域的 SOA 真实性？
这并不是它的工作原理，或者可能只是术语问题。（你可以看看RFC 8499“DNS 术语”了解详细信息）
要解析任何域名，它都需要具有权威的名称服务器，并且这些名称服务器需要在 NS 记录中的父区域中列出。
因此，如果您有，example.com您可以决定ns1.example.net并ns2.example.net为其配置权威名称服务器。这还不够。要使解析工作，两个名称服务器都必须列在父区域中，即此处.COM。
所有这些都是基本的 DNS 委派机制，因此这由 DNS 上的规范 RFC（RFC 1034 和 1035）涵盖。但请注意，它们已经很旧了，其中的许多内容不再适用（当然，其中未描述的许多新内容现在适用），并且其中的一些术语（例如域名）的含义与我们今天的含义不同。
父区域的变化是如何发生的？您前往注册商example.com并向其提供名称服务器。然后，注册商将通过特定的非公开协议（通常是 EPP）将它们提交给注册中心，经过“一段时间”后，该区域的注册中心权威名称服务器将拥有列出您的名称服务器的域的 NS 记录。
EPP 是性病 69但是，通过阅读这些 RFC，您不会获得任何有用的高级理解，因为它们详细解释了协议，而您永远不会看到它，因为它只存在于注册中心和注册商之间。
如您所见，上面没有提到SOA。SOA 记录位于您的区域内，而不是区域外，如果您区域上的任一权威名称服务器提出请求或进行相关查询，该记录将返回。
还要注意，域名注册商和 DNS 提供商是两个完全独立的工作。您可以选择 DNS 提供商来管理您的权威名称服务器，也可以选择注册商来注册域名，然后不时更新与其关联的名称服务器。当然，一家公司可以同时做这两项工作，但从技术上讲，他们各自都在做与另一项工作无关的具体工作。
至于记录的认证，确保它们在传输过程中不会被篡改，正如 Nikita Kipriyanov 已经回答的那样，这是 DNSSEC 的工作。有多个 RFC 涵盖 DNSSEC，掌握这项技术并不容易，您首先需要对 DNS 有扎实的了解，包括通配符和 CNAME 等暗角，然后对加密有基本的了解。我建议先阅读 Wikipedia 中的介绍，而不是 RFC，这足以让人胃口大开：https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
非常广泛地总结一下，使用 DNSSEC，所有记录（不仅仅是SOA区域中的所有记录）也将具有新的关联RRSIG记录，该记录包含使用某些密钥对内容（DNS 记录）计算的签名；如果路径上的某个人更改了部分内容，则签名将不再匹配（并且显然，他无法动态重新计算签名以使其再次匹配）。
对于您提到的特定用例（恶意 ISP 既可以监听您的所有 DNS 查询（进行分析），也可以过滤您的查询并修改响应），有些人（包括一些浏览器供应商）会试图说服您，DNS over HTTPS（也存在 DNS over TLS）可以解决所有问题，这是错误的，至少它不提供与 DNSSEC 相同的服务。但是使用 DNS over HTTPS 的想法（通常 DNS 在 TCP 和 UDP 中通过端口 53，因此所有流量都是纯文本；DNSSEC 增加了完整性和身份验证但没有增加机密性，整个流量仍然是明文的）是，通过使用 HTTPS（它本身就是通过 TLS），您可以获得机密性，因为 TLS 将加密所有交换，即您的 DNS 查询和 DNS 响应。
这种谬论的倡导者未能充分评估问题，即您确实获得了所有 DNS 交换的隐私（以及相关的事实，即响应无法修改；它们仍然可以被过滤），但仅限于您和您通过 DoH（DNS over HTTPS 的昵称）查询的递归 DNS 服务器之间。该特定 DNS 解析器显然可以看到您的查询和答案，因为它是为您处理查询和答案的人，因此它可以完全为您提供它想要的东西，而无需任何真实性证明……如果不使用 DNSSEC。
答案2
SOA 只是另一种 DNS 资源记录。当然，它具有特殊功能，但一般适用于 DNS RR 的规则仍然适用于 SOA。可以像往常一样请求它（如下所示：）host -vt soa example.com。
该记录由某些权威 DNS 服务器的名称、管理电子邮件地址（以“域名”形式，其中 @ 用点代替）和一串数字组成，这些数字定义了区域序列号（旨在只增加而不减少）和计时器，其中否定答复生命周期非常重要，因为它定义了远程缓存可以存储“NXDOMAIN”答复的时间长度。
在原始的“传统”DNS中，没有机制可以实时检查DNS RR篡改。事实上，ISP可以这样做，而且不会被察觉。
现代 DNS 中确实存在一种应对这种情况的措施。它被称为 DNSSEC。本质上，这是一组特殊的 DNS RR，带有数字密钥和数字签名，用于验证相应的数据 RR，以及以 DNS 根 (.) 开头的整个信任链，其密钥存储在任何支持 DNSSEC 的解析器中。这些密钥验证负责 TLD 的服务器，每个 TLD 验证二级域的服务器，依此类推，直到验证特定记录的终端服务器。根据此信任链，此解析器可以检测到任何恶意篡改。这包括验证某些记录不存在的能力。此外，没有人可以否认域使用 DNSSEC 的事实，因为此信息由其父级 DNS 签名。例如，.com 区域是经过签名的，因此如果您向注册商提供所需的 DNSSEC 数据，并且他们将其发布在 .com 区域中，那么没有人可以错误地声称您没有为您的域名使用 DNSSEC，因为该声明无法通过 .com 区域签名进行验证，并且如果他们试图声称 .com 未签名，那么也无法通过存储在解析器本身上的密钥进行验证。
一般情况下，这些签名即使在 DNS 缓存服务器提供服务时仍然有效，因此不会阻止缓存。它们仅验证所呈现的记录是由权威服务器生成的，并且该记录未经修改而准确呈现。
但是，恶意 ISP 仍然可以拒绝为这种“过于智能”的解析器提供服务。如果解析器检测到篡改，它唯一能做的就是返回错误，从而导致拒绝服务。然后，ISP 可能会篡改每个 DNS 数据包，这样 DNS 在启用 DNSSEC 检查的情况下实际上就无法工作，从而促使用户禁用该功能，恢复到普通的不安全 DNS。他们可能会编造各种看似好的理由来为这种行为辩解。然后，在说服用户 DNSSEC 不好之后，这个 ISP 就可以做任何事情了。