NT en 5 leçons

Leçon 1 Leçon 2 Leçon 3 Leçon 4 Leçon 5

Domain Naming Service (DNS) est le protocole Internet qui, sous forme d'une immense base de données distribuée, va assurer la corrélation entre ces deux types d'adresses : IP ou nom de domaine

La gestion des noms de domaine est distribuée de manière hiérarchique. Un petit nombre de serveurs au sommet de la pyramide se chargent de recenser toutes les informations communiquées par les serveurs de noms de domaine de plus bas niveau. Internic est l'organisme chargé de gérér les serveurs de nom du plus haut niveau qu'on appelle les 'top level domain'.

Aux USA, les noms de domaine ont une structure très codifiée, l'extension finale du nom étant fonction du type d'activité du site:

• COM pour les compagnies commerciales,
• EDU pour le monde académique,
• GOV pour les instances gouvernementales,
• MIL pour les institutions militaires,
• NET pour les grands centres de support réseau
• ORG pour les autres organisations
• INT pour les organisations internationales. ( Le seul domaine repris sous le suffixe INT est l'OTAN, l'Organisation du Traité de l'Atlantique Nord. )
• UUCP est un suffixe réservé à toutes les organisations utilisant UUCP sans avoir de noms de domaines.

Dans le reste du monde, la seule obligation est de respecter comme extension finale le nom du pays. L'abréviation du pays est codifiée par la norme ISO 3166 2 :

• be pour Belgique,
• nl pour Hollande,
• fi pour Finlande etc.

Seuls les anglais n'ont pas respecté la normee ISO et ont préféré l'extension .UK au lieu de la norme .GB

Chaque serveur ne contient que les informations concernant sa propre zone et se réfère à une autorité, un serveur de niveau supérieur, pour toutes les autres informations. . S'il reçoit une demande d'info relative à une machine hôte qu'il ne connaît pas, il passe la main à un authoritative server puis bufferise la réponse pour un usage ultérieur.

Dans les années 70, Arpanet n'était qu'une minuscule communauté d'une centaine de machines. Un simple fichier HOSTS.TXT contenait toutes les informations nécessaires pour désigner la totalité des machines du réseau. Le fichier était maintenu par un Network Information Center ( NIC ) qui se chargeait d'apporter toutes les modifications nécessaires et de les redistribuer à l'ensemble de la communauté.

Avec la croissance d'Internet, cette manière de procéder est devenu rapidement inutilisable : trop de traffic, la consistance du fichier devenait difficile à maintenir. En 1984, Paul Mockapetris déposa les RFC ( Request For Comments ) 882 et 883 posant les jalons du nouveau système DNS ou Domain Name System. Le DNS devient une base de données distribuée permettant un contrôle local de portions de la base de données globale. Des programmes baptisés name servers contiennent les informations à propos de certaines parties de la base de données et les mettent à disposition de programmes client baptisés resolvers. Un resolver n'est la plupart du temps qu'une simple routine d'une librairie logicielle créant des requêtes et les envoyant sur le réseau en direction d'un name server.

La structure d'une base de données DNS est très semblable à celle d'un système de gestion de fichiers Unix : la base de données est représentée comme un arbre inversé avec une racine au sommet. En Unix, la racine est représentée par un slash " / " tandis que la racine du DNS est désignée par un label vide mais s'écrit comme un simple point " . ". Chaque noeud de l'arborescence s'appelle un " directory " dans le monde Unix ou un " domain " dans l'architecture DNS.

Un domaine est donc une simple branche du domain name space. Un nom de domaine peut appartenir à plusieurs domaines : ainsi le nom de domaine insideinternet.bestof.be fait partie du domaine bestof.be mais aussi du domaine be.

Dans un DNS, chaque domaine peut être administré par une organisation différente, chaque organisation pouvant même fractionner son domaine en une série de subdomains dont l'administration est confiée à différentes entités. Le plus ancien et le plus répandu des programmes de gestion de DNS s'appelle BIND pour Berkeley Internet Name Domain écrit pour le système d'exploitation Berkeley Unix 4.3BSD et porté depuis lors sur l'ensemble des plates-formes Unix et même Windows NT.

Lorsqu'un nom de domaine est écrit avec un point à la fin, c'est pour préciser que ce nom de domaine est " absolu ", c'est-à-dire relatif à la racine. Il est dans ce cas généralement désigné par le terme Fully Qualified Domain Name ou FQDN.

On désigne comme top level domain des domaines rattachés directement à la racine du DNS ( .com, .net etc… )

L'objectif original à la base de la création du Domain Name System était de décentraliser l'administration de la base de données globale. Cette décentralisation est possible grâce au mécanisme de délégation. Un organisme chargé de l'administration d'un domaine peut diviser celui-ci en plusieurs sous-domaines, un responsable étant délégué pour gérer chacun de ces sous-domaines. Ce responsable peut gérer librement les données propres à ce sous-domaine, voire le re sous-diviser en sous-domaines dont il délèguera l'administration à d'autres.

Nous définirons donc le terme délégation comme l'acte d'assigner la responsabilité d'un sous-domaine à une autre organisation.

Les spécifications du DNS distinguent deux types de names servers, primary et secondary. Un primary name server dispose de ses propres fichiers de configuration et de données où sont reprises les informations sur les domaines gérés par ce serveur. Un secondary name server ne dispose pas de fichiers de configuration : il obtient les données propres à un domaine d'un autre serveur DNS ayant autorité sur ce domaine. Quand un serveur secondaire démarre, il contacte un primary name server et demande une mise à jour des données, opération baptisée en jargon DNS zone transfer

Il est intéressant de désigner plusieurs name servers pour la gestion d'un simple domaine : pour distribuer la charge de travail, pour être sûr qu'au moins un name server est disponible ( en cas de plantage d'un autre serveur).

Attention, la distinction primary-secondary name server peut être trompeuse puisqu'un même serveur DNS pourrait très bien être primary pour un domaine et secondary pour un autre.

Un root name server est capable de localiser les name servers ayant autorité pour tous les top-level domains.

Lorsqu'il reçoit une requête concernant un nom de domaine, le root name server peut au moins fournir le nom et l'adresse d'un name server ayant autorité pour le top-level domain auquel correspond ce domaine. Ce top-level domain va pouvoir à son tour fournir nom et adresse du name server du niveau suivant et ainsi de suite.

Toute requête d'un client/resolver va donc impérativement devoir passer par l'interrogation d'un root name server. Si ces root name servers venait à tomber en panne, toute résolution de nom de domaine sur Internet s'avérerait impossible. Pour se protéger de tels problèmes, les autorités Internet ont créé notamment les huit root name servers suivants disséminés dans le monde :

NS.INTERNIC.NET.

NS1.ISI.EDU.

C.NYSER.NET

TERP.UMD.EDU.

NS.NASA.GOV

NS.NIC.DDN.MIL

AOS.ARL.ARMY.MIL

NIC.NORDU.NET

Ces serveurs sont extrêmement sollicités par l'ensemble de la communauté Internet. De 6 requêtes à la seconde en 1992, les root name servers sont en moyenne passés aujourd'hui à une centaine d'interrogation par seconde.

Voici également la liste des root name servers pour le domain .be :

DNS.CS.KULEUVEN.AC.be internet address = 134.58.40.4

DNS.CS.KULEUVEN.AC.be internet address = 134.58.41.7

DNS.CS.KULEUVEN.AC.be internet address = 134.58.45.30

SECDNS.EUNET.be internet address = 193.74.208.139

NS.BELNET.be internet address = 193.190.198.2

NS.BELNET.be internet address = 193.190.198.10

MAILSERV.CC.KULEUVEN.AC.be internet address = 134.58.8.44

NS.EU.NET internet address = 192.16.202.11

SUNIC.SUNET.SE internet address = 192.36.125.2

NS.DNS.be internet address = 134.58.74.33

Lorsqu'un programme client resolver a besoin de convertir une adresse IP en un nom de domaine, sa tâche n'est pas simple et la procédure est un peu biscornue. Puisque tout le domain name space est indexé sur le nom uniquement, il faudrait théoriquement interroger tous les domaines de l'arborescence pour retrouver une adresse IP. Pour contourner ce problème, on a créé une portion spéciale du domain name space où les adresses IP sont utilisées comme nom. Cette portion de name space s'appelle le domain in-addr.arpa. Les nœuds du domaine in-addr.arpa sont nommés d'après les nombres correspondant aux quatre octets d'une adresse Ipv4. Le root name server pour le domaine addr.arpa pourrait donc gérer 254 sous domaines correspondant à toutes les valeurs possibles d'un octet d'une adresse IP. Chacun de ces sous domaines pointe vers 254 sous domaines correspondant au second octet et ainsi de suite. Quand elle est lue comme un nom de domaine l'adresse IP apparaît donc à l'envers puisqu'il faut la lire depuis la feuille jusqu'à la racine. Notre serveur web 193.74.105.205 est repris sous le nom 205.105.74.193.in-addr.arpa qui renvoie vers la machine www.best.be. Pourquoi cette écriture à l'envers ? Pour pouvoir assurer une meilleure délégation des adresses IP. L'administrateur du domaine 193.in-addr.arpa peut de la sorte gérer les adresses 193.x.x.x comme il l'entend et déléguer une partie de ce domaine à un tiers. Le sous-domaine 193.74.x.x peut déléguer à son tour si besoin est.

Comme nous venons de le voir, la simple résolution d'un nom en adresse IP suppose l'interrogation récursive ou itérative d'un grand nombre de serveurs intermédiaires. Heureusement, les name servers disposent d'un mécanisme de caching permettant d'accélérer cette lourde procédure. Un name server stocke généralement l'information qu'il vient d'obtenir sur une machine hôte ou un serveur de noms de domaine à des fins ultérieures. Ce mécanisme de tampon va aussi avoir pour effet de nous éviter d'avoir à faire appel plusieurs fois aux root name servers dont nous aurons conservé l'adresse et que nous éviterons ainsi de saturer.

La mémoire tampon d'un name serveur ne peut être conservée indéfiniment sinon les modifications apportées à la configuration d'un domaine n'atteindraient jamais le reste d'Internet. Il est de la responsabilité d'un administrateur de domaine de décider d'un time to live, ou TTL, en clair d'un laps de temps où un name server est autorisé à "cacher" les données de son domaine. Après cette période exprimée en TTL, le name server doit vider son cache et rafraichir son information auprès d'un name server ayant autorité sur ce domaine. Un petit TTL vous garantit une meilleure consistance des données relatives à votre domaine sur l'ensemble des name servers de la communauté Internet tandis qu'un TTL plus long vous offre de meilleurs temps de réponse pour la résolution d'adresses relatives à votre domaine puisque les informations seront "cachées" plus longtemps.

Les fichiers de configuration de données utilisés par les name servers sont généralement appelés db files, raccourci pour database files. Ces fichiers contiennent des enregistrements décrivant les propriétés d'un domaine et appelés Resource Records.

Les données associées à des noms de domaine sont appelées des resource records ou RR en abrégé. Ces records sont divisés en classes. Chaque classe de records traite d'un type de réseau particulier. Actuellement les réseaux gérés sont IN pour Internet ( ou n'importe quelle configuration TCP/IP) , CSNET pour Chaosnet et HS pour Hesiod.

Le record A va contenir les informations permettant d'associer un nom de machine et une adresse IP sous la forme Nom d'hote A classe adresse.

Dans le domaine best.be, la ligne de configuration associant le nom www à l'adresse 193.74.105.205 est donc

www A IN 193.74.105.205

Le record SOA pour Start Of Authority sert à marquer le début d'un domaine ou d'une zone. Il contient en premier lieu le nom du name server ayant autorité sur cette zone, puis l'adresse email d'un administrateur du domaine ainsi qu'une série d'informations utilisées en interne par un name server : un numéro de série ( la convention veut qu'on utilise généralement une date inversée AAAAMMJJ suivie d'un numéro de modification comme ceci 1999123101 ) qu'il faudra incrémenter chaque fois que l'on apporte une modification aux db files.

Viennent ensuite un "refresh interval", un "retyr interval", un "expire time" et un minimum TTL tous exprimés en secondes.

• Refresh, un nombre de 32 bits exprimant l'intervalle de temps en seconde que devrait respecter un serveur copiant cette base de données avant de rafraîchir sa copie.
• Retry, un nombre de 32 bits exprimant le délai à respecter entre deux tentatives de rafraîchissement d'une base de données en cas d'échec initial.
• Expire, un nombre de 32 bits utilisé pour stipuler la plus haute limite de temps en secondes à partir de laquelle une zone a perdu son autorité.
• Minimum, le Time To Live minimum envoyé avec chaque réponse à une requête DNS.

Si vous interrogez un serveur DNS sur le record SOA du domaine best.be avec un outil comme nslookup, il vous sera répondu ceci :

best.be

primary name server = ns.best.be

responsible mail addr = tom.best.be

serial = 1999010401

refresh = 28800 (8 hours)

retry = 7200 (2 hours)

expire = 604800 (7 days)

default TTL = 86400 (1 day)

Dans le fichier de configuration du name server, cela correspond à ceci

@ IN SOA ns.best.be

tom.best.be ( ; notez le . à la place de l'@ dans tom@best.be
1999010401 ; Serial 1^er modif du 04/01/1999
28800 ; Refresh - 8 heures
7200 ; Retry - 2 heures
604800 ; Expire - 1 Week
86400) ; Minimum - 24 Hours

Les champs NS définissent les noms des serveurs de domaine.

IN NS secdns.eunet.be

IN NS ns.best.be

Grâce au champ SOA, nous savions que le primary name server était ns.best.be. Nous savons maintenant qu'un secondary name server existe et s'appelle secdns.eunet.be

Les champs MX définissent le nom des machines utilisées comme serveurs de courrier électronique, comme Mail eXchanger

;
; Mail Exchanger Information
;

IN MX 10 mail.best.be.
IN MX 20 mail.eunet.be.

Pour envoyer un message à l'extérieur, un programme serveur mail SMTP comme Sendmail ou Exchange a besoin de connaître l'adresse IP d'un autre serveur mail appartenant au domaine avec lequel il veut communiquer. Pour ce faire, il interroge un champ du DNS appelé Mail Exchanger ou MX record. Avant d'envoyer un message à tom@best.be, Sendmail examine le contenu du champ MX pour le domaine best.be. Chaque enregistrement MX contient une valeur numérique mesurant un taux de préférence associé à chaque serveur mail du domaine : plus le chiffre est petit, plus la préférence est élevée avec la valeur 0 spécifiant le meilleur choix possible et 65535 la valeur la plus élevée.

Les lignes de configuration ci-dessus expliquent que tout courrier à l'intention d'un membre du domaine best.be doit être remis de préférence à la machine mail.best.be. Si celle-ci est indisponible, les emails seront dirigés vers

mail.eunet.be.

Le record CNAME ou Canonical Name permet de définir un alias ou synonyme pour une machine donnée.

;
; CNAME's
;

cytron IN A 193.75.158.124
ftp IN CNAME cytron

Le vrai nom de la machine 193.75.158.124 est ici cytron.best.be mais elle répondra aussi au synonyme ftp.best.be

Pour pouvoir assurer la recherche d'un nom de domaine à partir d'une adresse IP, ce que nous appelions plus haut du reverse mapping,, il a fallu passer par la création d'un domaine spécial IN-ADDR pour INverse ADDRess. Pour trouver le nom associé à l'adresse IP 1.2.3.4, nous devons chercher le champ PTR associé avec le nom 4.3.2.1.in-addr.arpa.

Le record AAAA ( pour adresse) permet d'associer un nom de domaine à une adresse IPv6 au lieu d'une adresse IPv4 habituelle.

Fin 1994, l'Internet Engineering Task Force s'est mis d'accord sur la norme IP Next Generation alias IPng alias IPv6. IPv6 supportera jusqu'à 1 milliard de réseaux en utilisant 128 bits pour chaque adresse au lieu des 32 bits d'Ipv4 qui arrive à saturation. IPv6 apporte plusieurs améliorations à la norme IPv4 :

• Les stations de travail sont auto configurées déterminant leur propre adresse réseau et adresse hôte.
• IPv6 est prévu pour coexister avec IPv4.
• Un réseau IPv6 peut supporter un nombre illimité d'hôtes.
• Une adresse IPv6 peut contenir une adresse IPv4

AFSDB

Le record AFSDB permet de spécifier la localisation d'un serveur compatible avec AFS ( Andrew File System)

Un système de gestion de fichier proche de NFS mais mieux adapté aux wide-area networks (WANs).

HINFO

ISDN

Le record ISDN (Integrated Services Digital Network) est une variante du champ A (address). On y fait la corrélation non plus entre un nom et une adresse IP, mais entre un nom et un numéro de téléphone ISDN de manière à pouvoir être exploité par un autre record RT (route through).

MB (Experimental)

Le record MB (mailbox) en est toujours au stade expérimental mais permet d'associer une adresse email à un serveur mail.

MG (Experimental)

Le record MG (mail group) permet de placer une mailbox dans un Mail Group ou une mailing list

MINFO (Experimental)

Le record MINFO (mailbox information) est tout aussi expérimental et permet de créer une boîte aux lettres spéciale responsable de la gestion d'une mailing list

Fields

RP

Le champ RP (responsible person) indique l'adresse email d'un responsable d'un nom de domaine

RT

Le champ RT (route through) désigne le nom d'une station intermédiaire permettant de router des paquets vers une destination finale

TXT

Le record TXT (text) associe une information de type texte à un élément d'une base de données DNS. On y place généralement une information sur la localisation physique d'une machine du domaine.

WKS

Le champ WKS (well-known service) décrit les services offerts par un protocole particulier sur une interface précise.

X25

Le record X25 (X.25) associe un nom de machine à une adresse X.121. X.121 est un protocole ISO ( International Standards Organization ) gérant le format des adresses dans des réseaux X.

La première opération sous Windows NT sera d'installer le service DNS. Par le biais du panneau de configuration, cliquez sur l'icône "network" puis sélectionnez l'onglet "services". Cliquez sur le bouton "add"

puis choisissez le service "Microsoft DNS Server". Une fois le service installé, vous êtes bon pour rebooter la machine et pour réinstaller votre dernier Service Pack . Quelques tasses de café plus tard, vous trouverez sous le bouton Start/Programs/Administrative tools une nouvelle icône DNS Manager. Lancez ce programme.

L'opération suivante sera de choisir dans le menu déroulant "dns" l'item "new server" Une boîte de dialogue apparaît vous réclamant l'adresse IP ou le nom d'un serveur DNS. Entrez-y l'adresse ou le nom de votre machine sur laquelle vous avez installé le service DNS. Si le serveur est bien installé et répond, vous verrez son nom apparaître dans le frame de gauche sous la "server list". Cliquez sur ce nom dans la liste et du bouton droit de la souris, sélectionnez l'option "new zone". C'est ici que vous allez pouvoir introduire tous les paramètres des Resource Records pour le domaine que vous êtes en train de créer. Imaginons que nous installons un primary name server pour le domaine "best.be". La boîte de dialogue nous enjoint de spécifier si nous créons un primary ou un secondary name server. Si nous choisissons "primary", un deuxième écran nous demande le nom de la zone à générer ( best.be ) et nous propose par défaut comme nom de fichier de configuration le nom de la zone suivi de ."dns" ( best.be.dns ). Cliquez sur "finish" et Microsoft DNS Server génère pour vous le champ SOA

et le champ NS.

Le plus gros du travail est fait. Il vous reste à présent à encoder manuellement le nom et les adresses IP des machines du domaine dont vous souhaitez rendre connue l'existence grâce au Resource Record A.

Cliquez du bouton droit de la souris dans le cadre de droite et choisissez l'item "new host" dans le menu déroulant. Dans la boîte de saisie, encodez le host name ( www ) suivi de l'adresse IP de la machine.

Pour créer les autres types de records, choisissez l'option "new record" dans le menu "dns".

Vous aurez certainement besoin d'un record MX que pouvez sélectionnez dans la listbox à gauche. Le nom de votre domaine apparaît déjà en haut à droite. Laissez en blanc le champ "Host name (optional), indiquez le nom de votre serveur mail SMTP sous la rubrique "Mail Exchange DNS Server Name " et placez le "preference number" à 10. Répétez l'opération pour chacun de vos serveurs SMTP en n'oubliant pas d'incrémenter le "preference number" à chaque fois.

Par le même menu "DNS/New record", vous allez pouvoir spécifier le nom d'une machine faisant office de name server secondaire après avoir choisi le record "NS" . Vous pouvez aussi créer des synonymes entre noms grâce au CNAME Record qui vous demandera quel "Alias Name" correspond à quel " Host DNS Name".

Vous n'aurez pratiquement jamais à vous préoccuper des autres records.

Dans le cadre de gauche, cliquez de temps en temps sur l'icône "cache" pour voir quelles informations a conservé votre name server dans sa mémoire tampon.

Consultez aussi de temps en temps via " Start/programs/administrative tools/event viewer" les messages générés par le DNS Manager dans votre fichier journal.

Si vous devez interrompre ou relancer le service DNS, il vous faudra passer dans le "control panel", trouver l'icône "services" et trouver la ligne correspondant au "Microsoft DNS Server"

Jetez un dernier coup d'œil dans le répertoire "\winnt\system32\dns". Vous y trouverez les fichiers de configuration compatibles BIND générés par le DNS Manager pour chacune de vos zones. Dans notre exemple, vous y trouverez le fichier best.be.dns contenant au minimum

@ IN SOA ns.best.be. tom.best.be. (

3 ; serial number

3600 ; refresh

600 ; retry

86400 ; expire

3600 ) ; minimum TTL

@ NS ns.best.be.