Posts by Aleph

  • Serverumzug + DNSSEC -> Probleme mit mehreren Domains

    Hallo NaN,


    danke für deine Antwort.

    Ich habe bei der .net-TLD jetzt den dritten Nameserver rausgenommen, dieser liegt bei einem anderen Hoster und hat anscheinend ein IPv6-Problem. Nachdem ich die DNS-Settings im CCP gespeichert habe, ist jetzt auch die entsprechende Warnung bei DNSViz verschwunden. Die Warnung bzgl. der Glue-Records bleibt aber.


    Aktuell sind im CCP für die .net-TLD jetzt folgende Nameserver hinterlegt:

    ns1.ormanns.net 37.120.174.123 2a03:4000:6:70dd::

    ns2.ormanns.net 185.16.60.59 2a03:4000:a:52::


    Ich verstehe deine Rückmeldung so, dass diese IPv6-Adressen streng genommen nicht korrekt sind. Allerdings wird bei DNSViz jetzt nur noch folgende Warnung ausgegeben:

    • net to ormanns.net: The glue address(es) for ns1.ormanns.net (2a03:4000:6:43f3::) differed from its authoritative address(es) (2a03:4000:6:70dd::). See RFC 1034, Sec. 4.2.2.
    • net to ormanns.net: The glue address(es) for ns1.ormanns.net (37.120.165.116) differed from its authoritative address(es) (37.120.174.123). See RFC 1034, Sec. 4.2.2.

    Ich schließe daraus, dass die dort angegebenen Adressen so schon verarbeitet werden können, denn sonst müsste ja auch eine Warnung für ns2 ausgegeben werden. Oder verstehe ich dein Posting falsch?


    Viele Grüße
    Aleph

  • Serverumzug + DNSSEC -> Probleme mit mehreren Domains

    Guten Morgen zusammen,


    erst einmal sorry für den unspezifischen Titel, aber da sich mittlerweile mehrere Baustellen auftun, bin ich ein bisschen "lost".


    Ich habe vor mehreren Monaten von meinem alten netcup-vServer auf einen neueren - ebenfalls bei netcup - migriert.

    Ich betreibe seit Jahren eine eigene bind-Instanz, welche sich um meine Domains kümmern. Die Domains liegen ebenfalls bei netcup. Ich habe vor rund 8 Jahren DNSSEC für meine Domains eingerichtet und soweit lief das auch alles jahrelang ordentlich vor sich hin.


    Beim Umzug habe ich bind dann auch endlich mal auf eine aktuellere Version geupdatet und nutze seitdem den neuen Parameter "dnssec-policy", über welchen das Management von KSK und ZSK vereinfacht und durch bind übernommen werden soll.


    Aktuell habe ich mit mehreren Problemen zu kämpfen:

    • Für ormanns.net sind laut https://dnsviz.net/d/ormanns.net/dnssec/ u.a. veraltete Glue-Records hinterlegt. Im CCP habe ich aber schon vor Monaten die aktuellen Adressen meiner Nameserver eingetragen - einmal als Hostname, einmal in IPv4 und einmal in IPv6. Woher kommen die veralteten Einträge?
    • Laut https://dnsviz.net/d/ormanns.net/dnssec/ reagieren nicht alle hinterlegten Nameserver auf Anfragen - das ist korrekt, denn die dort abgefragten Nameserver sind ja zum Teil außer Betrieb. Wo hakt es, wo werden die Infos nicht korrekt durchgereicht?


    • syncookie.de kann aufgelöst werden, hier hakt es aber nach wie vor an der sauberen DNSSEC-Implementierung (siehe https://dnsviz.net/d/syncookie.de/dnssec/). bind liefert mir für diese Domain keinen ZSK und KSK mehr, sondern einen CSK, der die beiden Keys kombiniert.
      • Den Status des Keys rufe ich wie folgt ab:
        # rndc dnssec -status syncookie.de
        dnssec-policy: default
        current time: Sat Apr 26 08:32:10 2025

        key: 64045 (ECDSAP256SHA256), CSK
        published: yes - since Thu Feb 13 18:44:12 2025
        key signing: yes - since Thu Feb 13 18:44:12 2025
        zone signing: yes - since Thu Feb 13 18:44:12 2025

        No rollover scheduled
        - goal: omnipresent
        - dnskey: omnipresent
        - ds: omnipresent
        - zone rrsig: omnipresent
        - key rrsig: omnipresent
      • Wenn ich mir dann das Keyfile anschaue, erhalte ich meinem Verständnis nach den Pubkey (ist das wirklich der öffentliche Schlüssel?) sowie ein paar Parameter:
        ; This is a key-signing key, keyid 64045, for syncookie.de.
        ; Created: 20250213174412 (Thu Feb 13 18:44:12 2025)
        ;Publish: 20250213174412 (Thu Feb 13 18:44:12 2025)
        ; Activate: 20250213174412 (Thu Feb 13 18:44:12 2025)
        ; SyncPublish: 20250214184912 (Fri Feb 14 19:49:12 2025)
        syncookie.de. 3600 IN DNSKEY 257 3 13 FIQP1EVPR[...]5UQ==
      • Heißt für mich: 257 = KSK, 13 = verwendeter Algorithmus und dahinter der Pubkey. Diese Parameter trage ich im CCP für diese Domain ein und speichere sie.
      • Ein "delv syncookie.de" liefert mir dann aber lokal auf dem Nameserver folgendes:
        ;; validating syncookie.de/A: no valid signature found
        ; unsigned answer syncookie.de. 60 IN A 37.120.174.123
        syncookie.de. 60 IN RRSIG A 13 2 60 20250504192639 20250420191653 64045
        syncookie.de. wYiSJYjmvIwrOjh+[...]w==
      • Welcher Schlüssel ist das, der hier ausgegeben wird?


    • row-records.de wird seit einiger Zeit nicht mal mehr korrekt aufgelöst, je nachdem welchen Nameserver man nutzt. Wenn ich meine Nameserver direkt abfrage, klappt alles. Der NAST Predelegation Check bei der DENIC liefert "Prüfung erfolgreich" und gibt mir die beiden Nameserver aus, welche ich im CCP für diese Domain hinterlegt habe. Rufe ich aber 1.1.1.1 oder 8.8.8.8 ab, bekomme ich einen SERVFAIL. Irgendwo in der Kette scheint die Domain also nicht korrekt weitergereicht zu werden, so ist zumindest mein Verständnis.
    • Allerdings ist hier auch noch ein Dnskey angegeben, welchen ich vorgestern aus dem CCP gelöscht habe. Ich will die Domain erstmal ordentlich auflösen lassen, bevor ich mich auch hier mit DNSSEC herumschlage.

    Daraus ergeben sich für mich folgende Fragen:

    • Hat netcup öffentlich verfügbare Nameserver, an welche ich testweise meine Queries richten kann? 46.38.225.230 und 46.38.252.230 scheinen keine Anfragen von außerhalb zuzulassen. Ich habe aber bei mehreren Domains das Problem, dass veraltete DNS-Informationen kursieren und würde gerne herausfinden, an welcher Stelle es klemmt.
    • Wie kann ich einen CSK ordentlich im CCP einbinden? Auf meine Anfrage beim Support kam nach 9 Tagen die Antwort "CSK Sollte gültig sein, solange das CCP das zulässt." - das hilft mir aktuell leider nicht weiter.
    • Ist das für syncookie.de beschriebene Vorgehen aus eurer Sicht korrekt? Wenn ja, dann sollte ich dieses ja theoretisch auf weitere .de-Domains übertragen können...


    Sicherlich werden hier noch Infos fehlen - diese reiche ich bei Bedarf gerne zeitnah nach.


    Viele Grüße

    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

    Quote from m_ueberall

    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.


    Quote from mainziman

    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,

    Quote from .A.

    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.

    Quote from .A.

    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
    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?

    Quote from .A.

    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
    smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/fullchain.pem
smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
smtpd_tls_key_file = /etc/letsencrypt/live/privkey.pem
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
    postfix/smtpd[17496]: SSL_accept:SSLv3 flush data
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)
postfix/smtpd[17496]: SSL3 alert read:fatal:insufficient security
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:
postfix/smtpd[17496]: lost connection after STARTTLS from unknown[212.227.15.14]
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
    insufficient_security
Returned instead of handshake_failure when a negotiation has
failed specifically because the server requires ciphers more
secure than those supported by the client. This message is always
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
    postfix/smtpd[17496]: connect from unknown[212.227.15.14]
postfix/smtpd[17496]: DC7CA1000D5: client=unknown[212.227.15.14]
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
    smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/fullchain.pem
smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
smtpd_tls_key_file = /etc/letsencrypt/live/privkey.pem
smtpd_tls_security_level = may
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.

    Quote from .A.

    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