Posts by Aleph

  • DANE - TLSA-Records werden nicht gefunden

    Ich konnte das Problem lösen. Laut https://dnsviz.net/d/ormanns.net/dnssec/ war mein dritter Nameserver nicht mehr per IPv6 erreichbar. Nachdem ich das gefixt hatte, konnte ich auch wieder die TLSA-Records auflösen. Die Nameserver für ormanns.net sind in IPv4 als auch in IPv6 hinterlegt, wohingegen die Nameserver für syncookie.de nur in IPv4 eingetragen sind - daher rührte dann wohl das Phänomen, dass die Auflösung der TLSA-Records bei einer Domäne funktionierte und bei der anderen nicht...

  • DANE - TLSA-Records werden nicht gefunden

    m_ueberall wrote:

    Wurde andersherum getestet, dass für beide Domänen die richtigen/selben DNS-Server zuständig sind? Ist das Problem reproduzierbar, wenn die Abfrage direkt an die IP-Adresse desjenigen DNS-Servers gerichtet wird, dessen Zonefile oben auszugsweise angegeben wurde (um jegliche Verwechslung auszuschließen, vom selben Host via 127.0.0.1 und danach von einem anderen aus)?

    Ja, wenn ich den Master unter 127.0.0.1 abfrage, wird ebenfalls ein NXDOMAIN ausgegeben.


    mainziman wrote:

    ein Tipp: lasse den private Key unverändert, dann bleiben auch die TLSA-Records die selben

    Ja, auf die Möglichkeit bin ich kürzlich auch gestoßen, die kam, nachdem ich mir mein Skript gebaut hatte. Und da es bislang anderthalb Jahre lang lief, habe ich es nicht mehr angefasst.

    Nichtsdestotrotz interessiert mich natürlich, warum nun auf einmal dieser Fehler auftritt.

  • DANE - TLSA-Records werden nicht gefunden

    Moin zusammen,


    ich setze seit rund anderthalb Jahren DANE ein, was bislang auch recht problemlos funktioniert hat. Die Zertifikate liefert letsencrypt, und sobald ein neues Zertifikat erstellt wurde, rotiert ein Skript die TLSA-Records in den betroffenen Zonefiles meiner beiden Domains. So weit, so gut.


    Seit Sonntag funktioniert das aber nur noch bei einer Domain, bei der anderen werden die TLSa-Records nicht mehr gefunden:


    $ dig _443._tcp.syncookie.de IN TLSA @ormanns.net +short:

    3 1 1 4F5FF30E3A1B43A88224689922E95B42305F422DBC7E42FE53B36CEE 8D1E9EC1


    "$ dig _443._tcp.ormanns.net IN TLSA @ormanns.net +short" liefert hingegen nichts, und lasse ich "+short" weg, sehe ich, dass die Ausgabe ein NXDOMAIN ausspuckt.


    Also schaue ich ins Zonefile. Dieses enthält u.a. folgende Records

    Sieht für mich soweit erstmal okay aus, aber vielleicht hat das Zonefile ja einen anderen Fehler?


    # named-checkzone ormanns.net /var/cache/bind/ormanns.net.zone

    zone ormanns.net/IN: loaded serial 2018101744

    OK

    Das Zonefile scheint also auch zu passen. Mir gehen gerade ein bisschen die Ideen aus, wo ich noch ansetzen könnte - ich wäre daher für Input dankbar.


    Beste Grüße,

    Aleph


    Nachtrag: bei mir läuft bind-9.14.8

  • mehrere meiner Domains werden nicht mehr aufgelöst

    chrko,


    vielen Dank für den Hinweis. Tatsächlich zeigt ormanns.net | DNSViz den Fehler an, DNSSEC Analyzer - ormanns.net hingegen vermeldet keine Fehler.
    Ich vermute den Fehler darin, dass BIND nicht die Serial erhöht, denn die Logs enthalten zwar für jede Stunde die folgenden Einträge, jedoch scheinen die Slaves kein Update zu erkennen und Aktualisieren daher auch die Zonefiles nicht.

    Quote

    Apr 4 17:58:02 ormanns.net named[17704]: zone ormanns.net/IN (signed): reconfiguring zone keys
    Apr 4 17:58:02 ormanns.net named[17704]: zone ormanns.net/IN (signed): next key event: 04-Apr-2017 18:58:02.553

    Trotz dem gut geschriebenen Howto von gunnarh und diversen Googlesuchen bin ich hier noch nicht wirklich vorangekommen.


    Zudem hat sich ein zweites Problem aufgetan - AFAIK muss ich update-policy auf "local" setzen, wenn ich automatische Key-Rollover haben will. Dann muss ich aber die Policy für meine Dyndns-Einträge deaktivieren...wie kann ich beides unter einen Hut bringen?


    Besten Dank vorab,
    Aleph

  • mehrere meiner Domains werden nicht mehr aufgelöst

    gunnarh,


    vielen Dank für deine Antwort.


    Vorab: ich habe jetzt eben die beiden betroffenen Zonefiles neu signiert und named neu geladen, jetzt läuft alles wieder wie gehabt.


    Zum Testen habe ich auf mehreren Systemen dig verwendet, dort, wo dig ein SERVFAIL aufgab, konnte die Domain auch nicht aufgelöst werden. Woanders gab es ein NOERROR, dort wurden die Domains dann natürlich auch aufgelöst.


    Einerseits ist es jetzt gut, dass alles wieder läuft, andererseits wüsste ich natürlich schon gern, warum aus heiterem Himmel dieses Problem entstand. Mangels Fehlermeldungen kann ich es aber derzeit nicht wirklich nachvollziehen...


    MfG Aleph

  • mehrere meiner Domains werden nicht mehr aufgelöst

    Guten Abend,


    seit heute Mittag werden zwei meiner Domains (ormanns.net & row-records.de) auf verschiedenen Systemen (bspw. Dig (DNS lookup) resp. Dig (DNS lookup)) nicht mehr gefunden bzw. aufgelöst. dig liefert in dem Fall ein SERVFAIL, ping meldet "unknown host". Bei mir zuhause hingegen können die Adressen aufgelöst werden.


    Ich habe seit dem 15.3. nichts an der BIND-Config geändert, ebenso loggte BIND keine Fehler. Mir fiel nur vorhin bei einem named-checkzone auf ormanns.net auf, dass die (vorhandenen) Keyfiles nicht gefunden werden konnten. Ein paar Minuten später versuchte ich es nochmal, und jetzt lief der Check ohne Fehler durch. Ebenso lieferte der Nameserver Predelegation Check der DENIC keine Fehler.


    Die Zonefiles sehen wie folgt aus:



    Wie gesagt - die Config lief jetzt wochenlang ohne Probleme, zudem treten die Probleme nur bei 2 von 3 Domains auf. Ich bin gerade etwas ratlos, was ich noch checken könnte und wäre froh, falls jemand eine Idee hat.


    MfG Aleph

  • Postfix - TLS library problem bei Mailempfang von Web.de und GMX

    .A., weiterhin vielen Dank für deine Bemühungen und den Input. Die Zertifikate würde ich an der Stelle erstmal so lassen (einfach um nicht ggf. eine weitere Baustelle aufzumachen) und später anpassen.


    Ich nutze gnutls-3.3.26.


    Mit dem Loglevel auf 4 und "tcpdump -X tcp port 25" habe ich mir dann eine Mail von Web.de aus geschickt. Den Output verlinke ich der Übersicht halber:
    mail.log: https://ormanns.net/pub/netcup_maillog
    tcpdump: https://ormanns.net/pub/netcup_tcpdump


    Aus der Ausgabe werde ich aber nicht wirklich schlau...


    MfG Aleph

  • Postfix - TLS library problem bei Mailempfang von Web.de und GMX

    Guten Morgen,

    .A. wrote:

    Ist Dein Zertifikat OK? Hast Du einen TLSA-RR gesetzt?

    Ja, das Zertifikat sollte in Ordnung sein. Die Warnings tauchen ja auch nur bei Verbindungsaufbauten von Web.de und GMX auf, bei allen anderen Mailservern läuft alles anstandslos durch.
    Einen TLSA-Record habe ich nicht gesetzt.

    .A. wrote:

    Nach dem Gesamtinhalt des Threads müssten die Ciphers eigentlich in Ordnung sein. Kannst Du trotzdem mal einen dump vom TLS handshake machen? Also so etwas wie

    Code
    1. tcpdump -w output tcp port 25

    Ich wusste jetzt nicht, wie ich aus dem Output den Traffic zwischen STARTTLS und Verbindungsabbrucht herauslesen kann und habe daher alles auf Port 25 bis zum Eintreffen der Mail gesnifft.


    tcpdump port 25:


    MfG Aleph

  • Postfix - TLS library problem bei Mailempfang von Web.de und GMX

    Quote

    Es ist möglich.

    Magst du verraten, wie?

    .A. wrote:

    Hast Du Deine Konfiguration schon aufgeräumt?

    Ja, ich habe die main.cf um die Einträge erleichtert, welche entweder auf dem Defaultwert standen oder in der aktuellen Version nicht mehr benötigt / unterstützt wurden (ich will nicht wissen, welche Version 2012 unter Debian angeboten wurde - daher rührte, dass ich immer noch Optionen drin hatte, die längst überholt waren):


    postconf -n | grep tls | grep smtpd:

    Code
    1. smtpd_tls_auth_only = yes
    2. smtpd_tls_cert_file = /etc/letsencrypt/live/fullchain.pem
    3. smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem
    4. smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
    5. smtpd_tls_key_file = /etc/letsencrypt/live/privkey.pem
    6. smtpd_tls_security_level = may


    MfG Aleph

  • Postfix - TLS library problem bei Mailempfang von Web.de und GMX

    Ich habe mal die Loggingverbosity etwas heraufgesetzt, wobei nicht wirklich neue Infos bei herumkamen:


    Code
    1. postfix/smtpd[17496]: SSL_accept:SSLv3 flush data
    2. postfix/smtpd[17496]: Anonymous TLS connection established from unknown[212.227.15.14]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
    3. postfix/smtpd[17496]: SSL3 alert read:fatal:insufficient security
    4. postfix/smtpd[17496]: warning: TLS library problem: error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient security:s3_pkt.c:1493:SSL alert number 71:
    5. postfix/smtpd[17496]: lost connection after STARTTLS from unknown[212.227.15.14]
    6. postfix/smtpd[17496]: disconnect from unknown[212.227.15.14] ehlo=1 starttls=1 commands=2


    Laut dem RFC zu TLSv1.2 (https://www.ietf.org/rfc/rfc5246.txt) bedeutet der Fehler folgendes:

    Code
    1. insufficient_security
    2. Returned instead of handshake_failure when a negotiation has
    3. failed specifically because the server requires ciphers more
    4. secure than those supported by the client. This message is always
    5. fatal.


    Daraus schließe ich nun, dass GMX / Web.de unsichere Ciphers verwenden wollen, als mein Server zum Aufbau einer verschlüsselten Verbindung akzeptiert. Also bricht der Verbindungsaufbau ab und GMX / WEb.de versuchen es daraufhin noch einmal:


    Code
    1. postfix/smtpd[17496]: connect from unknown[212.227.15.14]
    2. postfix/smtpd[17496]: DC7CA1000D5: client=unknown[212.227.15.14]
    3. postfix/cleanup[17489]: DC7CA1000D5: message-id=<21373d0a-e8ae-1b45-3f8b-18e171719008@MEINSERVER>


    Die Mail wird also letztendlich angenommen, wie ich auch schon im Eingangsposting schrieb.


    1) Ist die Verbindung, über welche die Mail letztendlich zugestellt werden kann, demzufolge unverschlüsselt?
    2) Falls ja, habe ich überhaupt irgendwelche Möglichkeiten, GMX / Web.de zum Aufbau einer sichereren Verbindung zu zwingen, ohne dass Mails dann nicht zugestellt werden können? Von "encrypt" wird ja abgeraten (Postfix Configuration Parameters)...


    Code
    1. smtpd_tls_auth_only = yes
    2. smtpd_tls_cert_file = /etc/letsencrypt/live/fullchain.pem
    3. smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem
    4. smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
    5. smtpd_tls_key_file = /etc/letsencrypt/live/privkey.pem
    6. smtpd_tls_security_level = may
    7. tls_preempt_cipherlist = yes (ob "yes" oder der Defaultwert "no" macht keinen Unterschied)


    MfG Aleph

  • Postfix - TLS library problem bei Mailempfang von Web.de und GMX

    .A., vielen Dank für die Anmerkungen und Verbesserungsvorschläge. Ich verstehe sie allerdings so, dass es gerade eher um ein sauberes Configfile geht, unabhängig von meinem Problem - ist das korrekt?
    Nichtsdestotrotz führe ich mir deine Vorschläge bei Gelgenheit gerne zu Gemüte :-)


    Zu "smtp_bind_address" - der Server sendet auf einer zweiten IP-Adresse, da ich mit der von netcup bereitgestellten Adresse Probleme beim Versand an Yahoo hatte.


    Bei dem Server handelt es sich übrigens um eine rein privat genutzt Kiste mit einer Handvoll Mailaccounts.


    MfG Aleph

  • Postfix - TLS library problem bei Mailempfang von Web.de und GMX

    Quote

    Bist Du sicher, dass Du folgende Einstellungen möchtest?

    Wenn du so direkt fragst - nein ;-)
    Die Installation lief vorher rund 5 Jahre auf einem Debian-System und ich habe sie beim Umzug zu netcup so übernommen.

    .A. wrote:

    Weißt Du, was Du damit bewirkst? Diese Werte sind recht eigenwillig.

    Du meinst wahrscheinlich smtpd_tls_ask_ccert? Den Parameter habe ich testweise zurück auf den Defaultwert "no" gesetzt.
    Bei den Session Caches kann ich ad hoc nichts eigenwilliges feststellen...

    Quote

    Außerdem solltest Du Deine Konfiguration einmal dringend aufräumen.

    Worauf genau beziehst du dich?


    @ de_bonner: danke für den Input. Ich werde deine Config später mal mit meiner vergleichen (mir fiel gerade auf, dass du "smtpd_tls_auth_only = yes" zweimal drin hast).


    MfG Aleph

  • Postfix - TLS library problem bei Mailempfang von Web.de und GMX

    killerbees19, danke für die schnelle Antwort.


    Ich setze Postfix 3.1.2-r2 ein (shame on me dafür, dass ich diese Angabe im Startposting vergessen habe...).


    postconf -d | grep cipher

    postconf -n | grep cipher

    Quote

    tls_preempt_cipherlist = yes

    Mit Hinblick auf Postfix Configuration Parameters verstehe ich das so, dass dieser Parameter darüber entscheidet, ob Server ("yes") oder Client ("no") darüber entscheiden, welche Chiffre zuerst genommen wird. Aktuell will mein Server TLS eine Cipher haben, welche Web.de und GMX nicht unterstützen, also wird im zweiten Anlauf dann eine unverschlüsselte Verbindung hergestellt. Oder missverstehe ich da was?


    MfG Aleph

  • Postfix - TLS library problem bei Mailempfang von Web.de und GMX

    Guten Abend,


    ich bemerke seit einiger Zeit, dass der Mailempfang von Web.de und GMX zu Fehlermeldungen im Log führt. Die Mails werden dann aber in einem neuen Versuch angenommen:

    Ich verstehe die Log-Einträge wie folgt:
    - Web.de versucht eine TLS-Verbindung aufzubauen, was fehlschlägt
    - Web.de stellt die Mail daraufhin über eine unverschlüsselte Verbindung zu


    Die TLS-bezogenen Optionen von Postfix sind wie folgt gesetzt:


    Die Mails werden zwar zugestellt, es stört mich aber, dass (mal wieder...) nur Verbindungen mit Web.de und GMX nicht rund laufen. Ich stehe absolut auf dem Schlauch, wo ich bei der Fehlerbehebung (oder -suche) anfangen könnte - any idea?


    MfG Aleph

  • E-Mails zu Yahoo sind wiederholt "temporarily deferred"

    Ich habe mir vor rund einer Woche für 1 € pro Monat eine zweite IP-Adresse besorgt. Laut dem netcup-Support werden zusätzliche Adressen generell aus einem anderen Pool vergeben.
    Mit der neuen Adresse scheint nun alles wie gewünscht zu laufen - Testmails an Yahoo kamen an.


    Ein fader Beigeschmack bleibt natürlich, da mich dieses Problem pro Jahr weitere 12 € kostet.


    MfG Aleph

  • E-Mails zu Yahoo sind wiederholt "temporarily deferred"

    Auch diesmal war die Antwort folgende:

    Ich weise darauf hin, dass mittlerweile nur noch "appropriate changes" gemacht werden, ganz zu Beginn der Problematik waren es noch "significant changes". So oder so ist das natürlich alles Quark - die Mails sind nach wie vor in der Queue und deferred.
    Nochmal die Checkliste, was Yahoo empfiehlt:

    -> Beim CFL-Programm habe ich mich registriert. Die paar Yahoo-Accounts, die Post von meinem Server bekommen, sind entweder mein Testaccount oder persönliche Kontakte der User auf meiner Kiste. Post mit Bezug auf die CFL habe ich noch nicht bekommen.


    • Check your email streams. Use separate IPs and
      streams, depending on your email content type. If the IPs you're sending
      your presumably valid email from are also sending unsolicited
      commercial email, your sending reputation can be impacted.

    -> Dürfte bei einem vorwiegend privat genutzten System wohl kaum relevant sein.


    • Make sure your emails are DKIM signed. DKIM signature helps Yahoo authenticate that email is safe, secure and from the senders who claim to send it.

    -> DKIM ist eingerichtet.


    • Control your email traffic. If you send emails at a
      certain rate and suddenly have a spike of activity, you could get
      flagged as a compromised sender and marked as spam. Instead, plan your
      campaign and spread it out over a period of time.

    -> Ich behalte meine Systeme mit Zabbix und tenshi, die auf einem separaten Logsystem laufen, im Blick. Ungewöhnliches Verhalten (hohe CPU- oder Netzauslastung) sollte mir somit eigentlich auffallen.


    • Check your email content. If the subject lines are
      not helpful or appear to be generic, users may not be interested and
      mark it as spam. When many users mark an email you send as spam, it can
      impact your overall deliverability.

    -> s.o., vorwiegend private Mails


    • Publish reverse DNS (PTR) records for your sending IPs.
      Yahoo is more likely to downgrade an IP’s sending reputation if there
      isn't a reverse DNS entry for your IP address. Not having a reverse DNS
      entry can cause your mailing IP to look like a dynamically-assigned IP
      instead of a static mail server.

    -> ist gegeben


    Ich habe eben eine Testmail an allaboutspam geschickt, das Ergebnis war, dass meine Mail scheinbar URLs enthält, welche bei URIBL gelistet sind. Sowohl meine IP-Adresse als auch meine Domains sind dort allerdings NICHT gelistet.
    Da mir mittlerweile die Optionen ausgehen, werde ich mal bei netcup nachfragen, ob es möglich ist, eine zweite IP-Adresse aus einem _anderen_ Adressbereich zu erhalten. Vielleicht bringt es ja was, die Mails dann darüber zu senden.


    MfG Aleph