Auto DNSSEC BIND

  • Im Betriebsmodus "inline-signing yes; auto-dnssec maintain;" ist es nicht nötig die Zone manuell mittels "rndc signing" zu signieren. Nach einem Reload von Bind müsste dieser automatisch die Zonen signieren, was Du mit entsprechenden Log-Output im SysLog nachvollziehen kannst.


    Vielleicht hilft Dir ja mein HowTo: https://hitco.at/blog/sicherer…ste-anbieter-dnssec-dane/

    Die DNSSEC Konfiguration startet in Kapitel 2.5


    Mögliche Fehlerquellen:

    • beim dnssec-keygen eventuell nicht die richtige Zone angegeben?
    • Das key-directory in dem die Keys liegen nicht korrekt in der Zonen-Konfiguration definiert?
    • Unpassende Rechte, sodass Dein bind-Prozess die Keys nicht lesen kann
    • ...
    • Das Syslog sollte Dir jedenfalls Anhaltspunkte geben. Bind restarten und Syslog-Output beobachten.
    • Unpassende Rechte, sodass Dein bind-Prozess die Keys nicht lesen kann
    • ...
    • Das Syslog sollte Dir jedenfalls Anhaltspunkte geben. Bind restarten und Syslog-Output beobachten.

    Das wars. Bind konnte lesen, aber nicht schreiben die signieren Zonefiles. Top Anleitung, wenn ich das mal vorher gewusst hätte!

    @gunnarh, entnehme ich es deiner Anleitung richtig, dass der Verweis in der domain.conf weiterhin auf der urpeünglichen Zonen Datei bleibt und nicht auf .signed oder so geändert werden?

  • Ja, der Verweis in der Config zeigt weiterhin auf das unsignierte (mit einem Editor änderbare) File.

    Im Modus "inline-signing yes; auto-dnssec maintain;" muss du Dich um das signierte File und das Journal (jnl bzw. jbk) nicht kümmern, darum kümmert sich bind selbst.


    Nachtrag: Wenn dich der Inhalt des ".signed" Files interessiert lässt sich dieses mit "named-checkzone" dumpen. Das Journal lässt sich mit named-journalprint anzeigen.

  • Die Konfiguration der Slave Server ändert sich mit dnssec nicht.


    Dein Fehlerszenario betreffend Schreibfehler ist mir unklar. Wenn aus Sicht bind keine passenden keyfiles vorhanden sind scheitert die Signatur und die Zone bleibt unsigniert.

  • Die Konfiguration der Slave Server ändert sich mit dnssec nicht.


    Dein Fehlerszenario betreffend Schreibfehler ist mir unklar. Wenn aus Sicht bind keine passenden keyfiles vorhanden sind scheitert die Signatur und die Zone bleibt unsigniert.

    DNSSEC sollte auf dem Slave aber aktiviert sein? Nur die signierte Zone wird auf den Slave übertragen?


    Mit dem Schreibfehler meinte ich den Eintrag in der übergeordneten Zone, wie beim Registrar. Würde sich da die Vergabestelle beschweren, wenn der Key falsch ist?

  • Was meinst Du mit "DNSSEC sollte auf dem Slave aber aktiviert sein"?

    Ein Bind in aktueller Konfiguration unterstützt DNSSEC und hat dieses automatisch aktiviert. Du müsstest es also schon explizit deaktivieren.

    Es geht auch nicht darum ob Du DNSSEC Validation aktiviert hast.

    Wenn die Zone am Master signiert ist, und der Slave ein halbwegs aktueller Bind in der Default-Konfiguration ist, dann ist am Slave nichts besonderes zu berücksichtigen, eine DNSSEC aktivierte Zone sieht am Slave in der Config nicht anders aus als eine Zone ohne aktivem DNSSEC.


    Ein Schreibfehler in der übergeordneten Zone (also beim Registrar) führt dazu, dass alle DNSSEC aktivierten Resolver die Signatur als ungültig ansehen werden und Deine Domain daher von allen DNSSEC aktivierten Resolvern nicht mehr korrekt aufgelöst werden kann.


    Ob Dein Registrar beim Eintragen des ZSK(257) eine Prüfung vornimmt, und das Eintragen nur dann durchführt wenn der von Dir eingegebene Schlüssel zur aktuellen Zone passt lässt sich ohne den Registrar zu kennen nicht sagen. Einige Registries und/oder Registrare prüfen das und lehnen den Key wenn er zu einer Fehlkonfiguration führen würde ab. Aber verlassen darauf würde ich mich nicht.

  • Google ist Dein Freund, Kapitel 3.6.2 hier:

    https://www.denic.de/fileadmin…cumentation/DENIC-23p.pdf


    Quote

    Das DNSKEY-RRSet muss an allen autoritativen Servern identisch sein [sonst Ausgabe von
    ERROR].
    Mindestens einer der zur Registrierung übergebenen Schlüssel muss sichtbar sein [sonst
    Ausgabe von ERROR]. Für jeden nicht sichtbaren Schlüssel wird eine WARNING erzeugt.
    Eventuell im DNSKEY-RRSet zusätzlich vorhandene Schlüssel werden nicht betrachtet.