Configurer DNS-over-HTTPS sur MikroTik RouterOS
Chiffrer les requêtes DNS entre le routeur et un résolveur DoH, vérifier le certificat TLS, sécuriser le cache pour le LAN et diagnostiquer les échecs.
Lorsque le MikroTik résout un nom avec le DNS classique, la requête quitte généralement le routeur en UDP ou TCP sur le port 53. Le nom demandé reste alors visible sur le trajet jusqu’au résolveur et une réponse non protégée peut être altérée par un équipement intermédiaire. DNS-over-HTTPS, ou DoH, transporte ces échanges dans une connexion HTTPS chiffrée.
RouterOS peut servir de cache DNS aux appareils du LAN tout en utilisant DoH vers l’extérieur. Les ordinateurs, téléphones et objets connectés continuent à interroger le routeur sur le port 53 ; le routeur regroupe ensuite ces demandes et contacte le résolveur distant sur le port 443 avec TLS. Cette distinction est essentielle pour comprendre ce que DoH protège réellement.
Ce qui est chiffré — et ce qui ne l’est pas
Dans la configuration de ce guide, le chemin comporte deux segments distincts.
| Segment | Transport | Protection |
|---|---|---|
| Client LAN → MikroTik | DNS classique, UDP/TCP 53 | Non chiffré par DoH, mais limité au réseau local |
| MikroTik → résolveur DoH | HTTPS, TCP 443 | Chiffré par TLS et authentifié par certificat |
| Client avec son propre DoH | HTTPS direct depuis l’appareil | Contourne le cache et les règles DNS du MikroTik |
Pourquoi ce guide cible RouterOS 7.21 ou ultérieur
RouterOS prend en charge DoH depuis longtemps, mais la gestion des autorités de certification a évolué. Depuis la branche 7.19, le système contient un magasin d’autorités racines intégré. La version 7.21 a remplacé l’ancien paramètre builtin-trust-anchors par builtin-trust-store et permet de sélectionner les services autorisés à utiliser ce magasin.
Sur une installation actuelle, le profil default autorise notamment le service DNS à employer les autorités intégrées. Il n’est donc plus nécessaire de télécharger manuellement un certificat racine depuis une URL qui pourrait devenir obsolète. Pour une ancienne version, utilisez les instructions correspondant exactement à cette version ou planifiez une mise à niveau après avoir lu les notes de publication et testé la configuration.
Avant de commencer
Travaillez depuis le LAN, activez le Safe Mode avec Ctrl+X et conservez un export ainsi qu’une sauvegarde binaire hors du routeur.
/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 printLa date et l’heure doivent être correctes. La validation TLS compare la période de validité du certificat avec l’horloge du routeur : une horloge très décalée peut faire échouer DoH alors que la connectivité Internet fonctionne.
Vérifiez aussi que le routeur peut joindre Internet en IPv4 et résoudre un nom avant la modification.
/ping 1.1.1.1 count=4
:put [:resolve example.com]1. Choisir un résolveur compatible
RouterOS n’accepte qu’un seul serveur global dans use-doh-server. Le service choisi doit donc être compatible avec l’implémentation HTTP de votre version de RouterOS et disposer d’un certificat reconnu par le magasin utilisé.
La documentation MikroTik actuelle cite Cloudflare, Google, NextDNS et OpenDNS parmi les services compatibles. Elle signale aussi que certains résolveurs qui imposent HTTP/2 peuvent ne pas fonctionner. Vérifiez cette liste avant chaque changement de fournisseur : un endpoint valide dans un navigateur n’est pas automatiquement compatible avec le client DoH de RouterOS.
Les commandes suivantes utilisent le résolveur standard Cloudflare :
https://cloudflare-dns.com/dns-queryCette URL suit le format RFC 8484. Elle ne correspond pas à une page Web destinée à être ouverte manuellement : RouterOS y envoie des messages DNS au format attendu par le service.
2. Préparer la résolution de démarrage
Avant d’établir HTTPS, le routeur doit connaître l’adresse de cloudflare-dns.com. C’est le problème du bootstrap : DoH ne peut pas résoudre le nom de son propre serveur tant que la connexion DoH n’existe pas.
Configurez temporairement ou durablement les adresses DNS classiques du même fournisseur. Lorsque use-doh-server est actif et joignable, RouterOS utilise DoH pour les requêtes normales ; les serveurs classiques restent nécessaires au démarrage de l’endpoint.
/ip dns
set servers=1.1.1.1,1.0.0.1Une autre méthode consiste à créer une entrée statique correcte pour le nom du serveur DoH, mais elle exige de suivre les changements d’adresses du fournisseur. Le bootstrap par les résolveurs classiques est généralement plus simple à maintenir.
3. Vérifier le magasin de certificats intégré
Affichez le réglage actuel. Sous RouterOS 7.21+, default comprend le service dns. Si vous avez volontairement créé une liste de services personnalisée, assurez-vous que dns y figure avant d’activer la vérification TLS.
/certificate settings print
/certificate builtin printPour revenir au profil intégré par défaut :
/certificate settings
set builtin-trust-store=defaultCette commande ne doit pas remplacer à l’aveugle une politique de certificats personnalisée. Notez la valeur précédente dans votre dossier d’exploitation. Dans une infrastructure maîtrisée, vous pouvez aussi conserver des autorités importées manuellement et limiter leur propriété trust-store au service dns.
4. Activer DoH avec validation TLS
Configurez maintenant l’endpoint HTTPS et activez impérativement verify-doh-cert=yes. Sans validation, la requête est chiffrée, mais le routeur ne vérifie pas correctement l’identité du serveur : un intermédiaire capable de présenter son propre certificat pourrait alors détourner la connexion.
/ip dns
set use-doh-server=https://cloudflare-dns.com/dns-query \
verify-doh-cert=yes doh-timeout=5s \
cache-size=8192KiBRouterOS ne bascule pas automatiquement vers un second endpoint DoH global. Si le serveur devient indisponible, la résolution peut échouer. La redondance doit donc être pensée au niveau de l’endpoint choisi, d’un résolveur local intermédiaire ou d’une architecture DNS dédiée.
5. Distribuer le MikroTik comme DNS du LAN
Si les clients doivent profiter du cache et de l’upstream DoH du routeur, annoncez l’adresse LAN du MikroTik par DHCP et autorisez les requêtes distantes. Adaptez le réseau et l’adresse à votre configuration.
/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.1Renouvelez ensuite le bail DHCP des appareils ou reconnectez-les au réseau. Une ancienne configuration DNS peut rester en mémoire jusqu’au renouvellement.
6. Fermer le cache DNS au WAN
allow-remote-requests=yes autorise le routeur à répondre sur UDP et TCP 53. Il faut limiter ce service aux réseaux de confiance. Le pare-feu RouterOS par défaut refuse déjà les nouvelles connexions venant du WAN, mais contrôlez l’ordre réel des règles avant de vous y fier.
/ip firewall filter
add chain=input action=accept in-interface-list=LAN \
protocol=udp dst-port=53 comment="DNS: autoriser le LAN"
add chain=input action=accept in-interface-list=LAN \
protocol=tcp dst-port=53 comment="DNS: autoriser le LAN TCP"
add chain=input action=drop in-interface-list=WAN \
protocol=udp dst-port=53 comment="DNS: refuser le WAN"
add chain=input action=drop in-interface-list=WAN \
protocol=tcp dst-port=53 comment="DNS: refuser le WAN TCP"Placez les deux autorisations avant le rejet final de input. Les deux rejets WAN sont explicites et facilitent l’audit ; si une règle générale équivalente existe déjà, ne créez pas de doublon inutile.
Un cache DNS ouvert sur Internet peut participer à des attaques par amplification. Testez depuis un réseau externe que l’adresse publique du routeur ne répond pas sur le port 53.
7. Tester la résolution et le certificat
Videz le cache, forcez une nouvelle résolution et consultez les journaux.
/ip dns cache flush
:put [:resolve example.com]
/ip dns cache print where name="example.com"
/ip dns print
/log print where topics~"dns"La commande :resolve doit retourner une adresse et le cache doit contenir le nom. Dans /ip dns print, vérifiez :
- l’URL exacte dans
use-doh-server; verify-doh-cert: yes;- une horloge correcte ;
- l’absence d’erreur TLS ou DNS répétée dans les journaux.
Pour confirmer le transport, observez brièvement l’interface WAN. Les nouvelles résolutions doivent produire une connexion HTTPS vers le résolveur, et non une série de requêtes DNS classiques vers des serveurs externes. Le bootstrap initial sur le port 53 reste toutefois normal.
/tool torch interface=ether1 port=53,443
/ip firewall connection print where dst-port=443Remplacez ether1 par l’interface WAN réelle. N’utilisez pas Torch comme preuve absolue du contenu : il confirme le transport et la destination, pas le message chiffré à l’intérieur de TLS.
Rediriger le DNS classique des clients : option à manier avec prudence
Certains appareils ignorent le DNS fourni par DHCP et contactent directement un résolveur public sur le port 53. Vous pouvez rediriger ce trafic vers le cache du routeur.
/ip firewall nat
add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 \
action=redirect to-ports=53 comment="DNS: rediriger UDP du LAN"
add chain=dstnat in-interface-list=LAN protocol=tcp dst-port=53 \
action=redirect to-ports=53 comment="DNS: rediriger TCP du LAN"Cette redirection ne capture ni DNS-over-TLS sur le port 853, ni DoH caché dans HTTPS 443. Bloquer tout le port 443 pour empêcher DoH casserait le Web. La maîtrise des DNS chiffrés directement par les clients exige une politique adaptée aux appareils : configuration MDM, contrôle des navigateurs, listes d’endpoints documentées ou résolveur d’entreprise.
DoH et les entrées DNS statiques de type FWD
Les anciennes instructions affirment parfois que les entrées FWD sont incompatibles avec DoH. La documentation RouterOS actuelle indique que les entrées FWD sont prises en charge et propose même des forwarders combinant serveurs DNS classiques et endpoints DoH.
La compatibilité exacte dépend néanmoins de la version. Si vous utilisez des règles FWD pour le split DNS, des domaines internes ou des listes dynamiques, testez-les avant la migration et après chaque mise à niveau. Une politique DNS ne doit jamais reposer sur une affirmation valable seulement pour une ancienne branche de RouterOS.
Dépannage
| Symptôme | Cause probable | Vérification |
|---|---|---|
| Erreur de certificat | Horloge incorrecte ou service DNS absent du magasin de confiance | Contrôler l’heure et /certificate settings print |
| Le nom de l’endpoint ne se résout pas | Bootstrap DNS absent | Configurer les serveurs classiques puis tester :resolve |
| DoH fonctionne puis s’arrête | Endpoint incompatible ou indisponible | Comparer avec la liste de compatibilité MikroTik et les journaux |
| Le routeur résout, pas les clients | allow-remote-requests, DHCP ou pare-feu incorrect | Tester TCP/UDP 53 depuis le LAN et renouveler le bail |
| Le WAN peut interroger le routeur | Règle input trop permissive | Vérifier l’ordre, les listes d’interfaces et tester depuis l’extérieur |
| Des requêtes partent encore ailleurs | DoH/DoT direct sur certains clients | Inspecter les politiques des appareils et les connexions 443/853 |
| La latence augmente | Résolveur éloigné, reconnexions TLS ou cache trop petit | Observer les temps, le cache et les connexions persistantes |
Revenir au DNS classique
Conservez les valeurs précédentes avant toute modification. Pour désactiver DoH tout en gardant les résolveurs de bootstrap comme DNS classiques :
/ip dns
set use-doh-server="" verify-doh-cert=no \
servers=1.1.1.1,1.0.0.1
/ip dns cache flushRetirez ensuite, si vous les aviez ajoutées uniquement pour ce projet, les règles de redirection et les règles DNS explicites en les recherchant par commentaire.
/ip firewall nat remove [find where comment~"DNS: rediriger"]
/ip firewall filter remove [find where comment~"DNS: autoriser"]
/ip firewall filter remove [find where comment~"DNS: refuser"]Conclusion
Configurer DoH sur MikroTik ne consiste pas seulement à coller une URL. Une installation fiable possède un bootstrap DNS, une horloge correcte, un endpoint compatible, une validation TLS active et un magasin d’autorités adapté à la version de RouterOS. Le cache doit être annoncé aux clients du LAN tout en restant inaccessible depuis le WAN.
Le résultat protège les requêtes entre le routeur et le résolveur DoH. Il ne chiffre pas automatiquement le segment LAN, n’empêche pas les applications d’utiliser leur propre DNS et ne masque pas les connexions IP. Considéré pour ce qu’il est — une protection du transport DNS amont — DoH constitue néanmoins une amélioration utile et mesurable.
Références techniques
À lire ensuite
À propos de l’auteur
Jeremy Kraft administre les infrastructures et les services auto-hébergés de l’IBCSC. Ces guides reprennent des configurations réellement déployées, revérifiées avant publication.
Discussion
Commentaires
Aucun commentaire pour le moment. Vous pouvez ouvrir la discussion avec une question ou un retour d’expérience.