DNS и TCP

Очень популярное заблуждение: DNS использует только UDP. Это заблуждение постоянно мешает на практике. Конечно, протокол UDP является основным протоколом обмена данными между клиентами и серверами в DNS. Это так. Однако UDP используется при наличии возможности, а DNS, как система, строго требует доступности серверов и по TCP. Причём, TCP является ничуть не менее “стандартным” протоколом для DNS. То есть, необходима поддержка и UDP, и TCP.

Хрестоматийный исторический пример использования TCP вместо UDP в DNS, это превышение максимального объёма данных, которые удаётся передать по UDP. Здесь часто упоминают 512 байтов, как предельное количество. Но, опять же, то и дело упускают контекст, к которому лимит в 512 байтов относится. Эти знаменитые 512 байтов, во-первых, происходят из принципов фрагментации пакетов в IP-сетях, – так-то в UDP можно передать гораздо больше, – да ещё и относятся, как ограничение, конкретно к классическому DNS: то есть, из-за 512 байтов в Интернете 13 логических корневых серверов DNS, например. Сетевые детали оставим для другой записки, а в этой важно отметить, что и лимит давно не 512 байтов, потому что есть расширение под общим названием EDNS, позволяющее задать другие границы данных ответа сервера, и возможность увеличения размера UDP-ответов пакета никак не отменяет требований по TCP.

Это всё весьма упрощенное описание. За DNS скрывается очень сложная технология, непосредственно использующая множество весьма и весьма нетривиальных особенностей в своих протоколах. Очень большой ошибкой будет посчитать, что DNS – это “запрос-ответ” про “IP-адрес”. Это только “понятийное ядро” DNS на самом базовом уровне возможно описать как элементарный протокол “запрос-ответ”. При изучении же деталей придётся быстро столкнуться с неожиданными артефактами. Например, с тем, что в DNS есть сжатие строк в DNS-сообщениях, куча хитрых статусов и флагов. Реально работающая система изобилует неожиданными “краевыми случаями”. Вот, кстати, один из примеров: рандомизация регистра символов в DNS. И это, заметьте, тут ещё ничего не сказано про DNSSEC.

В общем, вернёмся к TCP/UDP. Верная интерпретация такая: если DNS-ответ имеется, но не получается доставить его полностью по UDP, то система должна использовать TCP. Следовательно, должен быть TCP-доступ. И вовсе не только между авторитативными серверами для трансфера зоны.

К сожалению, сплошь и рядом продолжают фильтровать и отключать TCP-доступ даже к авторитативным серверам DNS, мотивируя это тем, что, мол, “DNS работает по UDP”, а поэтому прочий доступ нужно закрыть “для безопасности” (хотя, казалось бы, при чём здесь метод “порты закрыл – сервер в безопасности”?). Это неправильно и плохо: резолверы могут штатно подключаться к DNS-серверам по TCP, если им не удаётся работать по UDP, а в DNS описан типовой механизм (Truncated bit), позволяющий сообщить клиенту (резолверу), что нужно переключиться на TCP. Но это только возможный способ. Резолвер, вполне штатно, может самостоятельно перейти на TCP, если этого требует контекст запроса и сетевая конфигурация. Так что DNS работает и по TCP тоже.

Адрес записки: https://dxdt.ru/2024/12/08/14333/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

1 комментарий от читателей

  • 1 <t> // 9th December 2024, 09:25 // Читатель void написал:

    и не забываем про AXFR: если есть хоть один secondary сервер (а он обязан быть), то синхронизация зон сразу идет по TCP

Написать комментарий

Ваш комментарий:

Введите ключевое слово "GS23Z" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

Если видите "капчу", то решите её. Это необходимо для отправки комментария ("капча" не применяется для зарегистрированных пользователей). Обычно, комментарии поступают на премодерацию, которая нередко занимает продолжительное время.