Mögliche DNS-Probleme beim Internetaufbau (Zusammenspiel pfSense & Windows DNS)

JeGr

Hi :)

Definiere: "richtig konfigurieren" ;) Das ist immer abhängig der Situation.

Wir nutzen im "internen Netz" einen Windows DNS-Server (für die Namensauflösung im LAN, ActiveDirectory etc.). Die IP-Adresse des Windows-DNS ist auch auf allen Clients im LAN eingetragen bzw. wird autom. via DHCP verteilt. Zusätzlich ist auf dem Windows-Server (2008 R2) eine Weiterleitung an die ISP-DNS eingerichtet, für Anfragen an das Internet, welcher der DNS-Server intern nicht auflösen kann.

Das ist prinzipiell OK, macht aber nur dann Sinn, wenn man den DNS Forwarder in der pfSense nicht nutzt, dafür wäre dieser nämlich eigentlich prädestiniert. Muss aber nicht genutzt werden, da der AD Server eh den Großteil alleine erledigt. Gibt es noch einen zweiten DNS Server intern (2. DC?)

Nun machen sich (seit der Einrichtung von pfSense) teilweise Probleme beim Internet-Seitenaufbau bemerkbar. Dies äußert sich so, indem der Seitenaufbau auf allen verbundenen Clients sehr, sehr lange dauert, obwohl die DSL-Leitungen (eingerichtet als MultiWAN in der pfSense) kaum beansprucht sind.
Ist in der Konfiguration noch irgendwo der Wurm drinne? Bzw. kann der langsame Aufbau von Internetseiten auf den Clients mit einer fehlerhaften Einstellung des DNS zu tun haben?

Das hängt davon ab, was genau langsam ist. DNS Probleme sind meist erkennbar dadurch, dass der initiale Connect zu einer Seite ewig kein Ergebnis bringt (meist in der Statuszeile des Browsers begleitet von "Auflösen von xxx.yy"). Also die DNS Abfrage SEHR lange dauert, bis sie ein Ergebnis bringt. Sobald das aber da ist, geht der Rest des Seitenaufbaus flott und ohne Wartezeit, herumklicken auf der gleichen Seite ist dann auch schnell. Nur die nächste (neue) Seite wieder langsaaaam.

Sollte das der Fall sein, müsste man von hinten bis vorne analysieren:

am Client: welchen DNS Server (oder welche Server) hat der Client zugewiesen bekommen
funktioniert die DNS Auflösung am Client zuverlässig (Win: nslookup, Linux: host, dig, nslookup) für mehrere DNS Namen (möglichst welche die man selbst noch nicht angesurft hat. Sinnvoll hier große Firmen mit denen man sonst nix zu tun hat ;) Ich nehme gerne sowas wie novell.de, sap.de, etc.)
Wenn hier bei mancher Abfrage es schon lange dauert, nachsehen: wer liefert das Ergebnis (der AD Server? Pfsense?)
Firewall Logs auf der pfSense prüfen - wird DNS o.ä. geblockt?
Auf AD Server einloggen und dort die Konfiguration prüfen: lokales DNS OK? AD OK? Forwarder richtig konfiguriert? Erreichbar? Liefern auch ein Ergebnis?

Da du MultiWAN erwähnt hast wäre noch zu prüfen:
6) Sind beide WANs vom gleichen Anbieter?
7) Bekommen beide WANs die gleichen DNS Server?
8) Kann der AD Server seinen Forwarder überhaupt über BEIDE WANs erreichen? Bei 2 unterschiedlichen Providern bspw. könnte es sein, dass der Forwarder im AD Server überhaupt nicht über die 2. Leitung funktioniert

Das sind im Groben die Dinge die mir dazu einfallen ;)

Grüßend
Jens

9fisi1

Hallo Jens,

zunächst danke ich für deine Antwort ;)

Ich habe das "Szenario" einmal vereinfacht visualisiert (um das "richtig konfigurieren" zu definieren ;)):

Und genau das von Dir beschrieben Problem beim Seitenaufbau machte sich in der gezeigten Konstellation bemerkbar. D.h. wird eine Seite im Browser geöffnet z.B. "www.heise.de" dauert es "Ewigkeiten", bis die Seite "aufgelöst / geladen ist" (erkennbar an dem "drehenden Kreis im Tab des Browsers). Ist die Seite einmal "aufgelöst", geht es rasend schnell. Genauso Downloads funktionieren, wenn diese einmal gestartet sind, sehr zügig! Daher auch die Vermutung eines DNS-Problems.

Noch kurz ein paar Infos zur Netzwerkinfrastruktur:

die pfSense wird zurzeit nur als "reiner" MultiWAN-LoadBalancer zum Internetaufbau genutzt - es sind 2 DSL-Router (vom gleichen ISP) angebunden sowie ein DSL-Modem von einem weiteren, anderen ISP, über das die pfSense eine PPoE-Verbindung herstellen soll!
DNS-Anfragen werden nicht geblockt, weder intern im LAN noch zum WAN (hat vorher, mit nur einem DSL-Anschluss) ohne Probleme funktioniert!

Nun zur Analyse:

Die Clients erhalten (wie in der Skizze erkennbar) immer die IP des Windows-DNS-Servers, damit die Kommunikation im AD ordnungsgemäß funktioniert, (Client und Server)-Namen im LAN aufgelöst werden können etc..
"nslookup" von einem Client auf einen anderen Client oder Servernamen im LAN funktioniert ohne Probleme und ohne größere Verzögerung / nslookup auf z.B. "heise.de" funktioniert auch, zum Teil aber auch arg verzögert / langsam! (Daher vermute ich auch eine Fehlkonfiguration in der Weiterleitung im Windows-DNS, wenn der Client z.B. über einen anderen ISP im MultiWAN "rausgeht"?…
Das Ergebnis liefert der Windows-DNS
DNS wird nicht geblockt - wurde auch nocheinmal explizit mit einer Rule zugelassen
Die Weiterleitungen auf dem Windows-DNS sind DNS-Server-IPs der ISPs (kann das Problem hiermit zusammenhängen? - muss ich hier die pfSense-IP eintragen, oder die IP der Router - und was mache ich mit dem ISP, welcher die Verbindung über PPoE aufbaut?)
Zwei WANs vom gleichen Anbieter, die dritte WAN-Verbindung (PPoE) von einem anderen ISP
theoretisch müssten doch die beiden gleichen WANs (vom selben Anbieter) die gleichen DNS-Server erhalten (Verbindung wird ja hier über die DSL-Router aufbaut) und WAN3 erhält eine andere DNS-IP, da anderer ISP!

Vielen Dank schonmal
und
Viele Grüße!

pfSense_Szenario_skizze.jpg_thumb

JeGr

Hallo,

danke für die Skizze, das macht einiges leichter. Da ich denke 1)-5) sind OK, werde ich gleich weitermachen mit

Kann, muss aber nicht. Selbst wenn bspw. 2 Lines zu Vodafone gehen, müssen diese nicht den gleichen DNS geliefert bekommen. Was aber der Fall sein sollte ist, dass egal über welche der beiden Lines, die Vodafone DNSe antworten sollten. Allerdings weiß man nie, wie die Banausen gerade bei Telekom und Vodafone ihre Dial-In Lines und DNSe handhaben. Bspw. schert sich weder Telekom noch Vodafone oft um gesetzte TTLs im DNS sondern expired nach eigenem gusto, aber das ist ein anderes Problem. Es könnte aber sein, dass die DNSe von Line #1 bspw. für Line #2 nur "extern" erreichbar sind und die dort nicht abfragbar. Je nach routing wäre das denkbar.

Mir fallen 2 Möglichkeiten ein, wie man weiter vorgehen kann.

Vergiß die Provider DNSe. Man ist darauf eh nicht angewiesen und oftmals bringen die auch mehr Probleme als Gutes (bspw. erzwungene Weiterleitungen bei NOT_FOUNDs oder redirects bei Vertippern)
Lass die pfSense entscheiden, welcher DNS über welche Line abgefragt wird.
klingt im ersten Moment nett, aber in meinen Augen überwiegen die Vorteile von 1). Um das ganze aber erstmal auf DNS runterzubrechen und auszuschließen gehe einmal wie folgt vor:

a1) Wenn dir Google nicht zuwider ist, stelle auf der pfSense die beiden Google DNSe ein: 8.8.8.8 und 8.8.4.4. Sonst keinen. Lasse auch nicht die DNS Server von den Providern beim DialIn überschreiben (gibts einen Haken für).
a2) Wenn du kein Fan von Googles DNSen bist (gibt ja einige nach dem NSA Debakel die da jetzt nen großen Bogen rum machen), gehe auf http://www.opennicproject.org/ und nimm die beiden DNSe die dir am nächsten stehen.
b) Trage die beiden DNS Server, die du oben ausgewählt hast (Google/OpenNic) als einzige Forwarder auch in deinen AD DNS Server ein.
c) Jetzt sollte nirgends mehr irgendein Provider DNS drin sein.
d) Teste das Phänomen.

Wenn es damit gelöst ist, bleibt es dir überlassen, wer das DNS Forwaring übernehmen soll. Du könntest auch die pfSense in deinen AD DNS eintragen. Damit hast du die Möglichkeit, wenn du bspw. ein neues Subnetz ins LAN nimmst oder noch WLAN Gäste, etc., für diese einen eigenen Netzbereich zu stellen, der nicht den AD DNS und DHCP bekommt (Gäste haben nichts im AD zu schaffen), sondern statt dessen beides von der pfSense. Trotzdem hast du dann nur EINE zentrale Stelle, wo du nach DNS Problemen schauen musst (es sei denn dein AD macht Sperenzchen).

Außerdem würde ich empfehlen, noch einen zweiten DNS an die Clients mit auszuliefern. Ist der AD mal weg kann niemand mehr irgendwas machen, was richtig schmerzen kann. Einen zweiten DNS zu stellen ist da einfacher.

Eine veritable Möglichkeit wäre bspw.:

AD-DNS stellt DHCP und liefert DNS1 sich selbst, DNS2 die pfSense
AD hat als Forwarder OpenNIC o.ä.
pfSense hat als Forwarder ebenso OpenNIC ö.ä. (selbes wie oben)
pfSense DNS Forwarder hat eine Zusatzeinstellung, dass alle Abfragen auf "domain.local" (oder wie deine Domain intern auch heißt) an 10.10.10.1 geschickt werden. Somit kann auch pfSense als dein 2. DNS Anfragen auf AD Domainnamen beantworten indem es sie weiterreicht.
Fällt AD aus, können Clients via DNS2 auf pfSense zumindest noch alles externe auflösen, nur interne Dinge nicht mehr.

So würde ich das bauen :)

Grüßend
Jens

9fisi1

Hallo Jens,

vielen lieben Dank für die ausführliche, fundierte Antwort!

Prinzipiell habe ich persönlich kein Problem damit, die public "Google-DNS-Server" zu nutzen, müsste es aber mit den Kollegen abklären, ob die Probleme mit der 'Datenkrake' haben. Ansonsten ist der Hinweis mit dem "Opennicproject" eine sehr gute Alternative, danke!

Nun nocheinmal kurz zum Verständnis (wenn ich am Montag die erste mögliche/vorgeschlagene Lösung teste werde):
1. Die Google public DNS-Server IPs "8.8.8.8 & 8.8.4.4" trage ich auf der pfSense in der "General Setup" unter "DNS servers" für jedes der 3 WAN-Interfaces ein (?für jedes WAN-Interface die gleiche Google-DNS-IP oder mixen die 8.8.8.8 und 8.8.8.4?) und nehme den Haken bei "overridden by…" heraus.
2. Muss ich bis aufs "enablen" des DNS-Forwarders noch etwas ändern bzw. was muss ich dann noch in den "Services" unter "DNS Forwarder" auf der pfSense einstellen?
3. Nehme ich auf dem internen Windows-DNS-Server (AD) unter "Weiterleitungen" die DNS-IPs der ISPs (Telekom) heraus und trage auch hier die beiden Google-DNS-Server 8.8.8.8 und 8.8.4.4 ein.

Ich habe vergessen zu erwähnen, dass es in naher Zukunft natürlich noch einen zusätzlichen Replikations-Server (Art: "Secondary-DC" - nennt man ja nicht mehr so...), zweiten AD & DNS-Server geben wird, welcher dann auch auf den Clients im LAN, als "Alternativer DNS-Server" gesetzt wird / per DHCP verteilt wird, um den von die angesprochenen SPOF vermeiden zu können!

Die Lösung, nur die pfSense-IP (192.168.1.1) im Windows-DNS unter "Weiterleitungen" einzutragen hatte ich schoneinmal probiert - und (soweit ich mich erinnern kann) bin ich dabei immer auf das Problem gestoßen, dass der Windows-DNS-Server die IP "nicht richtig auflösen konnte" bzw. die Eingabe der pfSense-IP nach der Überprüfung immer mit einem "roten X-Symbol" quittiert wurde und nur die öffentlich zugänglichen DNS-Server der Telekom ordnungsgemäß geprüft werden konnten (mit "grünen Haken" gekennzeichnet wurden)...

Vielen Dank nochmals,
Gruß.

JeGr

Gerne :)

Zu deinen Verständnisfragen:

8.8.8.8 und 8.8.4.4 sind in "General Setup" unter "DNS servers" einzutragen, richtig. Als Gateway hinten "none" auswählen sollte auch funktionieren, da dann keine Präferenz vergeben wird. Ich denke die Beschreibung mit "should be at least" bezieht sich auf genau diese Problematik, nämlich, dass nicht jeder DNS über jede Verbindung auch sauber erreichbar ist. Alternativ könnte man sich vom opennicproject statt 2 gleich 3 aussuchen und jeder Verbindung einen zuweisen.
Service / DNS forwarder:

Enable DNS forwarder
Require Domain (denn "nur Namen" sollte er eigentlich an den ADS weitergeben bzw. die Domain sollte ergänzt werden)
Do not forward private reverse lookups (das sollte man eh nie, da draußen kein DNS der Welt wissen kann, wie das interne Netz bei dir aufgebaut ist ;))
Interfaces (nach gusto, ich denke bei dir wohl nur LAN)
Unter "domain overwrites" fügst du die lokale ADS Domain ein:

Domains: domain.local
IP: 10.10.10.1
Description: ADS domain

Noch ein zusätzlicher Tipp: "domain.local" ist natürlich durch deine eigene AD Domain zu ersetzen. Ich würde darauf achten (und inzwischen steht das glaube ich sogar in den MS Docs), NICHT .local zu verwenden, sondern etwa .lan
Die Begründung ist einfach: Inzwischen ist durch Protokolle wie zeroconf/bonjour etc. die .local Domäne eine Art inoffizieller Standard geworden. Die Protokolle sind dazu da um ohne große Konfiguration (ähnlich DHCP etc.) automatisch Geräte zu identifizieren (Drucker, etc.) und diese anzubieten. Diese mDNS Auflösungen sind meist mit .local versehen. Hat man nun eine lokale ADS Domain mit .local kann das bei einigen Clients (Linux bspw.) zu ziemlichem Durcheinander führen.

Der zukünftige 2. DNS kann dann natürlich problemlos die Arbeit der pfSense übernehmen. Dann muss nicht die Sense als 2. eingetragen werden und auch keine Weiterleitung.

Was mich eher irritiert ist die IP der Sense (192.168.1.1) während dein LAN 10.10.10.x hat? Wie geht das zusammen? Sieht irgendwie aus als würde was fehlen.

Ich mache das mit DNS forwarder und Weiterleitung zu bestimmtem DNS für Domains aus dem VPN Tunnel. Ich habe 2-3 statische VPN Tunnel und alle Abfragen an Domains aus den Tunnel-Locations werden über den Tunnel somit an deren DNS übergeben, da sie sonst nicht aufgelöst werden könnten.

Grüße
Jens

9fisi1

oha, da laufen wir wohl in eine weitere Falle, weil auch noch genau das Problem mit dem ".local"-im Domainnamen im besagten Netz vorhanden ist! (die Domäne wurde afaik immer unter dem selben Namen 'firmenname.local' "hoch migriert")…

Die Netze also das 192er /24 und 10ner /16 Netz sind über static Routing entsprechend durch den Core-Switch erreichbar, das macht eigentlich überhaupt keine Probleme.

Meine Frage wäre nun noch, muss im Windows-DNS unter "Weiterleitungen" die Google-DNS-IPs zusätzlich eingetragen werden, oder sollen dort gar keine "Weiterleitungs-DNS-IPs" mehr eingetragen werden? Weil die Clients im LAN ja weiterhin nur den/die Windows-DNS-Server "kennen" bzw. zugewiesen bekommen.

Und ich verstehe es so, dass wenn eine "interne Anfrage" an den Windows-DNS von einem Client gestellt wird (z.B. die Abfrage eines (Datei-)Server-Namen für 'nen "NET USE", um ein Share zu verbinden etc.) zunächst der Windows-DNS nach dem Servernamen gefragt wird und er diesen natürlich entsprechend auflösen kann.
Startet ein Client jedoch ein nslookup auf eine Internetseite "nslookup heise.de" wird der Windows-DNS wieder entsprechend abgefragt, er kann dies aber nicht auflösen und leitet es an den/die entsprechenden DNS-Server weiter, welcher unter "Weiterleitungen" eingetragen wurden?

Gruß

JeGr

OK da Quote ich lieber step-by-step :)

@9fisi1:

oha, da laufen wir wohl in eine weitere Falle, weil auch noch genau das Problem mit dem ".local"-im Domainnamen im besagten Netz vorhanden ist! (die Domäne wurde afaik immer unter dem selben Namen 'firmenname.local' "hoch migriert")…

Das ist ja sofern alles funktioniert und man nur Windows Clients hat auch nicht weiter schlimm. Wie gesagt Probleme treten dann auf, wenn man mit Protokollen à la zeroconf oder bonjour zu tun hat. Einige Drucker unterstützen das für "automagische" Konfiguration am Client. Genauso kann man mit DNS Einträgen auch erreichen, dass man automatisch Links zu einem Router oder diversen Webdiensten zugänglich macht. Ich wollte es nur erwähnen, weil es manchmal für seltsame Phänomene sorgen kann, muss es aber nicht. Bei uns ist das leider auch der Fall, deshalb werden jetzt auch alle nicht-Windows-Dienste (Wiki, Doku, etc.) auf Server/VMs mit anderen Domains ausgelagert, weil das bei vielen Linux Clients zu Problemen führen kann (Avahi unter Linux/Ubuntu bspw. hat .local als mdns zeroconf default Domain konfiguriert).

@9fisi1:

Die Netze also das 192er /24 und 10ner /16 Netz sind über static Routing entsprechend durch den Core-Switch erreichbar, das macht eigentlich überhaupt keine Probleme.

OK da hängt noch ein Core mit drin, das erklärt einiges. Dann ist es ja prinzipiell gut ;) Kommt eben drauf an ob der Core nur routet oder auch filtert, das würde das Problem in der Kommunikation ADS -> pfSense erklären.

@9fisi1:

Meine Frage wäre nun noch, muss im Windows-DNS unter "Weiterleitungen" die Google-DNS-IPs zusätzlich eingetragen werden, oder sollen dort gar keine "Weiterleitungs-DNS-IPs" mehr eingetragen werden? Weil die Clients im LAN ja weiterhin nur den/die Windows-DNS-Server "kennen" bzw. zugewiesen bekommen.

Gar keine Weiterleitungen würde bedeuten, dass der ADS sie selbst beantworten muss. Da er sie nicht kennt, wird er einen DNSFAIL zurückgeben. Die Weiterleitungen müssen natürlich rein :) Entweder auf die pfSense (um das da zu bündeln wenn gewünscht) oder direkt auf die gewünschten Ziel-DNSe.

@9fisi1:

Und ich verstehe es so, dass wenn eine "interne Anfrage" an den Windows-DNS von einem Client gestellt wird (z.B. die Abfrage eines (Datei-)Server-Namen für 'nen "NET USE", um ein Share zu verbinden etc.) zunächst der Windows-DNS nach dem Servernamen gefragt wird und er diesen natürlich entsprechend auflösen kann.
Startet ein Client jedoch ein nslookup auf eine Internetseite "nslookup heise.de" wird der Windows-DNS wieder entsprechend abgefragt, er kann dies aber nicht auflösen und leitet es an den/die entsprechenden DNS-Server weiter, welcher unter "Weiterleitungen" eingetragen wurden?

Bei diesem Szenario kommen eh verschiedene Welten zusammen, da NET USE mitunter gar keinen DNS Call macht, sondern über NETBIOS, WINS oder andere fiese Kleinigkeiten den Namen holt ;) Aber im Grundprinzip ist es richtig. Alles was der ADS selbst in seinem DNS hat, wird er auch selbst beantworten. Gerade bei NET USE (und Kurznamen) ist es wichtig nachzusehen, dass bei den Clients auch die richtige und ordentliche Domain-Suchfolge kommt, so dass sie "SERVER1" auch zu SERVER1.firmenname.local ergänzen. Dann wird das der Windows-DNS auch ordentlich beantworten.
Ist es keine von ihm verwaltete lokale Domain, wird er die DNSe fragen, die er als Forward-DNS genannt bekommen hat. In deinem Beispiel dann also die Google Public DNSe 8.8.8.8 und 8.8.4.4.

Dann siehts doch schonmal gut aus mit dem Verständnis :)

Grüße
Jens

9fisi1

Hallo Jens,

alles klar, ich werde es entsprechend umkonfigurieren, testen und berichten.

Vielen Dank nochmals für alle Infos!

Viele Grüße!

9fisi1

Hallo Jens,

wollte mich nochmal kurz bzgl. des eingangs erwähnten "DNS-Problems" melden.
Jetzt läuft alles PERFEKT! Internetseiten werden wieder sehr schnell geladen, aktualisiert und "nslookups" lassen sich ohne Probleme ausführen (sowohl intern als auch nach "draußen") - die Firma dankt! ;)

Einzig die von Dir beschriebenen Einstellungen (unter Punkt 2)) im "DNS forwarder" unter "Service" konnte ich in der Form finden bzw. einstellen.
Anbei ein Screenshot von der pfSense und den vorhandenen / möglichen Einstellungen. Was müsste ich hier noch konfigurieren?
(In der "General Setup" sind wie beschrieben, beide DNS Server mit "none" eingetragen, die Windows-Domain "firmenname.local" ist ebenfalls unter "Domain" eingetragen und der Haken "Allow DNS server list to be overridden by DHCP/PPP on WAN" ist ebenfalls rausgenommen.)

Viele Grüße!

ifhaijef2.jpg_thumb

JeGr

Ahoi,

na das ist doch schön zu hören :D Wenn du die Sense jetzt noch als AD-aware 2nd DNS einsetzen magst, müsste hier unter Domain Overrides noch folgendes rein:

Domain: firmenname.local
IP: IP-Adresse des DCs (AD DNS)
Description: WasAuchImmerDirGenugInfoVerschafft ;)

Damit weiß der DNS Forwarder der Sense dann, dass er *.firmenname.local doch bitteschön an den DNS auf x.y.z.a weiterleiten soll und tut das normalerweise auch :)

Grüßend
Jens