TSIG-Schlüssel auf Ihrem primären DNS-Server: BIND, PowerDNS, NSD und Knot

Was Sie brauchen

Ein TSIG-Schlüssel signiert jeden Zonentransfer zwischen Ihrem primären Server und unseren sekundären Servern. Ihr primärer Server erkennt unsere Server dann am Schlüssel, nicht an ihren IP-Adressen.

Aus dem SecondDNS-Dashboard brauchen Sie drei Dinge:

1. Den Schlüssel. Erstellen Sie ihn unter Einstellungen › DNS. Der Dialog zeigt Schlüsselnamen, Algorithmus (hmac-sha256 oder hmac-sha512) und Secret. Das Secret wird nur einmal angezeigt: Kopieren Sie es, bevor Sie den Dialog schließen. Geht es verloren, erzeugen Sie den Schlüssel neu. 2. Unsere Nameserver-Adressen für NOTIFY. Sie stehen auf der Seite Zone hinzufügen und im Schlüsseldialog. Die Beispiele verwenden 192.0.2.10 und 2001:db8::10; ersetzen Sie sie durch Ihre Adressen. 3. Den Schlüsselnamen, zum Beispiel `user_ab12cd34-primary`. Er besteht aus Ihrem Kontonamen und der gewählten Bezeichnung.

Ersetzen Sie in jedem Beispiel `SECRET_FROM_DASHBOARD` durch Ihr Secret und `example.com` durch Ihre Zone. Verwenden Sie den Algorithmus, mit dem der Schlüssel erstellt wurde.

Neu bei Secondary DNS? Beginnen Sie mit So richten Sie einen sekundären DNS-Server ein und kommen Sie dann hierher zurück, um die Transfers zu signieren.

Wie TSIG funktioniert

TSIG (Transaction Signature, RFC 8945, Nachfolger von RFC 2845) fügt einer DNS-Nachricht einen Signatureintrag hinzu. Beide Seiten besitzen dasselbe Secret. Der Absender berechnet einen HMAC über die Nachricht, den Schlüsselnamen, den Algorithmus und den Signaturzeitpunkt; der Empfänger berechnet denselben HMAC mit seiner Kopie des Secrets und vergleicht.

Bei einem Zonentransfer geschieht das in beide Richtungen. Unser sekundärer Server signiert seine AXFR- oder IXFR-Anfrage; Ihr primärer Server prüft die Signatur und sendet, wenn der Schlüssel für die Zone erlaubt ist, die Zone mit seiner eigenen Signatur, die wiederum unsere Seite prüft. Ein Transfer, der eine der Prüfungen nicht besteht, wird verworfen.

In der Praxis zählen drei Eigenschaften:

– Das Secret wird nie übertragen. Nur die Signatur. Wer den Verkehr mitschneidet, sieht die Zonendaten, kann aber keine gültige Anfrage erzeugen. – Die Zeit ist Teil der Signatur. Jede Signatur enthält den Signaturzeitpunkt und eine erlaubte Uhrenabweichung (meist 300 Sekunden). Eine Anfrage außerhalb dieses Fensters wird mit BADTIME abgelehnt; deshalb brauchen beide Server eine korrekte Uhr. – TSIG authentifiziert, verschlüsselt aber nicht. Die Zone läuft weiterhin im Klartext über das Netz. Ist der Inhalt selbst schützenswert, ist TSIG nicht das richtige Mittel: Es legt nur fest, wer die Zone abrufen darf.

Wie AXFR und IXFR selbst funktionieren und wie NOTIFY sie auslöst, beschreibt AXFR-Zonentransfers verstehen.

TSIG oder IP-Freigabeliste

Ohne Schlüssel entscheidet Ihr primärer Server nach der Quelladresse: Unsere Nameserver-IPs stehen in `allow-transfer`, `allow-axfr-ips`, `provide-xfr` oder einer ACL, alle anderen Adressen werden abgelehnt. Das funktioniert und bleibt eine vernünftige Grundeinstellung, bindet Ihre Konfiguration aber an unsere Adressen.

Ein Schlüssel löst diese Bindung. Ihr primärer Server vertraut dem, der den Schlüssel vorlegt; eine Änderung unserer Adressen, eine zusätzliche Transferquelle auf unserer Seite oder der Umzug Ihrer Zone an einen anderen unserer Standorte erfordert also keine Änderung am primären Server. Außerdem trennt der Schlüssel Kunden, die sich einen primären Server teilen: Jedes SecondDNS-Konto hat eigene Schlüssel, und der Schlüssel eines Kontos kann keine Zonen eines anderen abrufen.

Sie können beides kombinieren. Behalten Sie unsere Adressen in der ACL und verlangen Sie den Schlüssel. In NSD und Knot tragen Sie unsere Adressen statt `0.0.0.0/0` zusammen mit dem Schlüssel ein. In BIND greift eine Adressliste, sobald irgendein Element passt; Adressen und Schlüssel nebeneinander in `allow-transfer` bedeuten also Adresse oder Schlüssel; um beides zu verlangen, nutzen Sie die verschachtelte Form:

allow-transfer { !{ !{ 192.0.2.10; 2001:db8::10; }; any; }; key "user_ab12cd34-primary"; };

Dann braucht ein Transfer die richtige Quelle und den richtigen Schlüssel.

Wahl des Algorithmus

SecondDNS-Schlüssel verwenden hmac-sha256 oder hmac-sha512. Beide werden von allen aktuellen Versionen von BIND, PowerDNS, NSD und Knot DNS unterstützt.

Wählen Sie hmac-sha256, sofern nichts dagegen spricht: Es ist die übliche Wahl in Dokumentation und Beispielen, und sein 32-Byte-Secret lässt sich ohne Zeilenumbruch einfügen. hmac-sha512 nutzt ein 64-Byte-Secret; wählen Sie es, wenn eine Richtlinie auf Ihrer Seite es verlangt. Ältere Algorithmen wie hmac-md5 und hmac-sha1 werden nicht angeboten.

Der Algorithmus wird beim Erstellen des Schlüssels festgelegt. Um ihn zu ändern, erstellen Sie einen neuen Schlüssel mit dem anderen Algorithmus, stellen Ihre Zonen darauf um und löschen den alten.

Die Länge des Secrets hängt vom Algorithmus ab: 32 Byte für hmac-sha256 und 64 Byte für hmac-sha512, in Base64 also 44 bzw. 88 Zeichen. Kopieren Sie das ganze Secret einschließlich der `=`-Zeichen am Ende: Ohne sie lehnt Ihr primärer Server den Schlüssel ab oder berechnet eine andere Signatur, und der Transfer endet mit BADSIG.

BIND

Fügen Sie den Schlüssel hinzu und erlauben Sie damit signierte Transfers. Es sind dieselben Blöcke, die das Dashboard anzeigt:

key "user_ab12cd34-primary" {
    algorithm hmac-sha256;
    secret "SECRET_FROM_DASHBOARD";
};

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.zone";
    allow-transfer { key "user_ab12cd34-primary"; };
    also-notify { 192.0.2.10; 2001:db8::10; };
};

Steht der Schlüssel in `allow-transfer`, brauchen Sie dort unsere IP-Adressen nicht. Behalten Sie `also-notify`: NOTIFY-Nachrichten werden nicht signiert, und wir nehmen sie von der Adresse Ihres primären Servers an.

Konfiguration prüfen und anwenden:

named-checkconf && rndc reconfig

Warum NOTIFY bestimmt, wie schnell Änderungen bei uns ankommen: Zonensynchronisation mit NOTIFY.

PowerDNS

Importieren Sie den Schlüssel, erlauben Sie ihm den Transfer der Zone und senden Sie NOTIFY an unsere Server:

# PowerDNS 4.x
pdnsutil import-tsig-key user_ab12cd34-primary hmac-sha256 SECRET_FROM_DASHBOARD
pdnsutil activate-tsig-key example.com user_ab12cd34-primary primary
pdnsutil set-meta example.com ALSO-NOTIFY 192.0.2.10 2001:db8::10

# PowerDNS 5.x
pdnsutil tsigkey import user_ab12cd34-primary hmac-sha256 SECRET_FROM_DASHBOARD
pdnsutil tsigkey activate example.com user_ab12cd34-primary primary
pdnsutil metadata set example.com ALSO-NOTIFY 192.0.2.10 2001:db8::10

Die Zone muss vom Typ `primary` sein (oder `native` mit eigener NOTIFY-Einrichtung). `activate-tsig-key … primary` (`tsigkey activate` in 5.x) trägt den Schlüssel in die Zonen-Metadaten `TSIG-ALLOW-AXFR` ein. PowerDNS gewährt einer mit einem Schlüssel aus `TSIG-ALLOW-AXFR` signierten Anfrage Zugriff auf die Zone, auch wenn die Adresse nicht in `allow-axfr-ips` steht.

NSD

Definieren Sie den Schlüssel in `nsd.conf` und erlauben Sie Transfers nur damit:

key:
    name: "user_ab12cd34-primary"
    algorithm: hmac-sha256
    secret: "SECRET_FROM_DASHBOARD"

zone:
    name: "example.com"
    zonefile: "example.com.zone"
    provide-xfr: 0.0.0.0/0 user_ab12cd34-primary
    provide-xfr: ::0/0 user_ab12cd34-primary
    notify: 192.0.2.10 NOKEY
    notify: 2001:db8::10 NOKEY

`provide-xfr` mit `0.0.0.0/0` und `::0/0` bedeutet: von jeder Adresse, aber nur mit diesem Schlüssel. Um Adresse und Schlüssel zu prüfen, tragen Sie stattdessen unsere Adressen ein. NOTIFY geht unsigniert an unsere Adressen (`NOKEY`).

Prüfen und anwenden:

nsd-checkconf /etc/nsd/nsd.conf && nsd-control reconfig

Knot DNS

Definieren Sie den Schlüssel, eine ACL, die damit ausgehende Transfers erlaubt, und unsere Server als NOTIFY-Ziel:

key:
  - id: user_ab12cd34-primary
    algorithm: hmac-sha256
    secret: SECRET_FROM_DASHBOARD

remote:
  - id: seconddns
    address: [192.0.2.10, 2001:db8::10]

acl:
  - id: seconddns_transfer
    key: user_ab12cd34-primary
    action: transfer

zone:
  - domain: example.com
    acl: seconddns_transfer
    notify: seconddns

Eine ACL nur mit `key` erlaubt mit diesem Schlüssel signierte Anfragen von jeder Adresse. Ergänzen Sie `address`, um beides zu verlangen.

Prüfen und anwenden:

knotc conf-check && knotc reload

Schlüssel vor dem Hinzufügen der Zone prüfen

Fordern Sie die Zone mit dem Schlüssel von Ihrem primären Server an, von einem beliebigen Rechner, der ihn über TCP-Port 53 erreicht:

dig @PRIMARY_IP example.com AXFR -y hmac-sha256:user_ab12cd34-primary:SECRET_FROM_DASHBOARD

Eine vollständige Zonenliste bedeutet, dass Schlüssel und Berechtigung stimmen. `BADKEY` bedeutet, dass Ihr primärer Server keinen Schlüssel mit diesem Namen kennt; `BADSIG`, dass Secret oder Algorithmus abweichen. `Transfer failed` mit REFUSED ohne TSIG-Fehler bedeutet, dass der Schlüssel gültig, aber für diese Zone nicht erlaubt ist.

Prüfen, ob der Transfer signiert war

Sobald die Zone mit dem Schlüssel hinzugefügt ist, protokolliert Ihr primärer Server jeden Transfer zusammen mit dem Schlüssel, der ihn signiert hat. In BIND sieht ein signierter Transfer so aus:

client @0x… 192.0.2.10#43001/key user_ab12cd34-primary (example.com): transfer of 'example.com/IN': AXFR started: TSIG user_ab12cd34-primary (serial 2026101101)

Der Schlüsselname nach `TSIG` ist der, den unser Server verwendet hat. Ein Transfer ohne Schlüsselnamen im Protokoll wurde per Adresse erlaubt, nicht per Schlüssel: Prüfen Sie, ob für die Zone im Dashboard wirklich der Schlüssel gewählt ist, und entfernen Sie unsere Adressen aus der ACL, wenn der Schlüssel Pflicht sein soll.

In PowerDNS, NSD und Knot DNS suchen Sie im Protokoll zum Zeitpunkt des Transfers nach dem Zonennamen. Auf unserer Seite zeigt das Dashboard nach dem ersten erfolgreichen Transfer Serial und Anzahl der Einträge der Zone.

Schlüssel im Dashboard auswählen

Wählen Sie beim Hinzufügen einer Domain den Schlüssel im Feld TSIG-Schlüssel. Ihr Standardschlüssel ist, falls festgelegt, vorausgewählt; mit Keiner wird die Zone ohne Signatur übertragen. Für eine bestehende Zone öffnen Sie deren Bearbeitungsdialog und ändern den Schlüssel dort.

Unsere Server signieren ihre Transferanfragen für die Zone dann mit dem Schlüssel. Ein Schlüssel gelangt nur auf unsere Server, solange eine Zone ihn verwendet.

Ein neu erzeugtes Secret ersetzt das alte sofort. Zonen mit diesem Schlüssel werden nicht synchronisiert, bis Ihr primärer Server das neue Secret hat; aktualisieren Sie ihn also direkt danach.

Schlüssel rotieren

Rotieren Sie einen Schlüssel, wenn das Secret offengelegt worden sein könnte, wenn jemand mit Zugang zum primären Server ausscheidet oder regelmäßig, wenn Ihre Richtlinie es verlangt.

So bleibt die Unterbrechung möglichst kurz:

1. Öffnen Sie die Konfiguration Ihres primären Servers, damit die Änderung bereitliegt. 2. Wählen Sie unter Einstellungen › DNS beim Schlüssel Neu erzeugen. Der Dialog nennt, wie viele Zonen ihn verwenden. Kopieren Sie das neue Secret aus dem folgenden Dialog. 3. Ersetzen Sie das Secret auf Ihrem primären Server und laden Sie ihn sofort neu. 4. Prüfen Sie mit dem `dig -y`-Befehl oben und dem neuen Secret.

Zwischen Schritt 2 und 3 signieren unsere Server bereits mit dem neuen Secret, sodass Transfers dieser Zonen fehlschlagen, bis Ihr primärer Server es hat. Die Zonen antworten weiter aus unserer letzten Kopie; nur Änderungen kommen bis dahin nicht an. Darf es gar keine Unterbrechung geben, erstellen Sie einen zweiten Schlüssel, tragen ihn neben dem ersten auf dem primären Server ein, stellen die Zonen im Dashboard darauf um und löschen den alten Schlüssel, sobald ihn nichts mehr verwendet.

Fehlerbehebung

BADKEY: Ihr primärer Server kennt keinen Schlüssel mit diesem Namen. Vergleichen Sie den Namen in Ihrer Konfiguration mit dem im Dashboard, einschließlich Kontopräfix.

BADSIG: Secret oder Algorithmus weichen ab. Kopieren Sie das Secret erneut oder erzeugen Sie den Schlüssel neu und aktualisieren Sie den primären Server.

BADTIME: TSIG-Signaturen enthalten einen Zeitstempel und werden abgelehnt, wenn die Uhren um mehr als einige Minuten abweichen. Sorgen Sie auf Ihrem primären Server für eine Zeitsynchronisation per NTP.

Änderungen kommen verspätet an: NOTIFY erreicht unsere Server nicht. Gleichen Sie `also-notify`, `ALSO-NOTIFY` oder `notify` mit unseren Adressen ab und prüfen Sie, ob UDP- und TCP-Port 53 zu ihnen offen sind.

Transfer abgelehnt, obwohl der Schlüssel stimmt: Der Schlüssel ist für diese Zone nicht erlaubt. Prüfen Sie `allow-transfer`, `TSIG-ALLOW-AXFR`, `provide-xfr` oder die ACL an der Zone selbst, nicht nur global.

Häufige Fragen

Kann ich einen Schlüssel für mehrere Zonen verwenden? Ja. Wählen Sie im Dashboard für jede Zone denselben Schlüssel und erlauben Sie ihn auf Ihrem primären Server für jede Zone. Wie viele Schlüssel ein Konto haben kann, legt Ihr Tarif fest.

Kann ich einen selbst erzeugten Schlüssel verwenden? Nein. SecondDNS erzeugt den Schlüssel und zeigt das Secret einmal an; das Secret erreicht uns also nie von außen und wird nur verschlüsselt gespeichert.

Ändert TSIG etwas für IPv6? Nein. Der Schlüssel hängt nicht von der Adressfamilie ab. Erlauben Sie den Schlüssel, und wenn Sie zusätzlich nach Adresse einschränken, tragen Sie neben den IPv4- auch unsere IPv6-Adressen ein.

Wird NOTIFY signiert? Nein. Ihr primärer Server sendet NOTIFY unsigniert, und wir nehmen es von der Adresse Ihres primären Servers an. Ein NOTIFY fordert uns nur auf, das Serial zu prüfen; der folgende Transfer ist signiert.

Werden inkrementelle Transfers (IXFR) auch signiert? Ja. Der Schlüssel gilt für AXFR- und IXFR-Anfragen der Zone.

Was passiert, wenn ich den Schlüssel auf meinem primären Server lösche, ihn im Dashboard aber gewählt lasse? Transfers schlagen dann mit BADKEY fehl. Die Zone antwortet aus unserer letzten Kopie, bis sie gemäß dem SOA-Expire-Wert abläuft (was die SOA-Timer bedeuten); korrigieren Sie also rechtzeitig die Konfiguration oder stellen Sie die Zone auf Keiner um.

Kann ich einen Schlüssel löschen, den noch Zonen verwenden? Nein. Das Dashboard zeigt, welche Zonen ihn verwenden; stellen Sie sie zuerst auf einen anderen Schlüssel oder auf Keiner um.

Muss ich außer 53 weitere Ports öffnen? Nein. Transfers nutzen TCP-Port 53, NOTIFY UDP-Port 53. TSIG fügt keine Ports hinzu: Die Signatur steckt in derselben DNS-Nachricht.

Kann ich sehen, welche Schlüssel meine Zonen verwenden? Ja. Unter Einstellungen › DNS zeigt jeder Schlüssel, wie viele Zonen ihn verwenden, und jede Zonenkarte zeigt neben der Adresse des primären Servers den Namen ihres Schlüssels.