Comment les CDN utilisent le DNS pour router le trafic

La promesse centrale d'un CDN est de servir le contenu depuis un serveur physiquement proche de chaque visiteur, plutôt que depuis un unique serveur d'origine fixe desservant le monde entier. Dans la plupart des implémentations, le mécanisme qui rend cela possible est le DNS : plus précisément, donner des réponses différentes à des visiteurs différents pour exactement la même requête.

Même domaine, réponse différente, volontairement

Lorsqu'un domaine est placé derrière un CDN, ses enregistrements DNS pointent généralement (souvent via un CNAME) vers l'infrastructure propre du fournisseur de CDN plutôt que vers une IP d'origine unique. Les serveurs de noms du CDN répondent alors à chaque requête entrante selon l'endroit d'où elle semble provenir, en renvoyant l'adresse IP du site en périphérie (edge) le plus proche, ou le moins chargé, pour ce visiteur précis. Deux personnes aux antipodes qui interrogent le même domaine peuvent, à bon droit, recevoir deux adresses IP entièrement différentes.

• C'est pourquoi une même recherche de domaine vers IP effectuée deux fois, depuis deux endroits différents, n'est pas un bogue lorsque les résultats diffèrent : c'est le système qui fonctionne comme prévu.
• C'est aussi pourquoi les domaines derrière un CDN tendent à se résoudre vers plusieurs adresses au fil de recherches répétées : il n'existe pas une seule réponse « correcte », seulement des réponses adaptées au moment.
• Un TTL court est courant sur ces enregistrements précisément pour que le CDN puisse détourner rapidement le trafic d'un site en périphérie en difficulté, sans attendre la fin d'une longue fenêtre de cache.

Ce que cela change quand vous déboguez

Si un site derrière un CDN se comporte bizarrement pour certains visiteurs et pas pour d'autres, vérifier vers quoi différents points d'observation résolvent réellement le domaine est souvent le moyen le plus rapide de confirmer si le problème vient d'un site en périphérie précis plutôt que de l'origine ou de l'application elle-même. Un outil qui résout directement et affiche la réponse brute, sans le cache DNS propre au navigateur placé devant, donne une lecture plus nette de ce qui est réellement servi à une région donnée à l'instant présent.

L'adresse réelle du serveur d'origine est volontairement cachée

Un effet secondaire à connaître : résoudre un domaine derrière un CDN vous donne l'adresse du réseau en périphérie, pas celle du serveur d'origine qui se trouve derrière, et c'est généralement voulu, pas accidentel. Garder l'IP réelle de l'origine hors du DNS public est l'une des défenses les plus simples et les plus efficaces d'un site contre une attaque par déni de service directe visant l'infrastructure réelle plutôt que la capacité bien plus grande du CDN placé devant. Cela signifie aussi qu'une simple recherche de domaine ne peut pas vous dire où un site est « vraiment » hébergé, seulement où son trafic entre actuellement dans le réseau du CDN, ce qui est une question sensiblement différente.

Rechercher le WHOIS ou l'ASN d'une adresse résolue

Un moyen rapide et pratique de confirmer qu'un domaine se trouve derrière un CDN consiste à vérifier à qui appartient réellement l'adresse IP résolue, séparément de la recherche du domaine elle-même. Une adresse résolue enregistrée sous le numéro de système autonome (ASN) d'un CDN ou d'un fournisseur cloud bien connu est un signal fort que vous avez affaire à un réseau en périphérie et non à un serveur d'origine, et explique immédiatement pourquoi le même domaine peut afficher une adresse différente depuis une autre région sans que rien ne soit anormal. C'est une deuxième étape utile après une recherche, pas un remplacement : la réponse DNS vous donne l'adresse actuelle, et la recherche de propriété vous indique de quel type d'infrastructure cette adresse relève réellement.