4 oktober 2026 Netwerken en cyberbeveiliging 15 min. leestijd

DNS-over-HTTPS configureren op MikroTik RouterOS

DNS-verzoeken versleutelen tussen de router en een DoH-resolver, het TLS-certificaat verifiëren, de cache voor het LAN beveiligen en storingen diagnosticeren.

Auteur: Jeremy Kraft
Publicatie: 4 oktober 2026
Laatste controle: 4 oktober 2026
Omgeving: RouterOS 7.21+ · RouterOS DNS-cache · DHCP IPv4 · LAN/WAN-firewall

Wat er versleuteld is — en wat niet

In de configuratie van deze gids bestaat het pad uit twee afzonderlijke segmenten.

Segment	Transport	Bescherming
LAN-client → MikroTik	Klassieke DNS, UDP/TCP 53	Niet versleuteld door DoH, maar beperkt tot het lokale netwerk
MikroTik → DoH-resolver	HTTPS, TCP 443	Versleuteld met TLS en geauthenticeerd met certificaat
Client met eigen DoH	Directe HTTPS vanaf het apparaat	Omzeilt de cache en de DNS-regels van de MikroTik

Schema dat de lokale DNS toont tussen de clients en RouterOS, gevolgd door de geverifieerde HTTPS-tunnel naar de DoH-resolver — De clients bevragen de RouterOS-cache op het LAN ; de router versleutelt vervolgens de aanvraag naar de DoH-resolver en weigert DNS-aanvragen afkomstig van het WAN.

Waarom deze gids zich richt op RouterOS 7.21 of later

RouterOS ondersteunt DoH al geruime tijd, maar het beheer van de certificaatautoriteiten is geëvolueerd. Sinds tak 7.19 bevat het systeem een ingebouwde opslag voor root-authoriteiten. Versie 7.21 heeft de oude parameter builtin-trust-anchors vervangen door builtin-trust-store en maakt het mogelijk om de services te selecteren die gemachtigd zijn om deze opslag te gebruiken.

Op een huidige installatie staat het profiel default er onder andere toe dat de DNS-service de ingebouwde autoriteiten gebruikt. Het is dus niet langer nodig om handmatig een root-certificaat te downloaden vanaf een URL die verouderd zou kunnen raken. Voor een oudere versie gebruikt u de instructies die exact overeenkomen met die versie, of plant u een upgrade nadat u de release-opmerkingen hebt gelezen en de configuratie hebt getest.

Voordat u begint

Werk vanaf het LAN, activeer de Safe Mode met Ctrl+X en bewaar een export evenals een binaire back-up buiten de router.

/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

De datum en tijd moeten correct zijn. De TLS-validatie vergelijkt de geldigheidsperiode van het certificaat met de klok van de router: een sterk afwijkende klok kan ervoor zorgen dat DoH faalt, terwijl de internetverbinding werkt.

Controleer ook of de router via IPv4 verbinding kan maken met het internet en een naam kan oplossen vóór de wijziging.

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

1. Kies een compatibele resolver

RouterOS accepteert slechts één globale server in use-doh-server. De gekozen service moet daarom compatibel zijn met de HTTP-implementatie van uw RouterOS-versie en beschikken over een certificaat dat wordt erkend door de gebruikte opslag.

De huidige MikroTik-documentatie noemt Cloudflare, Google, NextDNS en OpenDNS onder de compatibele services. Ze geeft ook aan dat sommige resolvers die HTTP/2 verplichten mogelijk niet werken. Controleer deze lijst voor elke wijziging van provider: een geldig endpoint in een browser is niet automatisch compatibel met de DoH-client van RouterOS.

De volgende opdrachten gebruiken de standaard Cloudflare-resolver:

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

Deze URL volgt het RFC 8484-formaat. Het komt niet overeen met een webpagina die bedoeld is om handmatig te worden geopend: RouterOS stuurt er DNS-berichten heen in het formaat dat door de service wordt verwacht.

2. Bereid de opstartresolutie voor

Vóór het opzetten van HTTPS moet de router het adres van cloudflare-dns.com kennen. Dit is het bootstrap-probleem: DoH kan de naam van zijn eigen server niet oplossen zolang de DoH-verbinding niet bestaat.

Configureer tijdelijk of duurzaam de klassieke DNS-adressen van dezelfde provider. Wanneer use-doh-server actief en bereikbaar is, gebruikt RouterOS DoH voor de normale aanvragen; de klassieke servers blijven noodzakelijk voor het opstarten van het endpoint.

/ip dns
set servers=1.1.1.1,1.0.0.1

Een andere methode bestaat erin om een correcte statische invoer te maken voor de naam van de DoH-server, maar dit vereist dat u de adreswijzigingen van de provider opvolgt. De bootstrap via de klassieke resolvers is doorgaans eenvoudiger te onderhouden.

3. Controleer de ingebouwde certificaatopslag

Toon de huidige instelling. Onder RouterOS 7.21+ omvat default de service dns. Als u opzettelijk een aangepaste servicelijst hebt gemaakt, zorg er dan voor dat dns erin staat voordat u de TLS-controle activeert.

/certificate settings print
/certificate builtin print

Om terug te keren naar het standaard ingebouwde profiel:

/certificate settings
set builtin-trust-store=default

Deze opdracht mag niet blindelings een aangepast certificaatbeleid vervangen. Noteer de vorige waarde in uw exploitatiedossier. In een beheerste infrastructuur kunt u ook handmatig geïmporteerde autoriteiten behouden en hun eigenschap trust-store beperken tot de service dns.

4. Activeer DoH met TLS-validatie

Configureer nu het HTTPS-endpoint en activeer absoluut verify-doh-cert=yes. Zonder validatie is de aanvraag wel versleuteld, maar controleert de router de identiteit van de server niet correct: een tussenpersoon die in staat is om zijn eigen certificaat te presenteren, zou de verbinding dan kunnen kapen.

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

RouterOS schakelt niet automatisch over naar een tweede globaal DoH-endpoint. Als de server onbeschikbaar wordt, kan de resolutie mislukken. De redundantie moet dus worden bedacht op het niveau van het gekozen endpoint, van een tussenliggende lokale resolver of van een specifieke DNS-architectuur.

5. Verspreid de MikroTik als DNS voor het LAN

Als de clients moeten profiteren van de cache en de DoH-upstream van de router, kondig dan het LAN-adres van de MikroTik aan via DHCP en sta externe aanvragen toe. Pas het netwerk en het adres aan uw configuratie aan.

/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

Vernieuw vervolgens de DHCP-lease van de apparaten of verbind ze opnieuw met het netwerk. Een oude DNS-configuratie kan in het geheugen blijven tot de vernieuwing.

6. Sluit de DNS-cache af voor het WAN

allow-remote-requests=yes staat de router toe om te antwoorden op UDP en TCP 53. Deze service moet worden beperkt tot vertrouwde netwerken. De standaard RouterOS-firewall weigert al nieuwe verbindingen afkomstig van het WAN, maar controleer de werkelijke volgorde van de regels voordat u erop vertrouwt.

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

Plaats de twee autorisaties vóór de definitieve afwijzing van input. De twee WAN-afwijzingen zijn expliciet en vergemakkelijken de audit; als er al een equivalente algemene regel bestaat, maak dan geen onnodige duplicaten aan.

Een DNS-cache die openstaat voor het internet kan deelnemen aan amplificatieaanvallen. Test vanaf een extern netwerk of het publieke adres van de router niet antwoordt op poort 53.

7. Test de resolutie en het certificaat

Maak de cache leeg, forceer een nieuwe resolutie en raadpleeg de logboeken.

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

De opdracht :resolve moet een adres retourneren en de cache moet de naam bevatten. Controleer in /ip dns print:

de exacte URL in use-doh-server ;
verify-doh-cert: yes ;
een correcte klok ;
de afwezigheid van herhaalde TLS- of DNS-fouten in de logboeken.

Om het transport te bevestigen, observeer kort de WAN-interface. De nieuwe resoluties moeten een HTTPS-verbinding naar de resolver produceren, en geen reeks klassieke DNS-aanvragen naar externe servers. De initiële bootstrap op poort 53 blijft echter normaal.

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

Vervang ether1 door de werkelijke WAN-interface. Gebruik Torch niet als absoluut bewijs van de inhoud: het bevestigt het transport en de bestemming, niet het versleutelde bericht binnenin TLS.

Klassieke DNS van clients omleiden: een optie die met voorzichtigheid moet worden gehanteerd

Sommige apparaten negeren de DNS die door DHCP wordt geleverd en contacteren direct een publieke resolver op poort 53. U kunt dit verkeer omleiden naar de cache van de router.

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

Deze omleiding vangt noch DNS-over-TLS op poort 853, noch DoH verborgen in HTTPS 443. Het blokkeren van de volledige poort 443 om DoH te voorkomen, zou het web breken. Het beheersen van door clients direct versleutelde DNS vereist een beleid dat is aangepast aan de apparaten: MDM-configuratie, browsercontrole, gedocumenteerde endpointlijsten of een bedrijfsresolver.

DoH en statische DNS-items van het type FWD

Oude instructies beweren soms dat de items FWD incompatibel zijn met DoH. De huidige RouterOS-documentatie geeft aan dat FWD-items worden ondersteund en stelt zelfs forwarders voor die klassieke DNS-servers en DoH-endpoints combineren.

De exacte compatibiliteit hangt echter af van de versie. Als u FWD-regels gebruikt voor split DNS, interne domeinen of dynamische lijsten, test deze dan vóór de migratie en na elke upgrade. Een DNS-beleid mag nooit steunen op een bewering die alleen geldig is voor een oude tak van RouterOS.

Probleemoplossing

Symptoom	Waarschijnlijke oorzaak	Controle
Certificaatfout	Onjuiste klok of DNS-service afwezig in de vertrouwensopslag	Controleer de tijd en `/certificate settings print`
De naam van het endpoint wordt niet opgelost	DNS-bootstrap afwezig	Configureer de klassieke servers en test vervolgens `:resolve`
DoH werkt en stopt dan	Endpoint incompatibel of onbeschikbaar	Vergelijk met de MikroTik-compatibiliteitslijst en de logboeken
De router lost op, de clients niet	`allow-remote-requests`, onjuiste DHCP of firewall	Test TCP/UDP 53 vanaf het LAN en vernieuw de lease
Het WAN kan de router bevragen	Regel `input` te soepel	Controleer de volgorde, de interfacelijsten en test van buitenaf
Aanvragen vertrekken nog elders	Directe DoH/DoT op sommige clients	Inspecteer het beleid van de apparaten en de 443/853-verbindingen
De latentie neemt toe	Resolver ver weg, TLS-herverbindingen of cache te klein	Observeer de tijden, de cache en de persistente verbindingen

Terugkeren naar klassieke DNS

Bewaar de vorige waarden vóór enige wijziging. Om DoH uit te schakelen terwijl de bootstrap-resolvers als klassieke DNS behouden blijven:

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

Verwijder vervolgens, als u ze uitsluitend voor dit project had toegevoegd, de omleidingsregels en de expliciete DNS-regels door ze op te zoeken via de opmerking.

/ip firewall nat remove [find where comment~"DNS: omleiden"]
/ip firewall filter remove [find where comment~"DNS: toestaan"]
/ip firewall filter remove [find where comment~"DNS: weigeren"]

Conclusie

DoH configureren op MikroTik bestaat er niet alleen in om een URL te plakken. Een betrouwbare installatie beschikt over een DNS-bootstrap, een correcte klok, een compatibel endpoint, een actieve TLS-validatie en een autoriteitenopslag die is aangepast aan de RouterOS-versie. De cache moet worden aangekondigd aan de clients op het LAN, terwijl deze onbereikbaar blijft vanaf het WAN.

Het resultaat beschermt de aanvragen tussen de router en de DoH-resolver. Het versleutelt niet automatisch het LAN-segment, belet niet dat applicaties hun eigen DNS gebruiken en maskeert de IP-verbindingen niet. Beschouwd voor wat het is — een bescherming van het upstream-DNS-transport — vormt DoH niettemin een nuttige en meetbare verbetering.

Technische referenties

Over de auteur

Jeremy Kraft beheert de infrastructuur en de zelfgehoste diensten van het IBCSC. Deze gidsen beschrijven configuraties die echt zijn uitgerold en voor publicatie opnieuw zijn nagekeken.

Een vraag stellen Alle gidsen

Discussie

Reacties

Nog geen reacties. U kunt de discussie openen met een vraag of uw eigen ervaring.