PROFDINFO.COM

Votre enseignant d'informatique en ligne

Les serveurs DNS

Tel qu'on l'a déjà mentionné, un serveur DNS (Domain Name System) est un bottin de noms de domaines et d'adresses IP. Il permet de convertir les noms en adresses et vice-versa. Chaque serveur DNS est responsable d'une ou de plusieurs zones qui correspondent normalement à des sous-domaines. Les serveurs DNS connaissent également les adresses d'autres serveurs responsables de sous-domaines de leurs domaines.

Autrefois...

Dans les débuts d'Internet et d'Arpanet, chaque ordinateur connecté au réseau devait aller télécharger un fichier appelé HOSTS.TXT à un endroit prévu à cet effet. Une liste d'endroits alternatifs pour les prochaines fois était aussi incluse dans le processus. Le fichier HOSTS.TXT orginal était maintenu manuellement à jour.

Évidemment, vint un jour le moment où quelqu'un en eu assez et on inventa le concept du DNS. Le premier serveur DNS fut BIND (Berkeley Internet Name Domain) pour Unix. BIND fut un jour porté sur Windows NT et il continue d'être utilisé dans le monde Linux/Unix aujourd'hui.

La hiérarchie et la délégation

Il existe une hiérarchie de serveurs DNS qui permet de trouver rapidement l'adresse dont on a besoin. Il faut savoir qu'un nom de domaine est composé d'étiquettes séparées par des points. L'étiquette la plus à droite est la plus générale et on spécifie à mesure qu'on se déplace vers la gauche. C'est pourquoi un nom de domaine est toujours lu de droite à gauche (donc "à l'envers") lorsqu'il est temps de trouver l'adresse IP à laquelle il correspond.

Au haut de la hiérarchie se trouve le serveur racine, nommé "." (point). C'est l'origine de tout, l'alpha (mais pas l'oméga). En théorie, il devrait avoir une zone pour chaque domaine possible sur Internet, mais il ne va évidemment pas s'occuper de ça tout seul. Pour se faire aider, il va déléguer des zones (correspondant à des domaines) à des serveurs inférieurs. Il retiendra simplement l'adresse des serveurs délégués pour chaque zone. Le serveur "." s'occupe donc de fournir l'adresse d'un serveur approprié pour le domaine de haut niveau demandé par le client.

Chaque serveur DNS en dessous de la racine va lui aussi fonctionner selon ce même principe: il sera responsable d'une zone, mais pourra déléguer une partie de celle-ci (un sous-domaine) à un serveur DNS inférieur. Il n'aura plus alors qu'à retenir l'adresse de ce serveur DNS inférieur pour pouvoir la retourner en cas de besoin.

Directement sous la racine se trouvent les DNS responsables des TLD (Top Level Domains). Un TLD représente un domaine du plus haut niveau possible (en excluant la racine, qui n'est pas à proprement parler un domaine). Il en exsite deux types: des ccTLD (country code TLD - un domaine représentant (et géré par) un pays comme .ca, .fr, .uk, .tv, etc) ainsi que des gTLD (generic TLD - des domaines de haut niveau ne représentant pas un pays spécifique comme .com, .org, .net, .info, .biz, etc).

Chacun de ces serveurs DNS dédiés à un TLD délègue ses sous-domaines à d'autres serveurs. On peut descendre ainsi jusqu'à avoir 127 niveaux dans la hiérarchie. Chaque étiquette peut avoir jusqu'à 63 caractères de long, mais le nom de domaine au complet doit malgré tout tenir sur 253 caractères ou moins. Les seuls caractères permis sont les lettres (minuscules ou majuscules, ça ne fait pas de différence de toute façon), les chiffres et le trait d'union (une étiquette ne peut toutefois ni commencer ni finir par un trait d'union). On appelle ça la notation LDH (letters, digits, hyphen).

Par exemple, dans l'adresse www.radiococh.org on dira que org est un sous-domaine de ., que radiococh.org est un sous-domaine de .org et que www.radiococh.org est un sous-domaine de radiococh.org.

Les recherches

Lorsque vous tentez d'atteindre un site Web (ou autre) à partir du nom de domaine, votre ordinateur interrogera son serveur DNS préféré. Normalement, l'adresse IP du serveur DNS lui aura été fourni par le serveur DHCP qui lui a donné sa configuration TCP/IP (ou sinon, elle doit être inscrite en dur, en mode statique). Les fournisseurs de service Internet vous fournissent toujours l'adresse d'un (ou souvent de deux) serveurs DNS. On dira que ces requêtes DNS sont récursives, ce qui signifie qu'un serveur donné devra consulter d'autres serveurs pour obtenir la meilleure réponse possible. (à l'inverse, on dira qu'une requête dont la réponse peut être donnée sans consulter qui que ce soit est itérative). Voici un schéma explicatif de notre requête récursive (source: fr.wikipedia.org):

Recherche récursive par DNS

Supposons que le site que vous voulez atteindre est fr.wikipedia.org. Votre ordinateur va demander (en 1) à votre serveur DNS préféré de vous trouver ça. Ce dernier va trouver l'adresse d'un serveur racine pour aller lui demander l'adresse d'un serveur responsable du domaine voulu, soit .org (en 2). Le serveur racine va retourner (en 3) l'adresse du serveur gérant .org. Votre serveur DNS va donc (en 4) demander à ce serveur .org de lui retourner l'adresse du serveur DNS gérant wikipedia.org. Le serveur de .org (en 5) va retourner l'adresse voulue (notez que cette adresse correspond à un serveur géré par Wikipedia, contrairement aux précédentes). Votre DNS va donc aller interroger ce dernier serveur pour lui demander l'adresse de fr.wikipedia.org (en 6). La réponse lui sera retournée sous forme d'adresse IP (en 7) et finalement, votre serveur DNS (en 8) va retourner cette adresse à votre ordinateur!

Notez que les étapes 1 et 6 sont des demandes d'adresses (A) et que les étapes 2 et 4 sont des demandes de serveur DNS (NS pour Name Server). Les autres étapes sont des réponses.

Pour sauver du temps

Tous les serveurs DNS impliqués dans l'opération conserveront en cache les adresses dont ils ont obtenu une réponse d'un autre serveur. Ainsi, on pourra court-circuiter le parcours et donner une réponse plus rapidement. Les adresses en cache seront conservées un certain temps avant d'être éliminées afin que l'on puisse rester à jour si un changement survient. La durée de vie d'une adresse en cache est appelée TTL (Time to Live) et est fournie en même temps que l'adresse par le serveur DNS interrogé (c'est donc lui qui décide si sa réponse risque de s'appliquer longtemps). Le TTL d'un enregistrement peut aller de quelques secondes à quelques semaines.

Serveurs autoritaires

Un serveur est dit autoritaire s'il donne des réponses qui lui ont été fournies par l'administrateur du domaine ou par des mises à jour automatisées. Les réponses sont donc jugées fiables.

Serveurs non autoritaires

Un serveur est non autoritaire s'il donne des réponses qui lui ont été fournies lors de requêtes précédentes à d'autres serveurs DNS, donc s'il utilise son cache. Internet pourrait très bien fonctionner avec uniquement des serveurs autoritaires, mais pour des raisons d'efficacité, les serveurs non autoritaires ont été ajoutés au design. Imaginez ce que ça serait sans eux: des milliards de requêtes quotidiennes seraient envoyées aux serveurs racine, puisque chaque requête DNS doit commencer par là... Sachant que les adresses des serveurs DNS des TLD ne changent pas souvent, le cache est clairement la meilleure solution.

Serveur maître

Un serveur DNS est dit maître s'il conserve les données originales de toutes les zones qu'il dessert.

Serveur esclave

Un serveur DNS est dit esclave s'il copie les données d'un serveur maître. Le but est d'avoir de la redondance afin d'éviter que des sites soient inaccessibles parce qu'un serveur DNS est mort.

Chaque zone DNS doit avoir un ensemble de serveurs autoritaires (maître et esclaves). Lorsqu'un nom de domaine est enregistré par un registraire (c'est ce qui arrive si vous achetez <votrenom>.com, vous faites affaire avec un registraire), l'enregistrement nécessite de fournir au serveur du TLD un serveur DNS primaire et au moins un DNS secondaire qui seront responsable de la zone qui vient d'être achetée. Le serveur du TLD aura donc des adresses à fournir pour les gens qui veulent se rendre au sous-domaine en question. Tout ce qui se trouvera plus bas que ça sera la responsabilité de l'acquéreur.

Recherches inversées

Il est possible d'utiliser un serveur DNS pour faire des recherches inversées: trouver le nom qui correspond à une adresse IP. Après tout, pourquoi pas? Il faut toutefois que des mesures soient prises en compte pour permettre ces recherches dans un système qui fut pensé pour le contraire. Sachant que les requêtes DNS se font toujours de droite à gauche, il faut donc qu'on inverse l'ordre des octets composant l'adresse IP voulue. Par exemple, si on cherche le nom correspondant à 72.14.204.104, on fera plutôt la demande pour 104.204.14.72. À cette adresse inversée, on ajoutera le suffixe ".in-addr.arpa" pour une adresse IPv4 ou ".ip6.arpa" pour une adresse en IPv6. Dans notre exemple, on cherchera donc le nom associé à 104.204.14.72.in-addr.arpa. Le serveur commence par la fin (comme il le fait toujours) et demande donc à la racine l'adresse du serveur gérant .arpa, pour atteindre .in-addr.arpa, qui lui retournera alors l'adresse du serveur d'ARIN (American Registry for Internet Numbers) correspondant à 72. On continuera à descendre l'arborescence à partir de là pour obtenir ultimement le nom voulu. Une recherche inversée est de type PTR (pour "pointeur"), ce qui la différencie des recherches A et NS (voir plus haut).

Le cache du client

Le programme qui démarre une recherche DNS (généralement un navigateur Internet ou truc équivalent) ne communique jamais directement avec le serveur DNS. Il passe plutôt sa requête au système d'exploitation qui s'occupera de tout ça (beaucoup plus simple pour les développeurs et c'est exactement à ça que sert un SE). Le SE se gardera lui aussi un cache pour éviter de devoir se retaper tout le processus si vous allez sur facebook trente fois par heure.

Il faut tenir compte de ce cache lorsque l'on débogue des problèmes de DNS. Le serveur peut fonctionner parfaitement, mais c'est le client qui a enregistré une erreur précédente et qui n'en démord plus.

Sous Windows, on peut visualiser le contenu de ce cache en faisant ipconfig /displaydns. On peut également vider le cache local en faisant ipconfig /flushdns.

Il faut aussi se rappeler que certains navigateurs maintiennent en plus leur propre cache! Une couche supplémentaire à vérifier.

Protocole

La majorité des requêtes DNS et des réponses associées sont faites sur le port 53 en utilisant UDP. TCP sera utilisé uniquement si les réponses prennent plus de 512 octets (la taille d'un datagramme UDP) ou pour les copies de zones du maître à l'esclave.

WHOIS: qui êtes-vous?

La base de données WHOIS est également mise à jour par les registraires lorsque quelqu'un achète une zone. Cette base de données est accessible en ligne à www.whois.net (c'est public et gratuit!).

Les serveurs racines

Il y a uniquement treize serveurs racines répartis à travers le monde. Ces serveurs font tous partie du domaine root-servers.net. (leurs noms vont de a.root-servers.net à m.root-servers.net). Sept d'entre eux sont en réalité clonés et distribués dans le monde (question de diminuer la charge de travail) et utilisent la technique anycast pour contacter le serveur le plus proche ou le moins occupé. Du coup, les 13 serveurs racines sont en fait plus de 200, répartis dans plus de 50 pays.

FQDN: nom de domaine pleinement qualifié

Le FQDN (Fully Qualified Domain Name) représente un nom de domaine écrit de façon absolue du début jusqu'à la racine. On écrira donc l'adresse au complet jusqu'au TLD, et on terminera par un point pour représenter la racine. Par exemple: www.radiococh.org. est un FQDN.

NetBIOS

NetBIOS (Network Basic Input/Output System) est un protocole de la couche 5 (session) qui permet justement d'établir des sessions de communication entre différents ordinateurs d'un réseau. Il permet entre autres l'enregistrement de noms NetBIOS, un peu l'équivalent primitif du DNS. Un nom NetBIOS est composé de 16 caractères maximum, le dernier étant réservé pour le suffixe NetBIOS (un caractère indiquant le service offert par l'hôte). La résolution de noms NetBIOS peut se faire par des fichiers LMHOSTS (à l'ancienne) ou via un serveur WINS (Windows Internet Naming Service).

Le NetBIOS n'est pas particulièrement efficace: il est bruyant (puisque tout est broadcasté), peu sécuritaire et conçu à la base pour des petits réseaux (72 machines ou moins). On continue de le traîner partout même s'il pourrait aisément être remplacé par le DNS pour des raisons de rétrocompatibilité (les machines Windows 9x et NT ont besoin de NetBIOS pour fonctionner en réseau). Évidemment, elles sont bien rares de nos jours et on pourrait potentiellement se débarrasser de NetBIOS une bonne fois pour toutes. Il faut tout de même savoir que dans des grands réseaux, plusieurs domaines peuvent faire partie d'une forêt. Il est possible d'avoir plusieurs forêts qui vivent côte à côte. Et (décision de design fort étrange) NetBIOS est utilisé pour établir les relations de confiance entre les forêts qui partagent des ressources. C'est la raison pour laquelle il est toujours implémenté et allumé par défaut partout, même dans les versions récentes de Windows Server.

Si vous ne croyez jamais étendre votre réseau au point où vous aurez à gérer plusieurs forêts qui entrent en relation les unes avec les autres toutefois, NetBIOS peut être éteint sans problème (et le serveur WINS aussi par le fait même).

Configurer son serveur DNS

Sous Windows server, le serveur DNS connaît déjà les adresses des serveurs racine (donc toutes les requêtes qui sortent du domaine devraient pouvoir se rendre à destination). Il est possible de lui ajouter des redirecteurs pour des sous-domaines précis (si on a plusieurs serveurs DNS s'occupant chacun d'un sous-domaine).

Le reste du travail se passe au niveau des zones. Le serveur DNS abritera des zones de recherches directes (pour trouver l'adresse IP associée à un nom) et des zones de recherches inversées (pour faire le contraire).

 

Les serveurs DHCP

Les opérations DHCP (Dynamic Host Configuration Protocol) s'effectuent essentiellement en quatre phases. Ces phases sont les suivantes : demande de bail IP, offre de bail IP, sélection de bail IP et accusé de réception de bail IP.

Demande de bail IP

Lorsqu'un ordinateur entre en ligne, il vérifie s'il détient actuellement un bail d'adresse IP. S'il n'en a pas, il demande un bail à un serveur DHCP. L'ordinateur client ne connaissant pas l'adresse d'un serveur DHCP, il utilise 0.0.0.0 comme sa propre adresse IP et 255.255.255.255 comme adresse de destination. Cela permet au client de diffuser (broadcast) un message DHCPDISCOVER sur le réseau. Ce message est composé de l'adresse MAC (Media Access Control, l'adresse matérielle intégrée dans la carte réseau) et du nom NetBIOS de l'ordinateur client. En gros, DHCPDISCOVER est l'équivalent de: "HEY TOUT LE MONDE! Je possède l'adresse MAC blablabla et je veux une adresse IP! YOUHOU? Y'A QUELQU'UN? ALLÔ?"

Offre de bail IP

Lorsqu'un serveur DHCP reçoit une demande de bail IP d'un client, il propose une offre de bail IP. Pour cela, il réserve une adresse IP pour le client et diffuse un message DHCPOFFER sur le réseau. Ce message contient l'adresse MAC du client, suivie de l'adresse IP offerte, le masque de sous-réseau, la durée de bail et l'adresse IP du serveur DHCP faisant l'offre. DHCPOFFER correspond donc à: "Bonjour, adresse MAC blablabla. Je suis le serveur DHCP à l'adresse IP 192.168.1.100 et je t'offre l'adresse 192.168.1.75, masque 255.255.255.0, que tu pourrais utiliser pour la prochaine semaine. Dans l'espoir d'une réponse positive de ta part, j'aimerais bien apprendre à mieux te connaître".

Sélection de bail IP

Lorsque l'ordinateur client reçoit une offre de bail IP, il doit indiquer à tous les autres serveurs DHCP qu'il a accepté une offre. Pour cela, le client diffuse un message DHCPREQUEST contenant l'adresse IP du serveur ayant effectué l'offre. Lorsque les autres serveurs DHCP reçoivent ce message, ils retirent les offres qu'ils peuvent avoir faites au client. Ils remettent ensuite l'adresse qu'ils avaient réservée à ce client dans la réserve d'adresses valides qu'ils pourront offrir à un autre ordinateur. Un nombre illimité de serveurs DHCP peut répondre à une demande de bail IP, mais le client ne peut bien évidemment accepter qu'une seule offre par carte d'interface réseau. DHCPREQUEST est donc équivalent à: "HEY TOUT LE MONDE! Je possède l'adresse MAC blablabla et le serveur DHCP 192.168.1.100 vient de me faire une offre incroyable que je ne peux pas refuser! Je suis tellement excité! Désolé, les autres, je pars avec lui!".

Accusé de réception de bail IP

Lorsque le serveur DHCP qui avait fait l'offre reçoit le message DHCPREQUEST du client, il initialise la phase finale du processus de configuration. Cette phase d'accusé de réception implique l'envoi d'un paquet DHCPACK au client (ACK pour acknowledge, ou "montrer qu'on a vu"). Ce paquet inclut la durée de bail et toute autre information de configuration que le client peut avoir demandée. À ce stade, le processus de configuration TCP/IP est terminé. DHCPREQUEST est donc équivalent à: "Wow, adresse MAC blablabla, je suis bien content que tu aies accepté. Tu pourras donc utiliser l'adresse que je t'ai donnée pour 7 jours, voici l'adresse de ta passerelle, voici deux adresses de serveurs DNS que tu pourras utiliser. Bienvenue dans le réseau, Kid".

Demande de libération

Un client peut également demander la libération de son adresse IP, l'abandonnant de son côté et informant le serveur DHCP qu'elle est de nouveau disponible pour quelqu'un d'autre. Le client envoie pour ce faire un paquet DHCPRELEASE.

Gestion du DHCP du côté client

La commande ipconfig /all permet de vérifier si la configuration TCP/IP d'une connexion réseau sera configurée dynamiquement. Pour passer d'un mode d'adressage dynamique à un mode statique ou vice-versa, il faut alors utiliser l'interface graphique et modifier les propriétés TCP/IP, eux-mêmes disponibles dans les propriétés de la connexion réseau.

On peut également libérer son adresse IP en faisant ipconfig /release (remettant alors notre adresse à 0.0.0.0) et en demander une nouvelle en faisant ipconfig /renew (ce qui initie de nouveau tout le processus de découverte d'un serveur DHCP tel qu'indiqué ci-haut).

Notez que si votre adresse IP commence par 169, c'est que le système d'exploitation l'a autoconfigurée, normalement parce qu'aucun serveur DHCP n'a répondu au DHCPDISCOVER. On peut alors disposer d'une connexion à un réseau (parce qu'on arrive à rejoindre un routeur physiquement) mais ne pas être capable d'utiliser ce réseau (parce qu'on n'a pas d'adresse visible dans les sous-réseau pris en charge). Windows indiquera ce problème en disant que vous disposez d'une connexion locale avec connectivité limitée ou inexisante. La solution à ce problème est généralement de libérer l'adresse IP et de redémarrer le processus DHCP sur le client. Si le problème continue, il faut vérifier ailleurs sur le réseau pour trouver le problème (serveur DHCP mort, problème de connectivité physique entre le client et le serveur).

Gestion du serveur DHCP

Un serveur DHCP est assez simple à configurer. Il fonctionne en gérant des étendues, qui sont simplement des plages d'adresses IP qu'il peut offrir. Il est possible de réserver certaines adresses à des clients spécifiques (en connaissant leur adresse MAC - c'est ce qu'on appelle du DHCP statique), et d'exclure certaines adresses d'une plage (si on les a déjà attribuées statiquement à des serveurs, par exemple).

On devra également gérer les durées des baux. Si on dispose de beaucoup d'adresses, un bail peut être très long (une semaine ou même plus) sans que cela pose un problème particulier. Si on a peu d'adresses pour notre nombre de clients et qu'on s'attend à beaucoup de roulement, un bail très court (quelques heures ou moins) est un meilleur choix. En effet, comme les ordinateurs qui se déconnectent du réseau ne font pas nécessairement un DHCPRELEASE, certaines adresses peuvent être réservées pour longtemps et inutilisées.

De nos jours, comme la plupart des DHCP gèrent des adresses locales privées, il est bien facile d'en avoir autant qu'on en veut (il suffit de se donner un réseau de classe B ou même A) et les problèmes de gestions de baux sont beaucoup moins importants. Reste que des serveurs DHCP de fournisseurs d'accès Internet doivent en faire une gestion plus serrée.