Synology NAS: IMAP antwortet nicht (NAS-DNS)

[Hot Dog]

SOLVED: Schuld war eine falsche DNS-Einstellung der VPN-Verbindung. (siehe Beitrag #13)

Hey Leute,
gibt es hier ein paar erfahrene DNS-Spezialisten?

Ich habe Probleme mit meinem Synology DNS-Server auf meiner Synology 1821+
Habe meinen DNS-Server aufgesetzt und die Einträge in der Master-Zone angelegt (siehe Anhang).
Der Ping zu allen Servern läuft in der Regel einwandfrei (siehe Anhang).

Nun zu meinem Problem:
imap.oxaler.local fällt immer wieder mal aus (obwohl der Ping zur IP ohne Probleme antwortet). Also muss es wohl ein DNS-Auflösungsproblem geben, richtig? Das ist der einzige Eintrag, der Probleme verursacht. Er funktioniert zwar in 90% der Fälle aber ich habe fast jeden Tag das Problem, dass er mindestens einmal für 1-2 Stunden einfach ohne Grund ausfällt und sich nicht mehr anpingen lässt (tritt meistens direkt nach dem Start des PCs auf). In dieser Zeit kann ich dann natürlich auch meine Mails nicht einsehen bzw. neue abrufen. Die IP, sowie alle anderen Einträge lassen sich, wie gesagt, dauerhaft anpingen und antworten.
Ein Neustart des NAS, sowie eine Änderung an der TTL löst das Problem nicht.
Irgendwann fängt sich imap dann wieder und alles läuft wieder normal. Als Mail-Client kommt Thunderbird zum Einsatz.

Kann sich dieses Verhalten hier irgendjemand erklären bzw. hatte mal ähnliche Probleme?

Danke schonmal,
HD

 

[blablub1212]

Wenn du beim Ping die richtige IP bekommst, aber der Service nicht antwortet, dann hast du kein DNS-Problem. Mal die Logs von deinem Mailserver angeschaut?

 

[Hot Dog]

Wenn du beim Ping die richtige IP bekommst, aber der Service nicht antwortet, dann hast du kein DNS-Problem. Mal die Logs von deinem Mailserver angeschaut?

Das ist es ja, die Logs melden dazu rein gar nichts.
Weder die Logs des Mailserver Plus, noch die Logs des Protokoll-Centers merken das irgendwo an.
Für das NAS kommt es da anscheinend zu keinem Problem.

Und nein, wenn ich im besagten 1-2 Stunden-Zeitraum imap anpinge, bekomme ich keine Antwort zurück (keine IP).
Der Screenshot oben zeigt den Ping WÄHREND der Zeit, in der imap LÄUFT. Das dient zur Demonstration, dass imap.oxaler.local an sich überhaupt läuft.

 

[madmax2010]

An den thread von gestern denkend:
Hast du eine eigene, feste domain fuer den mailserver?
Soll er produktiv zum Empfang von emails genutzt werden?

teste mal:
openssl s_client -crlf -connect mailserver.domain.tld:993

 

[Hot Dog]

Hast du eine eigene, feste domain fuer den mailserver?

Ja, hab eine Domain bei Strato gebucht (oxaler). Aber das ist nicht das Problem. SMTP läuft zu 100%, der Mail-Ausgang läuft also anstandslos per Relay an Strato. Die Domain läuft also und das NAS leitet Mails nur an Strato weiter und sendet sie nicht direkt vom NAS in die Welt.

Soll er produktiv zum Empfang von emails genutzt werden?

Nein, nicht wirklich. Der Mail-Server (bzw. die Mail Station) holt sich die Mails nur von Strato per POP3 ab (das funktioniert auch). Nur am Zugriff per IMAP hakt es (zumindest ab und zu).

teste mal:
openssl s_client -crlf -connect mailserver.domain.tld:993

Wo soll ich das testen? Klingt nach einem Unix-Code.

 

[snaxilian]

Bitte nimm nicht die .local TLD, da denkt inzwischen jedes halbwegs moderne OS an multicast DNS und zeroconf: https://en.wikipedia.org/wiki/.local

Hier findest du gegen Ende eine Liste potentiell besser geeigneter TLDs für den privaten Gebrauch: https://en.wikipedia.org/wiki/Special-use_domain_name
Einmal alles entsprechend umkonfigurieren und ich wette, der Fehler tritt so nicht mehr auf.

Wenn du eine Bestätigung für meine Theorie suchst: Wireshark und parallel zu deinen Tests mit sniffen und auf DNS und mDNS Traffic filtern.

 

[Hot Dog]

Bitte nimm nicht die .local TLD, da denkt inzwischen jedes halbwegs moderne OS an multicast DNS und zeroconf:
Hier findest du gegen Ende eine Liste potentiell besser geeigneter TLDs für den privaten Gebrauch: https://en.wikipedia.org/wiki/Special-use_domain_name
Einmal alles entsprechend umkonfigurieren und ich wette, der Fehler tritt so nicht mehr auf.

Und du meinst daran liegt es? Im Grunde sollte es doch vollkommen egal sein, wie die TLD lautet oder nicht? Ich könnte die auch hans.wurst nennen und es sollte funktionieren. Was lässt dich glauben, dass der Fehler gerade da her kommt?
Schließlich laufen ja alle anderen Einträge (smtp, mailserver, etc) mit .local
Mit sniffing habe ich mich nie beschäftigt, ist es arg aufwendig Wireshark einzurichten und zu verstehen?
Aber danke schonmal für den Gedankengang, wäre ich so jetzt nicht drauf gekommen.

 

[snaxilian]

Und du meinst daran liegt es?

Wir können alle deinen Versuchsaufbau nicht 100%ig nachbauen, müssen also in gewissen Teilen raten und dann ist es bei unklarem Fehlerbild immer hilfreich wenn man potentielle Fehlerquellen minimiert und die Komplexität reduziert. Das die .local Endung für mDNS und zeroconf vorgesehen ist, ist nunmal Fakt.

Ich könnte die auch hans.wurst nennen und es sollte funktionieren

Genau so ist es aber nicht. Es gibt gewisse Domains die für spezielle Funktionen vorgesehen sind, siehe oben.

Was lässt dich glauben, dass der Fehler gerade da her kommt?

Berufserfahrung und die lehrt einen u.a.: halte dich an Standards, reduziere Komplexität, vermeide potentielle Fehlerquellen.

sniffing habe ich mich nie beschäftigt, ist es arg aufwendig Wireshark einzurichten und zu verstehen?

Ist relativ und war auch mehr als Hinweis zu sehen um ggf den mDNS Traffic zu sehen. Wenn du da bisher 0 mit zu tun hattest, lass es bleiben und bleib beim eigentlichen Problem.

Noch etwas: Erreichbarkeitstests per Ping sind technisch betrachtet nur bedingt geeignet. Es kann vorkommen, dass ping  hostname ein anderes Ergebnis liefert als nslookup  hostname. Willkommen in der komplexen Welt der IT. Hier noch ein ausführlicher Artikel dazu: https://www.logicmonitor.com/blog/why-name-resolution-for-ping-may-disagree-with-dns/
Dein Ping kann also netbios, mDNS usw. fragen und vermeintliche Fehler melden aber direkter Mailabruf/-versand nutzt nur eine DNS Abfrage und läuft korrekt.

 

[Hot Dog]

hier stand Text

danke für die Ausführung. Dann werde ich es mal mit .home als TLD versuchen und die Tage dann Bescheid geben, ob das Problem weiterhin besteht oder behoben wurde.

EDIT: .home als TLD eingerichtet. Ich melde mich die Tage nochmal, ob es das Problem gelöst hat.

 

[Hot Dog]

Also leider hat sich das Problem mit der Umstellung auf .home als TLD nicht gebessert (siehe Screenshot).
Hab das leider fast erwartet.
Es kommt nach wie vor zu gelegentlichen Ausfällen mit imap.example.home
Weiterhin gilt: smtp.example.home, mailserver.example.home und die IP selbst lassen sich dauerhaft anpingen und antworten.
Sonst noch irgendwelche Ideen?

 

[snaxilian]

Könnte es damit zusammen hängen?

Nein, denn die "Fehlermeldung" besagt lediglich, dass jeder entfernte Host (vom DNS Server aus gesehen, also alle Geräte außer dem NAS) Einträge in der Zone example.home aktualisieren darf. Sprich wenn du deinen PC umbenennst in toller-pc-1 dann kann dieser selbstständig in der Zone einen Eintrag für sich anlegen damit du deinen PC dann unter toller-pc-1.example.home erreichst.
Wenn man das einfach so jedes Gerät erledigen lässt, ist das eben potentiell unsicher denn ein Angreifer könnte z.B. selbst ein Update schicken für mail.example.home und so Anfragen umlenken und Credentials oder Mails abfangen oder manipulieren um nur ein Beispiel zu geben.
Weil Synology das Rad ja auch nicht neu erfunden hat sondern einfach bestehende DNS Serversoftware nimmt und ihre WebUI drüber klatscht kommt es halt zu solchen Meldungen aber DNS Server stehen in der Regel im Internet oder in Firmen wo Leute sitzen die sich damit regelmäßig beschäftigen und im 0815 Router für zuhause für den Privatkundenbereich siehst du solche Meldungen vermutlich einfach nicht weil das ja so gewünschtes Verhalten ist bzw. man Privatpersonen nicht zumuten kann und will, dass diese sich damit beschäftigen sollen wie man DNS Updates nur signiert oder nach Authentication erlaubt.

Ich gehe stark davon aus, dass zumindest der DNS-Teil auf dem NAS problemlos läuft denn du hast ja nur "Probleme" beim Ping und naja offenbar hast du den Link von mir in #8 noch nicht gelesen oder nicht verstanden daher versuche ich eine andere Erklärung:
Wenn Ping auf die IP geht, dann weißt du: das NAS ist erreichbar.
Wenn <ICODE>nslookup hostname.example.home ip.adresse.des.nas</ICODE> funktioniert, dann weißt du: Der DNS Server auf dem NAS antwortet korrekt.

Wenn aber ein ping auf einen hostname nicht funktioniert dann kann das ein falscher Eintrag in der hosts Datei sein (unwahrscheinlich) ODER dass NetBIOS dir eine falsche/keine Antwort liefert (sehr wahrscheinlich) ODER im lokalen DNS Cache von Windows etwas nicht stimmt (eher unwahrscheinlich) ODER der Windows WINS Server nicht korrekt antwortet (sofern der heutzutage noch ausgeliefert wird?) ODER ein NetBIOS Broadcast nicht beantwortet wurde.
Zum mitschreiben: Das Tool Ping ist NICHT geeignet für reproduzierbare und sinnvolle Tests ob die Namensauflösung korrekt funktioniert. Ping ist auch NICHT geeignet um zu prüfen ob ein System bzw. darauf laufende Serverdienste eingeschaltet bzw. erreichbar sind.
PING ist geeignet um zu prüfen ob ein Ping Paket zum Zielserver geht, dort beantwortet wird und zurück kommt und Ping kann ein Indiz dafür sein, dass ein System eingeschaltet bzw. erreichbar ist.

Vielleicht hilft dir ja eine Analogie. Stell dir vor, du willst den Telefonanschluss des Nachbarn prüfen. Du kannst entweder direkt zum Telefon greifen und die Nummer wählen oder du machst die "Ping"-Variante. Du rufst bei irgendeiner Auskunft an, fragst nach der Nummer vom Nachbarn und wenn du Glück hast und diese dir Auskunft geben kann, dann lässt du dich verbinden. Hat aber irgendeine der angerufenen Auskunften nicht die Nummer, dann gehst du also davon aus, dass der Telefonanschluss des Nachbarn nicht erreichbar sei.

Meine Vermutung: Du jagst hier einem Geist hinterher und siehst Probleme wo es keine Probleme gibt. Wenn du wissen willst ob ein Mailserver erreichbar ist, dann prüfe dies und zwar genau dies. Wenn du wissen willst ob ein ein DNS Record aufgelöst werden kann, dann prüfe dies und wenn du wissen willst ob ein DNS Record über einen bestimmten DNS Server aufgelöst werden kann, dann prüfe genau dies.

 

[Hot Dog]

zu viel

ok, danke für die ausführliche Antwort. Ich nutze den Ping immer dann, wenn mir Thunderbird meldet, dass imap.example.home nicht erreichbar ist. Damit lässt sich das dann einfach bestätigen, was mir der Client sowieso schon meldet.

Danke für den Hinweis mit nslookup (hab jetzt verstanden was du meinst). Konnte damit das Problem ausmachen.

 

[Hot Dog]

So, Problem wurde gefixt. Hab jetzt den Übeltäter identifiziert.
Das VPN mit dem ich mich täglich verbinde hat das Problem verursacht. Für diese Verbindung war ein bevorzugter DNS-Server unter IP v4 eingetragen (warum auch immer). Bei nslookup wurde immer dieser DNS-Server verwendet, sobald ich mich damit verbunden habe. Auch wenn ich mir nicht erklären kann, warum er die VPN-Verbindung höher priorisiert als die Haupt-Ethernet-Verbindung im internen Netz. Hab die Verbindung für VPN jetzt auf DNS automatisch beziehen geändert und siehe da, imap.example.home wird jetzt nun auch während der Verbindung mit dem VPN korrekt vom eigenen NAS aufgelöst. Danke nochmal.
Es ist ausreichend, die Priorität der Verbindungen unter Windows anzupassen. Dann können beide Verbindungen unterschiedliche DNS-Server nutzen.
Adaptereinstellung -> Einstellungen -> IPv4 -> Erweitert -> "automatische Metrik" deaktivieren und selbst eine Priorität einstellen (je kleiner die Zahl, desto höher die Priorität).
Nun wird standardmäßig der lokale DNS auf dem NAS angefragt. Nur wenn man ganz explizit den DNS im VPN mit IP anfragt, antwortet dieser.

 

[snaxilian]

Was mir an deiner Erklärung fehlt ist ein Lösungsansatz.

Bevor man einen Fehler beheben kann, muss man diesen zuerst vollständig verstehen. Bisher hast du mit ping versucht eine Namensauflösung zu testen was eine nur bedingt sinnvolle Methode ist. Das hast du ja jetzt verstanden.

Thunderbird meldet, dass imap.example.home nicht erreichbar ist

Bitte prüfe ob Thunderbird auch die systemweiten DNS Einstellungen verwendet oder ob du da eigene Einstellungen vorgenommen hast:
Thunderbird -> Extras -> Einstellungen -> oben rechts in der Suche "DNS" eingeben -> Verbindung - Festlegen wie sich Thunderbird mit dem Internet verbindet -> Einstellungen... -> unten die Einstellungen für SOCKS & DNS over HTTPS sollten deaktiviert sein.

Das VPN mit dem ich mich täglich verbinde

Auch DAS gehört in den Eingangspost. Junge du musst echt mal lernen wie man richtig postet und sinnvoll deine Umgebung so beschreiben, damit Dritte diese komplett nachvollziehen können^^

Für diese Verbindung war ein bevorzugter DNS-Server unter IP v4 eingetragen (warum auch immer)

Ganz einfach: Damit auch DNS-Abfragen durch den VPN-Tunnel gehen und nicht nur die eigentlichen Verbindungen.
Hättest du jetzt einen potentiellen Lauscher auf der Leitung dann bekommt dieser mit, dass du www.heiße-dns-admins-in-deiner-naehe.de aufrufen willst auch wenn die eigentliche Verbindung dann durchs VPN geht oder weil es gewisse (private) DNS Einträge gibt, die nur durch den VPN-Tunnel erreichbar sind. Da wird dann neben einem anderen DNS-Server bei aktivem VPN auch für die Dauer der Verbindung gewisse Search Domains eingerichtet. Anfragen an Namen aus diesen Search Domains gehen dann an den DNS-Server "im" Tunnel. Wenn der Betreiber des VPNs als eigene Domains auch example.home oder example.local nutzt, hättest falsche anstatt gar keine Antworten bekommen.^^
Ein weiterer Grund warum eigene DNS Domains nur genutzt werden sollten wenn man auch tatsächlicher Besitzer der Domains ist aber die Kosten sparen sich viele gerne was im privaten Umfeld auch ok sein kann. Man muss dann halt ab und an Threads wie diese erstellen.

 

[Hot Dog]

Bevor man einen Fehler beheben kann, muss man diesen zuerst vollständig verstehen. Bisher hast du mit ping versucht eine Namensauflösung zu testen was eine nur bedingt sinnvolle Methode ist. Das hast du ja jetzt verstanden.

Ja stimmt schon. Aber nur weil du schreibst: hier mach mal nslookup mit dem und dem host oder IP, sagt das ja noch nicht so viel aus. Du setzt quasi voraus, dass jeder weiß, was nslookup genau tut 😅
Aber gut, hab es dann selbst rausbekommen.

Bitte prüfe ob Thunderbird auch die systemweiten DNS Einstellungen verwendet oder ob du da eigene Einstellungen vorgenommen hast:

Alles gut, bei Thunderbird ist "Proxy-Einstellungen des Systems verwenden" eingestellt. Und da ich den DNS-Server bei VPN rausgeschmissen hab, kann er ab jetzt auch nur noch das NAS oder als Fallback die Fritzbox anfragen (auch wenn ihm die Fritzbox nicht weiter helfen können wird).

Auch DAS gehört in den Eingangspost. Junge du musst echt mal lernen wie man richtig postet und sinnvoll deine Umgebung so beschreiben, damit Dritte diese komplett nachvollziehen können^^

Niemand (und wirklich niemand) geht davon aus, dass ein VPN DNS-Probleme im internen Netz auslöst. Tu mal nicht so, als ob du dann die Lösung direkt gehabt hättest 🙄

Ganz einfach: Damit auch DNS-Abfragen durch den VPN-Tunnel gehen und nicht nur die eigentlichen Verbindungen.

Durch den Tunnel sollen überhaupt keine DNS-Abfragen. Der verbindet mich nur zu meiner Familie, um sich im internen Chat (Jabber-Server) zu unterhalten und auf den File-Server daheim zuzugreifen. Internetzugang ist über diesen Tunnel sowieso deaktiviert und das zurecht.
Darum verstehe ich ja auch nicht, warum meine Windows-Instanz zunächst diesen DNS-Server anfragt. Ergibt überhaupt keinen Sinn, aber ok, is ja Windows. Windows könnte auch einfach eine Prio für Verbindungen einrichten, aber das ist wohl für DAUs nicht vorgesehen. Hab nur meine Hauptverbindung und eben die VPN-Verbindung. Aber Windows priorisiert anscheinend lieber die VPN-Verbindung und eben was dort eingetragen ist.

Hättest du jetzt einen potentiellen Lauscher auf der Leitung

Wie gesagt, kein Internetzugang über VPN, keine Lauscher, alles sicher, alles gut. Zudem mit Zertifikat und Verschlüsselung abgesichert (OpenVPN).

 

[snaxilian]

Niemand (und wirklich niemand) [...]

Du solltest nicht von dir auf andere schließen
Hier im Forum gibt es eine Menge kompetenter Menschen die ziemlich gute Kenntnisse im Bereich Netzwerktechnik haben und einige von denen wissen um die Probleme beim Thema DNS die sehr schnell auftreten können bei VPNs und/oder abseits der durchschnittlichen Szenarios bei Privatanwendern.

Durch den Tunnel sollen überhaupt keine DNS-Abfragen.

Dann solltest du mit demjenigen Kontakt aufnehmen, der den VPN-Server administriert. Ob ein openvPN-Client beim Verbindungsaufbau auch weitere Informationen wie DNS oder weitere Routingeinträge bekommt oder nicht, wird durch den Admin bei der Erstellung der Config-Dateien festgelegt.

Ergibt überhaupt keinen Sinn, aber ok, is ja Windows.

Wäre mit ähnlicher Config unter einem Linuxclient vermutlich nicht viel anders

Windows könnte auch einfach eine Prio für Verbindungen einrichten, aber das ist wohl für DAUs nicht vorgesehen.

Tatsächlich gibt es so etwas aber ja für den normalen User nicht direkt ersichtlich. Geht man aber davon aus, dass ein normaler User VPN höchstens vom Homeoffice kennt/nutzt, dann braucht der normale User so etwas auch nicht wissen.
Das Problem bei IT ist: Es gibt keinen sanft ansteigenden seichten Pfad vom normalen User aufwärts. Da kommt sehr schnell eine sehr steile Wand wo man die technischen und fachlichen Grundlagen kennen und können muss wenn man komplexere Wege beschreiten will.
Vieles wird durch Wizards und Konfigurationshilfen von Appliances wie einem Synology NAS zwar erleichtert aber auch die haben ihre Grenzen und die liegen dort wenn man abseits von deren Angebot noch weitere Netzwerkdienste integrieren will.
Anyway, zum Thema der Prioritäten von Adaptern gibt hier auf cb schon einen Thread mit dort verlinkter Lösung wie man die Prios ändern kann: https://www.computerbase.de/forum/threads/openvpn-push-zu-hohe-metric.1631700/

 

[Hot Dog]

Dann solltest du mit demjenigen Kontakt aufnehmen, der den VPN-Server administriert. Ob ein openvPN-Client beim Verbindungsaufbau auch weitere Informationen wie DNS oder weitere Routingeinträge bekommt oder nicht, wird durch den Admin bei der Erstellung der Config-Dateien festgelegt.

Schon erledigt. Mein Vater hostet das VPN. Ich gehe stark davon aus, dass er den DNS in das VPN-Profil eingetragen hat, was ja im Grunde auch sinnvoll ist.

Anyway, zum Thema der Prioritäten von Adaptern gibt hier auf cb schon einen Thread mit dort verlinkter Lösung wie man die Prios ändern kann: https://www.computerbase.de/forum/threads/openvpn-push-zu-hohe-metric.1631700/

Das "Erweitert" gibt es unter Windows 10 nicht mehr unter Netzwerkverbindungen.
Unter Windows 10 ist das "Erweitert" nun in die jeweiligen Adaptereinstellungen integriert.
Aber cool, wusste nicht, dass es doch so etwas gibt.
Hab prompt den DNS für das VPN wieder eingetragen und die Metriken auf 1 (Main Prio 1) und 2 (VPN Prio 2) gesetzt und siehe da, jetzt klappt es ebenfalls.
Wenn ich jetzt den DNS Zuhause mit nslookup ansteuere, findet er diesen und wenn ich meine lokale DNS-Domain ansteuere findet er diese. D.h. er priorisiert jetzt richtig und beide DNS-Einstellungen können koexistieren.
Danke für den Hinweis!

 

[snaxilian]

Ja, die GUI ändert MS gerne mal, im Zweifel die PowerShell verwenden
Freut mich, dass ich helfen konnte und es jetzt klappt wie gewünscht.