8
DNS Auflösung funktioniert sporadisch kurzfristig nicht
Hallo,
kurz zu unserer Umgebung wir haben zwei Windows DNS-Server (Windows Server 2008 R2) welche über eine bedingte Weiterleitung für bestimmte Domänen DNS Abfragen auf einem anderen DNS-Server eines Geschäftspartners durchführen. Die Verbindung zum Geschäftspartner erfolgt über MPLS. Die Server sind über einen Cisco Layer 3 Switch (SG500-28 (2x im Stack)) und zwei Mikrotik RB2011 (VRRP) mit der MPLS Anbindung verbunden.
Problem:
Unser Monitoringsystem (NAGIOS) meldet sporadisch (ca. 2-3x pro Tag), dass ein Server unsers Geschäftspartners nicht erreichbar sei. Der Ping erfolgt jedoch auf den FQDN minütlich. Ein Ping die direkte IP des Servers ist immer möglich. Wenn ich zum Zeitpunkt einer solchen Fehlermeldung einen manuellen Ping auf den FQDN durchführe, erreiche ich diesen ebenfalls nicht. Ein nslookup ist ebenfalls nicht möglich. Eine Minute später bzw. nach Löschen des DNS-Server Caches ist die DNS Auflösung wieder möglich.
E-Mail von NAGIOS:
Benachrichtigungstyp: PROBLEM
Geraetename: host.abc.local
State: DOWN
IP-Adresse: host.abc.local
Zusaetzliche Informationen:
check_icmp: Failed to resolve host.abc.local
Datum: 25.09.2015 Uhrzeit: 15:12
Hatte jemand schon mal ein ähnliches Problem? Kann es sein, dass sporadisch Pakete von der Firewall blockiert werden?
Freundliche Grüße
taschaue
kurz zu unserer Umgebung wir haben zwei Windows DNS-Server (Windows Server 2008 R2) welche über eine bedingte Weiterleitung für bestimmte Domänen DNS Abfragen auf einem anderen DNS-Server eines Geschäftspartners durchführen. Die Verbindung zum Geschäftspartner erfolgt über MPLS. Die Server sind über einen Cisco Layer 3 Switch (SG500-28 (2x im Stack)) und zwei Mikrotik RB2011 (VRRP) mit der MPLS Anbindung verbunden.
Problem:
Unser Monitoringsystem (NAGIOS) meldet sporadisch (ca. 2-3x pro Tag), dass ein Server unsers Geschäftspartners nicht erreichbar sei. Der Ping erfolgt jedoch auf den FQDN minütlich. Ein Ping die direkte IP des Servers ist immer möglich. Wenn ich zum Zeitpunkt einer solchen Fehlermeldung einen manuellen Ping auf den FQDN durchführe, erreiche ich diesen ebenfalls nicht. Ein nslookup ist ebenfalls nicht möglich. Eine Minute später bzw. nach Löschen des DNS-Server Caches ist die DNS Auflösung wieder möglich.
E-Mail von NAGIOS:
Benachrichtigungstyp: PROBLEM
Geraetename: host.abc.local
State: DOWN
IP-Adresse: host.abc.local
Zusaetzliche Informationen:
check_icmp: Failed to resolve host.abc.local
Datum: 25.09.2015 Uhrzeit: 15:12
Hatte jemand schon mal ein ähnliches Problem? Kann es sein, dass sporadisch Pakete von der Firewall blockiert werden?
Freundliche Grüße
taschaue
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 283895
Url: https://administrator.de/contentid/283895
Ausgedruckt am: 25.11.2024 um 08:11 Uhr
8 Kommentare
Neuester Kommentar
tach..
also nach deiner beschreibung - hat das nix mit deiner firewall zu tun, nicht mal sporadisch...
ich tippe eher auf eine falsche DNS konfig... was sagen denn deine dns logs dazu ?
ist die listenreihenfolge der ip-adressen, die als weiterleitungen auf deinem dns-server definiert sind richtig ?
oder es ist doch dene firewall- und die packete werden auf 512byte gekürzt... bei langen abfragen, netzen mit vielen host´s - kann das auch sein.
lg
frank
also nach deiner beschreibung - hat das nix mit deiner firewall zu tun, nicht mal sporadisch...
ich tippe eher auf eine falsche DNS konfig... was sagen denn deine dns logs dazu ?
ist die listenreihenfolge der ip-adressen, die als weiterleitungen auf deinem dns-server definiert sind richtig ?
oder es ist doch dene firewall- und die packete werden auf 512byte gekürzt... bei langen abfragen, netzen mit vielen host´s - kann das auch sein.
lg
frank
Danke für die Antwort!
Ach hab ich vergessen: Log Einträge gibt es auf den beiden Servern dazu keine. Der letzte Eintrag stammt vom 23.9. und enhält die Info, dass der DNS-Server neugestartet wurde. Neustart wurde durch mich ausgelöst.
Die Listenreihenfolge ist korrekt - es werden zwei DNS-Server verwendet - beide beim Geschäftspartner. Beide sind erreichbar im Fenster beim Hinzufügen der einzelnen Server erscheint jedoch die Fehlermeldung Der Server mit dieser IP-Adresse ist für die erforderliche Zone nicht autorisierend. bei beiden Servern.
Das mit der Paketlänge muss ich prüfen.
LG
taschaue
Ach hab ich vergessen: Log Einträge gibt es auf den beiden Servern dazu keine. Der letzte Eintrag stammt vom 23.9. und enhält die Info, dass der DNS-Server neugestartet wurde. Neustart wurde durch mich ausgelöst.
Die Listenreihenfolge ist korrekt - es werden zwei DNS-Server verwendet - beide beim Geschäftspartner. Beide sind erreichbar im Fenster beim Hinzufügen der einzelnen Server erscheint jedoch die Fehlermeldung Der Server mit dieser IP-Adresse ist für die erforderliche Zone nicht autorisierend. bei beiden Servern.
Das mit der Paketlänge muss ich prüfen.
LG
taschaue
hmmmm,
dann mach die zone autorisierend...
warum sollen DNS-Zonen übertragen werden? für die namensauflösung der hosts in der anderen gesamtstruktur genügt eine bedingte Weiterleitung oder eine Stub-Zone.
lg
frank
dann mach die zone autorisierend...
warum sollen DNS-Zonen übertragen werden? für die namensauflösung der hosts in der anderen gesamtstruktur genügt eine bedingte Weiterleitung oder eine Stub-Zone.
lg
frank
Hallo ,
das koennte am Nagios liegen , den der DNS luebbt ja.
Ich wuerde den service ( hier ping mit check_icmp ) in der config anpassen.
Also ab wann die Email an die Admins rausgeht.
Gruss
das koennte am Nagios liegen , den der DNS luebbt ja.
Ich wuerde den service ( hier ping mit check_icmp ) in der config anpassen.
Also ab wann die Email an die Admins rausgeht.
Gruss
Ich meinte mit den beiden DNS Servern, die DNS Server unseres Geschäftspartners und da kann ich die Zone leider nicht autorisieren.
Lg
taschaue
Lg
taschaue
Ja aber kurzfristig geht ja wirklich kein Ping durch(ca. 1Minute) Von da her hätte Nagios recht.
lg
taschaue
lg
taschaue
Solche Effekte habe ich schon gesehen, wenn der DNS-Resolver DNSSEC validieren will, aber der Upstream-Server es nicht kann.
Das schon erwähnte UDP 512 Byte Problem ist aber auch ein beliebter Ansatz.
Das schon erwähnte UDP 512 Byte Problem ist aber auch ein beliebter Ansatz.
So, habe nun den Fehler gefunden.
Es lag am Mikrotik Router bzw. am VRRP. Im Mikrotik Manual steht, dass der physikalischen Ethernetschnittstelle das Netzwerk 10.10.10.10/24 zugewiesen werden muss under der VRRP Schnittstelle nur die gemeinsame Adresse 10.10.10.11/32. Das führt jedoch dazu, dass das Routing über die physikalische Schnittstelle erfolgt und nicht über das VRRP Interface.
Ich habe nun beim VRRP Interface 10.10.10.11/24 und beim physikalischen Interface 10.10.10.10/32 und die Pakete werden nun richtig (lt. Torch) geroutet.
Vielen Dank für die Tipps,
taschaue
Es lag am Mikrotik Router bzw. am VRRP. Im Mikrotik Manual steht, dass der physikalischen Ethernetschnittstelle das Netzwerk 10.10.10.10/24 zugewiesen werden muss under der VRRP Schnittstelle nur die gemeinsame Adresse 10.10.10.11/32. Das führt jedoch dazu, dass das Routing über die physikalische Schnittstelle erfolgt und nicht über das VRRP Interface.
Ich habe nun beim VRRP Interface 10.10.10.11/24 und beim physikalischen Interface 10.10.10.10/32 und die Pakete werden nun richtig (lt. Torch) geroutet.
Vielen Dank für die Tipps,
taschaue
