4.7.1 Client host rejected: cannot find your reverse hostname

  • Hallo zusammen,


    sorry für das Posten hier, ist zwar kein POP3/IMAP Problem, aber schioen mir am besten hier reinzupassen. Ich habe seit dem 03.05. ein Problem mit der rDNS Auflösung auf meinem Server. Ich habe die Restriction reject_unknown_reverse_client_hostname in der postfix Konfiguration aktiviert und bekomme folgende Fehlermeldung:


    Code
    May  4 21:52:18 mail postfix/smtpd[3981]: NOQUEUE: reject: RCPT from unknown[54.240.1.131]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [54.240.1.131]; from=<202
    20504194313706911bbeb3346008877a86d7140p0eu@bounces.amazon.de> to=<xxx@xxx.xxx> proto=ESMTP helo=<a1-131.smtp-out.eu-west-1.amazonses.com>


    Ich kann mir nicht vorstellen, dass die Amazon E-Mail Server falsch konfiguriert sind, also habe ich folgendes auf meinem Root Server ausgeführt:

    Code
    dig +short -t A a1-166.smtp-out.eu-west-1.amazonses.com
    54.240.1.166
    
    nslookup 54.240.1.166
    ** server can't find 166.1.240.54.in-addr.arpa: SERVFAIL

    Das Komische ist aber die Ausführung auf meinem lokalen Rechner:

    Code
    nslookup 54.240.1.166
    166.1.240.54.in-addr.arpa       name = a1-166.smtp-out.eu-west-1.amazonses.com.

    Kann mir einer sagen wo hier das Problem liegt?

  • Zur hilfreichsten Antwort springen
  • Ja, generell geht das:

    Code
    nslookup 8.8.8.8
    8.8.8.8.in-addr.arpa    name = dns.google.

    Ich habe auf dem Server keinen eigenen Resolver. Ich würde mal vermuten, dass ich da über netcup gehe

  • Den DNS-Resolver hast du entweder mit einem Image von netcup eingestellt bekommen oder du hast ihn bei der Installation deines OS irgendwo angegeben. Ansonsten würde dein Server ja überhaupt keine Namen auflösen können. Hast du ein Image von netcup installiert und den DNS-Resolver nicht geändert, dann nutzt du die netcup Resolver.

  • Ja, ich habe das Ubuntu 20.04. LTS Image von netcup installiert und nichts am DNS-Resover konfiguriert oder verändert. Ist also netcup das Problem?


    Code
    grep '^nameserver' /run/systemd/resolve/resolv.conf
    nameserver 46.38.225.230
    nameserver 46.38.252.230
    nameserver 2a03:4000:0:1::e1e6
    nameserver 2a03:4000:8000::fce6
  • Also ich kann beide rDNS Einträge von den von dir geteilten IPs über die Netcup DNS auflösen.

    Daher wohl eher kein Netcup problem.

    Matrix: @nan0:nan0.dev - IRC: nan0 on hackint.org - Discord? Nein danke!

  • Tja, aber wessen Problem ist es dann? Bei mir geht es über netcup nicht, über die Telekom bei mir zu Hause schon. Kann ich sonst noch irgendwas auf dem Server machen um das Problem zu beheben?

  • nan0 : Kannst du sie über alle Netcup DNS-Resolver auflösen. Klappt das immer, also 7/24? Ich weiss, schwer zu verifizieren ;) .


    Aus eigener Erfahrung muss ich sagen, ich hatte zwei Mal Schwierigkeiten mit der Namensauflösung. Beim ersten Mal habe ich es nicht realisiert, dass die netcup Resolver die Ursache waren, ich habe es im Gegenteil so gut wie ausgeschlossen, obwohl deren Zuverlässigkeit damals hier im Forum in diversen Threads Thema war. Ich habe es aber trotzdem zunächst als Ursache ausgeschlossen, weil ich die Probleme nur sporadisch und nur auf einem von drei Servern hatte und alle drei Server die selben netcup Resolver benutzten. Aber als ich nach tagelanger Suche absolut keine andere Ursache finden konnte, habe ich testhalber dann doch mal die DNS-Resolver auf dem problematischen Server geändert, von netcup auf Google, die Probleme waren sofort wie weggeblasen und sind seitdem nicht mehr aufgetreten.

    Beim zweiten Mal waren die Symptome etwas anders und die Signale in Richtung netcup Resolver wesentlich deutlicher. Zudem hatte ich den ersten Fall noch im Hinterkopf, habe also diesmal schneller den Test mit den Google Resolvern gemacht. Und wieder hat sich das Problem umgehend in Luft aufgelöst.


    Auch bei diversen Fehlern im DNSSEC von Domains war es jeweils ein netcup Problem, diesmal u.a. mit den Nameservern, insbesondere mit einem. Mit welchem weiss ich nicht mehr, da müsste ich mal schauen, ob ich die damaligen Logfiles noch habe. Auf meinen beiden Servern mit Intel-Prozessoren sind beide oben erwähnten Probleme nie aufgetreten. Ich habe gerade eben mal nachgeschaut und festgestellt, dass dort immer noch die netcup-Resolver benutzt werden. Beide Server sind aber zumindest absolut unauffällig. Zufall? Die Wahrscheinlichkeit dafür ist bei nur vier beobachteten Servern natürlich relativ groß. Werde jetzt aber doch mal in den nächsten Tagen die Logfiles genauer unter die Lupe nehmen, vielleicht findet sich ja doch was.

    • Hilfreichste Antwort

    Bei mir nicht, jedenfalls nicht mit der IP. Mit anderen schon, aber mit der IP kommt nach einigen Sekunden:

    Code
    resolve call failed: DNSSEC validation failed: no-signature

    resolvectl query 91.204.46.70 liefert mir z.B. korrekt:

    Code
    91.204.46.70: a2e46.netcup.net                 -- link: eth0


    dig -x 54.240.1.131 liefert den PTR sofort korrekt zurück.


    Ich habe mal DuckDuckGo und Google bemüht, könnte eventuell auch ein Bug in systemd/resolved sein. :/?(:rolleyes:

    Da gab es wohl schon öfter Probleme, mit dem sehr unschönen Workaround "DNSSEC=no" zu setzen anstatt "DNSSEC=allow-downgrade"

    Jedenfalls vertage ich das jetzt auf später und gehe an der Matratze horchen bevor es wieder hell wird.


    Netcup scheint da aber - Stand jetzt - unschuldig zu sein


    Denn es funktioniert auch mit den Resolvern von Google nicht.

  • funktioniert der systemd resolver denn -> resolvectl query 54.240.1.131

    Nein, auch das funktioniert bei mir nicht


    Code
    resolvectl query 54.240.1.166
    54.240.1.166: resolve call failed: DNSSEC validation failed: no-signature


    Denn es funktioniert auch mit den Resolvern von Google nicht.

    Kann das dann ein Problem bei Amazon sein?

  • Da gab es wohl schon öfter Probleme, mit dem sehr unschönen Workaround "DNSSEC=no" zu setzen anstatt "DNSSEC=allow-downgrade"


    probier doch einfach beide optionen mal nacheinander aus.

    Tatsache, jetzt, wo ich DNSSEC=no gesetzt habe, funktioniert die Auflösung. Hat das jetzt irgendeine Auswirkung? Ist das ein Bug in systemd/resolved?

  • Jester

    Hat einen Beitrag als hilfreichste Antwort ausgewählt.