La résolution DNS est une cinématique cruciale mais simple dans la vie de n’importe quelle infrastructure informatique.
Nous restons toujours aussi surpris après tant d’années en constatant que cette brique soit sujette à des erreurs, parfois paralysantes au plus haut point.
Improviser pour aller vite n’est jamais donc une solution viable dès lors que vous concevez une infrastructure.
Avant tout, l’architecture est de mise.
Finalement, sans prérequis, aucune solution technologique ne peut être pleinement efficace.
La bonne configuration DNS dans Active Directory
Pour la résolution DNS, ce que nous recommandons (particulièrement dans un environnement Active Directory) est la similitude entre les contrôleurs de domaine.
Dans l’hypothèse que n’importe quel contrôleur de domaine, autrement-dit n’importe quel serveur DNS, doit rester en mesure de délivrer un service DNS de la même manière et de façon continue le service DNS.
Au niveau global, la résolution DNS doit demeurer pleinement fonctionnelle et opérationnelle.
L’intégration de toutes les zones DNS dans Active Directory ainsi n’est pas uniquement dûe à la résilience Active Directory. L’autre raison est la stabilité des clients durant le processus de résolution DNS, cela fait sens, quelles que soient les opérations menées au niveau des contrôleurs Active Directory, par exemple : rétrofit, migration, maintenance, décommissionnement et campagne de patchs et cætera.
Dans ce cas précis, le DNS (dit Active Directory-Integrated DNS) est multi-maîtres by design, puisque chaque contrôleur de domaine dispose d’une copie en écriture des zones ainsi que de la configuration desdites zones.
La réplication de ces dernières étant liée à celle de l’Active Directory, le tout devient simple … easy 👌
Il est à noter que les serveurs DNS BIND sont hiérarchisés de manière un peu différente (serveur primaire et serveur secondaire) et ne prennent pas en charge non plus de façon automatique le fonctionnement en mode multi-maîtres. Ce n’est nullement un handicap, à condition de bien réfléchir de manière rationnelle et sécurisée sur son implémentation des résolveurs DNS.
Le résolution DNS
La vue de la résolution DNS à avoir dans l’esprit est celle-ci, l’ordre a son importance :
- Cache local : le client vérifie si l’adresse IP est déjà stockée dans son cache,
- Fichiers hosts (nous vous épargnons du cycle LMHOSTS, hosts et WINS 🤣) : le client exploite le fichier hosts. L’emplacement sous Windows est « C:\Windows\System32\drivers\etc\hosts »,
- WINS, mais c’est franchement obsolète même si certaines organisations misent toujours dessus : le client tente une réslution WINS,
- DNS : le client adresse ses requêtes aux serveurs DNS configurés au niveau de l’interface réseau. Les serveur DNS se chargent par la suite de lui fournir la meilleure réponse.
Quant aux réponses côté serveur DNS, les possibilités sont les suivantes :
- Retour direct du NS car il fait autorité sur la zone,
- Réponse via le redirecteur conditionnel DNS, car le DNS fait de la récursivité vers des NS (résoveurs) relatifs à) la zone à résoudre,
- Résolution DNS via les redirecteurs par défaut, car le DNS route la demande à des NS prédéfinis ou les NS de la racine, les TLD.
Fondamentalement, la récursivité DNS est ultra simple :
- Echange avec les serveurs DNS racine, domaine point (.)
- Retour de serveurs premier niveau, TLD, e.g. (io.)
- Réponse récursive des serveurs DNS déclarés, SLD, e.g. (neoconsiltin.io.)
Ci-après un mécanisme possible et représentatif de la résolution DNS d’un nom public :
Flux DNS
Il est nécessaire a minima d’ouvrir les flux 53/tcp-udp pour bien garantir la résolution DNS dans sont infrastructure.
L’ouverture doit être faite entre NS en interne et vers Internet également.
Pour la sécuriosation, vous avec besoin d’une approche supplémntaire et intrisèquement d’autre ports.
Synthèse
Ainsi lorsque les zone DNS sont intégrées à Active Directory, il convient d’harmoniser chaque résolveur, ce qui revient à harmoniser chaque contrôleur de domaine finalement.
Miser sur des redirecteurs configurés partiellement sut un serveur ADI vers un autre n’a aucun sens.
En définitive, les quelques approches bullshit à éviter sont :
- La différence de configuration au niveau des redirecteurs DNS (que ce soit « par défaut » ou « conditionnel »),
- Les zones stub, qui n’apportent que des inconvénients à mes yeux dans un environnement Active Directory conventionnel,
- La recopie des zones en dehors de leur NS … certains parviennent à décider de copier des zones DNS de premier niveau dans l’ADI,
- L’éclatement du RACI autour du DNS ADI en imaginant que l’équipe réseau peut être DnsAdmins sans corrompre la sécurité globale du T0,
- L’absence de récursivité ou la récursivité à moitié sécurisée,
- La redirection entre DNS ADI,
- L’utilisation abusive de l’utilitaire ADSIEdit pour contourner la limitation du produit. Le rappel fait par l’éditeur est : « A DNS server cannot forward queries for the domain names in the zones it hosts ». Article complet ici,
- Les nombreux suffixes de recherche DNS au niveau des clients DNS.
- L’utilisation de DNS publics au niveau des clients Active Directory 🤣
Une bonne résolution DNS implique toujours une bonne réflexion et la configuration ad hoc. Le mérite d’une solution technologique plutôt qu’une autre reste un faux débat, e.g. BIND / DDI versus ADI.
Partons du principe que la stratégie l’emporte toujours sur la technologie et que tendre vers l’état de l’art nécessite une discipline, dès la conception.
Conclusion
Au sens résolution DNS du terme, les serveurs ADI doivent être identiques entre eux, à l’adresse IP près disons. Les zones DNS seront ainsi chargées dans la partition application d’Active Directory et redondantes.
Ainsi, n’importe quel serveur DNS peut, ou plutôt doit, répondre aux requêtes DNS de façon constante.
Toute forme de dissemblance impulse fatalement une différence de comportement des clients, donc introduit des inflexions possibles.
La résolution DNS est cruciale pour le bon fonctionnement d’un réseau informatique. Elle constitue un des premiers prérequis !
L’absence de ce prérequis sur le terrain nous fait souvent constater que certaines infrastructures sont littéralement handicapées vis-à-vis de la scalabilité, la flexibilité, la fiabilité, la performance et la gestion de son réseau.
En définitive, une bonne résolution DNS est le pilier. Cela garantit que les services réseau fonctionnent correctement et que les utilisateurs peuvent accéder facilement aux ressources en ligne de façon fluide, efficace et sécurisée … surtout à l’ère de l’hybridation.
« Si tu veux réussir, tu te donnes les moyens. Si tu ne veux pas, tu te donnes des excuses ». La bonne résolution DNS est vitale ✌️