none
DNS Probleme wenn ein Standort offline ist RRS feed

  • Allgemeine Diskussion

  • Hallo Community,

    ich habe in unserem Netzwerk ein Problem und vielleicht könnt ihr mir helfen.

    Vorab der grobe Überblick:
    Standort A hat den ersten Domain Controller (Server 2012), natürlich mit DNS AD-integrierter Zone und allen FSMO Rollen.
    Hier steht auch ein Exchange 2016, sollte mit dem Problem aber nichts zu tun haben.
    Standort B hat einen zusätzlichen DC (Server 2012 R2) der gleichen Domain in einem eigenen AD Standort.

    Beide Standorte sind über VPN verbunden, grundsätzlich funktioniert auch alles korrekt.
    DCDiag etc. läuft alles ohne Probleme durch, AD Standorte sind sauber gepflegt mit den korrekten Subnetzen.
    Alles ist eine Domain, keine Subdomains etc.

    Jetzt komme ich zum Problem:
    Wenn der Standort B offline ist, beginnt das komplette DNS System im Hauptstandort A verrückt zu spielen.
    Es können z.B. nicht mal mehr interne Mails gesendet werden, diese bleiben mit einem DNS Error in der Warteschlange hängen.
    Auch die PC Anmeldungen und Dateizugriffe machen dann Probleme.
    Wenn der Standort B wieder online ist, funktioniert alles wieder ohne Probleme.

    Ich kann mir aber nicht erklären warum das so ist. Grundsätzlich sollte DNS doch weiter funktionieren wenn ein Standort offline ist?
    Der DNS Server aus Standort B ist nämlich nirgends im Standort A als DNS Server eingetragen.
    Außer natürlich am DC/DNS Server im Standort A als sekundärer DNS.

    Kennt jemand dieses Problem oder hat eine Idee zur Lösung.
    Ich bin für jeden Tipp Dankbar.

    Gruß
    Roman

    Freitag, 10. März 2017 08:18

Alle Antworten

  • Hallo Roman,

    das liest sich alles sehr verwirrend und daher ein "Schuss ins Blaue".

    Hast Du Deinem Active Directory alle IP Subnetze bekannt geben und den Standorten zugeordnet. Oder anders ausgedrückt: Befinden sich alle Systeme in der "DEFAULT First Site"?

    Für weiter Erläuterungen benötigen wir etwas mehr Informationen. Wie sieht Eure physikalische AD Struktur aus (Sites&Services + IP Subnetze)(Verbindung zwischen Standort A & B, ist das eine VPN Strecke) und nicht vergessen wie ist das IP Routing zwischen den Standorten eingerichtet.

     Gruß Malte


    • Bearbeitet Malte Pabst Freitag, 10. März 2017 20:29 es fehlte ein "r"
    Freitag, 10. März 2017 20:17
  • Moin,

    wie ist denn euer VPN beschaffen? Welche Geräte bauen die Verbindung auf?

    Hat der DC in Site A evtl. mehrere Beine?

    Das Fehlerbild (wenn wir jetzt einfach mal annehmen, dass Du bei den Subnetzen und Sites wirklich nichts übersehen hast) sieht doch arg danach aus, als ob die DCs die VPN-Verbindung zueinander aufbauen würden (mit RRAS oder so) und die so entstandenen virtuellen IP-Adressen im DNS registrieren würden. Besteht die VPN-Verbindung, kann die Adresse halt auch erreicht werden. Bricht der VPN-Tunnel ab, bleibt die Adresse noch eine Weile im DNS, kann aber nicht mehr erreicht werden. Irgendwie so.

    Was sagt denn DCDIAG, wenn der VPN-Tunnel mal weg ist?


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    Freitag, 10. März 2017 21:14
  • Hallo zusammen!

    Danke für eure Infos, hier meine Antworten:
    Alle Subnetze sind sauber unter AD Standorte und Dienste gepflegt.
    Natürlich sind nicht alle Subnetze und Server in der Default-First-Site sondern unter den entsprechenden Sites.
    Pro physikalischem Standort mit DC ist eine Site angelegt, darin ist das jeweilige Subnetz und der DC.
    Die IPSec VPN Verbindung wird mittels 2 Watchguard Hardware Firewalls hergestellt.
    Es handelt sich um bidirektionale Any<->Any Tunnel.
    Bei einer IPSec VPN Verbindung gibt es keine virtuellen IP Adressen.

    Da es eine Domain ist, kennen alle DNS Server alle Einträge, die Zonen sind AD integriert.

    Klar kann der DC in Site B nicht mehr erreicht werden, wenn diese nicht mehr per VPN verbunden ist,
    das darf aber doch nicht zu DNS Problemen in Site B führen?

    Die Zeit für Prüfungen ist natürlich immer sehr kurz, wenn das Problem auftritt.
    Beim letzten Mal war der Fehler in DCdiag, dass der RPC Server nicht erreichbar ist -> was ja logisch ist.

    Hilft euch das ein bisschen weiter?

    Gruß

    Montag, 13. März 2017 08:15
  • Hallo Roman,

    die Frage von Evgenij zum Thema Multi-Home-DCs und Deine Antwort, schließt das schon mal aus.

    Du hast pro Site je einen DC. Korrekt?

    Deine Clients nutzen immer als primären DNS Server einen DNS Dienst am eigenen AD Standort.
    - manuell oder über DHCP konfiguriert.
    Welche DNS Server hast Du auf Deinen DCs als primären DNS hinterlegt (127.0.0.1 oder einen DC im anderen Standort)?
    Eher unwahrscheinlich, ich frage es trotzdem ab. Hast Du als sekundäre DNS Server u.U. einen externen DNS Server auf den DNS Clients eingerichtet (8.8.8.8 oder den DNS Server Deines Providers)?

    Gruß Malte

    Montag, 13. März 2017 21:08
  • Hallo Malte!

    Korrekt, pro Site ein DC.
    Ebenfalls korrekt, alle Clients einer Site nutzen den DC der eigenen Site - zugewiesen per DHCP.
    Primärer DNS auf meinen DC's ist deren jeweilige IP, aber nicht localhost (127.0.0.1)
    Über dieses Thema kann man ewig lesen, mir wurde die IP und nicht 127.0.0.1 empfohlen. (vom MCT Trainer)
    Sekundärer DNS meiner DC's ist der jeweilige DC im anderen Standort, kein externer DNS wie google etc.
    Es müssen ja interne lookups funktionieren, das hilft mir google auch nichts.
    Forwarder an den DNS Servern sind die empfohlenen DTAG Root DNS Server.

    Blöderweise ist das ganze meiner Meinung nach in einer virtuellen Testumgebung nicht wirklich nachzustellen.

    Gruß und Danke

    Donnerstag, 16. März 2017 19:47
  • Hallo Roman,

    ich hole mal etwas aus.

    Wir konfigurieren bei mehreren DCs am Standort immer den anderen DC als primären DNS Server und 127.0.0.1 als sekundären DNS Server in der NIC Konfiguration. Das hat den Vorteil, dass bei einem Reboot, die AD Dienste nicht warten müssen bis die lokalen ad integrierten Dienste bereit sind DNS Anfragen zu beantworten. Sollte der jeweils andere DC ausfallen, dann erfolgt ein Fail back auf "localhost" und der DC kann weiter alle DNS Auflösungen durchführen. Sobald weitere Standorte im Spiel sind, konfigurieren wir dir DCs der anderen Standorte als 3. DNS Server.

    Das hat jedoch keine Auswirkung auf Deine Clients, sondern dient nur dem schnelleren Rebootverhalten der DCs.

    Deinen Clients solltest Du als Primären DNS Server immer einen DC am eigenen Standort mitgeben. Wenn möglich als sekundären DNS auch einen DNS am eigenen Standort.

    Da Du am Standort A einen Exchange betreibst und dieser ist sehr abhängig von den Domaincontrollerdiensten, hast Du die Möglichkeit am Standort A einen 2. DC in Betrieb zu nehmen und diesen gleichzeitig als sekundären DNS Server in die NIC Konfig des Exchange aufzunehmen?

    Gruß Malte

    Donnerstag, 16. März 2017 20:44
  • Hallo Malte,

    die Idee mit dem Reboot ist gut - leider habe ich momentan nur jeweils einen DC.

    Wahrscheinlich ist es das einfachste, am Standort A einen 2ten DC zu installieren.
    (So ganz kurzfristig werde ich das aber zeitlich nicht schaffen...)
    Die Regel, dass Exchange kein DC sein soll gilt immer noch, oder?

    Gruß Roman

    Mittwoch, 22. März 2017 22:42
  • Die Regel, dass Exchange kein DC sein soll gilt immer noch, oder?

    Ja. "Sollte" wäre wohl eher richtig - die Konstellation ist (leider) offiziell supported, bringt aber im täglichen Leben nur Probleme. MS hat sich nie dazu durchringen lassen, das offiziell zu verdonnern, sonder beschränkt sich auf die Empfehlung, es nicht zu tun...

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    Donnerstag, 23. März 2017 07:16
  • Vielleicht noch eine Frage, sind alle Domaincontroller deiner Infrastruktur auch Globaler Katalog?

    Gruß

    Mario

    Donnerstag, 23. März 2017 07:27
  • Liebe Gemeinde,

    die Hauptfrage ist, dass DNS bei Verlust einer Standortkopplung ausfällt. Das betrifft Clients und auch den Exchange Server.

    also muss doch geklärt werden, ob die Verfügbarkeit der DNS Auflösung unabhängig vom Zustand der VPN Brücken funktioniert. Das sollte man über alternative DNS Server in den Netzwerkkartenkonfigurationen (DHCP oder manuell) sicherstellen.
    1. DNS Server immer am eigenen Standort.
    2. DNS Server am eigenen Standort oder wenn nicht möglich in einem remote Standort.
    In jedem Fall muss natürlich die DNS Zone Deines ADs auf den DNS Servern bereitgestellt werden.

    Ausnahmen bilden u.U. die Domaincontroller.

    Solange Du ein Single-Domain Deployment hast, können alle DCs gleichzeitig die Funktion Global Catalog ausführen.

    Exchange auf einem DC zu installieren, würde ich nicht empfehlen. Du verlierst einige desasterrecovery Optionen für Exchange.

    Ich würde im ersten Schritt mir einen "unwichtigen" Client schnappen und mit Hilfe der Routingtabelle auf diesem Client den Ausfall der VPN Strecke simulieren.

    route add SUBNET_REMOTESITE MASK SUBNETMASK_REMOTESITE NICHTEXISTIERENDE_IP.

    Beispiel:
    Das normale Default Gateway ist die IP 192.168.22.1 und es gibt eine freie IP-Adresse 192.168.22.7, die remote Site hat das Netz 192.168.23.0/24 dann:
    route add 192.168.23.0 mask 255.255.255.0 192.168.22.7
    (Ein Reboot des Clients entfernt den Routingeintrag oder route del 192.168.22.0)

    Wie verhält sich der Client?

    Gruß Malte

    Donnerstag, 23. März 2017 12:36