Ce mémo explique comment rediriger l’ensemble des sous-domaines d’un domaine local, par exemple *.domotic.local, vers un reverse proxy comme Traefik avec Pi-hole v6, et comment débloquer la résolution côté Ubuntu quand l’extension .local entre en conflit avec systemd-resolved.

1. Côté serveur : configuration du wildcard dans Pi-hole v6

Avec Pi-hole v6, l’interface graphique ne gère pas nativement les wildcards avec astérisque, par exemple *.domaine.local, pour les enregistrements de type A. Autre point à connaître: le dossier /etc/dnsmasq.d/ est ignoré par défaut dans cette version.

La méthode la plus propre, dans une logique Infrastructure as Code, consiste donc à injecter la règle directement via les variables d’environnement du docker-compose.yml.

Modification du docker-compose.yml

Ajoutez la variable FTLCONF_misc_dnsmasq_lines dans la section environment de votre service Pi-hole:

services:
  pihole:
    image: pihole/pihole:latest
    # ... le reste de votre configuration ...
    environment:
      TZ: "Europe/Paris"
      # Configuration du wildcard DNS pour dnsmasq (v6)
      FTLCONF_misc_dnsmasq_lines: "address=/domotic.local/192.168.87.29"
    volumes:
      - /volume2/docker/pihole/etc-pihole:/etc/pihole

Remplacez 192.168.87.29 par l’adresse IP de votre reverse proxy ou de votre hôte Docker.

Application des changements

Recréez ensuite le conteneur pour appliquer la nouvelle configuration:

docker compose up -d --force-recreate

À partir de là, toutes les requêtes vers *.domotic.local peuvent être résolues vers la même machine, ce qui est particulièrement pratique pour faire router ensuite les services par Traefik.

Vérification

Pour valider la configuration vous pouvez faire un nslookup en forcant l’ip de votre pihole en serveur dns (second paramètre)

$ nslookup dummy.domotic.local 192.168.87.29
Server:		192.168.87.29
Address:	192.168.87.29#53

Name:	dummy.domotic.local
Address: 192.168.87.29

Si vous avez ce genre de résultat tout est bon.

$ nslookup dummy.domotic.local 192.168.87.29
Server:		192.168.87.29
Address:	192.168.87.29#53

** server can't find dummy.domotic.local: NXDOMAIN

Si vous avez ce genre de résultat la configuration n’est pas bonne ou n’est pas prise en compte.

“Have You Tried Turning It Off And On Again?”

2. Côté client : pourquoi .local pose problème sous Ubuntu

Le problème ne vient pas de Pi-hole, mais du suffixe .local lui-même.

Selon la RFC 6762, l’extension .local est réservée au mDNS (Multicast DNS), le mécanisme utilisé notamment par Avahi sous Linux et Bonjour sous macOS. En pratique, cela signifie que lorsqu’un système Ubuntu utilisant systemd-resolved voit une requête se terminer par .local, il considère qu’elle doit être résolue en multicast sur le réseau local, et non envoyée à un serveur DNS classique en unicast comme votre routeur ou votre Pi-hole.

Autrement dit, au lieu d’interroger votre DNS local pour dummy.domotic.local, systemd-resolved tente d’abord une résolution mDNS sur le réseau. Comme aucune machine ne répond dans ce scénario, la requête échoue et le résolveur peut retourner un REFUSED.

Si vous utilisez malgré tout .local pour votre zone interne, il faut donc déclarer explicitement ce domaine dans le profil réseau concerné pour que NetworkManager et systemd-resolved sachent qu’ils doivent aussi l’utiliser comme domaine de recherche.

Manipulation permanente

  1. Identifiez le nom de la connexion active:
nmcli connection show --active

Notez la valeur de la colonne NAME, par exemple super-wifi-01.

  1. Associez ensuite le domaine de recherche à cette connexion:
sudo nmcli connection modify "super-wifi-01" ipv4.dns-search "domotic.local"
  1. Redémarrez enfin la connexion pour appliquer la modification:
sudo nmcli connection up "super-wifi-01"

Ce correctif est permanent pour le profil réseau modifié, mais uniquement pour lui. Si vous utilisez un autre profil Wi-Fi ou une autre interface réseau, il faudra répéter l’opération.

3. Validation du fonctionnement

Depuis le poste client Ubuntu, vous pouvez vérifier le fonctionnement avec nslookup.

Test local

La commande suivante doit continuer à utiliser le résolveur système local 127.0.0.53:

nslookup dummy.domotic.local

Retour attendu

Server:    127.0.0.53
Address:  127.0.0.53#53

Non-authoritative answer:
Name: dummy.domotic.local
Address: 192.168.87.29

Si vous obtenez bien cette réponse, votre wildcard DNS côté Pi-hole fonctionne et le poste Ubuntu accepte désormais de résoudre la zone domotic.local via le résolveur configuré.