知识产权与互联网/域名系统

域名系统（DNS）是用于计算机、服务或连接到互联网或私有网络的任何资源的分层分布式命名系统。它将各种信息与分配给每个参与实体的域名相关联。最重要的是，它将对人类有意义的域名转换为与网络设备相关联的数字标识符，以便在全球范围内定位和寻址这些设备。

一个经常使用的比喻来解释域名系统是，它充当互联网的电话簿，将用户友好的计算机主机名转换为 IP 地址。例如，域名 www.example.com 转换为地址 192.0.32.10（IPv4）和 2620:0:2d0:200::10（IPv6）。

域名系统使得能够以有意义的方式将域名分配给互联网资源和用户组，而独立于每个实体的物理位置。因此，即使当前的互联网路由安排发生变化或参与者使用移动设备，万维网 (WWW) 超链接和互联网联系信息也可以保持一致和恒定。互联网域名比 IP 地址更容易记忆，例如208.77.188.166（IPv4）或2001:db8:1f70::999:de8:7648:6e8（IPv6）。用户在引用有意义的统一资源定位符 (URL) 和电子邮件地址时会利用这一点，而无需知道计算机如何实际定位它们。

域名系统通过为每个域指定权威名称服务器来分配域名和将这些名称映射到 IP 地址的责任。权威名称服务器被指定负责其特定域，并且反过来可以为其子域分配其他权威名称服务器。这种机制使 DNS 分布式且容错，并有助于避免需要不断查询和更新的单个中央注册表。

通常，域名系统还会存储其他类型的信息，例如接受给定互联网域的电子邮件的邮件服务器列表。通过提供全球范围的、分布式的基于关键字的重定向服务，域名系统是互联网功能的重要组成部分。

其他标识符，如 RFID 标签、UPC、电子邮件地址和主机名中的国际字符以及各种其他标识符，都可能使用 DNS。

域名系统还指定了此数据库服务的技术功能。它将 DNS 协议（DNS 中使用的数据结构和通信交换的详细规范）定义为互联网协议套件的一部分。

模板：IPstack

概述

互联网维护两个主要命名空间，即域名层次结构和互联网协议 (IP) 地址空间。域名系统维护域名层次结构，并在其与地址空间之间提供转换服务。互联网名称服务器和通信协议实现域名系统。DNS 名称服务器是存储域名 DNS 记录的服务器，例如地址 (A) 记录、名称服务器 (NS) 记录和邮件交换器 (MX) 记录（另请参见 DNS 记录类型列表）；DNS 名称服务器会以答案响应针对其数据库的查询。

历史

在网络上使用名称作为主机数字地址的更简单、更易于记忆的抽象的做法可以追溯到 ARPANET 时代。在 1982 年 DNS 发明之前，网络上的每台计算机都从 SRI（现为 SRI International）的一台计算机检索名为HOSTS.TXT的文件。HOSTS.TXT 文件将名称映射到数字地址。大多数现代操作系统默认情况下仍然存在主机文件，并且通常包含将 IP 地址 127.0.0.1 映射到“localhost”的映射。许多操作系统使用名称解析逻辑，允许管理员配置可用名称解析方法的选择优先级。

网络的快速增长使得集中维护的手工制作的 HOSTS.TXT 文件变得不可持续；有必要实现一个更具可扩展性的系统，能够自动传播必要的信息。

在 Jon Postel 的请求下，Paul Mockapetris 于 1983 年发明了域名系统并编写了第一个实现。原始规范由互联网工程任务组在RFC 882和RFC 883中发布，在 1987 年 11 月被RFC 1034和RFC 1035取代。一些其他请求意见书已提出对核心 DNS 协议的各种扩展。

1984 年，四名伯克利学生——道格拉斯·特里、马克·佩恩特、戴维·里格尔和周颂年——编写了第一个 Unix 实现，称为伯克利互联网名称域 (BIND) 服务器。1985 年，DEC 的凯文·邓拉普对 DNS 实现进行了重大重写。从那时起，迈克·卡雷尔斯、菲尔·阿尔姆奎斯特和保罗·维克西一直维护着 BIND。BIND 在 20 世纪 90 年代初移植到 Windows NT 平台。

BIND 被广泛分发，尤其是在 Unix 系统上，并且是互联网上使用最广泛的 DNS 软件。由于其开源代码的使用量很大以及随之而来的审查，以及越来越复杂 的攻击方法，BIND 中发现了许多安全漏洞。这促成了许多替代名称服务器和解析器程序的开发。BIND 版本 9 是从头开始编写的，现在其安全记录与其他现代 DNS 软件相当。

结构

域名空间

域名空间由域名树组成。树中的每个节点或叶子都有零个或多个资源记录，这些记录保存与域名相关联的信息。树从根区域开始细分为区域。DNS 区域可能仅包含一个域，也可能包含许多域和子域，具体取决于委托给管理器的管理权限。

分层域名系统，组织成区域，每个区域由一个名称服务器服务

任何区域的管理责任可以通过创建额外的区域来划分。对于旧空间的一部分，通常以子域的形式，被授权给另一个名称服务器和管理实体，称为委托。旧区域不再对新区域具有权威性。

域名语法

域名形成规则的明确描述出现在RFC 1035、RFC 1123和RFC 2181中。域名由一个或多个部分组成，技术上称为标签，通常通过点连接和分隔，例如example.com.

• 最右边的标签表示顶级域名；例如，域名www.example.com属于顶级域名com.
• 域名的层次结构从右到左下降；每个左边的标签指定右侧域名的细分或子域。例如：标签example指定了com域名的子域，而www是example.com的子域。此细分树最多可以有 127 个级别。
• 每个标签最多可以包含 63 个字符。完整的域名在其外部点分标签规范中不得超过 253 个字符。在 DNS 的内部二进制表示中，最大长度需要 255 个字节的存储空间。实际上，一些域名注册机构可能会有更短的限制。
• 从技术上讲，DNS 名称可以包含任何可以用八位字节表示的字符。但是，DNS 根区域和大多数其他子域中允许的域名格式和字符集使用首选格式和字符集。标签中允许的字符是 ASCII 字符集的子集，包括字符a到z、A到Z、数字0到9以及连字符。此规则称为LDH 规则（字母、数字、连字符）。域名以不区分大小写的方式解释。标签不能以连字符开头或结尾。
• 主机名是至少关联了一个 IP 地址的域名。例如，域名www.example.com和example.com也是主机名，而com域名则不是。

国际化域名

DNS 的允许字符集阻止了许多语言的名称和单词以其本地字母或文字进行表示。ICANN 批准了应用程序国际化域名 (IDNA) 系统，该系统使用 Punycode 将 Unicode 字符串映射到有效的 DNS 字符集。2009 年，ICANN 批准安装 IDN 国家代码顶级域名。此外，许多现有顶级域名 (TLD) 的注册机构已采用 IDNA。

名称服务器

域名系统由一个分布式数据库系统维护，该系统使用客户端-服务器模型。该数据库的节点是名称服务器。每个域至少有一个权威 DNS 服务器，用于发布有关该域以及任何从属于它的域的名称服务器的信息。层次结构的顶部由根名称服务器提供服务，这些服务器是在查找（解析）TLD 时要查询的服务器。

权威名称服务器

权威名称服务器是指提供由原始源（例如，域管理员或通过动态 DNS 方法）配置的答案的名称服务器，与通过对另一个名称服务器执行常规 DNS 查询获得的答案形成对比。仅权威名称服务器仅返回对已由管理员专门配置的域名查询的答案。

权威名称服务器可以是主服务器或从服务器。主服务器是存储所有区域记录的原始（主）副本的服务器。从服务器使用 DNS 协议的自动更新机制与其主服务器通信以维护主记录的相同副本。

每个 DNS 区域都必须分配一组权威名称服务器，这些服务器安装在父区域的 NS 记录中。

当域名在域名注册机构注册时，其在顶级域名的域名注册机构的安装需要分配一个主名称服务器和至少一个辅助名称服务器。多个名称服务器的要求旨在使域即使在其中一个名称服务器变得不可访问或无法运行时也能保持功能。主名称服务器的指定完全由赋予域名注册机构的优先级决定。为此，通常只需要名称服务器的完全限定域名，除非服务器包含在注册域中，在这种情况下，还需要相应的 IP 地址。

主名称服务器通常是主名称服务器，而辅助名称服务器可以实现为从服务器。

权威服务器通过设置软件标志（协议结构位），称为其响应中的权威答案（AA）位，来指示其提供确定性答案（被认为是权威的）的状态。此标志通常在 DNS 管理查询工具（如 dig）的输出中突出显示，以指示响应名称服务器是所讨论域名的权威机构。

递归和缓存名称服务器

原则上，权威名称服务器足以用于互联网的运行。但是，如果仅使用权威名称服务器，则每个 DNS 查询都必须从域名系统的根区域开始进行递归查询，并且每个用户系统都必须实现能够进行递归操作的解析器软件。

为了提高效率，减少互联网上的 DNS 流量，并提高最终用户应用程序的性能，域名系统支持 DNS 缓存服务器，这些服务器会将 DNS 查询结果存储一段时间，该时间由所讨论的域名记录的配置（生存时间）确定。通常，此类缓存DNS 服务器（也称为DNS 缓存）还实现了必要的递归算法，以从 DNS 根开始到查询域的权威名称服务器，解析给定的名称。通过在名称服务器中实现此功能，用户应用程序在设计和操作方面获得了效率。

在名称服务器中组合 DNS 缓存和递归功能不是强制性的；这些功能可以在服务器中独立实现以用于特殊目的。

互联网服务提供商通常会为其客户提供递归和缓存名称服务器。此外，许多家庭网络路由器都实现了 DNS 缓存和递归器以提高本地网络的效率。

DNS 解析器

DNS 的客户端称为 DNS 解析器。它负责启动和排序最终导致完全解析（转换）所需资源的查询，例如，将域名转换为 IP 地址。

DNS 查询可以是非递归查询或递归查询

• 非递归查询是指 DNS 服务器提供其本身具有权威性的域的记录，或者它提供部分结果而无需查询其他服务器。
• 递归查询是指 DNS 服务器将通过根据需要查询其他名称服务器来完全回答查询（或给出错误）。DNS 服务器不需要支持递归查询。

解析器或代表解析器递归运行的其他 DNS 服务器使用查询标头中的位协商递归服务的用法。

解析通常需要遍历多个名称服务器才能找到所需的信息。但是，一些解析器通过仅与单个名称服务器通信来更简单地运行。这些简单的解析器（称为“存根解析器”）依赖于递归名称服务器来完成查找信息的工作。

操作

地址解析机制

域名解析器通过一系列从最右侧（顶级）域名标签开始的查询，确定负责查询域名名的相应域名服务器。

DNS 递归解析器咨询三个名称服务器来解析 www.wikipedia.org 的地址。

此过程包括

1. 网络主机配置了一个初始缓存（称为提示），其中包含已知根名称服务器的地址。管理员会定期从可靠来源更新此类提示文件。
2. 向其中一个根服务器查询以查找负责顶级域名的服务器。
3. 向获得的 TLD 服务器查询二级域名的 DNS 服务器地址。
4. 重复上一步，依次处理每个域名标签，直到最后一步返回所查找主机的 IP 地址。

该图说明了主机 www.wikipedia.org 的此过程。

这种简单形式的机制会给根服务器带来巨大的操作负担，因为每次搜索地址都从查询其中一个根服务器开始。由于它们对于系统的整体功能至关重要，因此如此大量的使用会为每天数万亿次查询创建一个无法逾越的瓶颈。在实践中，DNS 服务器中使用了缓存来克服此问题，因此根名称服务器实际上只参与了很少一部分总流量。

循环依赖和粘合记录

委派中的名称服务器通过名称而不是 IP 地址来标识。这意味着解析名称服务器必须发出另一个 DNS 请求以找出已将其引用到的服务器的 IP 地址。如果委派中给出的名称是提供委派域名的子域名，则存在循环依赖关系。在这种情况下，提供委派的名称服务器还必须为委派中提到的权威名称服务器提供一个或多个 IP 地址。此信息称为粘合。委托名称服务器以 DNS 响应的附加部分中的记录形式提供此粘合，并在响应的答案部分中提供委派。

例如，如果以下域名的权威名称服务器为example.org是ns1.example.org，则尝试解析的计算机www.example.org首先解析ns1.example.org。由于ns1包含在example.org中，这需要首先解析example.org，这会产生循环依赖关系。为了打破依赖关系，顶级域名org的名称服务器将粘合与example.org的委派一起包含。粘合记录是提供ns1.example.org的 IP 地址的地址记录。解析器使用这些 IP 地址中的一个或多个来查询域的权威服务器之一，这使其能够完成 DNS 查询。

记录缓存

由于为公共互联网生成的 DNS 请求量很大，因此设计人员希望提供一种机制来减少单个 DNS 服务器的负载。为此，DNS 解析过程允许在答案一段时间后缓存记录。这包括本地记录和随后查阅副本，而不是发起新的上游请求。解析器缓存 DNS 响应的时间由每个记录关联的称为生存时间 (TTL) 的值确定。TTL 由发出权威响应的 DNS 服务器的管理员设置。有效期可以从几秒到几天甚至几周不等。

作为这种分布式和缓存架构的一个值得注意的结果，DNS 记录的更改不会立即传播到整个网络，而是需要所有缓存在 TTL 后过期并刷新。RFC 1912 传达了确定适当 TTL 值的基本规则。

某些解析器可能会覆盖 TTL 值，因为协议支持最多缓存 68 年或根本不缓存。负缓存，即缓存记录不存在的事实，由负责区域的名称服务器确定，该服务器在报告请求类型的任何数据不存在时必须包含起始授权 (SOA) 记录。SOA 记录的MINIMUM字段的值以及 SOA 本身的 TTL 用于建立负答案的 TTL。

反向查找

反向查找是在已知 IP 地址的情况下查询 DNS 以获取域名。多个域名可能与一个 IP 地址关联。DNS 以特殊格式的名称（指针（PTR）记录）的形式存储基础结构顶级域名 arpa 中的 IP 地址。对于 IPv4，该域名是in-addr.arpa。对于 IPv6，反向查找域名是ip6.arpa。IP 地址以反向排序的八位字节表示形式表示（对于 IPv4），以及反向排序的四位字节表示形式表示（对于 IPv6）。

执行反向查找时，DNS 客户端会将地址转换为这些格式，然后查询名称以获取 PTR 记录，这与任何 DNS 查询一样，遵循委派链。例如，IPv4 地址208.80.152.2表示为 DNS 名称为2.152.80.208.in-addr.arpa。DNS 解析器首先查询根服务器，这些服务器指向 ARIN 的208.in-addr.arpa区域服务器。从那里分配 Wikimedia 服务器152.80.208.in-addr.arpa，并且通过查询 wikimedia 名称服务器2.152.80.208.in-addr.arpa来完成 PTR 查找，这将产生权威响应。

客户端查找

DNS 解析序列

用户通常不会直接与 DNS 解析器通信。相反，DNS 解析会在 Web 浏览器、电子邮件客户端和其他 Internet 应用程序等应用程序程序中透明地进行。当应用程序发出需要域名查找的请求时，此类程序会将解析请求发送到本地操作系统中的DNS 解析器，然后该解析器处理所需的通信。

DNS 解析器几乎总是会拥有一个缓存（见上文），其中包含最近的查找。如果缓存可以提供请求的答案，则解析器会将缓存中的值返回给发出请求的程序。如果缓存不包含答案，则解析器会将请求发送到一个或多个指定的 DNS 服务器。对于大多数家庭用户而言，机器连接到的互联网服务提供商通常会提供此 DNS 服务器：此类用户要么手动配置了该服务器的地址，要么允许 DHCP 设置它；但是，在系统管理员已将系统配置为使用自己的 DNS 服务器的情况下，其 DNS 解析器将指向组织单独维护的名称服务器。无论如何，因此查询的名称服务器都将遵循上面概述的过程，直到它成功找到结果或找不到结果。然后，它将其结果返回给 DNS 解析器；假设它已找到结果，则解析器会适当地缓存该结果以供将来使用，并将结果交还给启动请求的软件。

损坏的解析器

当解析器违反 DNS 协议规则时，会产生另一层复杂性。一些大型 ISP 已将其 DNS 服务器配置为违反规则（可能是为了让他们能够在比完全兼容的解析器更便宜的硬件上运行），例如，不遵守 TTL，或者仅仅因为其名称服务器之一没有响应而指示域名不存在。

作为最后一层复杂性，某些应用程序（如 Web 浏览器）也拥有自己的 DNS 缓存，以减少对 DNS 解析器库本身的使用。此做法在调试 DNS 问题时可能会增加额外的难度，因为它会掩盖数据的最新程度和/或哪些数据来自哪个缓存。这些缓存通常使用非常短的缓存时间——大约一分钟。

Internet Explorer 是一个值得注意的例外：最高版本 IE 3.x 默认情况下会缓存 DNS 记录 24 小时。Internet Explorer 4.x 及更高版本（直至 IE 8）将默认超时值减少到半小时，这可以在相应的注册表项中更改。

其他应用程序

上面概述的系统提供了一个稍微简化的场景。域名系统包含其他几个功能

• 主机名和 IP 地址不一定是一对一匹配的。多个主机名可能对应于单个 IP 地址：结合虚拟主机，这允许一台机器服务于多个网站。或者，单个主机名可能对应于多个 IP 地址：这可以促进容错和负载分配，并且还允许站点无缝地移动物理位置。
• 除了将名称转换为 IP 地址外，DNS 还有许多用途。例如，邮件传输代理使用 DNS 找出要将特定地址的电子邮件发送到哪里。MX 记录提供的域名到邮件交换机映射在名称到 IP 地址映射之上提供了另一层容错和负载分配。

• **邮件黑名单：** DNS 系统用于高效存储和分发被列入黑名单的邮件主机 IP 地址。常见的方法是将目标主机的 IP 地址放入更高级别域名（higher level domain name）的子域名中，并解析该名称为不同的记录以指示是正向还是负向。这是一个假设的黑名单示例。
  • 102.3.4.5 被列入黑名单 => 创建 5.4.3.102.blacklist.example 并解析为 127.0.0.1
  • 102.3.4.6 未被列入 => 6.4.3.102.blacklist.example 未找到，或默认为 127.0.0.2
  • 然后，邮件服务器可以通过 DNS 机制查询 blacklist.example，以了解连接到它们的特定主机是否在黑名单中。如今，许多此类黑名单，无论是免费的还是基于订阅的，主要供电子邮件管理员和反垃圾邮件软件使用。

• **软件更新：** 许多反病毒和商业软件现在使用 DNS 系统存储最新软件更新的版本号，这样客户端计算机就不需要每次都连接到更新服务器。对于这些类型的应用程序，DNS 记录的缓存时间通常较短。

• 发送者策略框架 (SPF) 和 DomainKeys 并没有创建自己的记录类型，而是设计为利用另一种 DNS 记录类型：TXT 记录。
• 为了在计算机故障时提供弹性，通常会为每个域提供多个 DNS 服务器以实现覆盖，并且在顶级，存在 13 个功能强大的根服务器，以及通过 Anycast 分布在全球的几个根服务器的额外“副本”。
• **动态 DNS（有时称为 DDNS）** 允许客户端在 IP 地址更改时更新其 DNS 条目，例如，在 ISP 或移动热点之间切换时。

协议细节

DNS 主要使用用户数据报协议 (UDP) 在 53 端口上提供服务请求。 DNS 查询由客户端发出的单个 UDP 请求以及服务器发出的单个 UDP 回复组成。当响应数据大小超过 512 字节或执行区域传送等任务时，使用传输控制协议 (TCP)。一些解析器实现对所有查询都使用 TCP。

DNS 资源记录

**资源记录 (RR)** 是域名系统中的基本数据元素。每个记录都有一个类型 (A、MX 等)、一个过期时间限制、一个类以及一些特定于类型的的数据。相同类型的资源记录定义一个资源记录集 (RRset)。解析器返回给应用程序的集合中资源记录的顺序未定义，但服务器通常实现轮循排序以实现负载平衡。但是，DNSSEC 基于规范顺序处理完整的资源记录集。

当通过 IP 网络发送时，所有记录都使用 RFC 1035 中指定的通用格式。

RR（资源记录）字段

字段	描述	长度（八位字节）
NAME	此记录所涉及的节点的名称	(可变)
TYPE	RR 的类型，以数字形式表示（例如，MX RR 为 15）	2
CLASS	类代码	2
TTL	RR 保持有效的秒数（最大值为 231-1，大约 68 年。）	4
RDLENGTH	RDATA 字段的长度	2
RDATA	其他 RR 特定数据	(可变)

NAME 是树中节点的完全限定域名。在网络上传输时，可以使用标签压缩来缩短名称，其中数据包中前面提到的域名末尾可以替换为当前域名末尾。

TYPE 是记录类型。它指示数据的格式，并暗示其预期用途。例如，A 记录用于将域名转换为 IPv4 地址，NS 记录列出哪些名称服务器可以回答 DNS 区域中的查找，而 MX 记录指定用于处理电子邮件地址中指定的域的邮件的邮件服务器（另请参见 DNS 记录类型列表）。

RDATA 是与类型相关的特定数据，例如地址记录的 IP 地址，或 MX 记录的优先级和主机名。众所周知的记录类型可以在 RDATA 字段中使用标签压缩，但“未知”记录类型不得使用 (RFC 3597)。

记录的CLASS 设置为IN(用于Internet)，用于涉及 Internet 主机名、服务器或 IP 地址的常用 DNS 记录。此外，还存在 Chaos 类（CH）和 Hesiod 类（HS）。每个类都是一个独立的命名空间，可能具有不同的 DNS 区域委派。

除了在区域文件中定义的资源记录之外，域名系统还定义了几种请求类型，这些请求类型仅用于与其他 DNS 节点（在线）通信，例如执行区域传送 (AXFR/IXFR) 或 EDNS (OPT) 时。

通配符 DNS 记录

域名系统支持通配符域名，这些域名以星号标签“*”开头，例如：*.example.属于通配符域名的 DNS 记录指定了在单个 DNS 区域内生成资源记录的规则，方法是用查询名称（包括任何指定的子代）的匹配组件替换整个标签。例如，在 DNS 区域x.example中，以下配置指定x.example的所有子域（包括子域的子域）都使用邮件交换器a.x.example。需要a.x.example的记录来指定邮件交换器。由于这会导致排除此域名及其子域与通配符匹配，因此a.x.example的所有子域必须在单独的通配符语句中定义。

RFC 4592 改进了通配符记录的作用，因为 RFC 1034 中的原始定义不完整，导致实现者误解。

协议扩展

原始的 DNS 协议对扩展新功能的规定有限。1999 年，Paul Vixie 在 RFC 2671 中发布了一种扩展机制，称为 DNS 的扩展机制 (EDNS)，它引入了可选的协议元素，而不会在不使用时增加开销。这是通过OPT伪资源记录实现的，该记录仅存在于协议的网络传输中，而不存在于任何区域文件中。还建议了初始扩展 (EDNS0)，例如增加 UDP 数据报中 DNS 消息的大小。

动态区域更新

动态 DNS 更新使用UPDATEDNS 操作码以动态方式添加或删除权威 DNS 服务器上维护的区域数据库中的资源记录。RFC 2136 中描述了此功能。此功能对于在网络客户端启动或在网络上可用时将其注册到 DNS 中很有用。由于启动的客户端每次可能从 DHCP 服务器分配不同的 IP 地址，因此无法为这些客户端提供静态 DNS 分配。

安全问题

最初，安全问题不是 DNS 软件或任何用于在早期互联网上部署的软件的主要设计考虑因素，因为网络尚未向公众开放。但是，互联网在 1990 年代扩展到商业领域，改变了安全措施的要求，以保护数据完整性和用户身份验证。

恶意用户发现了多个漏洞问题并加以利用。其中一个问题是DNS缓存投毒，攻击者伪装成权威源服务器，将数据分发到缓存解析器，从而用可能错误的信息和较长的过期时间（生存时间）污染数据存储。随后，合法的应用程序请求可能会被重定向到恶意操作的网络主机。

传统的DNS响应没有使用加密签名，导致了许多攻击的可能性；域名系统安全扩展（DNSSEC）修改了DNS，增加了对加密签名响应的支持。还设计了一些扩展来保护区域传输的安全。

某些域名可能被用来实现欺骗效果。例如，paypal.com和paypa1.com是不同的名称，但用户可能无法在图形用户界面中区分它们，具体取决于用户选择的字体。在许多字体中，字母l和数字1看起来非常相似，甚至完全相同。在支持国际化域名（IDN）的系统中，这个问题尤其严重，因为ISO 10646中的许多字符代码在典型的计算机屏幕上可能看起来相同。此漏洞偶尔会被网络钓鱼攻击利用。

诸如前向确认反向DNS之类的技术也可用于帮助验证DNS结果。

域名注册

域名使用权由域名注册商授权，域名注册商由互联网名称与数字地址分配机构（ICANN）认证，该机构负责监督互联网的名称和数字系统。除了ICANN之外，每个顶级域名（TLD）在技术上都由一个管理组织维护和服务，并运营一个注册机构。注册机构负责维护其管理的顶级域名中注册的名称数据库。注册机构从每个被授权在相应顶级域名中分配名称的域名注册商处接收注册信息，并使用特殊的服务（whois协议）发布这些信息。

ICANN 发布了完整的顶级域名注册机构和域名注册商列表。与域名关联的注册人信息保存在一个可通过WHOIS服务访问的在线数据库中。对于超过240个国家代码顶级域名（ccTLD）中的大多数，域名注册机构维护WHOIS（注册人、名称服务器、过期日期等）信息。例如，德国NIC DENIC持有DE域数据。大约从2001年开始，大多数gTLD注册机构采用了这种所谓的“厚”注册机构方法，即在中央注册机构而不是注册商数据库中保存WHOIS数据。

对于COM和NET域名，使用“薄”注册机构模型：域名注册机构（例如VeriSign）保存基本的WHOIS（注册商和名称服务器等）数据。可以在注册商处找到详细的WHOIS（注册人、名称服务器、过期日期等）。

一些域名注册机构，通常称为“网络信息中心”（NIC），也充当最终用户的注册商。主要的通用顶级域名注册机构，例如COM, NET, ORG, INFO域，使用由许多域名注册商组成的注册机构-注册商模型在这种管理方法中，注册机构仅管理域名数据库以及与注册商的关系。“注册人”（域名用户）是注册商的客户，在某些情况下，通过额外的经销商层级。

互联网标准

域名系统由互联网工程任务组（IETF）发布的请求意见书（RFC）文档定义（互联网标准）。以下是定义DNS协议的RFC列表。

• RFC 920，域名要求 – 指定了最初的顶级域名
• RFC 1032，域名管理员指南
• RFC 1033，域名管理员操作指南
• RFC 1034，域名 - 概念和设施
• RFC 1035，域名 - 实现和规范
• RFC 1101，网络名称和其他类型的DNS编码
• RFC 1123，互联网主机要求 - 应用和支持
• RFC 1178，为您的计算机选择名称（FYI 5）
• RFC 1183，新的DNS RR定义
• RFC 1591，域名系统结构和委托（信息性）
• RFC 1912，常见的DNS操作和配置错误
• RFC 1995，DNS中的增量区域传输
• RFC 1996，区域更改的及时通知机制（DNS NOTIFY）
• RFC 2100，主机的命名（信息性）
• RFC 2136，域名系统中的动态更新（DNS UPDATE）
• RFC 2181，DNS规范的澄清
• RFC 2182，辅助DNS服务器的选择和操作
• RFC 2308，DNS查询的负缓存（DNS NCACHE）
• RFC 2317，无类IN-ADDR.ARPA委托（BCP 20）
• RFC 2671，DNS的扩展机制（EDNS0）
• RFC 2672，非终端DNS名称重定向
• RFC 2845，DNS的密钥交易身份验证（TSIG）
• RFC 3225，指示解析器支持DNSSEC
• RFC 3226，DNSSEC和IPv6 A6感知服务器/解析器消息大小要求
• RFC 3597，未知DNS资源记录（RR）类型的处理
• RFC 3696，名称检查和转换的应用程序技术（信息性）
• RFC 4343，域名系统（DNS）大小写不敏感性说明
• RFC 4592，通配符在域名系统中的作用
• RFC 4635，HMAC SHA TSIG算法标识符
• RFC 4892，识别名称服务器实例的机制要求（信息性）
• RFC 5001，DNS名称服务器标识符（NSID）选项
• RFC 5452，增强DNS对伪造答案的抵御能力的措施
• RFC 5625，DNS代理实现指南（BCP 152）
• RFC 5890，应用程序的国际化域名（IDNA）：定义和文档框架
• RFC 5891，应用程序中的国际化域名（IDNA）：协议
• RFC 5892，Unicode代码点和应用程序的国际化域名（IDNA）
• RFC 5893，应用程序的国际化域名（IDNA）的从右到左脚本
• RFC 5894，应用程序的国际化域名（IDNA）：背景、解释和基本原理（信息性）
• RFC 5895，2008年应用程序的国际化域名（IDNA）字符映射（信息性）
• RFC 6195，域名系统（DNS）IANA注意事项（BCP 42）

安全

• RFC 4033，DNS 安全性介绍和需求
• RFC 4034，DNS 安全性扩展的资源记录
• RFC 4035，DNS 安全性扩展的协议修改
• RFC 4509，在 DNSSEC 委派签名者 (DS) 资源记录中使用 SHA-256
• RFC 4470，最小覆盖 NSEC 记录和 DNSSEC 在线签名
• RFC 5011，DNS 安全性 (DNSSEC) 信任锚点的自动更新
• RFC 5155，DNS 安全性 (DNSSEC) 散列身份验证的否定存在
• RFC 5702，在 DNSSEC 的 DNSKEY 和 RRSIG 资源记录中使用 RSA 的 SHA-2 算法
• RFC 5910，域名系统 (DNS) 安全性扩展的可扩展配置协议 (EPP) 映射
• RFC 5933，在 DNSSEC 的 DNSKEY 和 RRSIG 资源记录中使用 GOST 签名算法

外部链接

• Vixie，Paul (2007年5月4日)。“DNS 复杂性 – 尽管它只包含几个简单的规则，但 DNS 已经发展成为一个极其复杂的系统”。ACM Queue。
• Zytrax.com，开源指南 – 为火箭科学家准备的 DNS，在线技术文档。
• 在 zonefile.org 上创建区域文件
• 域名系统 在 Microsoft TechNet 上