82959
15.04.2011
11871
22
0
Windows Server 2008 R2 DNS Server Timeouts
Domänen-Clients bekommen unregelmäßige Timeouts bei DNS Anfragen an den Domänencontroller mit Windows Server 2008 R2 (Windows DNS-Server Dienst)
Hallo Leute,
ich hoffe ihr könnt mir bei meinem Problem weiterhelfen. Leider besteht das Problem schon seit 2 Tagen und wir finden nach intensivster Suche keine Problemlösung.
Problembeschreibung
Domänen-Clients bekommen unregelmäßig im Internet Explorer die Anzeige "Die Webseite konnte nicht angezeigt werden". Teilweise tritt dies auf, teilweise funktioniert es einwandfrei. Wir konnten das Problem soweit eingrenzen, dass der DNS-Server des Domänencontrollers dafür verantwortlich ist. Dieser liefert nämlich bei DNS Abfragen von einem Domänen-Client über nslookup teilweise eine IP-Adresse zurück (Anfrage auf URL), teilweise kommt ein Timeout. Das Problem ist so unregelmäßig, dass ich kein Muster feststellen konnte.
Der DNS-Server ist einwandfrei konfiguriert bzw. hat die letzten 4 Monate ohne Probleme funktioniert. Einziges was ich mir erklären kann ist ein Problem in Zusammenhang mit einem Windows Update, da diese in den letzten Tagen installiert wurden. Nachdem das Problem angefangen hatte, habe ich auch noch den neuen Service Pack 1 installiert - keine Verbesserung.
Meine Frage
Was kann ich in diesem Fall machen? Gibt es die Möglichkeit den DNS-Server irgendwie zu reparieren? Kann ich irgendwie ergründen warum dieser Timeout auftritt? Was ich nicht grad unbedingt machen möchte ist die DNS-Server Rolle deinstallieren und dann wieder installieren. Ich habe keine Ahnung welche Auswirkungen das hat.
Background Daten
Server: Windows Server 2008 R2 SP1 - Windows DNS-Server Dienst
DNS-Server: Aktuell ist eine DNS-Weiterleitung auf unsere Firewall konfiguriert (DNS-Dienst auf der Firewall funktioniert durchgehend immer perfekt)
=> Habe parallel auf DNS-Server und Firewall getestet: DNS-Server = Timeout / Firewall = richtige DNS Auflösung
Clients: Domänen-Clients - allerdings egal, da das Problem bei jedem Client auftritt der eine Anfrage stellt
DNS Eintrag am Server: IP-Adresse des Servers und nicht 127.0.0.1 => allerdings habe ich mit beidem schon getestet
IPv6 habe ich sicherheitshalber mal deaktiviert
Sonst noch was wichtig?
Besten Dank im Voraus für eure Hinweise. Ich bin im Moment echt ratlos ...
LG
ITinfrastruktur
Hallo Leute,
ich hoffe ihr könnt mir bei meinem Problem weiterhelfen. Leider besteht das Problem schon seit 2 Tagen und wir finden nach intensivster Suche keine Problemlösung.
Problembeschreibung
Domänen-Clients bekommen unregelmäßig im Internet Explorer die Anzeige "Die Webseite konnte nicht angezeigt werden". Teilweise tritt dies auf, teilweise funktioniert es einwandfrei. Wir konnten das Problem soweit eingrenzen, dass der DNS-Server des Domänencontrollers dafür verantwortlich ist. Dieser liefert nämlich bei DNS Abfragen von einem Domänen-Client über nslookup teilweise eine IP-Adresse zurück (Anfrage auf URL), teilweise kommt ein Timeout. Das Problem ist so unregelmäßig, dass ich kein Muster feststellen konnte.
Der DNS-Server ist einwandfrei konfiguriert bzw. hat die letzten 4 Monate ohne Probleme funktioniert. Einziges was ich mir erklären kann ist ein Problem in Zusammenhang mit einem Windows Update, da diese in den letzten Tagen installiert wurden. Nachdem das Problem angefangen hatte, habe ich auch noch den neuen Service Pack 1 installiert - keine Verbesserung.
Meine Frage
Was kann ich in diesem Fall machen? Gibt es die Möglichkeit den DNS-Server irgendwie zu reparieren? Kann ich irgendwie ergründen warum dieser Timeout auftritt? Was ich nicht grad unbedingt machen möchte ist die DNS-Server Rolle deinstallieren und dann wieder installieren. Ich habe keine Ahnung welche Auswirkungen das hat.
Background Daten
Server: Windows Server 2008 R2 SP1 - Windows DNS-Server Dienst
DNS-Server: Aktuell ist eine DNS-Weiterleitung auf unsere Firewall konfiguriert (DNS-Dienst auf der Firewall funktioniert durchgehend immer perfekt)
=> Habe parallel auf DNS-Server und Firewall getestet: DNS-Server = Timeout / Firewall = richtige DNS Auflösung
Clients: Domänen-Clients - allerdings egal, da das Problem bei jedem Client auftritt der eine Anfrage stellt
DNS Eintrag am Server: IP-Adresse des Servers und nicht 127.0.0.1 => allerdings habe ich mit beidem schon getestet
IPv6 habe ich sicherheitshalber mal deaktiviert
Sonst noch was wichtig?
Besten Dank im Voraus für eure Hinweise. Ich bin im Moment echt ratlos ...
LG
ITinfrastruktur
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 164680
Url: https://administrator.de/forum/windows-server-2008-r2-dns-server-timeouts-164680.html
Ausgedruckt am: 06.04.2025 um 09:04 Uhr
22 Kommentare
Neuester Kommentar
Hi,
Normalerweise hast du mehr als einen DNS Server eingetragen,Dies ist bei dir wahrscheinlich der Fall. Einer / mehrere dieser DNS Server sind nicht mehr Aktiv oder nicht mehr ansprechbar. Die ungültigen DNS Server müssen entfernt / ersetzt werden. Dann geht es wieder.
Der Client versucht eine Seite aufzulösen, was im ersten Anlauf meist nicht funktioniert (TimeOut). Wenn du aktualisierst, wird dernicht gefundene DNS Server ignoriert und der nächste DNS Server in der Liste wird angefragt. Dieser antwortet und du siehst die Internetseite.
Bei uns war dies der Fall, als wir den Provider für die feste IP gewechselt haben. Die DNS Einträge waren auf verschiedene Anbieter ausgelegt, wovon durch den Wechsel 2 DNS Server nicht mehr erreichbar waren. (Vielleicht können die sich nicht
leiden
)
Hoffe das hilft.
Normalerweise hast du mehr als einen DNS Server eingetragen,Dies ist bei dir wahrscheinlich der Fall. Einer / mehrere dieser DNS Server sind nicht mehr Aktiv oder nicht mehr ansprechbar. Die ungültigen DNS Server müssen entfernt / ersetzt werden. Dann geht es wieder.
Der Client versucht eine Seite aufzulösen, was im ersten Anlauf meist nicht funktioniert (TimeOut). Wenn du aktualisierst, wird dernicht gefundene DNS Server ignoriert und der nächste DNS Server in der Liste wird angefragt. Dieser antwortet und du siehst die Internetseite.
Bei uns war dies der Fall, als wir den Provider für die feste IP gewechselt haben. Die DNS Einträge waren auf verschiedene Anbieter ausgelegt, wovon durch den Wechsel 2 DNS Server nicht mehr erreichbar waren. (Vielleicht können die sich nicht
leiden
)Hoffe das hilft.
Hallo,
danke für deine Hilfe.
Leider ist dies bei uns nicht der Fall. Wir haben am Server nur 1 DNS-Weiterleitung auf die Firewall und auf der Firewall sind 1 primärer DNS Eintrag unseres Providers und ein sekundärer Backup DNS-Eintrag des selben Providers eingetragen. Die Einstellungen stimmen und wurden gestern mit unserem Provider geprüft. Auf der Firewall funktioniert die DNS-Auflösung perfekt.
Schöne Grüße
ITinfrastruktur
danke für deine Hilfe.
Leider ist dies bei uns nicht der Fall. Wir haben am Server nur 1 DNS-Weiterleitung auf die Firewall und auf der Firewall sind 1 primärer DNS Eintrag unseres Providers und ein sekundärer Backup DNS-Eintrag des selben Providers eingetragen. Die Einstellungen stimmen und wurden gestern mit unserem Provider geprüft. Auf der Firewall funktioniert die DNS-Auflösung perfekt.
Schöne Grüße
ITinfrastruktur
So Leute,
hier mal einen kurzen Zwischenstand von der Situation:
- es ist unerklärlich woher das Fehlverhalten des DNS-Servers kommt
=> Es wurden keine Windows Updates installiert die sich am DNS-Server zu schaffen machen
=> Es wurden keine Konfigurationsänderungen am DNS-Server vorgenommen
=> Es wurden am DC auf dem der DNS-Server läuft überhaupt nichts gemacht, außer Benutzer und Gruppen angelegt (in den letzten Wochen)
- es wurde mit haufenweise Analysetools die Kommunikation, das Verhalten etc. des DNS-Servers überprüft
- Ungereimtheiten wurden behoben, Konfigurationen angepasst ...
=> ...obwohl eigentlich alles die letzten paar Monate auch einwandfrei funktioniert hat
Jetzt haben wir Freitag Abend und das Endergebnis aus Zusammenarbeit unserer internen IT und externen Betreuern ist, dass jetzt alles wieder funktionieren sollte. Haufenweise Geld gekostet, nichts gebracht ... wie immer
Ich werde am Montag berichten, ob wieder alles richtig und einwandfrei läuft ...
Schönes Wochenende
ITinfrastruktur
hier mal einen kurzen Zwischenstand von der Situation:
- es ist unerklärlich woher das Fehlverhalten des DNS-Servers kommt
=> Es wurden keine Windows Updates installiert die sich am DNS-Server zu schaffen machen
=> Es wurden keine Konfigurationsänderungen am DNS-Server vorgenommen
=> Es wurden am DC auf dem der DNS-Server läuft überhaupt nichts gemacht, außer Benutzer und Gruppen angelegt (in den letzten Wochen)
- es wurde mit haufenweise Analysetools die Kommunikation, das Verhalten etc. des DNS-Servers überprüft
- Ungereimtheiten wurden behoben, Konfigurationen angepasst ...
=> ...obwohl eigentlich alles die letzten paar Monate auch einwandfrei funktioniert hat
Jetzt haben wir Freitag Abend und das Endergebnis aus Zusammenarbeit unserer internen IT und externen Betreuern ist, dass jetzt alles wieder funktionieren sollte. Haufenweise Geld gekostet, nichts gebracht ... wie immer
Ich werde am Montag berichten, ob wieder alles richtig und einwandfrei läuft ...
Schönes Wochenende
ITinfrastruktur
Hallo,
die DNS - Einträge auf der Firewall - sind das noch gültige Server?? Ersetze diese doch einfach mal durch andere Provider - Unabhängige Server (z.B. von einer Universität etc.) Listen mit gültigen IP Adressen kannst du problemlos über Google finden.
die DNS - Einträge auf der Firewall - sind das noch gültige Server?? Ersetze diese doch einfach mal durch andere Provider - Unabhängige Server (z.B. von einer Universität etc.) Listen mit gültigen IP Adressen kannst du problemlos über Google finden.
Hi ITinfrastruktur,
ich hab in meiner Testumgebung folgendes Verhalten reproduzieren können, wenn die Weiterleitung nicht eingetragen ist, bzw. nicht funktioniert:
Der erste Versuch einer Namensauflösung endet meistens mit einem Timeout - aber nicht immer. Weitere Anfragen einer Namensauflösung funktionieren dann.
Wenn das bei euch auch so ist, könnte das daran liegen, dass der DNS nicht den Weiterleitungsserver bemüht, sondern die Stammhinweisserver.
In dem Fall würde ich nachsehen ob DNS-Anfragen an den DNS der Firewall durch diese geblockt werden oder durch die Windows Firewall geblockt werden und ob die Weiterleitungsadresse richtig eingetragen ist.
Ihr könnt auch - wenn gesetzt - die Option Stammhinweise verwenden wenn keine Weiterleitungen verfügbar sind mal deaktivieren. Wenn der Weiterleitungsserver nicht funktioniert/erreichbar ist dürfte dann gar nix mehr gehen. Dann wisst ihr wenigstens wo das Problem liegt ;)
Außerdem könntet ihr Testweise einen zusätzlichen Weiterleitungsserver eintragen (DNS vom Provider o.ä).
VG. mhard666
ich hab in meiner Testumgebung folgendes Verhalten reproduzieren können, wenn die Weiterleitung nicht eingetragen ist, bzw. nicht funktioniert:
Der erste Versuch einer Namensauflösung endet meistens mit einem Timeout - aber nicht immer. Weitere Anfragen einer Namensauflösung funktionieren dann.
Wenn das bei euch auch so ist, könnte das daran liegen, dass der DNS nicht den Weiterleitungsserver bemüht, sondern die Stammhinweisserver.
In dem Fall würde ich nachsehen ob DNS-Anfragen an den DNS der Firewall durch diese geblockt werden oder durch die Windows Firewall geblockt werden und ob die Weiterleitungsadresse richtig eingetragen ist.
Ihr könnt auch - wenn gesetzt - die Option Stammhinweise verwenden wenn keine Weiterleitungen verfügbar sind mal deaktivieren. Wenn der Weiterleitungsserver nicht funktioniert/erreichbar ist dürfte dann gar nix mehr gehen. Dann wisst ihr wenigstens wo das Problem liegt ;)
Außerdem könntet ihr Testweise einen zusätzlichen Weiterleitungsserver eintragen (DNS vom Provider o.ä).
VG. mhard666
Hallo mhard666,
danke für deine Lösungsansätze. Nach der ganzen Herumwerkerei am Freitag Nachmittag/Abend, bin ich wieder drauf gekommen, dass es doch noch nicht richtig funktioniert
Bevor am Freitag Abend haufenweise zeug herumgedreht wurde, habe ich ein Debugging-Log am DNS-Server erstellt. Nur leider kann ich es nicht lesen bzw. kenne ich mich bei diesen Angaben zu wenig aus.
Der unten stehende Logauszug ist genau dieser bei dem ein Client (10.10.15.4) versucht für die URL apple.cz eine DNS-Anfrage an unseren Server (10.10.15.1) zu senden und in einen Timeout läuft. Auf unsere Firewall (10.10.15.254) besteht vom Server aus eine DNS-Weiterleitung. Das angehängt Log ist was der Server für Kommunikation aufgezeichnet hat. Hat jemand eine Idee bzw. kann das Log richtig lesen?
danke für deine Lösungsansätze. Nach der ganzen Herumwerkerei am Freitag Nachmittag/Abend, bin ich wieder drauf gekommen, dass es doch noch nicht richtig funktioniert
Bevor am Freitag Abend haufenweise zeug herumgedreht wurde, habe ich ein Debugging-Log am DNS-Server erstellt. Nur leider kann ich es nicht lesen bzw. kenne ich mich bei diesen Angaben zu wenig aus.Der unten stehende Logauszug ist genau dieser bei dem ein Client (10.10.15.4) versucht für die URL apple.cz eine DNS-Anfrage an unseren Server (10.10.15.1) zu senden und in einen Timeout läuft. Auf unsere Firewall (10.10.15.254) besteht vom Server aus eine DNS-Weiterleitung. Das angehängt Log ist was der Server für Kommunikation aufgezeichnet hat. Hat jemand eine Idee bzw. kann das Log richtig lesen?
DNS Server log file creation at 15.04.2011 04:02:16
Message logging key (for packets - other items use a subset of these fields):
Field # Information Values
------- ----------- ------
1 Date
2 Time
3 Thread ID
4 Context
5 Internal packet identifier
6 UDP/TCP indicator
7 Send/Receive indicator
8 Remote IP
9 Xid (hex)
10 Query/Response R = Response
blank = Query
11 Opcode Q = Standard Query
N = Notify
U = Update
? = Unknown
12 [ Flags (hex)
13 Flags (char codes) A = Authoritative Answer
T = Truncated Response
D = Recursion Desired
R = Recursion Available
14 ResponseCode ]
15 Question Type
16 Question Name
15.04.2011 04:02:22 063C EVENT Der DNS-Server wartet darauf, dass von den Active Directory-Domänendiensten angezeigt wird, dass die Erstsynchronisierung des Verzeichnisses durchgeführt wurde. Der DNS-Serverdienst kann erst nach der Erstsynchronisierung gestartet werden, da wichtige DNS-Daten möglicherweise noch nicht auf diesen Domänencontroller repliziert wurden. Sofern die im Ereignisprotokoll der Active Directory-Domänendienste protokollierten Ereignisse deutlich machen, dass Probleme bei der DNS-Namensauflösung vorliegen, sollte ggf. die IP-Adresse eines weiteren DNS-Servers für diese Domäne der DNS-Serverliste in den Internetprotokolleigenschaften dieses Computers hinzugefügt werden. Dieses Ereignis wird alle zwei Minuten protokolliert, bis von den Active Directory-Domänendiensten angezeigt wird, dass die Erstsynchronisierung durchgeführt wurde.
15.04.2011 04:06:24 0820 PACKET 0000000003FD28F0 UDP Rcv 10.10.15.4 0036 Q [0001 D NOERROR] A (5)apple(2)cz(7)connect(5)local(0)
UDP question info at 0000000003FD28F0
Socket = 336
Remote addr 10.10.15.4, port 56466
Time Query=301, Queued=0, Expire=0
Buf length = 0x0fa0 (4000)
Msg length = 0x0028 (40)
Message:
XID 0x0036
Flags 0x0100
QR 0 (QUESTION)
OPCODE 0 (QUERY)
AA 0
TC 0
RD 1
RA 0
Z 0
CD 0
AD 0
RCODE 0 (NOERROR)
QCOUNT 1
ACOUNT 0
NSCOUNT 0
ARCOUNT 0
QUESTION SECTION:
Offset = 0x000c, RR count = 0
Name "(5)apple(2)cz(7)connect(5)local(0)"
QTYPE A (1)
QCLASS 1
ANSWER SECTION:
empty
AUTHORITY SECTION:
empty
ADDITIONAL SECTION:
empty
15.04.2011 04:06:24 0820 PACKET 0000000003FD28F0 UDP Snd 10.10.15.4 0036 R Q [8385 A DR NXDOMAIN] A (5)apple(2)cz(7)connect(5)local(0)
UDP response info at 0000000003FD28F0
Socket = 336
Remote addr 10.10.15.4, port 56466
Time Query=301, Queued=0, Expire=0
Buf length = 0x0fa0 (4000)
Msg length = 0x006c (108)
Message:
XID 0x0036
Flags 0x8583
QR 1 (RESPONSE)
OPCODE 0 (QUERY)
AA 1
TC 0
RD 1
RA 1
Z 0
CD 0
AD 0
RCODE 3 (NXDOMAIN)
QCOUNT 1
ACOUNT 0
NSCOUNT 1
ARCOUNT 0
QUESTION SECTION:
Offset = 0x000c, RR count = 0
Name "(5)apple(2)cz(7)connect(5)local(0)"
QTYPE A (1)
QCLASS 1
ANSWER SECTION:
empty
AUTHORITY SECTION:
Offset = 0x0028, RR count = 0
Name "(7)connect(5)local(0)"
TYPE SOA (6)
CLASS 1
TTL 3600
DLEN 43
DATA
PrimaryServer: (7)srvdc01[C028](7)connect(5)local(0)
Administrator: (10)hostmaster[C028](7)connect(5)local(0)
SerialNo = 5494
Refresh = 900
Retry = 600
Expire = 86400
MinimumTTL = 3600
ADDITIONAL SECTION:
empty
15.04.2011 04:06:24 0820 PACKET 0000000002491570 UDP Rcv 10.10.15.4 0037 Q [0001 D NOERROR] AAAA (5)apple(2)cz(7)connect(5)local(0)
UDP question info at 0000000002491570
Socket = 336
Remote addr 10.10.15.4, port 56467
Time Query=301, Queued=0, Expire=0
Buf length = 0x0fa0 (4000)
Msg length = 0x0028 (40)
Message:
XID 0x0037
Flags 0x0100
QR 0 (QUESTION)
OPCODE 0 (QUERY)
AA 0
TC 0
RD 1
RA 0
Z 0
CD 0
AD 0
RCODE 0 (NOERROR)
QCOUNT 1
ACOUNT 0
NSCOUNT 0
ARCOUNT 0
QUESTION SECTION:
Offset = 0x000c, RR count = 0
Name "(5)apple(2)cz(7)connect(5)local(0)"
QTYPE AAAA (28)
QCLASS 1
ANSWER SECTION:
empty
AUTHORITY SECTION:
empty
ADDITIONAL SECTION:
empty
15.04.2011 04:06:24 0820 PACKET 0000000002491570 UDP Snd 10.10.15.4 0037 R Q [8385 A DR NXDOMAIN] AAAA (5)apple(2)cz(7)connect(5)local(0)
UDP response info at 0000000002491570
Socket = 336
Remote addr 10.10.15.4, port 56467
Time Query=301, Queued=0, Expire=0
Buf length = 0x0fa0 (4000)
Msg length = 0x006c (108)
Message:
XID 0x0037
Flags 0x8583
QR 1 (RESPONSE)
OPCODE 0 (QUERY)
AA 1
TC 0
RD 1
RA 1
Z 0
CD 0
AD 0
RCODE 3 (NXDOMAIN)
QCOUNT 1
ACOUNT 0
NSCOUNT 1
ARCOUNT 0
QUESTION SECTION:
Offset = 0x000c, RR count = 0
Name "(5)apple(2)cz(7)connect(5)local(0)"
QTYPE AAAA (28)
QCLASS 1
ANSWER SECTION:
empty
AUTHORITY SECTION:
Offset = 0x0028, RR count = 0
Name "(7)connect(5)local(0)"
TYPE SOA (6)
CLASS 1
TTL 3600
DLEN 43
DATA
PrimaryServer: (7)srvdc01[C028](7)connect(5)local(0)
Administrator: (10)hostmaster[C028](7)connect(5)local(0)
SerialNo = 5494
Refresh = 900
Retry = 600
Expire = 86400
MinimumTTL = 3600
ADDITIONAL SECTION:
empty
15.04.2011 04:06:24 0820 PACKET 0000000002D797A0 UDP Rcv 10.10.15.4 0038 Q [0001 D NOERROR] A (5)apple(2)cz(0)
UDP question info at 0000000002D797A0
Socket = 336
Remote addr 10.10.15.4, port 56468
Time Query=301, Queued=0, Expire=0
Buf length = 0x0fa0 (4000)
Msg length = 0x001a (26)
Message:
XID 0x0038
Flags 0x0100
QR 0 (QUESTION)
OPCODE 0 (QUERY)
AA 0
TC 0
RD 1
RA 0
Z 0
CD 0
AD 0
RCODE 0 (NOERROR)
QCOUNT 1
ACOUNT 0
NSCOUNT 0
ARCOUNT 0
QUESTION SECTION:
Offset = 0x000c, RR count = 0
Name "(5)apple(2)cz(0)"
QTYPE A (1)
QCLASS 1
ANSWER SECTION:
empty
AUTHORITY SECTION:
empty
ADDITIONAL SECTION:
empty
15.04.2011 04:06:24 0820 PACKET 0000000003FD0BE0 UDP Snd 10.10.15.254 57a8 Q [1001 D NOERROR] A (5)apple(2)cz(0)
UDP question info at 0000000003FD0BE0
Socket = 5188
Remote addr 10.10.15.254, port 53
Time Query=0, Queued=0, Expire=0
Buf length = 0x0fa0 (4000)
Msg length = 0x0025 (37)
Message:
XID 0x57a8
Flags 0x0110
QR 0 (QUESTION)
OPCODE 0 (QUERY)
AA 0
TC 0
RD 1
RA 0
Z 0
CD 1
AD 0
RCODE 0 (NOERROR)
QCOUNT 1
ACOUNT 0
NSCOUNT 0
ARCOUNT 1
QUESTION SECTION:
Offset = 0x000c, RR count = 0
Name "(5)apple(2)cz(0)"
QTYPE A (1)
QCLASS 1
ANSWER SECTION:
empty
AUTHORITY SECTION:
empty
ADDITIONAL SECTION:
Offset = 0x001a, RR count = 0
Name "(0)"
TYPE OPT (41)
CLASS 4000
TTL 32768
DLEN 0
DATA
Buffer Size = 4000
Rcode Ext = 0
Rcode Full = 0
Version = 0
Flags = 80 DO
Allerdings konnte ich jetzt wieder ein total komisches Verhalten beobachten:
1.) DNS-Anfrage von Client (10.10.15.4) über URL apple.cz an Server (10.10.15.1) hat nicht funktioniert
2.) Habe die DNS-Anfrage 10x wieder holt und hat nicht funktioniert
3.) Habe mich am Server (10.10.15.1) eingeloggt und siehe da => im Moment des Logins hat die obige DNS-Anfrage funktioniert
Ich glaube ich fange an zu spinnen ...
Ich werde Gärtner!!!
Hier noch ein anderes Verhalten ca. 20 Minuten später:
Hier habe ich ca. 10 Minuten gewartet
Erneut ca. 10 Minuten gewartet
1.) DNS-Anfrage von Client (10.10.15.4) über URL apple.cz an Server (10.10.15.1) hat nicht funktioniert
2.) Habe die DNS-Anfrage 10x wieder holt und hat nicht funktioniert
3.) Habe mich am Server (10.10.15.1) eingeloggt und siehe da => im Moment des Logins hat die obige DNS-Anfrage funktioniert
Ich glaube ich fange an zu spinnen ...
Ich werde Gärtner!!!
Hier noch ein anderes Verhalten ca. 20 Minuten später:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.
C:\Users\Administrator.CONNECT>nslookup
Standardserver: srvdc01.connect.local
Address: 10.10.15.1
> googoo.com
Server: srvdc01.connect.local
Address: 10.10.15.1
*** googoo.com wurde von srvdc01.connect.local nicht gefunden: Server failed.
> apple.cz
Server: srvdc01.connect.local
Address: 10.10.15.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an srvdc01.connect.local.
> googoo.com
Server: srvdc01.connect.local
Address: 10.10.15.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an srvdc01.connect.local.
> googoo.com
Server: srvdc01.connect.local
Address: 10.10.15.1
Nicht autorisierende Antwort:
DNS request timed out.
timeout was 2 seconds.
Name: googoo.com
Address: 12.71.216.180
> googoo.com
Server: srvdc01.connect.local
Address: 10.10.15.1
Nicht autorisierende Antwort:
Name: googoo.com
Address: 12.71.216.180
> googoo.com
Server: srvdc01.connect.local
Address: 10.10.15.1
Nicht autorisierende Antwort:
Name: googoo.com
Address: 12.71.216.180
> apple.us
Server: srvdc01.connect.local
Address: 10.10.15.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an srvdc01.connect.local.
> apple.us
Server: srvdc01.connect.local
Address: 10.10.15.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an srvdc01.connect.local.
>
@82959
was passiert wenn du die DNS Anfrage vom Server aus stellst?
Haben die Clients feste IP Adressen oder bekommen sie die via DHCP?
Bezüglich des Logs: ich schätze die dritte Anfrage hat funktioniert, oder?
VG. mhard666
was passiert wenn du die DNS Anfrage vom Server aus stellst?
Haben die Clients feste IP Adressen oder bekommen sie die via DHCP?
Bezüglich des Logs: ich schätze die dritte Anfrage hat funktioniert, oder?
VG. mhard666
Nur zur Info: Das ist meiner Meinung nach ein richtiger (und funktionierender) Eintrag im Log für die DNS-Abfrage von google.com. Hier werden auch IP-Adressen von google.com zurück gegeben. Ist leider sehr lang weil auch IPv6 dabei ist.
15.04.2011 04:03:35 0820 PACKET 00000000022200C0 UDP Rcv 10.10.15.254 37f1 R Q [9081 DR NOERROR] A (6)google(3)com(0)
UDP response info at 00000000022200C0
Socket = 2160
Remote addr 10.10.15.254, port 53
Time Query=132, Queued=0, Expire=0
Buf length = 0x0fa0 (4000)
Msg length = 0x03a8 (936)
Message:
XID 0x37f1
Flags 0x8190
QR 1 (RESPONSE)
OPCODE 0 (QUERY)
AA 0
TC 0
RD 1
RA 1
Z 0
CD 1
AD 0
RCODE 0 (NOERROR)
QCOUNT 1
ACOUNT 6
NSCOUNT 14
ARCOUNT 22
QUESTION SECTION:
Offset = 0x000c, RR count = 0
Name "(6)google(3)com(0)"
QTYPE A (1)
QCLASS 1
ANSWER SECTION:
Offset = 0x001c, RR count = 0
Name "[C00C](6)google(3)com(0)"
TYPE A (1)
CLASS 1
TTL 209
DLEN 4
DATA 209.85.149.104
Offset = 0x002c, RR count = 1
Name "[C00C](6)google(3)com(0)"
TYPE A (1)
CLASS 1
TTL 209
DLEN 4
DATA 209.85.149.105
Offset = 0x003c, RR count = 2
Name "[C00C](6)google(3)com(0)"
TYPE A (1)
CLASS 1
TTL 209
DLEN 4
DATA 209.85.149.106
Offset = 0x004c, RR count = 3
Name "[C00C](6)google(3)com(0)"
TYPE A (1)
CLASS 1
TTL 209
DLEN 4
DATA 209.85.149.147
Offset = 0x005c, RR count = 4
Name "[C00C](6)google(3)com(0)"
TYPE A (1)
CLASS 1
TTL 209
DLEN 4
DATA 209.85.149.99
Offset = 0x006c, RR count = 5
Name "[C00C](6)google(3)com(0)"
TYPE A (1)
CLASS 1
TTL 209
DLEN 4
DATA 209.85.149.103
AUTHORITY SECTION:
Offset = 0x007c, RR count = 0
Name "(0)"
TYPE NS (2)
CLASS 1
TTL 515284
DLEN 20
DATA (1)c(12)root-servers(3)net(0)
Offset = 0x009b, RR count = 1
Name "(0)"
TYPE NS (2)
CLASS 1
TTL 515284
DLEN 4
DATA (1)a[C089](12)root-servers(3)net(0)
Offset = 0x00aa, RR count = 2
Name "(0)"
TYPE NS (2)
CLASS 1
TTL 515284
DLEN 4
DATA (1)m[C089](12)root-servers(3)net(0)
Offset = 0x00b9, RR count = 3
Name "(0)"
TYPE NS (2)
CLASS 1
TTL 515284
DLEN 4
DATA (1)l[C089](12)root-servers(3)net(0)
Offset = 0x00c8, RR count = 4
Name "(0)"
TYPE NS (2)
CLASS 1
TTL 515284
DLEN 4
DATA (1)j[C089](12)root-servers(3)net(0)
Offset = 0x00d7, RR count = 5
Name "(0)"
TYPE NS (2)
CLASS 1
TTL 515284
DLEN 4
DATA (1)g[C089](12)root-servers(3)net(0)
Offset = 0x00e6, RR count = 6
Name "(0)"
TYPE NS (2)
CLASS 1
TTL 515284
DLEN 4
DATA (1)b[C089](12)root-servers(3)net(0)
Offset = 0x00f5, RR count = 7
Name "(0)"
TYPE NS (2)
CLASS 1
TTL 515284
DLEN 4
DATA (1)f[C089](12)root-servers(3)net(0)
Offset = 0x0104, RR count = 8
Name "(0)"
TYPE NS (2)
CLASS 1
TTL 515284
DLEN 4
DATA (1)i[C089](12)root-servers(3)net(0)
Offset = 0x0113, RR count = 9
Name "(0)"
TYPE NS (2)
CLASS 1
TTL 515284
DLEN 4
DATA (1)e[C089](12)root-servers(3)net(0)
Offset = 0x0122, RR count = 10
Name "(0)"
TYPE NS (2)
CLASS 1
TTL 515284
DLEN 4
DATA (1)k[C089](12)root-servers(3)net(0)
Offset = 0x0131, RR count = 11
Name "(0)"
TYPE NS (2)
CLASS 1
TTL 515284
DLEN 4
DATA (1)h[C089](12)root-servers(3)net(0)
Offset = 0x0140, RR count = 12
Name "(0)"
TYPE NS (2)
CLASS 1
TTL 515284
DLEN 4
DATA (1)d[C089](12)root-servers(3)net(0)
Offset = 0x014f, RR count = 13
Name "(0)"
TYPE RRSIG (46)
CLASS 1
TTL 515284
DLEN 147
DATA
Type covered = NS
Algorithm = (null) (8)
Label count = 0
Original TTL = 518400
Expiration = 20110421000000
Inception = 20110413230000
Keytag = 34525
Signer's name = (0)
Signature:
93 64 1c a1 d3 ea 13 20 ff 20 a0 11 71 c6 b9 90
8b ff 6f 40 06 c5 6c c2 e0 de 2c bf 9c 5e bb 41
11 57 43 3b af 36 01 8b 80 cd 74 df bc e5 3b 66
8e 1f b3 38 d3 65 5a b0 7d 44 2b 7d 48 39 e8 ee
fd 60 35 03 d6 de c4 91 33 14 6b ba d0 f5 61 47
9d d5 0b a6 fd a0 86 7f 2d 89 5c 3c ac b8 2a 32
65 59 34 8d a9 71 0f 70 f4 87 2b 7e 2a 6e 15 54
86 a8 67 c6 0d f9 98 7a 05 bb 19 9a f0 c5 a9 0e
ADDITIONAL SECTION:
Offset = 0x01ed, RR count = 0
Name "[C0A6](1)a[C089](12)root-servers(3)net(0)"
TYPE A (1)
CLASS 1
TTL 602703
DLEN 4
DATA 198.41.0.4
Offset = 0x01fd, RR count = 1
Name "[C0A6](1)a[C089](12)root-servers(3)net(0)"
TYPE AAAA (28)
CLASS 1
TTL 602703
DLEN 16
DATA 2001:503:ba3e::2:30
Offset = 0x0219, RR count = 2
Name "[C0F1](1)b[C089](12)root-servers(3)net(0)"
TYPE A (1)
CLASS 1
TTL 602703
DLEN 4
DATA 192.228.79.201
Offset = 0x0229, RR count = 3
Name "[C087](1)c(12)root-servers(3)net(0)"
TYPE A (1)
CLASS 1
TTL 602703
DLEN 4
DATA 192.33.4.12
Offset = 0x0239, RR count = 4
Name "[C14B](1)d[C089](12)root-servers(3)net(0)"
TYPE A (1)
CLASS 1
TTL 602703
DLEN 4
DATA 128.8.10.90
Offset = 0x0249, RR count = 5
Name "[C11E](1)e[C089](12)root-servers(3)net(0)"
TYPE A (1)
CLASS 1
TTL 602703
DLEN 4
DATA 192.203.230.10
Offset = 0x0259, RR count = 6
Name "[C100](1)f[C089](12)root-servers(3)net(0)"
TYPE A (1)
CLASS 1
TTL 602703
DLEN 4
DATA 192.5.5.241
Offset = 0x0269, RR count = 7
Name "[C100](1)f[C089](12)root-servers(3)net(0)"
TYPE AAAA (28)
CLASS 1
TTL 602703
DLEN 16
DATA 2001:500:2f::f
Offset = 0x0285, RR count = 8
Name "[C0E2](1)g[C089](12)root-servers(3)net(0)"
TYPE A (1)
CLASS 1
TTL 602703
DLEN 4
DATA 192.112.36.4
Offset = 0x0295, RR count = 9
Name "[C13C](1)h[C089](12)root-servers(3)net(0)"
TYPE A (1)
CLASS 1
TTL 602703
DLEN 4
DATA 128.63.2.53
Offset = 0x02a5, RR count = 10
Name "[C13C](1)h[C089](12)root-servers(3)net(0)"
TYPE AAAA (28)
CLASS 1
TTL 602703
DLEN 16
DATA 2001:500:1::803f:235
Offset = 0x02c1, RR count = 11
Name "[C10F](1)i[C089](12)root-servers(3)net(0)"
TYPE A (1)
CLASS 1
TTL 602703
DLEN 4
DATA 192.36.148.17
Offset = 0x02d1, RR count = 12
Name "[C10F](1)i[C089](12)root-servers(3)net(0)"
TYPE AAAA (28)
CLASS 1
TTL 602703
DLEN 16
DATA 2001:7fe::53
Offset = 0x02ed, RR count = 13
Name "[C0D3](1)j[C089](12)root-servers(3)net(0)"
TYPE A (1)
CLASS 1
TTL 602703
DLEN 4
DATA 192.58.128.30
Offset = 0x02fd, RR count = 14
Name "[C0D3](1)j[C089](12)root-servers(3)net(0)"
TYPE AAAA (28)
CLASS 1
TTL 602703
DLEN 16
DATA 2001:503:c27::2:30
Offset = 0x0319, RR count = 15
Name "[C12D](1)k[C089](12)root-servers(3)net(0)"
TYPE A (1)
CLASS 1
TTL 602703
DLEN 4
DATA 193.0.14.129
Offset = 0x0329, RR count = 16
Name "[C12D](1)k[C089](12)root-servers(3)net(0)"
TYPE AAAA (28)
CLASS 1
TTL 602703
DLEN 16
DATA 2001:7fd::1
Offset = 0x0345, RR count = 17
Name "[C0C4](1)l[C089](12)root-servers(3)net(0)"
TYPE A (1)
CLASS 1
TTL 602703
DLEN 4
DATA 199.7.83.42
Offset = 0x0355, RR count = 18
Name "[C0C4](1)l[C089](12)root-servers(3)net(0)"
TYPE AAAA (28)
CLASS 1
TTL 602703
DLEN 16
DATA 2001:500:3::42
Offset = 0x0371, RR count = 19
Name "[C0B5](1)m[C089](12)root-servers(3)net(0)"
TYPE A (1)
CLASS 1
TTL 602703
DLEN 4
DATA 202.12.27.33
Offset = 0x0381, RR count = 20
Name "[C0B5](1)m[C089](12)root-servers(3)net(0)"
TYPE AAAA (28)
CLASS 1
TTL 602703
DLEN 16
DATA 2001:dc3::35
Offset = 0x039d, RR count = 21
Name "(0)"
TYPE OPT (41)
CLASS 4096
TTL 32768
DLEN 0
DATA
Buffer Size = 4096
Rcode Ext = 0
Rcode Full = 0
Version = 0
Flags = 80 DO
Hallo mhard666,
Neue Erkenntnis:
Ich habe das Paketfilter Log der Firewall (Astaro Virtual Appliance) geprüft und mir ist aufgefallen, dass Anfragen des Servers auf Port 53 (DNS) sporadisch gedroppt werden. Dieses Verhalten ist unerklärlich und könnte auch das Verhalten des Windows DNS-Server erklären btw. hat der Windows DNS-Server selbst vielleicht gar kein Problem (dies wäre vielleicht aus den obigen Logs ersichtlich, wobei ich diese, wie gesagt, selbst leider nicht interpretieren kann). Nur wurde eben die Firewall auch schon mehrfach geprüft (von verschiedenen Personen) und weißt keine falsche Konfiguration auf. Ich habe das ganze jetzt auch mal im Astaro Forum gepostet, vielleicht weiß da jemand was ob es bei irgendeiner Konstellation ein Problem mit der aktuellen Firmware gibt (Bug, Falsches Verhalten).
Wens interessiert, hier der Link zum Astaro Forum: http://www.astaro.org/astaro-gateway-products/management-networking-log ...
was passiert wenn du die DNS Anfrage vom Server aus stellst?
wenn ich die DNS-Anfrage vom Server stelle, dann funktioniert sie so gut wie immer. Ob sie wirklich 100% immer funktioniert kann ich nicht sagen, da das ganze unvorhersehbar Fehler aufweist und seinen eigenen Willen hat. Auf jeden Fall hat der Server sich selbst als DNS-Server eingetragen und zwar mit 10.10.15.1 und nicht mit 127.0.0.1.Neue Erkenntnis:
Ich habe das Paketfilter Log der Firewall (Astaro Virtual Appliance) geprüft und mir ist aufgefallen, dass Anfragen des Servers auf Port 53 (DNS) sporadisch gedroppt werden. Dieses Verhalten ist unerklärlich und könnte auch das Verhalten des Windows DNS-Server erklären btw. hat der Windows DNS-Server selbst vielleicht gar kein Problem (dies wäre vielleicht aus den obigen Logs ersichtlich, wobei ich diese, wie gesagt, selbst leider nicht interpretieren kann). Nur wurde eben die Firewall auch schon mehrfach geprüft (von verschiedenen Personen) und weißt keine falsche Konfiguration auf. Ich habe das ganze jetzt auch mal im Astaro Forum gepostet, vielleicht weiß da jemand was ob es bei irgendeiner Konstellation ein Problem mit der aktuellen Firmware gibt (Bug, Falsches Verhalten).
Wens interessiert, hier der Link zum Astaro Forum: http://www.astaro.org/astaro-gateway-products/management-networking-log ...
Haben die Clients feste IP Adressen oder bekommen sie die via DHCP?
Die Clients bekommen vom Server via DHCP alles zugewiesen. Es wir die IP-Adresse des Clients im selben Subnet zugewiesen. Außerdem bekommt der Client als DNS-Server die IP-Adresse des Windows DC (10.10.15.1) zugewiesen. Eigentlich alles Standard.Bezüglich des Logs: ich schätze die dritte Anfrage hat funktioniert, oder?
Das ganze Log das ich gepostet habe, ist nur 1 einzige Anfrage (außer ich habe mich grad eben total vertan). Die 1 Abfrage (Client -> nslookup -> apple.cz) besteht höchstwahrscheinlich aus diesen 6 Unterabfragen die der Server in diesem Fall durchgeführt hat. Im Log waren auch Abfragen bei der der DNS-Wirrwarr funktioniert hat und da waren als Rückmeldung auch die IP-Adressen enthalten. In meiner Anfrage steht immer nur als Rückmeldung "empty". Komischerweise bezieht sich die letzte Unterabfrage auf die IP-Adresse 10.10.15.254 was unsere Firewall ist und dies könnte auch ein Indiz sein, dass der Windows DNS-Server eigentlich richtig funktioniert, nur dass er von der Firewall erst gar nichts zurück bekommt, weil das Paket gedroppt wird (siehe Erklärung oben).
Hi ITInfrastruktur,
das zweite Log ist aber nur der Teil, wo der Windows-DNS vom Firewall-DNS eine Antwort bekommt.
Wir haben zwar auch eine Astaro im Unternehmen, bin mir aber mit nachfolgender Aussage jetzt nicht ganz sicher:
Kann man nicht auf der Astaro Proxy und Firewallregeln benutzerdefiniert anlegen? Mit Benutzerauthentifizierung über AD. Möglicherweise ist für "unprivilegierte" Benutzer der DNS gesperrt? Wenn du dich auf dem Server als Admin einloggst hättest du ggf. die entsprechenden Rechte... Naja ist so ne Überlegung
VG mhard666
das zweite Log ist aber nur der Teil, wo der Windows-DNS vom Firewall-DNS eine Antwort bekommt.
Wir haben zwar auch eine Astaro im Unternehmen, bin mir aber mit nachfolgender Aussage jetzt nicht ganz sicher:
Kann man nicht auf der Astaro Proxy und Firewallregeln benutzerdefiniert anlegen? Mit Benutzerauthentifizierung über AD. Möglicherweise ist für "unprivilegierte" Benutzer der DNS gesperrt? Wenn du dich auf dem Server als Admin einloggst hättest du ggf. die entsprechenden Rechte... Naja ist so ne Überlegung
VG mhard666
Hallo mhard666,
Wobei dies auch dann für uns eigentlich nicht in Frage kommen würde, weil wir ja unseren 2008er DNS-Server haben. Außerdem glaube ich das das Astaro in Bezug auf DNS gar nicht unterstützt. Die AD-Anbindung der Astaro wird eher verwendet wenn man den Astaro VPN-Dienst verwendet und sich per VPN direkt mit AD-Credentials authentifizieren will und nicht erst am Astaro nochmals einen separaten Benutzer anlegen will. Gleiches auch für bestimmte Application Filterungen, wo dann anhand der AD-Rechte unterschieden wird, ob man das darf oder nicht. Ich glaube das geht dann auch beim HTTP-Proxy. Der andere darf die Seite anschauen, der andere nicht -> eben anhand der AD-Rechte.
In unserem Fall haben wir eigentlich die einfachste Variante gewählt: Client <-> Windows DNS-Server <-> Astaro DNS-Server <-> Provider DNS-Server
Der Windows-DNS Server akzeptiert DNS Anfragen von allen Domänen-Clients. Der Astaro DNS-Server akzeptiert Anfragen nur vom Windows DNS-Server und nur der Astaro-DNS Server darf Anfragen an die Provider DNS-Server stellen.
Alles eine logische tolle Sache, wenns denn auch laufen würde
Auf jeden Fall mal vielen Dank für deine Rückmeldungen und Denkansätze! Das hat mir auf jeden Fall viel Unterstützung gegeben!
das zweite Log ist aber nur der Teil, wo der Windows-DNS vom Firewall-DNS eine Antwort bekommt.
Ja richtig, da bekommt der Windows DNS-Server vom Astaro DNS-Server die Antwort und die IP-Adressen. Wenn du den obigen allerletzten Log-Eintrag vergleichst, dann passiert da das selbe, außer dass der Astaro DNS-Server "Answer-Section" und der "Additonal-Section" jeweils "Empty" anführt. Somit also keine IP-Adresse(n) zurückliefert. So würde ich das interpretieren. Aber wie gesagt, mein erstes Mal mit den Logs und da bin ich nicht so der Spezialist Wir haben zwar auch eine Astaro im Unternehmen, bin mir aber mit nachfolgender Aussage jetzt nicht ganz sicher:
Kann man nicht auf der Astaro Proxy und Firewallregeln benutzerdefiniert anlegen? Mit Benutzerauthentifizierung über AD.
Möglicherweise ist für "unprivilegierte" Benutzer der DNS gesperrt? Wenn du dich auf dem Server als Admin
einloggst hättest du ggf. die entsprechenden Rechte... Naja ist so ne Überlegung
Ja grundsätzlich gibt es diese Möglichkeiten, allerdings haben uns die externen Berater damals bei unserer großen IT-Umstellung auf Windows Server 2008 R2 (von früheren 2003) davon abgeraten. Grund wäre folgender: Astaro kann das neue Active Directory von 2008 R2 nicht. Dafür müsse man am 2008er Server den Kompatibilitätsmodus für 2003 aktivieren, da Astaro nur mit 2003 kann. Da wir eine komplett neue Umgebung mit ausschließlich Windows 7 Clients und Windows 2008 R2 Servern haben, sollten wir keine Rückwärtskompatibilität mehr fahren. Astaro wird irgendwann ein Update erhalten und dann kann sich diese auch direkt ins 2008er Active Directory einhängen.Kann man nicht auf der Astaro Proxy und Firewallregeln benutzerdefiniert anlegen? Mit Benutzerauthentifizierung über AD.
Möglicherweise ist für "unprivilegierte" Benutzer der DNS gesperrt? Wenn du dich auf dem Server als Admin
einloggst hättest du ggf. die entsprechenden Rechte... Naja ist so ne Überlegung
Wobei dies auch dann für uns eigentlich nicht in Frage kommen würde, weil wir ja unseren 2008er DNS-Server haben. Außerdem glaube ich das das Astaro in Bezug auf DNS gar nicht unterstützt. Die AD-Anbindung der Astaro wird eher verwendet wenn man den Astaro VPN-Dienst verwendet und sich per VPN direkt mit AD-Credentials authentifizieren will und nicht erst am Astaro nochmals einen separaten Benutzer anlegen will. Gleiches auch für bestimmte Application Filterungen, wo dann anhand der AD-Rechte unterschieden wird, ob man das darf oder nicht. Ich glaube das geht dann auch beim HTTP-Proxy. Der andere darf die Seite anschauen, der andere nicht -> eben anhand der AD-Rechte.
In unserem Fall haben wir eigentlich die einfachste Variante gewählt: Client <-> Windows DNS-Server <-> Astaro DNS-Server <-> Provider DNS-Server
Der Windows-DNS Server akzeptiert DNS Anfragen von allen Domänen-Clients. Der Astaro DNS-Server akzeptiert Anfragen nur vom Windows DNS-Server und nur der Astaro-DNS Server darf Anfragen an die Provider DNS-Server stellen.
Alles eine logische tolle Sache, wenns denn auch laufen würde
Auf jeden Fall mal vielen Dank für deine Rückmeldungen und Denkansätze! Das hat mir auf jeden Fall viel Unterstützung gegeben!
Zitat von @82959:
Hallo mhard666,
> das zweite Log ist aber nur der Teil, wo der Windows-DNS vom Firewall-DNS eine Antwort bekommt.
Ja richtig, da bekommt der Windows DNS-Server vom Astaro DNS-Server die Antwort und die IP-Adressen. Wenn du den obigen
allerletzten Log-Eintrag vergleichst, dann passiert da das selbe, außer dass der Astaro DNS-Server
"Answer-Section" und der "Additonal-Section" jeweils "Empty" anführt. Somit also keine
IP-Adresse(n) zurückliefert. So würde ich das interpretieren. Aber wie gesagt, mein erstes Mal mit den Logs und da bin
ich nicht so der Spezialist
Hallo mhard666,
> das zweite Log ist aber nur der Teil, wo der Windows-DNS vom Firewall-DNS eine Antwort bekommt.
Ja richtig, da bekommt der Windows DNS-Server vom Astaro DNS-Server die Antwort und die IP-Adressen. Wenn du den obigen
allerletzten Log-Eintrag vergleichst, dann passiert da das selbe, außer dass der Astaro DNS-Server
"Answer-Section" und der "Additonal-Section" jeweils "Empty" anführt. Somit also keine
IP-Adresse(n) zurückliefert. So würde ich das interpretieren. Aber wie gesagt, mein erstes Mal mit den Logs und da bin
ich nicht so der Spezialist
Also da steht nur die Anfrage an den Astaro-DNS (Snd 10.10.15.254)
15.04.2011 04:06:24 0820 PACKET 0000000003FD0BE0 UDP Snd 10.10.15.254 57a8 Q [1001 D NOERROR] A (5)apple(2)cz(0)Die Antwort ist warscheinlich geblockt worden...
... oder die Anfrage ist gar nicht angekommen...
Hier jetzt mein vorläufiger Lösungsansatz. Mal schauen was die User dazu nächste Woche meinen
1.) Die bestehende DNS-Weiterleitung vom Windows DNS-Server auf den Astaro DNS-Server ergänzt. Der Windows DNS-Server darf jetzt in 2. Ebene auch direkt auf den primären DNS-Server des Providers weiterleiten. In 3. Ebene darf der Windows DNS-Server auch direkt auf den sekundären Backup-DNS-Server des Providers weiterleiten.
2.) Astaro erlaubt jetzt außerdem ausschließlich dem Windows DNS-Server, dass DNS-Anfragen zusätzlich zum Astaro DNS-Server auch direkt an die beiden DNS-Server des Providers gesendet werden dürfen.
3.) So frägt jetzt der Windows DNS-Server immer erst beim Astaro DNS-Server an. Bekommt er von da keine Antwort oder werden ev. die Pakete wieder gedroppt, dann fragt er im 2. und 3. Schritt die DNS-Server direkt beim Provider ab.
Ist zwar ne eher Quick&Dirty Lösung weil es das eigentliche Problem nicht behebt, aber mehrere Fallbacks zur Verfügung stellt, wenn wieder das ursprüngliche Problem auftritt.
Vielen Dank für die bisherige Hilfe (vor allem an mhard666) und ich werde berichten ob wir das ganze jetzt endgültig so lassen, wenn die User nächste Woche zufrieden Internet surfen können.
Schöne Grüße
ITinfrastruktur
1.) Die bestehende DNS-Weiterleitung vom Windows DNS-Server auf den Astaro DNS-Server ergänzt. Der Windows DNS-Server darf jetzt in 2. Ebene auch direkt auf den primären DNS-Server des Providers weiterleiten. In 3. Ebene darf der Windows DNS-Server auch direkt auf den sekundären Backup-DNS-Server des Providers weiterleiten.
2.) Astaro erlaubt jetzt außerdem ausschließlich dem Windows DNS-Server, dass DNS-Anfragen zusätzlich zum Astaro DNS-Server auch direkt an die beiden DNS-Server des Providers gesendet werden dürfen.
3.) So frägt jetzt der Windows DNS-Server immer erst beim Astaro DNS-Server an. Bekommt er von da keine Antwort oder werden ev. die Pakete wieder gedroppt, dann fragt er im 2. und 3. Schritt die DNS-Server direkt beim Provider ab.
Ist zwar ne eher Quick&Dirty Lösung weil es das eigentliche Problem nicht behebt, aber mehrere Fallbacks zur Verfügung stellt, wenn wieder das ursprüngliche Problem auftritt.
Vielen Dank für die bisherige Hilfe (vor allem an mhard666) und ich werde berichten ob wir das ganze jetzt endgültig so lassen, wenn die User nächste Woche zufrieden Internet surfen können.
Schöne Grüße
ITinfrastruktur
Die Antwort ist warscheinlich geblockt worden...
Ja, auch meiner Meinung nach ist die Anfrage geblockt worden, wie sich später herausgestellt hat (Paketfilter Log). Komisch nur, dass das passiert ist, da der Windows DNS-Server beim Astaro DNS-Server anfragen/abfragen/Tee trinken usw. darf. Ich will jetzt nicht von irgendeinem Bug bei der Astaro sprechen, aber es ist echt alles top konfiguriert.
Darf dann der Windows-DNS eigentlich selbst DNS Anfragen ins internet senden? Würde sinn machen, weil wenn die DNS-Weiterleitung geblockt ist könnten dann die Stammhinweisserver direkt angefragt werden - wenn die Option in den DNS Einstellungen gesetzt ist.
Darf dann der Windows-DNS eigentlich selbst DNS Anfragen ins internet senden?
Ja darf er.Würde sinn machen, weil wenn die DNS-Weiterleitung geblockt ist könnten dann die Stammhinweisserver direkt angefragt werden - wenn die Option in den DNS Einstellungen gesetzt ist.
Ja diese Option ist gesetzt. Also im Prinzip erst Astaro, dann prim. Provider, dann sek. Provider, dann Stammhinweisserver. Allerdings muss ich ehrlich sagen, dass ich nicht ganz Glücklich bin. Bei dieser Variante gibts sicherlich auch wieder Timeouts da das alles gar nicht so schnell gehen kann.Und da bin ich immer der der sagt, dass jedes Problem lösbar ist (sein muss). Manchmal kommen IT'ler zu mir und sagen, dass ein Problem für einen Kunden nicht gelöst werden kann. Dann sag ich immer jedes Problem ist irgendwie lösbar, oder willst du dem Kunden sagen, dass er sich sein Problem sonst wo hinschieben soll? Auch wenn die ganze Bude abbrennt, dann ist hald die Lösung, dass man ne neue IT kaufen muss
Zum Abschluss und was wirklich war:
Da der Domänenkontroller als vmWare VM lief, hab ich den Domänenkontroller aus einem kompletten Backup wiederhergestellt. Dieser war nämlich nicht das Problem, obwohl uns die Fehlersuche am Windows DNS Dienst ganz schön auf trapp gehalten hat.
Problem war, dass die DNS Anfragen in einem nicht nachvollziehbaren Muster an der Firewall geblockt wurden. Dies war sehr schwer raus zu finden, da es nicht immer passiert ist, sondern selten mal zwischendurch und anscheinend der Windows DNS Dienst dann teilweise Anfragen gecacht hat und auch nicht mehr immer weitergeleitet hat.
Schlussendlich: Lösung keine, nur ein Workaround an der Firewall eingerichtet. Es muss irgendein Bug an der Firmware der Firewall sein, der unter einer ganz bestimmten Konstellation dieses Problem verursacht. Weiter sind wir noch nicht gekommen. Aktuell funktioniert es mit einem Workaround.
Workaround: Zusätzliche DNS Regeln eingerichtet - die normalerweise definitiv nicht notwendig sind - und Sachen nochmals explizit per Regel freigegeben, die sowieso schon freigegeben waren. Naja, komisch, nicht sauber gelöst, aber es funktioniert!
Da der Domänenkontroller als vmWare VM lief, hab ich den Domänenkontroller aus einem kompletten Backup wiederhergestellt. Dieser war nämlich nicht das Problem, obwohl uns die Fehlersuche am Windows DNS Dienst ganz schön auf trapp gehalten hat.
Problem war, dass die DNS Anfragen in einem nicht nachvollziehbaren Muster an der Firewall geblockt wurden. Dies war sehr schwer raus zu finden, da es nicht immer passiert ist, sondern selten mal zwischendurch und anscheinend der Windows DNS Dienst dann teilweise Anfragen gecacht hat und auch nicht mehr immer weitergeleitet hat.
Schlussendlich: Lösung keine, nur ein Workaround an der Firewall eingerichtet. Es muss irgendein Bug an der Firmware der Firewall sein, der unter einer ganz bestimmten Konstellation dieses Problem verursacht. Weiter sind wir noch nicht gekommen. Aktuell funktioniert es mit einem Workaround.
Workaround: Zusätzliche DNS Regeln eingerichtet - die normalerweise definitiv nicht notwendig sind - und Sachen nochmals explizit per Regel freigegeben, die sowieso schon freigegeben waren. Naja, komisch, nicht sauber gelöst, aber es funktioniert!
Kann es evtl. sein, dass deine Firewall die DNS-Abfragen blockt, weil sie es für eine Art Angriff hält?
Wir hatten hier unseren Spass, dass z.B. GPOs nicht gezogen wurden, der pcs der Telefonanlage nicht hoch kam usw. Nach langem Monitoren und etlichen (hundert) MB Wireshark-Logfiles stellte sich heraus, dass die Firewall die genannten Anfragen (in diesem Falle Pings) über eine "Abnormally Detection" blockiert hat.
Da DNS-Anfragen auch gern mal in sehr hoher Anzahl auftreten könnte ich mir da durchaus nen Zusammenhang vorstellen, insbesonder dann, wenn die DNS-Anfragen noch durch nen VPN-Tunnel wandern, weil der DNS irgendwo zentral steht.
*Just my 5 Cent*
Cheers,
jsysde
Wir hatten hier unseren Spass, dass z.B. GPOs nicht gezogen wurden, der pcs der Telefonanlage nicht hoch kam usw. Nach langem Monitoren und etlichen (hundert) MB Wireshark-Logfiles stellte sich heraus, dass die Firewall die genannten Anfragen (in diesem Falle Pings) über eine "Abnormally Detection" blockiert hat.
Da DNS-Anfragen auch gern mal in sehr hoher Anzahl auftreten könnte ich mir da durchaus nen Zusammenhang vorstellen, insbesonder dann, wenn die DNS-Anfragen noch durch nen VPN-Tunnel wandern, weil der DNS irgendwo zentral steht.
*Just my 5 Cent*
Cheers,
jsysde
@jsysde
Danke für deinen Hinweis. Dies kann bei uns eher nicht zutreffen, da DNS-Abfragen speziell erkannt werden und normalerweise auch speziell gehandelt werden. Daher ist es auszuschließen, dass durch DNS-Abfragen irgend ein Attacken-Muster erkannt wird und dann durch IPS irgendwelche Gegenmaßnahmen eingeleitet werden.
Ich tendiere nach wie vor zu einem Bug in der Firmware bzw. das die Konfigurationsdatei in der alle Einstellungen gespeichert werden einen Fehler aufweist, der über das Konfigurationsmenü nicht ersichtlich ist. Ich bin mir ganz ganz sicher, dass wenn wir die Firewall neu installieren und alle Einstellungen wieder wie aktuell händisch einpflegen (ohne Backup zurückspielen), dass dann alles wieder reibungslos funktioniert.
Trotzdem vielen Dank für deinen Denkansatz!
Danke für deinen Hinweis. Dies kann bei uns eher nicht zutreffen, da DNS-Abfragen speziell erkannt werden und normalerweise auch speziell gehandelt werden. Daher ist es auszuschließen, dass durch DNS-Abfragen irgend ein Attacken-Muster erkannt wird und dann durch IPS irgendwelche Gegenmaßnahmen eingeleitet werden.
Ich tendiere nach wie vor zu einem Bug in der Firmware bzw. das die Konfigurationsdatei in der alle Einstellungen gespeichert werden einen Fehler aufweist, der über das Konfigurationsmenü nicht ersichtlich ist. Ich bin mir ganz ganz sicher, dass wenn wir die Firewall neu installieren und alle Einstellungen wieder wie aktuell händisch einpflegen (ohne Backup zurückspielen), dass dann alles wieder reibungslos funktioniert.
Trotzdem vielen Dank für deinen Denkansatz!
Hallo Leute,
ich habe ein ähnliches Problem. Der Server ist ein Windows Server 2008 R2 Datacenter als DC mit DNS und DHCP. Das Ganze lief seit Monaten problemlos...
Seit Mitte April können, wie bereits oben schon beschrieben, keine externen Anfragen per Firefox, nslookup, IE mehr ins Internet gestellt werden. Es kommt nen Timeout. Domaininterne Anfragen werden rasend schnell beantwortet. DIe Auslastung des Servers kann als niedrig beschrieben werden.
Es muss also an der Weiterleitung des Windows DNS-Dienstes liegen. Als Weiterleitungs-DNS sind aktuell die beiden Google Server eingetragen, 8.8.8.8 und 8.8.4.4. Die Auflösung der Adressen über diese beiden Server ist einwandfrei.
Was wir bereits probiert haben
Es wurden auch schon die Provider-DNS probiert, ohne Erfolg.
Die Windows-Firewall ist auf der Domain-Ebene ausgeschaltet, auch eine komplette Deaktivierung änderte nichts.
Unser Router, ein Draytek Vigor 2850, ist gleichzeitig die Firewall nach "draußen". Dort sind für den DNS-Dienst auf dem Server TCP/UDP geöffnet. Auch eine testweise Deaktivierung dieser brachte nichts.
EDNS ist übrigens auch aus und die Weiterleitungen sind aktiviert. Auch das Häckchen, dass die Stammhinweise zu nutzen sind, wenn die Weiterleitung nicht klappt, war drin und ist jetzt wieder raus. Änderte auch nichts!
Ich habe sogar die DNS-Cache-Funktion auf dem Server desktiviert, sodass jede externe Anfrage neu weitergeleitet werden muss... änderte nichts!
weitere Auffälligkeiten
Die Auflösung funktioniert nach dem Reboot des Server für eine gewisse Zeit, diese Zeitspanne ist aber unregelmäßig. Es sind manchmal mehrere Tage, manchmal auch nur wenige Minuten. In den Logfiles wird nichts problematisches erfasst. Ein Neustart des DNS-Dienstes behebt das Problem vorerst.
Weiterhin lasse ich sämtliche Firewall-Entscheidungen vom Router protokollieren. Auch dort wird nichts von bzw. an 8.8.8.8 bzw. 8.8.4.4 blockiert. Auch andere Anfragen über TCP/UDP Port 53 werden nicht blockiert. Es gehen nicht mal welche raus bzw. rein! Komischerweise behebt ein Neustart der Routerfirewall ebenfalls das Problem....
Das Ganze ist mir höchst schleierhaft. Es lief wie beschrieben monatelang völlig problemlos und schnell. An der Konfiguration wurde rein gar nichts verändert. Das Einzige, was mir dabei in den Sinn kommt ist ein Windows-Update.
Testweise habe ich den kostenlosen virtuellen Server 2008 (ohne R2) EPS von MS geladen und den DNS-Server-Dienst installiert. Ich habe meine Zonen als Secondary-Zones repliziert, den Server jedoch nicht als zweiten DC hochgestuft. Er war quasi ein Client mit Backup-DNS. Die IP des Virtuellen habe ich dann als Secondary-DNS per DHCP an die Clients verteilt. Lief super die Konfig, keinerlei Ausfälle. Doch das kann doch nicht die Lösung sein!
Wer kann mir helfen? Ich kann doch nicht überall zwei Server hinstellen bzw. einen Virtuellen mitlaufen lassen...
ich habe ein ähnliches Problem. Der Server ist ein Windows Server 2008 R2 Datacenter als DC mit DNS und DHCP. Das Ganze lief seit Monaten problemlos...
Seit Mitte April können, wie bereits oben schon beschrieben, keine externen Anfragen per Firefox, nslookup, IE mehr ins Internet gestellt werden. Es kommt nen Timeout. Domaininterne Anfragen werden rasend schnell beantwortet. DIe Auslastung des Servers kann als niedrig beschrieben werden.
Es muss also an der Weiterleitung des Windows DNS-Dienstes liegen. Als Weiterleitungs-DNS sind aktuell die beiden Google Server eingetragen, 8.8.8.8 und 8.8.4.4. Die Auflösung der Adressen über diese beiden Server ist einwandfrei.
Was wir bereits probiert haben
Es wurden auch schon die Provider-DNS probiert, ohne Erfolg.
Die Windows-Firewall ist auf der Domain-Ebene ausgeschaltet, auch eine komplette Deaktivierung änderte nichts.
Unser Router, ein Draytek Vigor 2850, ist gleichzeitig die Firewall nach "draußen". Dort sind für den DNS-Dienst auf dem Server TCP/UDP geöffnet. Auch eine testweise Deaktivierung dieser brachte nichts.
EDNS ist übrigens auch aus und die Weiterleitungen sind aktiviert. Auch das Häckchen, dass die Stammhinweise zu nutzen sind, wenn die Weiterleitung nicht klappt, war drin und ist jetzt wieder raus. Änderte auch nichts!
Ich habe sogar die DNS-Cache-Funktion auf dem Server desktiviert, sodass jede externe Anfrage neu weitergeleitet werden muss... änderte nichts!
weitere Auffälligkeiten
Die Auflösung funktioniert nach dem Reboot des Server für eine gewisse Zeit, diese Zeitspanne ist aber unregelmäßig. Es sind manchmal mehrere Tage, manchmal auch nur wenige Minuten. In den Logfiles wird nichts problematisches erfasst. Ein Neustart des DNS-Dienstes behebt das Problem vorerst.
Weiterhin lasse ich sämtliche Firewall-Entscheidungen vom Router protokollieren. Auch dort wird nichts von bzw. an 8.8.8.8 bzw. 8.8.4.4 blockiert. Auch andere Anfragen über TCP/UDP Port 53 werden nicht blockiert. Es gehen nicht mal welche raus bzw. rein! Komischerweise behebt ein Neustart der Routerfirewall ebenfalls das Problem....
Das Ganze ist mir höchst schleierhaft. Es lief wie beschrieben monatelang völlig problemlos und schnell. An der Konfiguration wurde rein gar nichts verändert. Das Einzige, was mir dabei in den Sinn kommt ist ein Windows-Update.
Testweise habe ich den kostenlosen virtuellen Server 2008 (ohne R2) EPS von MS geladen und den DNS-Server-Dienst installiert. Ich habe meine Zonen als Secondary-Zones repliziert, den Server jedoch nicht als zweiten DC hochgestuft. Er war quasi ein Client mit Backup-DNS. Die IP des Virtuellen habe ich dann als Secondary-DNS per DHCP an die Clients verteilt. Lief super die Konfig, keinerlei Ausfälle. Doch das kann doch nicht die Lösung sein!
Wer kann mir helfen? Ich kann doch nicht überall zwei Server hinstellen bzw. einen Virtuellen mitlaufen lassen...
