Microsoft AZ-700: Azure DNS 与名称解析 — 学习指南

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

属于 Microsoft Azure Network Engineer AZ-700 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

Azure DNS：公共区域、私有区域和权衡取舍

Azure 同时提供公共 DNS 托管和与虚拟网络平面紧密集成的私有 DNS 解析。在它们之间进行选择需要权衡范围、控制、成本和运营开销。公共 Azure DNS 区域（托管在 Azure DNS 中）适用于面向互联网的名称，并受益于全球任播终结点、可预测的 API 驱动管理以及按查询量扩展的能力。私有 DNS 区域允许您创建仅解析为已链接 VNet 内部私有 IP 地址的区域名称；它们消除了为 Azure 内部名称解析而运行和维护 DNS VM 的需要，并且在与某些 PaaS 私有终结点集成时支持自动记录管理。主要的权衡在于控制：自定义 DNS 服务器（如 Windows DNS、BIND）提供了绝对的灵活性——例如条件转发、高级策略和与 AD 集成的 SRV/CNAME 行为——但代价是 VM/管理开销和需要承担的弹性责任。性能选择归结为延迟与成本的权衡：托管的 Azure DNS 服务减少了维护工作，并为公共查询提供了全球解析速度；而中心辐射型网络中的 DNS 转发器或解析器设备可以提高混合环境的性能并强制执行策略，但会增加计算和可用性成本。常见的陷阱包括：忘记将私有 DNS 区域链接到每个需要解析的 VNet，在将名称从本地迁移到 Azure 时未能迁移委派，以及在没有显式 DNS 记录或转发的情况下期望自动实现公共到私有的分离域 (split-horizon) 行为。

Azure DNS (公共): 全球任播，托管 API，按区域/查询计费。
Private DNS zones: VNet 范围的解析，为支持的 PaaS 自动创建私有记录。
App Gateway WAF_v2: 推荐用于现代 WAF 功能和 v2 扩展模型。
Azure Firewall (Standard/Policy): 中央 DNS 代理选项；增加成本但能集中化策略。
自定义 DNS (基于 VM): 最大控制权，更高的运维和可用性成本。

私有 DNS 区域、私有终结点记录和命名策略

当您将公共托管的服务转换为私有终结点或将服务器迁移到 Azure 时，DNS 成为协调点。私有终结点在私有 DNS 区域中注册 NIC 级别的 A 记录，这些记录必须与您希望客户端使用的公共 FQDN 相匹配；正确的模式是创建镜像公共命名空间（例如 contoso.com）的私有区域，或使用特定于服务的 privatelink 区域（用于平台服务），然后启用自动注册或手动创建 A/CNAME 记录，将 FQDN 映射到终结点的私有 IP。范围至关重要：将私有区域链接到单个 VNet 会将解析限制在该 VNet 内；中心辐射型 (hub-and-spoke) 设计则要求将该区域链接到所有分支 (spoke)，或者使用从分支到中心解析器的 DNS 转发。一个典型的迁移陷阱是，公共 DNS 仍指向旧的本地 IP，而 Azure 客户端却解析到私有 IP；为避免“裂脑”混淆，应规划清晰的切换步骤——仅在私有 DNS 和转发验证通过后才更新公共记录，或者使用分离域命名法，为同一名称设置一个显式的私有区域。证书和主机头必须保持一致：如果您希望 Application Gateway 对私有后端执行端到端 TLS，请确保后端证书的 CN/SAN 与网关作为 Host 标头发送的主机名相匹配；否则后端 TLS 将会失败。

Azure Private Resolver 和混合名称解析模式

Azure Private Resolver 实现了在 Azure VNet 和本地网络之间进行托管的、可扩展的 DNS 转发，而无需自己拥有 DNS VM。设计模式通常将解析器终结点放置在中心 VNet 中：入站终结点接收来自本地（通过 VPN/ExpressRoute）对 Azure 私有区域的查询，而出站终结点则将 Azure 对仅内部名称的查询转发到本地 DNS 服务器。解析器规则集为特定命名空间定义条件转发（例如，contoso.internal → 本地 DNS IP），并可与 VNet 关联；对于全球企业部署，您可以在中心 VNet 集中管理规则，并将来自各分支的流量通过对等连接或路由发送到中心解析器。性能与成本的权衡包括：为了弹性和低延迟而在多个区域预配多个入站终结点（这会增加成本），或者接受单个区域的解析器终结点并使用对等连接，但要承受更高的跨区域延迟。常见的陷阱有：未更新本地的条件转发器以指向解析器的入站 IP；错误配置网络安全组 (NSG) 规则，导致发往解析器终结点的 DNS TCP/UDP 53 端口被阻止；以及想当然地认为 Azure 提供的 DNS (168.63.129.16) 会转发到本地——条件转发需要显式的解析器配置。

DNS 端口: 典型的解析和区域传送必须允许 53 UDP 和 53 TCP 端口。
解析器终结点: 部署在中心 VNet 中；确保 NSG 和防火墙允许入站 DNS 流量。

自定义 DNS 服务器、DNS 代理和运维陷阱

当需要 Active Directory 集成、复杂的条件转发或高级 DNS 策略时，使用自定义 DNS 服务器（如 Windows DNS 域控制器或 Linux BIND）仍然是合理的；然而，它们也带来了运维责任——包括补丁、高可用性 (HA) 集群、备份和扩展。能够减少运维工作的替代方案包括：用于 Azure 内部解析的 Azure Private DNS 区域，以及用于集中转发策略的 Azure Private Resolver 或 Azure Firewall DNS 代理。DNS 代理（如 Azure Firewall DNS 代理功能或第三方 NVA）可以拦截 DNS 请求并将其转发到选定的解析器，这简化了策略和日志记录，但可能会增加单点故障和额外的延迟。关键的设计决策包括：是选择在中心（hub）中使用基于 VM 的转发器（成本较低，维护成本较高），还是使用 Azure Private Resolver（托管服务，扩展性更好）；为了延迟和弹性，需要跨区域部署多少个解析器终结点；以及是否启用私有终结点 DNS 的自动注册。工程师常犯的错误包括：仅依赖 VNet 对等连接进行 DNS 解析（对等连接不会自动共享 Private DNS 区域）；忘记授予私有终结点自动注册 DNS 记录的权限；以及在通过网关实现端到端 TLS 时忽略验证证书链——这些都会在生产环境中破坏名称解析或安全连接。

实践问题：用例场景

场景：Fabrikam Inc. 运营着一个多区域的中心辐射型（hub-and-spoke）Azure 网络。位于 East US 的中心（hub）包含 Azure Firewall (Standard)，并且一个 Traffic Manager 配置文件将互联网用户路由到两个区域中的 Application Gateway WAF_v2 实例。两个 App Service 实例托管 www.fabrikam.com，它们都从本地迁移而来，并在其各自区域的辐射（spoke）网络中配置了私有终结点。

挑战：迁移后，本地客户端和 Azure 辐射（spoke）网络必须能将 www.fabrikam.com 解析到 App Service 的私有终结点；Application Gateway 必须保留主机头以实现端到端 TLS；并且 DNS 解析必须跨区域具备弹性。

推荐方法：

在中心（hub）部署一个名为 fabrikam.com 的 Azure Private DNS 区域，并将其链接到两个区域的辐射 VNet 和中心 VNet；为 www.fabrikam.com 添加指向私有终结点 IP 的 A 记录（或为 App Service 私有终结点启用自动注册）。
在中心（hub）部署 Azure Private Resolver 入站终结点（如果需要弹性，可每个区域部署一个），并配置本地条件转发器，将对 fabrikam.com 的查询转发到该解析器的入站 IP。
配置 Application Gateway WAF_v2 的 HTTP 设置，在 443 端口上使用 HTTPS，将后端主机头设置为 www.fabrikam.com，并确保后端健康探测使用 HTTPS，且其主机头与证书的 CN/SAN 匹配。
通过从本地和辐射网络运行 DNS 查询进行验证，确保它们返回私有 IP；并通过检查证书的 CN/SAN 和探测成功来验证 Application Gateway 的端到端 TLS。

理由：将私有 DNS 和解析器功能集中在中心（hub）可提供单一事实来源，并简化混合条件转发；将私有区域链接到所有 VNet，并确保网关使用正确的主机头，可以为端到端 TLS 保留证书验证，从而在运维可管理性、性能和弹性之间取得平衡。

← 混合网络 · 所有领域 · 网络安全 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →