4. Oktober 2026 Netzwerke und Cybersicherheit 15 Min. Lesezeit

DNS-over-HTTPS auf MikroTik RouterOS konfigurieren

Verschlüsseln Sie die DNS-Abfragen zwischen Router und DoH-Resolver, überprüfen Sie das TLS-Zertifikat, schützen Sie den Cache für das LAN und diagnostizieren Sie Fehler.

Autor: Jeremy Kraft
Veröffentlichung: 4. Oktober 2026
Letzte Prüfung: 4. Oktober 2026
Umgebung: RouterOS 7.21+ · DNS-Cache von RouterOS · DHCP IPv4 · Firewall LAN/WAN

Schlagwörter

Wenn der MikroTik einen Namen mit klassischem DNS auflöst, verlässt die Anfrage den Router in der Regel über UDP oder TCP auf Port 53. Der angefragte Name bleibt auf dem Weg zum Resolver sichtbar und eine ungeschützte Antwort kann durch ein zwischengeschaltetes Gerät verändert werden. DNS-over-HTTPS, oder DoH, transportiert diese Austauschvorgänge in einer verschlüsselten HTTPS-Verbindung.

RouterOS kann als DNS-Cache für die Geräte im LAN dienen, während extern DoH verwendet wird. Computer, Telefone und vernetzte Objekte fragen den Router weiterhin auf Port 53 ab; der Router bündelt dann diese Anfragen und kontaktiert den Remote-Resolver auf Port 443 mit TLS. Diese Unterscheidung ist entscheidend, um zu verstehen, was DoH tatsächlich schützt.

Was verschlüsselt ist — und was nicht

In der Konfiguration dieses Leitfadens umfasst der Pfad zwei unterschiedliche Segmente.

Segment	Transport	Schutz
LAN-Client → MikroTik	Klassisches DNS, UDP/TCP 53	Nicht durch DoH verschlüsselt, aber auf das lokale Netzwerk beschränkt
MikroTik → DoH-Resolver	HTTPS, TCP 443	Durch TLS verschlüsselt und per Zertifikat authentifiziert
Client mit eigenem DoH	Direktes HTTPS vom Gerät	Umgeht den Cache und die DNS-Regeln des MikroTik

Diagramm, das das lokale DNS zwischen den Clients und RouterOS sowie den verifizierten HTTPS-Tunnel zum DoH-Resolver zeigt — Die Clients fragen den RouterOS-Cache im LAN ab ; der Router verschlüsselt anschließend die Anfrage zum DoH-Resolver und lehnt DNS-Anfragen aus dem WAN ab.

Warum dieser Leitfaden RouterOS 7.21 oder höher anstrebt

RouterOS unterstützt DoH schon lange, aber die Verwaltung der Zertifizierungsstellen hat sich weiterentwickelt. Seit dem Zweig 7.19 enthält das System einen integrierten Root-CA-Speicher. Die Version 7.21 hat den alten Parameter builtin-trust-anchors durch builtin-trust-store ersetzt und ermöglicht die Auswahl der Dienste, die diesen Speicher nutzen dürfen.

In einer aktuellen Installation erlaubt das Profil default unter anderem dem DNS-Dienst, die integrierten Zertifizierungsstellen zu verwenden. Es ist daher nicht mehr erforderlich, manuell ein Root-Zertifikat von einer URL herunterzuladen, die veraltet sein könnte. Für eine ältere Version verwenden Sie die Anweisungen, die genau dieser Version entsprechen, oder planen Sie ein Upgrade, nachdem Sie die Versionshinweise gelesen und die Konfiguration getestet haben.

Bevor Sie beginnen

Arbeiten Sie aus dem LAN, aktivieren Sie den Safe Mode mit Ctrl+X und bewahren Sie einen Export sowie ein binäres Backup außerhalb des Routers auf.

/export file=avant-doh
/system backup save name=avant-doh
/system resource print
/system clock print
/system ntp client print
/ip dns print
/certificate settings print

Datum und Uhrzeit müssen korrekt sein. Die TLS-Validierung vergleicht die Gültigkeitsdauer des Zertifikats mit der Uhr des Routers: Eine stark abweichende Uhr kann dazu führen, dass DoH fehlschlägt, obwohl die Internetverbindung funktioniert.

Überprüfen Sie auch, ob der Router vor der Änderung das Internet über IPv4 erreichen und einen Namen auflösen kann.

/ping 1.1.1.1 count=4
:put [:resolve example.com]

1. Einen kompatiblen Resolver wählen

RouterOS akzeptiert nur einen einzigen globalen Server in use-doh-server. Der gewählte Dienst muss daher mit der HTTP-Implementierung Ihrer RouterOS-Version kompatibel sein und über ein Zertifikat verfügen, das vom verwendeten Speicher anerkannt wird.

Die aktuelle MikroTik-Dokumentation nennt Cloudflare, Google, NextDNS und OpenDNS unter den kompatiblen Diensten. Sie weist auch darauf hin, dass bestimmte Resolver, die HTTP/2 erzwingen, möglicherweise nicht funktionieren. Überprüfen Sie diese Liste vor jedem Anbieterwechsel: Ein in einem Browser gültiger Endpunkt ist nicht automatisch mit dem DoH-Client von RouterOS kompatibel.

Die folgenden Befehle verwenden den Standard-Resolver von Cloudflare:

https://cloudflare-dns.com/dns-query

Diese URL folgt dem Format RFC 8484. Sie entspricht keiner Webseite, die manuell geöffnet werden soll: RouterOS sendet dorthin DNS-Nachrichten im vom Dienst erwarteten Format.

2. Die Startauflösung vorbereiten

Bevor HTTPS hergestellt wird, muss der Router die Adresse von cloudflare-dns.com kennen. Dies ist das Bootstrap-Problem: DoH kann den Namen seines eigenen Servers nicht auflösen, solange die DoH-Verbindung nicht besteht.

Konfigurieren Sie temporär oder dauerhaft die klassischen DNS-Adressen desselben Anbieters. Wenn use-doh-server aktiv und erreichbar ist, verwendet RouterOS DoH für normale Anfragen; die klassischen Server bleiben jedoch zum Starten des Endpunkts erforderlich.

/ip dns
set servers=1.1.1.1,1.0.0.1

Eine andere Methode besteht darin, einen korrekten statischen Eintrag für den Namen des DoH-Servers zu erstellen, dies erfordert jedoch die Nachverfolgung der Adressänderungen des Anbieters. Das Bootstrap durch klassische Resolver ist in der Regel einfacher zu verwalten.

3. Den integrierten Zertifikatsspeicher überprüfen

Zeigen Sie die aktuelle Einstellung an. Unter RouterOS 7.21+ umfasst default den Dienst dns. Wenn Sie absichtlich eine benutzerdefinierte Dienstliste erstellt haben, stellen Sie sicher, dass dns darin enthalten ist, bevor Sie die TLS-Verifizierung aktivieren.

/certificate settings print
/certificate builtin print

Um zum integrierten Standardprofil zurückzukehren:

/certificate settings
set builtin-trust-store=default

Dieser Befehl sollte nicht blindlings eine benutzerdefinierte Zertifikatsrichtlinie ersetzen. Notieren Sie den vorherigen Wert in Ihrem Betriebsordner. In einer kontrollierten Infrastruktur können Sie auch manuell importierte Zertifizierungsstellen beibehalten und deren Eigenschaft trust-store auf den Dienst dns beschränken.

4. DoH mit TLS-Validierung aktivieren

Konfigurieren Sie nun den HTTPS-Endpunkt und aktivieren Sie zwingend verify-doh-cert=yes. Ohne Validierung ist die Anfrage zwar verschlüsselt, aber der Router überprüft nicht ordnungsgemäß die Identität des Servers: Ein Zwischenmann, der in der Lage ist, sein eigenes Zertifikat zu präsentieren, könnte dann die Verbindung umleiten.

/ip dns
set use-doh-server=https://cloudflare-dns.com/dns-query \
    verify-doh-cert=yes doh-timeout=5s \
    cache-size=8192KiB

RouterOS wechselt nicht automatisch zu einem zweiten globalen DoH-Endpunkt. Wenn der Server nicht verfügbar wird, kann die Auflösung fehlschlagen. Die Redundanz muss daher auf Ebene des gewählten Endpunkts, eines zwischengeschalteten lokalen Resolvers oder einer dedizierten DNS-Architektur konzipiert werden.

5. Den MikroTik als DNS für das LAN bereitstellen

Wenn die Clients vom Cache und dem DoH-Upstream des Routers profitieren sollen, kündigen Sie die LAN-Adresse des MikroTik über DHCP an und erlauben Sie Remote-Anfragen. Passen Sie das Netzwerk und die Adresse an Ihre Konfiguration an.

/ip dns
set allow-remote-requests=yes

/ip dhcp-server network
set [find where address="192.168.88.0/24"] dns-server=192.168.88.1

Aktualisieren Sie anschließend den DHCP-Lease der Geräte oder verbinden Sie diese erneut mit dem Netzwerk. Eine alte DNS-Konfiguration kann bis zur Erneuerung im Speicher verbleiben.

6. Den DNS-Cache für das WAN sperren

allow-remote-requests=yes erlaubt es dem Router, auf UDP und TCP 53 zu antworten. Dieser Dienst muss auf vertrauenswürdige Netzwerke beschränkt werden. Die Standard-Firewall von RouterOS lehnt bereits neue Verbindungen aus dem WAN ab, aber überprüfen Sie die tatsächliche Reihenfolge der Regeln, bevor Sie sich darauf verlassen.

/ip firewall filter
add chain=input action=accept in-interface-list=LAN \
    protocol=udp dst-port=53 comment="DNS: erlauben LAN"
add chain=input action=accept in-interface-list=LAN \
    protocol=tcp dst-port=53 comment="DNS: erlauben LAN TCP"
add chain=input action=drop in-interface-list=WAN \
    protocol=udp dst-port=53 comment="DNS: ablehnen WAN"
add chain=input action=drop in-interface-list=WAN \
    protocol=tcp dst-port=53 comment="DNS: ablehnen WAN TCP"

Platzieren Sie die beiden Erlaubnisse vor der endgültigen Ablehnung von input. Die beiden WAN-Ablehnungen sind explizit und erleichtern das Auditing; wenn bereits eine äquivalente allgemeine Regel existiert, erstellen Sie kein unnötiges Duplikat.

Ein im Internet offener DNS-Cache kann an Amplifikationsangriffen teilnehmen. Testen Sie aus einem externen Netzwerk, ob die öffentliche Adresse des Routers nicht auf Port 53 antwortet.

7. Die Auflösung und das Zertifikat testen

Leeren Sie den Cache, erzwingen Sie eine neue Auflösung und konsultieren Sie die Protokolle.

/ip dns cache flush
:put [:resolve example.com]
/ip dns cache print where name="example.com"
/ip dns print
/log print where topics~"dns"

Der Befehl :resolve muss eine Adresse zurückgeben und der Cache muss den Namen enthalten. Überprüfen Sie in /ip dns print:

die genaue URL in use-doh-server ;
verify-doh-cert: yes ;
eine korrekte Uhr ;
das Fehlen wiederholter TLS- oder DNS-Fehler in den Protokollen.

Um den Transport zu bestätigen, beobachten Sie kurz die WAN-Schnittstelle. Neue Auflösungen müssen eine HTTPS-Verbindung zum Resolver erzeugen und keine Reihe von klassischen DNS-Anfragen an externe Server. Das anfängliche Bootstrap auf Port 53 bleibt jedoch normal.

/tool torch interface=ether1 port=53,443
/ip firewall connection print where dst-port=443

Ersetzen Sie ether1 durch die tatsächliche WAN-Schnittstelle. Verwenden Sie Torch nicht als absoluten Beweis für den Inhalt: Es bestätigt den Transport und das Ziel, aber nicht die verschlüsselte Nachricht im Inneren von TLS.

Klassisches DNS der Clients umleiten: Option mit Vorsicht zu handhaben

Einige Geräte ignorieren das von DHCP bereitgestellte DNS und kontaktieren direkt einen öffentlichen Resolver auf Port 53. Sie können diesen Datenverkehr zum Cache des Routers umleiten.

/ip firewall nat
add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 \
    action=redirect to-ports=53 comment="DNS: umleiten LAN UDP"
add chain=dstnat in-interface-list=LAN protocol=tcp dst-port=53 \
    action=redirect to-ports=53 comment="DNS: umleiten LAN TCP"

Diese Umleitung erfasst weder DNS-over-TLS auf Port 853, noch DoH, das in HTTPS 443 verborgen ist. Das Blockieren des gesamten Ports 443 zur Verhinderung von DoH würde das Web zerstören. Die Kontrolle der direkt durch die Clients verschlüsselten DNS erfordert eine an die Geräte angepasste Richtlinie: MDM-Konfiguration, Browser-Kontrolle, dokumentierte Endpunktlisten oder ein Unternehmens-Resolver.

DoH und statische DNS-Einträge vom Typ FWD

Ältere Anweisungen behaupten manchmal, dass die Einträge FWD mit DoH inkompatibel sind. Die aktuelle RouterOS-Dokumentation gibt an, dass FWD-Einträge unterstützt werden, und schlägt sogar Forwarder vor, die klassische DNS-Server und DoH-Endpunkte kombinieren.

Die genaue Kompatibilität hängt jedoch von der Version ab. Wenn Sie FWD-Regeln für Split-DNS, interne Domänen oder dynamische Listen verwenden, testen Sie diese vor der Migration und nach jedem Upgrade. Eine DNS-Richtlinie sollte sich niemals auf eine Aussage stützen, die nur für einen älteren RouterOS-Zweig gilt.

Fehlerbehebung

Symptom	Wahrscheinliche Ursache	Überprüfung
Zertifikatsfehler	Falsche Uhrzeit oder DNS-Dienst fehlt im Vertrauensspeicher	Uhrzeit und `/certificate settings print` überprüfen
Der Name des Endpunkts wird nicht aufgelöst	DNS-Bootstrap fehlt	Klassische Server konfigurieren, dann `:resolve` testen
DoH funktioniert und stoppt dann	Endpunkt inkompatibel oder nicht verfügbar	Mit der MikroTik-Kompatibilitätsliste und den Protokollen vergleichen
Der Router löst auf, die Clients nicht	`allow-remote-requests`, DHCP oder Firewall falsch	TCP/UDP 53 aus dem LAN testen und den Lease erneuern
Das WAN kann den Router abfragen	Regel `input` zu freizügig	Reihenfolge, Schnittstellenlisten überprüfen und von außen testen
Anfragen gehen noch woanders hin	Direktes DoH/DoT auf bestimmten Clients	Geräterichtlinien und 443/853-Verbindungen inspizieren
Die Latenz steigt	Entfernter Resolver, TLS-Wiederverbindungen oder zu kleiner Cache	Zeiten, Cache und persistente Verbindungen beobachten

Zum klassischen DNS zurückkehren

Bewahren Sie die vorherigen Werte vor jeder Änderung auf. Um DoH zu deaktivieren und gleichzeitig die Bootstrap-Resolver als klassisches DNS beizubehalten:

/ip dns
set use-doh-server="" verify-doh-cert=no \
    servers=1.1.1.1,1.0.0.1
/ip dns cache flush

Entfernen Sie anschließend, falls Sie sie nur für dieses Projekt hinzugefügt hatten, die Umleitungsregeln und expliziten DNS-Regeln, indem Sie nach Kommentar suchen.

/ip firewall nat remove [find where comment~"DNS: umleiten"]
/ip firewall filter remove [find where comment~"DNS: erlauben"]
/ip firewall filter remove [find where comment~"DNS: ablehnen"]

Fazit

Die Konfiguration von DoH auf MikroTik besteht nicht nur im Einfügen einer URL. Eine zuverlässige Installation verfügt über ein DNS-Bootstrap, eine korrekte Uhr, einen kompatiblen Endpunkt, eine aktive TLS-Validierung und einen Zertifizierungsstellenspeicher, der zur RouterOS-Version passt. Der Cache muss den Clients im LAN angekündigt werden, während er vom WAN aus unzugänglich bleibt.

Das Ergebnis schützt die Anfragen zwischen dem Router und dem DoH-Resolver. Es verschlüsselt nicht automatisch das LAN-Segment, hindert Anwendungen nicht daran, ihr eigenes DNS zu verwenden, und verbirgt nicht die IP-Verbindungen. Für das, was es ist — ein Schutz des Upstream-DNS-Transports — betrachtet, stellt DoH dennoch eine nützliche und messbare Verbesserung dar.

Technische Referenzen

Über den Autor

Jeremy Kraft betreut die Infrastruktur und die selbst gehosteten Dienste des IBCSC. Diese Anleitungen beschreiben Konfigurationen, die tatsächlich im Einsatz waren und vor der Veröffentlichung erneut geprüft wurden.

Eine Frage stellen Alle Anleitungen

Diskussion

Kommentare

Noch kein Kommentar. Eröffnen Sie die Diskussion gern mit einer Frage oder Ihrem eigenen Erfahrungsbericht.