Contexte / besoin
Les services auto-hébergés portent des noms de domaine publics, mais la plupart ne sont joignables que depuis le réseau privé. Il faut donc que le même nom résolve vers la bonne destination selon l’endroit d’où on interroge. C’est le principe du split-horizon : une vue interne, une vue externe, et aucune topologie privée publiée dans le DNS public.
S’ajoutent deux besoins qui relèvent autant du confort que de la sécurité : filtrer pubs et trackers au niveau du réseau pour tous les appareils, et ne pas envoyer les requêtes DNS en clair chez le fournisseur d’accès.
Contraintes
- Ne rien divulguer. Le DNS public ne doit exposer ni adresses privées, ni la liste des services internes.
- Transparent pour les clients. Les appareils du réseau privé utilisent le même nom que partout ailleurs, sans domaine interne exotique à mémoriser.
- Fiable. Si le DNS interne tombe, plus rien ne marche. Le service doit rester simple, sans état superflu.
Options envisagées
- Fichiers hosts ou configuration par appareil : ne passe pas à l’échelle, diverge vite, invivable sur mobile.
- Tout-en-un type Pi-hole : le filtrage est là, mais la gestion des zones internes reste limitée quand on veut faire autorité proprement sur plusieurs domaines.
- CoreDNS + AdGuard, chacun son rôle : un résolveur qui fait autorité sur les zones internes (CoreDNS, configuration déclarative par fichiers) et un étage de filtrage et de confidentialité (AdGuard, blocklists, DoH).
Décision & pourquoi
Séparer les responsabilités, avec CoreDNS en frontal : c’est lui que les clients du réseau privé interrogent. Les domaines auto-hébergés sont résolus sur place, par des zones internes en wildcard qui renvoient les adresses privées. Tout le reste est transmis à AdGuard, qui filtre pubs et trackers puis fait la résolution sortante chiffrée (DoH) vers l’amont. Chaque brique fait une chose et la fait bien. Les deux se configurent en fichiers versionnés.
Ce montage est peu courant à cette échelle. C’est précisément le genre de sujet réseau que je préfère comprendre en profondeur plutôt que subir.
Tradeoff assumé
Deux services au lieu d’un : deux configurations à maintenir, et une dépendance de plus sur le chemin critique, puisque le DNS interne devient vital pour le réseau privé. J’accepte ce coût parce que la séparation des rôles rend chaque partie facile à comprendre, et parce que le mode dégradé reste simple : sans DNS interne, les résolveurs publics prennent le relais pour tout ce qui est public.
Résultat
- Fiable : résolution interne stable et déterministe, configuration déclarative reproductible.
- Sécurisé : zéro information privée dans le DNS public, résolution sortante chiffrée, filtrage des domaines malveillants et des trackers pour tout le réseau.
Comment une requête est résolue (vue logique)
Vue simplifiée, sans adresses ni topologie réelle :
- Un appareil du réseau privé interroge le résolveur local (CoreDNS).
- Domaine auto-hébergé : la zone interne répond directement avec l’adresse privée du reverse proxy.
- Tout le reste part vers AdGuard. Domaine en blocklist : réponse bloquée.
- Sinon, résolution chiffrée (DoH) vers l’amont public.
Depuis Internet, aucune de ces vues internes n’existe. Seuls les enregistrements publics volontairement exposés répondent.
Le détail de l’override interne fait l’objet d’un write-up : Override DNS interne avec CoreDNS.