Ausblick auf das nächste große Release

  • gute Entscheidung habe es bisher auch nur auf einem Testsystem.


    Denke aber in einigen Tagen sind die Problemchen die es noch gibt vom ausgezeichneten Team hier lokalisiert und weitestgehend behoben, hier scheint es mittlerweile auf dem Testsystem nach entsprechenden Nachbesserungen zu laufen.

    • Neu
    • Offizieller Beitrag

    Bei der DNSSEC-Migration gab es leider einen Fehler: bei DNS-Zonen, welche einen 4096-Bit RSA-Schlüssel als KSK haben, und bei denen wiederum der ZSK-Key-Tag einen kleineren Wert als der KSK-Key-Tag hat, bei denen wurde eine falsche DNSSEC-Policy in die Zonenliste geschrieben (für 2048-Bit statt 4096-Bit-KSKs). Das führte wiederum dazu, dass BIND die KSKs nicht übernommen sondern Neue erzeugt hat. :-/

    (das ist leider eine seeehr hässliche Nebenwirkung der "wir-kümmern-uns-ab-sofort-um-alles"-Philosophie bei dnssec-policy.


    Der Migrationsfehler wurde eben behoben, wir entwickeln eben noch ein Routine zur Korrektur aller betroffenen Domains (bei bereits migrierten Systemen), wird dann gleich in Form der v2.18.1 bereitstehen.

  • Bei der DNSSEC-Migration gab es leider einen Fehler: bei DNS-Zonen, welche einen 4096-Bit RSA-Schlüssel als KSK haben, und bei denen wiederum der ZSK-Key-Tag einen kleineren Wert als der KSK-Key-Tag hat, bei denen wurde eine falsche DNSSEC-Policy in die Zonenliste geschrieben (für 2048-Bit statt 4096-Bit-KSKs). Das führte wiederum dazu, dass BIND die KSKs nicht übernommen sondern Neue erzeugt hat. :-/

    (das ist leider eine seeehr hässliche Nebenwirkung der "wir-kümmern-uns-ab-sofort-um-alles"-Philosophie bei dnssec-policy.


    Der Migrationsfehler wurde eben behoben, wir entwickeln eben noch ein Routine zur Korrektur aller betroffenen Domains (bei bereits migrierten Systemen), wird dann gleich in Form der v2.18.1 bereitstehen.


    Wir hatten im Rahmen eines Umzugs eine niedrige TTL für schnellere Umstellungen gesetzt. Genau das hat den Effekt des Problems potenziert:


    Durch die fehlerhafte dnssec-policy wurden offenbar neue KSKs erzeugt, was dazu führte, dass unsere Domain plötzlich nicht mehr auflösbar war – insbesondere bei deutschen DNS-Providern heute schon wieder, jetzt dauert es wieder mehrere Stunden bis die DNS Änderungen bei den Kunden ankommen, es ist zum Mäusemelken. Es tritt im übrigen nur bei .de domains bei mir auf die .at /.ch waren nicht betroffen das machte die Sache noch schwerer zu verstehen also musste es irgendwas mit der DENIC zu tun haben

  • Bei der DNSSEC-Migration gab es leider einen Fehler: bei DNS-Zonen, welche einen 4096-Bit RSA-Schlüssel als KSK haben, und bei denen wiederum der ZSK-Key-Tag einen kleineren Wert als der KSK-Key-Tag hat, bei denen wurde eine falsche DNSSEC-Policy in die Zonenliste geschrieben (für 2048-Bit statt 4096-Bit-KSKs). Das führte wiederum dazu, dass BIND die KSKs nicht übernommen sondern Neue erzeugt hat. :-/

    (das ist leider eine seeehr hässliche Nebenwirkung der "wir-kümmern-uns-ab-sofort-um-alles"-Philosophie bei dnssec-policy.


    Der Migrationsfehler wurde eben behoben, wir entwickeln eben noch ein Routine zur Korrektur aller betroffenen Domains (bei bereits migrierten Systemen), wird dann gleich in Form der v2.18.1 bereitstehen.

    Genau das hatte ich bei zwei Domains. Gute Erklärung, habe ich es mir also doch nicht eingebildet 😄


    Ist das auch der Grund dafür, dass KSKs mit Algo 13/14 gar nicht erst gepublished werden?

    Bei mir wurde in jedem Fall von Bind immer ein neuer KSK mit Algo 7 erzeugt und die Policy lc-nsec3rsasha1-2048 angewandt.

    Ich habe jetzt über die GUI neue Algo 7 Keys erzeugt, beim zweiten Versuch werden jetzt die verwendet, da die erwähnte Bedingung mit den Key-Tags wohl nicht mehr zutrifft.

    • Neu
    • Offizieller Beitrag

    Durch die fehlerhafte dnssec-policy wurden offenbar neue KSKs erzeugt, was dazu führte, dass unsere Domain plötzlich nicht mehr auflösbar war – insbesondere bei deutschen DNS-Providern heute schon wieder, jetzt dauert es wieder mehrere Stunden bis die DNS Änderungen bei den Kunden ankommen, es ist zum Mäusemelken. Es tritt im übrigen nur bei .de domains bei mir auf die .at /.ch waren nicht betroffen das machte die Sache noch schwerer zu verstehen also musste es irgendwas mit der DENIC zu tun haben

    Das tut mir sehr leid, ich verstehe Ihren Ärger. Mir einem Provider haben wir die Nacht durch durchgearbeitet, um die Ursache zu lokalisieren und zu beheben (der Chatverlauf zwischen einem Techniker dort und einem Entwickler von uns endete heute früh um 05:02).

    Mit der TLD dürfte das aber nichts zu tun gehabt haben. Ich denke wir haben das inzwischen ganz gut nachvollzogen und werden eine ausführliche Beschreibung im Laufe des Tages veröffentlichen. Das Verhalten von BIND mit der dnssec-policy ist Fluch und Segen zugleich.

    Aktuell entwickeln wir noch ein Tool, um die fälschlicherweise erzeugten KSKs, die in Form von DNSKEYs noch in manchen Zonen hängen, sauber zu entfernen. Die Domains sollten soweit operativ funktionieren, aber es gibt in manchen Fällen sehr viele Log-Meldungen bei BIND die nun behoben werden müssen.

  • Bei der DNSSEC-Migration gab es leider einen Fehler: bei DNS-Zonen, welche einen 4096-Bit RSA-Schlüssel als KSK haben, und bei denen wiederum der ZSK-Key-Tag einen kleineren Wert als der KSK-Key-Tag hat, bei denen wurde eine falsche DNSSEC-Policy in die Zonenliste geschrieben (für 2048-Bit statt 4096-Bit-KSKs). Das führte wiederum dazu, dass BIND die KSKs nicht übernommen sondern Neue erzeugt hat. :-/

    (das ist leider eine seeehr hässliche Nebenwirkung der "wir-kümmern-uns-ab-sofort-um-alles"-Philosophie bei dnssec-policy.


    Der Migrationsfehler wurde eben behoben, wir entwickeln eben noch ein Routine zur Korrektur aller betroffenen Domains (bei bereits migrierten Systemen), wird dann gleich in Form der v2.18.1 bereitstehen.

    Kurze Rückfrage hinsichtlich v2.18.1 (da aktuell noch kein Changelog vorhanden): sind nach Einspielung des Updates noch manuelle Änderungen/Anpassungen notwendig oder übernimmt das Update eigenständig die entsprechend notwendigen Routinen?


    Und noch eine weitere Nachfrage zu v2.18.1/v3.0.0: unterstützt LiveConfig 2/3 bereits Dovecot 2.4 insbesondere hinsichtlich der notwendigen Anpassungen (2.4 ist nicht mit 2.3 Config-Files kompatibel) der Konfigurationsdateien?

    • Neu
    • Offizieller Beitrag

    Mit 2.18.1 wurde der Fehler mit der DNSSEC-Migration von 4096-Bit RSA-Keys behoben (wer kein DNSSEC oder keine so großen Keys verwendet hat, den betrifft das also nicht).

    Und in etwa einer Stunde werden wir 2.18.2 veröffentlichen, mit der das Upgrade auf LiveConfig 3 reibungsloser läuft (das betrifft die erwähnte Maskierung von Diensten während des Upgrades).

    Manuelle Nacharbeiten sind eigentlich nicht erforderlich. Falls Dienste deaktiviert/maskiert wurden, korrigieren die Updates das automatisch.

    Das Changelog wird im Laufe des Nachmittags auch entsprechend aktualisiert.


    Zu Dovecot 2.4: die "breaking changes" sind uns bekannt, Debian 13 soll diesen Samstag (09.08.) erscheinen und wird mit Dovecot 2.4 ausgeliefert. Wir passen derzeit die entsprechenden Lua-Scripte an um das bereits zu berücksichtigen - hierfür wird es entsprechend noch mal ein LiveConfig-Update geben (sowohl für 2.18 als auch 3.0).

    • Neu
    • Offizieller Beitrag

    Wir haben eben auch ein Upgrade von 2.8.2 auf 3.0.1 durchgeführt, die /etc/liveconfig/lclogparse.conf blieb dabei erhalten, ebenso waren alle Dienste korrekt "unmasked".

    lcbackup ist in LiveConfig 3 ein vollständig neues System, der Dienst wird da erst aktiviert wenn man diesen unter Serververwaltung -> Datensicherung aktiviert und mindestens ein Storage-Ziel definiert. (Doku wird gerade entsprechend erweitert).

    Hatten Sie während des Upgrades irgendwelche Fehler/Warnungen?

    • Neu
    • Offizieller Beitrag

    Ist das auch der Grund dafür, dass KSKs mit Algo 13/14 gar nicht erst gepublished werden?

    Ja, für einen Algorithmus-Rollover genügt es nicht, einfach "nur" einen anderen Key zu erzeugen. Wir werden die DNSSEC-Maske in dieser Hinsicht noch etwas anpassen - künftig wird man wohl keinen konkreten Key erzeugen, sondern einen Algorithmus auswählen (um den Rest kümmern sich LC und BIND dann im Hintergrund). Zudem muss für einen Algorithmus-Rollover dann auch angezeigt werden, wann man die DS-Records der alten Keys bei der Registry entfernen kann.

    • Neu
    • Offizieller Beitrag

    Mails funktionieren jetzt wieder. Mir scheint als wurde der Installationsprozess hier nicht komplett zu Ende ausgeführt. Das Log gibt dazu leider nichts her.

    Da sind wir ja auch noch eine Info schuldig: bei einem Upgrade von LC 2 auf 3 wird technisch betrachtet LiveConfig 2 entfernt (remove) und anschließend LiveConfig 3 installiert. Die Scripte, die hierbei in den einzelnen Schritten vom Paketmanager ausgeführt werden (u.a. postrm) werden zum Teil automatisch erzeugt (dpkg-helper). Und genau hier gab es einen fiesen Fehler: nach unseren Update-Tests gab es offenbar nochmal eine Änderung am postrm, welche bei der Deinstallation des Pakets liveconfig auch die Service-Unit-Files gelöscht hat (was hier eigentlich nur bei einem purge erfolgen soll). Das ist nun korrigiert, so dass Upgrades zwischen diesen Paketen nun eigentlich völlig reibungslos ablaufen sollten.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!