Configurer le DNS et vérifier le routeur, le client et le navigateur

Résultat

Vous pouvez répondre séparément à trois questions :

Quel serveur DNS amont le routeur utilise-t-il ?
Quel serveur DNS un client reçoit-il d’OpenWrt ?
Le navigateur contourne-t-il le résolveur du système avec DoH ?

Et vous pouvez revenir à un état où la résolution fonctionne après une modification ayant échoué.

Environnement concerné

OpenWrt 25.12.6, dnsmasq + odhcpd par défaut ; 25.12 utilise apk, 24.10 utilise opkg.
Les commandes d’inspection ne nécessitent aucun paquet supplémentaire. Si l’appareil exécute unbound ou https-dns-proxy, vérifiez d’abord lequel occupe le port 53.
Les libellés de menu et les clés de configuration sont proches sous 24.10, mais les commandes de paquets diffèrent ; ne copiez pas les commandes apk sous 24.10.

Chemin DNS et responsabilités

Emplacement	Responsable par défaut	À vérifier
Amont WAN	Client DHCP/PPPoE	`cat /tmp/resolv.conf.d/resolv.conf.auto`
Résolveur du routeur	`dnsmasq`	`nslookup openwrt.org 127.0.0.1`
Annonce côté LAN	option DHCP 6 de `dnsmasq` / RDNSS de `odhcpd`	le DNS affiché sur un client
Navigateur	résolveur du système ou DoH du navigateur	le réglage de DNS sécurisé du navigateur

Diagnostiquez la couche concernée avant de remplacer les serveurs DNS.

Avant de modifier quoi que ce soit

Shell du routeurSauvegarder la configuration DHCP/DNS

cp /etc/config/dhcp /etc/config/dhcp.bak.$(date +%F)
uci export dhcp > /tmp/dhcp.before
uci show dhcp | grep -E 'dns|resolv|server|option'

Conservez un accès filaire au LAN pour LuCI/SSH. Ne faites pas dépendre votre seule voie d’administration du DNS que vous modifiez.

AttenduUne sauvegarde existe et vous savez la restaurer.

Étapes minimales

Shell du routeurLire le DNS amont et les réglages de dnsmasq

cat /tmp/resolv.conf.d/resolv.conf.auto
uci show dhcp.@dnsmasq[0]
uci show network.wan | grep -E 'peerdns|dns'

/tmp/resolv.conf.d/resolv.conf.auto est écrit par le client WAN. Vérifiez la valeur réelle de dhcp.@dnsmasq[0].resolvfile. Si noresolv='1', dnsmasq ignore ce fichier et utilise sa liste server.

AttenduVous pouvez nommer les valeurs actuelles de resolvfile, server et noresolv.

LuCIDéfinir un DNS spécifique sur le WAN (premier changement le plus sûr)

Ouvrez Réseau → Interfaces → WAN → Paramètres avancés :

Décochez « Use DNS servers advertised by peer » (peerdns passe à 0).
Ajoutez les serveurs DNS de confiance sous « Utiliser des serveurs DNS spécifiques », par exemple 1.1.1.1 et 9.9.9.9.
Enregistrez et appliquez, puis reconnectez le WAN si nécessaire.

Cela interrompt brièvement le WAN mais laisse intacte la structure DHCP/DNS du LAN, ce qui facilite le retour en arrière.

AttenduAprès reconnexion du WAN, le résolveur amont est la valeur que vous avez définie.

Shell du routeurConfirmer que dnsmasq écoute et a chargé le nouvel amont

netstat -lnp | grep ':53'
/etc/init.d/dnsmasq restart
logread -e dnsmasq | tail -20

Si dnsmasq ne démarre pas, cessez de modifier les options DHCP. Utilisez le texte de l’erreur pour trouver une erreur de syntaxe ou un conflit de port.

AttenduLe port 53 est à l'écoute et le journal ne contient aucune erreur de configuration.

LuCIVérifier le DNS annoncé aux clients

Ouvrez Réseau → DHCP et DNS → Serveur DHCP → Paramètres avancés et examinez « DHCP Options ». Sans option 6, les clients utilisent normalement l’adresse LAN du routeur comme DNS. Avec l’option 6, ils reçoivent directement cette adresse.

Ne dirigez pas les clients vers une adresse qui n’écoute pas sur le port 53.

AttenduLe client reçoit l'adresse LAN d'OpenWrt, ou l'option 6 explicite que vous souhaitiez.

Shell du routeurÉquivalent en ligne de commande (facultatif)

uci set network.wan.peerdns='0'
uci -q delete network.wan.dns
uci add_list network.wan.dns='1.1.1.1'
uci commit network
ifup wan
cat /tmp/resolv.conf.d/resolv.conf.auto

Après la modification, utilisez logread -e dnsmasq pour confirmer le nouvel amont. Si les clients reçoivent encore l’ancien DNS, redémarrez dnsmasq ou examinez l’option DHCP 6.

Attenduresolv.auto affiche 1.1.1.1 et les requêtes aboutissent.

Vérifier depuis les clients

Shell du routeurVérifier A et AAAA sur le routeur

nslookup openwrt.org 127.0.0.1
nslookup -type=AAAA openwrt.org 127.0.0.1

AttenduLes deux requêtes renvoient une réponse sans expirer.

OrdinateurVérifier le DNS réellement reçu par le client

Linux :

resolvectl status
cat /etc/resolv.conf
nslookup openwrt.org

Windows :

ipconfig /all
nslookup openwrt.org

macOS :

scutil --dns
nslookup openwrt.org

AttenduLe DNS du client correspond à la configuration DHCP/statique et résout un nom.

OrdinateurVérifier si le navigateur contourne le routeur

Chrome/Edge : chrome://settings/security ou « Confidentialité et sécurité → Sécurité → Utiliser un DNS sécurisé ». Firefox : Paramètres → Vie privée et sécurité → DNS via HTTPS. Si DoH est activé, le résolveur du système peut ne pas être utilisé du tout ; cela ressemble à « le DNS du routeur n’a pas pris effet ».

AttenduDoH est désactivé pendant le test, ou vous savez exactement vers quoi il pointe.

OrdinateurVérifier la résolution IPv6 et RA/RDNSS

nslookup -type=AAAA openwrt.org
ip -6 route

Ne déduisez pas qu’un DNS IPv6 fonctionne à partir d’un résultat IPv4 lorsque l’amont n’a pas de préfixe IPv6.

AttenduAAAA se résout lorsqu'un amont IPv6 existe ; sinon, consignez la condition manquante.

Branches d’échec et récupération

Les pages ne se chargent pas, mais le ping par IP fonctionne

Soupçonnez d’abord le DNS :

Vérifiez le résolveur du client : resolvectl status, ipconfig /all ou scutil --dns.
Vérifiez le port 53 et les journaux de dnsmasq sur le routeur : netstat -lnp | grep ':53', logread -e dnsmasq.
Vérifiez DoH dans le navigateur et désactivez-le temporairement.
Vérifiez que l’option DHCP 6 ne contient pas une mauvaise adresse.

LuCI/SSH est inaccessible

Cessez de modifier le DNS. Connectez un client filaire au LAN, donnez-lui une adresse statique dans le même sous-réseau et confirmez que la passerelle est l’adresse LAN d’OpenWrt. Restaurez depuis la console ou SSH :

cp /etc/config/dhcp.bak.YYYY-MM-DD /etc/config/dhcp
uci commit dhcp
/etc/init.d/dnsmasq restart

Si vous avez modifié le DNS du WAN, rétablissez le DNS amont automatique :

uci set network.wan.peerdns='1'
uci -q delete network.wan.dns
uci commit network
ifup wan

Le DNS du WAN a changé mais les clients utilisent encore l’ancien résolveur

Vérifiez d’abord si resolv.auto a changé, puis si dnsmasq a chargé le nouvel amont :

cat /tmp/resolv.conf.d/resolv.conf.auto
logread -e dnsmasq | tail -20
/etc/init.d/dnsmasq restart

Si resolv.auto n’a pas changé, examinez network.wan.dns et peerdns. Si les clients reçoivent encore l’ancien DNS, examinez l’option DHCP 6 et DoH dans le navigateur.

dnsmasq ne démarre pas

Lisez l’erreur au lieu de redémarrer en boucle :

logread -e dnsmasq | tail -50
dnsmasq --test

Les causes courantes sont un autre résolveur qui occupe le port 53, une erreur de syntaxe ou un amont injoignable. Restaurez d’abord la sauvegarde, puis réintroduisez vos réglages personnalisés un par un.

Essai en laboratoire E2 (2026-10-20)

Environnement : PVE 9.2.2 à une seule carte réseau ; VM OpenWrt 25.12.6 200 ; WAN 192.168.50.77/24, LAN 192.168.1.1/24.
Référence : resolv.auto valait nameserver 192.168.50.1 ; nslookup openwrt.org 127.0.0.1 a renvoyé A/AAAA.
Personnalisé : peerdns=0 + network.wan.dns=1.1.1.1 ; resolv.auto est devenu nameserver 1.1.1.1 ; les requêtes fonctionnaient toujours.
Échec : amont de dnsmasq défini sur 192.0.2.1, injoignable ; une requête .example.com aléatoire a renvoyé connection timed out; no servers could be reached ; la suppression de noresolv/server et le rétablissement de peerdns=1 ont restauré la résolution.
Client : le DHCP netns a reçu 192.168.1.116/24, DNS 192.168.1.1 ; dig @192.168.1.1 openwrt.org a fonctionné ; ping 192.168.50.1 a fonctionné.
Non testé : DoH dans le navigateur, amont IPv6/RA/RDNSS, clients LAN physiques, stabilité sur la durée.

Sources et relecture

Cette page repose sur une reproduction en laboratoire E2 ; DoH dans le navigateur et l’amont IPv6 restent non testés et ne doivent pas être décrits comme vérifiés.
Preuves : docs/dns-e2-run.md et tests/recipes/dns-25.12-x86.md.
Mettez à jour testedVersions et lastVerifiedAt lorsque le menu ou la version change ; ne placez pas de commandes opkg de 24.10 dans une procédure 25.12.

Sources

Router.Homes

Notes indépendantes sur OpenWrt. Chaque page précise le firmware, l’appareil, le gestionnaire de paquets et le retour arrière.

Icônes : Solar by 480 Design, CC BY 4.0