在 Azure Stack Hub 中使用 iDNS

iDNS 是一种 Azure Stack Hub 网络功能，可用于解析外部 DNS 名称（例如 https://www.bing.com.)），它还让你能够注册内部虚拟网络名称。 如此一来，就可按名称（而非 IP 地址）解析同一虚拟网络上的虚拟机 (VM)。 使用此方法，不再需要提供自定义 DNS 服务器条目。 有关 DNS 的详细信息，请参阅 Azure DNS 概述。

iDNS 有什么作用？

使用 Azure Stack Hub 中的 iDNS 可以获得以下功能，而无需指定自定义 DNS 服务器条目：

• 适用于租户工作负荷的共享 DNS 名称解析服务。
• 适用于租户虚拟网络内的名称解析和 DNS 注册的权威 DNS 服务。
• 从租户 VM 解析 Internet 名称的递归 DNS 服务。 租户不再需要指定自定义 DNS 条目，就可以解析 Internet 名称（例如 www.bing.com.）

你仍然可以沿用自己的 DNS，也可以使用自定义 DNS 服务器。 但是，通过使用 iDNS，你可以解析 Internet DNS 名称并连接到同一虚拟网络中的其他 VM，而无需创建自定义 DNS 条目。

iDNS 不做什么？

iDNS 不允许针对可从虚拟网络外部解析的名称创建 DNS 记录。

在 Azure 中，可以选择指定与公共 IP 地址关联的 DNS 名称标签。 你可以选择标签（前缀），但 Azure 会根据创建公共 IP 地址所在的区域选择后缀。

如上图所示，Azure 会在 DNS 中为 chinanorth.chinacloudapp.cn 区域下指定的 DNS 名称标签创建“A”记录。 前缀和后缀组合起来构成完全限定域名 (FQDN)，此域名可以从公共 Internet 上的任何位置解析。

Azure Stack Hub 仅支持将 iDNS 用于内部名称注册，因此它无法执行以下操作：

• 在现有的托管 DNS 区域（例如，local.azurestack.external）下创建 DNS 记录。
• 创建 DNS 区域（例如 Contoso.com）。
• 在你自己的自定义 DNS 区域下创建记录。
• 支持购买域名。

演示 iDNS 的工作原理

虚拟网络中 VM 的所有主机名都作为 DNS 资源记录存储在同一区域，但是，在这些 VM 自有的唯一区间，这些主机名定义为 GUID，该 GUID 与作为 VM 部署目标的 SDN 基础结构中的 VNET ID 相关。 租户 VM 的完全限定域名 (FQDN) 由计算机名以及虚拟网络的 DNS 后缀字符串（采用 GUID 格式）组成。

以下简单实验演示了相关的工作原理。 我们在一个 VNet 中创建了 3 个 VM，并在另一个 VNet 中创建了另一个 VM：

可以执行一些名称解析测试，以更好地了解 iDNS 的工作原理：

在 VM-A1 (Linux VM) 中：查找 VM-A2。 可以看到，已添加 VNetA 的 DNS 后缀，并且名称已解析为专用 IP：

carlos@VM-A1:~$ nslookup VM-A2
Server:         127.0.0.53
Address:        127.0.0.53#53
 
Non-authoritative answer:
Name:   VM-A2.e71e1db5-0a38-460d-8539-705457a4cf75.internal.lnv1.azurestack.local
Address: 10.0.0.6

在不提供 FQDN 的情况下查找 VM-A2-Label 将会失败，这在意料之中：

carlos@VM-A1:~$ nslookup VM-A2-Label
Server:         127.0.0.53
Address:        127.0.0.53#53
 
** server can't find VM-A2-Label: SERVFAIL

如果提供 DNS 标签的 FQDN，则名称将解析为公共 IP：

carlos@VM-A1:~$ nslookup VM-A2-Label.lnv1.cloudapp.azscss.external
Server:         127.0.0.53
Address:        127.0.0.53#53
 
Non-authoritative answer:
Name:   VM-A2-Label.lnv1.cloudapp.azscss.external
Address: 172.31.12.76

尝试解析 VM-B1（位于不同的 VNet 中）将会失败，因为此记录不在此区域中。

carlos@caalcobi-vm4:~$ nslookup VM-B1
Server:         127.0.0.53
Address:        127.0.0.53#53
 
** server can't find VM-B1: SERVFAIL

使用 VM-B1 的 FQDN 没有作用，因为此记录来自另一个区域。

carlos@VM-A1:~$ nslookup VM-B1.e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local
Server:         127.0.0.53
Address:        127.0.0.53#53
 
** server can't find VM-B1.e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local: SERVFAIL

如果使用 DNS 标签的 FQDN，则可成功解析：

carlos@VM-A1:~$ nslookup VM-B1-Label.lnv1.cloudapp.azscss.external
Server:         127.0.0.53
Address:        127.0.0.53#53
 
Non-authoritative answer:
Name:   VM-B1-Label.lnv1.cloudapp.azscss.external
Address: 172.31.12.57

在 VM-A3 (Windows VM) 中。 请注意权威与非权威应答之间的差异。

内部记录：

C:\Users\carlos>nslookup
Default Server:  UnKnown
Address:  168.63.129.16
 
> VM-A2
Server:  UnKnown
Address:  168.63.129.16
 
Name:    VM-A2.e71e1db5-0a38-460d-8539-705457ª4cf75.internal.lnv1.azurestack.local
Address:  10.0.0.6

外部记录：

> VM-A2-Label.lnv1.cloudapp.azscss.external
Server:  UnKnown
Address:  168.63.129.16
 
Non-authoritative answer:
Name:    VM-A2-Label.lnv1.cloudapp.azscss.external
Address:  172.31.12.76

概括而言，在以上内容中可以看到：

• 每个 VNet 具有自身的区域，其中包含所有专用 IP 地址的 A 记录，这些记录由 VM 名称和 VNet 的 DNS 后缀（其 GUID）组成。
  • <vmname>.<vnetGUID>.internal.<region>.<stackinternalFQDN>
  • 此过程是自动完成的
• 如果使用公共 IP 地址，则也可以为其创建 DNS 标签。 这些地址的解析方式类似于其他任何外部地址。

• iDNS 服务器是其内部 DNS 区域的权威服务器，并且还在租户 VM 尝试连接到外部资源时，充当公共名称的解析器。 如果存在对外部资源的查询，则 iDNS 服务器会将请求转发到权威 DNS 服务器进行解析。

从实验结果中可以看到，你可以对使用的 IP 进行控制。 如果使用 VM 名称，则会获得专用 IP 地址；如果使用 DNS 标签，则会获得公共 IP 地址。

后续步骤

使用 Azure Stack Hub 中的 DNS