通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

DNS 区域和记录概述

  • 项目

本文解释了域、DNS 区域、DNS 记录和记录集的关键概念。 你将了解它们在 Azure DNS 中的受支持方式。

域名

域名系统是域的层次结构。 该层次结构从名为“.”的 root 域开始。 此域的下面是顶级域，例如 com、net、org、uk 或 jp。 位于顶级域之下的是二级域，例如 org.uk 或 co.jp。 DNS 层次结构中的域遍布全球，由世界各地的 DNS 名称服务器托管。

域名注册机构是一个组织，可以通过该组织购买域名，例如 contoso.com。 购买域名便有权控制该名下的 DNS 层次结构，例如可将名称 www.contoso.com 定向到公司网站。 注册器会代表你在其自身的名称服务器中托管域，或者允许你指定可选名称服务器。

Azure DNS 提供全球分布的高可用性名称服务器基础结构，并可将其用于托管域。 通过在 Azure DNS 中托管域，用户可以使用与其他 Azure 服务相同的凭据、API、工具、计费和支持来管理 DNS 记录。

Azure DNS 当前不支持购买域名。 对于年度费用，可以使用应用服务域或第三方域名注册机构购买域名。 然后，可以将域托管在 Azure DNS 中来管理记录。 有关详细信息，请参阅 向 Azure DNS 委派域。

DNS 区域

DNS 区域用来托管某个特定域的 DNS 记录。 若要开始在 Azure DNS 中托管域，需要为该域名创建 DNS 区域。 随后会在此 DNS 区域内为每个 DNS 记录创建域。

例如，域“contoso.com”可能包含几条 DNS 记录，如“mail.contoso.com”（用于邮件服务器）和“www.contoso.com”（用于网站）。

在 Azure DNS 中创建 DNS 区域时：

  • 在资源组中，区域名称必须是唯一的，不能存在该域。 否则，操作会失败。
  • 可在不同资源组或不同 Azure 订阅中重复使用同一区域名称。
  • 当多个区域共享相同的名称时，将为每个实例分配不同的名称服务器地址。 使用域名注册机构仅可配置一组地址。

注意

不必拥有域名即可在 Azure DNS 中以该域名创建 DNS 区域。 但是，需要拥有域才能通过域名注册机构将 Azure DNS 名称服务器配置为域名的正确名称服务器。

有关详细信息，请参阅 向 Azure DNS 委派域。

DNS 记录

记录名称

在 Azure DNS 中，记录使用相对名称指定。 完全限定的域名 (FQDN) 包括区域名称，而相对域名则不包括。 例如，contoso.com 区域中的相对记录名称 www 会提供完全限定的记录名称 www.contoso.com。

顶点记录是位于 DNS 区域的根（或顶点）中的 DNS 记录。 例如，在 DNS 区域 contoso.com 中，顶点记录还具有完全限定的名称 contoso.com（有时称为裸域）。 按照惯例，相对名称 @ 用于表示顶点记录。

记录类型

每个 DNS 记录都有一个名称和类型。 这些记录根据其所包含的数据分为各种类型。 最常见的类型为“A”记录，这种记录将名称映射到 IPv4 地址。 另一种常见类型是“MX”记录，这种记录将名称映射到邮件服务器。

Azure DNS 支持所有常见 DNS 记录类型：A、AAAA、CAA、CNAME、MX、NS、PTR、SOA、SRV 和 TXT。 请注意，SPF 记录使用 TXT 记录表示。

记录集

有时，需要创建具有给定名称和类型的多个 DNS 记录。 例如，假设在两个不同的 IP 地址上托管“www.contoso.com”网站。 该网站需要两个不同的 A 记录，每个 IP 地址一个。 这就是记录集的示例：

www.contoso.com.        3600    IN    A    134.170.185.46
www.contoso.com.        3600    IN    A    134.170.188.221

Azure DNS 使用记录集管理所有 DNS 记录。 记录集（也称为资源记录集）是某个区域中具有相同名称、相同类型的 DNS 记录的集合。 大多数记录集包含单个记录。 但是，上面所示的示例一个记录集包含多个记录，这并不少见。

例如，假设已在区域“contoso.com”中创建 A 记录“www”，指向 IP 地址“134.170.185.46”（上述第一条记录）。 要创建第二条记录，应将此记录添加到现有记录集而非创建其他记录集。

SOA 和 CNAME 记录类型例外。 对于这些类型，DNS 标准不允许多个记录具有相同的名称，因此这些记录集仅可包含单个记录。

生存时间

生存时间（或 TTL）指定客户端在重新查询之前缓存每个记录的时长。 在上例中，TTL 为 3600 秒或 1 小时。

在 Azure DNS 中，TTL 针对记录集而不是每个记录指定，因此同一个值适用于该记录集中的所有记录。 可以指定介于 1 和 2,147,483,647 秒之间的任何 TTL 值。

通配符记录

Azure DNS 支持 通配符记录。 具有匹配名称的任何查询都会返回通配符记录，除非存在与非通配符记录集更接近的匹配项。 对于除 NS 和 SOA 外的所有记录类型，Azure DNS 都支持通配符记录集。

若要创建通配符记录集，请使用记录集名称“*”。 此外，还可以使用将“*”作为最左侧标签的名称，例如“*.foo”。

CAA 记录

CAA 记录允许域所有者指定哪些证书颁发机构 (CA) 有权为其域颁发证书。 这使得 CA 可以避免在某些情况下错误颁发证书。 CAA 记录具有三个属性：

  • 标志：此字段是一个介于 0 和 255 之间的整数，用于按照 RFC6844 表示具有特殊含义的关键标志
  • Tag：一个 ASCII 字符串，可以是以下项之一：
    • 问题：适用于指定有权颁发证书（所有类型）的 CA
    • issuewild：适用于指定有权颁发证书（仅限通配符证书）的 CA
    • iodef：指定对于未经授权的证书颁发请求，CA 可以向其发送通知的电子邮件地址或主机名
  • Value：所选特定标记的值

CNAME 记录

CNAME 记录集不能与其他具有相同名称的记录集共存。 例如，不能同时创建包含相对名称 www 的 CNAME 记录集和包含相对名称 www 的 A 记录。

由于区域顶点（名称为“@”）始终包含创建区域时创建的 NS 和 SOA 记录集，因此不能在区域顶点创建 CNAME 记录集。

这些约束起源于 DNS 标准，并非 Azure DNS 的限制。

NS 记录

区域顶点（名称为“@”）处的 NS 记录集将随每个 DNS 区域自动创建，并在删除该区域时自动删除。 无法单独删除该项。

此记录集包含分配给该区域的 Azure DNS 名称服务器名称。 可向此 NS 记录集添加更多名称服务器，从而支持与多个 DNS 提供商共同托管域。 还可修改此记录集的 TTL 和元数据。 但是，不允许删除或修改预先填充的 Azure DNS 名称服务器。

此限制仅适用于区域顶点处的 NS 记录集。 区域中的其他 NS 记录集（用于委派子区域）不受约束，可进行创建、修改和删除。

SOA 记录

SOA 记录集在每个区域（名称为“@”）的顶点处自动创建，在删除该区域时会被自动删除。 无法单独创建或删除 SOA 记录。

可以修改 SOA 记录的所有属性，但 host 属性除外。 此属性将预先配置为引用 Azure DNS 提供的主名称服务器名称。

当对区域中的记录进行更改时，SOA 记录中的区域序列号不会自动更新。 如果需要，可以通过编辑 SOA 记录手动进行更新。

注意

Azure DNS 目前不支持在 SOA hostmaster 邮箱条目中的“@”前面使用点 (.)。 例如：不允许 john.smith@contoso.xyz（转换为 john.smith.contoso.xyz）和 john\.smith@contoso.xyz。

SPF 记录

发送方策略框架 (SPF) 记录用于指定可以代表域名发送电子邮件的电子邮件服务器。 正确配置 SPF 记录非常重要，可防止收件人将你的电子邮件标记为“垃圾邮件”。

DNS RFC 最初引入了新的 SPF 记录类型来支持此方案。 为了支持旧名称服务器，还允许它们使用 TXT 记录类型指定 SPF 记录。 这种不明确性导致混乱，已通过 RFC 7208 得到解决。 它指出必须使用 TXT 记录类型创建 SPF 记录。 它还指出 SPF 记录类型已弃用。

SPF 记录受 Azure DNS 支持且必须使用 TXT 记录类型创建。 不支持已过时的 SPF 记录类型。 导入 DNS 区域文件时，使用 SPF 记录类型的任何 SPF 记录将转换为 TXT 记录类型。

SRV 记录

多种服务使用 SRV 记录指定服务器位置。 在 Azure DNS 中指定 SRV 记录时：

  • 服务和协议必须指定为以下划线为前缀的记录集名称的一部分，如“_sip._tcp.name”。 对于区域顶点处的记录，无需在记录名称中指定“@”，只需使用服务和协议，例如“_sip._tcp”。
  • 将 priority 、weight 、port 和 target 指定为记录集中每个记录的参数。

TXT 记录

TXT 记录用于将域名映射到任意文本字符串。 它们在多个应用程序中使用，特别是与电子邮件配置相关（如发件人策略框架 (SPF)和域密钥识别邮件 (DKIM)）。

DNS 标准允许单个 TXT 记录包含多个字符串，其中每个字符串的长度最多可为 255 个字符。 使用多个字符串时，它们由客户端连接在一起，被视为单个字符串。

调用 Azure DNS REST API 时，需要单独指定每个 TXT 字符串。 使用 Azure 门户、PowerShell 或 CLI 接口时，应为每个记录指定单个字符串。 此字符串会在必要时自动划分为 255 个字符的段。

DNS 记录中的多个字符串不应与 TXT 记录集的多个 TXT 记录混淆。 TXT 记录集可以包含多个记录，其中每个 可以包含多个字符串。 Azure DNS 在每个 TXT 记录集（跨所有合并的记录）中支持总长度最多 4096 个字符。

标记和元数据

Tags

标记是名称/值列表，Azure 资源管理器利用它们来标记资源。 Azure 资源管理器使用标记来启用 Azure 帐单的筛选视图，并支持设置需要特定标记的策略。 有关标记的详细信息，请参阅 使用标记来组织 Azure 资源。

Azure DNS 支持使用 DNS 区域资源上的 Azure 资源管理器标记。 它不支持 DNS 记录集的标记，不过作为替代方法，DNS 记录集支持使用“元数据”，如下所述。

Metadata

作为记录集标记的替代方法，Azure DNS 支持使用“元数据”批注记录集。 与标记相类似，通过元数据可将名称/值对与每个记录集相关联。 此功能非常有用，例如可用于记录每个记录集的用途。 与标记不同的是，元数据不能用于提供 Azure 帐单的筛选视图，且不能在 Azure 资源管理器策略中指定。

Etag

假设两个人或两个进程尝试同时修改一条 DNS 记录。 哪一个占先？ 占先方是否知道他们/它们已覆盖了其他人/进程创建的更改？

Azure DNS 使用 Etag 来安全地处理对同一资源的并发更改。 Etag 与 Azure 资源管理器“标记”不同。 每个 DNS 资源（区域或记录集）都有与其相关联的 Etag。 只要检索资源，就会检索其 Etag。 当更新资源时，可以选择传递回 Etag 以便 Azure DNS 可以验证服务器上的 Etag 是否匹配。 由于对资源的每次更新都会导致重新生成 Etag，Etag 不匹配表示发生了并发更改。 创建新的资源时，也可以通过使用 Etag 来确保该资源不存在。

默认情况下，Azure DNS PowerShell 使用 Etag 来阻止对区域和记录集的并发更改。 可选 -Overwrite 开关可用于取消 Etag 检查，这种情况下会覆盖发生的所有并发更改。

Etag 是在 Azure DNS REST API 级别使用 HTTP 标头指定的。 下表给出了它们的行为：

标头 行为
无 PUT 始终成功（没有 Etag 检查）
If-match <etag> 只有当资源存在并且 Etag 匹配时，PUT 才会成功
If-match * 只有当资源存在时，PUT 才会成功
If-none-match * 只有当资源不存在时，PUT 才会成功

限制

使用 Azure DNS 时，以下默认限制适用：

公共 DNS 区域

资源 限制
每个订阅的公共 DNS 区域数 250 1
每个公共 DNS 区域的记录集数 10,000 1
公共 DNS 区域中每个记录集的记录数 20
单个 Azure 资源的别名记录数 20

1如果需要增加这些限制，请与 Azure 支持部门联系。

后续步骤