Life of an IT Pro Advisor @ Microsoft Canada

Le nom de domaine de DNS est fréquemment un bloc dans le processus de conception pour des personnes travaillant sur une migration d'AD. J'ai fait un certain nombre de « round tables » ou les discussions facilitées au sujet de ces matière et ce qui me surprise est que les gents le fait plus compliqués qu’ils on besoin. Étant un conseiller qui a fait un certain nombre de projet d'AD pour des clients avec les nombres d’usager de 200 à 27000 je l'ai vu tout. J'ai deux recommandations simples :

• Utilise le principle de KISS (Keep It Simple S{remplace le mot avec ton nom de choix})
• Fait le choix correctement un fois - et gardez-le.

La semaine passé, j'ai sorti pour le dîner (j'étais à Redmond pour une conférence technique) et une discussion a été soulevée au sujet du stratégies de DNS. Prenez un consultant en matière de stratégie d'entreprise, un consultant d’AD et un x-RedHat/Ingénieur d'oracle et quelques points intéressants obtiennent augmentés. Je ne vous dirai pas qui a soulevé quelle stratégie - je vous laisserai choisir:

Option 1 - Employez les mêmes noms internes et externes.
Si j’ai déjà achetez rickcompany.ca. et je l'emploi a l’extérieure, pourquoi pas employez a l'intérieure aussi? Humm... Maintenir 2 zone de DNS sur deux serveurs qui ne peut pas échangez l'information et devront être séparément contrôlés. Ceci pourrait sembler comme un bon principe de KISS et fortifier le « confort » des clients interne. En effet - il place beaucoup plus d’effort administratif sur les admins de DNS et ce n'est pas exactement « future proof » pour les besoins changeants d'affaires. Vous devrez manuellement ajouter les entrées externes dans votre zone interne. Vous devrez sélectivement ajouter les ressources internes à votre zone externe. Comment manipulerez-vous les ressources internes et externes quand c’est temps de changez a IPv6?

Oui – c’est vrai.  Je l'ai mise en application cette stratégie pour des clients - après qu'ils aient passé en revue tous les « pour et contre ». 

Option 2 - Employez un domaine secondaire délégué du domaine externe pour le domaine interne.
Si j’ai déjà achetez rickcompany.ca et je l'emploie a l’extérieur (je l'accueille sur un ensemble de serveurs moi-même ou mon service d’Internet), je crée un domaine secondaire a l’intérieur seulement qui pourrait s'appeler corp.rickcompany.ca ou ad.rickcompany.ca ou n’importequoi.rickcompany.ca. Puisque ce domaine secondaire est seulement maintenu a l’intérieur sur les serveurs internes de DNS, il ne peut pas être accidentellement placé sur les serveurs a extérieur. Les clients et les serveurs feraient partie du domaine secondaire interne de rickcompany.ca et fonction normalement dans un environnement d'AD.  Si vous aviez déjà une grande (ou petite) zone de DNS rickcompany.ca, les ressources pourraient être transférés à l’intérieur utilisant un zone secondaire. C'est le plus facile à contrôler, puisque vous commandez la zone et ne devez pas s'inquiéter de ce qui est à l'intérieur et dehors. Vous « futureproof » également votre réseau, puisque vous avez des noms uniques à l'intérieur et a l’extérieur. Si vos clients internes ont la mauvaise habitude d’identifier les ressources pas entièrement qualifier de DNS,  vous pouvez ajouter rickcompany.ca à votre liste de domaines de recherche pour assurer le nom résolution approprié.

Option 3 - Employez un domaine interne non standard. (Dustin Norman m'a rappelé celui-ci).
J'ai employé celui-ci à seulement une occasion. Je vous avertis que vous devriez employer celui-ci avec prudence - comme il limite sévèrement votre capacité de contrôler facilement les ressources internes que vous voulez faire accessible à l’extérieur. Si vous choisissez d'employer rickcompany.interne ou rickcompany.local pour votre Domaine interne de DNS, vous garantissez pratiquement que vos centres serveurs internes ne seront jamais résolubles du monde extérieur.  Il n'est pas dans généralement de meilleures habitudes recommandées d'employer ce type de domaine non standard de DNS sans regarder toutes les implications.

Je terminerai cette conversation en disant – comprenez toutes les implications de choisir le nom du domaine de DNS. Choisissez seulement après que vous avez évalué tout les options. Vous avez besoin d'un stratégie en bon état pour votre nom de domaine DNS et comment cela fonctionne afin d'assurer une base forte pour « Active Directory ».

Comment est-ce que je réponds quand quelqu'un me pose la question de DNS? "Ca dépend....."

Voici un lien à la discussion 2003 de guide déploiement des serveur DNS de Windows
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dnsbd_dns_tvnd.asp

• Use the KISS principle (Keep It Simple S{fill in appropriate word here}
• Do it right once and lock it in.

I was out last week for dinner (I was in Redmond for a technical conference) and a fairly heated discussion came up about DNS Naming Strategies for Active Directory. Take an x-enterprise strategy consultant, AD design consultant and an x-RedHat/Oracle engineer and throw them the DNS naming strategy topic and some interesting points get raised. I won't tell you who raised which strategy - I'll let you make your own.

Option 1 - Use the same Internal and External domain names.
If I already own rickcomapny.ca and I use it externally, why not use it internally as well? Humm... Maintain 2 DNS zone files on two servers that will from this day forward never exchange information and will need to be separately managed. This might seem like a good KISS principle and minimize internal client "comfort" of not having to change DNS namespace. In actual fact - it places much more administrative burden on the DNS admins and is not exactly "future proof" for changing business needs. You will have to manually add external entries into your internal zone. You will have to selectively add internal resources to your external zone. How will you handle internal and external records when you transition to IPv6?

I'm not knocking this method - I've implemented it for customers in the field - after they have reviewed all the Pros and Cons.

Option 2 - Use a delegated sub domain of the external domain for the internal domain.
Once again - if I own rickcompany.ca and I use it externally (either I host it on a set of servers or my ISP hosts it), I create a sub domain internally only (at this time) that could be called corp.rickcompany.ca or ad.rickcompany.ca or whatevermakessense.rickcompany.ca. Because this sub domain is only maintained internally on the internal DNS servers, it can't be accidentally placed on the outside servers. Clients and servers would be part of the internal sub domain of rickcompany.ca and function as normal in an AD environment. If you already had a large (or small) DNS zone of rickcompany.ca, the records could be transferred internally as secondary zones and maintained on which ever servers required the zones. This is by far the easiest one to manage, since you control the zone and don't have to worry about what is inside and outside. You are also futureproofing your design, since you have unique names inside and out. If your internal clients have the bad habit of not fully qualifying resources in the rickcompany.ca domain, you can add it to your list of search domains to ensure proper name resolution.

Option 3 - Use a non-standard internal domain. (Dustin Norman reminded me of this one).
I have used this one on only one occasion. I warn you that you should use this one with caution - as it severely limits your ability to easily manage externally accessible internal resources.  If you choose to use rickcompany.internal or rickcompany.local as your internal DNS domain name, you virtually guarantee that your internal hosts will never be resolvable from the outside world without jumping through hoops.  It is not generally a recommended best practice to use this type of non standard DNS domain naming convention without looking at all the implications.

I'll end off this conversation by saying - make sure to understand all the implications of DNS naming convention. Only after you have evaluated all the options should you make your choice. You need a rock solid understanding of DNS and how it works in order to ensure a strong foundation for AD and name resolution.

How do I answer when someone asks me the naming question? "It depends....."

Here's a link to the Windows Server 2003 Deployment guide discussion on DNS naming conventions.
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dnsbd_dns_tvnd.asp

Je veux essayer de faire mes post de blog en français et anglais quand c'est possible. Désoler, mon français écrit n'est pas très bon. J'emploie les services de traduction inclus avec Word 2003 - WordLingo et puis je les édite ainsi ils semblent plus « normal ». C'est ma première post en utilisant cette méthode – on vas voir si c’est acceptable.

Ce document a été poster au site web de Microsoft en mi-décembre. C'est leur document détaillé au sujet des changements du serveur 2003 avec Service Pack 1. Malheureusement - il est seulement disponible en anglais. On peut trouver ici :

http://www.microsoft.com/downloads/details.aspx?FamilyId=C3C26254-8CE3-46E2-B1B6-3659B92B2CDE&displaylang=en

Je l'ai déjà téléchargé et je suis en train de le lire au complet. Le service pack est assez impressionnant et comme XP SP2 - il aura un impact défini pour tous professionnels en TI. Je suggère fortement que vous téléchargiez une copie et commenciez votre lecture. Recherchez-vous les « bits » de RC1 pour commencer votre essai en laboratoire? L'essai avant de mettre en production est toujours une bonne chose! Je l'avais installer sur mon serveur « demo » pour tester la nouvelle fonctionnalité. Voici la page principale de téléchargement pour que la plupart des choses fassent avec W2K3 RC1.

http://www.microsoft.com/windowsserver2003/downloads/servicepacks/sp1/default.mspx

Enfin – je ne peu pas vous laisser partir sans vous donner le lien sur des ressources de TechNet pour le RC...

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/servicepack/default.mspx

Je vais poster encore plus sur Serveur 2003 RC1 et je vous donnerai quelques points culminants.