Auto DNSSEC BIND

  • ZSK und KSK, die Berechtigungen sind entsprechend der verlinkten Anleitung konfiguriert.

    Ich bin mittels root eingeloggt. Daher entfällt das sudo oder sehe ich das falsch?

  • 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.

  • Ich muss mich da auch nicht bei den Slave Servern weiter drum kümmern, das geht auch von alleine?

    Was würde passieren, wenn ich den falschen 257-Key hinterlege, ein Schreibfehler drinne wäre etc?

  • 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.

  • Ich meine damit, dass

    Code
    dnssec-enable yes;

    gesetzt bzw. belassen sein muss, auf dem Slave-Server.


    Wie sieht es bei der DENIC mit einer Prüfung aus?

  • Google ist Dein Freund, Kapitel 3.6.2 hier:

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


    Zitat

    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.

  • @Georg Deine Frage scheint mir DNS over TLS zu betreffen. Das ist ein Protokoll zwischen Stub-Resolver am Endgerät (Client, Webbrowser) zum interativ arbeitenden DNS-Resolver ("DNS-Server"). Da ein Stub-Resolver am Client aber gar kein DNSSec validiert (das erledigt der iterative Resolver am DNS-Server) sehe ich hier keinen Konex - also nein, wüsste nicht was da zusätzlich zu konfigurieren wäre.

  • Danke für deine Antwort. Verstehe ich es richtig DNS over TLS betrifft nur den DNS Resolver (eingetragenen DNS Server) für die Endgeräte? Der Austausch zwischen den bei der Vergabestelle hinterlegten DNS-Servern erfolgt weiterhin immer nur über 53 unverschlüsselt?