我们只有一个虚拟networking，在Azure上只有一台云服务器。 这个虚拟networking有多个服务器节点 – 包括Windows机器和一些Linux机器。 其中一台Windows机器托pipe本地DNS服务器，用于在虚拟networking中进行名称parsing。 所有节点都使用DNS选项创build，以便本地DNS作为其DNS注册到节点中。 此外，虚拟networking设置已更新，以包括此DNS服务器（172.16.0.4）作为VN的DNS。
我的Windows机器能够正常工作 – 在新的configuration或重新启动时，DNS会自动更新以反映该机器的新IP（如果有的话）。
但是，Linux机器根本没有在本地DNS上注册。 Linux节点能够通过使用本地DNS（172.16.0.4）parsingWindows节点IP，但是无法通过名称parsing到达其他Linux节点。
我尝试更新resolvconf / resolvconf.d / tail文件，并添加了一个“search”条目，并重新启动。 还尝试将FQDN提供到Linux服务器的主机名文件中。 我注意到resolv.conf仍然有一个“search reddog.microsoft.com”string。 这表明所使用的DNS后缀仍旧是旧的，即使VN内有新的本地DNS服务器可用。 resolv.conf如下所示：
nameserver 172.16.0.4 search reddog.microsoft.com 据我所知，这个问题的根本原因是，Azure DHCP服务器应该发送DDNS请求到这个本地DNS（已经适当注册为VN级别的DNS）来更新任何新节点或重新启动的节点的loggingVN。 但Azure DHCP似乎不会将这些DDNS请求发送到DNS。 我错过了什么？
我最初的想法是，这是你的DNS服务器接受来自Linux服务器的注册问题，而不是它在那里得到指示的问题。 有一件事要检查，你的DNS区域configuration为接受不安全的更新？ 这是必需的，因为Linux服务器将无法通过身份validation来更新DNS。
您可以通过添加以下几行来修改DHCP客户端的configuration：
supersede domain-name "your.domainname.com"; supersede domain-search "your.domainname.com"; supersede search "your.domainname.com";
通常情况下，您可以在/etc/dhcp/dhclient.conf文件中findDHCPconfiguration。 在/etc/内searchdhclient来find正确的。
其他可能的解决scheme： https ： //superuser.com/questions/110808/how-can-i-add-additional-search-domains-to-the-resolv-conf-created-by-dhclient-i
更不用说每次服务器重启时，/etc/resolv.conf的内容都重置为Azure默认值。 所以，即使您更改了它，下次重新启动时，也会返回到search域reddog.microsoft.com以及默认的Azure域名服务器。