Meine Server verfügen seit ein paar Wochen über lokale, nur vom DNS Root abhängige DNS-Resolver, die auch DNSSEC beherrschen. Der Vorteil: DNS-Ergebnisse lassen sich lokal cachen und man muss weniger auf externe Infrastruktur vertrauen. Das verbessert Datenschutz und Sicherheit. Die DNS-Anfragen werden direkt an einen der DNS-Rootserver gestellt und von dort aus aufgelöst. Der kleine DNS-Resolver “Unbound” ist perfekt als lokaler Resolver geeignet und mit wenigen Kommandos einsatzbereit:
apt install unbound
Eigentlich könnte die Anleitung an dieser Stelle schon fast zu Ende sein, denn nach der Installation horcht der Resolver lokal bereits auf Port 53 und beherrscht auch schon DNSSEC. Trotzdem sind wir noch nicht fertig, denn der Resolver bekommt jetzt noch eine aktualisierte Version des DNSSEC Root Trust Anchors:
Kürzlich habe ich euch gefragt, welchen Hoster ihr mir empfehlen könnt. Meine Anforderungen waren:
- KVM-Virtualisierung
- 100% Ökostrom
- Kompetenter und schneller Support
- Gute Verfügbarkeit
- Mindestens 100 MBit/s Upstream
- Gutes Preis- / Leitungsverhältnis
- Flexible, individuelle Anpassung der Serverressourcen
- Eigene Images nutzbar
- Unternehmens- und Serverstandort Deutschland
In den Kommentaren zu dem Beitrag wurde mir unter anderem Servercow.de vorgeschlagen. Ich habe mich ein wenig auf der Webpräsenz des Unternehmens umgesehen und war ziemlich schnell interessiert. Alle meine Anforderungen waren erfüllt und ich habe mir zunächst einen Testserver bereitstellen lassen, den ich nun auch fest gebucht habe. Hier will ich euch von meinen ersten Eindrücken und Erfahrungen mit Servercow.de erzählen.
In mindestens zwei Anwendungsfällen ist die geringe Laufzeit von Let’s Encrypt Zertifikaten lästig: Bei der Nutzung von HPKP (Public Key Pinning) und DANE. Beide Verfahren sollen HTTPS-Verbindungen zusätzlich absichern, indem genau spezifiziert wird, welche TLS-Zertifikate für eine Domain gültig sein sollen. Da mindestens alle 90 Tage ein anderes Let’s Encrypt -Zertifikat eingerichtet werden muss, müssen in diesem Zyklus auch die HPKP- und DANE-Einstellungen mehr oder weniger aufwendig aktualisiert werden.
Der Aufwand lässt sich jedoch mit einem Trick reduzieren: Da beide Verfahren auf der Untersuchung des Public Keys im öffentlichen Zertifikat beruhen, kann man dafür sorgen, dass sich dieser bei der Umstellung auf ein neues Zertifikat nichts ändert. Man verwendet daher bei der Beantragung eines neuen LE-Zertifikats also keinen neuen Private Key, sondern einen alten. (Der Public Key basiert auf dem Private Key). Um einen alten Key nutzen zu können, muss der Referenzclient von Let’s Encrypt im Zusammenspiel mit einem eigenen, gleich bleibenden Private Key und einer eigenen Zertifikatsanfrage (CSR) verwendet werden.