Les bases du DNS que tout développeur devrait connaître

Vous avez déployé votre application, mais les utilisateurs signalent qu’elle est inaccessible. Votre premier réflexe serait peut-être de vérifier le serveur, mais le véritable coupable est souvent le DNS. Comprendre les bases du DNS n’est pas optionnel—c’est essentiel pour déboguer les problèmes en production et comprendre comment vos applications web atteignent réellement les utilisateurs.

Cet article couvre le flux de résolution DNS, les types d’enregistrements courants, le comportement de mise en cache et les développements DNS modernes qui affectent les performances et la sécurité.

Comment fonctionne la résolution DNS

Lorsqu’un navigateur doit se connecter à api.example.com, il ne connaît pas magiquement l’adresse IP. Le processus de résolution implique trois couches :

Résolveur stub : Le client DNS intégré de votre système d’exploitation. Il ne résout pas les noms lui-même—il transmet les requêtes à un résolveur récursif configuré et met en cache les réponses localement.

Résolveur récursif : Généralement exploité par votre FAI ou un service public comme Cloudflare (1.1.1.1) ou Google (8.8.8.8). Ce serveur effectue le gros du travail, en interrogeant d’autres serveurs en votre nom.

Serveurs de noms autoritaires : La source de vérité pour les enregistrements DNS d’un domaine. Le résolveur récursif parcourt la hiérarchie DNS—serveurs racine, puis serveurs TLD (.com, .io), puis les serveurs autoritaires du domaine—pour trouver la réponse.

Pour les développeurs, l’élément clé à retenir est que les défaillances DNS peuvent survenir à n’importe quelle couche. Un résolveur stub mal configuré, un résolveur récursif inaccessible ou des enregistrements autoritaires obsolètes peuvent tous casser votre application.

Types d’enregistrements DNS courants

Vous rencontrerez régulièrement ces enregistrements :

• A / AAAA : Associent un nom d’hôte à une adresse IPv4 ou IPv6
• CNAME : Crée un alias d’un nom d’hôte vers un autre (ne peut pas être utilisé à l’apex de zone—example.com lui-même nécessite un enregistrement A ou AAAA)
• MX : Spécifie les serveurs de messagerie pour le domaine
• TXT : Stocke du texte arbitraire, couramment utilisé pour la vérification de domaine et l’authentification email (SPF, DKIM)
• NS : Délègue une zone à des serveurs de noms spécifiques

Comprendre ces enregistrements aide lors de la configuration de CDN, de services email ou du débogage d’un sous-domaine qui ne se résout pas.

Mise en cache DNS et TTL

La mise en cache DNS et le TTL (Time To Live) impactent directement votre stratégie de déploiement. Chaque enregistrement DNS inclut une valeur TTL en secondes. Une fois qu’un résolveur met en cache un enregistrement, il ne fera pas de nouvelle requête avant l’expiration du TTL.

Implications pratiques :

• Un TTL de 3600 secondes (1 heure) signifie que les modifications DNS prennent jusqu’à une heure pour se propager
• Avant les migrations, réduisez les TTL à l’avance—pas pendant le changement
• Les navigateurs et systèmes d’exploitation maintiennent leurs propres caches, ajoutant une couche supplémentaire

Le mythe selon lequel « la propagation DNS prend 24 à 48 heures » est trompeur. Le temps de propagation dépend de la valeur TTL précédente. Si votre ancien TTL était de 86400 secondes (24 heures), c’est votre temps d’attente dans le pire des cas.

DNS moderne : enregistrements HTTPS et transport chiffré

Le DNS a considérablement évolué ces dernières années. Deux développements importent le plus pour les développeurs web.

L’enregistrement DNS HTTPS (SVCB)

L’enregistrement HTTPS (un type spécifique d’enregistrement SVCB) fournit des indications de connexion avant même que le navigateur ne contacte votre serveur. Il peut annoncer :

• La prise en charge de HTTP/3 et QUIC
• Des ports alternatifs
• Des clés Encrypted Client Hello (ECH)

Cela permet aux navigateurs d’établir des connexions plus rapides et plus sécurisées. Cependant, la prise en charge des enregistrements HTTPS n’est pas encore universelle—tous les fournisseurs DNS ne le supportent pas, et certains résolveurs ne les interrogent pas.

Remarque : Les enregistrements HTTPS offrent des capacités limitées d’alias à l’apex, mais ils ne constituent pas une solution complète de CNAME à l’apex.

DNS over HTTPS (DoH) et DNS chiffré

Les requêtes DNS traditionnelles transitent en clair via le port UDP 53. DNS over HTTPS (DoH), DNS over TLS (DoT) et DNS over QUIC (DoQ) chiffrent ces requêtes, empêchant l’espionnage et la manipulation.

Le DNS chiffré est maintenant largement déployé—Firefox et Chrome utilisent DoH par défaut dans de nombreuses configurations—mais ce n’est pas universel. Les réseaux d’entreprise et certains FAI interceptent ou bloquent encore le DNS chiffré.

DNSSEC vs chiffrement : connaître la différence

Une confusion courante : DNSSEC n’est pas du chiffrement.

DNSSEC fournit de l’authentification. Il signe cryptographiquement les enregistrements DNS afin que les résolveurs puissent vérifier que les réponses n’ont pas été altérées. Il ne cache pas vos requêtes.

DNS chiffré (DoH/DoT/DoQ) fournit de la confidentialité. Il chiffre la couche de transport afin que les observateurs ne puissent pas voir quels domaines vous interrogez.

Ils résolvent des problèmes différents et peuvent être utilisés ensemble.

Comment les défaillances DNS se manifestent dans vos applications

Lorsque le DNS échoue, vous verrez généralement :

• Des erreurs NXDOMAIN (le domaine n’existe pas)
• Des timeouts de connexion (résolveur inaccessible)
• Des réponses SERVFAIL (problèmes de serveur en amont)

Dans les navigateurs, celles-ci apparaissent comme des erreurs « DNS_PROBE_FINISHED_NXDOMAIN » ou similaires. Dans Node.js ou d’autres environnements d’exécution, vous obtiendrez des exceptions ENOTFOUND ou équivalentes.

Utilisez dig ou nslookup pour déboguer. Interrogez différents résolveurs pour isoler si le problème vient du cache local, de votre résolveur ou des serveurs autoritaires.

Conclusion

Le DNS se situe entre vos utilisateurs et vos serveurs. Comprendre le flux de résolution, le comportement du TTL et les protocoles modernes comme les enregistrements HTTPS et DoH vous aide à déployer de manière plus fiable et à déboguer plus rapidement. Lorsque quelque chose casse, le DNS devrait être l’un de vos premiers suspects—pas le dernier.

FAQ

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.