Практикум по RFC 7766

DNS по TCP: соединение, полный ответ и восстановление

Разберите обмен DNS по TCP: когда соединение открывают повторно, как сопоставлять ответы при запросах без ожидания и что делать после разрыва. Задания основаны на RFC 7766; настройки конкретного сервера проверяются отдельно.

Практика → проверка решения150 минут10 модулей20 вопросов
После курса

Что вы сможете сделать

  1. Различать поддержку транспорта, повторное использование соединения и запросы без ожидания.
  2. Сопоставлять ответы с запросами при изменении порядка готовности.
  3. Считать полноту сообщения и применять условия простоя к нужной стороне.
  4. Разделять лимиты клиента и сервера и выбирать неотвеченные запросы для повтора.
Модуль 1 из 10

Роль узла, выбор транспорта и путь ответа

Разбираем сохранённый RFC 7766 от марта 2016 года. Его требования к реализации и рекомендации по эксплуатации не заменяют проверку конкретного программного продукта.

  • Реализации DNS общего назначения должны поддерживать UDP и TCP. RFC 7766 отдельно требует поддержку TCP от авторитетных серверов, рекурсивных серверов и пересылающих запросы серверов, а также от локальных DNS-клиентов.

    Проверить тезис: DNS по TCP: выбор транспорта и повторное использование соединения 01

  • Локальные DNS-клиенты и рекурсивные резолверы могут выбирать UDP или TCP по условиям эксплуатации. Разрешено отправить запрос по TCP до любых запросов по UDP; обязательной предварительной попытки по UDP нет.

    Проверить тезис: DNS по TCP: выбор транспорта и повторное использование соединения 02

  • Рекурсивные и авторитетные DNS-серверы должны отвечать тем же транспортом, которым получен запрос. Для TCP ответ должен идти по тому же соединению.

    Проверить тезис: DNS по TCP: выбор транспорта и повторное использование соединения 03

Модуль 2 из 10

Что повторно используется и откуда берётся задержка

Сначала установите, сохраняется ли одно соединение. Постоянное соединение, повторное использование и запросы без ожидания предыдущих ответов — разные признаки.

  • Постоянное TCP-соединение сервер не закрывает сразу после отправки первого ответа, а клиент — сразу после получения первого ответа. Повторное использование означает передачу нескольких DNS-запросов и ответов по одному соединению.

    Проверить тезис: DNS по TCP: выбор транспорта и повторное использование соединения 04

  • Клиентам и серверам рекомендуется поддерживать повторное использование TCP-соединения для нескольких DNS-запросов и ответов. Резолверу, у которого уже открыто соединение с нужным сервером, рекомендуется использовать это соединение.

    Проверить тезис: DNS по TCP: выбор транспорта и повторное использование соединения 05

  • Дополнительная задержка установления TCP-соединения обычно составляет один RTT — время обмена туда и обратно. Повторное использование позволяет распределить эти затраты между несколькими DNS-запросами.

    Проверить тезис: DNS по TCP: выбор транспорта и повторное использование соединения 06

  • Раздел 9 о TCP Fast Open имеет ненормативный статус. Передача данных при установлении соединения может сократить задержку обмена максимум на один RTT по сравнению с обычным TCP.

    Проверить тезис: DNS по TCP: выбор транспорта и повторное использование соединения 07

Модуль 3 из 10

Отправка без ожидания и обязанности сервера

Отделяйте готовность принять несколько запросов подряд от параллельного исполнения. В документе это разные модальности.

  • Pipelining в DNS означает передачу нескольких запросов по одному TCP-соединению без ожидания ответов на уже отправленные запросы перед отправкой следующего запроса.

    Проверить тезис: DNS по TCP: запросы без ожидания и сопоставление ответов 01

  • Клиентам DNS рекомендуется отправлять запросы без ожидания ответа на предыдущий запрос. При выборе момента отправки очередного запроса рекомендуется одинаково рассматривать TCP и UDP.

    Проверить тезис: DNS по TCP: запросы без ожидания и сопоставление ответов 02

  • DNS-сервер должен быть готов получать несколько запросов подряд без ожидания ответов. Серверу рекомендуется обрабатывать TCP-запросы параллельно и отвечать на все такие запросы, даже если запросы получены с короткими интервалами.

    Проверить тезис: DNS по TCP: запросы без ожидания и сопоставление ответов 03

Модуль 4 из 10

Порядок готовности и проверка полей

Быстрый ответ может обогнать медленный. Привязывайте ответ к исходному запросу, а не к позиции в очереди.

  • Авторитетным серверам и рекурсивным резолверам рекомендуется поддерживать параллельную подготовку ответов и отправку ответов не в порядке отправки запросов. Локальные DNS-клиенты и рекурсивные резолверы должны обрабатывать ответы, пришедшие не в порядке отправки запросов.

    Проверить тезис: DNS по TCP: запросы без ожидания и сопоставление ответов 04

  • Клиент не должен повторно использовать Message ID запроса, на который ещё ожидается ответ, в том же TCP-соединении. Это предотвращает совпадение идентификаторов одновременно ожидаемых ответов.

    Проверить тезис: DNS по TCP: запросы без ожидания и сопоставление ответов 05

  • Клиент должен сопоставлять ответ с ожидаемым запросом в том же TCP-соединении по Message ID. Если ответ содержит секцию вопроса, должны совпасть также QNAME, QCLASS и QTYPE.

    Проверить тезис: DNS по TCP: запросы без ожидания и сопоставление ответов 06

Модуль 5 из 10

Поле длины и неполное чтение

Размер DNS-части и объём одного чтения учитывайте отдельно. Одной отправке не обязаны соответствовать один сегмент и одно чтение.

  • Двухоктетное поле длины и описываемое им DNS-сообщение рекомендуется передавать на уровень TCP одновременно, например одним вызовом write. Это повышает вероятность передачи одним сегментом, но не гарантирует её.

    Проверить тезис: DNS по TCP: чтение сообщения и таймаут простоя 01

  • DNS-сообщение может прийти в нескольких TCP-сегментах. Сервер не должен закрывать соединение только потому, что первое чтение из TCP не содержит DNS-сообщение целиком.

    Проверить тезис: DNS по TCP: чтение сообщения и таймаут простоя 02

Модуль 6 из 10

Чей простой измеряется и когда сбрасывается таймер

Клиент знает о своей очереди отправки, сервер — о полученных обращениях. Новая порция байтов не всегда завершает сообщение.

  • Для DNS-клиента соединение простаивает, когда нет ни запросов на отправку, ни ожидаемых ответов. Для DNS-сервера соединение простаивает после отправки ответов на все запросы, полученные по этому соединению.

    Проверить тезис: DNS по TCP: чтение сообщения и таймаут простоя 03

  • DNS-клиенты должны принимать меры для сокращения времени простоя соединений с каждым сервером. Простаивающее соединение рекомендуется закрывать, если время простоя не установлено отдельным механизмом сигнализации.

    Проверить тезис: DNS по TCP: чтение сообщения и таймаут простоя 04

  • Для серверного таймаута простоя на уровне приложения рекомендуется значение порядка секунд, без единого точного числа. При наличии ресурсов сервер может держать соединения дольше; при большой нагрузке или атаке допускается нулевой таймаут.

    Проверить тезис: DNS по TCP: чтение сообщения и таймаут простоя 05

  • Серверу рекомендуется сбрасывать таймер простоя после получения полного DNS-сообщения, а не после получения любой части сообщения.

    Проверить тезис: DNS по TCP: чтение сообщения и таймаут простоя 06

  • Упоминание простоя порядка двух минут в разделе 6.1 — цитата прежнего RFC 1035. Собственные рекомендации RFC 7766 о серверном простое находятся в разделе 6.2.3 и говорят о порядке секунд без точного значения.

    Проверить тезис: DNS по TCP: чтение сообщения и таймаут простоя 07

Модуль 7 из 10

Клиентский ориентир и несколько клиентов за адресом

Считайте подключения к одному серверу по назначению. Не приравнивайте общий IP-адрес к одному программному клиенту.

  • DNS-клиент должен принимать меры для сокращения числа одновременных TCP-соединений с одним сервером. Рекомендуется не более одного соединения для обычных запросов, одного для передачи зон и одного для каждого используемого протокола поверх TCP. При одновременной передаче нескольких активно используемых зон могут понадобиться дополнительные соединения.

    Проверить тезис: DNS по TCP: лимиты соединений и восстановление после разрыва 01

  • Сервер может ограничивать число TCP-соединений от IP-адреса или подсети. Такие лимиты рекомендуется делать существенно менее жёсткими, чем рекомендации для клиента: за одним адресом могут находиться несколько резолверов или клиентов, в том числе за NAT.

    Проверить тезис: DNS по TCP: лимиты соединений и восстановление после разрыва 02

Модуль 8 из 10

Параметры сервера и область совета об ACL

Перечень настроек помогает составить проверку. Значения для продукта и условия допустимого доступа требуют отдельного обоснования.

  • В качестве настраиваемых параметров RFC 7766 перечисляет общее число TCP-соединений, максимум на IP-адрес или подсеть, таймаут простоя, число DNS-транзакций на соединение и длительность соединения. Конкретные значения этих параметров документ не рекомендует.

    Проверить тезис: DNS по TCP: лимиты соединений и восстановление после разрыва 03

  • Операторам рекурсивных серверов рекомендуется принимать соединения только от ожидаемых клиентов, например с помощью ACL, и отклонять соединения от неизвестных источников.

    Проверить тезис: DNS по TCP: лимиты соединений и восстановление после разрыва 04

Модуль 9 из 10

Разрыв соединения и оставшиеся обращения

Отслеживайте полученные ответы отдельно от отправленных запросов. Рекомендация повторить запросы не задаёт готовый алгоритм повторов.

  • Обычно закрытие простаивающего соединения начинает DNS-клиент, но сервер может закрыть соединение по своему таймауту простоя. При необычных условиях, включая защиту от атаки, сбой или перезапуск, соединение может закрыть любая сторона.

    Проверить тезис: DNS по TCP: лимиты соединений и восстановление после разрыва 05

  • Если TCP-соединение закрылось до получения всех ожидаемых ответов, DNS-клиенту рекомендуется повторить запросы, оставшиеся без ответа. Конкретный алгоритм повторов RFC 7766 не задаёт.

    Проверить тезис: DNS по TCP: лимиты соединений и восстановление после разрыва 06

Модуль 10 из 10

Ответ подготовлен, соединение прервалось

Сохранённый на сервере результат и полученный клиентом ответ — разные состояния. В итоговом разборе связывайте правило с конкретным сообщением и соединением.

  • Если клиент закрыл TCP-соединение или соединение прервалось до отправки всех ответов, DNS-сервер не должен пытаться отправлять оставшиеся ответы. Сервер может сохранить эти ответы в кэше.

    Проверить тезис: DNS по TCP: лимиты соединений и восстановление после разрыва 07

  • Рекурсивные и авторитетные DNS-серверы должны отвечать тем же транспортом, которым получен запрос. Для TCP ответ должен идти по тому же соединению.

    Проверить тезис: DNS по TCP: выбор транспорта и повторное использование соединения 03

  • Клиент должен сопоставлять ответ с ожидаемым запросом в том же TCP-соединении по Message ID. Если ответ содержит секцию вопроса, должны совпасть также QNAME, QCLASS и QTYPE.

    Проверить тезис: DNS по TCP: запросы без ожидания и сопоставление ответов 06

Финишная прямая

Проверьте инженерное мышление

Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.

01Авторитетный узел и рекурсор работают с обоими транспортами. Системная библиотека отправляет обращения только по UDP, хотя приёмка требует полной реализации DNS. Как оценить ограничение библиотеки по RFC 7766?
02Запрос поступил в соединение X. Сервер вернул ответ через соединение Y к тому же клиентскому адресу. Оба соединения используют TCP. Как оценить такой обмен?
03Три обращения прошли последовательно по подключению A. Каждое следующее обращение отправляли лишь после получения предыдущего результата. Какой признак подтверждает такая запись?
04В отчёте по RFC 7766 записали: «TCP Fast Open обязателен; каждый повторный запуск сэкономит один RTT». Как поправить оба вывода?
05У клиента готов следующий DNS-запрос, но отправка всегда ждёт предыдущего ответа. Какое изменение соответствует рекомендации RFC 7766 о времени отправки?
06В рецензии готовность к быстрой серии обращений и одновременную обработку объявили одинаково обязательными. Какая запись сохраняет различие исходных условий RFC 7766?
07В одном соединении полный список Message ID запросов, на которые ещё ожидаются ответы: 10, 20, 30. Какой из предложенных номеров свободен для нового обращения?
08DNS-клиент получил ответ с ожидаемым Message ID в нужном TCP-соединении. Секция вопроса присутствует. Какой набор полей §7 RFC 7766 прямо требует сверить с исходным запросом?
09Объявленная длина самой DNS-части — 96 октетов. Первое чтение вернуло 10 октетов, включая полностью полученное двухоктетное поле длины. Сколько октетов DNS-части ещё нужно получить?
10Отправитель передал префикс и сообщение одним write. Наблюдатель видит несколько TCP-сегментов и объявляет отправку неправильной. Какой вывод подтверждается разделом 8?
11Сервер отправил ответы на все поступившие обращения. У клиента есть новое обращение, которое ещё не передано. Как стороны определяют простой на уровне приложения?
12Незаконченный запрос поступает малыми частями. Любой новый фрагмент начинает отсчёт простоя заново, поэтому соединение держится открытым. Какую правку рекомендует RFC 7766?
13Один резолвер уже выделил отдельные подключения для передачи зоны и для TLS. Теперь он выбирает число одновременных подключений для обычных запросов к тому же узлу. Какой верхний ориентир RFC 7766 относится именно к этой категории?
14За одним внешним адресом находятся восемь независимых резолверов. Оператор перенёс клиентский ориентир одного подключения в жёсткий серверный лимит на адрес. Какое обоснование согласуется с рекомендацией RFC 7766?
15В проекте настройки записаны точные значения общего лимита и максимальной длительности, а единственным основанием назван раздел 10 RFC 7766. Как оформить ссылку?
16Рекомендацию принимать обращения от известных клиентов перенесли с рекурсора на общедоступный авторитетный сервис. Как точнее определить область пункта 10?
17Отправлены обращения K, L, M, N, P и Q. Ответы K и N получены. После этого соединение закрылось. Сколько обращений попадает в набор повтора по прочитанной рекомендации?
18В плане восстановления написано: «RFC 7766 требует три попытки с фиксированным интервалом». Как исправить ссылку на документ?
19Сервер подготовил результат, но клиентское соединение прервалось до передачи. Какой шаг сервера с этим результатом соответствует разделу 6.2.4?
20Сервер закрывает подключение после короткого простоя; следующее обращение проходит по новому каналу. Отчёт объявляет любое серверное закрытие нарушением постоянного соединения. Какой план проверки сохраняет границы RFC 7766?
Проверяемая база

Источники курса

Полные сведения о первоисточниках приведены один раз для всего курса. Под тезисами — ссылки на соответствующие утверждения Архивариума.

  • Первичная спецификация

    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 — дата постановки в очередь.

    Открыть первоисточник

Delect.ru — информационный справочник: сведения о ценах, наличии и брендах формируются из данных витрины для анализа и сравнения. Наличие по данным витрины лучше дополнительно уточнять у выбранного поставщика; перед закупкой обязательно ставьте резервы. Сервис не является посредником при сделке и не сторона договора; коммерческие условия согласуются напрямую с выбранным дистрибьютором. Обозначения брендов приводятся для идентификации предложений.

Подтвердите действие