☰

Wie sichere ich eine Zone mit dem DLV-Dienst von dlv.isc.org?

tag-icon • tag-icon domain-name-system bind dnssec
Wie sichere ich eine Zone mit dem DLV-Dienst von dlv.isc.org?

Ich richte die Domain-Lookaside-Validierung ein. Ich glaube, ich habe fast alles richtig gemacht. Ich bin den Anweisungen hier gefolgt:https://dlv.isc.org/about/using. Ich habe meine Domain registriert und den Schlüssel zur Schlüsselsignatur hochgeladen, meine Zone mit -l dlv.isc.orgOption signiert, dlv.isc.org als fremden Nameserver für meine Domain in den Zonendateien hinzugefügt. named schlägt stillschweigend fehl. Ich habe sogar geändert, /dev/nullum /var/log/named.logeinige Informationen aus named herauszupressen. Ich habe überprüft, ob die Änderungen vorgenommen wurden, aber es hat nicht funktioniert. Ich weiß nicht, was ich überprüfen oder versuchen soll.

Ich stelle 2 Fragen:

  1. Strategien zum Sammeln von Informationen aus benannten, wenn es stillschweigend fehlschlägt, wie es
  2. Ist die Konfiguration korrekt? Meine begrenzten Kenntnisse von DNS und DNSSEC sagen mir, dass dies funktionieren sollte

Datei weiterleiten:

$TTL 3600;

@ IN SOA ns1.sub.db.archives.net. dlv.isc.org. (
2014112100  ; serial
4h      ; refresh
1h      ; retry
7d      ; expiration
1h      ; minimum
)
$INCLUDE Ksub.db.archives.net.+008+07374.key
$INCLUDE Ksub.db.archives.net.+008+24586.key

        IN  NS  ns1.sub.db.archives.net.
        IN  NS  ns1.db.archives.net.
        IN  NS  dlv.isc.org.

dlv.isc.org.    IN  A   149.20.1.5
ns1.db.archives.net.    IN  A   10.103.35.66
ns1     IN  A   10.103.35.64
luke        IN  A   10.103.35.64
bo      IN  A   10.103.35.65
daisy       IN  A   10.103.35.66
sheriff     IN  A   10.103.35.67
boss        IN  A   10.103.35.68
dlv.sub.db.archives.net. 0 IN TXT "DLV:1:blablabla"

dlv.isc.org. IN DNSKEY 257 3 5 BEAAAAPHMu ...TDN0YUuWrBNh

Rückwärtsdatei:

$TTL 3600

@ IN SOA ns1.sub.db.archives.net. dlv.isc.org. (
2014112100  ; serial #
4h              ; refresh
1h              ; retry
7d              ; expiration
1h              ; minimum
)

                IN      NS  ns1.sub.db.archives.net.
                IN      NS  ns1.db.archives.net.
        IN  NS  dlv.isc.org.

5.1.20.149  IN  PTR dlv.isc.org.
66.35.103.10    IN  PTR ns1.db.archives.net.
64  IN  PTR ns1.sub.db.archives.net.
64  IN  PTR luke.sub.db.archives.net.
65  IN  PTR bo.sub.db.archives.net.
66  IN  PTR daisy.sub.db.archives.net.
67  IN  PTR sheriff.sub.db.archives.net.
68  IN  PTR boss.sub.db.archives.net.

dnssec-signzone-Befehl:

dnssec-signzone -l dlv.isc.org -o sub.db.archives.net -k Ksub.db.archives.net.+008+24586.key sub.db.archives.net.fwd Ksub.db.archives.net.+008+07374.key

genannt:

[root@test master]# service named start
Starting named:                                            [FAILED]

Antwort1

  1. Strategien, um herauszufinden, warum namedder Start fehlschlägt:
    • Überprüfen Sie named-checkconf -zjdie Ausgabe. ( sollte wahrscheinlich named-checkconfauch named-checkzoneTeil Ihres regulären Arbeitsablaufs sein, nicht nur zur Fehlerbehebung)
    • Prüfen Sie die Protokolle. ( namedProtokolliert standardmäßig in Syslog, prüfen Sie, named.confob Sie eine Protokollierungskonfiguration haben, die dies möglicherweise außer Kraft setzt.)
    • Wenn keine der oben genannten Maßnahmen hilft (was unwahrscheinlich ist), besteht auch die Möglichkeit zu prüfen, welche Parameter Sie normalerweise in Ihrer namedBefehlszeile haben, und das Programm manuell zu starten, indem Sie diese -gzu Ihrem normalen Parametersatz hinzufügen (dies erzwingt, nameddass das Programm im Vordergrund bleibt und in stderr protokolliert wird).


  1. Es gibt zahlreiche offensichtliche Probleme mit den in der Frage enthaltenen Zonendaten, die in keiner Weise spezifisch für DNSSEC oder DLV sind. Ehrlich gesagt würde ich Ihnen empfehlen, sich als ersten Schritt mit den DNS-Grundlagen zu befassen.
    Einige der Probleme, die mir aufgefallen sind, waren die folgenden. Bitte konsultieren Sie named-check{conf,zone}}auch die Protokolle und/oder die Ausgabe.

    • Die SOADatensätze haben sehr unwahrscheinliche RNAME-Werte ( [email protected])
    • dlv.isc.orgist als Nameserver aufgeführt, aber ich bezweifle sehr, dass er Ihre Zonen hostet.
    • dlv.isc.org. IN A ...sieht nicht so aus, als ob es in diese Zone gehört.
    • ns1.db.archives.net. IN A ...sieht nicht so aus, als ob es in diese Zone gehört.
    • dlv.isc.org. IN DNSKEY ...sieht nicht so aus, als ob es in diese Zone gehört.
    • 5.1.20.149 IN PTR dlv.isc.org.– Abgesehen davon, dass es falsch geschrieben ist, ist dies ein weiterer Datensatz, der hier nicht hingehört.
    • 66.35.103.10 IN PTR ns1.db.archives.net.gehört wahrscheinlich dazu, ist aber falsch geschrieben.


(Mein Eindruck aus der Frage ist, dass die beiden Zonen sub.db.archives.netund sind 35.103.10.in-addr.arpa, worauf ich die Aussagen bezüglich der Zonenfremdheit gestützt habe. Wenn man sich zusätzlich zu den Zonendaten die tatsächliche Konfiguration ansieht, würde das dies bestätigen.)

Antwort2

Die tatsächlichen file not foundFehler sind ziemlich selbsterklärend (solche Dateien existieren nicht, nehme ich an?).

Die Datensätze befinden sich jedoch DSin der übergeordneten Zone oder alternativ DLVauf dem DLV-Server.

Dies bedeutet, dass Ihr Schritt 4 nicht vorhanden ist (gemäß der Anleitung, auf die Sie verlinkt haben).

Können Sie die DS-Einträge wirklich nicht stattdessen in die übergeordnete Zone übertragen? DLV war anfangs hauptsächlich eine Übergangslösung und sollte nicht die erste Wahl sein.

Siehe auchInline-Signierung (und automatische DNSSec-Wartung), dies ist im Allgemeinen eine bessere Option für die Zonensignierung und Schlüsselverwaltung als der manuelle Aufruf von dnssec-signzone.

verwandte Informationen