Comment intégrer le DNS d’UNIX dans Windows 2000

Les clients NT se sont pas tenus de spécifier un contrôleur de domaines lorsqu’ils
se connectentà  un domaine NT. WINS se
charge de fournir au client un contrôleur de domaine sur lequel se connecter.
Ce paramétrage permet aux clients d’accéder à  un domaine aussi longtemps qu’il
reste un contrôleur disponible, même si tous les autres sont plantés. Windows
2000 a hérité de cette fonctionnalité et permet aux clients de se connecter à 
un domaine AD sans spécifier un contrôleur de domaine.

Cependant, pour assurer cette fonctionnalité, Windows 2000 utilise DNS et non
WINS. (Windows 2000 supporte WINS pour des raisons de compatibilité ascendante.)
Lorsqu’un système client Windows 2000 se connecte, il interroge le serveur DNS
pour connaître le contrôleur de domaine du domaine de connexion. Windows 2000
utilise les SRV RR pour trouver le service de connexion et envoie au client le
nom du contrôleur de domaine. Le client utilise un contrôleur de domaine disponible
pour se connecter au domaine AD.

Les SRV RR sont un mécanisme permettant de publier et retrouver des services sur
Internet. Par exemple, supposons que acme.com soit votre serveur Web. En pointant
un SRV RR de _http._tcp.acme.com
sur webdev.acme.com, vous pouvez permettre à  un browser Web supportant les SRV
RR d’utiliser http://acme.com au
lieu de http://webdev.acme.com
pour accéder à  votre serveur Web.
Ceci signifie que vous n’avez pas besoin d’un nom canonique (CNAME) de webdev.acme.com
dans le domaine DNS acme.com, ce qui veut dire qu’il est facile de déplacer le
service Web d’une machine à  une autre. Les SRV RR permettent également l’équilibrage
des charges et la tolérance de panne lorsque l’on associe plusieurs serveurs pour
le service de noms.

Voyons comment Windows 2000 utilise les SRV RR. Si le domaine AD (c’est-à -dire
le domaine DNS) acme.com comporte deux contrôleurs de domaine, w2kdc1 et w2kdc2,
Windows 2000 utilise deux SRV RR pour le service du protocole LDAP dans le domaine
acme.com. Les SRV RR suivantes indiquent les deux contrôleurs de domaine supportant
LDAP dans le domaine acme.com : _ldap.tcp.acme.com.600
IN SRV O 100 389 w2kdc1.acme.com et _ldap.tcp.acme.com.600
IN SRV O 100 389 w2kdc2.acme.com.
Lorsqu’un client interroge _ldap_tcp.acme.com à  la recherche d’un contrôleur de
domaine, le serveur DNS d’acme.com enverra au client les deux valeurs. Le client
choisit soit w2kdc1.acme.com, soit w2kdc2.acme.com, comme contrôleur de domaine
et utilise le protocole LDAP sur le port 389 pour communiquer avec.

Le client choisit le contrôleur de domaine en fonction des paramètres des SVR
RR et des contrôleurs disponibles. Un serveur DNS et le cache système de Windows
2000 reçoivent les enregistrements DNS. Le nombre qui suit le protocole et le
nom du domaine (600 dans notre exemple) est la durée de vie (valeur Time to Live
– TTL) du cache.

Par exemple, Windows 2000 peut mettre en cache pendant 600 secondes (soit 10 minutes).
Le nombre qui suit SRV donne la priorité de l’enregistrement (0 dans l’exemple).

Plus le nombre est petit, plus la priorité est élevée. Le nombre qui suit la priorité
(100 dans notre exemple) indique le poids de l’enregistrement. Plus le chiffre
est grand, plus le poids est important. Si plusieurs enregistrements du même service
ont la même priorité mais des poids différents, le client choisira l’enregistrement
ayant le poids le plus élevé. Si la priorité et le poids sont identiques, le client
choisit le contrôleur de domaine au hasard. Si un client ne peut se connecter
sur le contrôleur de domaine de son choix, il prend le suivant. De cette façon,
les SRV RR permettent d’équilibrer la charge et la tolérance de panne.

Windows 2000 utilise également les SRV RR pour localiser les contrôleurs de domaine
d’un domaine spécifique ; d’un site spécifique (dans les environnements mixtes
Windows 2000/NT) ; d’un serveur de catalogue global (CG), dans un domaine donné
; des serveurs de GC d’un site ; ou des KDC (Key Distribution Center) Kerberos
d’un domaine ou d’un site. Microsoft publie un article (consultable à  l’adresse
http.//support.microsoft.com/support/kb/articles/q178/1/69.asp)
qui documente les SRV RR que les contrôleurs de domaine enregistrent dans DNS.

Certains utilisateurs se plaignent de l’utilisation par Microsoft du caractère
souligné (_) dans les SRV RR de Windows 2000 car certaines implémentation UNIX
de DNS ne les acceptent pas. Microsoft ne doit pas être blâmé pour ce choix.
En janvier 1999, l’IETF a mis à  jour la RFC 2052 dans un draft Internet (chttp./search.ietf.internet-drafts/draft-ietf-dnsind-rfc2052bis-05.txt).
Microsoft a adopté la version révisée pour les SRV RR de Windows 2000 car l’ancienne
RFC sera bientôt remplacée par la version révisée.
Dans la nouvelle version, l’IEFT ajoute un caractère souligné à  l’identifiant
des services SRV RR et au nom du protocole par rapport aux autres étiquettes DNS.
De nombreuses implémentations UNIX de DNS, telles que BIND 4.9.4 et les versions
ultérieures, vérifient que les noms de serveurs sont conformes à  la RFC 952, un
standard de nommage de serveurs qui n’autorise pas les caractères soulignés dans
les noms de serveurs.

Cependant, la première partie des nouveaux SRV RR (qui contient ces caractères)
n’est pas un nom de serveur, ce qui fait que ces caractères ne sont pas un problème.
En outre, les implémentations DNS conformes à  la RFC 952 ne vérifient pas les
noms de serveurs dans la partie du nom qui contient les caractères soulignés.
La partie effectivement lus, le nom de domaine DNS, ne peut contenir de caractère
souligné. A ma connaissance, il n’y a pas de problème de SRV RR contenant des
caractères soulignés avec BIND 8.2.2. Si votre version de DNS UNIX n’accepte pas
les caractères soulignés dans les SRV RR, changez les options de contrôle de noms
de la valeur par défaut (echec) à  Alerter ou Ignorer.