Comment le protocole DNS bascule-t-il d'UDP à TCP?

Avant que quelqu'un ne demande: J'ai vu Quand les requêtes DNS utilisent-elles TCP au lieu d'UDP? et cela ne répond pas à ma question.

Tout ce que j'entends, c'est " si la réponse est trop longue, DNS utilisera TCP ". Cela n'explique cependant pas comment cela se produit.

Voici donc la situation: le client DNS demande la résolution d'un enregistrement en utilisant UDP. Le record est trop long pour UDP:

le serveur répond avec un opcode spécifique, pour que le client passe à TCP
le serveur ne répond pas du tout et le client réessaye via TCP
le serveur ouvre une connexion TCP au client (stupide, si vous comptez NAT, mais qui sait?)
le client en quelque sorte (?) sait que la requête donnée doit être exécutée sur TCP afin de ne pas déranger avec UDP en premier lieu
Les pixies DNS transforment par magie UDP en TCP en cas de besoin

J'ai cherché partout sur Internet pour la réponse, mais il y a beaucoup de bruit (voir ci-dessus), et je n'arrive pas à écrire la bonne requête Google à ce sujet (je ne peux pas non plus trouver les informations dans les RFC, d'ailleurs) .

domain-name-system rfc

— StanTastic
source

Tout ce que j'ai pu trouver était dans la RFC5966: "Un résolveur DEVRAIT envoyer une requête UDP d'abord, mais PEUT choisir d'envoyer une requête TCP à la place s'il a de bonnes raisons de s'attendre à ce que la réponse soit tronquée si elle était envoyée via UDP (avec ou sans EDNS0 ) ou pour d'autres raisons opérationnelles, notamment s'il dispose déjà d'une connexion TCP ouverte avec le serveur. ". Quand le résolveur doit-il "s'attendre" à ce que la réponse soit tronquée?

— StanTastic

Un exemple évident serait si une demande précédente pour le même enregistrement était trop longue pour tenir dans un datagramme UDP.

— David Schwartz

Il y a donc un opcode qui dit «tronqué», non? Et ça change alors - essentiellement ce que je pensais, c'est la solution la plus évidente.

— StanTastic

Le cas (d) peut être un choix judicieux si la requête contient plusieurs "questions" (adresses à résoudre). Si vous devez résoudre 100 adresses, vous ne pourrez pas adapter la réponse dans un seul paquet UDP.

— MSalters

1.et 4.sont à peu près corrects (lequel des deux dépend des circonstances).

— kasperd

Le client ne sait pas à l'avance que la réponse sera trop importante, il interrogera donc le serveur via UDP.
Le serveur répondra via UDP et inclura autant que possible et définira le bit d'en-tête tronqué ("TC" http://www.networksorcery.com/enp/protocol/dns.htm ).
Le client peut ensuite renvoyer la demande via TCP et obtenir la réponse complète.

Voir aussi: https://tools.ietf.org/html/rfc5966

En l'absence d'EDNS0 (mécanismes d'extension pour DNS 0) (voir ci-dessous), le comportement normal de tout serveur DNS devant envoyer une réponse UDP qui dépasserait la limite de 512 octets est que le serveur tronque la réponse pour qu'elle corresponde dans cette limite, puis définissez l'indicateur TC dans l'en-tête de réponse. Lorsque le client reçoit une telle réponse, il prend l'indicateur TC comme une indication qu'il doit réessayer sur TCP à la place.

Et: https://www.ietf.org/rfc/rfc2181.txt

Et comme mentionné dans les commentaires, bien sûr, les transferts de zone DNS utilisent toujours TCP.

— truqueur
source

La RFC 5966 note également que TCP est toujours utilisé pour les transferts de zone.

— Matt Nordhoff

@MattNordhoff C'est vrai et c'est bon à mentionner. Cela visait davantage le «comment fonctionne le passage d'UDP à TCP? angle. Mais je vais l'ajouter à la réponse.

— faker

Cependant, s'il existe déjà une connexion TCP, il n'utilisera que TCP

— Jim B

Oh c'est intéressant. Alors, quand revient-il à UDP?

— StanTastic

@JimB Êtes-vous sûr de cela? Je ne pense pas qu'il garde une connexion TCP persistante ouverte.

— Barmar