Compartir a través de

Azure 虚拟网络中资源的名称解析

Azure 可用于托管 IaaS、PaaS 和混合解决方案。 为了推动虚拟机(VM)和虚拟网络中部署的其他资源之间的通信,可能需要允许它们相互通信。 使用易于记住和不变的名称可简化通信过程,而不是依赖于 IP 地址。

当部署在虚拟网络中的资源需要将域名解析到内部 IP 地址时,它们可以使用以下四种方法之一:

使用的名称解析类型取决于资源需要以怎样的方式进行相互通信。 下表说明了方案和相应的名称解析解决方案:

注意

Azure DNS 专用区域是首选的解决方案,可让你灵活管理 DNS 区域和记录。 有关详细信息,请参阅在专用域中使用 Azure DNS

注意

如果使用 Azure 提供的 DNS,则相应的 DNS 后缀会自动应用到虚拟机。 对于所有其他选项,必须使用完全限定的域名 (FQDN),或手动将相应的 DNS 后缀应用到虚拟机。

方案 解决方案 DNS 后缀
位于相同虚拟网络的 VM 或位于相同云服务的 Azure 云服务角色实例之间的名称解析。 Azure DNS 专用区域Azure 提供的名称解析 主机名或 FQDN
位于不同虚拟网络的 VM 或位于不同云服务的角色实例之间的名称解析。 Azure DNS 专用区域或客户管理的 DNS 服务器(在虚拟网络之间转发查询,以通过 Azure(DNS 代理)进行解析)。 请参阅使用自己的 DNS 服务器进行名称解析 仅 FQDN
通过 Azure 应用服务(Web 应用、函数或自动程序)实现的名称解析:对同一虚拟网络中的角色实例或 VM 使用虚拟网络集成。 客户托管的 DNS 服务器,该服务器在虚拟网络之间转发查询,并由 Azure 进行解析(DNS 代理)。 请参阅使用自己的 DNS 服务器进行名称解析 仅 FQDN
从应用服务 Web 应用到同一虚拟网络中 VM 之间的名称解析。 客户托管的 DNS 服务器,该服务器在虚拟网络之间转发查询,并由 Azure 进行解析(DNS 代理)。 请参阅使用自己的 DNS 服务器进行名称解析 仅 FQDN
从应用服务 Web 应用到不同虚拟网络中 VM 之间的名称解析。 客户托管的 DNS 服务器,该服务器在虚拟网络之间转发查询,并由 Azure 进行解析(DNS 代理)。 请参阅使用自己的 DNS 服务器进行名称解析 仅 FQDN
解析来自 Azure 中 VM 或角色实例的本地计算机和服务名称。 客户托管的 DNS 服务器(例如本地域控制器、本地只读域控制器或使用区域传送同步的 DNS 辅助服务器)。 请参阅使用自己的 DNS 服务器进行名称解析 仅 FQDN
解析本地计算机中的 Azure 主机名。 将查询转发到相应虚拟网络中客户托管的 DNS 代理服务器,该代理服务器将查询转发到 Azure 进行解析。 请参阅使用自己的 DNS 服务器进行名称解析 仅 FQDN
针对内部 IP 的反向 DNS。 Azure DNS 专用区域Azure 提供的名称解析使用你自己的 DNS 服务器的名称解析 不适用
位于不同云服务(而非虚拟网络)中的 VM 或角色实例之间的名称解析。 不适用。 不同云服务中的 VM 和角色实例之间的连接在虚拟网络外部不受支持。 不适用

Azure 提供的名称解析

Azure 提供的名称解析仅提供基本的权威 DNS 功能。 如果使用 Azure 提供的 DNS,Azure 会管理 DNS 区域名称和记录。 无法控制 DNS 区域名称或 DNS 记录的生命周期。 如果需要对虚拟网络使用全功能 DNS 解决方案,可以结合使用 Azure DNS 专用区域客户管理的 DNS 服务器

除公共 DNS 名称解析之外,Azure 还为驻留在相同虚拟网络或云服务中的 VM 和角色实例提供内部名称解析。 云服务中的 VM 和实例共享相同的 DNS 后缀,因此仅使用主机名便可。 但在使用经典部署模型部署的虚拟网络中,不同云服务具有不同的 DNS 后缀。 在这种情况下,需要使用 FQDN 解析不同云服务的名称。 在使用 Azure 资源管理器部署模型部署的虚拟网络中,某个虚拟网络中的所有虚拟机的 DNS 后缀是一致的,因此无需 FQDN。 DNS 名称可分配给 VM 和网络接口。 虽然 Azure 提供的名称解析无需任何配置,但并不适合所有部署方案,详见上表。

注意

在使用云服务 Web 和辅助角色的情况下,还可以使用 Azure 服务管理 REST API 访问角色实例的内部 IP 地址。 有关详细信息,请参阅服务管理 REST API 参考。 地址基于角色名称和实例编号。

功能

Azure 提供的名称解析包括以下功能:

  • 易于使用。 不需要任何配置。

  • 高可用性。 无需创建和管理你自己的 DNS 服务器的群集。

  • 可以将该服务与自己的 DNS 服务器结合使用,从而解析本地主机名和 Azure 主机名。

  • 可以在同一云服务中的 VM 和角色实例之间使用名称解析,无需 FQDN。

  • 可以在使用 Azure 资源管理器部署模型的虚拟网络中的 VM 之间使用名称解析,无需 FQDN。 经典部署模型中的虚拟网络需要使用 FQDN 来解析不同云服务中的名称。

  • 可以使用最能描述部署的主机名,而不是使用自动生成的名称。

注意事项

使用 Azure 提供的名称解析时要注意的问题:

  • 无法修改 Azure 创建的 DNS 后缀。

  • DNS 查找范围限定为虚拟网络。 无法从其他虚拟网络解析针对一个虚拟网络创建的 DNS 名称。

  • 无法手动注册你自己的记录。

  • 不支持 WINS 和 NetBIOS。 在 Windows 资源管理器中看不到你的 VM。

  • 主机名必须符合 DNS。 名称只能使用 0-9、a-z 和“-”,并且不能以“-”开头或结尾。

  • DNS 查询流量按照 VM 进行限制。 限制不会影响大多数应用程序。 如果遵循请求限制,请确保启用客户端缓存。 有关详细信息,请参阅 DNS 客户端配置

  • 为虚拟网络中的每个虚拟机使用不同的名称,以避免 DNS 解析问题。

  • 在经典部署模型中,每个虚拟网络仅注册前 180 个云服务中的 VM。 此限制不适用于 Azure 资源管理器中的虚拟网络。

  • Azure DNS IP 地址为 168.63.129.16。 此地址是静态 IP 地址,不会更改。

反向 DNS 注意事项

所有基于 Azure 资源管理器的虚拟网络都支持 VM 的反向 DNS。 当你启动 VM 时,会自动向 DNS 添加 [vmname].internal.chinacloudapp.cn 格式的 Azure 管理的反向 DNS (PTR) 记录;停止(解除分配)VM 时会移除该记录。 请参阅以下示例:

C:\>nslookup -type=ptr 10.11.0.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.0.11.10.in-addr.arpa  name = myeastspokevm1.internal.chinacloudapp.cn

internal.chinacloudapp.cn 反向 DNS 区域由 Azure 管理,无法直接查看或编辑。 对 [vmname].internal.chinacloudapp.cn 格式的 FQDN 执行正向查找会将其解析为分配给虚拟机的 IP 地址。

如果 Azure DNS 专用区域 通过 虚拟网络链接 链接到虚拟网络,并且在该链接上已启用 自动注册,反向 DNS 查询会返回两条记录。 一条记录的格式为 [vmname].[privatednszonename],另一条记录的格式为 [vmname].internal.chinacloudapp.cn。 请参阅以下示例:

C:\>nslookup -type=ptr 10.20.2.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.2.20.10.in-addr.arpa  name = mywestvm1.internal.chinacloudapp.cn
4.2.20.10.in-addr.arpa  name = mywestvm1.azure.contoso.com

返回两条 PTR 记录时(如之前所示),对任一 FQDN 执行正向查找都会返回 VM 的 IP 地址。

反向 DNS 查找的范围限定为给定的虚拟网络,即使该虚拟网络已对等互连到其他虚拟网络。 对位于对等互连虚拟网络中的虚拟机的 IP 地址执行反向 DNS 查询会返回 NXDOMAIN

注意

反向 DNS (PTR) 记录不会存储在正向专用 DNS 区域中。 反向 DNS 记录存储在反向 DNS (in-addr.arpa) 区域中。 不可查看或编辑与 VNet 关联的默认反向 DNS 区域。

可以在虚拟网络中禁用反向 DNS 功能,方法是使用 Azure DNS 专用区域创建你自己的反向查找区域,然后将此区域链接到虚拟网络。 例如,如果虚拟网络的 IP 地址空间是 10.20.0.0/16,则你可以创建空的专用 DNS 区域 20.10.in-addr.arpa,并将其链接到该虚拟网络。 此区域替代虚拟网络的默认反向查找区域。 此区域为空。 反向 DNS 会返回 NXDOMAIN,除非手动创建这些条目。

不支持自动注册 PTR 记录。 如果要创建条目,请手动输入。 如果已为其他区域启用自动注册,必须在虚拟网络中禁用自动注册。 此限制是由于已启用自动注册时仅允许链接一个专用区域的 限制。 请参阅专用 DNS 快速入门指南,详细了解如何创建专用 DNS 区域并将其链接到虚拟网络。

注意

由于 Azure DNS 专用区域是全球性的,你可以创建反向 DNS 查找以跨越多个虚拟网络。 为此,请创建一个 Azure DNS 专用区域(一个 in-addr.arpa 区域)用于反向查找,并将其链接到虚拟网络。 必须手动管理 VM 的反向 DNS 记录。

DNS 客户端配置

本部分介绍客户端缓存和客户端重试。

客户端缓存

不是每个 DNS 查询都需要跨网络发送。 通过解析本地缓存中的重复性 DNS 查询,客户端缓存有助于减少延迟和提高网络信号的恢复能力。 DNS 记录包含生存时间 (TTL) 机制,这允许缓存尽可能长时间存储记录,而不影响记录刷新。 因此,客户端缓存适用于大多数情况。

默认 Windows DNS 客户端具有内置的 DNS 缓存。 默认情况下,某些 Linux 发行版不包括缓存。 如果没有本地缓存,请向每个 Linux VM 添加 DNS 缓存。

有许多不同的 DNS 缓存包可用(例如 dnsmasq)。 下面介绍如何在最常见的发行版上安装 dnsmasq:

RHEL(使用 NetworkManager)

  1. 使用以下命令安装 dnsmasq 包:

    sudo yum install dnsmasq
    
  2. 使用以下命令启用 dnsmasq 服务:

    systemctl enable dnsmasq.service
    
  3. 使用以下命令启动 dnsmasq 服务:

    systemctl start dnsmasq.service
    
  4. 使用文本编辑器将 prepend domain-name-servers 127.0.0.1; 添加到 /etc/dhclient-eth0.conf

  5. 使用以下命令重启网络服务:

    service network restart
    

注意

dnsmasq 包只是适用于 Linux 的众多 DNS 缓存中的一个。 在使用之前,请检查其是否适合特定需求,且没有安装其他缓存。

客户端重试

DNS 主要是一个 UDP 协议。 因为 UDP 协议无法保证消息传递,所以重试逻辑在DNS 协议本身中处理。 每个 DNS 客户端(操作系统)可能会表现出不同的重试逻辑,具体取决于创建者的偏好:

  • Windows 操作系统在 1 秒后重试,然后再在 2 秒后、4 秒后和额外 4 秒后再次重试。
  • 默认 Linux 设置在 5 秒后重试。 我们建议将重试规范更改为 5 次,每隔 1 秒一次。

使用 cat /etc/resolv.conf 检查 Linux VM 上的当前设置。 查看“options”行,例如:

options timeout:1 attempts:5

resolv.conf 文件自动生成,不应进行编辑。 添加 options 行的具体步骤因发行版而异:

RHEL(使用 NetworkManager)

  1. 使用文本编辑器将行 RES_OPTIONS="options timeout:1 attempts:5" 添加到文件 /etc/sysconfig/network-scripts/ifcfg-eth0

  2. 使用以下命令重启 NetworkManager 服务:

    systemctl restart NetworkManager.service
    

使用自己的 DNS 服务器的名称解析

本部分介绍 VM、角色实例以及 Web 应用。

VM 和角色实例

Azure 提供的功能可能无法满足名称解析的需求。 例如,可能需要使用 Microsoft Windows Server Active Directory 域来解析虚拟网络之间的 DNS 名称。 为了涵盖这些方案,Azure 允许你使用自己的 DNS 服务器。

虚拟网络中的 DNS 服务器可将 DNS 查询转发到 Azure 的递归解析程序。 此过程使你能够解析该虚拟网络内的主机名。 例如,在 Azure 中运行的域控制器 (DC) 可以响应自身域的 DNS 查询,而将所有其他查询转发到 Azure。 转发查询,VM 就可以(通过 DC)查看本地资源以及(通过转发器)查看 Azure 提供的主机名。 可以通过虚拟 IP 168.63.129.16 访问 Azure 中的递归解析程序。

重要

如果在此设置中使用 VPN 网关以及 VNet 上的自定义 DNS 服务器 IP,还需要将 Azure DNS IP (168.63.129.16) 添加到列表中来保持服务不中断。

DNS 转发还可用于在虚拟网络之间进行 DNS 解析,可以通过本地计算机来解析 Azure 提供的主机名。 若要解析 VM 的主机名,DNS 服务器 VM 必须驻留在同一虚拟网络中,并且必须配置为将主机名查询转发到 Azure。 由于 DNS 后缀在每个虚拟网络中是不同的,因此可使用条件性转发规则将 DNS 查询发送到正确的虚拟网络进行解析。 下图显示了两个虚拟网络和一个本地网络使用本方法在虚拟网络之间进行 DNS 解析。 DNS 转发器示例可在 Azure 快速入门模板库GitHub 中获取。

注意

角色实例可对同一虚拟网络中的 VM 执行名称解析, 方法是使用由 VM 主机名和 internal.chinacloudapp.cn DNS 后缀组成的 FQDN。 但是,在这种情况下,仅当角色实例在角色架构(.cscfg 文件)中定义了 VM 名称时,名称解析才会成功。 <Role name="<role-name>" vmName="<vm-name>">

需要在另一个虚拟网络中执行 VM 名称解析的角色实例(使用 internal.chinacloudapp.cn 后缀的 FQDN)必须使用本部分所述的方法(在两个虚拟网络之间进行自定义 DNS 服务器转发)。

虚拟网络之间的 DNS 示意图

使用 Azure 提供的名称解析时,Azure 动态主机配置协议 (DHCP) 会为每个 VM 提供内部 DNS 后缀 (.internal.chinacloudapp.cn)。 此后缀可实现主机名解析,因为主机名记录位于 internal.chinacloudapp.cn 区域中。 当你使用自己的名称解析解决方案时,不会向 VM 提供此后缀,因为该后缀会干扰其他 DNS 体系结构(例如已加入域的方案)。 相反,Azure 会提供无法正常运行的占位符(reddog.microsoft.com)

如果需要,可以使用 PowerShell 或 API 确定内部 DNS 后缀:

如果不想将查询转发到 Azure,请提供自己的 DNS 解决方案。

如果你提供自己的 DNS 解决方案,该解决方案需要:

  • 提供合适的主机名解析(例如,通过 DDNS)。 如果使用 DDNS,则可能需要禁用 DNS 记录清理。 Azure DHCP 租约时间很长,进行清理可能会导致 DNS 记录过早删除。

  • 提供适当的递归式解析来解析外部域名。

  • 可以从其所服务的客户端进行访问(端口 53 上的 TCP 和 UDP),并可访问 Internet。

  • 禁止从 Internet 进行访问,减少外部代理带来的威胁。

注意

  • 为获得最佳性能,在将 Azure VM 用作 DNS 服务器时,应禁用 IPv6。
  • NSG 充当 DNS 解析程序终结点的防火墙。 你应修改或替代你的 NSG 安全规则,以允许 UDP 端口 53(也可选择 TCP 端口 53)访问 DNS 侦听器终结点。 在网络中设置自定义 DNS 服务器后,通过端口 53 的流量将绕过子网的 NSG。

重要

如果使用 Windows DNS 服务器作为将 DNS 请求转发到 Azure DNS 服务器的自定义 DNS 服务器,请确保将“转发超时”值增大至 4 秒以上,使 Azure 递归 DNS 服务器能够执行正确的递归操作。

有关此问题的详细信息,请参阅转发器和条件转发器解析超时

此项建议同样适用于转发超时值为 3 秒或更低的其他 DNS 服务器平台。

不这样做可能会导致使用公共 IP 地址解析专用 DNS 区域记录。

Web 应用

假设你需要执行从使用应用服务生成的、已链接到某个虚拟网络的 Web 应用到同一虚拟网络中的 VM 的名称解析。 除了设置具有 DNS 转发程序(可向 Azure 转发查询)的自定义 DNS 服务器(虚拟 IP 为 168.63.129.16)以外,还需要执行以下步骤:

根据将应用与虚拟网络集成中所述,为 Web 应用启用虚拟网络集成(如果尚未启用)。

如果需要执行从链接到 VNet 的 Web 应用(通过应用服务生成)到另一 VNet(未链接到同一专用区域)中的 VM 的名称解析,请在这两个 VNet 上使用自定义 DNS 服务器。

若要使用自定义 DNS 服务器,请执行以下操作:

  • 在某个也可向 Azure 中的递归解析程序(虚拟 IP 为 168.63.129.16)转发查询的 VM 上的目标虚拟网络中设置 DNS 服务器。 DNS 转发器示例可在 Azure 快速入门模板库GitHub 中获取。

  • 在某个 VM 上的源虚拟网络中设置 DNS 转发程序。 将此 DNS 转发器配置为向目标虚拟网络中的 DNS 服务器转发查询。

  • 在源虚拟网络的设置中配置源 DNS 服务器。

  • 遵照将应用与虚拟网络集成中的说明,为 Web 应用启用虚拟网络集成以链接到源虚拟网络。

指定 DNS 服务器

当你使用自己的 DNS 服务器时,Azure 允许为每个虚拟网络指定多个 DNS 服务器。 也可以针对每个网络接口(适用于 Azure 资源管理器)或云服务(适用于经典部署模型)指定多个 DNS 服务器。 为网络接口或云服务指定 DNS 服务器时,其优先级高于为虚拟网络指定的 DNS 服务器。

注意

不应直接在 VM 中编辑网络连接属性,例如 DNS 服务器 IP。 这是因为,在更换虚拟网络适配器后,可能会在服务修复过程中擦除这些属性。 这同时适用于 Windows VM 和 Linux VM。

使用 Azure 资源管理器部署模型时,可为虚拟网络和网络接口指定 DNS 服务器。 有关详细信息,请参阅管理虚拟网络管理网络接口

注意

如果为虚拟网络选择自定义 DNS 服务器,则必须至少指定一个 DNS 服务器 IP 地址;否则,虚拟网络将忽略配置,而改用由 Azure 提供的 DNS。

注意

如果更改已部署的虚拟网络或虚拟机的 DNS 设置,要使新的 DNS 设置生效,必须对虚拟网络中所有受影响的 VM 执行 DHCP 租约续订。 对于运行 Windows OS 的 VM,可以直接在 VM 中键入 ipconfig /renew 来完成此操作。 步骤因 OS 而异。 请参阅 OS 类型的相关文档。

后续步骤

Azure 资源管理器部署模型