Le DNS associe les noms de domaine aux adresses IP pour que les appareils puissent communiquer sans demander aux internautes de mémoriser des suites de chiffres. Dans le sens inverse, une adresse IP peut aussi être associée à un nom grâce à des enregistrements spécifiques.
Cette résolution de noms intervient à chaque accès à un site ou à un service réseau. Comprendre le rôle du serveur DNS, les principaux enregistrements et les outils de vérification aide à diagnostiquer les problèmes de connexion.
DNS : comment un nom de domaine devient une adresse IP
La requête DNS et la résolution de noms
Lorsqu’une personne saisit un nom de domaine dans son navigateur, l’ordinateur doit obtenir l’adresse IP du serveur visé. Selon les objectifs de certification Cisco CCNA, DNS et DHCP jouent des rôles distincts : le premier traduit des noms, tandis que le second fournit notamment des paramètres réseau aux appareils.
Le système consulte d’abord ses informations locales, dont le fichier hosts, puis adresse une requête DNS à un résolveur si aucune correspondance n’est disponible. Celui-ci peut répondre depuis son cache ou interroger les serveurs DNS de la hiérarchie, depuis la racine jusqu’aux serveurs faisant autorité pour la zone DNS concernée.
Les requêtes ordinaires utilisent généralement UDP sur le port 53, tandis que TCP est notamment employé pour les transferts de zone et certaines réponses volumineuses. Le DNS est donc un protocole réseau complémentaire à IP : il facilite l’accès aux ressources, mais ne transporte pas lui-même les données du site.
Repères utiles sur les échanges DNS :
- Nom demandé : nom de domaine à résoudre
- Résolveur : serveur qui cherche ou fournit la réponse
- Cache : réponses conservées temporairement selon leur durée de vie
- Port habituel : port 53 en UDP ou en TCP selon l’échange
Les principaux enregistrements DNS
La réponse dépend du type d’information demandé. Selon IBM, DNS peut associer un nom à une adresse numérique, mais aussi publier des informations utiles au courrier électronique et à la découverte de services.
Par exemple, une requête de type A cherche une adresse IPv4, tandis qu’une requête AAAA concerne une adresse IPv6. Le navigateur peut ensuite contacter la destination obtenue ; en environnement à double pile, les systèmes peuvent disposer des deux familles d’adresses.
Les enregistrements suivants illustrent les usages les plus courants :
| Type | Rôle | Exemple d’usage |
|---|---|---|
| A | Associe un nom à une adresse IPv4 | Accès à un serveur web |
| AAAA | Associe un nom à une adresse IPv6 | Accès à un service en IPv6 |
| MX | Indique les serveurs de courrier du domaine | Distribution des courriels |
| NS | Désigne les serveurs responsables d’une zone | Délégation DNS |
| CNAME | Associe un alias à un nom canonique | Nom alternatif pour un service |
Ces types ne sont pas interchangeables : un enregistrement MX ne fournit pas l’adresse d’un site web et un CNAME n’identifie pas directement une adresse IP.
Résolution inverse : retrouver un nom à partir d’une adresse IP
Le rôle de l’enregistrement PTR
Après la résolution directe, l’opération complémentaire consiste à rechercher un nom associé à une adresse IP. Selon la documentation de F5 sur la résolution de noms, cette opération est appelée résolution inverse et repose notamment sur un enregistrement PTR.
Pour une adresse IPv4, la recherche s’effectue dans l’espace in-addr.arpa, en inversant l’ordre des octets. Ainsi, l’adresse 91.198.174.2 correspond à une requête portant sur 2.174.198.91.in-addr.arpa. Le serveur faisant autorité peut alors fournir un nom, si un PTR a été configuré.
Les principales différences entre les deux sens de recherche sont les suivantes :
- Résolution directe : nom de domaine vers adresse IP
- Résolution inverse : adresse IP vers nom associé
- Enregistrement direct IPv4 : type A
- Enregistrement inverse : type PTR dans une zone dédiée
Un PTR ne garantit pas à lui seul que le nom retourné pointe en retour vers la même adresse. Les administrateurs vérifient souvent les deux correspondances lorsqu’ils diagnostiquent un serveur de messagerie ou un service réseau.
Pourquoi la résolution inverse est utile
Cette recherche aide à interpréter les journaux, à identifier des équipements et à contrôler certaines configurations de services. Elle ne révèle toutefois pas automatiquement le propriétaire d’une adresse IP : le résultat dépend des enregistrements publiés par l’organisation responsable de l’espace d’adressage.
Une absence de réponse PTR ne signifie donc pas nécessairement que l’adresse est inutilisable. Elle indique simplement qu’aucun nom inverse n’est disponible pour cette adresse dans la zone interrogée.
Vérifier un serveur DNS et diagnostiquer une réponse
Utiliser nslookup ou dig
Quand un site ne s’ouvre pas, il faut distinguer une panne DNS d’un problème de connexion ou de serveur. Les outils nslookup et dig permettent d’interroger un résolveur et d’observer le type de réponse reçu.
Avec dig, une commande ciblant un type précis permet de tester une information particulière, par exemple une adresse AAAA ou les serveurs de courrier MX. La commande dig -x réalise une résolution inverse ; elle affiche la requête PTR correspondante et la réponse éventuelle.
Pour examiner les informations publiées par DNS, ces contrôles sont utiles :
- Interroger un type A pour vérifier une adresse IPv4
- Interroger un type AAAA pour vérifier une adresse IPv6
- Consulter les NS pour repérer les serveurs de la zone
- Utiliser dig -x pour rechercher un enregistrement PTR
Une réponse issue du cache peut être différente d’une interrogation directe auprès d’un serveur faisant autorité, notamment après une modification récente. Le champ TTL indique combien de temps une réponse peut être conservée avant une nouvelle vérification.
Comprendre les réponses et les limites du DNS
Une erreur de résolution peut provenir d’un nom mal saisi, d’un serveur indisponible, d’une délégation incorrecte ou d’un cache encore ancien. Comparer plusieurs requêtes aide à isoler la cause sans confondre le fonctionnement du DNS avec celui du réseau IP.
Par exemple, si un nom ne renvoie aucune adresse mais que le serveur répond aux autres requêtes, l’anomalie concerne probablement la configuration de la zone ou l’enregistrement recherché. Si aucune requête n’aboutit, il faut aussi vérifier l’accès au résolveur et la connectivité réseau.
| Observation | Vérification utile | Piste de diagnostic |
|---|---|---|
| Aucune réponse du résolveur | Tester l’accès au serveur DNS | Connectivité ou serveur indisponible |
| Adresse IPv4 absente | Interroger le type A | Enregistrement absent ou incorrect |
| Nom inverse introuvable | Tester avec dig -x | Enregistrement PTR non publié |
| Réponse ancienne | Examiner la durée TTL | Cache pas encore renouvelé |