Deux sites, une zone DNS privée : qui possède les enregistrements ?

Vous ajoutez un hôte sur le site vert, il se résout pour les utilisateurs verts, et le bureau jaune reçoit toujours NXDOMAIN. Ce n’est ni une panne de VPN ni un résolveur cassé ; c’est un manque de propriété dans la zone privée. Deux listes d’enregistrements modifiées séparément ne deviennent pas une seule zone simplement parce que les sites peuvent communiquer. La solution est un plan de publication, pas une règle de pare-feu supplémentaire.

Le symptôme nomme le propriétaire manquant

Chaque site possède probablement une dérogation locale, une entrée Pi-hole ou une ligne dnsmasq ajoutée par quelqu’un quand un nom était nécessaire. L’enregistrement vert n’existe que sur le résolveur vert, donc un client du site jaune interroge son propre résolveur et obtient un « aucun nom de ce type » véridique. Une réponse périmée a un autre aspect : l’hôte a déménagé, un site a mis à jour sa copie et l’autre renvoie toujours l’ancienne adresse.

Aucun des deux schémas ne se corrige durablement avec un vidage de cache. Le cache d’un résolveur de transfert est une copie d’une réponse reçue autrefois, pas une autorité qui publie de nouveaux noms, donc un cache qui fonctionne aujourd’hui ne dit rien de l’hôte de demain. La documentation BIND décrit séparément les rôles primaire, secondaire, récursif et de transfert précisément pour cette raison.

La question de conception est donc étroite et a une réponse : qui peut créer un enregistrement, et comment cet enregistrement atteint-il chaque résolveur qui doit répondre à son sujet ?

Option A : une zone faisant autorité avec des secondaires

Lancez un primaire pour internal.example.com et laissez des secondaires pris en charge obtenir la zone sur chaque site. Le résolveur récursif de chaque site interroge son secondaire local, donc les réponses viennent d’une source faisant autorité plutôt que d’un cache, et une modification faite une fois est transférée au lieu d’être retapée.

Cet agencement exige des décisions explicites, faciles à reporter et coûteuses à omettre. Qui peut modifier la zone ? Quels serveurs sont autorisés à la transférer, et par quelles adresses ? Que doivent voir les clients pendant que le tunnel entre sites est hors service ? Un secondaire continue de répondre depuis sa dernière copie, ce qui est généralement le comportement souhaité, mais ce doit être un choix énoncé et non une surprise pendant une panne.

Limitez les transferts de zone aux secondaires connus par adresse et utilisez les signatures de transaction là où l’implémentation les prend en charge. Un transfert ouvert est une copie de votre espace de noms interne pour quiconque atteint le port.

Le coût est la coordination : un seul chemin de modification, une seule revue de changement et une compréhension partagée de qui est d’astreinte quand un enregistrement est faux.

Option B : un sous-domaine par site

Déléguez green.internal.example.com au site vert et yellow.internal.example.com au site jaune. Chaque site fait autorité pour ses propres noms, et la zone parente ne porte que les enregistrements de délégation. La concurrence autour d’un seul fichier disparaît, et une équipe locale peut ajouter un hôte sans attendre une modification centrale.

La délégation doit exister dans la zone parente, avec des enregistrements NS qui pointent vers les serveurs faisant autorité du site. Un transfert conditionnel pour le sous-domaine est une alternative valable quand une délégation complète n’est pas pratique, mais c’est un réglage de résolveur et non un fait publié, donc chaque résolveur a besoin de la même règle.

Le coût se déplace au lieu de disparaître : la zone parente a toujours besoin d’un propriétaire, et créer un nouveau site est désormais une modification à deux endroits au lieu d’un.

Faites suivre le choix à chaque résolveur

Fournissez aux clients le résolveur approuvé et le domaine de recherche via leur configuration prise en charge, et assurez-vous que le résolveur dispose d’une route VPN autorisée vers tout serveur DNS distant qu’il doit interroger. Les applications ont aussi besoin de routes vers les adresses privées que renvoient ces réponses, car un nom correct sans chemin reste une connexion rompue.

Si Pi-hole assure la résolution locale, notez quels enregistrements il possède et quelles requêtes il transfère. Deux listes Pi-hole modifiées séparément ne se répliquent toujours pas. Dans Pi-hole v6, les lignes dnsmasq personnalisées se définissent via des options côté hôte comme TOML, la CLI ou des variables d’environnement et ne sont pas exposées par l’API ; le chargement des fichiers de /etc/dnsmasq.d/ est une option distincte, désactivée par défaut.

Testez ensuite des deux côtés avec un nom qui devrait être visible partout :

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

La réponse SOA vous dit si le résolveur jaune se croit faisant autorité, interroge un secondaire ou se contente de transférer. Ce sont des conceptions différentes avec des modes de défaillance différents, et la réponse identifie généralement celle que vous avez réellement déployée.

Terminez par trois cas d’acceptation : un nom depuis chaque site, un enregistrement modifié en moins d’une heure et la liaison entre sites indisponible. Une conception qui ne réussit que le premier a un plan de publication sur le papier et une dérogation locale en production.