DDNS dans Windows 2000

et CNAME dont le contrôleur de domaine a besoin pour s’enregistrer auprès
du serveur DNS. Windows 2000 vous laisse poursuivre l’installation d’un contrôleur
de domaine s’il découvre que le serveur DNS ne supporte pas les mises à  jour dynamiques,
mais vous devez saisir manuellement les enregistrements dans le fichier de zone
du domaine sur le serveurs DNS après l’installation. Si vous ne souhaitez pas
utiliser un serveur DDNS, la saisie manuelle de ces enregistrements peut fonctionner
dans un réseau Windows 2000 comportant un tout petit nombre de contrôleurs de
domaine.
Cependant, dans les moyens et grands réseaux, il faut envisager sérieusement d’utiliser
DDNS (celui de Windows 2000 ou d’un éditeur tiers) pour limiter la charge d’administration
consistant à  saisir les enregistrements et éliminer le risque d’introduire des
erreurs.

Les clients Windows 2000 utilisent également les mises à  jour dynamiques. Lors
de l’initialisation, un client Windows 2000 ayant une adresse IP statique essaiera
d’enregistrer ses valeurs A et PTR sur le serveur DDNS. Un poste de travail utilisant
DHCP pour obtenir une adresse IP dynamique essaiera d’inscrire sa valeur A sur
le serveur DDNS lorsque la poste de travail recevra l’adresse IP. Le serveur DHCP
essaiera d’inscrire la valeur PTR du poste de travail sur le serveur DDNS pour
la compte du client. Pour assurer la compatibilité ascendante, le serveur DHCP
de Windows 2000 enregistre à  la fois les valeurs A et PTR des clients DHCP sous
Windows NT et 9x sur le serveur DDNS. Pour tirer le meilleur des mises à  jour
dynamiques de Windows 2000, vous devez avoir un système DDNS en place là  où vous
déployez Windows 2000.

Les serveurs DNS UNIX acceptent généralement les requêtes de mises à  jour dynamiques
de toutes sortes de valeurs, notamment les valeurs A, PTR. Cependant, ils peuvent
ne pas supporter les mises à  jour dynamiques des SRV RR. Par exemple, BIND 8.2.1
ne les supporte pas, pas plus que les versions précédentes de BIND 8. Pour supporter
Windows 2000, votre implémentation UNIX de DNS doit être BIND 8.2.2 ou 9.

Les serveurs DNS UNIX acceptent généralement les requêtes de mises à  jour
dynamiques de toutes sortes de valeurs

Pour découvrir si votre DNS UNIX supporte les mises à  jour dynamiques des
SRV RR, on peut utiliser l’utilitaire d’invite de commande nsupdate de BIND pour
faire une mise à  jour des SRV RR. Par exemple, créez un domaine de test (par exemple
acme.com) et son fichier de zone dans votre serveur DNS. Activez l’option de mise
à  jour dynamique de la zone et laissez n’importe quel host mettre à  jour la zone.
Utilisez l’utilitaire nsupdate pour générer manuellement une mise à  jour dynamique
du SRV RR du service Web d’acme.com. Utilisez la syntaxe suivante :

$
nsupdate

>
update add webdev.acme.com.86400 IN A 192.168.1.10

update add _http._tcp.acme.com.3600 IN SRV 0 1 80 wedev.acme.com

La première commande lance l’utilitaire nsupdate, la seconde ajoute
l’enregistrement A du serveur Web, la troisième commande ajoute la valeur SRV
RR du service Web au domaine acme.com, et la dernière (ligne vierge) indique à 
nsupdete d’envoyer les deux mises à  jour dynamiques que vous avez saisies vers
le serveur DNS. Si, après avoir lancé cette commande, vous pouvez utiliser nslookup
ou accéder au fichier de zone d’acme.com et y trouver les deux valeurs dans le
serveur DNS, votre serveur DNS supporte les mises à  jour dynamiques des SRV RR.
BIND sauvegarde temporairement les mises à  jour dynamiques reçues dans un fichier
journal de zone et modifie le fichier zone en conséquence.

Option 1 : Migration

Une fois que vous aurez vérifié votre implémentation UNIX de DNS pour vérifier
si elle supporte les SRV RR et les mises à  jour dynamiques, vous allez probablement
découvrir que votre version ne les supporte pas. Une façon simple de supporter
les déploiements de Windows 2000 consiste à  migrer votre service DNS vers celui
de Windows 2000. Le DNS de Windows 2000 supporte les SRV RR, les mises à  jour
dynamiques et l’intégration avec AD.

La procédure de migration est simple. Installez un serveur Windows 2000 autonome
avant d’installer un contrôleur de domaine et AD. Installez le service DNS de
Windows 2000 dans la boîte de dialogues des services réseau. Copiez les zones
de contrôle d’envoi (forward) et de retour (reverse) de votre serveur DNS UNIX
dans le répertoire C:\winnt\system32\dns du nouveau serveur DNS Windows 2000.

On utilise FTP pour transférer les fichiers d’UNIX à  Windows 2000. Si vous n’êtes
pas certain de l’endroit où se trouvent ces fichiers dans la machine UNIX, l’indication
de répertoire dans les fichiers named.boot ou name.conffile du répertoire /etc
vous indique dans quel répertoire se trouvent les fichiers de zone. Les administrateurs
DNS UNIX utilisent souvent un nom de fichier commençant par db pour représenter
un ficher de zone (par exemple, db.acme). Par défaut, Windows 2000 utilise un
nom de fichier avec une extension .dns pour les fichiers de zone (ex. acme.com.
dns), mais on peut utiliser une convention différente ou utiliser les anciens
noms de fichiers de zone du DNS UNIX dans le DNS Windows 2000.

Si votre nom de domaine AD est différent du nom de domaine DNS UNIX, vous devrez
prendre le nom du domaine AD pour le DNS Windows 2000. Changez l’ancien nom de
domaine dans les fichiers zone copiés qui sont maintenant sur le serveur DNS Windows
2000 en leur donnant le nom du nouveau domaine.

Vous pouvez désormais créer une nouvelle zone dans l’outil d’administration du
DNS de Windows 2000 pour chaque fichier zone que vous avez copié du serveur DNS
UNIX. Entrez le nouveau nom de domaine (ex. acme.com) et l’assistant de création
de nouvelle zone vous propose de créer un nouveau fichier de zone ou d’en utiliser
un existant (écran 1). Sélectionnez l’option d’utilisation du fichier existant
et saisissez le nom du fichier de zone que vous avez copié du serveur DNS UNIX
ou celui que vous avez modifié (deb.acme.com ou acme.com.dns). Dans l’écran suivant,
sélectionnez ce serveur DNS comme serveur maître hébergeant la copie maîtresse
de la zone crée. (BIND le qualifie généralement de serveur principal maître.)
Une fois que l’ancien fichier de zone est migré vers le serveur DNS Windows 2000,
changez la valeur du paramètre Permettre la mise à  jour dynamique en Oui dans
l’onglet Général des Propriétés du fichier de zone. Vous permettrez ainsi la lise
à  jour automatique pour cette zone. Par défaut, Windows 2000 désactive cette option.
Pour permettre le load balancing et la tolérance de panne, il vous faut définir
au moins un serveur DNS par zone de contrôle d’envoi et de retour.

Le service DNS de Windows 2000 en place, vous pourrez alors mettre en
oeuvre AD

Le service DNS de Windows 2000 en place, vous pourrez alors mettre en oeuvre
AD. Si vous faites la promotion d’un serveur Windows 2000 hébergeant le serveur
DNS comme contrôleur de domaine, le serveur DNS peut être intégré dans AD. Tous
les serveurs DNS intégrés dans AD sont serveurs maîtres principaux. Ils stockent
les informations sur la zone dans AD et se répliquent mutuellement via le mécanisme
de réplication multimaître d’AD. Les serveurs DNS intégrés à  AD supportent également
les mises à  jour dynamiques sécurisées qui permettent de définir quels clients
sont habilités à  réaliser une mise à  jour dynamique.

Si les serveurs DNS de votre intranet sont aussi serveurs de noms pour Internet,
vous devez changer l’adresse d’enregistrement de votre domaine en reprenant les
nouveaux noms et adresses IP de vos serveurs.

Les postes clients, qu’ils soient sous Windows 2000 ou pas, peuvent désormais
utiliser les nouveaux serveurs DNS. Si certains de vos clients utilisent toujours
DHCP, changez simplement les anciennes adresses de serveur DNS en mettant les
nouvelles adresses de serveurs DNS dans la configuration du serveur DHCP. Les
anciens clients reçoivent l’adresse du nouveau serveur NDS la prochaine fois qu’ils
renouvelleront leur adresse IP ou lorsque l’ordinateur sera initialisé.

Option 2 : la coexistence

La plupart des entreprises exploitant des services DNS sous UNIX ont des environnements
hétérogènes qui incluent Linux, Novell NetWare, UNIX et Windows. Pour minimiser
les interruptions pour les utilisateurs non-Windows lors du déploiement de Windows
2000, on peut créer un sous-domaine DNS et le dédier à  AD. AD n’exige pas de nom
de domaine à  2 niveaux, tel qu’acme.com. On peut définir le domaine racine AD
comme sous-domaine (par exemple win2k.acme.com) de la hiérarchie DNS UNIX de votre
entreprise. Dans la figure 1, win2k est un sous-domaine du système DNS existant
d’Acme. Le sous-domaine win2k utilise le service DNS de Windows 2000.

Pour minimiser les interruptions pour les utilisateurs non-Windows lors
du déploiement, on peut créer un sous-domaine DNS et le dédier à  AD

Pour que le service DNS de Windows 2000 fonctionne, dans le nouveau sous-domaine,
il faut créer une zone DNS distincte pour le sous-domaine et déléguer le sous-domaine
sur au moins un serveur DNS Windows 2000. Ce serveur DNS devient un serveur de
nom et fournit les services DNS pour le sous-domaine. Par exemple, si vous installez
deux serveurs de noms ns1.win2k.acme.com et ns2.win2k.acme.com dans le sous-domaine
win2k.acme.com, vous pouvez déléguer le sous-domaine aux deux serveurs de noms
du domaine acme.com. Les deux serveurs de noms deviennent autorités de noms pour
les sous-domaine et assurent la tolérance de panne et l’équilibrage de charge.

Vous complèterez la délégation en ajoutant une valeur NS pour le sous-domaine
dans le fichier de zone du domaine parent. Par exemple, pour déléguer le sous-domaine
win2k.acme.com au serveur de nom ns1.win2k.acme.com dans le domaine acme.com,
saisissez la commande BIND suivante dans le fichier de zone d’acme.com :

win2k
86400 IN NS

ns1.win2k.acme.com

Vous devez également ajouter une valeur A pour le host ns1.win2k.acme.com
dans le fichier de zone d’acme.com.

Ensuite, vous devez définir une zone de contrôle de retour pour le sous-réseau
Windows 2000. Si vos systèmes Windows 2000 résident dans un sous-réseau distinct,
vous pouvez utiliser des serveurs DNS Windows 2000 pour contrôler les retours
de noms de host. Si vos systèmes hétérogènes résident tous sur le même réseau,
vous devez utiliser vos serveurs DNS UNIX comme serveurs de noms pour les zones
de contrôle des retour, ou migrer vos services DNS sous Windows 2000. Si vous
n’envisagez pas d’utiliser le DHCP de Windows 2000 pour enregistrer dynamiquement
les enregistrements PTR, vous pouvez continuer d’utiliser le DNS UNIX pour cette
tâche. Si vous voulez bénéficier de la mise à  jour dynamique des valeurs PTR de
Windows 2000 et que votre serveur DNS UNIX ne supporte pas cette fonctionnalité,
vous devrez passer sur un serveur DNS Windows 2000.

Autre solution, les serveurs DNS Windows 2000 et UNIX peuvent travailler ensemble
comme serveurs de noms primaires et secondaires pour la même zone. Par exemple,
dans la figure 1, le serveur DNS Windows 2000 qui dessert principalement le sous-domaine
Windows 2000 peut faire office de serveur de nom secondaire pour la zone acme.com.
Avec ce paramétrage, un utilisateur Windows 2000 de win2k.acme.com peut rapidement
résoudre un nom de host UNIX depuis le serveur DNS Windows 2000 local. Si votre
serveur DNS UNIX supporte les SVR RR, vous pouvez définir votre serveur de noms
UNIX comme serveur de noms secondaire du domaine AD. Cependant, si le serveur
DNS UNIX ne supporte pas les mises à  jour dynamiques, n’en faite pas un serveur
de nom d’autorité pour la zone. Lorsqu’un client DNS envoie une mise à  jour dynamique
au serveur de nom d’autorité de la zone, ce dernier envoie la mise à  jour au serveur
maître principal pour une mise à  jour de la zone. Si le serveur de nom d’autorité
ne supporte pas les mises à  jour dynamiques, il ne peut comprendre ou répondre
à  une requête de mise à  jour dynamique. Un serveur DNS UNIX peut être serveur
secondaire d’un serveur DNS Windows 2000, même si le serveur Windows 2000 est
intégré nativement à  AD. Un serveur DNS intégrant nativement AD peut également
être serveur de noms secondaire.

Option 3 : DNS UNIX seulement

Les entreprises qui exploitent des serveurs DNS UNIX depuis longtemps considèrent
souvent que le service de noms de réseau est du domaine d’UNIX et entendent continuer
à  utiliser le DNS UNIX pendant et après leur déploiement de Windows 2000. Si vous
administrez le serveur DNS dans une telle entreprise, il vous faudra probablement
mettre à  jour vos serveurs DNS pour qu’ils supportent les SRV RR et les mises
à  jour dynamiques car Windows 2000 et AD l’exigent. BIND est l’implémentation
DNS UNIX la plus répandue, je me focaliserais donc la mise à  jour et l’utilisation
de BIND pour supporter Windows 2000. Si vous utilisez un autre serveur DNS UNIX,
consultez votre fournisseur et demandez-lui une nouvelle version de DNS supportant
ces fonctions. BIND a été créé par des chercheurs de l’université de Berkeley,
mais il est maintenant maintenu et développé par l’ISC. BIND est disponible pour
pratiquement toutes les plates-formes UNIX, y compris Linux. L’ISC a porté la
plus récente version de BIND (8.2.2) sur Windows 2000 et travaille actuellement
sur BIND 9. Cette version offrira une évolution de l’architecture BIND sous-jacente
pour prendre en compte les zones Internet à  forte croissance (par exemple .com)
et proposera de nouvelles fonctions. Comme bous l’avons vu précédemment, BIND
8.2.2 supporte parfaitement Windows 2000. BIND est un freeware open-source que
l’on peut télécharger du serveur FTP de l’ISC (ftp:\\ftp.isc.org/isc/bind/src).

Les entreprises qui exploitent des serveurs DNS UNIX depuis
longtemps considèrent souvent que le service de noms de réseau est du domaine
d’UNIX

Après avoir décompressé le fichier de distribution de BIND, vous trouverez
le code source dans le sous-répertoire src/port du répertoire dans lequel vous
avez stocké le fichier de distribution de BIND. Dans le répertoire src/port, se
trouve une vingtaine de sous-répertoires tels que Solaris et winnt. Chacun de
ces répertoires contient un fichier makefile qui vous permet d’utiliser le compilateur
C de votre choix pour compiler BIND pour votre plate-forme. Le fichier INSTALL
du répertoire src propose des instructions pour compiler et installer BIND pour
votre OS.

BIND 8.x utilise un nom de fichier de configuration différent de BIND 4.x. Avec
BIND 4.x, le fichier de configuration porte le nom .boot, et dans BIND 8.x, il
s’appelle named.conf. Ce fichier spécifie l’emplacement des fichiers de zones,
définit les paramètres globaux et spécifiques à  la zone, et indique au serveur
BIND de lire et charger les fichiers de zone lorsque le démon nommé s’exécute.
Ce fichier est souvent dans le répertoire /etc. BIND 8.x utilise également une
syntaxe différente, dans named.conf, de celle de BIND 4.x pour named.boot. Le
listing 1 est un exemple de fichier named.conf de BIND 8.2.2. Si vous avez migré
de BIND 4.x à  la version 8.2.2, vous devez convertir votre fichier named.boot
en named.conf. BIND propose heureusement un script de shell bind-bootconf (répertoire
src/bin/namedbootconf) pour converit named.boot en named.conf sans intervention
manuelle.

Par défaut, BIND 8.2.2 désactive les mises à  jour dynamiques. Il faut activer
la fonction zone par zone. Pour activer les mises à  jour dynamiques dans une zone,
il faut ajouter une commande {adress_match_list}
dans la section de la zone du fichier named.conf de BIND. On peut utiliser une
zone existante ou en créer une autre selon votre organisation AD. Les adresse
IP dans la liste de contrôle de mise à  jour indiquent au système sur quel système
trouver la liste authentifiant les mises à  jour dynamiques. Par exemple, dans
le listing 1, named.conf n’accepte que les serveurs du sous-réseau 192.168.1/24
pour la mise à  jour dynamique de la zone de contrôle d’envoie de la zone acme.com
; et ceux de 1.168.192.in-addr.arpa. Cependant, cette méthode d’authentification
de protège pas des attaques. Les hackers peuvent utiliser un serveur présent dans
la liste de contrôle pour attaquer une zone dynamique en envoyant une requête
de mise à  jour dynamique qui efface un enregistrement important ou tous les enregistrements
de la zone. Pour garantir l’authentification et l’intégrité des données DNS, la
RFC 2065 a mis en oeuvre les extensions de sécurité DNS (DNSSEC) dans BIND 8.2.2.
Malheureusement, Windows 2000 ne supporte pas DNSSEC ce qui fait que l’on ne peut
pas utiliser le DNSSEC de BIND 8.2.2 dans les déploiements Windows 2000.

Pour garantir l’authentification et l’intégrité des données DNS, la RFC
2065 a mis en oeuvre les extensions de sécurité DNSSEC dans BIND 8.2.2

Le format d’un fichier de zone dans BIND 4.x et dans BIND 8.x est le même.
Pourtant, pour supporter la mise en cache des requêtes DNS (fonctionnalité définie
dans la RFC 2308), BND 8.2 et les versions qui suivent utilisent le septième paramètre
(minimum TTL) dans un enregistrement SOA (System Access Object) comme paramètre
explicite de cache TTL négatif. Si une requête de résolution de nom DNS tente
d’interroger un enregistrement inexistant, le paramètre de cache TTL négatif indique
à  l’émetteur de la requête combien de temps mettre en cache l’information indiquant
que la ressource n’existe pas. BIND 8.1 et les versions précédentes qui ne supportent
pas la RFC2308 utilisent généralement le paramètre minimum TTL comme valeur par
défaut pour le cache TTL positif des ressources sans valeur TTL explicite. Ce
paramètre de cache TTL positif permet à  DNS de stocker en cache les enregistrements
résolus pendant la durée qu’il spécifie. Lorsque vous utilisez un ancien fichier
de zone (fichier de zone BIND 8.1 ou antérieur) avec BIND 8.2.2, vous devez ajouter
une directive $TTL (par exemple $TTL 86400) pour spécifier une valeur par défaut
de cache TTL positif dans le fichier de zone. La directive $TTL placée dans l’enregistrement
SOA devient la valeur par défaut du cache TTL positif pour tous les enregistrements
TTL de la zone. Si vous n’utilisez pas de directive $TTL, BIND 8.2.2 utilise la
valeur de cache TTL négatif comme valeur de cache TTL positif, la valeur du cache
TTL négatif étant généralement plus petite.

Après avoir fait les modifications nécessaires au fichier named.conf et au fichier
de zone, vous pouvez lancer ou relancer le démon nommé afin qu’il utilise les
nouveaux fichiers de configuration et de zone. On peut employer l’utilitaire nsupdate
de BIND en premier lieu pour vérifier que votre serveur DNS supporte des mises
à  jour dynamiques. Votre serveur DNS est alors prêt à  accepter les mises à  jour
dynamiques des systèmes Windows 2000. Lorsque BIND reçoit une mise à  jour dynamique,
il enregistre la mise à  jour dans le fichier journal dont le nom correspond au
nom de la zone (par exemple db.acme.log) et met à  jour les données DNS en mémoire.
BIND met à  jour le fichier de zone périodiquement (environ toute les heures) et
supprime l’ancien fichier journal lorsque BIND confirme la mise à  jour. De cette
façon, BIND regroupe les mises à  jour dynamiques dans un processus batch plutôt
que de mettre à  jour le fichier de zone à  chaque fois que BIND reçoit une mise
à  jour dynamique. Ce mécanisme peut prendre en charge simultanément plusieurs
mises à  jour.

Lorsque l’on utilise les mises à  jour dynamiques pour une zone dans BIND, ne modifiez
pas manuellement le fichier de zone. BIND définit le fichier de zone comme en
lecture seule une fois que la zone est mise à  jour. Toutes les modifications manuelles
que vous pouvez faire entre les mises à  jour des zones seront perdues. Pour ajouter,
supprimer ou modifier un enregistrement, on peut utiliser nsupdate pour envoyer
manuellement une requête de mise à  jour dynamique vers la zone.

BIND 8.2 et les versions ultérieures supportent le transfert de zone incrémentiel
(la RFC 1995 définit cette fonction), qui permet à  un serveur de nom secondaire
(serveur de noms esclave dans la terminologie BIND 8.x) de ne transmettre que
les modifications et non tout le fichier modifié. Le serveur BIND maître gère
les changements entre un numéro de série SOA et le suivant dans le fichier .ixfr
(par exemple db.acme.ixfr) d’une zone. Lorsqu’un serveur esclave demande un transfert
de zone incrémentiel, le serveur maître ne transfert que les modifications. Windows
2000 supporte le transfert de zone incrémentiel.

A vos marques, prêts, partez !

Vous avez désormais une meilleure vision des besoins DNS de Windows 2000, vous
pouvez donc désormais décider quelle option est la meilleure pour intégrer vos
services DNS UNIX et Windows 2000. Lorsque vous aurez mis en place une infrastructure
DNS supportant les SRV RR et les mises à  jour dynamiques, vous serez prêts à  déployer
Windows 2000 et AD.