Par défaut, le sigle DNS fait référence au système de résolution global des noms de domaines de l'Internet. Ce dernier ne fournit que des adresses IP publiques.

Mais il est également possible de mettre en place un DNS dans un réseau privé. En effet, de même qu'il existe des adresses IP privées non routables sur l'Internet (cf. chap. R1‑III ), on peut définir des noms de domaines privés, c'est‑à‑dire qui ne peuvent pas être résolus par le DNS de l'Internet.

Les serveurs de noms forment une topologie en arbre qui est constituée d'une myriade de zones d'autorité hiérarchisées.

• Chaque zone d'autorité doit prendre en charge, de façon autonome, la résolution des noms du domaine qu'elle comprend – cette zone pouvant s'étendre sur plusieurs niveaux de sous‑domaines. On dit du ou des serveurs de noms qu'elle emploie qu'ils font autorité sur la zone (en anglais, on parle d'authoritative name servers).
Lorsqu'une zone d'autorité emploie plusieurs serveurs de noms, ils sont le plus souvent organisés en réplication d'un serveur maître.

• La hiérarchie des noms de domaines obéit au principe de délégation descendante, c'est‑à‑dire depuis la racine de l'arbre vers les feuilles.
Par exemple, en réponse à une requête en résolution du nom www.culture.gouv.fr :
• le serveur de la zone fr ne fera que retourner l'adresse IP d'un serveur de noms de la zone gouv.fr ;
• qui lui‑même retournera l'adresse IP du serveur de noms faisant autorité sur la zone culture.gouv.fr ;
• et c'est seulement ce dernier serveur de nom qui fournira l'adresse IP de la ressource demandée – typiquement celle du serveur web de la page d'index de ce domaine.
• La racine (unique) de l'arbre constituant l'ensemble de tous les noms de domaines publics forme une zone spéciale placée sous l'autorité de l'ICANN (cf. chap. R1‑I ). Ses serveurs de noms sont appelés les serveurs racine W du DNS (root name servers). Ils ne résolvent que les noms de domaines dits de premier niveau – tous individuellement constitués en zones distinctes, par exemple org, com, fr, etc.
Ainsi, en réponse à une requête en résolution du nom www.culture.gouv.fr, un serveur racine ne fera que retourner l'adresse IP d'un serveur de noms faisant autorité sur le domaine fr.

Dans la pratique, un enregistrement comporte d'autres informations techniques en plus des deux champs de la forme donnée ci‑dessus. Sa composition sera détaillée infra .

Un résolveur DNS assure un service crucial. En cas de dysfonctionnement, la navigation sur l'Internet devient quasi impossible : les hyperliens ne fonctionnant plus, il faudrait saisir les adresses IP des sites pour y accéder, ce qui est très laborieux.

C'est pourquoi, en règle générale, la configuration réseau de l'interface d'une machine comporte au moins deux adresses IP de résolveur DNS (cf. chap. R1‑III ). Elles déterminent respectivement ce qu'on appelle les résolveurs DNS primaire et secondaire, prévus pour coopérer dans un système de répartition de charge.

Par défaut, tout fournisseur d'accès à l'Internet met à disposition de ses abonnés (ou de tout autre internaute) deux adresses IP de résolveurs DNS publics, respectivement primaires et secondaires. Elles sont attribuées automatiquement aux interfaces des machines reliées à la box via son service DHCP.

Ce faisant, un fournisseur d'accès est en mesure de connaître toutes les requêtes en résolution de noms des internautes qui recourent à son service de résolveur DNS. Ces données ont une grande valeur commerciale, elles permettent de répondre aux attentes des organisations qui souhaite connaître les tendances d'actualité, l'évolution de la popularité de tel ou tel sujet, etc.

Même s'il est le plus souvent implémenté sur une machine dédiée (typiquement un serveur), un résolveur DNS est avant tout un logiciel qui met en œuvre algorithme de résolution de nom. Et ce dernier peut procéder de deux façons :

Il peut opérer en mode récursif lorsqu'il propage la requête en interrogeant un autre résolveur qu'il connaît par défaut pour obtenir une réponse.
C'est typiquement ce mode qui est adopté lorsque, sollicité par une application (typiquement, un navigateur), le système d'exploitation d'une machine ne trouve pas dans sa mémoire cache l'adresse correspondant à un nom de domaine requis. Il sollicite alors l'un des résolveurs DNS définis dans la configuration de l'interface réseau – typiquement, un résolveur du FAI – pour accomplir cette même tâche.

Il peut aussi opérer en mode itératif lorsqu'il obtient de la part d'un serveur de noms non pas l'adresse IP du nom de domaine à résoudre mais celle d'un autre serveur de noms, qu'il doit alors solliciter, et ce jusqu'à obtenir une réponse.
C'est typiquement ce mode qui est adopté lorsqu'un résolveur interroge un serveur de noms de la racine du DNS :
• ce dernier ne connaissant pas l'adresse IP du nom de domaine complet recherché, il retourne celle du serveur de noms de premier niveau (TLD) ;
• le résolveur doit alors réitérer sa requête auprès de ce serveur de noms, qui lui‑même peut renvoyer celle d'un serveur de noms de 2^e niveau, etc.

Cette stratégie présente deux avantages :

• diminuer le temps de réponse aux applications qui sont à l'origine des requête ;
• diminuer le nombre de requêtes adressées aux serveurs de noms.

Mais elle pourrait avoir l'inconvénient d'aboutir à une réponse erronée lorsqu'elle n'est plus à jour. C'est pourquoi la durée de vie des enregistrements en mémoire cache doit être judicieusement choisie.

Le format d'encodage sur 32 bits permet théoriquement de définir une valeur de durée de vie jusqu'à 136 ans (environ 4,3 × 10⁹ s). Mais en pratique :

• dans tous les cas, on ne dépasse pas 7 jours maximum (604 800 s) ;
• pour un domaine peu sollicité et doté d'un adressage stabilisé, par défaut, on peut prendre une valeur de 12 heures (43 200 s) ou 24 heures (86 400 s) ;
• sur un tel domaine, lorsque des changements d'adressage sont en cours, on aura tendance à choisir une valeur de l'ordre d'1 heure (3 600 s) ;
• les domaines très sollicités (moteurs de recherche, Wikipedia, etc.) qui ont recours à des dispositifs de répartition de charge W, on observe des valeurs beaucoup plus courtes, typiquement 5 minutes (300 s).

Ces composants logiciels permettent de considérablement accélérer le temps de réponse et diminuer la charge sur les résolveurs DNS publics. Et il faut savoir que lorsqu'une application sollicite le système pour accéder à une ressource par son nom de domaine :

• par défaut, et en l'absence de recours à un serveur proxy, c'est le fichier hosts qui est consulté en premier ; si une adresse IP y est associé au nom à résoudre, c'est cette réponse et elle seule qui est retournée à l'application ;
• dans la négative, c'est la mémoire cache DNS du système d'exploitation qui est ensuite consultée ; là encore, si une adresse IP correspondante y figure, elle est fournie à l'application requérante sans qu'aucun résolveur DNS ne soit sollicité.

Comme ces composants logiciels sont gérés par le système d'exploitation, un administrateur du poste peut les manipuler, contrairement à tout autre élément issu d'un résolveur public ou d'un serveur de noms. Ce qui donne quelques moyens rudimentaires pour orienter et filtrer les réponses aux requêtes en résolution de noms (cf. infra ).

Plus précisément :

• Un domaine enregistré est constitué d'un ensemble de machines répertorié par le DNS du réseau – chacune disposant d'une adresse IP susceptible d'être fournie lors une requête en résolution du nom de ce domaine traitée positivement par un serveur de nom de la zone d'autorité.
• Une ressource enregistrée est une machine répertoriée par le DNS du réseau, c'est‑à‑dire disposant d'une adresse IP et donnant accès à une ou plusieurs ressource du réseau (site web, etc.). On peut alors parler de nom d'hôte W (en anglais, hostname) au sens où cette machine est « hébergée » dans le réseau.

L'espace des noms de domaine (domain name space) forme un arbre :

• dont la racine est anonyme ; on la symbolise par un simple caractère . sachant qu'il est le plus souvent omis lors des saisies ;
• dont les nœuds de premier niveau W (top-level domain ou TLD) peuvent être :
• soit génériques (gTLD pour generic), c'est‑à‑dire chacun attribué à un domaine d'activité transversal, par exemple org pour les organisations à but non lucratif, com pour le commerce, etc. ;
• soit « géographiques » (ccTLD pour country code), c'est‑à‑dire chacun attribué à un pays ou un territoire, par exemple fr pour la France métropolitaine, mq pour l'île de la Martinique, uk pour le Royaume‑Uni, etc.
• dont les nœuds de deuxième niveau W forment des sous‑domaines à l'intérieur du domaine de premier niveau dont ils sont issus ; ils sont attribués à des organisations de toutes sortes (entreprises, administrations, associations, etc.) ; par exemple, wikipedia.org désigne le domaine qui réunit tous les sous‑domaines de l'encyclopédie en ligne ;
• dont les feuilles désignent des ressources enregistrées hébergées dans un domaine particulier ; par exemple, fr.wikipedia.org désigne la ou les machines qui donnent accès au site web de la page d'accueil en langue française de Wikipedia.

On dit d'un nom de domaine qu'il est pleinement qualifié W – fully qualified domain name, abrégé FQDN – s'il forme un chemin jusqu'à la racine incluse de l'arbre de l'espace de nom, marquée par un « . » final.

Ce point symbolisant la racine est nécessaire pour le bon déroulement des algorithmes de résolution de noms. Lorsqu'il est omis dans une requête en résolution de nom, il est en fait automatiquement rajouté par l'application ou le système d'exploitation.

L'enregistrement d'un alias d'un nom de domaine présente potentiellement plusieurs intérêts, en particulier :

• augmenter la visibilité d'un site par l'ajout de différents noms pour y accéder, notamment avec et sans le nom de sous‑domaine www (cf. infra ) ;
Exemple. Le nom de domaine www.lycee-ferry-versailles.fr est en fait un alias du nom de domaine enregistré lycee-ferry-versailles.fr qui est plus simple.
• assurer la transition d'hébergement d'un site qui soit robuste aux habitudes des internautes non informés de cette transition (l'ancien nom étant l'alias du nouveau nom durant toute la période de transition) ;
Exemple. Le nom de domaine www.neuf.fr est un alias de www.sfr.fr. En effet, l'opérateur 9 Télécom est un ancien FAI ayant fusionné avec SFR en 2008 W.
• simplifier l'espace des noms d'un sous‑domaine pour le rendre plus attractif, voire complètement différent du nom de domaine réellement utilisé.
Exemple. Le nom de domaine www.education.gouv.fr est un alias du nom de domaine enregistré cs4.wpc.alphacdn.net. Ce domaine est géré par la société américaine Verizon Trademark Services LLC qui agit en qualité d'hébergeur web pour le Ministère de l'éducation nationale français. Bien évidemment, ce nom de domaine « technique » est trop complexe pour les internautes, c'est pourquoi il est doté d'un alias beaucoup plus lisible.

De plus, un nom de domaine doit respecter les limites suivantes :

• chaque identifiant (label) ne doit pas dépasser 63 caractères ;
• un nom complet ne doit pas dépasser 253 caractères.

Si cet usage facilite l'identification du contenu des noms de domaine, il n'est pourtant pas obligatoire. Aujourd'hui, pour diminuer les erreurs d'adressage, il est fréquent d'attribuer deux noms à un même domaine, avec et sans sous‑domaine www et de renvoyer l'un sur l'autre.

Il faut savoir que :

• la racine et certains TLD génériques (int, arpa) sont placés sous l'autorité historique de l'IANA W – Internet assigned numbers authority – qui est un département de l'ICANN (cf. chap. R1‑I ) ;
• d'autres TLD génériques sont gérés par divers organismes, par exemple :
• org par le PIR W – public interest registry – qui est une association américaine à but non lucratif ;
• com par VeriSign W, une société américaine qui gère également deux serveurs racine ;
• les TLD géographiques sont le plus souvent placés sous l'autorité d'institutions des pays respectifs ou régions correspondant à ces domaines ; par exemple, le domaine fr… est géré par l'AFNIC.

• C'est donc le TLD manager qui détermine la politique d'enregistrement (conditions générales, limites tarifaires…).
• Quant au registraire, il se charge :
• d'instruire au demandeur les formalités administratives à accomplir ;
• de maintenir au niveau des serveurs de noms la base de donnée des enregistrements qu'il commercialise.
En règle générale, tous les fournisseurs d'accès à l'Internet et les hébergeurs de données assument des fonctions de registraires.

Cette association est en général enregistrée dans le fichier hosts du système d'exploitation (cf. supra  et infra ).

Il existe de nombreux types d'URL. Les plus courants sont ceux qui donnent accès à :

• des serveurs de pages web, via le protocole http ;
• des serveurs de fichiers, via le protocole ftp ;
• des serveurs de messagerie, via le protocole smtp…

Mais on peut aussi spécifier l'accès à une ressource locale (un fichier) sur la même machine que celle qui héberge l'application dans laquelle l'URL est saisie.

Le détail de ces 6 composantes peut être trouvé sur cette page web W. La combinatoire de toutes leurs valeurs possibles est immense. Toutefois, pour un étudiant dans le domaine des réseaux, il est surtout important d'en retenir les usages les plus courants, qui seront exposés ci‑après dans cette section.

Par ailleurs, on voit dans l'écriture d'une URL, il existe des caractères réservés car ce sont des séparateurs syntaxiques. Ils sont les suivants :
 !   #   $   &   '   (   )   *   +   ,   /   :   ;   =   ?   @   [   ] 
et, évidemment, ils sont à ne pas utiliser pour un autre usage que celui qui leur est dévolu.

Pour une description encore plus exhaustive, on peut évidemment consulter la RFC 3986  qui est consacrée à la syntaxe générique des URI. Sa rédaction a été dirigée par Tim Berners‑Lee W, également principal inventeur du langage HTML.

On peut trouver dans le lien supra la liste des noms de pages d'information qui sont valides dans tel ou tel navigateur.

Dans cette forme :

• le nom d'hôte doit être le nom de domaine enregistré hébergé par une machine hôte du réseau, typiquement un serveur web (cf. supra ) ;
• le chemin définit le chemin d'accès au fichier sur la machine hôte dans l'arbre des répertoires web qu'elle héberge.
Quel que soit le système d'exploitation, ce chemin est codé par une succession de segments concaténés les uns après les autres par le séparateur / – et non pas \ – sachant que :
• la racine est conventionnellement un segment vide, autrement dit le chemin commence toujours par le caractère / ;
• le dernier segment est le nom du fichier codant la page web ; par défaut, le nom doit être complet, c'est‑à‑dire codé avec son extension (mais il existe des solutions pour se passer de ce détail technique peu commode pour le grand public).

Une telle URL permet d'accéder à la page web non pas à son début mais directement au segment qui commence là où est identifié le fragment.

L'identificateur du fragment doit être déclaré dans une et une seule balise du code html de la page web, comme valeur de son attribut id.

La syntaxe d'une requête est celle d'une suite d'affectations, chacune de la forme  champ=valeur . Ces affectations sont concaténées l'une après l'autre avec les séparateurs & ou ;.

Sur un poste de travail, pour accéder à une page web stockée localement (ou même une image, un document .pdf, etc.), le schéma d'URL est file. Il doit être suivi du chemin absolu de la ressource dans l'arborescence du système de fichiers sur la machine.

Les raisons d'employer une redirection d'URL sont les mêmes que celles pour l'enregistrement d'un alias évoquées supra  : robustesse aux erreurs de saisie des utilisateurs, migration d'un site, simplification de noms, etc..

Mais une redirection d'URL offre plus de possibilités qu'un alias, puisqu'une URL ne se limite pas à un nom de domaine :

• elle précise le protocole, qui peut donc être changé – en particulier, pour basculer automatiquement de http à https ;
• elle cible aussi un chemin et peut inclure un fragment, une requête…

En général, on opère une réduction d'URL en concaténant :

• un nom de domaine abrégé ;
• une clef unique – la plus petite possible – générée à partir de l'URL initiale ou de la page web ciblée ;

le but étant de composer une URL suffisamment courte pour être facile à saisir (voire mémoriser).

De façon détaillée, et en rappel des explications précédentes :

• Le champ domain name est le nom de domaine pleinement qualifié – FQDN, cf. supra  – qui est le sujet de l'enregistrement.
C'est une chaîne de caractères conforme aux limites syntaxiques exposées supra .
• Le champ TTL – ou time‑to‑live, cf. supra  – exprime en secondes la durée de conservation de l'enregistrement dans la mémoire cache des résolveurs.
Comme on l'a vu supra , c'est un nombre entier non signé encodé sur 32 bits, avec des valeurs pouvant donc aller jusqu'à 136 ans.
• Le champ class indique le domaine général d'emploi de l'enregistrement ; sauf exceptions historiques, la classe IN — pour Internet – est la seule employée.
Plus précisément, il s'agit d'un nombre entier non signé encodé sur 16 bits (2 octets). En particulier, la valeur 0x0001 code la classe IN et les valeurs 0xFF00 à 0xFFFE sont réservées pour un usage privé (cf. la RFC 6895 , section 3.2).
• Le champ type indique la « nature » de la donnée enregistrée associée au nom de domaine. Il existe un très grand nombre de types (cf. cette liste W). Ceux les plus fréquemment employés sont :
• A pour une adresse IPv4 et AAAA pour une adresse IPv6 (4 lettres « A » car elle fait 4 fois la taille d'une adresse IPv4) ;
• NS pour le nom de domaine du serveur de nom (name server) ;
• CNAME pour le nom de domaine d'un alias W (canonical name) ;
• SOA pour les informations administratives de la zone d'autorité W (start of authority) ;
• MX pour un serveur de mail associés au nom de domaine W (mail exchange) – cf. chap. R2‑VII ).
Là encore, il s'agit d'un nombre entier non signé encodé sur 16 bits. Les valeurs 0x0001, 0x001C (28), 0x0002, 0x0005, 0x0006 et 0x000F codent respectivement les types A, AAAA, NS, CNAME, SOA et MX. Les valeurs 0xFF00 à 0xFFFE sont réservées pour un usage privé.
• Le champ RDlength (record data length) exprime la longueur en octets du champ variable Rdata. Purement technique, cette information n'est pas affichée par les commandes d'investigation sur les noms de domaine.
C'est aussi un nombre entier non signé encodé sur 16 bits.
• Le champ Rdata (record data) contient la donnée au associée au nom de domaine, qui est l'objet de l'enregistrement. C'est donc lui qui contient l'information essentielle de l'enregistrement.
Par exemple, si l'enregistrement est de type A, le champ Rdata contient l'adresse IPv4 associée au nom de domaine qui est le sujet de l'enregistrement (champ domain name).

De façon détaillée :

• Le champ domain name est nom de domaine pleinement qualifié – FQDN, cf. supra  – qui est justement l'objet de la requête.
• Le champ Qclass indique le domaine général d'emploi de la donnée recherchée ; comme le champ Class des enregistrements (cf. supra ), sauf exceptions, seule la classe IN – pour Internet – est aujourd'hui employée.
• Le champ Qtype (query type) indique la « nature » de la donnée demandée. Il doit correspondre à un type d'enregistrement reconnu d'enregistrement de ressource (cf. supra ).

La localisation du fichier hosts dépend bien évidemment du système de fichiers de la machine. Typiquement, il est accessible dans le répertoire :

• /etc sous Linux ;
• C:\System32\drivers\etc\ sous Windows.

Dans tous les cas, pour le modifier, il faut les droits d'administration. Cette précaution est essentielle pour protéger la machine contre toutes sortes de détournements malveillants.

Le fichier hosts peut remplir principalement 2 fonctions :

• définir pour la machine des noms de domaines privés, notamment le nom de domaine générique localhost ;
• implémenter un filtrage de noms de domaine indésirables.

En particulier, on trouve systématiquement par défaut dans le fichier hosts la définition du nom de domaine générique localhost, associée à l'adresse IPv4 de rebouclage (cf. chap. R1‑III ) :

127.0.0.1 localhost

Typiquement, on peut utiliser comme adresse IP de substitution :

• l'adresse réservée nulle – en IPv4, 0.0.0.0 ou tout simplement 0 (cf. chap. R1‑III ) ;
• n'importe quelle adresse de rebouclage – notamment 127.0.0.1 (cf. chap. R1‑III idem) ;
• l'adresse associée à une page web d'explication ou d'avertissement, à condition d'avoir mis en place un serveur web sur la machine disposant de cette adresse IP (pas forcément l'hôte local).

Comme tous les outils en ligne de commande, ceux du DNS :

• possèdent de nombreuses options, qu'il est possible de découvrir en affichant les options d'aide ou de manuel en ligne (cf. chap. S1‑III S) ;
• peuvent aussi être utilisés dans des fichiers de script pour automatiser les recherches et optimiser l'exploitation de leurs résultats.

La présentation ci‑après de ces outils reste très superficielle. Des liens sont proposés pour en approfondir la pratique.

La commande host W est un outil logiciel pour systèmes d'exploitation Unix et Linux, développé par l'ISC W (Internet systems consortium). Elle est en général pré‑installée, quelle que soit la distribution du système.

Par défaut, elle fournit des résultats de « premier niveau » sous forme synthétique, c'est‑à‑dire sans détails techniques.

La commande dig W – pour DNS information groper –  est une composante de la suite logicielle multiplateforme BIND (cf. infra ). Elle est en général pré‑installée dans les distributions Linux.

Plus puissante que la commande host, elle fournit ses résultats avec une présentation technique conforme à la composition d'un message DNS exposée supra . Elle est donc bien adaptée pour une exploitation automatisée où de multiples requêtes sont mise en œuvre par un script et leurs résultats analysés et exportés dans un ou plusieurs fichiers.

La commande nslookup W est l'outil logiciel le plus ancien de requêtes au DNS. Développé conjointement par l'ISC (Internet systems consortium) ainsi que les entreprises IBM (Industrial business machines) et Microsoft, il est multi‑plateforme et pré‑installé sur la plupart des systèmes d'exploitation.

Même si elle est parfois jugée comme étant redondante avec les autres outils sur les systèmes Linux, la commande nslookup possède des caractéristiques particulières qui rendent son utilisation « manuelle » très commode :

• elle possède un mode interactif, qui permet d'enchaîner rapidement des requêtes ;
• elle ne fait jamais appel à la mémoire cache du système d'exploitation, autrement dit elle interroge systématiquement l'un des résolveurs DNS définis dans la configuration de l'interface réseau ;
• elle adopte toujours une présentation conviviale des résultats pour l'utilisateur (user‑friendly display).

La commande whois W offre un service d'informations administratives relatives aux noms de domaines à leurs adresses IP associées. Ces données sont publiées par les RIR (cf. chap. R1‑III ) ou les TLD manager (cf. supra ) sur des serveurs dédiés. Elles sont rendues accessibles via un protocole nommé également whois et spécifié par la RFC 3912 .

En règle générale, la commande whois n'est pas pré‑installée sur les systèmes d'exploitation des postes de travail. Pour pouvoir l'utiliser, il faut donc procéder à son installation, ce qui nécessite bien entendu de disposer des droits d'administration.

• Sur une machine à système Linux (distribution Ubuntu ou similaire), il suffit de saisir la commande :

  
sudo apt install whois -y
  

• Sur un PC Windows, il faut :
• télécharger le fichier exécutable via une archive disponible sur cette page  ;
• en extraire le fichier whois.exe et le placer dans le dossier C:\Windows\System32.