Il galère avec sa zone DNS … « Un problème est survenu lors de la tentative d’ajout du redirecteur conditionnel. Un problème de configuration de zone s’est produit. ».
Tel était le message d’un DNSADI, c’est à dire DNS intégré à Active Directory.
Dans la confusion, comme à chaque incident, la réplication Active Directory est désignée comme étant l’origine et la responsable de cette anomalie.
Un souci DNS dans un environnement Active Directory se manifesterait autrement et bruyamment, c’est tout ce que je dis.
Bref, de ma fenêtre, c’est un peu comme la longueur du bateau et l’âge du capitaine, d’où ce nième focus sur DNSADI pour mieux maîtriser son implémentation.
La solution est que, dans un environnement Microsoft, un DNS faisant autorité sur une zone ne pourra pas être configuré pour la pose d’un redirecteur DNS conditionnel de la même zone.
Pour ma part, c’est parfaitement logique et cela s’appele une boucle. Voici un écrit officiel de l’éditeur (MSDN Microsoft) sur le sujet. L’extrait mentionne : je cite « A DNS server cannot forward queries for the domain names in the zones it hosts … »
Il est à noter que ce qui est décrit comme étant une limitation par Microsoft demeure parfaitement possible et faisable dans un mécanisme DNS BIND.
Tout est une question de choix, de pragmatisme et de responsabilité.
Zone DNS et raisonnement global
Conceptuellement, cette limitation microsoftienne est valable et est parfaitement compréhensible, pour les puristes en tout cas. Ce n’est pas incompatible, vous pouvez être Microsoft Palyer et fondamentalement puriste #gotobasics.
En effet, si un serveur DNS est maître de la zone nommée « thierry.adrian. », je conçois mal, pour des raisons de sécurité, qu’un tiers puisse être maître de la sous-zone baptisée « infra.thierry.adrian. ». Il en est de même pour l’hôte « www.thierry.adrian. » ou encore le service LDAP «_ldap._tcp.dc._msdcs.thierry.adrian. ».
Une zone ou un domaine se contrôle toujours dans son entièreté.
Cela se comprend et le raisonnement paraît généralisable à tous les étages.
Pour être à l’état de l’art, nous pouvons imaginer que les zones DNS du premier niveau sont normées.
Elles sont réparties entre différents registrars éclatés dans différentes zones géographiques du monde. Les combinaisons sont illimitées. La frontière entre la zone DNS privée et la zone DNS publique reste mince également.
Partant de cette hypothèse, il faut admettre qu’il n’est nullement nécessaire qu’un serveur DNS cumule toutes les zones de la planète avant que vous ne puissiez résoudre.
La résolution doit se faire de manière continue, cohérente et sécurisée selon les mécanismes DNS.
Il faut savoir raison garder
La même approche demeure valable pour les zones DNS purement privées, même si vos environnements sont isolés d’internet.
Votre instance DNS ne doit en aucun cas cumuler toutes les zones, e.g. zone DNS liée à l’IT, zone DNS liée à l’OT si je n’évoque que l’environnement de production disons. Je simplifie pour une meilleure compréhension du raisonnement.
Chaque zone a ses serveurs DNS et chaque serveur DNS a ses zones.
Telle est la première règle d’or, le principe de base. La suite du plan consiste à exploiter les redirecteurs DNS ad hoc, selon chaque besoin et situation.
Donc, concrètement si vous avez un espace de nommage lié à l’environnement de production d’un côté, et à l’environnement de développement de l’autre, il n’est pas nécessaire d’accumuler ces espaces de noms dans une unique instance DNS. Afin de vous permettre de résoudre correctement les noms et services dans les deux environnements, il vous suffit de poser des redirecteurs, redirecteurs conditionnels en l’occurence, dans un sens et dans l’autre. That’s all
Cela contribue à l’optimisation de votre mécanisme de résolution et vous offre la résolution attendue dans chaque espace de noms.
Zone DNS et la norme
Le DNS est une implémentation normalisée. Peu importe les solutions technologiques, la cohabitation reste simple et toujours possible moyennant des flux réseaux DNS à établir. Toute cohabitation nécessite à l’évidence des règles de gestion/sécurité. Les vôtres ne sont pas forcément celles du voisin, mais il faut trouer la cohérence globale. Vous trouverez ci-après quelques RFC en lien avec la zone DNS, pour instaurer l’équilibre.
Au-delà des RFC, il faut accepter que chaque solution ait aussi sa spécificité, son historique, son avantage et sa limite. Un BIND n’est pas un DNSADI, l’inverse est vrai aussi. En conséquence, une appliance DNS reste fatalement différente d’une autre et cætera. Rien ne sert de batailler là-dessus.
C’est une redite mais, la cohabitation DNS est avant tout une histoire de stratégie, d’architecture et de sécurité. Ce sont les seules vraies questions. La bonne réponse à ces questions dépend uniquement de la politique globale de votre organisation et de la réflexion de vos architectes.
La politique, indirectement une norme dans ce cas, fait toujours la différence. C’est pourquoi la technique restera toujours un faux débat autour des infrastructure DNS.
Dire que BIND est plus solide que DNSADI, ou le contraire selon les écoles, peut être un signe d’absence de discernement et de l’importance du rôle que ce même DNS joue pour vous.
Comment sécuriser votre zone DNS (DNSADI) ?
Dans un environnement Microsoft, voici quelques règles simples pouvant être mise en oeuvre.
Elles vous aideront à obtenir une infrastructure DNS plus performante et mieux sécurisée :
- Documenter,
- Intégrer vos zones à Active Directory,
- Limiter le nombre de zone de votre instance DNS,
- Maintenir à jour les zones,
- Sauvegarder régulièrement les zones,
- Refuser les mises à jour dynamiques non sécurisées, c’est fondamentalement lié au maintien du bon niveau de sécurité de vos zones,
- Eviter la copie illégitime de vos zones,
- Configurer la récursivité globale pour que votre serveur DNS route les demandes vers les DNS racines ou les DNS publiques. C’est nécessaire quand votre serveur DNS ne détient pas les réponses (résolution des noms sur internet typiquement). Il s’agit du redirecteur par défaut,
- Configurer la récursivité conditionnelle pour que votre serveur DNS adresse les demandes vers des DNS bien identifiés pour les zones bien identifiées également. Il s’agit du redirecteur conditionnel,
- Sécuriser les flux DNS à l’aide de TSIG et de DNSSEC afin de mettre en place un processus d’authentification et de vérification des transactions, un transit en clair est toujours source potentielle de problèmes futurs,
- Etablir un RACI suffisamment restrictif autour du DNS, car il est partie intégrante du T0, un « Service Core » et aussi un annuaire. Sa gestion doit être carrée et parfaite. Sa stabilité doit être continue, une indisponibilité du DNS a des impacts directs sur l’infrastructure et les applications, donc fatalement le business,
- Eviter dans la mesure du possible la délégation des zones,
- Traquer les éventuelles fuites DNS.
Synthèse
Il faut garder à l’esprit que même si votre infrastructure DNS est privée, elle ne doit pas être bancale et permissive. Rappelez-vous, il y a des règles à suivre et vous devez vous méfier des faux amis, des wizards.
En interne comme à l’externe, les types d’attaques redoutables sont le DNS spoofing, le DNS cache poisoning et le DNS flooding (DDoS).
Les attaques par déni de service, par altération des données ou par redirection sont simplement les plus mortelles. Elles peuvent engendrer rapidement des arrêts complets de la production.
Après avoir subi ces attaques, vous verrez généralement la vie autrement ; mais dites-vous bien aussi qu’il n’est jamais trop tard pour corriger le tir. L’amélioration et la sécurité restent des exercices permanents.
Le DNS est un service fondamental et essentiel. C’est le cas pour tout le monde, sans aucune exception.
Or, depuis mes débuts en informatique (juillet 1997), je ne compte plus le nombre de rencontres faites avec des DNS hasardeux, peu importe la technologie. C’est hallucinant !
Plus le temps passe, plus je suis convaincu que devenir un « Pure Player DNS » a du sens. D’autres l’ont compris bien avant moi, et c’est juste parfait côté public. Des efforts restent à mener côté privé.
Le pire cauchemar est de sécuriser un environnement Active Directory avec un DNS bancal, c’est juste une mission impossible.