05.01.2023, aktualisiert um 07:47:11 Uhr

2992

DNS Auflösung (nur) vom DFS Namespace dauert lange

Ich habe ein seltsames Problem und bekomme es einfach nicht gelöst.

2 Server:
zeus2 (Windows Server 2008 R2) 192.168.1.101
zeus3 (Windows Server 2016) 192.168.1.102

Active Directory Domäne: myspace.local
DFS Namespace: \\myspace.local\shared
replizierter Ordner "data" in Namespace eingebunden: \\myspace.local\shared\data

das Problem:
Die DNS Auflösung des Namespace dauert relativ lange (ca. 10 Sek.)
Das passiert, wenn man z.B. "ping myspace.local" ausführt, oder \\myspace.local im File-Explorer öffnen möchte.
(die Pings selbst sind dann ohne Verzögerung, genauso wie die Verzeichnisnavigation und Dateizugriff im Explorer)

Das seltsame ist aber, das alles andere und auch alle anderen DNS-Auflösungen quasi ohne Verzögerung passieren.
also z.B. ping zeus2.myspace.local, ping zeus3.myspace.local, etc. erfolgen sofort.

Ebenfalls seltsam ist, dass ein "nslookup myspace.local" (was doch auch nichts anderes als eine DNS Abfrage wie vor einem Ping ist) auch keinerlei Verzögerung hat.

Auf beiden Servern läuft ein DNS Server.
Der DHCP Server verteilt auch beide an die Clients.
Die doppelten DNS Einträge (für beide Server) für myspace.local hat der Server selbst eingefügt und das passt eigentlich auch.
nslookup zeigt bei Abfrage von "nslookup myspace.local" mal die eine IP als erstes an, mal die andere (ist auch so gewünscht zwecks Lastverteilung)

Ich habe auch schon versucht mal nur einen der beiden DNS Server beim Client einzutragen, dann nur den anderen. Macht auch keinen Unterschied.
Habe den Namespace testweise auch mal komplett gelöscht und auf Überbleibsel in der Registry und AD überprüft, und dann neu angelegt (diesmal gleich in Version 2). Brachte ebenfalls nichts.
Clients und Server neu gestartet, DNS Caches auf Clients und Server geleert, etc. half auch nichts.

Das Problem taucht übrigens nur auf den Clients auf.
Auf den beiden Servern selbst, also z.B. ein "ping myspace.local" in der Konsole, hat diese Verzögerung NICHT.
Auf den Clients taucht das Problem bei jedem einzelnen Aufruf auf, der DNS Cache hilft also nicht.

Für Hilfe wäre ich sehr dankbar, weil ich einfach nicht weiterkomme.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 5216250385

Url: https://administrator.de/contentid/5216250385

Ausgedruckt am: 22.11.2024 um 06:11 Uhr

14 Kommentare

Neuester Kommentar

Sind die Subnetze im AD Sites and Services usw korrekt gepflegt?

moin,

kannst du etwas auch zu deinem Netzwerk sagen wie es aufgebaut ist ob es Subnetze gibt VLANs Firewall, Switche wie die Config aussieht......

es muss nicht unbedingt am DNS liegen kann auch am Netzwerk liegen....

Gruß

Zitat von @Bluebrain:

Ebenfalls seltsam ist, dass ein "nslookup myspace.local" (was doch auch nichts anderes als eine DNS Abfrage wie vor einem Ping ist) auch keinerlei Verzögerung hat.

Nicht unbedingt. Windows feuert hier gleich mehrere Lookups in Form von LLMNR, NBT-NS, mDNS usw ab.
Ggf hast du auch IPv6 aktiv und einen IPv6 DNS Eintrag?
Dann wäre es möglich das ein DNS Request an den v4 und den v6 Server parallel gehen, der v6 aber in ein Timeout läuft. Wenn du aber den v4 in NSLookup direkt angibst, geht der Request halt nur da hin

Auf beiden Servern läuft ein DNS Server.

Antworten auch beide?

Der DHCP Server verteilt auch beide an die Clients.

Wie sieht denn der Output von ipconfig /all am Client aus aus ?

Installiere mal Wireshark auf einem Client und schau was da so passiert. Der Verursacher sollte sich mit der Verzögerung ja recht leicht identifizieren lassen

Netzwerk ist ziemlich einfach gehalten. Keine weiteren Subnetze, keine VLANs und Firewall sitzt nur im Router für Verkehr von und nach außen/WAN.
Clients und Server hängen alle am gleichen (unmanaged) Switch.

ping mit der Option -4 (also nur IP 4) macht auch keinen Unterschied.

DNS Server antworten beide.

ipconfig /all gibt die zu erwartende Config aus.

Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Intel(R) Ethernet Controller (3) I225-V
   Physische Adresse . . . . . . . . : D8-BB-C1-9F-5F-CE
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.21(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Mittwoch, 4. Januar 2023 21:23:07
   Lease läuft ab. . . . . . . . . . : Sonntag, 5. Februar 2023 21:23:08
   Standardgateway . . . . . . . . . : 192.168.1.1
   DHCP-Server . . . . . . . . . . . : 192.168.1.101
   DNS-Server  . . . . . . . . . . . : 192.168.1.101
                                       192.168.1.102
   Primärer WINS-Server. . . . . . . : 192.168.1.101
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Sehr versiert bin ich leider nicht in Wireshark, werde es aber mal probieren.

Moin,

Primärer WINS-Server. . . . . . . : 192.168.1.101

Wenn du keinen WINS brauchst (und ich nehme an auf dem Server .101 läuft auch kein WINS Server), dann konfigurier das auch nicht im DHCP. Das allein könnten schon die Verzögerung auslösen.

lg,
Slainte

Und was ist nun konfiguriert für die Singlesite mit Singlesubmet?

WINS auf jeden fall abschalten wenn das nicht verwendet wird.
Ist der DNS Suffix da wirklich leer oder hast du den entfernt?

Ausserdem solltest du Netbios sowie LLMNR deaktivieren.
https://woshub.com/how-to-disable-netbios-over-tcpip-and-llmnr-using-gpo ...

Wenn du keinen WINS brauchst
WINS auf jeden fall abschalten wenn das nicht verwendet wird.

Stimmt, der hat da nichts zu suchen und ist jetzt weg.
Hat nichts geändert.

Und was ist nun konfiguriert für die Singlesite mit Singlesubmet?

Subnet ist eingetragen. Sollte aber nicht notwendig sein bei meiner Konfiguration mit nur einem Standort und einem Subnet.

Ausserdem solltest du Netbios sowie LLMNR deaktivieren.

Habe ich auch gemacht, brachte auch keinerlei Veränderung.

Ist der DNS Suffix da wirklich leer oder hast du den entfernt?

Der war leer. Expliziertes Setzen ist aber doch auch nicht nötig, bei nur einer einzigen AD, oder?
Dafür sorgt doch eh diese default-Einstellung:

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : Richard2022
   Primäres DNS-Suffix . . . . . . . : myspace.local
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : myspace.local

Habe es aber mal eingetragen. Brachte aber auch nichts.

Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix: myspace.local
   Beschreibung. . . . . . . . . . . : Intel(R) Ethernet Controller (3) I225-V
   Physische Adresse . . . . . . . . : D8-BB-C1-9F-5F-CE
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.21(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.1.1
   DNS-Server  . . . . . . . . . . . : 192.168.1.101
                                       192.168.1.102
   NetBIOS über TCP/IP . . . . . . . : Deaktiviert

Dennoch muss das sitzen, dass nach der erfolgreichen DNS Auflösung geprüft werden kann "wo" der Server steht der zum Stamm gehört.

Vermutlich ist der Ansatz mit den Kabelhai der beste Ansatz.

Kabelhai

Den installiere ich gerade.

Wenn du mitschneidest dann mache vorher alle störenden Software und Dienste aus, dass man mehr oder weniger pur das DFS -Geraffel sieht.

So, ich glaube, ich bin nun zu neuer Erkenntnis gelangt.

Ping sendet zuerst eine mDNS Broadcast Nachricht, und da wird halt entsprechend lange auf eine Antwort gewartet.

Beim Aufruf im Dateiexplorer von \\myspace.local geht es dann richtig wild her.

ABER:
Ich hatte wohl einen grundlegenden Denkfehler und bereits der Titel von meinem Post ist eigentlich falsch. :/
Und vermutlich habe ich andere damit ebenfalls verwirrt. :D
Denn ich hatte geschrieben "DNS Auflösung vom DFS Namespace".
Das ist ja so nicht richtig!
myspace.local bzw. \\myspace.local ist ja die Domäne, nicht der Namespace!
Der Namespace lautet \\myspace.local\shared
(wovon es ja sehr viele geben kann)

Und der Namespace \\myspace.local\shared lässt sich (jetzt wieder) im Explorer auch quasi verzögerungsfrei aufrufen.

Bei einem Aufruf von \\myspace.local muss Windows logischerweise erst im gesamten Netzwerk nach möglichen Freigaben auf dieser Domäne suchen, was naturgemäß eine Zeit lang dauert und wohl auch gar nicht beschleunigt werden kann.

Ganz umsonst war das ganze aber trotzdem nicht.
Gestern noch war da noch was ziemlich im Argen bei der Sache, wodurch teilweise überhaupt kein Zugriff mehr über das eingebundene Netzlaufwerk möglich war.
War also sicherlich kein Fehler, mal alles komplett zu entfernen, neu einzurichten, und dabei das ganze noch weiter zu optimieren und auch noch etwas dabei dazuzulernen.

Zitat von @Bluebrain:

Ping sendet zuerst eine mDNS Broadcast Nachricht, und da wird halt entsprechend lange auf eine Antwort gewartet.

Dann hast du LLMNR aber nicht abgeschaltet ;)

Und der Namespace \\myspace.local\shared lässt sich (jetzt wieder) im Explorer auch quasi verzögerungsfrei aufrufen.

Und was hast du getan damit das jetzt läuft?

**Bei einem Aufruf von \\myspace.local muss Windows logischerweise erst im gesamten Netzwerk nach möglichen Freigaben auf dieser Domäne suchen

Äh nein? Beim aufruf davon wird einfach einer der DCs aufgerufen und dieser Präsentiert seine SMB Shares.
Wenn man noch den Namespace anhängt, dann gibt der DFS Dienst dahinter seine Shares aus.
"Das Netzwerk" wird da keineswegs abgesucht.

Dann hast du LLMNR aber nicht abgeschaltet ;)

Doch, eigentlich schon. Wie in dem von dir verlinkten Artikel. Habe mich auch nicht in der Registry vertippt. Im Gruppenrichtlinieneditor sieht man auch, dass es abgeschaltet ist.
Wie auch WINS raus geschmissen, NetBIOS deaktiviert, sowie den DNS Präfix nochmal extra hinzugefügt.
(Neustart des PCs versteht sich von selbst)

Und was hast du getan damit das jetzt läuft?

Den kaputten Namespace und alle Überbleibsel aus der Registry und mit dem ADSI Editor entfernt und dann neu erstellt.
Das betrifft aber wie gesagt nur den Aufruf vom Namespace \\myspace.local\shared im Explorer.
Rufe ich nur die Domäne \\myspace.local auf, wo ja dann ggf. auch alle Namespaces aufgelistet werden, das dauert noch immer sehr lange. (~13 Sek.)

"Das Netzwerk" wird da keineswegs abgesucht.

Ich sehe aber, dass diverse Geräte, PCs, Netzwerkkamera, etc. abgefragt werden, und auch mittels SSDP/UPnP danach gesucht wurde.

Nur wenn ich den freigegebenen Namespace \\myspace.local\shared aufrufe, geht der Aufruf direkt sofort zum DC mit einem 'Tree Connect Request' und das ganze ist in ein paar Millisekunden erledigt.

Das ganze betrifft übrigens sowohl Windows 7 PCs als auch solche mit Windows 10 gleichermaßen.

Frage Windows Server DNS

Mehr von Bluebrain

Warum kann ich SPF so einfach austricksen?Bluebrain - 21 Kommentare

VPN nur für bestimmte Port(s) verwenden unter Win10Bluebrain - 1 Kommentar

Heiß diskutiert