Почему это важно
Практическое пояснение: лимит на один 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
Internet Engineering Task Force · RFC 7766, March 2016
Полный текст RFC 7766 (март 2016) прочитан локально 09.09.2026 при подготовке кластера «DNS по TCP»; сверены заголовок, редакция и нормы о поддержке TCP, усечении и соединениях. retrieved_on — дата постановки в очередь.
Открыть первоисточник