Почему это важно
Практическое пояснение: получение первых байтов ещё не означает, что сообщение прочитано полностью. В проверке клиента и сервера полезно отдельно учитывать полноту сообщения, ожидаемые ответы и время простоя.
Что подтверждено
Двухоктетное поле длины и описываемое им DNS-сообщение рекомендуется передавать TCP вместе, например одним вызовом write. Это повышает вероятность передачи одним сегментом, но не гарантирует её.
Граница применимости: RFC 7766, март 2016 года; раздел 8, стр. 11. Используется SHOULD; единый вызов write — пример. Границы TCP-сегментов не объявляются обязательными границами DNS-сообщений.
DNS-сообщение может прийти в нескольких TCP-сегментах. Сервер не должен закрывать соединение только потому, что первое чтение из TCP не содержит DNS-сообщение целиком.
Граница применимости: RFC 7766, март 2016 года; разделы 6.2.3 и 8, стр. 9 и 11. Запрет MUST NOT относится к одной этой причине закрытия; таймауты и прочие допустимые причины закрытия сохраняются.
Для DNS-клиента соединение простаивает, когда нет ни запросов на отправку, ни ожидаемых ответов. Для DNS-сервера соединение простаивает после отправки ответов на все запросы, полученные по этому соединению.
Граница применимости: RFC 7766, март 2016 года; раздел 3, стр. 4. Это два определения простоя на уровне приложения. Сервер не знает о ещё не отправленном запросе клиента.
DNS-клиенты должны принимать меры для сокращения времени простоя соединений с каждым сервером. Простаивающее соединение рекомендуется закрывать, если время простоя не установлено отдельным механизмом сигнализации.
Граница применимости: RFC 7766, март 2016 года; раздел 6.2.3, стр. 9. Общее требование MUST и рекомендация SHOULD с исключением сохранены. Полный протокол edns-tcp-keepalive не пересказывается.
Для серверного таймаута простоя на уровне приложения рекомендуется значение порядка секунд, без единого точного числа. При наличии ресурсов сервер может держать соединения дольше; при большой нагрузке или атаке допускается нулевой таймаут.
Граница применимости: RFC 7766, март 2016 года; раздел 6.2.3, стр. 9. Рекомендован порядок величины, а не обязательный минимум или универсальная настройка. Условие большой нагрузки или атаки относится к нулевому таймауту.
Отсчёт серверного таймаута простоя рекомендуется начинать заново после получения полного DNS-сообщения, а не после получения любой части сообщения.
Граница применимости: RFC 7766, март 2016 года; раздел 6.2.3, стр. 9. SHOULD сохраняет рекомендательный характер. Получение одного TCP-сегмента не доказывает полноту DNS-сообщения.
Упоминание простоя порядка двух минут в разделе 6.1 — цитата прежнего RFC 1035. Собственные рекомендации RFC 7766 о серверном простое находятся в разделе 6.2.3 и говорят о порядке секунд без точного значения.
Граница применимости: RFC 7766, март 2016 года; разделы 6.1 и 6.2.3, стр. 6 и 9. Различаются описание прежней практики и рекомендации этого RFC. Полный RFC 1035 здесь не объявляется отдельно прочитанным.
Что проверить
- Различайте поле длины, DNS-сообщение, TCP-сегмент и результат чтения.
- Проверьте получение сообщения несколькими чтениями до истечения тайм-аута простоя.
- Зафиксируйте, какое событие начинает отсчёт простоя заново.
- Раздельно определите простой для клиента и сервера.
- Не переносите цитату прежней практики в обязательное значение таймаута.
Первоисточники
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 — дата постановки в очередь.
Открыть первоисточник