# dnsmasq pour un DNS local avec des domaines *.test illimités

> En résolvant tous les domaines *.test vers 127.0.0.1 d'un seul coup, dnsmasq évite d'éditer /etc/hosts à chaque nouveau projet WordPress local.

- Auteur : Clément Hadrot
- Publié le : 2020-01-09
- Mis à jour le : 2020-01-09
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/dnsmasq-dns-local-domaines-test-illimites/

## L’essentiel

- Résolution automatique de *.test
- Aucun fichier hosts à toucher
- Configuration en dix minutes

Un nouveau client, un nouveau projet, et le même rituel : ouvrir `/etc/hosts`, ajouter une ligne `127.0.0.1 client-x.test`, sauvegarder, parfois oublier de vider le cache DNS du système. Sur une année, ce rituel se répète des dizaines de fois pour une agence qui jongle avec plusieurs sites WordPress en local. Le fichier hosts finit par ressembler à un vieux carnet d'adresses, avec des lignes mortes que personne n'ose supprimer de peur de casser un projet oublié.

dnsmasq résout ce problème d'une autre manière : au lieu d'ajouter une entrée par domaine, il résout un domaine générique entier. Toutes les adresses en `*.test` pointent alors vers la machine locale, sans qu'aucune modification supplémentaire ne soit nécessaire pour le prochain projet. C'est un petit serveur DNS léger, initialement conçu pour de tout autres usages réseau, mais redoutablement pratique pour le développement.

## Pourquoi *.test et pas *.local ou *.dev

Le choix du domaine n'est pas anodin. `.local` est réservé par mDNS/Bonjour sur macOS et peut entrer en conflit avec la découverte réseau. `.dev` a longtemps été utilisé par la communauté avant que Google ne l'achète comme extension réelle et ne force le HTTPS via HSTS préchargé, ce qui casse les sites locaux en HTTP. `.test`, en revanche, est officiellement réservé par l'IANA (RFC 6761) pour un usage de test et ne sera jamais un vrai domaine public. C'est le choix le plus sûr pour un environnement WordPress local.

## Installer et configurer dnsmasq sur macOS et Linux

> L'essentiel à retenir : Résolution automatique de *.test ; Aucun fichier hosts à toucher ; Configuration en dix minutes

Sur macOS, l'installation passe par Homebrew :

```
brew install dnsmasq
echo 'address=/.test/127.0.0.1' >> $(brew --prefix)/etc/dnsmasq.conf
sudo brew services start dnsmasq
```

Il reste ensuite à indiquer au système que les domaines `.test` doivent être résolus par ce serveur local plutôt que par le DNS habituel. macOS permet de déclarer cela par extension via le mécanisme des « resolvers » :

```
sudo mkdir -p /etc/resolver
sudo bash -c 'echo "nameserver 127.0.0.1" > /etc/resolver/test'
```

Sur Linux, la configuration dépend du gestionnaire réseau. Avec NetworkManager, un fichier dans `/etc/NetworkManager/dnsmasq.d/` suffit :

```
address=/.test/127.0.0.1
```

Puis il faut activer dnsmasq comme résolveur dans `/etc/NetworkManager/NetworkManager.conf` en ajoutant `dns=dnsmasq` sous la section `[main]`, avant de redémarrer le service.

## Vérifier que la résolution fonctionne

Une fois la configuration en place, n'importe quel sous-domaine en `.test` doit répondre immédiatement, sans redémarrage de la machine :

```
dig client-x.test +short
# 127.0.0.1
dig un-nom-invente-a-la-volee.test +short
# 127.0.0.1
```

C'est là tout l'intérêt : même un domaine qui n'a jamais existé auparavant se résout sans configuration additionnelle, tant qu'il se termine par `.test`. Pour un serveur local comme celui utilisé par un environnement WordPress fait maison (nginx ou Apache avec des vhosts basés sur le nom de domaine), il suffit de créer le vhost au moment de démarrer le projet, sans jamais retoucher la couche DNS.

## Combiner avec un vhost générique

L'astuce se prolonge côté serveur web. Avec nginx, un bloc `server_name ~^(?<project>.+)\.test$;` associé à une racine dynamique comme `/var/www/$project` permet de servir n'importe quel dossier de projet sans ajouter de configuration à chaque fois. La combinaison dnsmasq côté DNS et vhost générique côté serveur web supprime presque totalement la friction de mise en route d'un nouveau site local.

> Sur nos machines d'agence, la règle est simple : un nom de dossier de projet devient automatiquement un domaine fonctionnel. Personne ne devrait avoir à réfléchir à la configuration réseau pour ouvrir un site en local.

## Les limites à connaître

- dnsmasq doit rester actif en permanence, ce qui ajoute un service de plus à surveiller sur la machine.
- Certains VPN d'entreprise réécrivent la configuration DNS système au moment de la connexion et peuvent temporairement neutraliser le résolveur local.
- Sous Windows, il n'existe pas d'équivalent direct aussi simple ; WSL2 avec un DNS interne ou un outil comme Acrylic DNS Proxy est nécessaire.
- Cette solution ne fournit aucun certificat HTTPS : elle traite uniquement la résolution de nom, pas le chiffrement du trafic local.

## En résumé

dnsmasq n'est pas un outil pensé pour WordPress, mais il règle un point de friction que beaucoup de développeurs subissent sans même y penser : la gestion manuelle du fichier hosts. Dix minutes de configuration suffisent pour ne plus jamais avoir à éditer ce fichier, quel que soit le nombre de projets locaux ouverts en parallèle. Pour une agence qui multiplie les sites clients, c'est un gain de temps cumulé qui vaut largement l'effort initial.