借我一双慧眼吧——浅析Azure内置DNS

  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来实现:

总结

  虽然Azure Private DNS在Azure China还未提供,但是Azure已经内置了一套对VM的DNS解析规则。充分了解其工作方式,可以大大简化对VM的网络管理。
  在实际运维中也需注意,规则的灵活性可能会导致事故,所以一定要有完善的文档管理、变更机制以保证生产的正常。