Microsoft DNS versus BIND, restera toujours pour nous, en tant que spécialistes, un faux débat.
Prérequis
Dans un environnement Microsoft Windows Active Directory, vous êtes parfois amenés à vous demander quelle solution est la plus simple ?
En matière de mécanisme de résolution où trouver l’efficacité et fiabilité entre Microsoft DNS et BIND.
Microsoft DNS versus BIND, comment s’y prendre ?
Constat
Dans nos différentes interventions, missions en tant qu’expert Active Directory, nous avons été à maintes reprises confrontés à ce type de choix. Quoi implémenter exactement, puisqu’il fallait créer ou rationaliser un existant ? Quelle option prendre avec des solutions technologiques déjà en place ; comme Efficient IP, Infoblox ou Microsoft DNS ?
Notre seule repère est : Microsoft Windows Active Directory a besoins d’un DNS dynamique avec enregistrement des services pour fonctionner.
Le choix
Choisir dans une cohabitation technique assez riche avec une absence de stratégie globale claire revient fondamentalement à architecturer.
Il y aura par conséquent des implications à tous les étages, surtout en partant vers un design spécifique du mécanisme DNS.
Tout est possible et faisable, il est avant tout question de stratégie. Il y a des questions à se poser en interne (qui fait quoi, qui est responsable de quoi …). La même approche est valable pour l’extérieur également (quid la supportabilité en cas d’incident ? …).
Dans un réseau hébergeant des progiciels Microsoft (Active Directory, Exchange et cætera), le premier réflexe reste la tendance à déployer du DNS Microsoft. C’est un socle fondamental de l’annuaire Active Directory et une solution bien intégrée par Microsoft aussi.
Un mécanisme de résolution cohérent et fonctionnel est un prérequis en effet. Gardez toutefois à l’esprit que la résolution DNS est à implémenter de bout en bout, donc bien au-delà des composants Microsoft. Il faut intégrer aussi que de nos jours les environnements informatiques s’hybrident davantage.
Enfin, vis-à-vis de Microsoft Windows Active Directory, le DNS peut tout à fait exotique, c’est à dire autre technologie que le DNS Microsoft.
Architecture
D’une certaine façon, toujours concevoir de la même façon n’a rien d’intéressant pour personne, puisqu’il n’y a finalement aucune analyse situationnelle. Aussi, nous pensons que ce « toujours déployer un DNS Microsoft » n’est pas constamment valable pour tout justifier. Autrement-dit, l’architecture varie forcément en fonction des situations. Il faut donc réfléchir faire simple et s’adapter au contexte.
Pour bien souligner nos propos, le choix instinctif de tout miser sur le DNS Microsoft peut parfois aller vers une stratégie globale discutable. Cela peut être lié à des divers aspects : historique, hétérogénéité, volumétrie, exposition à internet et sécurité. La plupart du temps, nous pouvons aussi avoir besoin de la function IPAM pour corréler certains entrées et données.
Il faut comprendre que c’est un sujet bien au-delà des simples aspects techniques disons. D’où la nécessité pour les décideurs at architectes d’avoir un minimum de background technique autour de ce sujet. La vision globale, mais ce n’est pas toujours le cas (sic), est vraiment nécessaire.
Par conséquent, Microsoft DNS versus BIND est faux débat technique, tout en restant un vrai sujet stratégique.
Gestion
La gestion et la configuration du DNS de Microsoft paraissent plus faciles et simples pour certains. Le produit est en effet très intuitif et c’est la raison du présent partage car ce côté intuitif ne conduit pas toujours vers la simple et la sécurisé. Certaines infrastructure DNS se sont éloignées largement de l’état de l’art à cause de cette intuition.
Il y a ceux qui revendiquent que le BIND est plus sécurisé. Ce dernier est moins intuitif évidement disons, sa sécurité relative dépend de son implémentation ainsi que de son interaction avec Microsoft Windows Active Directory.
Par ailleurs, les efforts liés à l’administration de BIND ne sont pas identiques à ceux du DNS Microsoft. C’est le cas au quotidien comme lors des cas exceptionnels, e.g. PRA (Plan de Reprise d’Activité).
Dans un cas comme dans l’autre, la rigueur, la maîtrise et la sécurité doivent être au rendez-vous !
Quand il est question de DNS, il faut maîtriser ces fondamentaux et les normes.
REX
De par notre retour d’expérience (REX), il paraît possible de bâtir un serveur DNS sécurisé avec Microsoft DNS, Efficient IP, Infoblox ou BIND Core.
Contrairement aux failles de sécurité, les problématiques DNS sont la plupart du temps liées à des erreurs humaines en matière d’impléméntation et configuration.
Ces erreurs humaines peuvent survenir quelle que soit la solution technologique mise en œuvre in fine. L’Homme est un facteur important de la réussite de son service DNS.
Bref, si vous avez les deux compétences (Linux et Windows) et avez le sens de l’organisation, vous serez sans doute de notre avis.
Ce dernier consiste à dire finalement que Microsoft DNS versus BIND, dans un environnement Microsoft Active Directory, reste un vrai « faux débat ».
Conclusion
Ce dont nous avons besoin est de résoudre des noms courts, qualifiés, services et ainsi de suite. Nous avons besoin d’enregistrer dynamiquement également des services. C’estg le cas lors des phases de création des objets Active Directory tels que DSA et NTDS Setting par exemple.
La marque du mécanisme de résolution de noms n’a aucune importance, tant que l’implémentation, la résolution, la gouvernance et le RACI demeurent cohérents.
En fin de compte, notre REX n’a jamais soulevé aucun blocable dans un environnement Microsoft Active Directory adossé à du BIND.
DNS versus BIND, aucune grande différence. Lorsque la résolution est mal implémentée, franchement les problèmes restent les mêmes 🙂