Bagaimana protokol DNS beralih dari UDP ke TCP?

Sebelum ada yang bertanya: Saya sudah melihat Kapan permintaan DNS menggunakan TCP, bukan UDP? dan itu tidak menjawab pertanyaan saya.

Yang saya terus dengar adalah " jika jawabannya terlalu panjang, DNS akan menggunakan TCP ". Ini tidak menjelaskan bagaimana itu terjadi.

Jadi inilah situasinya: Klien DNS meminta resolusi catatan menggunakan UDP. Rekor terlalu panjang untuk UDP:

server menjawab dengan opcode tertentu, agar klien beralih ke TCP
server tidak menjawab sama sekali, dan klien mencoba ulang melalui TCP
server membuka koneksi TCP ke klien (bodoh, jika Anda menghitung NAT, tapi siapa yang tahu?)
client entah bagaimana (?) 'tahu' bahwa kueri yang diberikan harus dijalankan melalui TCP sehingga tidak mengganggu UDP
Pixies DNS secara ajaib mengubah UDP menjadi TCP bila diperlukan

Saya sudah mencari di internet untuk jawabannya, tetapi ada banyak suara (lihat di atas), dan saya sepertinya tidak bisa menulis permintaan Google yang tepat untuk itu (saya juga tidak bisa menemukan info di RFC, dalam hal ini) .

domain-name-system rfc

— StanTastic
sumber

Yang dapat saya temukan adalah di RFC5966: "Penyelesai HARUS mengirim kueri UDP terlebih dahulu, tetapi MUNGKIN memilih untuk mengirim kueri TCP sebagai gantinya jika ia memiliki alasan yang baik untuk mengharapkan respons akan terpotong jika dikirim melalui UDP (dengan atau tanpa EDNS0 ) atau untuk alasan operasional lainnya, khususnya, jika sudah memiliki koneksi TCP terbuka ke server. Kapan penyelesai "berharap" bahwa respons akan terpotong?

— StanTastic

Contoh yang jelas adalah jika permintaan sebelumnya untuk catatan yang sama terlalu lama untuk dimasukkan dalam datagram UDP.

— David Schwartz

Jadi ada opcode yang mengatakan 'terpotong', kan? Dan beralih kemudian - pada dasarnya apa yang saya pikir, itu solusi yang paling jelas.

— StanTastic

Kasus (d) mungkin merupakan pilihan bijak jika kueri berisi beberapa "pertanyaan" (alamat untuk diselesaikan). Jika Anda perlu menyelesaikan 100 alamat, Anda tidak akan dapat mencocokkan respons dalam satu paket UDP.

— MSalters

1.dan 4.keduanya kira-kira benar (yang mana dari keduanya tergantung pada keadaan).

— kasperd

Klien tidak tahu sebelumnya bahwa responsnya akan terlalu besar, sehingga akan meminta server melalui UDP.
Server akan merespons melalui UDP dan akan memasukkan sebanyak mungkin dan mengatur bit header yang terpotong ("TC" http://www.networksorcery.com/enp/protocol/dns.htm ).
Klien kemudian dapat mengirim ulang permintaan melalui TCP dan mendapatkan respons penuh.

Lihat juga: https://tools.ietf.org/html/rfc5966

Dengan tidak adanya EDNS0 (Mekanisme Perpanjangan untuk DNS 0) (lihat di bawah), perilaku normal dari setiap server DNS yang perlu mengirim respons UDP yang akan melebihi batas 512-byte adalah agar server memotong respons sehingga cocok dalam batas itu dan kemudian mengatur bendera TC di header respons. Ketika klien menerima respons seperti itu, dibutuhkan bendera TC sebagai indikasi bahwa ia harus mencoba kembali melalui TCP.

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

Dan seperti yang disebutkan di komentar, tentu saja transfer zona DNS selalu menggunakan TCP.

— pemalsu
sumber

RFC 5966 juga mencatat bahwa TCP selalu digunakan untuk transfer zona.

— Matt Nordhoff

@ MatNordhoff Benar, itu benar dan bagus untuk disebutkan. Ini lebih ditujukan pada 'bagaimana beralih dari UDP ke TCP bekerja?' sudut. Tapi saya akan menambahkannya ke jawabannya.

— faker

Namun jika sudah ada koneksi TCP itu hanya akan menggunakan TCP

— Jim B

Oh, itu menarik. Jadi kapan kembali ke UDP?

— StanTastic

@ JimB Apakah Anda yakin tentang itu? Saya tidak berpikir itu membuat koneksi TCP tetap terbuka.

— Barmar