Cum trece protocolul DNS de la UDP la TCP? (Administrarea sistemului, Sistem De Nume De Domeniu, Rfc)

StanTastic a intrebat.

Înainte ca cineva să întrebe: Am văzut Când interogările DNS folosesc TCP în loc de UDP? și nu răspunde la întrebarea mea.

Tot ce aud este „dacă răspunsul este prea lung, DNS va folosi TCP„. Totuși, acest lucru nu explică cum se întâmplă.

Deci, iată care este situația: Clientul DNS solicită rezoluția unei înregistrări folosind UDP. Înregistrarea este prea lungă pentru UDP:

  1. serverul răspunde cu un opcode specific, pentru ca clientul să treacă la TCP.
  2. serverul nu răspunde deloc, iar clientul încearcă din nou prin TCP
  3. serverul deschide o conexiune TCP către client (o prostie, dacă se pune la socoteală NAT, dar cine știe?)
  4. clientul „știe” cumva (?) că o anumită interogare ar trebui să fie executată prin TCP, astfel încât nu se deranjează cu UDP de la început.
  5. pixii DNS transformă în mod magic UDP în TCP atunci când este necesar.

Am căutat răspunsul pe tot internetul, dar există mult zgomot (a se vedea mai sus) și nu reușesc să scriu o interogare corectă pe Google pentru acest lucru (și nici nu pot găsi informații în RFC-uri, de altfel).

Comentarii

  • Tot ce am putut găsi a fost în RFC5966: „Un rezolvator TREBUIE să trimită mai întâi o interogare UDP, dar POATE alege să trimită în schimb o interogare TCP dacă are motive întemeiate să se aștepte ca răspunsul să fie trunchiat dacă ar fi trimis prin UDP (cu sau fără EDNS0) sau din alte motive operaționale, în special dacă are deja o conexiune TCP deschisă la server.”. Când ar trebui ca rezolvatorul să se „aștepte” ca răspunsul să fie trunchiat? –  > Por StanTastic.
  • Un exemplu evident ar fi dacă o cerere anterioară pentru aceeași înregistrare a fost prea lungă pentru a încăpea într-o datagramă UDP. –  > Por David Schwartz.
  • Deci există un opcode care spune „trunchiat”, nu? Și se comută apoi – în principiu, ceea ce am crezut, este cea mai evidentă soluție. –  > Por StanTastic.
  • Cazul (d) poate fi o alegere înțeleaptă dacă interogarea conține mai multe „întrebări” (adrese de rezolvat). Dacă trebuie să rezolvi 100 de adrese, nu vei putea să încadrezi răspunsul într-un singur pachet UDP. –  > Por MSalters.
  • 1. și 4. sunt amândouă aproximativ corecte (care dintre cele două depinde de circumstanțe). –  > Por kasperd.
1 răspunsuri
faker

Clientul nu știe dinainte că răspunsul va fi prea mare, așa că va interoga serverul prin UDP.
Serverul va răspunde prin UDP și va include cât mai mult posibil și va seta bitul de antet trunchiat („TC” http://www.networksorcery.com/enp/protocol/dns.htm).
Clientul poate retrimite apoi cererea prin TCP și poate obține răspunsul complet.

A se vedea, de asemenea: https://tools.ietf.org/html/rfc5966

În absența EDNS0 (Extension Mechanisms for DNS 0) (a se vedea mai jos), comportamentul normal al oricărui server DNS care trebuie să trimită un răspuns UDP care ar depăși limita de 512 octeți este ca serverul să truncheze răspunsul astfel încât să se încadreze în această limită și apoi să seteze indicatorul TC în antetul de răspuns. Atunci când clientul primește un astfel de răspuns, acesta consideră indicatorul TC ca fiind o indicație că ar trebui să încerce din nou prin TCP.

Și: https://www.ietf.org/rfc/rfc2181.txt

Și, după cum s-a menționat în comentarii, bineînțeles că transferurile de zone DNS utilizează întotdeauna TCP.

Comentarii

  • RFC 5966 menționează, de asemenea, că TCP este întotdeauna utilizat pentru transferurile de zonă. –  > Por Matt Nordhoff.
  • @MattNordhoff Corect, este adevărat și este bine de menționat. Aceasta viza mai mult unghiul „cum funcționează trecerea de la UDP la TCP?”. Dar o voi adăuga la răspuns. –  > Por faker.
  • Cu toate acestea, dacă există deja o conexiune TCP, se va folosi doar TCP –  > Por Jim B.
  • Oh, asta e interesant. Deci, când se revine la UDP? –  > Por StanTastic.
  • @JimB Sunteți sigur de asta? Nu cred că menține deschisă o conexiune TCP persistentă. –  > Por Barmar.