DNS 是分层分布式数据库和一组关联的协议，用于定义：
用于查询和更新数据库的机制
用于在服务器之间复制数据库中的信息的机制
数据库的架构
DNS 主机名驻留在可在多个服务器之间分布的数据库，减少任何一台服务器上的负载，并提供按分区管理此命名系统的能力。 DNS 支持分层名称，并允许注册各种数据类型，以及 HOSTS 文件中使用的主机名到 IP 地址映射。 DNS 数据库是分布式的，允许它纵向扩展和横向扩展，这意味着添加更多服务器时性能不会下降。
原始 DNS 基于征求意见稿 （RFC） 1035 （域名实现和规范）。 其他 RFC 介绍了 DNS 安全性、实现和管理问题，后来增加了原始设计规范。
Windows Server作系统中使用的 RFC 包括：
- 域名 - 概念和设施 RFC 1034
- 域名 - 实现和规范 RFC 1035
- 用于支持 IP 版本 6 RFC 1886 的 DNS 扩展
- 区域更改提示通知机制 （DNS NOTIFY） RFC 1996
- DNS RFC 1995 中的增量区域传输
- 域名系统中的动态更新（DNS 更新）RFC 2136
- DNS 查询（DNS NCACHE） RFC 2308 的负缓存
- DNS 安全扩展插件 RFC 4034 的资源记录
- DNS 安全扩展插件 RFC 4035 的协议修改
- 用于指定服务位置（DNS SRV） RFC 2052 的 DNS RR
DNS 域名
DNS 作为包含各种类型的数据（包括主机名和域名）的分层分布式数据库实现。 DNS 数据库中的名称构成了称为域命名空间的分层树结构。 域名由用点分隔的各个标签组成，例如： mydomain.contoso.com
完全限定的域名 （FQDN） 唯一标识主机在 DNS 分层树中的位置。 FQDN 指定了从引用主机到根目录的路径中用点分隔的名称列表。 下图显示了一个 DNS 树示例，其中在 mydomain 域中有一个名为 contoso.com 的主机。 主机的 FQDN 将为 mydomain.contoso.com。
了解 DNS 域命名空间
如上图所示，DNS 域命名空间基于命名域树的概念。 树的每个级别都可以表示分支或叶。 分支是一个级别，其中多个名称用于标识命名资源的集合。 叶代表在该级别使用一次的单个名称，表示特定资源。
DNS 域名层次结构
DNS 客户端和服务器使用查询作为将树中的名称解析为特定类型的资源信息的方法。 此信息由 DNS 服务器在查询响应中提供给 DNS 客户端，然后提取信息并将其传递给请求程序以解析查询的名称。 在解析名称的过程中，DNS 服务器通常充当 DNS 客户端，查询其他服务器以完全解析查询的名称。
例如，Contoso 被互联网根服务器授予权力管理其自身的 DNS 域命名空间树的一部分，即contoso.com。 解析 contoso.com 命名空间外部的名称需要 Contoso DNS 服务器查询其他 DNS 服务器，例如根服务器。
如何组织 DNS 域命名空间
树中使用的任何 DNS 域名在技术上都是一个域。 但是，大多数 DNS 讨论根据级别和常用名称的方式，以五种方式之一标识名称。 例如，注册到 Contoso （contoso.com） 的 DNS 域名称为二级域。 该名称有两个部分（称为标签），表示它位于根或树顶以下两级。 大多数 DNS 域名都有两个或更多个标签，每个标签都指示树中的新级别。 句点用于名称以分隔标签。
下表按命名空间中的函数描述 DNS 域名的五个类别，以及每种名称类型的示例。
| 名称类型 | Description | Example |
|---|---|---|
| 根域 | 树的顶部，表示未命名的级别;它有时显示为两个空引号（“），指示 null 值。 在 DNS 域名中使用时，会用尾随句点（.）来指定该名称位于域层次结构的根级别或最高级别。 在此实例中，DNS 域名被视为完整，并指向名称树中的确切位置。 按这种方式声明的名称为 FQDN。 单个句点 (.) 或名称末尾使用的句点，例如 example.contoso.com. |
单个句点 (.) 或名称末尾使用的句点，例如 example.contoso.com. |
| 顶级域 （TLD） | 一个名称，用于指示国家或地区或使用名称的组织类型。 |
.com，表示注册给企业用于 Internet 商业用途的名称。 |
| 二级域 | 注册给个人或组织以在 Internet 上使用的可变长度名称。 这些名称始终基于适当的顶级域，具体取决于使用名称的组织或地理位置的类型。 |
contoso.com. 是 Internet DNS 域名注册机构注册到 Contoso 的第二级域名。 |
| Subdomain | 组织可以创建的其他名称，这些名称派生自已注册的二级域名。 子域名包括被添加的名称，用于扩展组织中的 DNS 名称树，并将其划分为部门或地理位置。 |
example.contoso.com. 是 Contoso 分配的子域，用于文档示例名称。 |
| 主机或资源名称 | 表示 DNS 名称树中的叶并标识特定资源的名称。 通常，DNS 域名的最左侧标签标识网络上的特定计算机。 例如，如果在主机 （A） 资源记录中使用此级别的名称，则用于基于计算机的主机名查找计算机的 IP 地址。 |
host-a.example.contoso.com. 第一个标签（主机 a）是网络上特定计算机的 DNS 主机名。 |
DNS 和 Internet 域
Internet 注册机构管理域名系统。 注册机构负责维护组织和国家/地区分配的顶级域。 这些域名遵循国家/地区代码国际标准（ISO 3166）。 有数百个顶级域名可供公众使用。 下表显示了几个常见的 TLD，以及用于国家和地区的双字母缩写示例。
| DNS 域名 | 组织类型 |
|---|---|
| .com | 商业组织 |
| .edu | 教育机构 |
| .org | 非盈利组织 |
| .net | 网络（Internet 的主干） |
| .gov | 非军事政府组织 |
| .mil | 军事政府组织 |
| .arpa | 反向 DNS |
| .xx | 双字母国家/地区代码（例如，.us、.au、.ca、.fr） |
DNS 资源记录
DNS 资源记录包含区域所包含的资源（如主机）的相关信息。 典型的资源记录包括：
- 资源记录的名称（主机）。
- 有关资源记录在缓存中可以保留多长时间的信息。
- 资源记录类型，例如主机（A）资源记录。
- 特定于记录类型的数据，例如主机 IPv4 地址。
可以直接添加资源记录，也可以在启用 Windows 的动态主机配置协议（DHCP）客户端使用动态更新加入网络时自动添加这些记录。
资源记录的类型
常见资源记录包括：
| 资源记录类型 | Description |
|---|---|
| 主机（A、AAAA）记录 | 将主机名映射到 IP 地址。 |
| 别名 (CNAME) 记录 | 将别名域名或子域转发到另一个主域名或标准域名。 别名 (CNAME) 资源记录也称作规范名称资源记录。 使用这些记录，可以使用多个 DNS 名称指向单个主机。 |
| 邮件交换器 （MX） 记录 | 指定交换或转发邮件的计算机的名称。 电子邮件应用程序使用邮件交换器（MX）资源记录根据邮件电子邮件收件人的目标地址中的 DNS 域名查找邮件服务器。 如果存在多个邮件交换器（MX）资源记录，则 DNS 客户端服务会尝试按从最低值（最高优先级）到最高值（最低优先级）的顺序联系邮件服务器。 |
| 指针 (PTR) 记录 | 反向 DNS 查询用于将一个 IP 地址映射到一个域名。 根据在 in-addr.arpa 域中创建并以其为根的区域，指针 (PTR) 资源记录支持反向查找过程。 需要在 DNS 服务器上具有适当的反向查找区域，才能创建一条 PTR 记录，该记录将 IP 地址映射到特定主机名。 |
| 服务位置 (SRV) 记录 | 指定服务的主机、端口和协议。 当客户端使用 DNS 查找位置服务（如 Active Directory 域控制器）时，需要服务位置（SRV）资源记录。 |
| 域名服务器（NS）记录 | 指定域的权威名称服务器。 |
| 文本 (TXT) 记录 | 允许在 DNS 记录中发布文本。 通过文本记录，可以添加通过查询 DNS 返回的文本信息。 TXT 记录通常用于对 DNS 区域的所有权进行身份验证。 |
| 委托名称 (DNAME) 记录 | 为域提供别名，例如 CNAME 记录，但包括所有子域。 |
| 授权启动 (SOA) 记录 | 提供有关 DNS 区域的权威信息。 SOA 记录包括主名称服务器、DNS 区域管理员联系人、刷新信息和其他信息。 |
资源记录的生存时间
资源记录中的生存时间（TTL）值指示其他 DNS 服务器用来决定缓存记录信息的时间长度，以便在其过期并被丢弃之前对其进行缓存。 例如，DNS 服务器服务创建的大多数资源记录从颁发机构 (SOA) 资源记录开始后继承一小时的最小（默认）TTL，从而阻止其他 DNS 服务器的扩展缓存。
DNS 客户端解析程序会缓存解析 DNS 查询时收到的响应。 然后，这些缓存的响应可用于回答后续查询中的相同信息。 但是，缓存的数据在响应数据返回的 TTL 参数中指定的生存期有限。 TTL 确保 DNS 服务器不会长时间保留信息，使其过期。 缓存的 TTL 可以在 DNS 数据库中设置（通过指定记录的 TTL 字段为每个单独的资源记录设置，通过 SOA 记录的最小 TTL 字段为每个区域设置），也可以在 DNS 客户端解析程序端设置，方法是指定解析程序允许缓存资源记录的最大 TTL。
设置 TTL 时需要考虑两个相互竞争的因素。 第一个是缓存信息的准确性，第二个是 DNS 服务器的利用率和网络流量量。 如果 TTL 较短，则旧信息的可能性会大幅减少，但它会增加 DNS 服务器和网络流量的利用率，因为 DNS 客户端必须在下次请求时查询 DNS 服务器以获取过期的数据。 如果 TTL 很长，则缓存的响应可能会过时，这意味着解析程序可能会为查询提供虚假答案。 同时，长时间的 TTL 会减少 DNS 服务器的利用率，并减少网络流量，因为 DNS 客户端使用缓存的数据来回答查询。
如果查询通过缓存中的条目进行应答，则条目的 TTL 也会随响应一起传递。 这样，接收响应的解析程序知道条目的有效时间。 解析程序遵循来自响应服务器的 TTL;它们不会根据自己的 TTL 重置它。 因此，当条目从 DNS 服务器移动到具有更新的 TTL 的 DNS 服务器时，条目实际上会过期，而不是永久过期。
Note
一般情况下，从不将 TTL 配置为零。 0 或 60 的设置在记录的准确性上差异最小，但当 TTL 设置为 0 时，对 DNS 服务器性能有显著影响，因为 DNS 服务器需要不断查询过期的数据。
区域和委派
DNS 数据库可以分区为多个区域。 区域是 DNS 数据库的一部分，其中包含属于 DNS 命名空间连续部分的所有者名称的资源记录。 区域文件保留在 DNS 服务器上。 可以将单个 DNS 服务器配置为托管零、一个或多个区域。
每个区域都定位在称为区域根域的特定域名上。 区域包含有关以区域根域名结尾的所有名称的信息。 如果 DNS 服务器加载包含该名称的区域，则将其视为具有权威性的名称。 任何区域文件中的第一条记录都是“授权起始”(SOA) 资源记录。 SOA 资源记录将该区域的主 DNS 名称服务器标识为该区域中数据的最佳信息来源。 SOA 还充当处理区域更新的实体。
还可以将区域中的名称委托给托管在不同的 DNS 服务器上的其他区域。 委派是将 DNS 命名空间的一部分责任分配给由单独实体拥有的 DNS 服务器的过程。 此单独的实体可以是公司内的另一个组织、部门或工作组。 此类委派由 NS 资源记录表示，该记录指明被委派的区域以及负责该区域服务器的 DNS 名称。 跨多个区域委派是 DNS 原始设计目标的一部分。
若要详细了解 DNS 区域的类型和复制，请参阅 DNS 区域。
委托 DNS 命名空间的原因包括：
需要将 DNS 域的管理委托给组织内的许多组织或部门。
需要在多个 DNS 服务器之间分配维护一个大型 DNS 数据库的负载，以提高名称解析性能并创建 DNS 容错环境。
需要允许主机的组织关联，方法是在适当的域中包含主机。 名称服务器（NS）资源记录通过识别每个区域的 DNS 服务器来促进委派，并且 NS 资源记录显示在所有区域中。 每当 DNS 服务器需要跨委派才能解析名称时，它引用目标区域中 DNS 服务器的 NS 资源记录。
下图显示如何将 contoso.com 域的管理委托给两个区域，contoso.com 和 mydomain.contoso.com。
Note
如果委托区域存在多个 NS 记录，标识可用于查询的多个 DNS 服务器，则 Windows Server DNS 服务器服务将能够根据每个 DNS 服务器的往返间隔选择最近的 DNS 服务器。
DNS 服务体系结构
下图展示了在 Windows 客户端和 Windows Server 中，DNS 客户端服务架构的名称解析和更新作业流程。 使用客户端应用程序演示名称解析体系结构，更新由 DHCP 客户端表示。
下图演示了 DNS Server 服务体系结构及其管理工具和 Windows Server 中的 Windows Management Instrumentation （WMI） 接口。
以下部分介绍了 DNS 查询过程以及 DNS 更新的处理方式。
DNS 查询
DNS 查询可以从 DNS 客户端（解析程序）发送到 DNS 服务器，也可以从两个 DNS 服务器之间发送。
DNS 查询只是对具有指定 DNS 名称的指定资源记录类型的 DNS 资源记录的请求。 例如，DNS 查询可以请求具有指定 DNS 名称的 A 类型（主机）的所有资源记录。
有两种类型的 DNS 查询可以发送到 DNS 服务器：
递归：递归查询强制 DNS 服务器响应失败或成功响应的请求。 DNS 客户端（解析程序）通常进行递归查询。 使用递归查询，DNS 服务器必须联系它需要解决请求的任何其他 DNS 服务器。 当它从其他 DNS 服务器（或服务器）收到成功的响应时，它会向 DNS 客户端发送响应。 递归查询是解析器查询 DNS 服务器时的典型查询类型，同时也是 DNS 服务器查询其转发器时使用的查询类型。转发器是配置为处理转发给它请求的另一个 DNS 服务器。
当 DNS 服务器处理递归查询并且无法从本地数据（本地区域文件或以前的查询缓存）解析查询时，递归查询必须升级到根 DNS 服务器。 每个基于标准的 DNS 实现都包含一个缓存文件（或根服务器提示），其中包含 Internet 域的根 DNS 服务器的条目。 （如果 DNS 服务器配置了转发器，则先使用转发器，然后再使用根服务器。）
迭代：迭代查询是一个迭代查询，其中 DNS 服务器应根据 DNS 服务器从本地区域文件或缓存中知道的内容，响应它拥有的最佳本地信息。 如果 DNS 服务器对名称不具有权威性，则此响应也称为引荐。 如果 DNS 服务器没有任何本地信息可以应答查询，则只需发送负面响应。 DNS 服务器在尝试在其本地域（或域）之外查找名称时（如果未使用转发器配置）时进行这种类型的查询。 它可能需要在 DNS 服务器外部查询，以尝试解析名称。
下图显示了这两种类型的查询的示例。
此图显示了如何使用多个查询来确定其 www.contoso.comIP 地址。 查询序列如下所述：
www.contoso.com的递归查询（资源记录）。www.contoso.com的迭代查询（资源记录）。引用
.com域名服务器（NS 资源记录，用于.com）；为简单起见，省略了 DNS 服务器为解析其他 DNS 服务器返回的域名服务器主机名 IP 地址而进行的迭代 A 查询。www.contoso.com的迭代查询（资源记录）。引用
contoso.com域名服务器（NS 资源记录，用于contoso.com）。www.contoso.com的迭代查询（资源记录）。迭代查询的回答来自 contoso.com 服务器（
www.contoso.comIP 地址）。从本地 DNS 服务器向解析程序发出的对原始递归查询的应答（
www.contoso.comIP 地址）。
更新 DNS
资源记录通常会随着计算机、服务器和设备添加到网络或从网络中删除而更改。 Windows Server 中 DNS 的实现同时支持 DNS 数据库的静态更新和动态更新。
可以使用 Add-DNSServerResourceRecord PowerShell 命令将资源记录添加到现有区域。 某些常见的资源记录类型具有其他 PowerShell 命令，无需指定资源记录类型。 还可以使用 DNS 管理器控制台添加资源记录。 有关使用资源记录的指导，请参阅 管理 DNS 资源记录 ，包括创建和修改所有类型的现有资源记录。
Unicode 字符支持
当 DNS 作为 RFC 1035 的一部分引入时，名称仅限于使用大写和小写字母（A-Z、a-z）、数字（0-9）和连字符（-）。 此外，DNS 名称的第一个字符可以是数字，必须使用基于 US-ASCII 的字符对名称进行编码和表示。 在国际环境中使用 DNS 时，此要求对使用扩展字符集的本地命名标准产生了显著限制。 除了 RFC 1035 规范之外，Windows Server DNS 服务还支持 UTF-8 字符。
什么是 UTF-8？
UTF-8 是协议发展的建议字符集，超越了 ASCII 的使用。 UTF-8 协议支持扩展 ASCII 字符和 UCS-2 的翻译，这是一个包含全球大多数写入系统的 16 位 Unicode 字符集。 UTF-8 支持比使用 ASCII 或扩展 ASCII 编码字符数据实现的名称范围要大得多。
运行 Windows Server 2008 的计算机可识别 UTF-8。 这意味着，当服务器接收或用作数据的 UTF-8 编码字符时，服务器可以在其区域中加载和存储此数据。 尽管基于 Windows 的 DNS 服务器具有 UTF-8 感知功能，但它们仍与使用传统 US-ASCII 数据编码和当前 DNS 标准的其他 DNS 服务器兼容。
DNS 服务如何实现 UTF-8
为了提供与其他 DNS 实现的标准兼容性和互操作性，DNS 服务会将收到的任何字符数据统一转换为小写。 在此过程中，DNS 服务将标准 US-ASCII 数据中使用的所有大写字符转换为小写等效数据，原因如下：
- 保持与当前和现有 DNS 标准的兼容性。
- 提供与无法识别或支持 UTF-8 编码的 DNS 服务器实现的互作性。
若要了解为什么选择了统一的小写处理，必须先考虑当前修订的 DNS Internet 标准中的几个相关点。 标准中的几个要点直接关系到如何在 DNS 服务器和其他服务器和客户端之间处理字符数据。 要点包括：
- 任何二进制字符串都可以在 DNS 名称中使用。 （RFC 2181）
- DNS 服务器必须能够以不区分大小写的方式比较名称。 （RFC 1035）
- 在将数据输入系统时，应尽可能保留字符数据的原始大小写。 （RFC 1035）
由于大小写不区分是 DNS 核心标准的必要组成部分，而大小写保留则是一项可选建议，因此选择了统一的小写处理来提供有效的符合标准的解决方案。 在传输前将 UTF-8 编码名称转换为小写，这样一来，其他 DNS 服务器（不支持 UTF-8 的服务器）就能够接收到数据，成功进行二进制比较并获得所需结果。
与 UTF-8 互作性的注意事项
可以将 DNS 服务器服务设置为允许或阻止对每台服务器使用 UTF-8 字符。 某些不支持 UTF-8 的 DNS 服务器可能接受 UTF-8 名称的区域，但可能难以保存或重新加载这些名称。 将 UTF-8 名称的区域传输到不支持 UTF-8 的服务器时，请小心。
某些协议对名称中允许的字符施加限制。 此外，旨在全局可见的名称（RFC 1958）应包含仅限 ASCII 的字符，如 RFC 1123 中建议的那样。
使用 UTF-8 转换 Unicode 字符对用户不可见。 但是，如果使用网络监视器或类似工具来分析 DNS 流量，则可以看到 UTF-8 编码字符。
除了对 UTF-8 编码格式的 DNS 服务器支持外，客户端解析程序默认使用 UTF-8 字符编码格式。
以 UTF-8 格式编码的名称不得超过 RFC 2181 中阐明的大小限制，每个标签最多指定 63 个八进制数，每个名称最多 255 个八进制数。 字符计数不足以确定大小，因为某些 UTF-8 字符的长度超过一个八进制。
UTF-8 编码协议适应于与现有的 DNS 协议实现一起使用，这些实现期望 US-ASCII 字符，因为在 UTF-8 中表示 US-ASCII 字符的方式在字节上与 US-ASCII 表示完全相同。 无法识别 UTF-8 字符的 DNS 客户端或服务器实现始终采用 US-ASCII 格式对名称进行编码。 DNS 服务器服务能够正确解释这些名称。
DNS 服务可以配置名称检查，以允许或限制在 DNS 数据中使用 UTF-8 字符。
默认情况下，使用多字节 UTF-8 名称检查，从而允许 DNS 服务处理字符时的最大容差。 多字节 UTF-8 名称检查是大多数未为 Internet 主机提供名称服务的专用 DNS 服务器的首选名称检查方法。