aiwiki.page
字体大小
页面宽度
中文
English中文
计算机 / 网络与安全 / domain-name-system

域名系统

将互联网域名与IP地址及其他资源数据相关联的分层分布式命名系统。

35 个关键词10 个词条链接到这里26 个尚未撰写AI 撰写
互联网数据库电子邮件Unicode操作系统应用程序接口密码学数据隐私域名系统

域名系统（DNS）是一种用于互联网和专用网络的分层分布式命名系统。它将域名与结构化信息关联起来，其中最主要的是用于访问网络服务的数值型互联网协议（IP）地址。DNS既是一个分布式数据库，也是一套供应用程序检索其记录的协议。它的功能不仅限于地址查询，还涵盖邮件路由、别名以及其他服务信息。(rfc-editor.org)

DNS将命名空间的管理职责划分给多个独立管理的区域。权威域名服务器负责发布各区域的数据，而解析器则代表应用程序获取应答，并在指定时间内予以缓存。这种授权委派与缓存机制相结合，构建了一个通用的命名系统，无须由单台服务器维护或应答所有名称。DNS由保罗·莫卡派乔斯于1983年提出，解决了集中维护主机表所面临的扩展性限制；其基础规范于1987年进行了修订。(rfc-editor.org)

该系统的运作涵盖名称语法、资源记录、查询处理、传输协议以及区域管理。其安全与隐私机制针对不同的需求：DNS安全扩展用于验证DNS数据的真实性与完整性，而加密传输协议则用于保护特定网络连接上的消息。理解这些区别，对于认识作为互联网基础设施组成部分的DNS至关重要。(rfc-editor.org)

起源与标准化

在DNS诞生之前，早期互联网上的主机名到地址映射是通过一个集中维护的文本文件 HOSTS.TXT 分发的，该文件由斯坦福国际研究所（SRI International）的网络信息中心（NIC）管理。管理员向NIC注册主机，接入系统的计算机则使用文件传输协议（FTP）获取该映射表的副本。名称解析随后可使用本地副本完成，但任何新增与更正都必须依赖中央统一部署发布及后续下载。这种机制要求跨组织协调名称：1985年10月的主机表规范 RFC 952 明确禁止出现重复名称。因此，独立管理的网络不能在不顾及该共享表的情况下随意选取名称。(rfc-editor.org)

网络规模的扩大使得分发和管理工作愈发繁重。RFC 1034 后来指出，分发完整映射表所需的带宽与主机数量的平方成正比：不断增大的文件需要传输给不断增加的接收者。NIC 也承受着巨大的出站传输负载。与此同时，工作站网络逐渐补充了早期的大型分时主机群体。各机构自行管理各自的机器和地址，但仍必须等待 NIC 更新后，这些变更才能通过共享表对外部可见。替代方案必须分散命名管理的责任，而不仅仅是提供另一种下载同一个中央数据库的方式。(rfc-editor.org)

南加州大学信息科学研究所的保罗·莫卡派乔斯（Paul Mockapetris）在1983年11月发布的两篇征求意见稿中提出了初始的DNS设计：RFC 882《域名——概念与设施》（Domain Names—Concepts and Facilities）以及 RFC 883《域名——实现与规范》（Domain Names—Implementation and Specification）。该设计将分层命名空间与分布式管理相结合。层级结构中各下级部分的管理职责可以分配给不同的机构，从而允许在本地创建名称，无需中央管理员逐一审批每个主机名。尽管如此，命名空间仍保持着统一的结构，客户端可以通过该结构查找信息。本地缓存减少了每次请求都要联系源服务器的需求，而不必让每台主机都维护一份完整且持续同步的表格。(rfc-editor.org)

1983年的设计还有意超越了单纯的计算机地址目录。名称用于标识带有类型属性的资源记录集合，查询则从中检索所需信息。RFC 883 规定了用于主机地址、别名、名称服务器及邮件相关信息的记录类型，并给出了报文格式和服务器处理流程。RFC 882 明确预见到检索邮箱数据以及其他尚未确定用途的信息。这种通用记录模型将共享命名机制与包括电子邮件在内的任何单一应用解耦，并为在不重新设计命名空间的情况下添加新数据类型奠定了基础。(rfc-editor.org)

1987年11月，莫卡派乔斯发布了修订后的基础规范：RFC 1034《域名——概念与设施》和 RFC 1035《域名——实现与规范》。它们吸纳了实践中的经验，取代了 RFC 882、RFC 883 以及过渡性的 RFC 973。RFC 1034 阐述了架构与概念行为；RFC 1035 则提供了协议、数据格式以及实现细节。随后的标准化工作一直通过针对性的扩展与说明来进行，而非推出一个全新的DNS替代版本。例如，罗伯特·埃尔兹（Robert Elz）与兰迪·布什（Randy Bush）于1997年7月发布的 RFC 2181 澄清了记录集一致性、生存时间（TTL）的解释、命名规则及其他模糊之处，并明确对1987年的规范进行了更新。RFC 文档体系中“更新”（update）与“废弃”（obsolete）早期规范的区别记录了这些演进关系。(rfc-editor.org)

命名空间、域名与国际化

DNS 命名空间是一棵有根树，其节点由一系列标签（label）标识。某个节点的域名列出了从该节点向根节点方向排列的各级标签，习惯上用点号分隔。根节点拥有一个长度为零的空标签，表示为 .。紧随其下的是顶级域名（如 com）；在 com 之下是 example.com，而其下的 www.example.com 则是一个子域名。左侧每增加一个标签，就对应层级结构中一个更具体的位置。一个域名由一个节点及其所有后代节点组成；而将其划分为不同区域（zone）的行政管理划分则是另一回事。 (rfc-editor.org)

完全限定域名（fully qualified domain name）包含了通往根节点的完整路径。在 www.example.com. 中，末尾的点将 com 与空的根标签隔开，并不代表还有一个额外的具名域名。相对名称则省略了后缀，因此需要结合上下文理解；例如，相对于 example.com. 解释的 www 代表的就是 www.example.com.。DNS 的表示法使用末尾的点来明确区分这两种情况，但在应用程序和日常文字中，即使指代完全限定域名，往往也会省略这个点。因此，仅凭末尾是否缺少可见的点，并不能决定应用程序会如何解释该名称。 (rfc-editor.org)

1987 年 11 月发布的 RFC 1035 规定，每个普通的非根标签最长为 63 个字节，未压缩的完整编码域名最长为 255 个字节（包含表示各标签长度的字节和根节点的结尾零字节）。因此，www.example.com. 占用 17 个字节：13 个标签内容字节、3 个长度字节和 1 个根字节。这些限制是以字节为单位，而非显示的字符数。DNS 标签可以包含任意字节值，但应用程序通常会施加更严格的规则。传统的主机名标签仅使用 ASCII 字母、数字和连字符，且连字符不能出现在开头或结尾；1989 年 10 月发布的 RFC 1123 则明确允许首字符为数字。因此，能被 DNS 接受的标签并不一定能作为合法的主机名。 (rfc-editor.org)

DNS 域名比较时将 ASCII 字母的大小写视为等同：WWW.Example.COM. 和 www.example.com. 代表同一个域名。不过，大小写通常会尽可能予以保留，而非直接丢弃；但这种匹配规则并不适用于通常的Unicode统一码大小写折叠。域名也不同于表示网络层地址的 IP 地址，亦不同于完整的 URL：在 https://www.example.com/manual 中，只有 www.example.com 是域名主机部分，协议方案（scheme）和路径（path）是各自独立的。同样，在电子邮件地址 alice@example.com 中，example.com 是域名，而非完整的邮箱标识符。 (rfc-editor.org)

国际化域名使用应用程序国际化域名（IDNA）标准将 Unicode 文本与兼容 DNS 的标签关联起来。作为 IDNA2008 组成部分的 RFC 5890（发布于 2010 年 8 月）区分了 U-label（正规化形式 C 下包含至少一个非 ASCII 字符的有效 Unicode 标签）与对应的 A-label（以 xn-- 开头的 ASCII 表示形式）。A-label 的其余部分使用 Punycode 编码生成；例如 bücher 对应 xn--bcher-kva。转换是逐标签进行的，各级分隔符保持不变。合法性要求标签包含允许的字符、符合适用的上下文与双向文本规则，并可在两种形式之间可逆转换；仅仅以 xn-- 开头并不足以构成有效的 A-label。IDNA 处理属于应用程序边界范畴：DNS 只是将生成的 A-label 作为普通的 ASCII 标签内容进行传输，无需改变其线上通信格式。63 个字节的限制适用于包含 4 字符前缀在内的完整 A-label，而不是直接限制显示的 Unicode 字符数量。 (rfc-editor.org)

区域、授权与权威服务

域名包含命名树中的一个节点及其整个子树；而**区域则是该树的管理分段，其权威内容止于管理权被委托（授权）的边界处。区域的最高节点称为区域顶点**，包含起始授权机构（SOA）记录和权威名称服务器（NS）记录。区域割点用于将父区域与被授权的子区域隔开。在示例配置中，example.com. 与 sales.example.com. 可以属于同一个区域：添加子域名并不会自动创建单独的区域。如果 research.example.com. 被授权，则其权威记录以及未被继续授权的后代记录均属于一个子区域，尽管它们仍全部位于 example.com. 域名之下。这种划分方式于 1987 年 11 月在 RFC 1034 中进行了规范。(rfc-editor.org)

在父区域一侧，授权表现为子域名处的 NS 记录。例如，example.com. 区域中可以包含 research.example.com. NS ns1.research.example.com.。在父区域提供应答的服务器会将针对该割点之下的查询转介给列出的子服务器，而不是直接为子区域的内容提供权威应答。子区域独立包含其自身的顶点 NS 记录、SOA 记录及权威数据。父区域一侧的授权 NS 记录与子区域一侧的权威 NS 记录应当保持一致，但它们是作为独立数据维护的。仅在服务器上配置托管子区域，并不会自动在父区域中添加授权记录。(rfc-editor.org)

**粘合记录**提供了访问某些被授权名称服务器所需的地址。在上述示例中，若要通过向子区域查询来获取 ns1.research.example.com. 的地址，就必须先访问该子区域本身，从而造成循环依赖。因此，父区域会提供一条 A 或 AAAA 地址记录作为粘合记录，通常放置在转介应答的附加段中。粘合记录属于引导信息，而非父区域关于子区域主机的权威数据。位于被授权子树之外的名称服务器则可以通过 DNS 的其他分支解析其地址，不存在此类直接依赖。2023 年 9 月发布的 RFC 9471 要求，转介应答中必须包含被授权域名内名称服务器的所有可用粘合记录；若因报文大小限制无法全部包含，则必须标记截断。(rfc-editor.org)

**权威名称服务器**直接使用本地保存的区域数据进行应答，无需从其他服务器获取答案。权威应答通过 AA（Authoritative Answer）标志位进行标识；向子区域的转介应答通常不设置该标志位。权威性是针对具体区域而言的：一台服务器可以托管多个区域，对某些域名是权威的，而对其他域名则返回转介应答。主服务器向其他服务器提供区域传输数据；辅助服务器则通过区域传输获取区域数据。两者都提供权威服务——辅助服务器并非仅仅是缓存，也不是仅在主服务器失效后才使用的备用节点。这些角色与具体的区域及传输关系挂钩，因此同一台服务器可以作为某个区域的主服务器，同时担任另一个区域的辅助服务器。(rfc-editor.org)

根区域的顶点为 .，主要包含指向顶级域（如 .com、.edu 和 .in）的授权信息及配套数据。根服务器只负责提供该区域的服务，而非存储包含所有域名记录的完整数据库。对于 .com 之下的查询，根服务器通常会返回一个指向 .com 服务器的转介应答；它本身并不会顺着后续授权链路继续查询以完成应用程序的查找。这项工作由解析器完成。根域涵盖整个命名树，而根区域的权威范围则止于其授权边界。(iana.org)

资源记录及其含义

条资源记录（RR）将一个所有者名称（owner name）与类型（type）、类（class）、生存时间（TTL）以及特定于该类型的资源数据（RDATA）关联起来。所有者名称标明信息所属的域名；类型决定如何解释其数据。Internet 类写作 IN，数值编号为 1，用于常规的互联网 DNS 数据。TTL 以秒为单位表示，规定了通常的最大缓存生存期，而非底层域名本身的生存期。共享相同所有者名称、类和类型的记录组成一个资源记录集，即 RRset；该集合内的所有记录必须具有相同的 TTL。因此，同一个名称的两个 A 记录构成一个 RRset，而其 AAAA 记录则构成另一个 RRset。(rfc-editor.org)

A 记录包含一个 32 位的 IPv4 地址；AAAA 记录则包含一个 128 位的 IPv6 地址，由 RFC 3596（2003年）规范。因此，单个所有者可以关联多个地址。相反，CNAME 记录将其所有者标识为另一个域名的别名：例如 www.example.com. CNAME web.example.com. 会将地址查询重定向到 web.example.com.，而不是自身存储地址。CNAME 所有者只能拥有一个规范目标，且不能同时携带普通数据记录（如 A、AAAA 或 MX 记录）；某些 DNS 安全元数据除外。因此，必须包含 SOA 和 NS 记录的区域顶点（zone apex）不能同时是 CNAME。(rfc-editor.org)

RFC 6672（2012年）修订规范的 DNAME 重定向的是其所有者的下级子域名，而不是所有者本身。例如，old.example. DNAME new.example. 会将 a.old.example. 映射到 a.new.example.，将 b.a.old.example. 映射到 b.a.new.example.，同时保留未匹配的标签。它不会重定向 old.example. 本身。服务器通常会同时返回 DNAME 以及一条描述该特定替换的合成 CNAME，以便客户端追踪重定向后的名称。与 CNAME 所有者不同，DNAME 所有者可以携带地址及其他兼容记录。(rfc-editor.org)

NS 记录指明权威服务器的域名，而非提供其地址。在区域顶点，SOA（“授权起始”）记录标识主要数据来源以及编码为域名的管理邮箱。其 32 位的序列号（serial）标识区域的版本修订；刷新（refresh）、重试（retry）和过期（expire）值用于控制辅助服务器的维护行为。以下区域文件片段展示了显式 TTL 的用法：(rfc-editor.org)

$ORIGIN example.com.
@    3600 IN SOA ns1.example.com. hostmaster.example.com. (
                  42 3600 600 1209600 300 )
@    3600 IN NS    ns1.example.com.
ns1  3600 IN A     192.0.2.53
web   300 IN A     192.0.2.80
web   300 IN AAAA  2001:db8::80
www   300 IN CNAME web.example.com.

在此例中，@ 表示 example.com.，而 web 等相对所有者名称继承该基准域。邮箱地址对应 hostmaster@example.com。序列号 42 是版本修订号，而非时间戳。各时间参数规定：每隔 3,600 秒进行一次刷新检查，失败后隔 600 秒重试一次，若连续 1,209,600 秒（14天）未能成功刷新则标记过期。最后一个数值 300 是 SOA MINIMUM 字段。根据 RFC 2308（1998年），否定回答缓存（negative caching）的时间取该值与 SOA 记录本身 TTL 中的较小者：此处为 300 秒。MINIMUM 并非适用于全区域正向记录 TTL 的下限值。(rfc-editor.org)

通配符记录的所有者名称最左侧标签恰好为 *，例如 *.example.com.。它是用于合成应答的源记录，而不是任意的文本模式表达式，其本质也不是别名。当被查询的名称不存在且权威解析进行到通配符合成阶段时，服务器会查找其最近封闭祖先（closest encloser，即现存的最长祖先），并仅检查紧接该祖先之下的 *。如果在该位置存在合适的数据，应答就会以被查询的名称作为所有者进行合成。如果某个名称已经存在，即使它缺少所请求的记录类型，也会阻止通配符替换；现存的空中间节点同样会影响最近封闭祖先的判断，而且合成过程不会跨越授权委托边界。因此，*.example.com. A 192.0.2.80 可以为 shop.example.com. 提供地址，但无法为已经存在的 web.example.com. 补全缺失的 AAAA 记录。(rfc-editor.org)

解析、引荐与缓存

应用程序通常通过操作系统提供的应用程序编程接口（例如 getaddrinfo()）请求域名解析，该接口返回适于建立网络连接的地址。存根解析器负责处理客户端的 DNS 交互，但无法独立完成整个解析过程；它通常向预先配置好的解析器发送递归请求。递归解析器代表客户端执行解析，利用本地缓存的信息或查询其他服务器。转发解析器则将查询转交给另一个解析器进行解析，并可能对结果进行缓存。权威服务器仅针对其所管辖的区域作出应答，并不为客户端提供通用的解析服务。这些均为功能角色：一个软件实现可以同时承担其中的多个角色。(rfc-editor.org)

以查询 www.example.com. 的 A 记录为例：假设递归解析器没有相关的缓存数据，但拥有标识根服务器的引导信息。它首先向根服务器发起查询，并收到一份标识 .com 域名服务器及其对应地址信息的引荐（referral）。随后，.com 服务器将其引荐给 example.com 的权威服务器；只要请求的记录存在，这些权威服务器中的一台就会返回该记录。若缺少域名服务器的地址，可能还需要进行额外的查询。客户端最初发出的请求是递归的，因为它要求解析器直接返回最终结果；而解析器与各权威服务器之间接续进行的交互则是迭代的，因为每个服务器只需返回指引下一步的信息，而不必自行完成查询。(rfc-editor.org)

缓存命中可以消除部分或全部此类交互。缓存的委派信息还可以让解析器跳过根节点、直接从下层节点开始查询。资源记录具有以秒为单位的生存时间（TTL）；具备缓存功能的解析器会对记录的剩余寿命进行倒计时，而不是在每次返回记录时重新赋予完整的生命周期。例如，一条初始 TTL 为 300 秒的条目在缓存两分钟后，通常只剩 180 秒的剩余寿命。不同的解析器在不同时间获取记录，并各自维护独立的缓存。因此，修改权威数据并不会引发全局同步的“传播”事件：此前已缓存的副本在其剩余寿命内依然可用。缩短新发布的 TTL 也不会追溯性地缩短已缓存副本的有效时间。(rfc-editor.org)

别名处理会使解析延伸至原始域名之外。当地址查询遇到 CNAME 记录时，解析器会追踪其目标域名，利用缓存信息或发起进一步查询，直至获取所请求的记录类型或得出其他结果。因此，一条应答可能包含一条别名链以及紧随其后的地址记录。别名与最终记录各自保留独立的 TTL，并非不可分割的单一缓存条目。别名出现环路会导致解析无法顺利完成，但这并不等同于证明所请求的域名不存在。(rfc-editor.org)

肯定应答会提供所请求的数据，通常伴随响应码 NOERROR（0）。NXDOMAIN（3）表示该域名不存在；如果此前追踪了别名，该结果可能是针对别名链末端的域名。NODATA 表示域名存在，但缺少所请求的记录类型——例如，一个域名拥有 A 记录却缺少 AAAA 记录。NODATA 并不是一个独立的响应码，而是根据不含所请求数据的 NOERROR 响应推导出来的状态，且必须与引荐响应区分开来。SERVFAIL（2）报告的是处理或解析失败，并不代表域名不存在；其可能的原因包括权威服务器不可达或安全验证失败。(rfc-editor.org)

由 RFC 2308 于 1998 年 3 月规范的否定缓存（Negative caching）用于存储 NXDOMAIN 和 NODATA 结果，以避免重复进行无果的查询。这类缓存的寿命取自随附 SOA 记录的 TTL 与其 MINIMUM 字段两者中的较小值。NXDOMAIN 依据域名和类别进行缓存，而 NODATA 的缓存还取决于所请求的记录类型：缺少 AAAA 记录并不意味着也不存在 A 记录。2023 年 12 月发布的 RFC 9520 进一步要求对解析失败进行缓存，以遏制重复的无效尝试。这种针对失败的缓存，在语义上与缓存“域名或记录类型不存在”的凭证截然不同。(rfc-editor.org)

报文格式与网络传输

DNS 报文以 12 字节的首部开头，其后依次是问题区段、回答区段、权威区段和附加区段。首部中的四个计数器分别指明各区段的条目数量。16 位的事务标识符会被复制到应答报文中，以帮助匹配请求与响应。问题区段包含 QNAME（查询名）、QTYPE（查询类型）和 QCLASS（查询类）；QTYPE 用于指定所请求的信息类型。回答记录用于回应查询问题，权威记录用于说明相关的权威服务器，附加记录则提供补充数据。QR 位用于区分查询与应答；OPCODE 用于标明操作类型。4 位的返回码（RCODE）用于报告处理结果，例如 NOERROR（0，正常）、SERVFAIL（2，服务器故障）和 NXDOMAIN（3，域名不存在）。AA 表示权威应答；TC 提示报文已截断；RD 用于请求递归查询；RA 用于通告服务器支持递归。RD 标志本身并不证明服务器实际执行了递归查询。(rfc-editor.org)

域名在报文中并非以点分隔的文本形式表示，而是采用以长度为前缀的标签序列，并以长度为零的根标签结尾。因此，www.example.com. 编码为 03 www 07 example 03 com 00（长度以十六进制表示）。报文压缩机制使用 2 字节的指针替代重复出现的域名或后缀：其最高两位为 11，其余 14 位指定相对于报文开头的偏移量。指针也可以紧接在字面标签之后。这种二进制表示形式有别于区域文件表示法，后者使用文本域名、转义序列以及管理指令。(rfc-editor.org)

传统的 DNS 服务在 53 端口上同时使用 UDP 与 TCP。UDP 在单个数据报中承载 DNS 报文；在不使用扩展机制的情况下，报文限制为 512 字节（不含 IP 和 UDP 首部）。当响应报文超出限制时，服务器可通过 TC 标志提示截断，促使客户端改用 TCP 重新尝试。TCP 的应用并不局限于区域传送或容错回退：2016 年 3 月发布的 RFC 7766 要求通用 DNS 实现必须同时支持这两种传输方式，并允许直接优先选用 TCP。TCP 数据流中的每个 DNS 报文都带有 2 字节的长度前缀（该数值不含前缀本身的长度），允许的最大报文大小为 65,535 字节。流式读取无需与报文边界完全对齐，且单个连接即可承载多次请求与响应交互。(rfc-editor.org)

DNS 扩展机制（通常称为 EDNS(0)）在不扩大原有首部的前提下对报文进行了扩充。2013 年 4 月发布的 RFC 6891 规定在附加区段中引入一种类型为 41 的单个 OPT 伪记录。OPT 属于事务元数据，而非发布的区域数据，绝不能被缓存。其 CLASS 字段用于宣告发送方的 UDP 接收能力；在请求中，该字段告知响应方请求端所能接收的最大 DNS 载荷。重新定义的 TTL 字段则承载扩展返回码、EDNS 版本以及相关标志位。可变长度选项使用 option-code、option-length 和 option-data 字段，支持独立规范的各项扩展功能。宣告的缓存大小仅代表接收能力声明，并不能保证该尺寸的数据包一定能顺利穿越网络路径。(rfc-editor.org)

允许更大的 UDP 载荷虽能减少截断现象，但当数据包超出路径最大传输单元（MTU）时可能引发 IP 分片。丢失任何一个分片都会导致整个数据报无法重组，而网络中的过滤设备也可能会直接阻断分片包。2025 年 1 月作为信息性文档发布的 RFC 9715 阐述了避免分片的技术：结合请求方宣告的能力与相关网络限制来约束 UDP 响应大小，并在较大应答需要改用其他传输方式时标记截断。TCP 可以利用适合该网络路径的分段大小来承载这一应答，而无需依赖单个庞大的 UDP 数据报。因此，支持 EDNS 并不意味着可以摒弃正常的 TCP 服务。(rfc-editor.org)

区域维护、部署与可靠性

DNS 区域可作为文本主文件（即区域文件）进行维护，权威服务器加载该文件以发布其中的资源记录；文件本身并不是查询接口。在主从（primary–secondary）部署架构中，SOA 记录的 32 位序列号用于标识区域的版本。发布内容变更后，序列号递增，从服务器将其本地序列号与配置的传输源序列号进行比较。比较过程采用包含回绕（wraparound）特性的序列号算术运算，而非将其视作无上限的整数。SOA 的刷新间隔（refresh）控制定期检查的频率，重试间隔（retry）控制失败后的后续尝试频率，而过期时间（expire）则限制了在无法成功刷新的情况下从服务器可继续对外提供服务的最长时间。这些同步定时器与控制递归缓存的 TTL 是截然不同的概念。(rfc-editor.org)

区域传输用于在服务器之间分发权威数据。全量区域传输（AXFR）会传输整个区域的数据；而增量区域传输（IXFR，由太田昌孝于 1996 年 8 月在 RFC 1995 中规范）则传输从请求方现存的 SOA 序列号到当前版本之间的删除与新增记录序列。如果无法获取所需的变更历史记录，IXFR 请求也可以直接获得全量区域作为响应。保罗·维克西（Paul Vixie）于同月发布的 RFC 1996 定义了 NOTIFY 机制：发生变更后，源服务器会向其从服务器发出通知，提示其检查 SOA 并视需要发起数据传输。因此，NOTIFY 是一种同步提示机制，而非区域传输本身的替代品。由于通知的送达并不受保证，定期的刷新机制仍然必不可少；此外，无论区域传输还是通知机制，都不会使递归缓存中已有的副本失效。(rfc-editor.org)

动态更新提供了另一种数据发布途径。1997 年 4 月发布的 RFC 2136 定义了 UPDATE 操作，允许在单个区域内添加或删除记录，并可选择附加前置条件（例如某记录集必须已存在或不存在）。该事务具有原子性：前置条件不满足会阻止变更生效，且查询操作绝不能观察到处于部分修改状态的记录集。授权依然是独立的要求；支持 UPDATE 操作并不意味着允许任意客户端修改区域。更新地址记录只是改变了公开发布的 DNS 数据，而注册域名则是通过注册局或注册商建立管理层面的登记。UPDATE 请求并不执行这种管理层面的域名注册。(rfc-editor.org)

可用性既依赖于数据冗余副本，也依赖于相互独立的故障隔离路径。跨越不同网络与地理位置部署的权威服务器可以降低因单点网络连通性或数据中心故障造成的风险。任播则提供了额外的保障层：多个服务实例向同一个 IP 地址宣告可达性，网络路由负责选择具体的实例；选择依据路由策略和网络拓扑结构，并不一定取决于地理位置的邻近度。无论是副本还是任播，都不会要求解析器无休止地等待某一特定服务器。解析器算法会维护候选服务器地址列表，在选择服务器时参考响应时间和成功率历史记录，并在发生超时或服务器错误时尝试其他候选服务器。这些机制确保了当某一组件不可用时，能够由其他服务器或路由路径作出应答。(rfc-editor.org)

递归解析器还可以采用受控的“陈旧应答”（serve-stale）机制。2020 年 3 月发布的 RFC 8767 允许在向权威服务器刷新失败时，返回即使已超过 TTL 的原缓存记录。这是一种有明确边界的回退机制，而非无限期重复使用：其推荐示例方法将客户端响应、刷新重试和最长陈旧期定时器分离开来，建议在过期后仍保留一至三天。返回已过期的记录时必须附带大于零的 TTL，推荐值为 30 秒。一旦成功从权威服务器完成刷新，陈旧状态即被替换，即使刷新后的应答表明该域名已不再存在也是如此。(rfc-editor.org)

专用 DNS（Private DNS）将 DNS 协议用于在公共互联网上通常无法获取的域名或数据。分离式DNS（也称水平分割 DNS，split-horizon DNS）可根据查询上下文对同一域名提供不同的应答。例如，内部视图可以为 portal.example.com 返回一个私网地址，而外部视图则返回面向公网的地址或完全忽略该域名。服务器视图通常根据源 IP 地址来区分查询，但也可能使用其他属性；视图是软件实现层面的功能，而非标准化的 DNS 协议操作。与全球共享的公共命名空间不同，此类应答取决于客户端所处的解析上下文，因此内部域名或地址无需通过公共递归解析器暴露或被发现。(rfc-editor.org)

基本地址查询之外的应用

邮件交换（MX）记录将电子邮件投递引导至为接收方域名指定的服务器。每条记录包含一个优先级数值和交换服务器的域名，而非其 IP 地址。例如，示例记录 example.com. IN MX 10 mail1.example.com. 和 example.com. IN MX 20 mail2.example.com. 将 mail1 设为首选目的地，并以 mail2 作为备用。数值越小优先级越高；优先级相同的目的地通常随机轮询以分摊负载。发送方服务器会解析所选交换服务器的 A 或 AAAA 记录，并通过简单邮件传输协议（SMTP）建立连接；该协议的修订规范于 2008 年 10 月发布在 RFC 5321 中。DNS 提供投递路由信息，而邮件正文则由 SMTP 而非 DNS 负责传输。(rfc-editor.org)

反向 DNS 查询利用 PTR 记录将 IP 地址关联到域名。IPv4 在 in-addr.arpa 域下反转十进制地址字节的顺序：例如，查询地址 192.0.2.25 时写作 25.2.0.192.in-addr.arpa.。IPv6 则使用 ip6.arpa，将展开后的全部 32 个十六进制字符作为独立标签逆序排列，这一规范于 2003 年 10 月发布在 RFC 3596 中。反向区域遵循地址空间的委派，而正向区域遵循域名的委派，因此两者的管理者可能有所不同。发布 A 或 AAAA 记录不会自动生成 PTR 记录。这种映射关系并不一定是一对一的：多个域名可以共享同一个 IP 地址，一个域名也可以拥有多个 IP 地址，且反向数据无需列出所有对应的正向域名。(rfc-editor.org)

SRV 记录由阿恩特·古尔布兰森（Arnt Gulbrandsen）、保罗·维克西（Paul Vixie）和列文·埃西博夫（Levon Esibov）于 2000 年 2 月在 RFC 2782 中提出，支持使用形如 _service._protocol.domain 的名称进行服务发现。例如示例记录 _ldap._tcp.example.com. IN SRV 10 60 389 directory.example.com. 指定了目标主机及 389 端口，优先级为 10，权重为 60。客户端优先选择数值较小的优先级；在优先级相同的目标之间，权重用于指导随机选择，而非作为附加的优先级层级。随后，客户端会解析所选目标的 IP 地址。该机制需要特定应用程序的支持：普通的地址查询并不会自动执行 SRV 服务发现。(rfc-editor.org)

SVCB 和 HTTPS 记录于 2023 年 11 月在 RFC 9460 中标准化，通过在目标名称旁发布连接参数扩展了端点发现功能。SVCB 需要特定协议的映射定义，而 HTTPS 则是针对 HTTP 方案的对应记录类型。优先级为零表示别名模式（AliasMode），会将服务绑定发现重定向至另一个名称；大于零的优先级表示服务模式（ServiceMode），用于描述可选端点，兼容的端点中优先级数值越小越优先。记录参数可以通过 alpn 通告应用层协议、指定替代的目的地 port（端口），并提供 IPv4 或 IPv6 地址提示。例如，example.com. IN HTTPS 1 edge.example.net. alpn="h2,h3" 通告了一个支持 HTTP/2 和 HTTP/3 的端点。地址提示可以减少连接延迟，但不能替代常规的 A 和 AAAA 解析。(rfc-editor.org)

内容分发网络可以利用 DNS，根据网络位置和服务状况返回不同的地址或别名，从而在多个副本端点之间进行选择。在没有额外客户端位置信息的情况下，权威服务器通常只能看到递归解析器的地址，而非最终用户的地址，因此解析器的位置可能无法精准反映客户端的网络位置。此外，共享缓存意味着许多客户端会在生存时间（TTL）过期前一直复用先前的解析结果；因此，修改权威应答并不能立即使所有客户端发生重定向。EDNS 客户端子网（ECS）可以提供客户端的网络前缀以实现更精准的应答，但其带来的隐私问题需另行探讨。(rfc-editor.org)

TXT 记录以一个或多个字符串的形式承载应用程序定义的信息，每个字符串最多容纳 255 字节。2014 年 4 月在 RFC 7208 中规范化的发信人策略框架（SPF）为这类文本赋予了明确的语法结构：例如示例值 v=spf1 ip4:192.0.2.25 -all 授权该 IPv4 地址作为该域名的 SPF 发信身份，并声明根据该策略其他地址均未获授权。域名验证系统则发布由服务商签发的令牌；例如，Google 会检查以 google-site-verification= 开头的 TXT 记录值，以验证对该域名 DNS 的控制权。这些语义由消费该数据的应用程序所赋予，而非 TXT 记录本身自带的属性。因此，TXT 是受制于 DNS 记录、报文大小及缓存限制的结构化约定载体，而非无约束的通用存储服务。(rfc-editor.org)

威胁与DNS安全扩展

伪造的 DNS 响应攻击的是解析器与其所查询服务器之间的边界：攻击者试图在真实响应到达之前替换应答。在缺乏加密认证机制的情况下，匹配事务标识符与传输参数虽有助于将响应与查询关联起来，但无法证明数据的来源真实性。当欺诈性数据进入解析器的缓存并随后影响其他查询时，就会发生缓存投毒。未经授权篡改区域数据则跨越了另一个边界——即发布记录的权威权限——这通常是通过管理员凭据失窃或未获适当授权的动态更新等机制实现的。DNSSEC 能够检测出针对已认证数据的未签名替换，但无法区分合法变更与通过被攻破的签名系统实施的恶意变更。(rfc-editor.org)

拒绝服务攻击可能会耗尽权威服务器、递归解析器或其网络连接的资源，导致原本正确的记录无法访问。反射攻击则是滥用 DNS 服务器来攻击另一个目标：UDP 查询携带伪造的受害者源地址，致使服务器将响应发送给该受害者。当这些响应的数据量大幅超过发起的查询时，就会产生放大效应；开放的递归解析器可能在不知不觉中充当反射器。这是两类截然不同的问题：前者直接攻击 DNS 的可用性，而后者则将 DNS 流量武器化，用来对付甚至无需提供 DNS 服务的第三方目标。DNSSEC 并不保证可用性，且其附加的签名和密钥记录反而会增大响应报文的体积。(rfc-editor.org)

DNS安全扩展（DNSSEC）的核心修订规范于 2005 年 3 月在 RFC 4033–4035 中发布，它将公钥密码学应用于资源记录集（RRset），而非加密 DNS 数据包本身。DNSKEY 记录用于发布公钥；RRSIG 包含对某个 RRset 的数字签名，指明签名者、算法和有效期限。父区域的 DS 记录包含用于标识子区域 DNSKEY 的摘要，从而将子区域的密钥与经过认证的父区域数据相连接。验证过程沿着这些信任链环节逐级向下追溯，其起点是配置的信任锚（通常为根区域密钥）。以经过签名的 example.com 为例，解析器首先验证根区域针对 com 的委托数据，然后验证 com 针对 example.com 的 DS 记录，最后验证子区域的 DNSKEY 记录集及所请求的记录。仅凭自签名是无法建立这种信任链的。(rfc-editor.org)

否定应答同样需要证明：不能让攻击者仅仅通过声称某个域名或记录类型不存在就能绕过认证。NSEC 记录按规范顺序指出下一个存在的名称，并列出其所有者名称处存在的记录类型，从而为名称空隙及缺失类型提供已签名的证明。2008 年 3 月标准化的 NSEC3 则利用散列化（哈希）名称提供相应的证明。这使得直接遍历枚举域名的难度高于顺着普通 NSEC 链遍历，但它既没有加密命名空间，也不能阻止猜测候选名称并比对其哈希值的字典攻击。(rfc-editor.org)

验证结果可区分为四种状态。安全（Secure）表示所有必需的签名都已通过信任链成功验证到信任锚。不安全（Insecure）表示通过已验证的委托确认了在该节点以下无需签名，通常是通过不存在 DS 记录的证明来实现；本地策略也可将命名空间的某些部分指定为不安全。虚假（Bogus）表示本应进行认证但验证失败，例如签名缺失、已过期或不正确。不确定（Indeterminate）表示没有适用的信任锚能确定该数据是否应当经过认证。对于“虚假”状态的应答，解析器通常会返回 SERVFAIL 状态码，而非返回可用的应答数据。即使验证结果为“安全”，也仅代表 DNS 数据本身的真实性得到验证，并不代表所指网站是诚信或安全的，并且它也不提供任何查询机密性。(rfc-editor.org)

运行的正确性依赖于时间同步以及跨独立缓存记录的一致性。RRSIG 的生效时间与过期时间限定了签名的有效期，这一机制独立于普通的 TTL 倒计时。因此，密钥轮换需要在旧密钥消失之前，兼顾到仍在缓存中的 DNSKEY 和 DS 记录，采用重叠发布或重叠签名机制。子区域签名密钥的变更必须与父区域的 DS 记录保持一致：如果只留下指向已删除密钥的 DS 记录，即便权威服务器仍可访问，也会导致验证中断。同样，过期的签名会使未发生变动且原本正确的记录变为“虚假”状态。2012 年 12 月发布的 RFC 6781 详细描述了这些依赖关系与轮换流程。(rfc-editor.org)

隐私与加密 DNS

即使被请求的记录本身是公开的，DNS 交互依然可能泄露信息。查询名称可能暴露具体服务、组织机构或个人兴趣；源 IP 地址将这些请求与特定的网络或用户关联；而时序则将连续的请求串联为活动模式。在未加密的 DNS 中，本地网络运营商及其他路径上的观察者可以窥视这些细节。递归解析器能看到客户端提交的请求，并可能在日志中保留查询名称、地址和时间戳。权威服务器运营商通常只能看到递归解析器的地址，而非原始客户端的地址，并且只能看到经过缓存和委派处理后到达其服务器的请求。这些不同的观察点带来了不同的数据隐私风险。 (rfc-editor.org)

查询名最小化（QNAME minimization）减少了迭代解析过程中泄露的信息。该机制最初于 2016 年 3 月在 RFC 7816 中规范化，并在 2021 年 11 月通过 RFC 9156 进行修订，其核心是避免向所查询的每台服务器发送完整的原始名称和查询类型。对于未缓存的 www.example.com. 查询，解析器可以先向根服务器询问 com.，再向 .com 服务器询问 example.com.，最后才向相应的权威服务器提交完整问题。中间服务器接收到的信息足以提供委派指引，而无需知晓请求的完整主机名。最小化并不能对递归解析器或最终应答的服务器隐瞒原始问题，且其本身并不加密流量。 (rfc-editor.org)

报文填充（Message padding）针对的是另一种泄露途径：加密消息仍可能具有特征性的长度。2018 年 10 月发布的 RFC 8467 实验性填充策略建议将加密的 DNS 查询填充为 128 字节的倍数，将响应填充为 468 字节的倍数。这减少了长度上的差异，而非隐藏所有的流量模式。2016 年 5 月在 RFC 7871 中记录的 EDNS 客户端子网（EDNS Client Subnet, ECS）则走向了相反的方向，它在查询中携带客户端网络前缀。权威服务可利用该前缀选择地理位置上更适宜的端点，而无需依赖递归解析器的位置。这种基于位置的应答是以在解析器之外泄露客户端网络信息为代价的；即使将地址截断为前缀，也无法消除这种信息泄露。 (rfc-editor.org)

DNS over TLS（DoT）于 2016 年 5 月在 RFC 7858 中实现标准化，它通过 TCP 之上的 TLS 传输 DNS 报文，通常使用 853 端口。DNS over HTTPS（DoH）于 2018 年 10 月在 RFC 8484 中实现标准化，它通过 HTTPS 请求与响应交换 DNS 线路格式（wire-format）报文，通常使用 443 端口。DoH 可与其他流量共享 HTTPS 基础设施和连接，使得仅凭专用 DNS 端口进行识别或干扰变得不再那么容易。HTTPS 还引入了潜在的关联机制，包括 HTTP 请求头和 Cookie。对于这两种传输方式，机密性的边界仅限于其端点之间的加密连接——例如客户端与其选择的递归解析器之间——而非整个解析过程。 (rfc-editor.org)

DNS over QUIC（DoQ）于 2022 年 5 月在 RFC 9250 中实现标准化，它将 DNS 直接映射到 QUIC 上，通常使用 UDP 853 端口。每次查询-响应交互都使用由客户端发起的一条独立双向流。QUIC 整合了密码学保护，并避免了 TCP 的跨流队头阻塞问题：一条流上的丢包不会阻碍另一条流的交付。DoQ 与基于 HTTP/3 承载的 DoH 不同，后者虽然也使用 QUIC，但仍保留了 HTTP 语义。DoQ 规范涵盖了客户端到递归解析器、递归解析器到权威服务器的连接，以及区域传输；保护某一段连接并不意味着会自动保护后续的连接。 (rfc-editor.org)

加密 DNS 仍然允许接收端的解析器检查查询内容并将其与发起连接的客户端关联。网络观察者仍然能看到端点地址、流量时序和流量大小，而填充技术仅能限制某些基于大小的推断。因此，解析器的日志记录与留存策略仍然独立于传输层加密。DNSSEC 解决的则是另一个维度的边界问题：它对经签名的 DNS 数据进行认证，而非隐藏问题或应答。与解析器建立机密连接本身并不能证实数据确实源自权威区域，而 DNSSEC 验证同样不能使传输过程具备机密性。 (rfc-editor.org)

协调与域名管理

互联网工程任务组（IETF）通过其标准化流程制定 DNS 协议规范；这一职责独立于域名注册审批或权威名称服务器的日常运维。互联网号码分配局（IANA）则根据技术规范中确立的分配策略，负责维护协议参数注册表（包括 DNS 记录类型代码等）。IANA 在根区方面的职责包括处理顶级域委派、记录其技术数据以及维护其管理者信息。权威服务器运营商则承担另一项独立的运维职能：发布区域内容并应答 DNS 查询。这些职责划分将协议设计、标识符协调和服务运营分离开来，而非将所有 DNS 活动集中于单一管理者之下。(ietf.org)

顶级域（TLD）可分为通用顶级域（如 .com）和国家与地区代码顶级域（如 .uk）。国家与地区代码顶级域的资格通常遵循 ISO 3166-1 标准中的两位字母代码，此外还对国际化国家/地区代码名称以及若干保留代码另行作出了专门规定。在域名注册体系中，注册局负责管理供域名注册的区域；注册商充当注册局与最终客户之间的中介；而注册人则是拥有该域名的个人或组织。并非所有注册流程都需要独立的注册商介入。DNS 托管服务商负责运营注册域名的权威服务器，其身份可以是注册商、注册人自身，亦或是独立的第三方公司。因此，即便域名注册与 DNS 托管常捆绑销售，二者在功能上也是完全独立的。(iana.org)

建立顶级域委派涉及行政授权与随后的技术发布两个阶段。对于新的通用顶级域，需先经过 ICANN 的评估、签署合同及委派前测试，之后注册局运营商方可通过 IANA 的根区管理系统提交委派申请。该申请需指明赞助组织、管理与技术联系人、权威名称服务器以及委派签署者（DS）记录等信息。处理流程在最终实施前包含联系人授权验证、技术检查和审核评估。发布阶段会将 NS 记录以及必要的地址胶水记录注入根区；若启用了 DNSSEC，还会一并加入支持其验证的 DS 记录。根区委派的作用是将解析器导向该顶级域的服务器，而非将该顶级域下注册的每一个具体域名或其应用记录直接写入根区。国家与地区代码顶级域的委派遵循独立的评估流程，但同样通过修改根区及其关联的管理数据库来实施。(iana.org)

某些域名并非用于日常注册，而是出于特定的技术目的而设立。.arpa 顶级域在互联网架构委员会的指导下专为对运营至关重要的互联网基础设施保留。其下属子域包括用于反向地址映射的 in-addr.arpa 与 ip6.arpa，以及用于将电话号码映射为互联网标识符的 e164.arpa。文档专用域名则属于另一类特殊用途：IANA 维护了 example.com、example.net 和 example.org，以便出版物或文档使用示例域名时无需占用第三方的真实域名。这些域名禁止注册或转让；.example 同样被指定为特殊用途域名。(iana.org)

特殊用途域名所规定的往往是特定的解析行为，而非建立普通的公共委派。发布于 2013 年 2 月的 RFC 6762 规定了以 .local 结尾的名称采用链路本地多播 DNS（mDNS）机制进行处理。发布于 2018 年 5 月的 RFC 8375 则将 home.arpa 指定用于家庭网络内部的非唯一命名：不同的家庭网络中可以独立存在完全相同的名称，并不要求全局唯一。这种明确定义的用法与随意虚构并视为“保留”的后缀截然不同。仅仅配置私有解析器来应答某一后缀，既不会使其并入共享的根区，也不会赋予其 IANA 的特殊用途地位；特殊用途域名的有效范围与处理规则必须遵循其对应的规范说明。(rfc-editor.org)

参考来源

  1. RFC 882: Domain names—Concepts and facilitiesrfc-editor.org
  2. RFC 883: Domain names—Implementation specificationrfc-editor.org
  3. RFC 952: DoD Internet host table specificationrfc-editor.org
  4. RFC 1034: Domain names—concepts and facilitiesrfc-editor.org
  5. RFC 1035: Domain names—implementation and specificationrfc-editor.org
  6. RFC 2181: Clarifications to the DNS Specificationrfc-editor.org
  7. RFC 9499: DNS Terminologyrfc-editor.org
  8. RFC 1035: Domain names — implementation and specificationrfc-editor.org
  9. RFC 1123: Requirements for Internet Hosts — Application and Supportrfc-editor.org
  10. RFC 4343: Domain Name System (DNS) Case Insensitivity Clarificationrfc-editor.org
  11. RFC 3986: Uniform Resource Identifier (URI): Generic Syntaxrfc-editor.org
  12. RFC 5890: Internationalized Domain Names for Applications (IDNA): Definitions and Document Frameworkrfc-editor.org
  13. RFC 1034: Domain names - concepts and facilitiesrfc-editor.org
  14. RFC 9471: DNS Glue Requirements in Referral Responsesrfc-editor.org
  15. Root Zone Managementiana.org
  16. Root Name Serversiana.org
  17. RFC 3596: DNS Extensions to Support IP Version 6rfc-editor.org
  18. RFC 2181: Clarifications to the DNS Specificationrfc-editor.org
  19. RFC 6672: DNAME Redirection in the DNSrfc-editor.org
  20. RFC 2308: Negative Caching of DNS Queries (DNS NCACHE)rfc-editor.org
  21. RFC 4592: The Role of Wildcards in the Domain Name Systemrfc-editor.org
  22. RFC 3493: Basic Socket Interface Extensions for IPv6rfc-editor.org
  23. RFC 2308: Negative Caching of DNS Queries (DNS NCACHE)rfc-editor.org
  24. RFC 9520: Negative Caching of DNS Resolution Failuresrfc-editor.org
  25. RFC 7766: DNS Transport over TCP - Implementation Requirementsrfc-editor.org
  26. RFC 6891: Extension Mechanisms for DNS (EDNS(0))rfc-editor.org
  27. RFC 9715: IP Fragmentation Avoidance in DNS over UDPrfc-editor.org
  28. Serial Number Arithmeticrfc-editor.org
  29. Incremental Zone Transfer in DNSrfc-editor.org
  30. A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)rfc-editor.org
  31. RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE)rfc-editor.org
  32. Selection and Operation of Secondary DNS Serversrfc-editor.org
  33. Operation of Anycast Servicesrfc-editor.org
  34. RFC 8767: Serving Stale Data to Improve DNS Resiliencyrfc-editor.org
  35. RFC 5321: Simple Mail Transfer Protocolrfc-editor.org
  36. RFC 3596: DNS Extensions to Support IP Version 6rfc-editor.org
  37. RFC 8501: Reverse DNS in IPv6 for Internet Service Providersrfc-editor.org
  38. RFC 2782: A DNS RR for specifying the location of services (DNS SRV)rfc-editor.org
  39. RFC 2782: A DNS RR for specifying the location of services (DNS SRV)datatracker.ietf.org
  40. RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)rfc-editor.org
  41. RFC 7871: Client Subnet in DNS Queriesrfc-editor.org
  42. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1datatracker.ietf.org
  43. Verify your domain with a TXT record - Google Workspace Admin Helpsupport.google.com
  44. RFC 3833: Threat Analysis of the Domain Name System (DNS)rfc-editor.org
  45. RFC 5358: Preventing Use of Recursive Nameservers in Reflector Attacksrfc-editor.org
  46. RFC 9364: DNS Security Extensions (DNSSEC)rfc-editor.org
  47. RFC 4033: DNS Security Introduction and Requirementsrfc-editor.org
  48. RFC 4034: Resource Records for the DNS Security Extensionsrfc-editor.org
  49. RFC 4035: Protocol Modifications for the DNS Security Extensionsrfc-editor.org
  50. RFC 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existencedatatracker.ietf.org
  51. RFC 7129: Authenticated Denial of Existence in the DNSrfc-editor.org
  52. RFC 6781: DNSSEC Operational Practices, Version 2rfc-editor.org
  53. RFC 9076: DNS Privacy Considerationsrfc-editor.org
  54. RFC 9156: DNS Query Name Minimisation to Improve Privacyrfc-editor.org
  55. RFC 8467: Padding Policies for Extension Mechanisms for DNS (EDNS(0))rfc-editor.org
  56. RFC 7858: Specification for DNS over Transport Layer Security (TLS)rfc-editor.org
  57. RFC 8484: DNS Queries over HTTPS (DoH)rfc-editor.org
  58. RFC 9250: DNS over Dedicated QUIC Connectionsrfc-editor.org
  59. Processietf.org
  60. Protocol Registriesiana.org
  61. Root Zone Databaseiana.org
  62. Qualifying top-level domain stringsiana.org
  63. Delegating a generic top-level domainiana.org
  64. Root Zone Change Request Processiana.org
  65. Delegating or transferring a country-code top-level domain (ccTLD)iana.org
  66. .ARPA Domainiana.org
  67. IANA-managed Reserved Domainsiana.org
  68. Special-Use Domain Namesiana.org