Verschlüsseltes DNS selber machen - Teil 2

In meinem Artikel im Februar habe ich ein Setup vorgestellt, in welchem der DNS-Loadbalancer dnsdist und der Resolver unbound verwendet wurden, um einen DoH- und DoT-Server zu betreiben. Die Kombination der beiden Programme ist notwendig, da der in Debian 11 Bullseye enthaltenen Version von unbound Funktionen fehlen und dnsdist selbst kein Resolver ist. Mit dem Knot-Resolver gibt es im Repository von Debian ein Programm, welches beide Rollen übernehmen kann. Dieser Artikel zeigt, wie der Knot-Resolver als DoH- und DoT-Server eingerichtet wird.

Verschlüsseltes DNS selber machen

Seit einiger Zeit gibt es Bestrebungen, die Namensauflösung kryptographisch abzusichern. Dafür existiert auf der einen Seite mit DNSsec eine Technik, die eigene Zone zu signieren und so gefälschte DNS-Antworten zu verhindern. Auf der anderen Seite existieren mit DNS over TLS (DoT) und DNS over HTTPS (DoH) zwei Techniken, mit denen die Anfragen zwischen Client und Resolver verschlüsselt werden können. Standardmäßig funktioniert die Namensauflösung komplett unverschlüsselt und kann beispielsweise vom Internet Service Provider oder dem Betreiber eines öffentlichen WLANs mitgelesen oder sogar verändert werden. Mit der Verschlüsselung kann das Mitlesen von DNS-Abfragen auf der Netzwerkverbindung zwischen Client und Resolver verhindert werden, zwischen Resolver und Nameserver bleibt sie unverschlüsselt. Auf dieser Verbindung ist eine Zuordnung der Anfragen zu einem Client in der Regel nicht möglich, weiterhin können viele Anfragen direkt aus dem Resolver-Cache beantwortet werden. Meist sind es jedoch große Konzerne, welche die dafür nötigen Resolver zur Verfügung stellen. Damit wird das eigentlich dezentrale DNS letztendlich doch wieder an wenigen Stellen zentralisiert.

Das muss aber nicht sein, denn der Betrieb eines eigenen Resolvers für DoT und DoH ist möglich. Die folgende Anleitung zeigt, wie das geht.

Netzwerk-Probleme beim Upgrade auf Proxmox 7 vermeiden

Nach dem Upgrade von Proxmox 6 auf Proxmox 7 kommt es teilweise zu Problemen mit dem Netzwerk. Der Host ist in diesen Fällen nach dem abschließenden Reboot nicht mehr erreichbar. Eines dieser Probleme ist im Upgrade-Leitfaden von Proxmox beschrieben - einem anderen soll sich dieser Artikel widmen.

Let's-Encrypt-Zertifikate für interne Hosts

Viele Webseiten verwenden Zertifikate von Let’s Encrypt zur Absicherung des Datenverkehrs zwischen Benutzer und Server. Dies hat vor allem zwei Gründe: Zum einen sind diese Zertifikate kostenlos, zum anderen lässt sich die Erneuerung automatisieren, sodass abgelaufene Zertifikate der Vergangenheit angehören. Es gibt allerdings auch einen kleinen Nachteil: Die zur automatisierten Verifikation des Domainnamens in der Regel eingesetzte HTTP-01-Challenge erfordert, dass der Host auf Port 80 aus dem Internet erreichbar ist. Dies ist bei öffentlichen Webseiten kein Problem, für interne Dienste ist die Ausstellung von Zertifikaten auf diesem Weg aber nicht möglich. Neben der HTTP-01-Challenge gibt es noch weitere Challenge-Arten. In diesem Artikel soll gezeigt werden, wie die DNS-01-Challenge genutzt werden kann, um ein Let’s-Encrypt-Zertifikat für einen Intranet-Server auszustellen.

Eine Einführung in nftables

Neben dem älteren und den meisten Linux-Administratoren wohlbekannten iptables gibt es seit einiger Zeit den Paketfilter nftables, der iptables zukünftig komplett ablösen soll. Da nftables gegenüber iptables einige Vorteile bietet, lohnt sich der Umstieg bereits heute.