☰

Verwirrung mit DNS auf Windows Server und Sonicwall

tag-icon • tag-icon windows-server-2008 domain-name-system sonicwall
Verwirrung mit DNS auf Windows Server und Sonicwall

Ich habe heute Abend ein bisschen darüber gelesen, wie wir unser Schulnetzwerk am besten für den Internetzugang einrichten. Es funktioniert, wie es ist, aber von Zeit zu Zeit gibt es Probleme beim Client/Server-Zugriff auf das Internet. (Hinweis: Die Sonicwall erkennt das Internet immer.)

Mein Setup ist wie folgt:

Internet---Sonicwall---Managed Switch---Win 2k8 r2 Server | Clients und Drucker

Die Sonicwall

  • LAN-Zone mit einer IP in unserem IP-Bereich
  • WAN-Zone mit statischer, vom ISP zugewiesener IP und DNS auf Google DNS eingestellt und DNS des ISPs als Backup

Der Windows Server (nur ein interner Dateiserver)

  • Active Directory
  • DNS (auf 127.0.0.1 eingestellt)
  • DHCP dynamisch für einen kleinen Gästebereich (Telefone),
  • DHCP statisch für Geräte und Schüler- und Lehrer-Clients (zu Filterzwecken)

Die Kunden

  • Gateway auf Sonicwall-IP eingestellt
  • DNS auf Server-IP eingestellt (auf einigen Win8-Systemen musste ich für die Internetverbindung einen alternativen DNS auf 8.8.8.8 einstellen).

Also, zu den Fragen:

Nach dem, was ich heute Abend gelesen habe, hätte ich wohl Folgendes tun sollen:

  • Das Sonicwall WAN sucht nach innen zur Server-IP für DNS
  • Der Server ist so eingestellt, dass er nach außen auf Google/ISP DNS blickt
  • Der DNS des Clients ist auf die Server-IP und das Gateway auf die Sonicwall-IP eingestellt

Kann das jemand bestätigen? Ich bin verwirrt. Wenn Sonicwall beim Server nach Internet-DNS sucht, werden meine Clients dann nicht A) den Server verlangsamen und B) kein Internet haben, wenn der Server ausgeschaltet ist?

Wenn das nicht die beste Vorgehensweise ist, was dann? Mache ich es schon richtig? Sollte der Client-DNS auf den Server UND den ISP schauen?

Danke!

Antwort1

Da auf dem Server Active Directory/DNS läuft, können die ClientsMUSSLassen Sie ihren DNS auf dem Server einrichten, um eine ordnungsgemäße Domänenauflösung/Konnektivität mit internen Ressourcen zu gewährleisten.

Der Schlüssel besteht darin, den DNS-Dienst des Servers so zu konfigurieren, dass alle nicht lokalen Abfragen an einen externen Resolver (wie Google [8.8.8.8; 8.8.4.4]) weitergeleitet werden. Der DNS-Verkehr ist so gering, dass er keine erkennbaren Auswirkungen auf Ihren Server haben sollte, es sei denn, Sie haben den Cache zu niedrig eingestellt.

Der Netzwerkstapel des Servers sollte so konfiguriert sein, dass er für die DNS-Auflösung auf 127.0.0.1 (oder seine lokale Adresse) schaut, und der Dienst sollte mit Weiterleitungen konfiguriert sein.

Was Sonicwall betrifft, können Sie es auf beide Arten einstellen. Wenn Sie möchten, dass Sonicwall sowohl interne als auch externe FQDNs auflösen kann, muss es Ihren lokalen Server zur Auflösung verwenden. Wenn Sie nur externe benötigen, stellen Sie es auf die Resolver Ihres ISPs oder von Google ein.

Antwort2

Wie JuxVP bereits erklärt hat, alle in die Domäne eingebundenen Windows-Clientsmussmüssen ihren DNS auf den AD-Server einstellen, da sonst viele Dienste fehlschlagen, insbesondere die Authentifizierung. Alle anderen internen Clients müssen ihren DNS auf den AD-Server einstellen, wenn sie interne Namen auflösen sollen.

Darüber hinaus sind die in die Domäne eingebundenen Windows-Clientsdarf nichtSind andere DNS-Server aufgelistet, die keine AD-Abfragen auflösen können, da Windows die Suchreihenfolge nicht garantiert. Beispiel: Sie haben die folgende Konfiguration auf einem Client:

DNS1: 192.168.10.10 (AD server)
DNS2: 8.8.8.8 (Google DNS)

dann treten wahrscheinlich Authentifizierungsprobleme, ungewöhnliche Hänger oder andere Kommunikationsprobleme auf. Dies liegt daran, dass der Client möglicherweise Googles DNS abfragt adserver.domain.localund der Server von Google mit statt mit einem Timeout antwortet does not exist. Der Client probiert den anderen Server nur aus, wenn der erste nicht antwortet. Wenn der Client eine does not existAntwort erhält, gibt er auf und die Suche schlägt fehl.

Antwort3

  • Der DNS-Server von Sonicwall sollte für die DNS-IP-Adresse Ihres ISPs konfiguriert sein.
  • Ihr Server (d. h. der Domänen-DNS-Server) kann mit Weiterleitungen zum DNS von Google konfiguriert werden.
  • Der DNS des Endpunkts sollte für den DNS-Server der Domäne konfiguriert werden.

Antwort4

Da Sie im Bildungsbereich arbeiten, empfehle ich Ihnen, Ihren internen DNS-Server so zu konfigurieren, dass alle Anfragen an OpenDNS weitergeleitet werden. OpenDNS bietet spezielle Pläne nur für K-12 an, um die CIPA-Konformität einzuhalten [0]. OpenDNS bietet auch Malware-Schutz, bei dem Anfragen nach schädlichen Ressourcen blockiert werden.

Wenn Sie die oben genannten Einstellungen vorgenommen haben, stellen Sie alle Hosts/Geräte/usw. in Ihrem Netzwerk so ein, dass sie Ihren internen DNS-Server verwenden. Dadurch wird sichergestellt, dass Ihre Clients erfolgreich intern eine Verbindung miteinander herstellen können. Dies ist insbesondere dann wichtig, wenn Sie Microsoft Active Directory verwenden.

Konfigurieren Sie als Nächstes alle Router-ACLs und Firewall-Regeln so, dass nur ausgehende DNS-Anfragen von Ihrem internen DNS-Server an OpenDNS-Server zugelassen werden. Dies hat den Vorteil, dass einige Malware-Programme versuchen werden, DNS-Anfragen direkt an öffentliche Nameserver zu senden. Diese Konfiguration stellt sicher, dass die Anfrage über Ihre Server und schließlich über OpenDNS läuft, wo sie hoffentlich abgefangen wird. Jeder Host, der den internen DNS-Server nicht verwendet (Firewall-Löschprotokolle), sollte auf Fehlkonfigurationen oder Malware untersucht werden, da dies ein Hinweis auf eine Kompromittierung sein könnte.

Implementieren Sie abschließend Router-ACLs und/oder Firewall-Regeln, um den Zugriff auf Ihren DNS-Server aus dem öffentlichen Internet zu blockieren.

[0]https://www.opendns.com/enterprise-security/solutions/k-12/

verwandte Informationen