Les bases de la requête DNS: Comment fonctionne la résolution en fait

Chaque fois que vous tapez un domaine dans un navigateur ou que vous vous connectez à un service distant, votre appareil envoie une requête DNS. Cette requête consiste en un en-tête avec des drapeaux (QR, Opcode, AA, TC, RD, RA, etc.) et une section de questions qui spécifie le domaine cible et le type d'enregistrement que vous voulez. Le résolveur suit ensuite une chaîne de requêtes – en commençant par la racine, puis le TLD, puis le serveur de noms faisant autorité – pour récupérer la réponse finale.

Demandes de renseignements recursives ou itératives

Les requêtes récursives sont envoyées par les clients à un résolveur (p. ex., votre DNS ISP= ou un résolveur public comme 1.1.1.1). Le résolveur effectue tout le travail : il interroge la racine, le TLD et le serveur faisant autorité, puis renvoie soit la réponse, soit une erreur. Les requêtes itératives sont utilisées entre les résolveurs et les serveurs de noms. Lorsqu'un résolveur demande un serveur racine pour , la racine répond par une référence aux serveurs TLD de .com – elle n'aller pas plus loin.

Types de requêtes DNS communs – élargi

Chaque type d'enregistrement DNS sert un but spécifique dans les diagnostics réseau. Ci-dessous sont les types les plus utilisés, leurs rôles, et les problèmes qu'ils peuvent révéler.

Un enregistrement (Adresse – IPv4)

L'enregistrement A map un domaine à une adresse IPv4 32 bits. C'est le type de requête le plus fondamental. Lorsqu'une requête retourne (domaine inexistant), le domaine n'est pas configuré pour IPv4. Une réponse suggère que le serveur de noms faisant autorité est inaccessible ou mal configuré. Utilisez pour vérifier que votre serveur web =s IP est correct. Pour les services équilibrés en charge, plusieurs enregistrements A peuvent apparaître; le résolveur tourne généralement entre eux.

AAAA Enregistrement (adresse IPv6)

L'adoption IPv6 augmente, la vérification des enregistrements AAAA est essentielle lors du diagnostic des problèmes de connectivité sur les réseaux à double prise. Si un client préfère IPv6 mais qu'il n'existe pas d'enregistrement AAAA, la connexion peut échouer ou revenir à IPv4. Utilisez pour confirmer l'accessibilité IPv6.

MX Record (échange de courrier)

Les enregistrements MX spécifient les serveurs de messagerie responsables d'un domaine et leurs numéros de priorité (les valeurs inférieures sont essayées en premier). Un enregistrement MX manquant signifie que le domaine ne peut pas recevoir de courriel. Une configuration avec un seul serveur de faible priorité crée un seul point de défaillance. Utilisez pour lister les serveurs d'échange de courrier. Problèmes communs : noms d'hôte incorrects (par exemple, au lieu de ) ou des enregistrements A/AAAA cassés pour les cibles MX (également appelés cohérence --glue).

NS Enregistrement (Serveur de Nom)

Lorsque ces enregistrements pointent vers des serveurs de noms qui n'existent pas ou qui ne sont pas configurés pour la zone, la délégation est cassée. Utilisez pour voir la liste. Demandez également la zone parent (p. ex. .com) avec pour vérifier la délégation correspond à la zone enfant. Les erreurs causent des pannes intermittentes.

TXT Record (Texte)

Les enregistrements TXT stockent du texte arbitraire, mais aujourd'hui ils sont dominés par l'authentification par courriel : SPF, DKIM et DMARC. La questionnement révèle des politiques SPF comme . Les enregistrements TXT manquants ou mal configurés conduisent à des vulnérabilités de spoofing par courriel ou des messages légitimes atterrissant dans le spam.

Enregistrement du CNAME (dénomination canonique)

Un enregistrement CNAME alias un domaine à un autre. Par exemple, peut pointer vers . Utilisez pour trouver le nom d'hôte canonique. Important : un CNAME ne peut coexister avec d'autres enregistrements du même nom (RFC 1912). La surutilisation des chaînes CNAME augmente la latence de résolution. Note de sécurité : un attaquant qui compromet le domaine cible peut rediriger votre trafic.

SoA Record (Début de l'autorisation)

L'enregistrement SOA contient des métadonnées administratives : le serveur de noms principal, l'adresse email responsable, le numéro de série (critique pour les transferts de zones) et les valeurs de chronométrage (raffinement, réessayer, expirer, minimum TTL).

Enregistrement TPR (Pointeur – DNS inversé)[

Les serveurs de messagerie rejettent souvent le courrier des hôtes dont le PTR ne correspond pas au domaine d'envoi. Utilisez pour vérifier les DNS inversés. Les enregistrements PTR incorrects ou manquants sont une source fréquente de problèmes de livraison de courriels.

Enregistrement du VRS (lieu de service)

Les enregistrements SRV définissent le nom et le port de l'hôte pour des services spécifiques tels que SIP, LDAP ou XMPP. Ils suivent le format . Interrogez pour voir la priorité, le poids et le port.

Pratique DNS Enquêter avec creuser

L'outil dig (Domain Information Groper) est la norme de facto pour les diagnostics DNS manuels. Voici les modèles de commande les plus utiles:

  • Simple recherche:[ – retourne l'adresse IPv4 et le TTL.
  • Spécifier le type d'enregistrement:[ ou .
  • Demander un résolveur spécifique:[ – contourne votre résolveur local.
  • Tracez le chemin de résolution complète: – montre les étapes itératives de la racine à l'autorité.
  • Short output:[ – seulement l'adresse IP, utile pour les scripts.
  • – recherche inverse : – recherche l'enregistrement PTR.

Interpréter la réponse est la clé. Le champ peut être (enregistrement trouvé), (domaine n'existe pas), (défaut de serveur, souvent un délai ou une erreur de configuration), (rejection de politique), ou (question mal formée). ] montre les enregistrements récupérés; ] liste les serveurs de noms responsables; le contient souvent des enregistrements de colle ou des adresses IP de ces serveurs de noms.

Incidences sur la sécurité des types de requêtes DNS

Les requêtes DNS sont en texte clair par défaut, les rendant visibles aux adversaires du réseau, à moins que DNS-over-HTTPS (DoH) ou DNS-over-TLS (DoT) ne soient utilisés.

  • TXT records for SPF, DKIM, and DMARC: Ce sont les piliers de la sécurité de l'email. Un seul enregistrement SPF manquant ou trop permissif (par exemple, ) permet à quiconque d'envoyer des courriels comme votre domaine. Interrogez régulièrement votre propre domaine avec et .
  • Les attaques de CNAME et de redirection: Si un domaine cible CNAME expire ou est repris par un attaquant, chaque alias pointant vers lui devient un vecteur de phishing. Vérifiez toujours que les noms d'hôte cible sont contrôlés et ont des enregistrements A/AAAA valides.
  • NS enregistrement spoofing:[ Une zone parent mal configurée pourrait pointer vers des serveurs de noms malveillants. Utilisez pour vérifier chaque étape de délégation.

DNSSEC (DNS Security Extensions) est conçu pour protéger contre les réponses falsifiées. Interrogez pour voir les enregistrements RRSIG et DNSKEY. Si votre résolveur supporte la validation, les réponses comprendront le drapeau (données authentiques).

Dépannage avec les requêtes DNS – Un scénario étape par étape

Supposons que les utilisateurs ne puissent pas accéder à et que le courriel échoue. Utilisez la méthodologie suivante:

  1. Vérifier A/AAAA: et . Si NXDOMAIN, le domaine peut être expiré ou supprimé. Si SERVFAIL, essayez de demander directement à un résolveur public: .
  2. Vérifier la délégation: et comparer avec la zone parente: . S'ils diffèrent, le domaine est mal délégué.
  3. Inspecter SOA: . Vérifiez le numéro de série des serveurs de noms primaires et secondaires. Si les séries sont mal adaptées, les transferts de zones échouent.
  4. Test MX: . Notez les noms d'hôte cible (p. ex. ). Ensuite, testez chaque cible : . Si l'IP du serveur de messagerie ne résout pas, l'email ne peut pas être livré.
  5. Confirmer le DNS inverse: . L'enregistrement PTR doit correspondre au FQDN du serveur de messagerie.
  6. Vérifiez les enregistrements TXT pour auth: pour SPF, et . Cherchez des erreurs de syntaxe ou des étiquettes --v=-.

En exécutant systématiquement ces requêtes, vous isolez si le problème est dans la délégation, le contenu de zone, ou la configuration de courriel.

Conclusion

La maîtrise des types de requêtes DNS transforme les diagnostics abstraits en étapes précises et réalisables. Les outils comme et mettent l'écosystème DNS à portée de main – comprendre les sections de réponse et les codes d'erreur, et vous pouvez résoudre la plupart des problèmes de connectivité et de courriel en quelques minutes. Intégrer la validation DNSSEC et l'audit régulier des enregistrements TXT pour garder votre domaine sécurisé. Pour plus de détails, consultez RFC 1035 sur la mise en œuvre DNS et le Registre des paramètres DNS [ de l'IANA]. Grâce à ces compétences, vous assurez une résolution fiable et sécurisée des noms sur votre réseau.