Une application ordinaire interroge le résolveur stub du système d'exploitation, lequel consulte la politique locale du service de noms et envoie une requête récursive au résolveur configuré. Ce dernier ne parcourt la hiérarchie que si son cache valide ne répond pas déjà.
DNS · Leçon 3
Processus DNS
Découvrez comment les résolveurs stub et récursif utilisent cache, renvois, glue et autorité pour répondre à une requête DNS.
Commencer par la politique locale et le cache
Le résolveur du système peut consulter /etc/hosts, le DNS et d'autres sources dans l'ordre configuré. Les suffixes de recherche peuvent transformer un nom court en plusieurs noms candidats. Le résolveur récursif vérifie ensuite ses caches positif et négatif avant d'envoyer du trafic en amont.
Pourquoi un résolveur récursif peut-il ne contacter aucun serveur faisant autorité pour une requête ?
Interroger un serveur racine
En cas d'absence en cache, le résolveur récursif peut interroger un serveur racine. La racine DNS comporte 13 identités de serveurs nommées de A à M, servies par de nombreuses instances physiques grâce à l'anycast et d'autres techniques résilientes. La réponse renvoie normalement le résolveur vers les serveurs du domaine de premier niveau pertinent au lieu de fournir l'adresse finale.
Que renvoie normalement un serveur racine pour une recherche non mise en cache de www.example.com ?
Suivre les renvois du TLD et des serveurs d'autorité
Le résolveur interroge un serveur faisant autorité pour com, qui renvoie les serveurs délégués de example.com. Le renvoi peut inclure des enregistrements d'adresse glue lorsqu'ils sont nécessaires pour joindre un serveur dont le nom se trouve dans l'enfant délégué. Le résolveur interroge ensuite un serveur d'autorité pour l'enregistrement demandé.
Quel problème les données glue du DNS contribuent-elles à résoudre ?
Suivre les alias et les types d'enregistrements
Une réponse peut contenir un alias CNAME qui nécessite la recherche d'un autre nom, ou des enregistrements propres à l'application qui entraînent d'autres requêtes. Une demande A ne renvoie que les adresses IPv4 et les données liées à leur chaîne ; une requête AAAA distincte obtient les adresses IPv6. La réponse finale porte un état comme NOERROR, NXDOMAIN ou SERVFAIL, chacun ayant un sens différent.
Que signale NXDOMAIN ?
Validation, cache et utilisation par l'application
Un résolveur récursif validant peut utiliser les signatures DNSSEC et la chaîne de confiance pour vérifier un déni authentifié ou l'intégrité d'un enregistrement. DNSSEC ne chiffre pas les requêtes et ne prouve pas que l'application à l'adresse renvoyée est digne de confiance.
Le résolveur met les résultats en cache selon les règles de TTL et les renvoie au stub. L'application choisit ensuite une adresse et tente ses propres protocoles réseau et de sécurité.
Que ne fournit pas la validation DNSSEC ?
Leçon terminée
Vous avez terminé Processus DNS
Vous savez maintenant suivre une résolution DNS récursive depuis la politique locale jusqu'à la réponse finale mise en cache.
Vérifier d'abord les sources locales et le cache du résolveur.
Suivre les renvois de la racine et du domaine de premier niveau.
Utiliser les données glue pour joindre les serveurs délégués.
Distinguer les alias, les réponses sans données et les noms inexistants.
Séparer l'intégrité DNSSEC de la confidentialité du transport.
Conservez votre progression
Créez un compte gratuit pour enregistrer cette leçon et continuer sur n'importe quel appareil.
Créer un compte gratuit