Résumé

  • Avec un seul serveur faisant autorité, APNIC Labs observait 3,43 requêtes par test; avec deux serveurs, 2,57. La part des tests ne produisant qu’une requête est passée de 58 % à 71 %.
  • L’expérience n’identifie pas de cause. Elle fragilise surtout l’hypothèse selon laquelle une adresse publique correspond à un résolveur unique doté d’un état cohérent.
  • Pour expliquer une répétition, il faut relier la demande du client, le répartiteur, le moteur récursif, l’état du cache, la destination faisant autorité, la réponse et la décision de relance.
Mesure Un serveur Deux serveurs
Nombre de tests 254 894 985 150 221 951
Requêtes observées 875 316 423 385 725 364
Requêtes par test 3,43 2,57
Tests avec une seule requête 58 % 71 %
Répétitions moyennes parmi les tests concernés 3,80 2,56

Le changement visible n’était pas une panne

Le protocole expérimental décrit par APNIC Labs est important parce qu’il évite une explication trop commode. La zone témoin disposait d’un serveur faisant autorité, joignable en IPv4 et en IPv6. La seconde configuration a ajouté un autre nom de serveur ainsi que ses deux adresses. Les réponses restaient positives. On n’observait donc pas un résolveur s’acharnant sur un silence ou un SERVFAIL.

La différence est pourtant nette. Le premier dispositif a reçu plus de 875 millions de requêtes pour près de 255 millions de tests. Le second, environ 386 millions pour 150 millions de tests. Le rapport moyen tombe de 3,43 à 2,57. Surtout, treize points supplémentaires de tests se terminent après une seule requête vue à l’autorité.

Ces nombres ne permettent pas de proclamer qu’un deuxième serveur accélère toujours le DNS. Les populations d’essai et leurs volumes ne sont pas identiques, et le point d’observation ne voit qu’une partie de la résolution. Le fait solide est plus restreint : après l’élargissement du choix faisant autorité, la distribution des paquets reçus a changé.

Les premières dizaines de millisecondes sont le vrai indice

Si un délai d’attente classique expliquait tout, les répétitions devraient s’ordonner autour de quelques temporisations reconnaissables. Or une grande partie de l’écart apparaît entre 10 et 70 millisecondes, avec une concentration entre 10 et 40 ms. C’est plus rapide que les délais UDP individuels habituellement invoqués. Les répétitions en rafale, sous 10 ms, passent elles aussi d’environ 17 % à 12 %.

La forme entière mérite attention. Avec un serveur, les pics se situent près de 100, 310 et 800 ms. Avec deux, d’autres pics apparaissent vers 50, 370 et 750 ms. Environ 85 % des doublons surviennent dans la première seconde dans le cas à un serveur, contre 75 % dans l’autre; dans les deux cas, près de 90 % sont arrivés avant cinq secondes.

Une autre étude d’APNIC sur les réponses négatives et l’absence de réponse aide à ne pas mélanger les mécanismes. Elle mesurait 3,43 requêtes pour une réponse positive, 51,73 pour SERVFAIL et 83,46 en cas de silence. Là, la classe de réponse et la mise en cache des échecs dominaient. Ici, des réponses positives sont maintenues et seule la surface faisant autorité s’élargit.

Derrière une IP, une fabrique de décisions

APNIC avance une hypothèse sans la présenter comme démontrée : certains grands services récursifs peuvent placer un répartiteur devant plusieurs moteurs. Le client voit une adresse durable. Le répartiteur distribue les demandes. Deux moteurs sans état de cache partagé, ou avec des travaux déjà engagés, peuvent produire des paquets très proches que l’autorité attribue à la même IP publique.

La documentation officielle de dnsdist confirme que cette architecture est banale : une façade reçoit les requêtes, choisit des serveurs en aval puis renvoie les réponses. Les politiques possibles ne se limitent pas à une simple alternance; elles comprennent le nombre de requêtes en cours, des fonctions de hachage et des poids. Les réglages de performance ajoutent plusieurs fils d’écoute et de réponse. Mais cette documentation ne transforme pas l’hypothèse en diagnostic. L’expérience ne révèle ni le logiciel, ni le moteur choisi, ni l’état interne des résolveurs observés.

L’adresse remplit donc parfaitement son rôle de routage tout en échouant comme identité d’exécution. Elle peut représenter un site anycast, un répartiteur, un groupe de processus ou une politique qui évolue pendant une résolution. Inversement, plusieurs paquets portant la même source peuvent appartenir à un seul travail logique.

Un tuple ne ferme pas le dossier

RFC 9520 distingue le serveur, son adresse et le transport. Il formalise le travail autour de QNAME, QTYPE et QCLASS. RFC 1035 décrit aussi l’identifiant de message sur 16 bits qui associe une réponse à une requête en attente. Ces champs sont nécessaires pour raisonner proprement; ils ne donnent pas, à eux seuls, l’identité de la résolution.

Un répartiteur peut réécrire l’identifiant. Deux moteurs peuvent en produire un identique. Une requête satisfaite par le cache ne laisse aucune trace auprès du serveur faisant autorité. Le journal distant ignore le client initial, le moteur sélectionné, l’horloge qui a expiré et le moment où la réponse a été déclarée suffisante.

Il faut donc remplacer l’identité supposée par une chaîne de reçus. Le premier reçu concerne la demande du client et son échéance. Le répartiteur enregistre le moteur choisi. Le moteur note l’état du cache et de la délégation. Chaque émission conserve le nom et l’adresse du serveur cible, le transport, le tuple et l’heure. Chaque réponse conserve sa classe et son résultat de validation. Toute répétition indique la condition qui l’a autorisée. Enfin, un reçu de clôture rattache la réponse rendue au client à ce travail logique.

Cette chaîne peut traverser plusieurs organisations et n’a pas besoin d’être rendue publique. Elle doit seulement exister assez longtemps pour qu’un opérateur cesse d’utiliser l’IP partagée comme jointure imaginaire.

Le nombre de serveurs n’est pas la conclusion

RFC 2182 exige la pluralité des serveurs faisant autorité et insiste sur leur séparation réseau et géographique. Il rappelle également le coût opérationnel d’une multiplication mal maîtrisée. Cette logique de résilience reste intacte. L’expérience APNIC ne démontre ni une règle de vitesse, ni un mécanisme causal particulier.

Elle laisse ouvertes plusieurs familles d’explication : choix du serveur, comportement IPv4/IPv6, affinité du répartiteur, partage du cache, concurrence entre moteurs ou état non observé. La rigueur consiste à préserver cette incertitude tout en acceptant le constat gênant : un champ d’adresse que beaucoup de tableaux de bord traitent comme un acteur stable ne portait pas cette signification.

Sources