Aperçu des terminologies, composants et concepts du DNS

DNS (Domain Name System) est l’un des composants cruciaux qui propulsent l’internet. Avoir une bonne compréhension du fonctionnement du DNS peut aider à diagnostiquer les problèmes de configuration de sites web et à élargir votre compréhension de ce qui se passe en coulisses.

Dans ce guide, nous aborderons certains concepts fondamentaux du DNS afin de vous fournir des bases solides lorsque vous travaillez sur votre configuration DNS. Ce guide vous aidera également à configurer votre propre nom de domaine ou serveur DNS.

Commençons !

Terminologie des domaines

Tout d’abord, nous devons bien comprendre les termes que nous allons utiliser. Vous êtes peut-être déjà familier avec certains d’entre eux dans d’autres contextes. Cependant, il existe de nombreux termes spécifiques lorsque l’on parle de noms de domaine et de DNS qui ne sont pas très abordés dans d’autres domaines de l’informatique.

• Système de noms de domaine

Le système de noms de domaine (DNS, en abrégé) est un système réseau en place qui traduit les noms de domaine faciles à retenir pour les humains en adresses IP uniques.

• Nom de domaine

Un nom de domaine fait référence au nom facile à retenir utilisé pour s’associer à une ressource Internet. Par exemple, “cloudsigma.com” est un nom de domaine. Certains diront que seule la partie “cloudsigma” est le nom de domaine, mais généralement, il fait référence à l’ensemble.

L’URL “cloudsigma.com” est associée aux serveurs appartenant à CloudSigma. Lors de la saisie de l’URL dans le navigateur web, celui-ci communique avec le DNS pour se connecter à l’adresse IP du serveur cible.

• Adresse IP

Une adresse IP fait office d’adresse réseau pour un appareil connecté au réseau. Chaque adresse IP doit être unique au sein du réseau. Dans le contexte des sites web, le réseau est, la plupart du temps, l’ensemble d’Internet.

Il existe deux types d’adresses IP :

• • IPv4: Il s’agit de la forme la plus courante d’adresse IP. Elle s’écrit sous la forme d’un ensemble de quatre nombres, chaque ensemble comportant jusqu’à 3 chiffres. Chaque ensemble est séparé par un point. La plage de l’IPv4 va de 0.0.0.0 à 255.255.255.255.

  • IPv6: C’est une norme plus moderne qui a été développée pour résoudre le problème de l’épuisement des adresses IPv4. L’IPv4 prend en charge jusqu’à 232 adresses uniques tandis que l’IPv6 prend en charge jusqu’à 2128 adresses. Toute adresse IPv6 est écrite en chiffres hexadécimaux. Elle peut contenir jusqu’à 32 chiffres, répartis en 8 sections (4 chiffres par section). Chaque section est séparée par deux-points (:).

Domaine de premier niveau

Un domaine de premier niveau (TLD en abrégé) est la partie la plus générale du domaine. Il fait référence à la partie la plus à droite (séparée par un point). Certains des domaines de premier niveau les plus courants comprennent :

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

En termes de noms de domaine, ces domaines se situent au sommet de la hiérarchie. L’ICANN (Internet Corporation for Assigned Names and Numbers) peut accorder une autorisation pour le contrôle de certains tiers sur les domaines de premier niveau. Avec cette autorisation, ces tiers peuvent distribuer des noms de domaine sous le TLD (généralement via un bureau d’enregistrement de noms de domaine).

• Hôtes

Dans le domaine, le propriétaire peut spécifier des hôtes individuels, faisant référence à des machines/services distincts accessibles via un domaine. Par exemple, il est courant de rendre les serveurs web accessibles via le domaine nu ( example.com) et la définition d’“hôte” “www  ( www.example.com).

Il est possible d’avoir des hôtes supplémentaires sous le domaine général, par exemple, un accès API via l’hôte “api” ( api.example.com), un accès FTP via l’hôte “ftp” ou “files” ( ftp.example.com ou files.example.com).

Notez que les noms de domaine peuvent être arbitraires tant qu’ils sont uniques au sein du domaine.

• Sous-domaine

Un sous-domaine est un sujet lié aux hôtes. Le DNS fonctionne selon une hiérarchie. Un TLD peut avoir de nombreux domaines sous lui. Par exemple, “ example.com”, “ cloudsigma.com”, etc. se trouvent tous sous le TLD “com”. À cet égard, un sous-domaine est une référence à tout domaine qui fait partie du domaine cible. Ainsi, on peut dire que “example.com” est un sous-domaine de “com”. Généralement, la partie “example” est appelée un SLD (second-level domain).

De même, un domaine peut contrôler tous les “sous-domaines” situés sous lui. C'est généralement à cela que fait référence le terme “sous-domaine”. Par exemple, “ history.example.com” est un sous-domaine de “ example.com”.

La différence clé entre un nom d'hôte et un sous-domaine est qu'un hôte définit un ordinateur/une ressource tandis qu'un sous-domaine étend le domaine parent. Chaque fois que nous parlons de sous-domaines ou d'hôtes, vous pouvez vous en assurer en regardant la partie la plus à gauche d'un domaine, car c'est la plus spécifique. C'est ainsi que fonctionne le DNS : du plus spécifique (le côté le plus à gauche) au moins spécifique (le côté le plus à droite).

• Nom de domaine pleinement qualifié

Un nom de domaine pleinement qualifié (FQDN, en abrégé) fait référence à un nom de domaine absolu. Dans le système DNS, les domaines peuvent être définis les uns par rapport aux autres. Cela peut prêter à ambiguïté. Un FQDN, cependant, est un nom absolu faisant référence à la racine absolue du système de noms de domaine.

Cela signifie que le FQDN spécifie chaque domaine parent, y compris le TLD. Un bon exemple serait “ mail.google.com”. Dans des cas spécifiques, le FQDN peut ne pas se terminer par un point, mais il doit comporter un point final (requis par les normes de l'ICANN).

• Serveur de noms

Un serveur de noms est un ordinateur dédié à la traduction des noms de domaine en adresses IP. Les serveurs de noms supportent la majeure partie de la charge du système DNS. Comme le nombre total de requêtes de traduction de domaine est trop élevé pour être géré par un seul serveur, les requêtes sont souvent redirigées vers d'autres serveurs de noms pour atténuer la pression.

Un serveur de noms peut être “faisant autorité”, ce qui signifie qu'il ne donne des réponses qu'aux requêtes concernant les domaines sous son contrôle. Ces serveurs peuvent relayer la requête vers d'autres serveurs de noms ou fournir une copie en cache des données d'autres serveurs de noms.

• Fichier de zone

Un fichier de zone est un fichier texte contenant les correspondances entre les noms de domaine et les adresses IP. Il sert de base de données au système DNS. C'est le catalogue que le DNS utilise pour trouver l'adresse IP à contacter lors de la résolution d'une requête d'utilisateur pour un nom de domaine donné.

Généralement, les serveurs de noms hébergent les fichiers de zone et définissent les ressources disponibles sous un seul domaine. Ils peuvent également contenir des informations sur l'endroit où aller pour obtenir ces informations.

• Enregistrements

Un fichier de zone comprend de nombreux enregistrements. Ici, un enregistrement est défini comme une correspondance unique entre une ressource et un nom. Les enregistrements peuvent être une correspondance entre un nom de domaine et une adresse IP, des ressources disponibles sous un domaine spécifique, ou des références vers des emplacements pour obtenir ces informations.

Le DNS en action

Jusqu'à présent, nous nous sommes familiarisés avec certains termes courants liés au DNS. Cependant, comment le système fonctionne-t-il réellement ? Le système peut sembler très simple à première vue. Néanmoins, entrer plus en détail révélera sa véritable complexité. Dans l'ensemble, le système DNS est important pour l'adoption généralisée d'Internet.

• Serveurs racines

Le DNS, à la base, fonctionne selon une hiérarchie. Au sommet du système se trouvent les “serveurs racines”. Ces serveurs sont sous le contrôle de diverses organisations. L'autorité de ces serveurs est déléguée par l'ICANN (Internet Corporation for Assigned Names and Numbers).

À l'heure actuelle, il y a environ 13 serveurs racines en service. En raison de la charge, cependant, chacun de ces serveurs possède un miroir. Il est important de noter que tous les serveurs miroirs partagent la même adresse IP que le serveur racine. Chaque fois qu'une requête est adressée au serveur racine, elle est redirigée vers le miroir le plus proche de ce serveur.

Quels sont les rôles des serveurs racines ? Ils fournissent des informations sur les domaines de premier niveau. Chaque fois qu'un serveur de noms de niveau inférieur ne parvient pas à résoudre une requête, elle est redirigée vers le serveur racine du domaine.

Cependant, le serveur racine ne connaît pas réellement l’emplacement du domaine. Il redirige uniquement la requête vers celui qui gérera le domaine de premier niveau spécifiquement demandé. Par exemple, si une requête est faite pour “ blog.cloudsigma.com”, le serveur racine ne l’aura pas dans ses enregistrements. Il cherchera dans ses fichiers de zone, mais il n’y aura aucun enregistrement pour cela. Au lieu de cela, il reconnaîtra le TLD “com” et redirigera l’entité requérante vers le serveur de noms gérant les adresses “com”.

• Serveurs TLD

Pour continuer avec notre exemple précédent, l’entité requérante va maintenant envoyer la requête à l’adresse IP (fournie par le serveur racine). Dans le cas de “ blog.cloudsigma.com”, le serveur de noms “com” recherchera ses enregistrements dans ses fichiers de zone.

Il n’y aura pas d’enregistrement correspondant à la requête. Cependant, il trouvera un enregistrement indiquant l’adresse IP du serveur de noms responsable de “ cloudsigma.com”.

• Serveur de noms de niveau domaine

À présent, l’entité requérante dispose de l’adresse IP du serveur de noms qui héberge réellement les informations concernant “ blog.cloudsigma.com”. Elle va maintenant envoyer une nouvelle requête au serveur, lui demandant de résoudre “www.cloudsigma.com”.

Comme précédemment, le serveur de noms vérifiera ses fichiers de zone et trouvera celui associé à “ cloudsigma.com”. À l’intérieur de ce fichier se trouvera une entrée pour l’hôte “www”. Cet enregistrement décrit où se trouve l’hôte. La réponse finale est ensuite relayée à l’entité requérante.

• Serveur de noms résolveur

Dans l’exemple, nous avons mentionné une entité requérante. Qu’est-ce que c’est ? Dans la plupart des cas, le demandeur sera un “serveur de noms résolveur”. C’est un serveur configuré pour poser des questions à d’autres serveurs. Il agit comme un serveur intermédiaire pour les utilisateurs. Il met en cache les résultats pour améliorer la vitesse.

Tout utilisateur aura généralement un ou deux serveurs de noms résolveurs configurés sur son système. En général, les serveurs de noms résolveurs sont proposés par le FAI ou d’autres organisations. Par exemple, Google propose des serveurs DNS résolveurs publics à interroger. Vous pouvez le configurer manuellement sur votre système.

Lors de la saisie d’une URL dans le navigateur web, celui-ci recherche l’emplacement de la ressource. Tout d’abord, la recherche est effectuée localement. Cela inclut le fichier “hosts” (et certains autres emplacements). S’il n’est pas trouvé, la requête est envoyée au serveur de noms résolveur. Après avoir reçu la requête, le serveur de noms résolveur recherche la réponse dans son cache. Si elle n’est pas trouvée, il suit alors les étapes mentionnées précédemment.

Les serveurs de noms résolveurs simplifient le processus de requête pour l’utilisateur final. Le client n’a qu’à demander aux serveurs de noms résolveurs l’emplacement d’une ressource. Le serveur de noms fera des recherches et renverra la réponse finale.

• Fichiers de zone

Nous avons déjà abordé les concepts de “fichiers de zone” et d’“enregistrements”. Eh bien, comment fonctionnent-ils ?

Les fichiers de zone font office de base de données pour les serveurs de noms, stockant les informations sur les domaines qu’ils connaissent. Tous les domaines qu’un serveur de noms connaît seront stockés dans son fichier de zone. Cependant, la plupart des requêtes arrivant à un serveur de noms ne sont pas résolues par le fichier de zone. Si la configuration du serveur permet de gérer les requêtes récursives (les serveurs de noms résolveurs, par exemple), il renverra alors la réponse. Sinon, il redirigera la partie requérante vers un autre endroit pour poursuivre la recherche.

Plus un serveur de noms héberge de fichiers de zone, plus ses réponses feront autorité. Les fichiers de zone décrivent une “zone” DNS (un sous-ensemble de l’ensemble du système de nommage DNS). Généralement, un fichier de zone contient les données de configuration d’un seul domaine. Il peut comporter de nombreux enregistrements définissant l’emplacement des ressources du domaine en question.

Le $ORIGIN paramètre d’une zone est égal au niveau d’autorité le plus élevé de la zone. Par exemple, un fichier de zone pour “ cloudsigma.com” aura son $ORIGIN comme “ cloudsigma.com”. La valeur du paramètre peut être stockée au début du fichier de zone ou dans la configuration du serveur DNS. Dans tous les cas, le paramètre décrit la zone pour laquelle le fichier fait autorité.

Le $TTL définit l'information de “time to live” du résultat qu'il fournit. Il peut être décrit comme un minuteur qu'un serveur de cache peut utiliser pour suivre la validité des réponses en cache. Si la valeur TTL expire, la réponse n'est plus valide et est rejetée.

• Types d'enregistrements

Les fichiers de zone se composent de nombreux enregistrements. Il existe différents types d'enregistrements. Ensuite, nous allons passer en revue certains des types d'enregistrements les plus courants (et obligatoires) :

Enregistrements SOA

L'enregistrement Start of Authority (SOA, en abrégé) est obligatoire dans tous les fichiers de zone. Il doit être le premier véritable enregistrement du fichier. Cependant, des entrées comme $ORIGIN ou $TTL sont autorisées à apparaître auparavant.

L'enregistrement SOA est l'un des types d'enregistrements les plus complexes. Sa structure ressemble à ceci :

Analysons-le en détail :

• • example.com : cette partie définit la racine de la zone. Dans cet exemple, le fichier de zone concerne le domaine “ example.com”. Parfois, la valeur peut être remplacée par @ (un espace réservé pour remplacer la valeur de $ORIGIN).

  • IN SOA : le terme “IN” signifie “internet”. Vous le trouverez dans de nombreux enregistrements. Le terme “SOA” indique qu'il s'agit d'un enregistrement SOA.

  • ns1.example.com : cette valeur contient le serveur de noms principal pour le domaine “ example.com”. Les serveurs de noms peuvent être principaux ou secondaires. S'il a été configuré avec un DNS dynamique, il doit y avoir un serveur “principal”. Si aucun DNS dynamique n'a été configuré, ce sera l'un des serveurs de noms principaux.

  • admin.example.com : l'adresse e-mail de l'administrateur de la zone va ici. Notez que le @ est remplacé par . ici. Si l'adresse e-mail d'origine contient un point, il est remplacé par un \. Par exemple, “ my.domain@example.com” deviendrait “ my\domain.example.com”.

  • 12083 : c'est le numéro de série du fichier de zone. Chaque fois que le fichier de zone est modifié, le numéro doit être mis à jour pour que le fichier se propage correctement. Les serveurs secondaires utilisent ce numéro de série pour vérifier si leurs propres fichiers de zone sont à jour.

  • 3h : cela représente l'intervalle de rafraîchissement de la zone. Les serveurs secondaires attendront cette durée avant de vérifier les mises à jour du fichier de zone.

  • 30m : cette valeur représente l'intervalle de tentative de la zone. Si un serveur secondaire ne parvient pas à se connecter au serveur principal une fois la période de rafraîchissement écoulée, il attendra cette durée avant d'interroger à nouveau le serveur principal.

  • 3w : cette valeur représente la période d'expiration. Si un serveur secondaire ne parvient pas à se connecter au serveur principal pendant cette durée, il cessera de renvoyer des réponses comme faisant “autorité”.

  • 1h : cette valeur représente la durée pendant laquelle le serveur de noms mettra en cache une erreur de nom s'il n'a pas été trouvé dans son fichier de zone.

Enregistrements A et AAAA

Ces enregistrements établissent une correspondance entre un hôte et une adresse IP. Ici, l'enregistrement “A” signifie la correspondance IPv4 avec l'hôte et AAAA la correspondance IPv6.

Voici la structure fondamentale des enregistrements A et AAAA :

Dans l'exemple d'enregistrement SOA, nous avons appelé le serveur de noms “ ns1.exampel.com”. Le serveur de noms relève du domaine “ example.com”. Voici à quoi ressemblerait son enregistrement A :

Notez que nous n’avons pas eu à fournir le nom complet. Avec seulement le nom d’hôte (sans le FQDN), le serveur DNS peut compléter le reste avec la valeur de $ORIGIN. Cependant, nous pouvons toujours utiliser le FQDN :

Voici comment définir le serveur web comme “www” :

Nous devrions également inclure le mappage vers le domaine de base. L'entrée ressemblerait à ceci :

Alternativement, nous pouvons utiliser le @ symbole pour désigner le domaine de base (au lieu de son nom complet) :

C’est une bonne pratique d’inclure une entrée générique qui permet de résoudre tout ce qui se trouve sous ce domaine et qui n’a pas été défini explicitement :

La même structure s'applique aux enregistrements AAAA. La seule différence réside dans les adresses IPv6.

Enregistrements CNAME

Les enregistrements CNAME agissent comme un alias pour le nom canonique du serveur (défini par un enregistrement A ou AAAA). Jetez un œil à l'exemple suivant :

Ici, nous avons utilisé “server1” comme alias pour définir le nom “www”. Notez que de tels raccourcis entraînent des coûts de performance car le serveur doit exécuter des requêtes supplémentaires pour obtenir la réponse finale. Selon le nombre de couches d'alias, cela peut facilement engendrer un coût de performance important. Cependant, il existe un cas spécifique qui bénéficie de l'aliasing CNAME, par exemple, la fourniture d'une ressource en dehors de la zone actuelle.

Enregistrements MX

Les enregistrements MX définissent les serveurs de messagerie pour le domaine. Ils aident l’e-mail à arriver correctement sur le serveur. Contrairement aux autres enregistrements, les enregistrements MX ne mappent pas un hôte à quelque chose car ils s’appliquent à l’ensemble de la zone. C’est pourquoi les enregistrements MX ressemblent à ceci :

Notez qu’il n’y a pas de nom d’hôte au début de l’entrée. Vous remarquerez également qu’il y a une valeur supplémentaire sur la ligne. Il s’agit du numéro de préférence qui aide à décider vers quel serveur envoyer le courrier (si plusieurs serveurs de messagerie sont définis). Plus le numéro est bas, plus la priorité est élevée.

Un enregistrement MX doit pointer vers un hôte défini par un enregistrement A ou AAAA (pas par un CNAME). En gardant cela à l’esprit, si deux serveurs de messagerie sont configurés, les enregistrements ressembleraient à ceci :

Dans cet exemple, à en juger par le numéro de préférence, “mail1” est le serveur préférable à “mail2”. Nous pouvons encore raccourcir le code en omettant le nom de domaine complet :

Enregistrements NS

Ces enregistrements définissent les serveurs de noms pour la zone concernée. Maintenant, la question évidente est : si le fichier de zone réside dans le serveur de noms, pourquoi nécessite-t-il une référence à lui-même ? Une réponse à cette question réside dans les multiples mécanismes de mise en cache du système DNS. Le fichier de zone peut en fait être une copie mise en cache sur d’autres serveurs.

Semblables aux enregistrements MX, les enregistrements NS s’appliquent à l’ensemble de la zone. Ainsi, ils n’ont pas d’hôte spécifique par défaut. Les entrées d’enregistrement NS ressembleront à ceci :

Il est recommandé de définir deux serveurs de noms au cas où l’un d’eux ne fonctionnerait pas correctement. De plus, la plupart des serveurs DNS rejetteront un fichier de zone s’il ne contient qu’un seul serveur de noms.

Vous devez également inclure le mappage des hôtes avec des enregistrements A ou AAAA :

Enregistrements PTR

Les enregistrements PTR sont l’inverse d’un enregistrement A ou AAAA classique. Ces enregistrements sont utilisés pour définir un nom associé à une adresse IP. Ces enregistrements ont une propriété unique car ils commencent à la .arpa racine et représentent le propriétaire de l’adresse IP. Ce sont les RIR (Regional Internet Registries) qui distribuent les adresses IP aux organisations et aux fournisseurs de services. Les RIR comprennent l’APNIC, l’AFRINIC, le LACNIC, le RIPE NCC et l’ARIN.

Par exemple, un enregistrement PTR pour 111.222.333.444 ressemblerait à quelque chose comme ceci :

Dans l’exemple d’enregistrement PTR suivant, jetez un œil au serveur DNS IPv6 de Google 2001:4860:4860::8888:

Nous pouvons utiliser l’outil dig avec le flag -x pour rechercher le nom DNS inversé d’une adresse IP. Par exemple, découvrez l’adresse IP DNS inversée de 8.8.4.4:

Les serveurs Internet utilisent les enregistrements PTR pour suivre les noms de domaine dans les entrées de journal, prendre des décisions éclairées en matière de gestion du spam et afficher des informations faciles à lire sur d’autres appareils.

Les serveurs de messagerie couramment utilisés recherchent l’enregistrement PTR de l’adresse IP à partir de laquelle l’e-mail a été envoyé. Si l’enregistrement PTR est vide, il y a de fortes chances que l’e-mail soit un spam (et soit donc rejeté). Notez que la correspondance entre le FQDN et le nom de domaine de l’enregistrement PTR n’est pas le problème. Le facteur important est de savoir si un enregistrement PTR valide est associé à un enregistrement A direct correspondant.

En général, les routeurs réseau sur Internet ont des enregistrements PTR correspondant à leur emplacement physique. Par exemple, “NYC” ou “CHI” sont des références valides pour les routeurs situés à New York et Chicago. Cette technique est utile lors de l’exécution d’un traceroute ou d’un MTR et de l’examen du chemin emprunté par les paquets.

Enregistrements CAA

Ces enregistrements spécifient les AC (Autorités de Certification) qui peuvent émettre des certificats SSL/TLS pour votre domaine. Depuis le 8 septembre 2017, toutes les AC sont tenues de vérifier les enregistrements CAA avant de délivrer un certificat. Si aucun enregistrement CAA n’existe, n’importe quelle AC peut délivrer un certificat. Sinon, seules les AC spécifiées sont autorisées à délivrer des certificats. Les enregistrements CAA peuvent être appliqués soit à des hôtes uniques, soit à un domaine entier.

Voici un exemple d’enregistrement CAA :

La partie spécifique au CAA de l’entrée est 0 issue "letsencrypt.org". Trois parties sont impliquées dans cette portion :

• Flags : Il s’agit d’une valeur entière indiquant comment une AC doit gérer les balises qu’elle ne comprend pas. Si la valeur du flag est définie sur 0, l’enregistrement sera ignoré. Si la valeur est 1, l’AC doit refuser de délivrer le certificat.
• Tags : Ce sont des chaînes de caractères indiquant le but d’un enregistrement CAA. À ce jour, les valeurs valides incluent issue (autorisant une AC à délivrer des certificats pour un domaine spécifique), issuewild (autorisant les certificats génériques), et iodef (définissant une URL où les AC signalent les violations de politique).
• Valeurs : Ce sont des chaînes de caractères associées à la balise de l’enregistrement. Si la balise est issue ou issuewild, la valeur sera généralement le domaine de l’AC à laquelle vous accordez l’autorisation. Si la balise est iodef, ce sera l’URL d’un formulaire de contact ou un lien mailto: pour un retour d’information par e-mail.

We can use the dig tool to fetch the CAA records:

Pour des informations plus détaillées sur les enregistrements CAA, consultez le RFC 6844.

Réflexions finales

Ce guide décrit diverses terminologies liées au DNS. Il décrit également comment tous les composants s'assemblent. Avec cet aperçu complet à l'esprit, vous devriez avoir une bonne compréhension du fonctionnement du système DNS. Bien que l'idée générale soit simple et facile à comprendre, les subtilités deviennent très vite complexes. Pour les administrateurs inexpérimentés, il peut être difficile d'appliquer ces concepts et stratégies.

Êtes-vous un client de CloudSigma ? Alors consultez la gestion et la mise à jour des enregistrements DNS inversés/PTR pour votre infrastructure CloudSigma.

Bonne informatique !