—https://hyblob.blob.core.windows.net/
title: 借我一双慧眼吧——浅析Azure内置DNS
toc: true
tags:

Azure
网络
categories:
网络
Azure
abbrlink: 33701
date: 2019-07-31 10:38:05

Azure已经发布了DNS服务，Azure上的客户可以直接使用该服务创建DNS解析而无需自己安装配置管理DNS服务器，大大方便了使用。即使客户不使用DNS服务，Azure其实也内置了一套为VM服务的DNS。下边就看看内置DNS的使用规则。

DNS解析规则

再同一个资源组、同一个vnet里创建两台VM，虚机名（代指在Azure创建VM给虚机的命名，下同）分别为vm01和vm02。登录后可以看到，默认将虚机名作为了主机名（代指在Guest OS的机器名，下同）：

从vm01直接用ping到vm02：

可以正确的解析vm02。
现在需要确认解析是基于虚机名还是主机名？通过hostname命令将vm02的主机名改为host02：

再次从vm01分别ping虚机名和主机名：

虚机名（vm02）已经找不到，解析已经变成了主机名（host02）。
通过nslookup查找也是同样结果：

这个简单测试可以确认，在Azure默认的VM DNS解析中，是对主机名进行解析。

主机名修改对DNS的影响

众所周知，hostname虽然可以修改主机名，但是并不会发起DNS注册。DNS服务器如何知道VM修改了主机名？在Azure VM里，有一个插件waagent对VM进行配置管理，检查waagent的配置文件（/etc/waagent.conf），可以看到如下参数：

从参数名就能看出，这个参数是对hostname进行监控，如果发现hostname变化就会通告。
再做一个小测试，将该参数修改为n，然后重启waagent服务，再将虚机vm02的主机名从host02修改为vm02，看看DNS解析是否自动修改：

如我们所料，将该参数修改为n后，DSN解析仍为host02，修改主机名不会再影响到DNS解析。
所以如果客户的环境希望能保持DNS解析不受修改主机名的影响，可以通过修改waagent的参数来实现。

虚机状态对DNS的影响

VM的各种状态（OS层面关机、解除分配、删除）会对DNS解析有何影响？下边逐一测试。
vm02在正常开机情况下，从vm01可以解析到vm02的主机名：

从OS层将vm02关机，vm02状态是已停止，从vm01检查vm02的解析，正常：

在Azure层面关机，vm02状态是已取消分配，从vm01检查vm02的解析，无法解析，vm02的解析自动从DNS注销：

现在将vm02正常开机后直接删除，vm02的解析也被注销了：

综上所述，Azure VM的DNS生命周期是在分配资源的状态，与VM自身的开关机无关。当VM的资源被释放（deallocate、删除等）时，VM的DNS解析被注销。

主机名冲突

如果同一个环境里，两台VM被修改为同一个主机名，解析会怎样？
还是新建两台VM，然后主机名分别修改为host01和host02，可以正常解析到对应主机的ip：

现在将vm02的主机名从host02修改为host01，再检查解析：

host02的解析找不到，而host01的解析从之前的vm01的ip（172.19.18.4）变为了host02的ip（172.19.18.6）。
从以上实验可以看出，多台VM的主机名出现冲突时，按照后来者优先的原则，DNS解析到最后一台同名的VM。
这个设计思路是非常合理的，考虑一个场景，当一台业务主机出现故障时，启动一台备机来顶替；这时候需要将所有业务指向备机，这时候只需要将备机的主机名设置为故障机的主机名，DNS就会解析到备机的ip，备机直接“抢到”所有的流量，而无需再做其他配置。
现在去将vm02解除分配，解析是否会“飘回”vm01？测试一下。
从Azure界面管掉vm02（取消分配）：

再去vm01上检查host01：

所以当正常解析的VM由于各种原因从DNS注销后，DNS并不会自动解析到同主机名的VM。
这种设计是为了避免出现不可知故障。例如，当环境里有多台同主机名的VM，正常解析并使用的VM下线后，自动解析到剩下的哪台主机？要是解析到了错误的主机，就会影响业务，所以这时候需要人工介入处理。
处理方法很简单，既然修改主机名就可以导致DNS重新注册，那么我们将需要解析的主机随便修改一下主机名（主要不要导致冲突），再改回正确的主机名即可：

进一步的研究

waagent的影响

前边说了，VM的waagent配置里有对hostname的监控，VM取消分配并重新分配（以下简重置VM）后将重新注册DNS。进一步看看，如果在waagent配置里禁用对hostname改变的监控，然后修改主机名后重置VM，DNS解析是否会更改。
修改waagent配置文件，重启waagent服务，重命名主机名：

主机名从host01修改为host001.
重置VM后检查解析：

虽然重置了VM，但是解析仍然是host01，而非修改后的主机名host001.
为什么会出现这个情况？检查一下：

重置VM后，修改主机名失效，变回了修改前的主机名host01。
在Linux里，hostname命令只是临时修改主机名，OS重启后就会失效，真正的主机名时保存在/etc/hostname文件里的。做个测试如下：

如图所示，用hostname修改主机名后，/etc/hostname文件的内容并没有变化，所以重启就失效了。
之前的修改为什么可以持久化？原因还是在waagent配置里，当监控hostname的参数设置为y时，用hostname修改主机名，将会把新主机名写入/etc/hostname文件，测试如下：

修改成功。

网络的影响

如果我们检查VM完整主机名，得到信息如下：

主机名后加上了一串后缀。
但是我们不用加后缀也可以ping通另一台VM：

检查另一VM的完整主机名：

可以发现两VM的后缀一样。这是因为在同一个vnet里，DNS解析默认的后缀一致。
根据Azure的设计，vnet之间是不通的，如果要跨vnet通讯，需要做vnet peer互通。
现在创建一个新的VM，命名为vm03，在HyDNSDemoRG-vnet02的vnet：

而原有的vm01（主机名为host01）在HyDNSDemoRG-vnet的vnet：

显然vm01找不到vm03：

现在通过peer将两个vnet打通，通过vm01去ping vm03的ip，可以通讯：

但是用主机名仍然找不到：

检查vm03的完整主机名：

其主机名的后缀与vm01不一样，所以vm01通过不带域名的主机名找不到vm03。
现在通过完整的主机名来查找vm03：

依然找不到。
由此可以看出，Azure默认的DNS只对vnet内部生效，不能跨vnet。如果需要跨vnet使用DNS解析VM，就要通过配置Azure 私有DNS服务，并附加到多个vnet来实现：