Mécanisme de découverte du PMTU

Table des matières

Nommage direct : du nom vers les adresses

Lorsqu'une application souhaite communiquer avec une autre s'exécutant sur un équipement distant dont elle ne connaît que le nom, elle a besoin d'en trouver l'adresse, sans quoi la communication ne peut en général avoir lieu. Aux débuts de l'Internet, les adresses IP en usage n'étaient pas très nombreuses et il était donc relativement facile de les stocker dans une base de données centralisée, le fichier hosts.txt. Cette base de données pouvait alors être téléchargée (via ftp) par les utilisateurs souhaitant rafraîchir leurs informations stockées sous forme de fichier local (en l'occurrence /etc/hosts pour les systèmes Unix).

Dès le début des années 80, la croissance du nombre d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu de plus en plus difficiles la mise à jour et la mémorisation de ces adresses. Afin de remédier à ce problème, un nouveau système, le DNS (Domain Name System), a été conçu et mis en oeuvre. Petit à petit, le DNS s'est imposé comme étant une infrastructure pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système a l'avantage d'être :

• hiérarchique : sa structure d'arbre est analogue à celle d'un système de fichiers Unix. Cette structure d'arbre rend le système extensible (« scalable »),
• réparti : au niveau de chaque noeud, un ensemble de serveurs fait autorité sur les données contenues dans la zone décrivant ce noeud. Cet ensemble de serveurs représente la source officielle des données de la zone,
• et redondant : deux serveurs ou plus sont nécessaires pour chaque zone DNS afin d'assurer une meilleure disponibilité et un équilibrage de charge.

Le DNS avait initialement comme objectif premier d'offrir un service de résolution de noms de domaines Internet complètement qualifié (FQDN : Fully Qualified Domain Name) garantissant l'unicité du nom (exemple : ns3.nic.fr) en adresses IP et vice-versa.

En pratique, le service de résolution DNS consiste plus généralement à stocker et à retourner, sous forme d'enregistrements DNS (RR : Resource Records) et à la demande des applications, des informations associées à des noms de domaines, comme les adresses IP, les relais de messagerie (enregistrement de type MX) ou les serveurs de noms (enregistrement de type NS).

Rappelons au passage que pour ces applications, la communication est précédée par une phase lors de laquelle le client DNS local, appelé « stub resolver », interroge son serveur DNS récursif (ou cache) qui se charge d'effectuer les requêtes itératives nécessaires, en partant de la racine de l'arbre DNS s'il le faut, et de retourner les ressources recherchées. Pour les machines Unix, le fichier /etc/resolv.conf fournit l'adresse IP du (ou des) serveur(s) à interroger par défaut.

Le service de résolution DNS se trouvant au niveau de la couche application de la pile TCP/IP, il s'applique aux réseaux IPv6 de manière analogue aux réseaux IPv4. Le fait que les adresses IPv6 soient quatre fois plus longues que les adresses IPv4, qu'elles puissent être attribuées automatiquement et qu'elles soient représentées de surcroît en notation hexadécimale, a considérablement réduit les chances pour ces adresses IPv6 d'être mémorisées par un être humain. Ainsi, avec l'arrivée d'IPv6, le DNS devient plus que jamais un service critique pour le fonctionnement des applications TCP/IP classiques.

Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) :

• l'enregistrement AAAA (prononcé « quad A »), pour le nommage direct (correspondance : nom vers adresse). Ce nouveau type a pour code-valeur 28.
• le nouveau sous-arbre DNS inverse ip6.arpa pour le nommage inverse (correspondance : adresse vers nom)

Mécanisme de découverte du PMTU

Table des matières

Nommage direct : du nom vers les adresses