Signing Proxy und Inline-Signing mit BIND

Am LRZ wurde DNSSEC mit dem Aufsetzen eines dedizierten "Signing Proxy"-Server eingeführt. Ein Signing-Proxy hat viele Vorteile:

  • Die Verwaltung der DNS-Inhalte (Webinterface, Hidden-Master) muss nicht geändert werden.
  • Die autoritativen Server müssen nicht bzw. wenig geändert werden (einzige Änderung: der Signing-Proxy wird Master für signierte Zonen).
  • Der Signing-Proxy muss weder für Zonenverwalter, noch öffentlich erreichbar sein, das verringert die Angrifsfläche auf die sicherheitskritischen Schlüssel.
  • Man kann für das Signieren die dafür am besten geeignete DNS-Server-Software einsetzen ohne andere Parameter berücksichtigen zu müssen.
  • Fehler bei DNS-Updates erreichen nicht die signierte Zone, da die Inhalte nicht auf dem Proxy, sondern auf dem Hidden-Master geändert werden.
  • Wird eine Zone auf dem Hidden-Master fehlerhaft oder fällt der Master aus, kann der Signing-Proxy zwar keine Updates mehr holen, er kann aber die bestehende Zone weiter signieren! Somit verfallen die Signaturen nicht, damit ist ein Ausfall wie bei bayern.de (Zone von Hand auf dem Master geändert, Zone kann durch Fehler nicht geladen werden, Signaturen laufen ab, Admin im Urlaub, Zone fällt komplett aus) ausgeschlossen..

Funktionsweise

Der Proxy-Server nimmt bei Veränderungen die neuen DNS-Einträge vom bestehenden Master entgegen, signiert die Zone, erhöht ggf. die Seriennummer und gibt die Änderungen inklusive Signaturen an die autoritativen DNS-Server weiter.

Für die Kommunikation zwischen Master und Signing-Proxy, sowie zwischen Signing-Proxy und den autoritativen Servern werden die üblichen Mechanismen verwendet werden (Serials, Notifications, Zonentransfer).

Bei den Seriennummern ist zu beachten, dass der Master bei der nächsten Änderung eine höhere Seriennummer wählt, als der Signing-Proxy zuletzt beim Signieren vergeben hat. Bei datumsbasierten Seriennummern (z.B. 2017032027) ist das üblicherweise gegeben.
Da der Signing-Proxy eine andere (d.h. signierte) Version der Zone vorhält, ist ein inkrementelles Update nicht so leicht möglich, vor dem diff müsste man die DNSSEC-Operationen herausrechnen. Da das (bisher?) nicht möglich ist, haben wir die Option auf dem Signing-Proxy deaktiviert:

ixfr-from-differences no;

Damit BIND die DNSSEC-Signierung selbstständig vornimmt, muss (wie schon in der Wiki-Seite zum dnssec-keymgr beschrieben) auto-dnssec maintain in der Konfiguration gesetzt sein. Damit lösen "key events", z.B. auslaufende Signaturen oder das Vorhandensein neuer Zonenschlüssel ein Signieren aus.


auto-dnssec maintain;
inline-signing yes;


inline-signing yes weißt BIND zusätzlich an, sobald ein Zonentransfer neue Zonendaten liefert, ein entsprechendes Signieren auf den geänderten Zonendaten vorzunehmen.


Dabei werden nur die neuen unsignierten Einträge signiert. Ältere Einträge, deren Signaturen irgendwann einmal auslaufen würden, werden im Rahmen des regulären Re-Signierens durch auto-dnssec maintain bei Bedarf neu signiert.


Entropy für DNSSEC

Sowohl die Erzeugung der DNSSEC-Schlüssel, als auch das Generieren von Signaturen beim regelmäßigen Signieren, benötigt Zufallsinformationen als "seed", um Schlüssel und Signaturen mit starker Kryptographie zu erzeugen, bei denen nicht die privaten Schlüssel errechnet werden können.

Auf virtuellen Maschinen ist die Entropie aufgrund der fehlenden physischen Hardware, deren Rauschen oder Zufälligkeit sonst als Quelle für Zufallszahlen genutzt werden, sehr gering. Hier sollte man "Entropie-Dämonen" über den Paketmanager installieren, z.B. haveged oder rng-tools.



Dies setzt natürlich das Vorhandensein von gültigen DNSSEC-Schlüssel für die fragliche Zone voraus. Dies kann mit dem dnssec-keymgr bewerkstelligt werden (siehe unsere Wiki-Seite zum dnssec-keymgr).


Auf dem Signing Proxy liegen die signierten Zonen-Dateien nur noch in binärer From vor. Ein direktes Editieren der Zonendateien ist nicht mehr möglich, die Updates müssen über das DNS-Protokoll an den Signing-Proxy weitergegeben werden, etwa über nsupdate.


Autoritative Server

Die drei autoritativen DNS-Server (dns1.lrz.de, dns2.lrz.bayern und dns3.lrz.eu) beziehen die signierten Zonen vom Signing-Proxy, die unsignierten direkt vom Master.
Die Zonenkonfiguration wird über einen Konfigurationsserver (CMDB zum Speichern, Webinterface zum editieren,  und Skripte und Makefiles zum Ausrollen der Konfiguration) umgesetzt.

Resolver

Die DNS-Resolver (resolver1.lrz.de und resolver2.lrz.de) sind aus historischen Gründen noch Slaves für alle Zonen und machen daher keine DNSSEC-Validierung für diese Zonen. Mittelfristig wird es konfigurierbar sein, ob eine Zone auf den Resolvern als Slave (ohne Validierung) umgesetzt wird, damit Änderungen sofort auf dem Resolver verfügbar sind, oder ob eine Zone validiert und damit nicht als Slave konfiguriert wird.

Monitoring

Die DNS-Server werden mit unterschiedlichen Tools überwacht (siehe Wiki-Seite zum DNSSEC/DANE-Monitoring).


Konfigurationsbeispiel

Mit nur einem primary öffentlichen autoritativen Nameserver, ergibt sich ein Setup aus drei Maschinen. Im Beispiel haben diese die folgenden IPs:

Hidden Master:  IP 138.246.99.206
Signing Proxy:   IP 138.246.99.197
Public Master    IP 138.246.99.220
(eigentlich Slave des Signing Proxy)


Da der Hidden master eventuell auch unsignierte Zonen zum Public Master durchreichen soll und wir auf dem jeweiligen Systemen zum Debuggen einen lokalen Zonentransfer mit „dig axfr <zone>“ ausführen können wollen, wird die IP des  localhost zum Transfer freigegeben und es wird auf dem Public Master auch die IP des Hidden Master mit allow-transfer freigegeben:


# 138.246.99.206 = localhost  138.246.99.197 = signing-proxy  138.246.99.220 = public master
  allow-transfer { 138.246.99.206; 138.246.99.197; 138.246.99.220; };


Da sowohl der Hidden Master zur Verwaltung, der Signing Proxy zum Signieren und der Public Master zum Veröffentlichen auf der selben Zone arbeiten, heißen die Zonendefinitionen überall gleich: ws03.ws.dnssec.bayern


Der Signing-Proxy braucht einen „file“-Eintrag, das kann aber ein nicht-existentes File sein. Dies wird durch den Einstellung „inline-signing yes“ bedingt, da aus dem Stammnamen das .signed-File mit den signierten Zoneninformationen generiert wird.


Die Konfigurationsdateien der einzelnen Maschinen lauten dann wie folgt. Die Logausgaben, die das jeweilige BIND9 beim Start ausgibt, und die Zonentransfers bzw. das Signieren zeigen, sind nachstehend angegeben: