7. Réorganisation des Réponses (Response Reordering)

La RFC 1035 est ambiguë sur la question de savoir si les réponses TCP peuvent être réorganisées -- le seul texte pertinent se trouve dans la section 4.2.1, qui concerne UDP :

Les requêtes ou leurs réponses peuvent être réorganisées par le réseau, ou par le traitement dans les serveurs de noms, de sorte que les résolveurs ne devraient pas dépendre de leur retour dans l'ordre.

Pour éviter tout doute futur, cette exigence est clarifiée. Il est RECOMMANDÉ (RECOMMENDED) aux serveurs faisant autorité et aux résolveurs récursifs de prendre en charge la préparation des réponses en parallèle et de les envoyer dans le désordre, quel que soit le protocole de transport utilisé. Les résolveurs stub et récursifs DOIVENT (MUST) être capables de traiter les réponses qui arrivent dans un ordre différent de celui dans lequel les requêtes ont été envoyées, quel que soit le protocole de transport utilisé.

Afin d'obtenir des performances équivalentes à UDP, les résolveurs récursifs DEVRAIENT (SHOULD) traiter les requêtes TCP en parallèle et renvoyer les réponses individuelles dès qu'elles sont disponibles, éventuellement dans le désordre.

Puisque les réponses pipelinées peuvent arriver dans le désordre, les clients DOIVENT (MUST) faire correspondre les réponses aux requêtes en attente sur la même connexion TCP en utilisant l'ID de message. Si la réponse contient une section question, le client DOIT (MUST) faire correspondre les champs QNAME, QCLASS et QTYPE. L'échec des clients à faire correspondre correctement les réponses aux requêtes en attente peut avoir de graves conséquences pour l'interopérabilité.