Як протокол 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.обидва вони є коректно правильними (яке з двох залежить від обставин).

— kasperd

Клієнт не знає заздалегідь, що відповідь буде занадто великою, тому він запитує сервер через 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-з'єднання відкритим.

— Бармар