L'ingénierie doit-elle avoir sa propre zone DNS, son propre délégué ou son sous-domaine?

Nous avons le domaine principal de notre organisation (avec AD) example.com. Dans le passé, les administrateurs précédents ont créé plusieurs autres zones - telles que dmn.com, lab.example.com, dmn-geo.com etc. - ainsi que des sous-domaines et des délégués qui sont tous pour différents groupes d'ingénierie. Notre DNS en ce moment est un peu en désordre. Et bien sûr, cela pose des problèmes lorsque quelqu'un sur un poste de travail dans example.com doit se connecter à un système dans l'un de ces autres zones / sous-domaines, ou vice versa (en partie parce que le transfert et la délégation de zone ne sont pas correctement configurés pour la plupart d'entre eux) .

Notre DNS de production est intégré à Active Directory, mais les systèmes d'ingénierie doivent être isolés d'AD.

Nous discutons des moyens de réorganiser le DNS et de consolider toutes ces différentes entrées. Je vois trois avenues différentes que nous pouvons emprunter:

• Créez une nouvelle zone, c'est-à-dire 'dmn.eng'. Cela pourrait être géré par l'informatique, à l'aide de nos serveurs DNS ou par l'ingénierie à l'aide de leurs serveurs de noms.
• Créez un nouveau délégué eng.example.com, consolidez l'ingénierie DNS dans ce sous-domaine et laissez les ingénieurs gérer le serveur de noms pour le délégué.
• Créez un nouveau sous-domaine eng.example.com sans délégation et gérez nous-mêmes le DNS pour le sous-domaine.

Je préfère créer un sous-domaine délégué et laisser les ingénieurs avoir un contrôle total sur leur propre structure DNS au sein de ce sous-domaine. L'avantage est que si leur DNS ne fonctionne pas, ce n'est probablement pas de ma faute;). Cependant, il y a toujours une certaine ambiguïté sur la responsabilité quand quelque chose ne fonctionne pas et il faudra une coordination avec l'ingénierie pour installer, configurer et administrer.

Si nous ne déléguons pas le sous-domaine, cela signifie beaucoup plus de travail pour le service informatique de production qui gère le DNS non-production (ce que nous avons déjà fait beaucoup). L'avantage est que nous avons un contrôle total sur tous les DNS et lorsque quelque chose ne fonctionne pas, il n'y a aucun doute sur la responsabilité de la réparer. Nous pouvons également ajouter des délégués, tels que geo.eng.example.com, pour donner à l'ingénierie plus de flexibilité et de contrôle quand ils en ont besoin.

Je ne suis vraiment pas certain de la nécessité ou des avantages de créer une nouvelle zone, dmn.eng.

Quelles sont donc les meilleures pratiques et recommandations de l'industrie pour des situations comme celle-ci? Quelle solution serait la plus simple à mettre en œuvre et à fournir une résolution transparente des noms entre l'ingénierie et la production? Quels sont les avantages ou les pièges potentiels de chaque solution qui pourraient me manquer?

Pour ajouter un peu plus d'informations, nous sommes une assez grande entreprise manufacturière. Ces ingénieurs travaillent dans la R&D, le développement et l'AQ. Les laboratoires ont souvent leurs propres sous-réseaux ou réseaux entiers, DHCP, etc. En ce qui concerne l'organisation et la technologie, ils sont en quelque sorte leur propre petit monde.

Nous voulons maintenir un certain niveau d'isolement du réseau pour les laboratoires d'ingénierie et les réseaux afin de protéger notre environnement de production (référence à une question précédente concernant les ingénieurs qui ont ajouté des serveurs DHCP d'ingénierie en tant que serveurs DHCP AD faisant autorité - cela ne devrait pas être possible). Cependant, un utilisateur d'un poste de travail dans un laboratoire devra accéder à une ressource de notre réseau de production, ou un utilisateur d'un poste de travail de notre réseau de production devra se connecter à un système de laboratoire, et cela se produit avec une fréquence suffisante pour justifier un tri. -de DNS unifié.

Les délégués existants ont déjà des serveurs DNS gérés par l'ingénierie, mais il n'y a pas de communication entre les ingénieurs des différents laboratoires où ces serveurs sont installés, donc le problème le plus courant est l'échec de la résolution de noms entre les sous-domaines. Étant donné que les ingénieurs possèdent ces serveurs délégués, je ne peux pas corriger les entrées NS pour les faire parler entre eux - d'où l'avantage du DNS non délégué entièrement détenu par l'informatique. Mais la gestion du DNS pour la production et l' ingénierie est un casse-tête, d'autant plus que l'ingénierie peut apporter des changements DNS quotidiennement. Mais comme BigHomie l'a mentionné dans sa réponse, cela signifie probablement que l'ingénierie devra embaucher (ou désigner) un véritable administrateur DNS; et cette personne et moi devrons nous familiariser assez bien.

Je n'aime pas nécessairement l'idée de créer une nouvelle zone avec un nom de domaine ou un suffixe de niveau supérieur non plus, mais nous avons déjà 5 autres zones avec des noms arbitraires, donc la consolidation en une seule est toujours une amélioration. Je sais qu'il existe d'autres entreprises qui ont des zones distinctes de niveau supérieur pour différents groupes dans leur organisation, donc je suis curieux de savoir quand cela est approprié et quels sont les avantages / inconvénients de cette approche.

Pour info, je ne suis dans cette entreprise que depuis quelques mois et le précédent administrateur AD / DNS a quitté l'entreprise, je n'ai donc aucune référence à la raison pour laquelle une des structures DNS existantes existe.

Dans le monde d'aujourd'hui, je ne recommande pas de créer de nouvelles zones avec des domaines de premier niveau arbitraires , car ceux-ci pourraient en faire des "DNS officiels" à tout moment.

Personnellement, je préférerais le scénario de délégation de sous-domaine, car il semble correspondre à ce que vous essayez de faire. (Consolider mais contrôler l'ingénierie)

Peut-être que vous pouvez même trouver une interface Web pour MS DNS où l'ingénierie pourrait ajouter / supprimer des enregistrements, de sorte que le serveur lui-même soit toujours la propriété de l'informatique de production, et la seule chose "qu'ils" gèrent est les entrées DNS.

Tout d'abord, assurez-vous de posséder le domaine.tld que vous prévoyez d'utiliser (mit.edu). Même si cela ne se connecte jamais à Internet, ce n'est pas la question.

Il y a d'énormes avantages à avoir une hiérarchie de DNS qui correspond au moins quelque peu à l'organisation. Je n'ai vu cela que lorsqu'il y a quelqu'un / des personnes pour gérer ce département en termes de support informatique. Il s'agit d'avoir des zones distinctes aux fins de la DA. Les adresses Web, etc. sont un sujet distinct et cela ne s'applique pas à cela. Je n'ai pas ou ne connais pas de règles strictes pour la hiérarchie DNS, je pense que les besoins de votre organisation le dicteront. Certaines zones peuvent nécessiter un sous-domaine (eng.mit.edu) et d'autres pas (hr.mit.edu, par exemple). Bien sûr, il ne devrait y avoir qu'un seul domaine de premier niveau pour la cohérence.

Cela étant dit, qu'est-ce qui détermine si un département a besoin ou non d'un sous-domaine? S'il s'agit de postes de travail, ont-ils leur propre support informatique ou des personnes capables de gérer un tel système? Sinon, il est inutile d'utiliser une zone DNS pour spécifier qu'une machine se trouve dans un certain rayon, il existe de nombreuses autres méthodes qui feront très bien l'affaire. Ce ne sont que des questions que vous devrez vous poser.

Je réévaluerais chaque zone et déterminerais

1. Si c'est encore pertinent. Y a-t-il encore des serveurs ou des postes de travail pointant vers quoi que ce soit dans cette zone?

2. Qui gérera la nouvelle zone. Il va sans dire que la zone devra être migrée vers votre nouvelle hiérarchie, mais implémentez-vous simplement une adresse de transfert / informations de serveur de noms pour la zone, ou allez-vous gérer activement la zone?

Quels systèmes sont «isolés» de l'AD? Cela ne nécessitera-t-il pas l'authentification et / ou la gestion du réseau? Quelle est la raison de les séparer du point de vue DNS? Pour confirmer vos soupçons, tout est question de facilité de gestion. Si besoin d' ingénierie que beaucoup l' administration dns, ils devraient se procurer un administrateur DNS.

Pour ajouter des informations en fonction de votre mise à jour, je leur donnerais personnellement leur propre sous-domaine eng.spacelysprockets.comet sous-réseau. Il doit être protégé par un pare-feu du reste du réseau avec le trafic approprié autorisé. S'ils veulent partir et créer eng.eng.localou si eng.bikesvous ne pouvez pas les arrêter, vous ne devriez pas non plus être obligé de supporter cela *.

S'ils jouent bien, utilisez la sous-zone et décidez qu'ils veulent rompre lab.eng.spacelysprockets.comet une partie du sous-réseau, c'est sur eux. Cela devrait probablement être une courtoisie professionnelle de vous le faire savoir afin que vous puissiez également segmenter ce trafic, mais tout le monde ne pense pas comme ça.

Un vrai nom de domaine pour votre infrastructure vous donnerait sérieusement un avantage sur la gestion, vous devriez le considérer.

* Si vous et vous serez deux choses différentes, mais je m'égare.