Qu'est-ce que le DNS? Explication des concepts du système de noms de domaine, du serveur DNS et des adresses IP

introduction

À la fin de cet article, vous devriez avoir une meilleure compréhension de:

  1. Qu'est-ce que le DNS et ce qu'il fait
  2. Que font les serveurs DNS
  3. Fonctionnement des adresses IP (Internet Protocol) dans le contexte du DNS

Concepts importants

Il existe des modèles mentaux essentiels à connaître lors de l'apprentissage du DNS, des serveurs DNS et des adresses IP. Passer en revue ces concepts maintenant, avant de commencer à en apprendre davantage sur le DNS,

  • aider à comprendre tous les différents termes utilisés pour décrire un comportement qui s'inscrit dans ces modèles, et
  • aide à la rétention de la mémoire.

Les modèles mentaux vous donnent un cadre de référence lorsque les choses deviennent un peu bizarres et inconnues.

Alors jetons les bases.

  • Requête et réponse. C'est à ce moment que Thing 1 demande quelque chose à Thing 2 et Thing 2 répond à cette demande. Comme ça:
  • Relations de nœuds parent-enfant et graphiques qui ressemblent à ceci (mais plus compliqués).
  • Messages. Ce n'est pas une requête et une réponse car il n'y a pas de réponse. Dans le monde du DNS, le formatage et le contenu des messages varient en fonction de l'utilisation.
  • Relation client-serveur. En termes plus simples, un serveur est un logiciel ou un périphérique matériel qui fournit des fonctionnalités pour d’autres périphériques logiciels ou matériels, appelés «clients».

    Préparez-vous à de nombreuses discussions sur les serveurs. En fait, il y a beaucoup de serveurs qui entrent dans cette chose que nous appelons DNS, et comment nous, en tant qu'êtres humains, l'utilisons lorsque nous nous connectons à Internet.

Qu'est-ce que le DNS?

Le système de noms de domaine (DNS) mappe les noms de domaine lisibles par l'homme (dans les URL ou dans l'adresse e-mail) aux adresses IP. Par exemple, DNS traduit et mappe le domaine freecodecamp.org à l'adresse IP 104.26.2.33.

Pour vous aider à bien comprendre cette description, cette section détaille:

  • Contexte historique du développement du DNS - quels sont les problèmes et les adresses IP résolus?
  • Noms de domaine
  • Adresses IP

Contexte historique

En 1966, l'Advanced Research Projects Agency (ARPA), une agence gouvernementale américaine, a fondé un réseau informatique appelé ARPAnet. En termes simples, pensez à ARPAnet comme la première itération de ce que nous connaissons aujourd'hui comme Internet.

Les principaux objectifs d'ARPAnet comprenaient

"(1) fournir une communication fiable même en cas de panne partielle d'équipement ou de réseau, (2) pouvoir se connecter à différents types d'ordinateurs et de systèmes d'exploitation et (3) être un effort de coopération plutôt qu'un monopole contrôlé par un seul société. Afin de fournir une communication fiable en cas de panne d'équipement, ARPANET a été conçu de sorte qu'aucun point ou lien ne soit plus critique qu'un autre. Cela s'est accompagné de la création d'itinéraires redondants et de l'utilisation d'un réacheminement à la volée des données en cas de défaillance d'une partie du réseau. »

Les problèmes

DNS et TCP / IP ont été essentiels pour résoudre deux problèmes avec ARPAnet:

Pour ARPAnet, il y avait un emplacement unique (un fichier appelé HOSTS.TXT) qui contenait tout le mappage nom-adresse pour chaque hôte sur le réseau.

«HOSTS.TXT a été maintenu par le centre d'information réseau de SRI (surnommé« le NIC ») et distribué à partir d'un seul hôte, SRI-NIC. [*] Les administrateurs d'ARPAnet ont généralement envoyé leurs modifications par e-mail au NIC, et périodiquement envoyé par FTP au SRI- NIC et récupéré le fichier HOSTS.TXT actuel. Leurs modifications ont été compilées dans un nouveau fichier HOSTS.TXT une ou deux fois par semaine. »

Il y avait trois défis avec cette configuration:

  1. Trafic et charge - la distribution du fichier devenait trop difficile à gérer pour l'hôte responsable.
  2. Collisions de noms - chaque hôte devait avoir un nom unique et aucune autorité centralisée n'empêchait les utilisateurs du réseau d'ajouter un hôte avec un nom en conflit (non unique), «rompant ainsi l'ensemble du schéma».
  3. Cohérence - le fait de mettre à jour le fichier et de s'assurer que tous les hôtes avaient la version la plus à jour est devenu impossible ou du moins très difficile.

En substance, HOSTS.TX était un point de défaillance unique, donc l'ensemble du processus ici n'a pas évolué bien au-delà d'un certain nombre d'hôtes. ARPAnet avait besoin d'une solution décentralisée et évolutive. Le DNS était-il. La source

La communication d'hôte à hôte au sein du même réseau n'était pas suffisamment fiable. TCP / IP a aidé à résoudre ce problème.

  1. Le protocole TCP (Transmission Control Protocol) fournit des mesures d'assurance qualité pour le processus de transformation des messages (entre hôtes) en paquets. Le protocole TCP est orienté connexion, ce qui signifie qu'une connexion entre l'hôte source et l'hôte de destination doit être établie.
  2. Le protocole Internet (IP) définit la manière dont les messages (paquets) sont transportés entre l'hôte source et l'hôte de destination. Une adresse IP est un identifiant unique pour un chemin spécifique menant à un hôte sur un réseau.
  3. TCP et IP travaillent en étroite collaboration, c'est pourquoi ils sont généralement référencés comme «TCP / IP».
  4. Bien que je ne m'y plongerai pas dans cet article, TCP et le protocole UDP (User Datagram Protocol) sont utilisés dans la couche de transport de données du DNS. UDP est plus rapide, beaucoup moins fiable et ne nécessite aucune connexion; TCP est plus lent, beaucoup plus fiable, mais nécessite des connexions. Ils sont utilisés selon les besoins et appropriés dans le DNS; il va sans dire que l'inclusion de TCP dans APRAnet a été un ajout précieux à la couche de transport de données.

Au début des années 80, DNS et TCP / IP (et donc les adresses IP) étaient des procédures d'exploitation standard pour ARPAnet.

Cette histoire est très abrégée. Si vous souhaitez en savoir plus sur ces sujets, veuillez consulter la section Ressources à la fin de cet article.

Maintenant que nous avons un contexte historique, passons à en apprendre davantage sur les noms de domaine et les adresses IP.

Noms de domaine

Dans le contexte du DNS, un nom de domaine offre un moyen convivial de pointer vers des ressources non locales. Il peut s'agir d'un site Web, d'un système de messagerie, d'un serveur d'impression ou de tout autre serveur disponible sur Internet. Un nom de domaine peut être plus qu'un simple site Web!

«Le but des noms de domaine est de fournir un mécanisme pour nommer les ressources de telle sorte que les noms soient utilisables dans différents hôtes, réseaux, familles de protocoles, internets et organisations administratives.»

Un nom de domaine est beaucoup plus facile à mémoriser et à entrer dans un terminal ou un navigateur Internet qu'une adresse IP.

Un nom de domaine fait partie d'une URL (Uniform Resource Locator), mais les termes ne sont pas synonymes . Une URL est l'adresse Web complète d'une ressource, tandis que le nom de domaine est le nom d'un site Web et est un sous-composant de chaque URL.

Bien qu'il existe des distinctions techniques entre les URL et les noms de domaine, les navigateurs Web les traitent généralement de la même manière, vous accéderez donc au site Web si vous saisissez l'adresse Web complète ou simplement le nom de domaine.

Domaines de premier niveau et domaines de deuxième niveau

Il y a deux parties dans un domaine donné: le domaine de premier niveau (TLD) et le domaine de second niveau (SLD). Les parties d'un nom de domaine deviennent plus spécifiques lors du déplacement de la droite (fin) vers la gauche (début).

Cela peut être déroutant au début. Par exemple, regardons "freecodecamp.org"

  • URL: //www.freecodecamp.org
  • Nom de domaine: freecodecamp.com
  • TLD: org
  • SLD: freecodecamp

Au début d'ARPAnet, il y avait un nombre limité de domaines de premier niveau disponibles, y compris les domaines de code de pays com, edu, gov, org, arpa, mil et à 2 lettres. Ces TLD étaient initialement réservés aux institutions participant à l'ARPAnet, mais certains sont ensuite devenus disponibles sur les marchés commerciaux.

Aujourd'hui, il existe une richesse comparative de TLD disponibles, y compris net, aero, biz, coop, info, musée, nom et autres.

Les domaines de second niveau sont les domaines disponibles pour un achat individuel via les bureaux d'enregistrement de domaines (par exemple, Namecheap).

Adresses IP

Alors que les adresses IP sont liées au DNS dans leur fonction, le protocole Internet lui-même est techniquement distinct du DNS. J'ai déjà fourni un contexte historique pour cette distinction, alors je vais maintenant expliquer comment fonctionnent les adresses IP.

Une adresse IP, comme mentionné précédemment, est un identifiant unique pour un chemin spécifique qui mène à un hôte sur un réseau. Je voudrais faire référence à l'analogie d'un numéro de téléphone et d'un téléphone: un numéro de téléphone ne représente pas le téléphone lui-même, c'est juste un moyen de joindre la personne avec le téléphone.

Cette analogie est raisonnablement appropriée (du moins en surface) avec les adresses IP. Une adresse IP représente un point de terminaison, mais ce n'est pas le point de terminaison lui-même. Les attributions IP peuvent être fixes (permanentes) ou dynamiques (flexibles et peuvent être réaffectées).

Comme un nom de domaine, l'organisation des adresses IP suit une structure hiérarchique. Contrairement aux noms de domaine, les adresses IP sont plus spécifiques de gauche à droite. Voici un exemple IPv4 ci-dessous:

Le diagramme montre que 129.144 est la partie réseau et 50.56 est la partie hôte d'une adresse IPv4.
  • Réseau: le numéro unique attribué à votre réseau
  • Hôte: identifie l'hôte (machine) sur le réseau

Si une plus grande spécificité est nécessaire, les administrateurs réseau peuvent sous-réseau l'espace d'adressage et déléguer des numéros supplémentaires.

Combien d'adresses IP y a-t-il?

IPv4 était la toute première itération d'IP utilisée par ARPAnet en production. Déployée au début des années 80, c'est toujours la version IP la plus répandue. C'est un schéma 32 bits, et peut donc prendre en charge un peu plus de 4 milliards d'adresses.

Mais attendez, est-ce suffisant? Nan.

IPv6 a un schéma de 128 bits, ce qui lui permet de prendre en charge 340 adresses indécillions. Il offre également des améliorations de performances sur IPv4.

Exemple d'adresse IPv4:

  • 104.26.2.33 (freeCodeCamp)

Exemple d'adresse IPv6:

  • 2001: db8: a0b: 12f0 :: 1 (le format compressé et ne pointant pas vers freeCodeCamp)

Comment fonctionne le système de noms de domaine?

Donc, nous avons appris les noms de domaine! Nous avons appris les adresses IP! Maintenant, comment sont-ils liés au système de noms de domaine?

Tout d'abord, ils s'intègrent dans l'espace de noms.

L'espace de noms de domaine

Comme l'indiquent les domaines de niveau «supérieur» et de «deuxième» niveau du langage, l'espace de noms est basé sur une hiérarchie

«... avec la hiérarchie correspondant à peu près à la structure organisationnelle et les noms utilisant". " comme caractère pour marquer la limite entre les niveaux de hiérarchie. » La source.

Cet arbre graphique, avec la racine en haut, illustre le mieux la structure:

Décomposons cela, en commençant par le haut.

Le haut de ce graphique, marqué d'un «.» s'appelle la «racine».

«Les serveurs de noms faisant autorité qui desservent la zone racine DNS, communément appelés« serveurs racine », sont un réseau de centaines de serveurs dans de nombreux pays du monde. Ils sont configurés dans la zone racine DNS en tant que 13 autorités nommées. »

Le domaine racine a une étiquette de longueur nulle.

À partir de maintenant, chaque nœud (point) dans le graphique a une étiquette unique de 63 caractères maximum.

Le premier niveau à partir de la racine sont les TLD: com, org, edu et gov. Veuillez noter que ce graphique ne contient pas une liste complète des TLD.

Sous les TLD se trouvent les SLD, les domaines de second niveau. Les enfants de chaque nœud sont appelés «sous-domaines», qui sont toujours considérés comme faisant partie du domaine parent. Par exemple, dans freecodecamp.org, freecodecamp (le SLD) est un sous-domaine de org (le TLD).

Selon la hiérarchie du site Web, il peut y avoir des domaines de troisième, quatrième, cinquième niveau. Par exemple, dans hypothetical-subdomain.freecodecamp.org, hypothetical-subdomain est le domaine de troisième niveau et le sous-domaine de freecodecamp. Ainsi de suite et ainsi de suite, au moins jusqu'à 127 niveaux, ce qui est le maximum autorisé par DNS.

Qui gère l'espace de noms?

Ne serait-il pas fou d'essayer de laisser une personne ou une organisation administrer tout? Oui, ça le ferait. Surtout parce que l'un des principaux objectifs de conception du DNS était de promouvoir une gestion distribuée et décentralisée du système dans son ensemble.

J'aimerais pouvoir vous dire que les responsables sont appelés les «Namespace Kings», mais hélas.

Chaque domaine (ou sous-domaine) de l'espace de noms de domaine fait ou fait partie d'une zone , «une partie administrée de manière autonome de l'espace de noms». Ainsi, l'espace de noms est divisé en zones.

La responsabilité de ces zones est gérée par délégation et administration.

Le processus d'attribution de la responsabilité des sous-domaines à d'autres entités est appelé délégation.

Par exemple, le registre d'intérêt public administre le nom de domaine org, et depuis 2003. Le registre d'intérêt public peut déléguer la responsabilité à d'autres parties de gérer les sous-domaines de l'organisation, par exemple freecodecamp. Et puis, quiconque administre freecodecamp peut attribuer la responsabilité des sous-domaines de freecodecamp (par exemple, hypothethical-subdomain.freecodecamp.com) à une autre partie.

Si quelqu'un (une organisation, une équipe ou un individu) administre une zone, il administre le serveur de noms responsable de la zone.

Cela nous amène à l'un des concepts les plus fondamentaux du système de noms de domaine.

Serveurs de noms de domaine

«Les programmes qui stockent des informations sur l'espace de noms de domaine sont appelés serveurs de noms.»

C'est à ce stade que la réflexion sur une relation client-serveur, du moins au début, est utile. Les serveurs de noms de domaine sont le côté «serveur» de la relation client-serveur. Les serveurs de noms peuvent charger une, des centaines ou même des milliers de zones, mais ils ne chargent jamais tout l'espace de noms. Une fois qu'un serveur de noms a chargé la totalité d'une zone, on dit qu'il fait autorité pour cette zone.

Pour comprendre pourquoi les serveurs de noms fonctionnent comme ils le font, il est utile de comprendre la partie «client» de la relation.

Résolveurs

Dans DNS, le client (le demandeur d'informations) est appelé le «résolveur», ce qui peut sembler arriéré au début. Le serveur qui résout la demande ne s'appellerait-il pas le «résolveur»? Je le pensais aussi, mais ce n'est pas le cas. Mieux vaut simplement mémoriser cela et passer à autre chose.

Les résolveurs sont généralement inclus, de facto, dans la plupart des systèmes d'exploitation, de sorte que les applications installées sur le système d'exploitation n'ont pas à comprendre comment effectuer des requêtes DNS de bas niveau.

Les requêtes DNS et leurs réponses sont des types de messages DNS et ont leur propre protocole de transport de données (généralement UDP). Les résolveurs sont chargés d'aider les applications installées sur le système d'exploitation à traduire les demandes de données DNS en requêtes DNS.

En somme, les résolveurs sont responsables du conditionnement et de l'envoi des demandes de données. Une fois que le résolveur reçoit la réponse (le cas échéant), il la renvoie à l'application demandeuse d'origine dans un format consommable à l'application demandeuse.

Retour aux serveurs de noms

Maintenant que nous sommes un peu plus familiers avec le côté client de la relation, nous devons comprendre comment les serveurs de noms de domaine répondent aux requêtes du résolveur.

Les serveurs de noms répondent aux requêtes DNS par résolution . La résolution est le processus par lequel les serveurs de noms trouvent les fichiers de données dans l'espace de noms. Selon le type de requête, les serveurs de noms répondent différemment aux différentes requêtes, mais l'objectif final est la résolution.

Types de requêtes

Type de requête? Oui, il existe plusieurs types de requêtes DNS. Mais d'abord, que contient généralement une requête DNS? C'est une demande d'informations, spécifiquement pour l'adresse IP associée à un nom de domaine.

  • Récursif : les requêtes récursives permettent à la requête d'être référencée sur plusieurs serveurs de noms à résoudre. Si le premier serveur de noms interrogé n'a pas les données souhaitées, alors ce serveur de noms envoie la requête au serveur de noms suivant le plus approprié, jusqu'à ce que le serveur de noms avec les fichiers de données souhaités soit trouvé et envoie une réponse au résolveur.
  • Itérative : les requêtes itératives nécessitent que le serveur de noms interrogé réponde soit avec les données souhaitées, soit avec une erreur. La réponse peut contenir l'adresse IP du serveur de noms le plus approprié pour envoyer la demande au suivant; le résolveur peut alors envoyer une autre requête à ce serveur de noms plus approprié.

Au cas où vous en auriez besoin, vous pouvez également demander le nom de domaine, si tout ce que vous avez est l'adresse IP. C'est ce qu'on appelle une recherche DNS inversée.

Une fois que la requête atteint un serveur de noms contenant les fichiers de données souhaités, la requête peut être résolue. Les serveurs de noms ont un certain nombre de fichiers de données qui leur sont associés, dont tous ou certains peuvent être utilisés pour résoudre la requête.

Enregistrements de ressources (RR)

Ce sont les fichiers de données dans l'espace de noms de domaine. Ces fichiers de données ont des formats et des contenus spécifiques.

Les RR les plus courants:

  • Un record: si vous n'avez entendu parler d'aucun autre RR à l'exception de celui-ci, cela aurait du sens. C'est probablement le RR le plus connu et contient l'adresse IP du domaine donné.
  • Enregistrement CNAME: si vous n'avez entendu parler d'aucun autre RR à l'exception de celui-ci et de l'enregistrement A, cela aurait également du sens. Le «C» signifie «canonique», et est utilisé à la place d'un enregistrement A, pour attribuer un alias à un domaine.
  • Enregistrement SOA: cet enregistrement contient des informations administratives sur celui-ci, y compris l'adresse e-mail de l'administrateur. Astuce: si vous administrez une zone, assurez-vous qu'il y a une adresse e-mail valide ici, afin que les gens puissent vous contacter si nécessaire.
  • Les autres types d'enregistrements de ressources (RR) importants sont PR, NS, SRV et MX. Lisez à leur sujet ici.

Mise en cache et durée de vie (TTL)

Lorsque le serveur de noms local reçoit une réponse d'une requête, il met en cache ces données (les stocke en mémoire), donc la prochaine fois qu'il reçoit la même requête, il peut simplement répondre directement à la requête plutôt que de passer par le processus de résolution original et plus long.

Mais une fois que ces informations sont mises en cache, elles sont à la fois statiques et isolées, et risquent donc de devenir obsolètes. Par conséquent, les enregistrements de ressources ont tous ce qu'on appelle une valeur de durée de vie (TTL), qui dicte la durée de mise en cache des données. Lorsque ce délai est écoulé (atteint zéro), le serveur de noms supprime l'enregistrement.

Remarque importante: TTL ne s'applique pas aux serveurs de noms faisant autorité pour la zone qui contient l'enregistrement de ressource. Cela s'applique uniquement au serveur de noms qui a mis en cache cet enregistrement de ressource.

Une journée dans la vie d'une requête

Nous avons couvert beaucoup de terrain dans cet article, et il a été lourd sur les concepts. Pour lier tout cela et le rendre réel, voici un jour (jour figuratif) dans la vie d'une requête.

Alors pourquoi ai-je besoin de savoir tout cela?

Il y a tellement de raisons de se familiariser avec les concepts liés au DNS et aux adresses IP.

  • Premièrement, c'est une épine dorsale d'Internet, ce que beaucoup d'entre nous utilisent, développons des sentiments pour (amour / haine / vous-nommez) et tenons pour acquis chaque jour. Il est important de se familiariser avec les structures qui nous permettent d'accomplir de grandes choses aujourd'hui avec la technologie et Internet aujourd'hui.
  • Des gens incroyablement intelligents ont passé des décennies de leur vie à construire ce truc! Reconnaissons et apprécions leurs contributions.
  • Maintenant que je me suis débarrassé de tout cela, il est important de se familiariser avec les concepts DNS au cas où vous seriez responsable de tout ce qui concerne l'infrastructure de votre entreprise ou de votre équipe ou de votre propre entreprise. Avoir un cadre de référence lorsque des problèmes importants surgissent vous permet d'agir beaucoup plus rapidement et de trouver des solutions beaucoup plus tôt.

Conclusion

À ce stade, vous devez comprendre ce qu'est le DNS et ce qu'est un serveur de noms, ainsi que vous familiariser avec les concepts techniques relatifs aux adresses IP.

De nombreux livres ont été écrits et plongent plus profondément dans le monde fascinant du DNS, et il y a tellement plus à apprendre. Les sujets qui n'étaient pas inclus dans cet article mais qui font partie du DNS ou sont très liés incluent:

  • Implémentations de serveurs de noms
  • Expéditeur
  • (En savoir plus) étiquettes de nœuds
  • Relations de serveur de noms primaire et secondaire
  • Algorithmes de retransmission
  • L'équilibrage de charge
  • De plus, d'autres sujets plus généraux sur le fonctionnement d'Internet, tels que:
  • Internet
  • HTTP
  • FTP
  • Couches de protocole de communication: couche liaison, couche IP, couche transport, couche Internet, etc.

Pour ceux d'entre vous qui lisez encore etvoulez en savoir plus sur le DNS, je recommande avant tout «DNS and BIND, 5e éd.», écrit par Cricket Liu et publié par O'Reilly Media. C'est inestimable.

J'encourage également tout le monde à fouiller dans la demande de commentaires originale (RFC) ci-dessous. Non seulement il y a des points pour lire les sources primaires, mais ce sont aussi des documents exceptionnellement bien organisés et compréhensibles, c'est pourquoi je les ai cités dans cet article.

Ressources

  1. RFC 1034: NOMS DE DOMAINE - CONCEPTS ET FACILITÉS
  2. RFC 1035: NOMS DE DOMAINE - IMPLÉMENTATION ET SPÉCIFICATION
  3. RFC 1122: Exigences pour les hôtes Internet - Couches de communication
  4. En savoir plus sur les objectifs de conception DNS, de Connected: An Internet Encyclopedia
  5. Comment Internet est né de l'ARPAnet à l'interprète, de la conversation
  6. Cours vidéo d'apprentissage sur le DNS, par Cricket Liu, de O'Reilly Media

Un peu de moi

Je suis Chloe Tucker, artiste et développeur à Portland, Oregon. En tant qu'ancienne éducatrice, je recherche continuellement l'intersection entre l'apprentissage et l'enseignement, ou la technologie et l'art. Contactez-moi sur Twitter @_chloetucker et consultez mon site Web à chloe.dev.