DNS Probleme mit Domain Controller und Virtual Switch

  • Hallo,


    ich habe seit geraumer Zeit (ich meine nach dem Update von 5.1.8.x nach 5.2.0.2860) große Probleme mit dem DNS vom Domaincontroller. Bzw. das NAS selbst erklärt mir beim einloggen , dass es Probleme mit der Auflösung gibt. Ich habe noch einen Pi-Hole Server, der Ad-Blocking übernehmen soll. Ich weiß, dass das in Zusammenhang mit dem Domaincontroller nur eingeschränkt gut ist, aber bei folgendem Setup sollte es eigentlich keine Probleme geben.


    NAS DNS -> PiHole DNS -> FritzBox Gateway

    pasted-from-clipboard.png

    Im virtuellen Switch habe ich den PiHole als auch die FritzBox jeweils als DNS1 und DNS 2 eingetragen. Früher habe ich den DNS auf dem NAS selbst als DNS1 und den PiHole als DNS2 eingetragen. Das hat eigentlich auch funktioniert bin ich der Meinung.

    Jedenfalls ist mein weiterer Eindruck auch, dass der virtuelle Switch seit einem der letzten Updates auch nicht mehr besonders zuverlässig funktioniert. Manche Zugriffe aus VMs funktieren, andere wieder nicht, aber ein Muster ist auch nur bedingt zu erkennen. Meist ist nach einem Reboot irgendetwas im argen gewesen, dass erstmal nur durch den 3s Reset wieder behoben werden konnte.


    Vielleicht kann mir aber jemand zum internen DNS noch ein paar Infos geben. Mir ist nämlich nicht klar wo der seine Upstream Konfiguration hat. Die einzige Einstellmöglichkeit scheint mir das Gateway und die DNS Infos im Virtuellen Switch zu sein. Ich habe beide Adapter am Netz, aber offenbar kann nur einer als Gateway dienen. Warum ist mir auch nicht so ganz klar. Ich wollte z.B. VMs auf unterschiedliche Adapter aus Lastgründen verteilen, scheinbar geht das nur bedingt. Bzw. die VMs dort können dann nicht aufs Internet zugreifen. Auf jeden Fall hat der DC DNS ein Problem, denn nslookup produziert immer Timeouts bei externen Domains.


    Vielleicht kennt ja jemand auch ein brauchbares Tool, mit dem man seine Netzwerktopologie mal auf Macken abscannen kann. Ich hab den zwar den Eindruck, dass das QNAP die Macke hat, aber ich will mal nichts ausschließen. Es scheint so zu sein, dass, sobald der Microsoft Networking Dienst sprich SMB am laufen ist, der DNS nicht mehr sauber läuft. Aber ich weiß nicht so recht, wie ich das überprüfen kann. Auf komplettes Neuaufsetzen habe ich eigentlich wenig Lust und noch weniger Zeit. Aber die Probleme sind schon sehr nervig, weil es geht eben irgendwie, aber nicht zuverlässig. Und ob ein Ticket bei QNAP selbst hier hilfreich wäre sei mal dahingestellt. Vorher will ich aber alle anderen Fehlerquellen ausgeschlossen haben.

  • Male mal auf was du jetzt genau wo hast und wie du dir das vorgestellt hast.


    Das klingt ein wenig nach Chaos.


    Das NAS hat sich selber als ersten und dann den externen DNS Server als zweites eingetragen.

    Ist die Frage wo du dann hin willst, erst zur Fritz, die geht zum PiHole und dann weiter ins Internet?


    Macht irgendwie nur Sinn, wenn jeder Client vom DHCP den PiHole als DNS erhält und so für alle der Filter aktiv ist.

    Daher auch die Anforderung der Zeichnung, dann wird dir die Struktur klar.

  • Hallo,


    auch wenn es auf den ersten Blick etwas wirr erscheint ist ein Sinn dahinter ;)


    Momentan ist die FritzBox der DHCP. Der verteilt den QNAP DNS .

    Das QNAP ist ja DC. Das Problem ist, dass, damit das einigermaßen vernünftig funktioniert, alle Clients dies als DNS verwenden müssen. Ich möchte aber meinen AdBlocker gerne weiter haben. Somit nutzt der DC DNS vom QNAP den piHole zum Filtern. Damit sieht dieser natürlich nur einen einzigen Client. Eine bessere Lösung habe ich bisher da nicht gefunden, wenn man nicht das AdBlocking nur auf den Clients machen möchte. Der PiHole benutzt die FritzBox als DNS Forwarder.


    Also sollte die normale Auflösung so aussehen:


    Client -> Qnap -> piHole -> Fritzbox


    Da sehe ich auch kein grundlegendes Problem drin. Es sieht aber so aus, als ob der Qnap DNS nicht korrekt funktioniert. Jedenfalls produziert der sehr viele Timeouts, und ich kann mir nicht so recht vorstellen, dass das am PiHole liegt. Ich gehe davon aus, dass der DNS im QNAP die Einstellungen aus dem virtuellen Switch vom Gateway nimmt, also den piHole als 1st und die FB als 2nd DNS. Das sollte ja auch kein Problem sein, wenn der piHole mal zicken sollte. Dann wäre halt das AdBlocking mal kurz weg, aber DNS würde noch gehen.


    Ich habe mittlerweile den Verdacht, dass der virtuelle Switch merkwürde Seiteneffekte hat. Ich hatte jetzt im DNS auch Einträge für Netze vom Switch, die gar nicht verbunden waren ... die habe ich niemals selbst dort eingetragen. Und inzwischen gibt es ja auch einige Beiträge, wo die VM / Containerkonnektivität merkwürdig eingeschränkt zu sein scheint. Das Phänomen hatte ich auch schon. Mir fehlt im Moment ein wenig das Wissen, wie ich das auf dem Qnap überprüfen soll. Es geht irgendwie, aber es gibt komische Timeouts, die ich nicht verstehen kann. Im piHole sind die Anfragen vom NAS alle sichtbar und auch ok. Trotzdem kriege ich Timeouts, wenn ich mal mit nslookup was prüfe.

  • Das NAS sollte zuerst sich selber also 127.0.0.1 als DNS eingetragen haben und dann den piHole als zweiten.

    Nur so wird das AD zuerst abgefragt und wenn der Eintrag hier nicht gefunden wird, dann erst geht es raus.


    Ansonsten wird round robin angefragt und der PiHole bekommt Anfragen über interne Clients, die er nicht beantworten kann, daher könnten schon deine Timeouts kommen.

    Also baue hier eine saubere Forwarding Struktur auf.

  • Das NAS sollte zuerst sich selber also 127.0.0.1 als DNS eingetragen haben und dann den piHole als zweiten.

    Das kann ich nochmal probieren ... ich hatte die echte IP angeben, dass war möglicherweise das Problem . Wobei nslookup auch zickt, wenn ganz klar eine externe Domain abgefragt wird, also bspw. "heise.de" etc. Erst gibt es ein paar timeouts, dann kommt ein Ergebnis. Mal mehr timeouts, mal weniger.


    Hmm, es macht nicht wirklich einen Unterschied. Der DNS produziert einfach Timeouts und reagiert sehr träge. Ich glaube, das Problem liegt da woanders...

    Einmal editiert, zuletzt von nasferatu () aus folgendem Grund: Ein Beitrag von nasferatu mit diesem Beitrag zusammengefügt.