Le What is DNS? | How DNS works | Cloudflare (système de nom de domaine) ou DNS est un service informatique distribué qui associe les noms de domaine Internet avec leurs adresses IP ou d'autres types d'enregistrements. En fournissant dès les premières années d'Internet, autour de 1985, un service distribué de résolution de noms, le DNS est un composant essentiel du développement du réseau informatique.

À la demande de l'Agence américaine pour les projets de recherche avancée de défense (DARPA), Jon Postel et Paul Mockapetris conçoivent le DNS et en rédigent la première implémentation en 1983.

Rôle du DNS vignette|La structure du Domain Name System. Les équipements (ou hôtes) connectés à un réseau IP, comme Internet, possèdent une adresse IP qui les identifie sur le réseau. Ces adresses sont numériques afin de faciliter leur traitement par les machines. En IPv4, elles sont représentées sous la forme « - - - . - - - . - - - . - - - », où chaque groupe de trois tirets est substituable par un nombre entre 0 et 255 (en représentation décimale). En IPv6, les adresses sont représentées sous la forme « .... : .... : .... : .... : .... : .... : .... : .... », où chaque groupe de quatre points est substituable par une valeur hexadécimale de 0000 à FFFF.

Pour faciliter l'accès aux hôtes sur un réseau IP, un mécanisme a été mis en place pour associer un nom à une adresse IP. Ce nom, plus simple à retenir qu'une suite de chiffres, est appelé « nom de domaine ». Résoudre un nom de domaine consiste à trouver l'adresse IP qui lui est associée.

En plus des adresses IP, des informations complémentaires peuvent être associées aux noms de domaine comme des enregistrements dans le contexte de la lutte contre le spam (SPF), RRSIG pour la sécurité des informations du DNS (DNSSEC) ou NAPTR pour associer des numéros de téléphone à des adresses e-mail (ENUM).

Histoire

Avant le DNS, la résolution d'un nom sur Internet devait se faire grâce à un fichier texte appelé HOSTS.TXT () maintenu par le NIC du Stanford Research Institute et copié sur chaque ordinateur du réseau par transfert de fichier. En 1982, ce système centralisé montre ses limites et plusieurs propositions de remplacement voient le jour, parmi lesquelles le système distribué Grapevine de Xerox et IEN 116IEN 116 Internet Name Server, Jon Postel 1979. Le premier (Grapevine) est jugé trop compliqué tandis que le second (IEN 116) est insuffisantDevelopment of the Domain Name System, Paul Mockapetris, Kevin Dunlap, Sigcomm 1988. C’est finalement l’équipe dirigée par Elizabeth Feinler au NIC qui définira le Domain Name System afin de gérer la croissance de l'internet en déléguant la gestion des noms de domaine à des serveurs de noms distribués. Paul Mockapetris publie la conception du système dans les et en 1983. La norme correspondante est publiée dans les et en 1987. En 1987, le fichier HOSTS.TXT contenait entrées, tandis que hôtes étaient définis dans le DNS.

Un système hiérarchique et distribué vignette|400px|Hiérarchie du DNS. vignette|400px|Résolution itérative d'un nom dans le DNS par un serveur DNS (étapes 2 à 7) et réponse (étape 8) à la suite de l'interrogation récursive (étape 1) effectuée par un client () DNS. (remarque : le serveur DNS récursif est dit récursif car il accepte ce type de requêtes mais il effectue des requêtes itératives.).

Hiérarchie du DNS

Le système des noms de domaine consiste en une hiérarchie dont le sommet est appelé la racine. On représente cette dernière par un point. Dans un domaine, on peut créer un ou plusieurs sous-domaines ainsi qu'une délégation pour ceux-ci, c'est-à-dire une indication que les informations relatives à ce sous-domaine sont enregistrées sur un autre serveur. Ces sous-domaines peuvent à leur tour déléguer des sous-domaines vers d'autres serveurs.

Tous les sous-domaines ne sont pas nécessairement délégués. Les délégations créent des zones, c'est-à-dire des ensembles de domaines et leurs sous-domaines non délégués qui sont configurés sur un serveur déterminé. Les zones sont souvent confondues avec les domaines.

Les domaines se trouvant immédiatement sous la racine sont appelés domaine de premier niveau (, TLD). Les noms de domaines ne correspondant pas à une extension de pays sont appelés des domaines génériques (gTLD), par exemple .org ou .com. S'ils correspondent à des codes de pays (fr, be, ch, etc.), ce sont des domaines de premier niveau national, aussi appelés ccTLD de l'anglais .

On représente un nom de domaine en indiquant les domaines successifs séparés par un point, les noms de domaines supérieurs se trouvant à droite. Par exemple, le domaine org. est un TLD, sous-domaine de la racine. Le domaine wikipedia.org. est un sous-domaine de .org. Cette délégation est accomplie en indiquant la liste des serveurs DNS associée au sous-domaine dans le domaine de niveau supérieur.

Les noms de domaines sont donc résolus en parcourant la hiérarchie depuis le sommet et en suivant les délégations successives, c'est-à-dire en parcourant le nom de domaine de droite à gauche.

Pour qu'il fonctionne normalement, un nom de domaine doit avoir fait l'objet d'une délégation correcte dans le domaine de niveau supérieur.

Résolution du nom par un hôte Les hôtes (ordinateurs des utilisateurs finaux) n'ont qu'une connaissance limitée du système des noms de domaine. Quand ils doivent résoudre un nom, ils s'adressent à un ou plusieurs serveurs de noms dits récursifs (ou résolveur) ou bien ils recherchent l'information dans les caches, comme ceux des navigateurs ou bien ceux des résolveurs eux-mêmes.

Il y a deux types de serveurs DNS: les résolveurs (aussi appelés récursifs, bien qu'ils travaillent de manière itérative) et les serveurs faisant autorité. Les serveurs DNS récursifs ne font qu'interroger les serveurs faisant autorité. Les serveurs faisant autorité détiennent les informations DNS sur les domaines sur lesquels ils ont autorité.vignette|alt=serveurs faisant autorité|Serveurs faisant autorité.

Les serveurs récursifs vont parcourir la hiérarchie DNS et faire suivre la requête à un ou plusieurs autres serveurs de noms ayant autorité pour fournir une réponse. Les adresses IP de ces serveurs récursifs sont souvent obtenues par l'utilisateur final via DHCP ou encore configurés en dur sur la machine hôte de l'utilisateur. Les fournisseurs d'accès à Internet mettent à disposition de leurs clients ces serveurs récursifs. Il existe également des serveurs récursifs publics comme ceux de Cloudflare, Yandex.DNS, Google Public DNS, OpenNIC ou FDN.

Quand l'ordinateur d'un utilisateur a besoin de charger une page internet de fr.wikipedia.org, il s'adresse d'abord à un serveur récursif pour trouver l'adresse IP (ie l'adresse numérique) de fr.wikipedia.org. Pour trouver l'adresse IP de fr.wikipedia.org, le serveur DNS récursif démarre un processus itératif pour consulter la hiérarchie DNS: Ce serveur demande à des serveurs DNS ayant autorité appelés serveurs racine quels serveurs ont autorité pour la zone org. Parmi ceux fournis dans la réponse, le serveur récursif va en choisir un pour lui demander quels serveurs ont autorité pour la zone wikipedia.org. C'est un de ces derniers qui pourra lui donner l'adresse IP de fr.wikipedia.org. S'il se trouve qu'un serveur ne répond pas, un autre serveur de la liste sera consulté.

Pour optimiser les requêtes ultérieures, les serveurs DNS récursifs font aussi office de DNS cache : ils gardent en mémoire (cache) la réponse d'une résolution de nom afin de ne pas effectuer ce processus à nouveau ultérieurement. Cette information est conservée pendant une période nommée Time to live et associée à chaque nom de domaine. Il existe aussi un cache au niveau du navigateur de l'utilisateur et eventuellement de son système d'exploitation.

Un nom de domaine peut être défini, à l'identique, dans plusieurs serveurs DNS ayant autorité. Généralement, les noms de domaines en utilisent au moins deux : un primaire et un secondaire. Il peut y avoir plusieurs serveurs secondaires.

L'ensemble des serveurs primaires et secondaires font autorité pour un domaine, c'est-à-dire que la réponse ne fait pas appel à un autre serveur ou à un cache. Les serveurs récursifs fournissent des réponses qui ne sont pas nécessairement à jour, à cause du cache mis en place. On parle alors de réponse ne faisant pas autorité ().

Cette architecture garantit au réseau Internet une certaine continuité dans la résolution des noms. Quand un serveur DNS tombe en panne, le bon fonctionnement de la résolution de nom n'est pas remis en cause dans la mesure où des serveurs secondaires sont disponibles.

Résolution inverse Pour trouver le nom de domaine associé à une adresse IP, on utilise un principe semblable. Dans un nom de domaine, la partie la plus générale est à droite : org dans fr.wikipedia.org, le mécanisme de résolution parcourt donc le nom de domaine de droite à gauche. Dans une adresse IP V4, c'est le contraire : 213 est la partie la plus générale de 213.228.0.42. Pour conserver une logique cohérente, on inverse l'ordre des quatre termes de l'adresse et on la concatène au pseudo domaine in-addr.arpa. Ainsi, pour trouver le nom de domaine de l'adresse IP 91.198.174.2, on résout 2.174.198.91.in-addr.arpa.

La déclaration inverse est importante sur les adresses IP publiques Internet puisque l'absence d'une résolution inverse est considérée comme une erreur opérationnelle () qui peut entraîner le refus d'accès à un service. Par exemple, un serveur de messagerie électronique se présentant en envoi avec une adresse IP n'ayant pas de résolution inverse (PTR) a de grandes chances de se voir refuser, par l'hôte distant, la transmission du courrier (message de refus de type : ).

De plus, cette résolution inverse est importante dans le cadre de la réalisation de diagnostics réseaux car c'est elle qui permet de rendre les résultats de la commande traceroute humainement exploitables. Les dénominations des noms d'hôtes inverses sont souvent des composites de sous-domaines de localisation (ville, région, pays) et de domaines explicites indiquant le fournisseur d'accès Internet traversé comme francetelecom.net (- - - -.nctou202.Toulouse.francetelecom.net) et opentransit.net (- - - -.Aubervilliers.opentransit.net) pour France Télécom, ou encore proxad.net (- - - -.intf.routers.proxad.net) pour Free.

Une adresse IP peut être associée à différents noms de domaine via l'enregistrement de plusieurs entrées PTR dans le sous-domaine .arpa consacré à cette adresse (in-addr.arpa. pour IPv4 et ip6.arpa. pour IPv6). L'utilisation d'enregistrements PTR multiples pour une même adresse IP est éventuellement présente dans le cadre de l'hébergement virtuel de multiples domaines web derrière la même adresse IP mais n'est pas recommandée dans la mesure où le nombre des champs PTR à renvoyer peut faire dépasser à la réponse la taille des paquets UDP de réponse et entraîner l'utilisation du protocole TCP (plus coûteux en ressources) pour envoyer la réponse à la requête DNSVoir la section du draft .

Résolution inverse CIDR Les délégations des zones inverses se font sur une frontière d'octet, ce qui fonctionne quand les blocs d'adresses sont distribués de façon classful mais pose des problèmes quand les blocs assignés sont de taille quelconque.

Par exemple, si deux clients A et B disposent chacun des blocs 192.168.0.0/25 et 192.168.0.128/25, il n'est pas possible de déléguer 0.168.192.in-addr.arpa. au premier pour qu'il puisse définir les PTR correspondant à ses hôtes, car cela empêcherait le second de faire de même.

La a défini une approche pour traiter ce problème, elle consiste à faire usage de domaines intermédiaires et de CNAME.

$ORIGIN 0.168.192.in-addr.arpa. 0/25 NS ns.clientA.fr. 128/25 NS ns.clientB.fr.

0 CNAME 0.0/25.0.168.192.in-addr.arpa. 1 CNAME 1.0/25.0.168.192.in-addr.arpa. ... 127 CNAME 127.0/25.0.168.192.in-addr.arpa. 128 CNAME 128.128/25.0.168.192.in-addr.arpa. ...