Résumé

  • RFC 1794 décrit une tentative de 1995 pour adapter l’ordre des adresses DNS à la charge des serveurs sans changer le protocole.
  • Une réponse pouvait présenter une préférence ; caches, serveurs secondaires et logiciels clients empêchaient cette préférence de devenir une affectation obligatoire.

Une liste ordonnée ne lance pas la connexion

Un nom peut renvoyer vers plusieurs machines équivalentes. Si l’une est moins chargée, l’administrateur peut souhaiter qu’elle apparaisse en premier. Pourtant, le DNS transmet des enregistrements : il n’ouvre pas lui-même la connexion de l’application. C’est la frontière que RFC 1794 rend visible. La réponse peut être ordonnée de façon utile et prévisible, sans que le protocole oblige le client à respecter cet ordre.

Publié en avril 1995, le texte est de catégorie Informational et précise qu’il ne définit aucune norme Internet. L’auteur voulait consigner une exploration du groupe de travail DNS et les solutions envisagées. Il avertit aussi que certaines parties de l’historique peuvent manquer. Le document atteste donc un débat de conception, pas le nombre de déploiements ni leur efficacité.

De la rotation à la mesure de charge

L’auteur situe vers 1986 l’apparition de modifications de BIND qui changeaient l’ordre des enregistrements d’adresse. Il cite les adaptations « Shuffle Address » de Bryan Beecher et le code Round Robin de Marshall Rose comme exemples probablement très diffusés. Cette datation rétrospective n’est pas un recensement indépendant.

La rotation faisait varier l’adresse présentée en premier, sans mesurer la charge réelle des machines. RFC 1794 la compare aux adaptations attribuées à Matt Madison chez TGV, qui exploitaient des fonctions propres à VMS pour classer les adresses de la moins chargée à la plus chargée. Le classement tenait mieux compte de l’état d’un hôte, mais dépendait d’un système d’exploitation particulier et exigeait de modifier le traitement des enregistrements. D’un côté, une rotation portable sans mesure ; de l’autre, une information de charge plus directe, mais liée à une plateforme.

La compatibilité déplaçait le mécanisme

Les critères consignés par le groupe de travail étaient larges : préserver la compatibilité avec le DNS existant, permettre des changements fréquents, renvoyer plusieurs adresses, respecter les autres types d’enregistrements, représenter plusieurs formes de charge et calculer rapidement. Une actualisation toutes les cinq minutes était jugée normale ; une cadence de soixante secondes était évoquée comme possibilité, sans mesure à l’appui. Les adresses de repli devaient offrir une autre piste si la machine privilégiée tombait en panne avant l’expiration du TTL.

Modifier le protocole ou créer un nouveau type d’enregistrement paraissait risqué face au parc déjà installé. RFC 1794 attribue à Rob Austein une autre proposition : rendre le programme de transfert de zone plus intelligent. Celui-ci pouvait obtenir des données de charge, réordonner les informations de la zone, puis les remettre au serveur de noms, sans changer le format des messages DNS. La requête restait familière ; la préparation des données devenait dynamique.

La complexité changeait de place. Les transferts mettent à jour les serveurs secondaires ; le serveur primaire n’en utilise pas un pour répondre à ses propres requêtes. Une sous-zone volatile dépendait donc de la fréquence de rafraîchissement, tandis que les TTL distribués devaient être bas pour diffuser plus vite un nouvel ordre. Le calcul devait aussi se terminer avant que l’information produite ne devienne périmée. Un classement récent à la source pouvait déjà être ancien dans un cache.

Le dernier choix demeurait local

RFC 1794 rappelle que le DNS ne garantit pas l’ordre des réponses. L’auteur le qualifie de prévisible : un client pouvait recevoir plusieurs fois le même ordre, mais aussi réordonner les adresses localement, notamment avec une liste de tri. Le programme de transfert ne pouvait pas prévoir ces choix distants. La présence de plusieurs adresses ne prouvait ni que le client les essaierait toutes, ni que la suivante était saine, ni que la requête applicative aboutirait.

L’épisode raconte moins la transformation du DNS en répartiteur de charge que la reconnaissance d’une frontière. L’opérateur pouvait choisir la méthode de classement et publier le résultat. Les secondaires et les caches réglaient sa propagation. Le client conservait le choix final. RFC 1794 décrit une manière de travailler dans ces limites ; il ne prouve ni l’ampleur de son adoption ni ses performances.

Sources