Как протокол DNS переключается с UDP на TCP?

Прежде чем кто-нибудь спросит: я видел, когда DNS-запросы используют TCP вместо UDP? и это не отвечает на мой вопрос.

Все, что я продолжаю слышать, это « если ответ слишком длинный, DNS будет использовать TCP ». Это не объясняет, как это происходит, хотя.

Итак, вот ситуация: DNS-клиент запрашивает разрешение записи с использованием UDP. Запись слишком длинная для UDP:

сервер отвечает определенным кодом операции, чтобы клиент переключился на TCP
сервер не отвечает вообще, а клиент пытается через TCP
Сервер открывает TCP-соединение с клиентом (глупо, если вы считаете NAT, но кто знает?)
клиент каким-то образом (?) «знает», что данный запрос должен выполняться по TCP, чтобы он не беспокоился о UDP в первую очередь
DNS-феи волшебным образом превращают UDP в TCP при необходимости

Я искал ответ по всему Интернету, но там много шума (см. Выше), и я не могу написать правильный запрос Google для этого (и при этом я не могу найти информацию в RFC) ,

domain-name-system rfc

— StanTastic
источник

Все, что я мог найти, было в RFC5966: «Средство распознавания ДОЛЖНО отправить сначала запрос UDP, но МОЖЕТ выбрать вместо этого отправку запроса TCP, если у него есть веские основания ожидать, что ответ будет усечен, если он был отправлен по UDP (с EDNS0 или без него). ) или по другим эксплуатационным причинам, в частности, если у него уже есть открытое TCP-соединение с сервером. ". Когда распознаватель должен «ожидать», что ответ будет усечен?

— StanTastic

Очевидным примером может быть, если предыдущий запрос на ту же запись был слишком длинным, чтобы поместиться в дейтаграмму UDP.

— Дэвид Шварц

Так что есть код операции, который говорит «усеченный», верно? И это переключается тогда - в основном то, что я думал, это самое очевидное решение.

— StanTastic

Случай (d) может быть разумным выбором, если запрос содержит несколько «вопросов» (адресов для разрешения). Если вам нужно разрешить 100 адресов, вы не сможете уместить ответ в одном UDP-пакете.

— MSalters

1.и 4.оба они примерно верны (что зависит от обстоятельств).

— Касперд

Клиент заранее не знает, что ответ будет слишком большим, поэтому он будет запрашивать сервер через UDP.
Сервер ответит по протоколу UDP и включит как можно больше и установит усеченный бит заголовка («TC» http://www.networksorcery.com/enp/protocol/dns.htm ).
Затем клиент может повторно отправить запрос через TCP и получить полный ответ.

Смотрите также: https://tools.ietf.org/html/rfc5966

В отсутствие EDNS0 (Механизмы расширения для DNS 0) (см. Ниже) нормальное поведение любого DNS-сервера, которому необходимо отправить ответ UDP, который превысил бы ограничение в 512 байт, состоит в том, что сервер усекает ответ, чтобы он соответствовал в пределах этого предела, а затем установите флаг TC в заголовке ответа. Когда клиент получает такой ответ, он принимает флаг TC в качестве указания на то, что он должен вместо этого повторить попытку по TCP.

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

И, как упоминалось в комментариях, конечно, при передаче DNS-зон всегда используется TCP.

— обманщик
источник

RFC 5966 также отмечает, что TCP всегда используется для зонных передач.

— Мэтт Нордхофф

@ MattNordhoff Правильно, это правда и приятно упомянуть. Это было больше нацелено на то, «как работает переключение с UDP на TCP?» угол. Но я добавлю это к ответу.

— Мошенник

Однако, если уже есть TCP-соединение, он будет использовать только TCP

— Jim B

О, это интересно. Так, когда это возвращается к UDP?

— StanTastic

@JimB Ты уверен в этом? Я не думаю, что он поддерживает постоянное соединение TCP открытым.

— Бармар