[English]Heute erneut ein krudes Problem, welches durch einen Leser an mich herangetragen wurde. Es geht um Windows Server 2019, wo es in den Morgenstunden zu einem Problem am Domain Controller kommt, weil der DNS-Dienst ausfällt. Das Ganze ist dabei nicht auf ein System begrenzt, sondern tritt bei mehreren Kunden-Systemen auf. Ich stelle es mal in den Blog, um herauszufinden, ob es noch weitere Betroffene gibt.
Anzeige
Leser meldet DNS-Ausfälle
Blog-Leser Patrick P. ist als Dienstleister für verschiedene Kunden aktiv. In diesem Kontext administriert er auch mehrere Windows Server 2019, die auch als Domain Controller fungieren. Seit einiger Zeit beobachtet er aber ein krudes Problem.
- Bei einigen der betreuten Windows Server 2019 Domain Controller fällt immer der DNS-Dienst in den Morgenstunden aus.
- Ein Neustart des Windows Server 2019 oder des DNS-Diensts behebt diesen Ausfall, bis der Dienst am Folgetag wieder ausfällt.
Wenn der DNS-Dienst ausgefallen ist, klappt natürlich der Zugriff der Clients auf die Domäne nicht mehr. Hat entsprechende Anrufe der Kunden, bei denen das System nicht mehr läuft, zur Folge. Als besonderes Problem gibt Patrick noch an, dass er auch über das Gateway per RDP nicht mehr auf den Terminalserver kommt. Das merkwürdige Verhalten konnte Patrick bisher bei vier Kunden beobachten – es ist also kein Einzelsystemproblem.
Ereignisanzeige liefert Ereignis 404
Patrick hat sich noch die Ereignisanzeige der betreffenden Domain Controller auf den Windows Server 2019-Systemen angesehen. Dort finden sich dann jeweils Einträge mit der Ereignis-ID 404, die sich auf den DNS-Dienst beziehen.
Ereignisanzeige; Zum Vergrößern klicken
Anzeige
In den Details heißt es, dass ein TCP-Socket nicht an die IP-Adresse xx.xx.xx.xx gebunden werden konnte. Irgendwie scheinen die Ressourcen auszugehen. Die Empfehlung lautet, den DNS-Server bzw. den Computer neu zu starten.
Ein Ressourcenproblem?
An Hand der obigen Fehlerbeschreibung würde ich spontan auf so etwas wie ein Speicherleck tippen, so dass der Arbeitsspeicher voll läuft und die Ressourcen knapp werden. Der Neustart des Servers oder des DNS-Diensts geben den Speicher wieder frei, so dass die Maschine wieder einige Stunden läuft.
Mir spukt dazu der Beitrag Windows Server: April 2024 Update KB5036909 verursacht LSASS-Abstürze auf DCs durch den Kopf. Das dortige Speicherleck, welches durch das März/April 2024-Update hervorgerufen wurde, ist aber eigentlich seit Mail per Out-of-Band-Update gefixt und sollte im Juni 2024 mit den regulären Sicherheitsupdates beseitigt worden sein.
Es gibt bei Microsoft den Forenpost DNS server errors 404, 407, 408 when windows server installed on SSD aus dem November 2020, wo jemand das Fehlerbild beschreibt und das Ganze auf eine SSD-Installation zurückführen möchte. Von Microsoft gibt es noch diese Ressource aus dem Jahr 2010, die sich ebenfalls mit dem Event ID 404 beim DNS-Server befasst. Dort ist der Vorschlag, Speicher (der durch Anwendungen oder Dienste belegt ist) auf dem betreffenden Server freizugeben.
Es gibt noch einen recht frischen Supportbeitrag Ereignis-IDs 4016 und 4004 bei DNS-Aktualisierungstimeout von Mai 2024, der sich aber mit einem anderen Fehlercode befasst. Dort bietet Microsoft Hotfixes an, um das Problem zu beheben.
An dieser Stelle die Frage: Hat jemand das oben beschriebene Verhalten ebenfalls beobachtet? Gibt es eine Erkenntnis zur Ursache und wie man das Problem dauerhaft fixen kann?
Ähnliche Artikel:
Windows Server: März 2024-Update verursacht LSASS Memory-Leak auf DCs
Windows Server: Fix für (Kerberos) LSASS-Memory-Leak durch März 2024-Updates
Windows Server: April 2024 Update KB5036909 verursacht LSASS-Abstürze auf DCs
Windows Server 2019: Out-of-Band-Update KB5039705 veröffentlicht (23. Mai 2024)
Anzeige
Ich habe keine entsprechenden DC am Start. Aber das ganze Verhalten liest sich recht typisch. Ich nutze auch einen Laptop der sich über Edge/IPV4 in das O2 Netz einwählen kann.
Günter Born schrieb:
> "Mir spukt dazu der Beitrag Windows Server: April 2024 Update KB5036909 verursacht LSASS-Abstürze auf DCs durch den Kopf. Das dortige Speicherleck, welches durch das März/April 2024-Update hervorgerufen wurde, ist aber eigentlich seit Mail per Out-of-Band-Update gefixt und sollte im Juni 2024 mit den regulären Sicherheitsupdates beseitigt worden sein."
Dieser Zeitraum entspricht genau dem Verhalten das sich hier gezeigt hat. Es war entweder keinerlei Einwahl möglich oder wenn sehr spät – dann allerdings keinerlei DNS Auflösung oder UDP bzw. TCP Datenübertragung auch wenn eigentlich eine andere DNS Verwendung stattfinden sollte. Jeden Tag … zeigte sich dieses Verhalten
um ca. 7/7:30 Uhr bis 19/21 Uhr. Nur In der Nacht war es wieder normal funktionstüchtig (dann hat der Spät/Nacht Dienst die Server evtl. neu gestartet ???).
Das Ganze hat sich gezeigt bei Verwendung des NIC "oder" MODEM Device.
Seit ende Juni ist das O2 Problem nicht mehr vorhanden!
Meine Meinung – O2 nutzt für dieses alte Netz wohl noch diese Server.
Wir haben früher mit dem Performance Monitor die Resourcen überwacht. Hat Microsoft das ausgebaut dass man für jeden kleinen F…z ein Zähler anschalten kann?
Oder warum sieht man das leak nicht sondern wartet, bis die Kiste steht?
Deswegen habe ich auch das (im Nachbarthread gerade thematisierte) Check_MK im Einsatz, und ja – ich kriege auch mitten in der Nacht eine SMS, wenn ein wichtiger Server gerade bei 95% RAM, CPU oder Festplatte steht 🙂
Natürlich auch, wenn der DNS nach 50ms noch nicht geantwortet hat.
Server 2019 hat noch ganz andere Marotten.
Sehr beliebt: Nach einer Firmware- oder Treiber-Aktualisierung des Mainboards wird/werden der/die Netzwerkadapter neu hinzugefügt. Manchmal auch nach einem Windows Update und hin und wieder auch "einfach so" aus Spaß an der Freude.
Diese Veränderung des identischen Netzwerkadapters werden aber nicht auf die Hyper-V-Adaption abgebildet. Der verbleibt bei dem (nunmehr nicht vorhandenen) Netzwerk-Adapter.
Sprich: Ein auf diesem Server laufende virtuelle Maschinen bekommen von jetzt auf gleich virtuelle Netzwerk-Adapter, die nicht mehr "extern" zugreifen können, sondern nur noch "intern" verbunden sind.
Einen 404 habe ich nicht vorzuweisen, es läuft aber auch kein DNS-Dienst auf dem Hyper-V. Allerdings gibt es augenscheinlich Problemen hardwarebeschleunigte Funktionen wie IPsec-Taskabladungen an die VMs weiter durchzureichen.
Wäre vielleicht ein Anhaltspunkt, sich mal die Netzwerkkarte nebst Treiber genauer anzusehen.
Nur ein Hinweis:
Jeder Netzwerk Adapter ist bei Windows uniq.
Tauscht man einen Adapter gegen einen identischen aus, so baut Windows den ganzen Stack komplett neu auf und versteckt den des vorherigen.
Das kostet natürlich Ressourcen und falls da eine Software andauernd "neue" Karten anschleppt kann es schnell zu viel sein.
Auch wird jedes mal die Default Konfiguration genommen.
Sorry das stimmt so nicht. Wenn ich einen Netzwerkadapter durch das baugleiche Modell im gleichen Slot tausche bekommt Windows das gar nicht mit. Wenn ich den Adapter aber in einen anderen Slot stecke meint Windows das sei eine neue Netzwerkkarte. Sieht man ganz schön am #2 usw. im Geräte Manager. Das ist z.B. ziemlich blöde wenn durch irgendwelche Chipsatz Updates die Reihenfolge der Ports von einem Quadport-Adapter durcheinander gewürfelt wird. Selbst bei einem Hyper-V Host geht der Austausch des Netzwerkadapter durch ein baugleiches Modell ohne Probleme. Hat man die MAC-Adresse des physischen Adapters für die Netzwerkbrücke auf dem Host verwendet kann man auf diesem Weg auch ganz schnell doppelte MACs im Netzwerk haben, wenn man nach einem Umzug des Hosts auf neue Hardware die alte Hardware umwidmet :)
Da ist meine Erfahrung eine andere Vermutlich hängt es mit der Karte zusammen, und evtl. auch mit der MAC Adresse.
Daran sollte man denken wenn man "kurzmal" NICs tauscht um zu sehen ob, der Fehler mitwandert.
Das hängt mit der von Windows verwalteten "Geräte-ID" zusammen. Im Gegensatz zu ISA ist ja auch PCI trotz seines Namens logisch eine Baumstruktur mit Bridges, jeder Slot ist eindeutig identifizierbar. Da reicht es schon, eine Netzwerkkarte in den Slot nebenan umzustecken um sie als neues Gerät erkennen zu lassen – trotz gleicher PCI-ID und MAC.
Besonders spaßig ist es für die Anwender bei USB, wenn sie ein Gerät achtlos an eine andere Buchse stecken als zuvor und bei dem dann als "neu" erkannten Gerät die Defaults nicht passen. Ein Speicherstick kriegt dann vielleicht einen neuen Laufwerksbuchstaben, ein Netzwerkadapter eine neue IP.
Kann man schön im Gerätemanger beobachten, wenn man sich die ausgeblendeten (bekannten, aber gerade nicht verbundenen) Geräte mit anzeigen läßt.
Bei einem Firmware-Update kann ich noch mitgehen, nicht jedoch bei Treiber- oder Windows-Aktualisierungen.
DIESES Verhalten ist 2019-Exklusiv. Das hast Du nicht in 2016 und auch nicht in 2012 (R2).
Noch schlimmer war es, als 2019 raus kam… da konnte ich die Netzwerk-Konfiguration des Hyper-V mehrmals täglich "richten". Etliche Updates später hat sich das gelegt (nur noch alle paar Monate…).
Negativ bei mir. Die DNS-Server unter 2019 laufen problemfrei. Keine Einträge oder ähnliches. Püh! Mir reicht es schon, dass nun Teile der GUI auf Englisch sind …
Die Patchdays entwickeln sich echt zum russischen Roulette … man man man …
Ach, nicht wundern. In der gesamten Lebenszeit von 2012 r2 hat MS es nicht geschafft, im Server-Manager den Begriff "Server löschen" gegen "Server neustarten" auszutauschen.
Die Firma hat fertig. Aber sowas von.
Habe nun seit ca. einer Woche bei 4 Kunden mit Server 2019 unerklärliche Unerreichbarkeiten der DCs, die sporadisch auftreten. Im Serverlog wird nichts abgelegt, jedoch melden die Clients DNS-Fehler. Also von hier aus: Ja, es gibt mit den aktuellen Updates für Server 2019 anscheinend Probleme im DNS.
virtuelles System?
Interface down? Mac doppelt bei vms? Interface Doppelt (oder totes Interface noch da)
alte Listen Interface runter loeschen
nur auf die ips binden die da sind.
Hier tritt es nicht auf.
Hi, das sind VMs die dort laufen.
Das mit den IPs binden habe ich schon gelesen, muss dort nur der DC gebunden werden oder tatsächlich alle Clients und weiteren Server?!
Zum einen läuft es gegen jede Best Practice, in einem Netz nur einen DNS zu betreiben.
Praktisch in jeder Netzwerkkonfiguration wird mindestens ein "primärer" und "sekundärer" DNS abgefragt, oft kann man auch eine ganze Liste eintragen, etwa unter Windows (erweitert) oder Linux (resolv.conf).
Registrierungen öffentlicher Domains werden gar nicht bearbeitet, wenn man nicht mindestens zwei DNS dazu angibt, zusätzlich müssen diese (der Redundanz wegen) sogar in unterschiedlichen Netzen stehen.
Zum eigentlichen Problem wird man in der Windows-Hilfe fündig:
"404: The DNS server could not bind a Transmission Control Protocol (TCP) socket to address 192.168.1.10. The event data is the error code. An IP address of 0.0.0.0 can indicate a valid "any address" configuration in which all configured IP addresses on the computer are available for use.
Restart the DNS server or reboot the computer."
Mit "Ressourcen" ist also gemeint, daß der DNS-Port (TCP/53) bereits durch ein anders Programm belegt ist. UDP wäre übrigens Fehler 407 bzw. 408.
Das kann natürlich ein abgestürzter DNS-Dienst sein, aber vielleicht auch eine Malware, die versucht, sich als DNS-Dienst zu installieren. Von "wildem Gebastel" und parallelem Installieren eines zweiten DNS (z.B. Mobilfunkprovider liefern manchmal einen Cache-Dienst zum Datensparen) gehe ich in einer professionell administrierten Umgehung mal nicht aus.
Klarheit sollte ein "netstat -abn" wahlweise noch mit "find:53" ergänzt liefern, das zeigt alle Programme und Prozesse an, die den Port 53 belegen.
ja, würde ich auch so interpretieren.
Es muss ja kein anderes Programm sein, sondern der DNS kann sich selbst auf dem Fuß stehen.
Ein 2.DNS ist bei der Fehlersuche nicht unbedingt hilfreich.
Auch nicht vergessen, dass DNS UDP und TCP macht.
Mal mit nmap checken was da noch geht, bis wann.
Evtl. ist der Event Eintrag viel später
Wenn das ganze nicht Patch/Update zuordnet sein sollte, mal im fehlerhaften Zustand rausfinden ob der DNS Ports! (Auch Oberhalb 49000) noch von der dns*.exe verwendet werden. Ich hatte mal Kunden auf den wurden auf die DCs/DNS Server 3rd Party installiert, die sich sehr sehr großzügig Port dyn. portranges eingenommen haben, die dann mit der DNS Range kollidierten. Das ganz fand auch zu einem festen Zeitpunkt immer statt, da alle 24 std der DNS sich intern Neustarten und somit Ports freigibt, die dann von der anderen applikation geklaut wurde..
Keine Probleme. Habe einige Server draußen.
Dito, keine Probleme.
Mal im Taskmanager/Ressourcenmonitor nachgesehen, was auf den Maschinen so abgeht? Taskmanager -> Details -> Nach Speichergröße sortiert
ebenfalls keine Probleme und betreue ca. 25 Kunden deren DCs noch mit 2019 laufen. Alle auf dem aktuellen Patchlevel.
Hallo zusammen,
hier konnten wir fehelerhafte DNS Server auf Probleme mit dem Network Location Awareness Service Provider zurückführen, also das Netzwerk wurde nicht mehr als Domänen Netzwerk erkannt, aber es passt doch nicht nicht wirklich zum beschriebenen Fehlerbild. weil dies meistens nach einem Neustart auftrat und wir es mit einem automatischen Neustart des Dienstes 5 Minuten nach Neustart eines Servers in den Griff bekommen haben.
Hmm dein Fehler klingt so als hätte man nur einen DC im Netzwerk bzw. mehrere aber auf den DCs nicht einen anderen DC als primären DNS eingerichtet. Denn dann bekommt man genau dieses Fehlerbild!
Das Problem trat vor 2 Jahren schonmal auf und konnte durch 2 Gruppenrichtlinien und einen Known Issue Rollback (KIR) des KB5009616 gelöst werden:
www[.]der-windows-papst[.]de/2022/03/25/dns-problem-in-windows-server-2019-beheben/
Wurde das bereits durchgeführt?
2.
Man kann auch einen Task einrichten, der den DNS-Dienst täglich beendet, den Cache löscht und den DNS-Dienst neu startet.
3.
Auf den Clients den DNS-Client-Dienst (Dnscache) abschalten.
4.
Den Microsoft-Support anrufen, anmailen, ein Ticket aufmachen etc.
Das ist deren OS und deren Aufgabe, solche Probleme zu fixen.
5.
Harten Schnitt machen und Microsoft komplett aus dem Unternehmen verbannen, weil nichts mehr funktioniert aufgrund von tausenden ungefixten Bugs und dadurch viel zu viele Arbeitsstunden für die Problembehebungsversuche verballert werden.
Genau. Unsere alten Unix Büchsen wurden auch jeden Tag 05:55 gebootet. Dann waren sie zu um 06:00 fit.
Damit würden alle hängenden User Prozesse beendet und das Memory leak wirkte sich nicht aus.
kann ebenfalls keine Probleme bestätigen… ich tippe auf den Klassiker: Doppelte MACs aufgrund Mix von statischer und dynamischer Zuweisung wenn Systeme zu festen Zeiten neu starten und andere plötzlich weg sind. Wäre interessant zu erfahren, ob ICMP auf IPs noch ging oder nicht.
Ansonsten wie der Vorposter bereits sagte: Kein AD ohne 2x DCs und 2x DNS, besser noch ist es, einen selbstkontrollierten (Linux) DNS und PKI zu führen, ohne von dem MS Schrott abhängig zu sein.
Die Morgenstunden, 02-05 Uhr, deuten immer auf (Telekom) xDSL Wartungsfenster hin. Gibt es da Abhängigkeiten?
dcdiag alles grün, besonders /test:DNS?
Sonst sind die 2019er was AD / DNS / DHCP angeht absolut unauffällig.
Ich habe hier zwei 2019er Server als DNS ohne AD als physische Server. Auf beiden keine besonderen Auffälligkeiten. Dieser Fehler finden sich dieses Jahr aber schon einmal bzw. zweimal im Log, allerdings jedesmal nach einem Neustart. Ein manueller Eingriff war aber auch nicht nötig. Ich meine vor Jahren auf einem Hyper-V Cluster oder einem Hyper-V Host mit VMs ähnliche Probleme gehabt zu haben. Ich meine sogar im Ereignisprotokoll der VM Hinweise auf das Entfernen und wieder Hinzufügen des Netzwerkadadapters in der VM gesehen zu haben. Ich weiß aber nicht mehr ob das was im Zusammenhang mit der Backuplösung für die Hosts war und der Fehler beim Erstellen des Snapshots der VM auftrat oder ob ich das MAC-Adress Spoofing für den Netzwerkdapter in den Einstellungen der VM aktivieren musste. Ich erinnere mich nur noch sehr sehr wage daran, das waren noch Systeme mit Windows Server 2012 R2 :)
Hallo zusammen,
mmh wir haben seit einiger Zeit das Problem, das Clients eines Standortes immer wieder die Vertrauensstellung verlieren. Vor Ort ist ein RODC… Dachten bis jetzt der RODC hat ein Problem oder die Verbindung zum DC oder die Clients… Aber vielleicht ist es dieses DNS Problem?
Mfg
Wenn Rechner in einer Domäne die Vertrauensstellung verlieren, sollte man grundsätzlich dokumentieren, welcher Rechner mit welchem Rechnernamen die Vertrauensstellung wann verloren hat. Bei einem Kunden kam dann nämlich irgendwann ans Tageslicht, dass irgendwer Rechnernamen doppelt vergeben hat an den Clients…
Doppelte Namen, so einfach ist es leider nicht.
Muss was unter der Motorhaube sein.
schwierig zu greifen weil die typischen logs so viele Problemlösungen bringen… aber keiner hat davon bis jetzt geholfen.
MfG
Wie gesagt, Performance/System Monitor Rulez.
: Morgens kommen die User und schalten ihre Rechner ein.
da ist remmidemmy in DHCP und DNS.
netstat -abn" wahlweise noch mit "find:53" ergänzt liefern, das zeigt alle Programme und Prozesse an, die den Port 53 belegen.
man sollte dazu entsprechende (admin) Rechte in der Console haben.
Wie machst du das mit dem "find:53"?
Mit einer Pipe.
Netstat -abn | find ":53"
FIND: Parameterformat falsch
So sollte es klappen:
netstat -abn | findstr :53
Hallo zusammen,
Ja, diese Probleme kann ich so bestätigen, auch mit zwei DNS Servern. Teil Seiten nicht Auflösung, teils konnten sich PCs an Domäne nicht mehr anmelden. Neustart DNS mit Cache löschen half mir weiter. Auch nach Neustart nicht besser – erst Cache löschen hat geholfen. Hoffe das hält, haben einige 2019er draußen.
LG
Micha
Hallo erstmal,
ich hatte das Problem auch schon mal auf einem HP Server. Alle 24 Stunden war dieser nicht mehr erreichbar, bis ich über den Ressourcen Monitor feststellen konnte, dass der HPE MR Storage Administrator alle verfügbaren DNS Ports in Beschlag genommen hat. nachdem ich ich diese Anwendung neu installiert hatte, war Ruhe.
Vielleicht hilft Dir das ja weiter.
Grus Marcus
3 x 2019er DCs, davon 2x DNS.
Alle VMs auf KVM. Aktueller Patchstand, keine DNS-Probleme.