Introduction au DNS. Les noms de domaine s'écrivent de la gauche vers la droite, en remontant vers la racine et sont séparés par un "." (point).

Transcription

1 Introduction au DNS Le principe du DNS (Domain Name System) Toutes les requêtes de service que nous effectuons sur le réseau doivent en finalité aboutir sur l'adresse IP du serveur qui fournit ces services. L'utilisation de ces adresses IP n'étant pas intuitives pour les êtres humains, nous préférons utiliser des noms plus parlant comme " On les appelle des noms "complètement qualifiés" (FQDN pour "Fully Qualified Domain Name") car ils sont composés du nom de machine (ici "www") et du nom de "domaine" (ici "tuxnet.org"). Les FQDN que nous utilisons doivent donc être "résolus" en adresses IP pour effectivement arriver au bon serveur. Nous disposons de 2 manières différentes de résoudre ces noms : Résolution dans le fichier /etc/hosts A l'origine d'internet, cette résolution se faisait dans un fichier texte qui était recopié régulièrement sur chaque machine. Ce fichier sous Linux, s'appelle /etc/hosts et permet toujours de résoudre des noms. On y retrouve généralement les entrées suivantes : localhost cette ligne résout le nom court (hostname) "localhost" vers l'adresse www cette ligne résout le FQDN " et le hostname "www" vers l'adresse Remarque : l'entièreté de la classe d'adresse /8 est réservée à l'interface de bouclage (loopback). Cette interface n'est pas "physique" et sert à tester le comportement de TCP/IP et des applications même en l'absence d'interface physique. Il est déconseillé de supprimer ces lignes dans /etc/hosts sous peine de ralentir fortement les applications et le système. Résolution par le Domain Name System Le nombre croissant de machines connectées à Internet a obligé les responsables à imaginer une organisation décentralisée, composée de serveurs ayant chacun la responsabilité de résoudre une partie des noms répartis sur Internet. Etant donné qu'il est indispensable de pouvoir identifier sans ambiguïté le nom de chaque machine, le système DNS utilise une arborescence pour organiser tous les noms de manière unique. Le point le plus haut de cette arborescence s'appelle la "racine" et aucun caractère particulier ne la désigne. Chaque niveau de cette arborescence est appelé "noeud" et reçoit un nom, pour pouvoir le distinguer des autres noeuds de même niveau. Quelques caractéristiques des noeuds : - le noeud le plus haut s'appelle la "racine" et n'a pas de nom (chaîne "nulle") - les autres noeuds ont une longueur maximum de 63 caractères - il ne peut pas y avoir deux noms identiques pour un même niveau - chaque noeud est en fait un "DOMAINE" dont le nom est composé par la concaténation de tous les domaines situés sur le chemin vers la racine. Les noms de domaine s'écrivent de la gauche vers la droite, en remontant vers la racine et sont séparés par un "." (point). tuxnet.org "tuxnet" est un sous-domaine de "org", lui-même sous-domaine de la racine Introduction au DNS : Philippe WAUTERS (octobre 2006) - page 1

2 Les TLD (Top Level Domains). Les domaines situés directement en dessous de la racine sont appelés des Top Level Domains. On retrouve principalement des TLD génériques (type d'organisation) et des TLD géographiques (pays, régions, continents). Voici quelques "TLD" courants :.biz réservé pour le monde des "affaires" (business).com réservé pour les organismes commerciaux (commercial).mobi réservé pour les fournisseurs de services pour GSM (mobiles).net réservé pour les membres de réseaux informatiques.org réservé pour les organisations non commerciales.pro réservé à certains professionnels (médecins, avocats...).gov.edu.mil.int.be.fr.nl.uk.de.lu.eu réservé pour le gouvernement américain réservé pour les institutions scolaires américaines du niveau supérieur réservé pour l'armée américaine réservé pour les organismes internationaux réservé pour la Belgique réservé pour la France réservé pour les Pays-Bas réservé pour le Royaume-Uni réservé pour l'allemagne réservé pour le Luxembourg réservé pour l'europe Remarque : "DNS.be" est par exemple responsable de l'octroi des noms de domaine ".be". Chaque organisme responsable d'un TLD peut exiger le respect de règles particulières pour l'octroi d'un nom de domaine. Le fait de réserver un nom de domaine "géographique" ne veut par contre pas dire que les serveurs gérant ce domaine doivent se trouver effectivement à cet endroit. Le domaine "in-addr.arpa" Certaines applications nécessitent de pouvoir résoudre les adresses en noms (résolution inverse). Par exemple, un fichier d'audit (log file) sera plus facilement lisible par un administrateur si le hostname ou le FQDN d'une machine est indiqué, plutôt que son adresse IP. Cette résolution inverse est assurée par un domaine spécial appelé "in-addr.arpa". Chaque sous-domaine correspondra ici à un des octets d'une adresse IP en version 4. Imaginons que l'hôte " corresponde à l'adresse IP " ". Chaque niveau de noeud correspond donc ici à toutes les valeurs possibles pour un des octets (de 0 à 255). Dans notre exemple, la résolution passera par les domaines suivants : arpa TLD spécifique au réseau "ARPANET" (précurseur d'internet) in-addr domaine s'occupant de toutes les résolutions d'adresses en noms 191 domaine s'occupant de tous les hôtes dont le premier octet est domaine s'occupant de tous les hôtes dont le deuxième octet est domaine s'occupant de tous les hôtes dont le troisième octet est 80 4 domaine s'occupant du dernier octet et pointant vers l'hôte Remarque : notez que les adresses IP spécifiées dans le domaine "in-addr.arpa" s'écrivent dans l'ordre inverse. Dans notre exemple, le sous-domaine " in-addr.arpa" permettra de trouver le nom d'hôte " Introduction au DNS : Philippe WAUTERS (octobre 2006) - page 2

3 Domaines et zones L'entièreté de la base de données du DNS, c.-à-d. la résolution de toutes les machines de tous les domaines disponibles, ne se trouve donc pas sur une unique machine. A la place, la responsabilité de portions de l'arborescence est octroyée à des serveurs différents. Alors qu'un "domaine" correspond à un point de l'arborescence et son contenu (les sous-domaines), une zone correspond à la partie de cette arborescence qui est déléguée à un serveur DNS particulier. Imaginons le "domaine" tuxnet.org", organisé en 3 sous-domaines : belgium.tuxnet.org luxemburg.tuxnet.org france.tuxnet.org Les responsables du domaine "tuxnet.org" pourraient simplement utiliser un unique serveur de noms, s'occupant des 3 sous-domaines. Dans ce cas, le domaine "tuxnet.org" et la zone "tuxnet.org" seraient identiques. Il est probable que dans ce cas, la majorité des requêtes DNS seraient situées sur le territoire français. Les responsables pourraient alors décider de dédier un serveur DNS pour la France qui aura la responsabilité de la zone "france.tuxnet.org" alors que le premier serveur serait responsable du restant de la zone "tuxnet.org (englobant "belgium.tuxnet.org et "luxemburg.tuxnet.org"). Du point de vue pratique, on peut donc dire qu'une "zone" est un morceau de l'arborescence pour lequel un serveur de noms possède les informations complètes (toutes les machines situées dans cette zone). On dit que ce serveur fait "autorité" sur la zone. Un serveur DNS peut faire autorité sur plusieurs zones. Requêtes récursives et non récursives Imaginons un "resolver" demandant à son DNS local la résolution de " Les "resolvers" sont des programmes "clients" du système DNS et sont responsables de : - interroger les différents serveurs DNS - interpréter leurs réponses (résolution ou message d'erreur) - transmettre l'information de résolution au logiciel appelant Remarque : les "resolvers" ne sont pas toujours des programmes séparés (processus autonome) et se résument parfois à des librairies. Requêtes non récursives - le client "Firefox" demande la page de garde du site web " - le resolver interroge le serveur DNS responsable de la zone "racine". Le serveur racine vérifie dans ses données locales (fichiers de zones et cache) et renvoie la meilleure réponse possible, SANS effectuer luimême de nouvelles requêtes sur le réseau. Il renverra uniquement la liste des serveurs DNS responsables de la zone ".org" - le resolver interroge le serveur DNS responsable de la zone ".org" qui donne l'adresse du serveur responsable de la zone "tuxnet.org" - le resolver interroge le serveur DNS responsable de la zone "tuxnet.org" qui est responsable (à l'autorité) sur la zone. Ce serveur peut donc renvoyer l'adresse de l'hôte " - le resolver transmet l'adresse IP au programme appelant, c.-à-d. Firefox Introduction au DNS : Philippe WAUTERS (octobre 2006) - page 3

4 Requêtes récursives Dans ce mode de fonctionnement, un serveur DNS interrogé n'aura que 2 choix possibles : - effectuer lui-même une nouvelle requête sur le réseau pour pouvoir répondre complètement à la requête. Ceci implique beaucoup plus de travail et de ressources utilisées, sur le DNS qui accepte ce genre de requêtes. - répondre par un message d'erreur stipulant que la résolution demandée n'existe pas. La "mémoire cache" et les "TTL" L'interrogation systématique de tous les serveurs DNS, depuis la racine jusqu'au DNS responsable de la zone finale, représente une perte de temps et de performance. Dès qu'un resolver connaît le serveur responsable d'une zone, il garde cette information en mémoire cache afin de répondre plus rapidement à des requêtes similaires (par exemple "mail.tuxnet.org"). Si les informations étaient maintenues dans le "cache" de manière permanente, les modifications apportées à un serveur faisant autorité sur une zone ne seraient jamais connues d'un "resolver". Le TTL (Time To Live) représente le temps maximum pendant lequel un resolver peut garder une information en cache avant de devoir réinterroger le serveur DNS ayant autorité sur la zone. Les principaux "rôles" de serveurs DNS Les serveurs ayant autorité sur une zone Chaque zone doit disposer au moins d'un serveur DNS ayant l'autorité sur cette zone, c.-à-d. ayant tous les renseignements pour résoudre les noms à l'intérieur de cette zone. Plusieurs serveurs peuvent avoir cette autorité et sont classés en fonction de leur rôle dans la zone : Primary Master Slaves maintien la copie principale des informations de la zone. Cette copie est généralement générée manuellement par un administrateur ou est le résultat d'une mise à jour dynamique (dynamic update). serveurs esclaves (également appelés "secondary"). Ils répliquent les informations de la zone au départ d'un serveur primaire (zone transfert) Les serveurs de cache Ils sont uniquement destinés à augmenter les performances en gardant les requêtes précédentes en "cache". Ils ne gardent ces informations que pendant un temps déterminé (TTL). Remarque : un serveur DNS peut cumuler plusieurs rôles. Par - serveur primaire pour une ou plusieurs zone(s) - serveur secondaire pour ou plusieurs autres zone(s) - serveur de cache pour certains clients Qu'est-ce qu'un "Ressource Record" Les données associées à chaque domaine sont consignées dans des "enregistrements de ressources" (Resource Records ou RR). Ces enregistrements sont d'abord divisés en "classes" de ressources puis en "type" de ressources. Classes : IN CH HE classe "TCP/IP" (tous les réseaux utilisant TCP/IP) classe "Chaosnet" (ancien réseau) classe "Hesiod" (réseaux utilisant le logiciel Hesiod) Introduction au DNS : Philippe WAUTERS (octobre 2006) - page 4

5 Les types principaux d'enregistrements pour la classe TCP/IP SOA NS MX A PTR CNAME TXT "Start of authority" (defini le serveur DNS "primaire" ayant autorité sur la zone et d'autres renseignements généraux) défini un serveur DNS ayant autorité sur la zone défini un serveur de mail responsable d'un domaine résolution de nom (pour trouver une adresse à partir d'un nom) résolution inverse (pour trouver un nom à partir d'une adresse) Canonical name (pour trouver un nom à partir d'un "alias") champ de texte (utilisé avec certains protocoles) Les commandes Linux d'interrogation du DNS Il faut avant tout se rappeler qu'un client, sous Linux, interroge les DNS dans l'ordre dans lequel ils sont inscrits dans le fichier /etc/resolv.conf : nameserver premier serveur DNS interrogé nameserver deuxième serveur interrogé en cas de non-réponse du premier nameserver troisième serveur interrogé en cas de non-réponse du deuxième La commande "nslookup" Cette commande fonctionne aussi bien en mode interactif qu'en mode non interactif. $ nslookup utilisation en mode interactif > demande l'adresse IP du serveur " > exit ou $ nslookup la même demande en mode non interactif Quelques autres exemples : $ nslookup -type=soa unixtech.be recherche du champ SOA pour le domaine "unixtech.be" en utilisant le premier serveur spécifié dans /etc/resolv.conf $ nslookup -type=soa unixtech.be ns1.dogmanet.com recherche du champ SOA pour le domaine "unixtech.be" en spécifiant un serveur ayant autorité sur la zone (ns1.dogmanet.com) $ nslookup -type=ns unixtech.be ns1.dogmanet.com recherche des serveurs de nom (DNS) du domaine "unixtech.be", en spécifiant un serveur ayant autorité sur la zone $ nslookup -type=mx unixtech.be ns1.dogmanet.com Recherche des serveurs de mail du domaine "unixtech.be", en spécifiant un serveur ayant autorité sur la zone Remarque : le nombre qui apparait à gauche du nom d'un serveur de mail, dans la réponse, correspond à la priorité de ce serveur pour prendre en charge le courrier. $ nslookup ns1.dogmanet.com demande de résolution d'un serveur particulier ou $ nslookup mail.dogmanet.com $ nslookup demande de résolution inverse d'un serveur particulier Introduction au DNS : Philippe WAUTERS (octobre 2006) - page 5

6 La commande "host" Voici les mêmes requêtes que précédemment, mais avec la commande "host" : $ host -t SOA unixtech.be champ SOA (premier DNS dans /etc/resolv.conf) $ host -t SOA unixtech.be ns1.dogmanet.com champ SOA (DNS = ns1.dogmanet.com) $ host -t NS unixtech.be ns1.dogmanet.com champs NS (DNS = ns1.dogmanet.com) $ host -t MX unixtech.be ns1.dogmanet.com champs MX (DNS = ns1.dogmanet.com) $ host ns1.dogmanet.com résolution du serveur ns1.dogmanet.com $ host mail.dogmanet.com résolution du serveur mail.dogmanet.com $ host résolution inverse du serveur La commande "dig" C'est la commande généralement recommandée car elle est la plus complète. Voici tout d'abord les mêmes requêtes qu'avec "nslookup" et "host" : $ dig -t SOA unixtech.be champ SOA (premier DNS dans /etc/resolv.conf) $ -t SOA unixtech.be champ SOA (DNS = ns1.dogmanet.com) $ -t NS unixtech.be champs NS (DNS = ns1.dogmanet.com) $ -t MX unixtech.be champs MX (DNS = ns1.dogmanet.com) $ dig ns1.dogmanet.com résolution du serveur ns1.dogmanet.com $ dig mail.dogmanet.com résolution du serveur mail.dogmanet.com $ dig -x résolution inverse du serveur Analyse d'une réponse avec "dig" $ dig -t A ; <<>> DiG P1 <<>> -t A explication : ceci correspond au numéro de version de la commande ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 explication : on a effectué une seule requête (QUERY: 1), "dig" nous renvoie 2 réponses (ANSWER: 2), il y a "0" serveurs DNS dans la réponse ayant autorité sur la zone (AUTHORITY: 0) ;; QUESTION SECTION: ; IN A explication : cette section correspond donc à notre requête. On pourrait demander qu'elle ne s'affiche PAS en ajoutant l'option "+noquestion" à la fin de la commande "dig". ;; ANSWER SECTION: IN CNAME unixtech.be. unixtech.be IN A explication : cette section correspond aux 2 réponses à notre requête. Le nombre "3600" correspond au TTL (Time To Live) ;; Query time: 14 msec ;; SERVER: #53( ) explication : le serveur DNS ayant été interrogé correspond à la première ligne dans le fichier /etc/resolv.conf du client (ici le DNS primaire de Cybernet) ;; WHEN: Mon Jan 21 10:33: ;; MSG SIZE rcvd: 63 Introduction au DNS : Philippe WAUTERS (octobre 2006) - page 6

7 Quelques autres exemples : Nous allons maintenant utiliser des "drapeaux" (flags) pour modifier la façon dont la commande affiche les différents éléments : $ dig -t A +nottlid pas d'affichage du TTL dans la(les) réponse(s). Par défaut ce drapeau est à "+ttlid" $ dig -t A +short affichage "court". Par défaut ce drapeau est à "+noshort" $ dig -t A +noquestion pas d'affichage de la section "QUESTION". Par défaut ce drapeau est à "+question" $ dig -t A +noall pas d'affichage du tout. Tel quel, ce drapeau n'a pas de sens et doit être utilisé en combinaison avec un drapeau qui affiche juste ce que l'on désire. Par défaut ce drapeau est à "+all" $ dig -t A +noall +answer dig affichera juste la section "ANSWER" $ dig -t SOA unixtech.be +multiline au lieu d'afficher certaines informations sur la même ligne, "dig" les affichera sur des lignes distinctes. Par défaut ce drapeau est à "+nomultiline" $ dig -t SOA unixtech.be +nssearch "dig" essaiera de trouver un serveur ayant autorité sur la zone spécifiée $ dig -t SOA unixtech.be +trace "dig" affichera tous les DNS interrogés pour arriver à répondre à notre question Introduction au DNS : Philippe WAUTERS (octobre 2006) - page 7