Résumé

  • RFC 3568 inventorie des techniques de routage de requêtes connues ou utilisées au plus tard en décembre 2000. DNS voit surtout un résolveur; les couches transport et application gagnent du contexte au prix d’état, de délai et d’autorité supplémentaires.
  • Un substitut n’est « meilleur » que relativement à un observateur, des candidats, des métriques datées et orientées, une politique et une requête. La preuve doit survivre jusqu’à la livraison et au résultat applicatif.

Un TTL ne mesure pas seulement la fraîcheur d’un enregistrement. Dans un système de routage de requêtes, il fixe la période pendant laquelle un choix continue d’agir sans être rejugé. C’est une délégation temporelle.

RFC 3568, publié comme document informatif en juillet 2003, résume des pratiques industrielles antérieures ou contemporaines à décembre 2000. Il distingue trois familles : routage par DNS, par la couche transport et par la couche application. Leur différence essentielle tient moins au nom de la technique qu’à la quantité de réalité accessible au décideur.

Le DNS voit le mandataire

Un serveur DNS spécialisé peut renvoyer des enregistrements A, NS ou CNAME différents selon ses règles et ses mesures. Une réponse unique désigne un substitut ou une adresse virtuelle; plusieurs réponses proposent un ensemble dont le résolveur peut faire varier l’ordre. Une chaîne NS ou CNAME répartit la décision entre plusieurs serveurs spécialisés.

Pourtant, l’adresse du client n’est normalement pas transportée dans la requête DNS. Le décideur voit le serveur DNS du site client. Si une résolution récursive intervient, il peut ne voir qu’un autre serveur qui agit pour ce premier résolveur. Le système calcule alors une proximité vers un représentant dont il ignore parfois qu’il représente lui-même quelqu’un d’autre.

Cette substitution doit figurer dans le reçu. Il faut distinguer l’identité du client connue au moment de la livraison, le résolveur du site et le serveur récursif effectivement visible. Dire « le plus proche » sans dire de qui est une suppression de donnée, pas une simplification.

La durée du cache devient la durée de l’autorité

Un TTL court permet de réagir plus tôt à une panne ou à une charge nouvelle, mais augmente le trafic de requêtes. Certaines implémentations ne respectent pas le TTL. Et tous les clients qui partagent un résolveur peuvent recevoir le même ensemble d’adresses pendant l’intervalle, jusqu’à concentrer une foule soudaine sur le même substitut.

La réponse devrait donc être liée à la date des mesures, à l’ensemble des candidats, à la version de politique, au périmètre du cache et à l’expiration. Lorsque ces éléments sont séparés, on sait qu'une réponse était valide au sens DNS, sans savoir si sa décision restait défendable à l’usage.

La résolution multi-niveau complique encore cette horloge. Une redirection NS peut permettre au dernier serveur de peser sur le TTL global, provoquer des cas de temporisation et ajouter des allers-retours. Un CNAME ouvre un autre espace de nom et une nouvelle résolution. Chaque niveau améliore potentiellement la spécialisation; chacun crée aussi un point d’autorité et de vieillissement.

Anycast rapproche le résolveur du décideur

Dans le schéma décrit par le RFC, plusieurs serveurs DNS de routage annoncent la même adresse anycast. Le routage remet la requête à l’instance la plus proche, au sens des protocoles de routage, du DNS du site client.

Cela répond à la question : quel décideur reçoit la requête de ce résolveur ? Cela ne prouve ni qu’il est proche du client réel, ni que le futur nœud de livraison est peu chargé. Les protocoles de routage ne sont généralement pas sensibles à la charge; leur proximité n’équivaut pas nécessairement au plus faible délai; la charge du serveur n’entre pas dans cette première sélection.

Le reçu anycast et le reçu de sélection du substitut sont donc deux objets. Leur fusion transforme la facilité de joindre un décideur en promesse de bonne livraison.

Le nom de domaine ne suffit pas à nommer l’objet

Le DNS décide naturellement au niveau d’un domaine. Encoder dans le nom un type, un condensat ou un identifiant d’objet offre une granularité plus fine, mais peut imposer plusieurs résolutions pour une seule page et augmenter le délai total.

La couche transport corrige autrement cette pauvreté. Le premier paquet révèle l’adresse IP du client, le port et le protocole. Le système peut affiner la première décision DNS. Mais le flux aller peut continuer à traverser le substitut choisi initialement tandis que le flux retour, plus volumineux, part directement du nouveau nœud. Une session possède alors une géographie de décision, une géographie aller et une géographie retour.

Toute métrique doit indiquer sa direction. Toute transmission de session doit indiquer si le destinataire l’a acceptée et quel chemin a réellement transporté les données.

Voir l’objet signifie exercer davantage de pouvoir

La couche application peut lire l’URL, les en-têtes, les cookies, la langue ou l’agent utilisateur. Elle peut produire une redirection 302, intercepter et raccorder une connexion, ou réécrire les URL d’objets incorporés. Elle peut enfin décider au niveau de l’objet.

Mais une redirection ajoute un aller-retour et dépend de son exécution par le client. Un élément sur le chemin ajoute analyse et état au trafic. La réécriture enregistre une ancienne décision dans le contenu : la première requête passe toujours par l’origine, puis une page cachée peut continuer à désigner un substitut indisponible. Le RFC conseille donc de ne pas mettre ces pages en cache, ou seulement brièvement.

TLS rend le prix explicite. Le réseau de contenu ne voit pas l’URL complète sans terminer la session TLS. Obtenir le contexte nécessaire à une décision plus fine revient à recevoir une responsabilité cryptographique et un accès au contenu. Le contrôle doit nommer le titulaire du certificat, l’autorité de terminaison et les champs effectivement inspectés.

Une mesure ne quitte jamais son point de vue

Le RFC cite la latence, les sauts, les informations BGP, la charge et la disponibilité du contenu. Pour son analyse, la proximité signifie un temps aller-retour; dans le cas DNS, celui-ci est souvent mesuré vers le résolveur local. Certaines observations ne couvrent qu’un sens alors que les chemins Internet peuvent être asymétriques.

Les sondes actives sont périodiques. Les pare-feu et les NAT peuvent les bloquer; les systèmes de détection peuvent les interpréter comme une attaque. L’absence de réponse n’établit donc pas une distance. Les sondes HTTP peinent à donner une charge en temps réel et les données anciennes peuvent être fausses. Même la longueur AS_PATH de BGP peut, avertit le texte, n'avoir aucun sens comme bonne métrique de choix.

Une observation exploitable conserve la source, la cible, la méthode, le sens, l’heure, la valeur brute et la signification d’un échec. Le classement conserve ensuite l’âge accepté, les poids et les exclusions. Sans cela, « meilleur » n’est qu’un adjectif appliqué à des nombres incompatibles.

La chaîne de preuve

Le graphe commence par la requête telle que la couche peut la voir. Il enregistre la chaîne de résolveurs, le nom ou l’objet, les candidats admissibles, leur disponibilité et chaque mesure. Une politique versionnée apporte contraintes, poids et règle de départage. La décision nomme le substitut et son échéance.

La preuve continue par la réponse DNS, la redirection, la réécriture, l’interception ou le transfert. Elle conserve l’autorité TLS. Puis elle montre l’acceptation par le substitut, la présence de l’objet, sa charge au moment du service, le chemin de réponse, la fin ou la reprise par le client et l’issue applicative.

Une réponse DNS n’est pas une arrivée. Une redirection n’est pas son exécution. Une URL réécrite n’est pas une livraison. Une sélection n’est pas une acceptation. Aucun niveau ne peut déclarer le succès du suivant.

Limite des preuves

Cet Article ne nomme aucun CDN, opérateur, résolveur, client, substitut, fournisseur, incident ni résultat mesuré. RFC 3568 est un inventaire informatif des mécanismes connus avant fin 2000, pas une norme ni la preuve d’un déploiement actuel.

RFC 3466 apporte le vocabulaire contemporain; RFC 3238 traite les intermédiaires. RFC 2782, RFC 1546, RFC 1034, RFC 1035 et RFC 2181 fournissent le contexte DNS; RFC 3272, RFC 2386 et RFC 3221 celui du routage. RFC 7336 et RFC 8008 sont un contexte CDNI postérieur, jamais une preuve rétrospective.

Les essais de Heng Lu sur la primauté du code en fonctionnement et sur la spécification initiale minimale sont des prismes éditoriaux déclarés. Ils justifient ici de tester la chaîne réelle et de limiter le contrat commun; ils ne décrivent ni l’intention des auteurs du RFC ni un résultat d’exploitation.

La conclusion reste bornée : le meilleur substitut est le meilleur choix que cet observateur pouvait calculer à cet instant. Une preuve complète doit encore montrer pour qui, avec quelles données et si la livraison a confirmé le pari.

Sources