Ответ
DNS в основном использует UDP на порту 53 для стандартных запросов, так как это протокол без установления соединения, что делает запросы быстрее и с меньшими накладными расходами. Однако, в нескольких специфичных случаях используется TCP (также порт 53):
- Когда размер ответа превышает 512 байт (стандартный лимит для UDP).
- При использовании расширений безопасности, таких как DNSSEC, которые увеличивают размер ответа.
- Для операций зонного трансфера (AXFR/IXFR) между primary и secondary DNS-серверами, так как передаются все записи зоны, что обычно составляет большой объем данных.
Практический пример: При развертывании и настройке DNS-серверов (например, BIND или CoreDNS) в инфраструктуре важно убедиться, что в правилах сетевого экрана (firewall) открыт как UDP, так и TCP порт 53 для корректной работы.
# Проверка, какой протокол используется по умолчанию (UDP)
dig @8.8.8.8 example.com A +short
# Принудительное использование TCP для запроса
dig @8.8.8.8 example.com A +tcp
# Запрос, который может вызвать переключение на TCP из-за большого ответа (например, с DNSSEC)
dig @8.8.8.8 example.com DNSKEY +dnssecДля DevOps-инженера: Понимание этого важно при настройке мониторинга сетевого трафика, диагностике проблем с разрешением имен в контейнеризированных средах (Kubernetes) и обеспечении безопасности DNS-трафика.
Ответ 18+ 🔞
А, слушай, вот тебе насущный вопрос, который многих вводит в ступор. DNS, казалось бы, простейшая штука — имя преврати в адрес и всё. Но нет, там под капотом целый ёперный театр с протоколами.
В общем, основная работа идёт по UDP на 53-м порту. Почему? Да потому что он без установки соединения, запрос-ответ — и свободен. Быстро, без лишних телодвижений, накладных расходов — овердохуища. Идеально для миллиардов мелких запросов в день.
Но жизнь, как всегда, вносит коррективы. В нескольких конкретных случаях эта мартышлюшка переключается на TCP (на том же 53-м порту, кстати). Вот когда:
- Когда ответ не влезает в стандартную UDP-посылку. Там исторический лимит — 512 байт. Если ответ больше (например, у сайта куча A-записей), сервер такой: «Ну, чувак, нихуя не влезло», обрезает ответ и ставит специальный флажок «truncated». Клиент видит этот флаг и, без лишних вопросов, повторяет тот же запрос, но уже по TCP. Потому что TCP может передавать данные любого размера, хоть целую книгу.
- Когда включается тяжёлая артиллерия — DNSSEC. Это расширение для безопасности, там подписи, ключи — в общем, ответ сразу раздувается, как пузырь. Без TCP тут вообще никуда.
- Самый жирный случай — зонный трансфер (AXFR/IXFR). Это когда secondary-сервер тянет всю зону (все записи домена) с primary-сервера. Представляешь объём? Это же не один запрос «где ya.ru», а вся база данных! Тут уж UDP — это как пытаться перевезти диван на велосипеде. Только TCP, только хардкор.
Для нас, инженеров, практический вывод пиздец какой важный: когда настраиваешь файрвол для DNS-сервера (тот же BIND или CoreDNS в кубере), НЕЛЬЗЯ тупо открывать только UDP 53. Обязательно надо открыть и TCP 53 тоже. Иначе в один прекрасный день какие-то запросы просто начнут отваливаться, а зонные трансферы не пойдут вообще. Будешь потом ломать голову, а проблема-то в простейшем правиле.
Вот, посмотри на практике, как это выглядит:
# Обычный запрос — летит по UDP (по умолчанию)
dig @8.8.8.8 example.com A +short
# А тут мы говорим: «Не муть воду, используй TCP с самого начала»
dig @8.8.8.8 example.com A +tcp
# А это запрос с DNSSEC. Скорее всего, ответ будет большой, и dig сам переключится на TCP,
# даже если мы явно не просили. Видишь этот флаг 'truncated' в выводе без +tcp?
dig @8.8.8.8 example.com DNSKEY +dnssecКороче, мораль для DevOps: когда мониторишь трафик в своём кластере Kubernetes и видишь TCP-пакеты на 53-й порт между подами — не пугайся, это не атака. Это либо здоровенный ответ, либо кто-то DNSSEC использует. А если трансфер зоны не работает — первым делом проверь, не забыл ли ты этот самый TCP 53 в NetworkPolicy или security group. Доверия к этим настройкам, блядь, ноль, всегда надо перепроверять.
