DNS по TCP: лимиты соединений и восстановление после разрыва
Определение
Лимиты соединений DNS по TCP — это ограничения на число одновременных TCP-соединений между клиентом и сервером. Клиенту рекомендуют не больше одного соединения для обычных запросов, а серверу — лимит на адрес или подсеть помягче: за одним адресом могут работать несколько клиентов за NAT.
Также ищут: DNS TCP connection limits · Повтор запросов DNS после разрыва TCP
Зачем это знать
Практическое пояснение: лимит на один IP-адрес может затронуть сразу нескольких клиентов за NAT. После разрыва нужно установить, какие ответы уже получены, чтобы выбрать запросы для повторной отправки.
Карта понятия
Что подтверждено
DNS-клиент должен принимать меры для сокращения числа одновременных TCP-соединений с одним сервером. Рекомендуется не более одного соединения для обычных запросов, одного для передачи зон и одного для каждого используемого протокола поверх TCP. При одновременной передаче нескольких активно используемых зон могут понадобиться дополнительные соединения.
Граница применимости: RFC 7766, март 2016 года; раздел 6.2.2, стр. 9. Минимизация — MUST; схема числа соединений — SHOULD, не жёсткий общий максимум. Исключение относится к передаче нескольких зон.
Сервер может ограничивать число TCP-соединений от IP-адреса или подсети. Такие лимиты рекомендуется делать существенно менее жёсткими, чем рекомендации для клиента: за одним адресом могут находиться несколько резолверов или клиентов, в том числе за NAT.
Граница применимости: RFC 7766, март 2016 года; раздел 6.2.2, стр. 9. Ограничение MAY и рекомендация SHOULD не задают конкретных чисел и не приравнивают IP-адрес к одному клиенту.
В качестве настраиваемых параметров RFC 7766 перечисляет общее число TCP-соединений, максимум на IP-адрес или подсеть, таймаут простоя, число DNS-транзакций на соединение и длительность соединения. Конкретные значения этих параметров документ не рекомендует.
Граница применимости: RFC 7766, март 2016 года; раздел 10, стр. 12. Это примеры управления ресурсами. Они не подтверждают доступность таких настроек в любом программном продукте.
Операторам рекурсивных серверов рекомендуется принимать соединения только от ожидаемых клиентов, например с помощью ACL, и отклонять соединения от неизвестных источников.
Граница применимости: RFC 7766, март 2016 года; раздел 10, стр. 13. Совет адресован операторам рекурсивных серверов. Это не общее требование закрыть публичный авторитетный DNS от неизвестных адресов.
Обычно закрытие простаивающего соединения начинает DNS-клиент, но сервер может закрыть соединение по своему таймауту простоя. При необычных условиях, включая защиту от атаки, сбой или перезапуск, соединение может закрыть любая сторона.
Граница применимости: RFC 7766, март 2016 года; раздел 6.2.4, стр. 10. Постоянное соединение не считается неразрываемым. Причина закрытия не выводится только из того, какая сторона начала закрытие.
Если TCP-соединение закрылось до получения всех ожидаемых ответов, DNS-клиенту рекомендуется повторить запросы, оставшиеся без ответа. Конкретный алгоритм повторов RFC 7766 не задаёт.
Граница применимости: RFC 7766, март 2016 года; раздел 6.2.4, стр. 10. Используется SHOULD. Не задаются число попыток, задержки или обязанность повторять уже отвеченные запросы.
Если клиент закрыл TCP-соединение или соединение прервалось до отправки всех ответов, DNS-сервер не должен пытаться отправлять оставшиеся ответы. Сервер может сохранить эти ответы в кэше.
Граница применимости: RFC 7766, март 2016 года; раздел 6.2.4, стр. 10. Запрет отправки — MUST NOT; кэширование — MAY. Наличие ответа в серверном кэше не подтверждает получение ответа клиентом.
Что проверить
- Посчитайте соединения с одним сервером отдельно по их назначению.
- При выборе серверного лимита учитывайте, что за одним адресом могут находиться несколько клиентов.
- Зафиксируйте доступные настройки и их единицы без выдуманных значений из RFC.
- При разрыве составьте список запросов, оставшихся без ответа.
- Проверьте восстановление после разрыва отдельно от повторного использования соединения.
Первоисточники
- DNS Transport over TCP - Implementation Requirements
Полный текст RFC 7766 (март 2016) прочитан локально 09.09.2026 при подготовке кластера «DNS по TCP»; сверены заголовок, редакция и нормы о поддержке TCP, усечении и соединениях. retrieved_on — дата постановки в очередь.