Le problème
Les services portent des noms publics (service.domaine.fr) mais vivent sur
un réseau privé. Depuis l’intérieur, résoudre le nom public pose deux
problèmes. Le trafic sort pour revenir : détour inutile, dépendance à la
connectivité externe. Et pour les services privés, le nom ne doit tout
simplement pas résoudre publiquement ; il faut bien que quelqu’un réponde en
interne.
Les solutions naïves vieillissent mal : fichiers hosts par machine
(divergence garantie, impossible sur mobile), ou noms internes exotiques
(service.local) qui cassent TLS et obligent à tout configurer en double.
Le pattern
Une zone interne qui fait autorité sur les domaines auto-hébergés, servie par CoreDNS uniquement aux clients du réseau privé :
- Les requêtes des clients internes passent par le résolveur local (DNS split-horizon).
- Pour les zones auto-hébergées, CoreDNS répond avec les adresses internes, celles du reverse proxy privé. Configuration déclarative, versionnée.
- Tout le reste est transmis aux résolveurs publics : l’override reste chirurgical.
Le même nom fonctionne donc partout (réseau interne, Internet, tailnet), et TLS reste valide puisque le certificat wildcard couvre le nom public utilisé.
Les pièges
- Penser aux caches. Un client qui a résolu le nom avant d’entrer sur le réseau garde sa réponse jusqu’à expiration du TTL. Les incohérences transitoires sont normales ; les connaître évite de les chasser pour rien.
- Ne pas divulguer la zone interne. La vue interne n’est servie qu’aux clients internes, le DNS public reste minimal.
- Documenter l’invariant : chaque nouveau service auto-hébergé a son enregistrement interne. Sinon le service marche depuis Internet mais pas depuis le réseau, et le débogage devient contre-intuitif.
Pourquoi c’est intéressant
C’est un petit montage, mais il touche à un invariant système réel : la résolution de noms est contextuelle. Le comprendre, c’est comprendre une classe entière de bugs réseau réputés impossibles.