Wir haben ein einzelnes virtuelles Netzwerk mit einem einzelnen Cloud-Server auf Azure. Dieses virtuelle Netzwerk hat mehrere Serverknoten – darunter Windows-Rechner und einige Linux-Rechner. Einer der Windows-Rechner hostet einen lokalen DNS-Server zur Namensauflösung innerhalb des virtuellen Netzwerks. Alle Knoten wurden mit der DNS-Option erstellt, sodass der lokale DNS in den Knoten als ihr DNS registriert ist. Außerdem wurden die Einstellungen des virtuellen Netzwerks aktualisiert, um diesen DNS-Server (172.16.0.4) als DNS für das VN einzuschließen.
Meine Windows-Rechner funktionieren einwandfrei – bei einer Neubereitstellung oder einem Neustart wird der DNS automatisch aktualisiert, um die neue IP für diesen Rechner (sofern vorhanden) wiederzugeben.
Die Linux-Rechner sind jedoch überhaupt nicht auf diesem lokalen DNS registriert. Die Linux-Knoten können die IP des Windows-Knotens mithilfe des lokalen DNS (172.16.0.4) auflösen, aber sie können die anderen Linux-Knoten nicht über die Namensauflösung erreichen.
Ich habe versucht, die Datei resolvconf/resolvconf.d/tail zu aktualisieren, einen „search“-Eintrag hinzugefügt und neu gestartet. Außerdem habe ich versucht, den FQDN in die Hostnamendatei des Linux-Servers einzugeben. Mir ist aufgefallen, dass die Datei resolv.conf immer noch die Zeichenfolge „search reddog.microsoft.com“ enthält. Dies deutet darauf hin, dass das verwendete DNS-Suffix immer noch das ältere ist, obwohl innerhalb des VN ein neuer lokaler DNS-Server verfügbar ist. Die Datei resolv.conf sieht folgendermaßen aus:
nameserver 172.16.0.4
search reddog.microsoft.com
So wie ich es verstehe, liegt die Hauptursache dieses Problems darin, dass der Azure DHCP-Server DDNS-Anfragen an diesen lokalen DNS (der ordnungsgemäß als DNS auf VN-Ebene registriert wurde) senden sollte, um Datensätze für jeden neuen oder neu gestarteten Knoten zu aktualisieren, der in diesem VN auftaucht. Aber der Azure DHCP scheint diese DDNS-Anfragen nicht an den DNS zu senden. Was übersehe ich?
Antwort1
Mein erster Gedanke wäre, dass dies ein Problem mit Ihrem DNS-Server ist, der die Registrierung vom Linux-Server akzeptiert, und nicht ein Problem mit der Weiterleitung dorthin. Eine Sache, die Sie überprüfen sollten, ist Ihre DNS-Zone so konfiguriert, dass sie unsichere Updates akzeptiert? Dies ist erforderlich, da die Linux-Server sich nicht authentifizieren können, um DNS zu aktualisieren.
Antwort2
Sie können die Konfiguration Ihres DHCP-Clients ändern, indem Sie die folgenden Zeilen hinzufügen:
supersede domain-name "your.domainname.com";
supersede domain-search "your.domainname.com";
supersede search "your.domainname.com";
Normalerweise finden Sie die DHCP-Konfiguration in /etc/dhcp/dhclient.confder Datei. Suchen Sie dhclientdarin /etc/nach der richtigen.
Andere mögliche Lösungen:https://superuser.com/questions/110808/wie-kann-ich-zusätzliche-Suchdomänen-zur-von-dhclient-i-erstellten-Resolv-Conf-hinzufügen
Antwort3
Ganz zu schweigen davon, dass der Inhalt von /etc/resolv.conf bei jedem Neustart des Servers auf die Azure-Standardeinstellung zurückgesetzt wird. Selbst wenn Sie ihn also ändern, wird er beim nächsten Neustart wieder die Suchdomäne reddog.microsoft.com und Ihren standardmäßigen Azure-Nameserver verwenden.