wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
sebix schrieb: wolfi3300 schrieb: sebix schrieb: Hier hab ich ein paar long running queries von zwei unterschiedlichen lokalen DNS Servern:
Sehr eigenartig. Frage mich gerade wo hier ein Flaschenhals sein könnte? Ist das Problem zwangsweise bei uns? Vor allem, wenn er bei mir an der Maschine 10ms zeigt?
Das weiss ich auch nicht, aber eigenartig ist es. Ich kann das in mehreren Netzen mit mehreren Nameservern nachvollziehen. Hier zB die Ergebnisse des NS der TU Wien: 5s, SERVFAIL
Ich glaube zwar nicht, dass das jetzt mit dem Mailproblem zu tun haben könnte, denn irgendwann müsste unsere IP ja bei GMX oder MAILWALL im Cache sein und eine Mail durchrutschen. Wir bekommen ja gar nichts durch. Aber ich werde trotzdem noch versuchen, ob ich das irgendwo/irgendwie nachvollziehen kann. Zur Not mal zu Hause den Raspberry hochfahren ☺
|
wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
Also mit https://www.dnsperf.com/dns-speed-benchmark?id=c716okxl3txsra9 habe ich eigentlich überall gute Zeiten aus DE (~23msec) Nordamerika wird dann natürlich mehr über den Teich, so um die 170msec
https://www.dnsperf.com/dns-speed-benchmark?id=mt88qwl3txu7hv @sebix: Kann es sein, dass der Flaschenhals da irgendwo bei dir liegt? Wie sieht es bei anderen Domänen aus?
|
wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
Das Problem ist gelöst. Dank eines jungen Mitarbeiters eines Partnerunternehmens, der herausgefunden hatte, dass es mit unserem DNSSEC Schwierigkeiten gibt und irgendwas nicht stimmt. Ich habe die ganzen DNSSEC Einträge jetzt mal rausgenommen und keine 5 Minuten später bekam ich schon meine GMX Testmails herein. Auch in Richtung GMX klappt es wieder, die Queue wurde schnell geleert. Ich denke ich kann auch ohne DNSSEC noch ne ganze Weile gut leben, wenn das so komische Fehler verursachen kann. 😀 Möglicherweise war der Grund, dass unsere DNS Server nur via UDP durch die Firewall gehen. DNSSEC will aber wohl zwingend TCP, was gescheitert ist.
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17583
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Möglicherweise war der Grund, dass unsere DNS Server nur via UDP durch die Firewall gehen. DNSSEC will aber wohl zwingend TCP, was gescheitert ist.
Es ist halt ein Problem, wenn man Firewalls nutzt, aber die Protokolle nicht versteht. Eure FW ist das Problem, nicht DNSSEC.
Ihr müsst bei DNS TCP/53 und UDP/53 durchlassen.
Wenn ihr nicht wollt, dass die Leute den Zonentransfer nutzen, müsst ihr das am DNS auf bestimmte IP-Bereiche beschränken.
Zudem sollte man keinen offenen Resolver betreiben, also die Rekursion nur für die eigenen IP-Bereiche erlauben.
|
wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
DJKUhpisse schrieb: Möglicherweise war der Grund, dass unsere DNS Server nur via UDP durch die Firewall gehen. DNSSEC will aber wohl zwingend TCP, was gescheitert ist.
Es ist halt ein Problem, wenn man Firewalls nutzt, aber die Protokolle nicht versteht. Eure FW ist das Problem, nicht DNSSEC.
Ihr müsst bei DNS TCP/53 und UDP/53 durchlassen.
Wenn ihr nicht wollt, dass die Leute den Zonentransfer nutzen, müsst ihr das am DNS auf bestimmte IP-Bereiche beschränken.
Zudem sollte man keinen offenen Resolver betreiben, also die Rekursion nur für die eigenen IP-Bereiche erlauben.
Die Firewall ist das Problem nicht. Da braucht man nur TCP auf Durchzug schalten. Das Problem ist, wenn irgendwelche Dinge abgefragt werden und dann keine ordentlichen Fehlermeldungen generiert werden, was denn nicht geklappt hat. Da sucht man dann ewig nach der Ursache ...
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17583
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Dann hast du DNS nicht verstanden. Ihr müsst TCP Port 53 zulassen.
|
wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
DJKUhpisse schrieb: Dann hast du DNS nicht verstanden. Ihr müsst TCP Port 53 zulassen.
Ja, auch das weiß ich, habe ich oben ja schon geschrieben ... 😉
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17583
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Also bei den DNS-Server, die im NS-Record stehen, ist jetzt DNS für UDP und TCP bei IPv4 und IPv6 freigegeben?
Dann wäre DNS soweit ok.
Was gibt es denn für Abfragen, die aktuell Probleme machen?
|
wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
DJKUhpisse schrieb: Also bei den DNS-Server, die im NS-Record stehen, ist jetzt DNS für UDP und TCP bei IPv4 und IPv6 freigegeben?
Dann wäre DNS soweit ok.
Was gibt es denn für Abfragen, die aktuell Probleme machen?
Das Problem war so gelagert, dass vor einiger Zeit die DNSSEC Einträge gemacht wurden. 53/TCP aber versehentlich nicht durchgeschliffen wurde. Das ist aber lange Zeit nicht aufgefallen. Erst jetzt hat wohl GMX da irgendwas umprogrammiert und plötzlich kommen diese eigenartigen Fehler. Bei GMX ist natürlich niemand zu erreichen der da weiterhelfen würde.
Ich dachte Anfangs es könne am Protokoll oder am Cipher liegen, da ich hier zuletzt viel gemacht habe (TLS1/1.1 disabled, stärkere Cipher, etc.) das wars aber alles nicht. 53/TCP war das Problem, aber muss man dann erst mal draufkommen. 😉 Wenn die schreiben "DNSSEC Einträge gefunden aber kein Zugriff auf DNS via TCP" und nicht "Requested action aborted: local error in processing (in reply to MAIL FROM command)" wäre sofort alles klar gewesen ...
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5323
|
wolfi3300 schrieb: Wenn die schreiben "DNSSEC Einträge gefunden aber kein Zugriff auf DNS via TCP" und nicht "Requested action aborted: local error in processing (in reply to MAIL FROM command)" wäre sofort alles klar gewesen ...
Ist eben nicht so einfach, wenn die IT in der wir arbeiten, alles verschachtelt und verkettet. Wenn der (als Client) benutzte DNS-Recursor DNSSEC validiert, schlaegt er damit fehl (SERVFAIL), weil er nicht durch eure Firewall kommt (hohe Verarbeitungszeiten). Deren Mailserver wiederum macht die ueblichen DNS-Queries beim Erhalt der Mail (Reverse-Record, Helo, DMARC & Co.) und laeuft dort in beide Probleme. Nicht einmal der DNS-Recursor wusste, dass es an eurer Firewall lag.
|
wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
sebix schrieb: wolfi3300 schrieb: Wenn die schreiben "DNSSEC Einträge gefunden aber kein Zugriff auf DNS via TCP" und nicht "Requested action aborted: local error in processing (in reply to MAIL FROM command)" wäre sofort alles klar gewesen ...
Ist eben nicht so einfach, wenn die IT in der wir arbeiten, alles verschachtelt und verkettet. Wenn der (als Client) benutzte DNS-Recursor DNSSEC validiert, schlaegt er damit fehl (SERVFAIL), weil er nicht durch eure Firewall kommt (hohe Verarbeitungszeiten). Deren Mailserver wiederum macht die ueblichen DNS-Queries beim Erhalt der Mail (Reverse-Record, Helo, DMARC & Co.) und laeuft dort in beide Probleme. Nicht einmal der DNS-Recursor wusste, dass es an eurer Firewall lag.
Ja, der wusste nicht an was es liegt. Was er aber schon wusste, dass er bei der TCP-DNS Abfrage einen Timeout hatte und nichts retour bekam. Wenn man das mit einer schönen Fehlermeldung weitergibt "DNS/TCP timed out", dann weiß die Gegenstelle wo sie ansetzen kann mit der Fehlersuche. Ich habe Stunden damit verbracht an anderer Stelle zu suchen ☺
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5323
|
wolfi3300 schrieb: @sebix: Kann es sein, dass der Flaschenhals da irgendwo bei dir liegt?
Ja, kann ich 😎 Uebrigens zeigt dieses Beispiel auch gut, warum das zensieren von Logs nicht hilfreich ist. Wenn du nicht an einer Stelle die Domain drinnen gelassen haettest, war ich auch nie auf das DNS-Problem gekommen.
|
wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
sebix schrieb: wolfi3300 schrieb: @sebix: Kann es sein, dass der Flaschenhals da irgendwo bei dir liegt?
Ja, kann ich 😎 Uebrigens zeigt dieses Beispiel auch gut, warum das zensieren von Logs nicht hilfreich ist. Wenn du nicht an einer Stelle die Domain drinnen gelassen haettest, war ich auch nie auf das DNS-Problem gekommen.
Ich glaub du hast aber mit dem DNS irgend ein anderes Problem. Meine DNS Server hier sind eigentlich flott und liefern schnell raus. Weiß nicht wo deine 3-10 Sekunden herkommen?
Auf TCP geht ja gar nichts durch. Ich vermute, du hast nur auf UDP getestet?
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5323
|
wolfi3300 schrieb: sebix schrieb: wolfi3300 schrieb: @sebix: Kann es sein, dass der Flaschenhals da irgendwo bei dir liegt?
Ja, kann ich 😎 Uebrigens zeigt dieses Beispiel auch gut, warum das zensieren von Logs nicht hilfreich ist. Wenn du nicht an einer Stelle die Domain drinnen gelassen haettest, war ich auch nie auf das DNS-Problem gekommen.
Ich glaub du hast aber mit dem DNS irgend ein anderes Problem. Meine DNS Server hier sind eigentlich flott und liefern schnell raus. Weiß nicht wo deine 3-10 Sekunden herkommen?
Auf TCP geht ja gar nichts durch. Ich vermute, du hast nur auf UDP getestet?
Nein, das Problem war eure Firewall, wie du ja selbst herausgefunden hast. Wenn ein DNS-Recursor so eingestellt ist, dass er DNSSEC validiert, verbindet er sich zum zustaendigen DNS-Server via TCP. Die Requests verschwinden und die Connection timeoutet, das dauert eine Weile. Folglich schlaegt die Validierung fehlt und resultiert in einem Fehler (SERVFAIL). Solche DNS-Recursor, die DNSSEC nicht validieren, oder den Fehler schon gecacht haben und in der Folge ignorieren, antworten sofort. Und: Keiner der DNS-Recursor, dich ich getestet hatte, hab ich selbst betrieben. zB ist 128.130.4.3 von der TU Wien. Ein andrer war der vom Provider (A1).
|
wolfi3300
(Themenstarter)
Anmeldungsdatum: 5. Juni 2006
Beiträge: 66
|
sebix schrieb: wolfi3300 schrieb: sebix schrieb: wolfi3300 schrieb: @sebix: Kann es sein, dass der Flaschenhals da irgendwo bei dir liegt?
Ja, kann ich 😎 Uebrigens zeigt dieses Beispiel auch gut, warum das zensieren von Logs nicht hilfreich ist. Wenn du nicht an einer Stelle die Domain drinnen gelassen haettest, war ich auch nie auf das DNS-Problem gekommen.
Ich glaub du hast aber mit dem DNS irgend ein anderes Problem. Meine DNS Server hier sind eigentlich flott und liefern schnell raus. Weiß nicht wo deine 3-10 Sekunden herkommen?
Auf TCP geht ja gar nichts durch. Ich vermute, du hast nur auf UDP getestet?
Nein, das Problem war eure Firewall, wie du ja selbst herausgefunden hast. Wenn ein DNS-Recursor so eingestellt ist, dass er DNSSEC validiert, verbindet er sich zum zustaendigen DNS-Server via TCP. Die Requests verschwinden und die Connection timeoutet, das dauert eine Weile. Folglich schlaegt die Validierung fehlt und resultiert in einem Fehler (SERVFAIL). Solche DNS-Recursor, die DNSSEC nicht validieren, oder den Fehler schon gecacht haben und in der Folge ignorieren, antworten sofort. Und: Keiner der DNS-Recursor, dich ich getestet hatte, hab ich selbst betrieben. zB ist 128.130.4.3 von der TU Wien. Ein andrer war der vom Provider (A1).
Ja, ein SERVFAIL ist klar, wenn gar nichts daher kommt. Aber du hattest geschrieben, dass sie langsam sind und teilweise hohe Response Zeiten bis 10 Sekunden haben. Das kann aber nicht sein. Ein kompletter Fail auf TCP schon. So meinte ich das ☺
|