Кратко

  • TC сообщает, что сообщение превысило длину, допустимую каналом передачи. RFC 2181 уточнил: речь идёт о необходимом RRset, который не вошёл целиком; клиенту следует игнорировать усечённый ответ, а не считать видимые записи полным набором.
  • TCP переносил повторный, более крупный ответ, а затем перестал быть исключением. RFC 7766 потребовал от общего DNS поддержки UDP и TCP и разрешил начинать с TCP; RFC 9210 сделал ёмкость, пропуск и наблюдение обычными обязанностями эксплуатации.

Предел пакета не должен был определять имя

RFC 1035 в 1987 году задал DNS на порту 53 поверх UDP и TCP. UDP подходил для обычных вопросов: соединение не создаётся, состояние минимально, при потере можно обратиться к другому серверу. Но DNS-сообщение ограничивалось 512 байтами без заголовков IP и UDP.

Более длинный ответ усекался и получал TC=1. Бит описывал канал, а не имя. Он не означал отсутствие записи, отрицательный ответ или осознанный выбор тех значений, которые успели поместиться.

Если имени принадлежат пять адресов, а в датаграмму вошли три, размер датаграммы не получает права объявить набор из трёх авторитетным. Дефицит транспорта не должен переписывать namespace.

RRset стал неделимой единицей свидетельства

RFC 2181 в 1997 году определил записи с одинаковыми owner name, class и type как RRset. Когда эти данные обязательны, ответом служит весь набор.

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

Если TC установлен, клиенту следует игнорировать ответ и повторить запрос механизмом, допускающим больший результат, например TCP. Часть RRset может физически остаться в пакете, но она не становится пригодной для кеша и не должна соединяться со старыми фрагментами.

DNS предпочёл потерять одну попытку, а не создать ложную завершённость. Целостность доказательства оказалась важнее полезных на вид байтов.

Сервер обозначал границу, резолвер выбирал продолжение

Знакомая последовательность — запрос UDP, ответ с TC и повтор по TCP. В TCP перед DNS-сообщением стоит двухбайтовая длина, поэтому ответ не ограничен одной датаграммой.

Однако бит не открывает соединение сам. Резолвер выбирает повтор, другой сервер или уже открытую сессию; сервер задаёт допуск, параллелизм и idle timeout. Узлы, которые оплачивают состояние, сохраняют право ограничивать ресурс.

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

EDNS увеличил предложение, но не гарантировал путь

RFC 6891 позволил запрашивающей стороне объявить размер UDP payload, который она готова принять. EDNS(0) удержал много ответов больше 512 байт на UDP.

Число одного конца не измеряет каждый канал, туннель и firewall. IP-фрагменты могут теряться или фильтроваться. DNSSEC добавил подписи и доказательства, а новые типы данных увеличили ответы.

EDNS предлагает бюджет. TC признаёт, что обязательные данные не вошли в реально доступный бюджет. Объявленный размер не является квитанцией сквозной доставки. Если крупная датаграмма исчезает, TC может не прийти вовсе; поэтому timeout UDP нельзя смешивать с авторитетным отрицательным ответом.

TCP перестал быть церемониальным запасным выходом

Долгое время TCP описывали как транспорт для zone transfer и fallback после усечения. Такое сокращение подтолкнуло сети блокировать TCP/53 — именно тот выход, на который рассчитывал механизм TC.

RFC 7766 в 2016 году изменил положение TCP. Общие авторитетные и рекурсивные серверы, forwarder и stub resolver обязаны поддерживать UDP и TCP. Старое требование всегда начинать обычный запрос с UDP было ослаблено: локальная эксплуатация может выбрать TCP сразу, а открытое соединение следует использовать повторно.

Поэтому TC часто ведёт к TCP, но не управляет всем современным выбором транспорта. TCP стал самостоятельной альтернативой, позже появились и другие способы переноса DNS. Постоянно требование полноты, а не фиксированный ритуал.

Надёжный поток потребовал экономить состояние

Новое соединение на каждый вопрос повторяет handshake. RFC 7766 рекомендует reuse и pipelining: несколько запросов уходят без ожидания, сервер обрабатывает их параллельно и может ответить в другом порядке.

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

Ограничения соединений на клиента или подсеть и idle timeout остаются законными. Защита памяти, дескрипторов и workers — часть эксплуатации. Но нехватка ресурса не превращает усечённый RRset в успех.

Эксплуатация должна была увидеть оба транспорта

RFC 9210 в 2022 году потребовал, чтобы резолверы и серверы обслуживали UDP и TCP, а сетевые операторы в общем случае пропускали оба. Фильтрация TCP вредна, поскольку удаляет путь восстановления крупных ответов.

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

Мониторинг обязан собирать поток, понимать reuse, pipeline и ответы не по порядку. Панель только по UDP не видит, закончился ли TC полным ответом или тупиком.

Отказ от фрагментации сохранил значение старого бита

RFC 9715 в 2025 году рекомендовал избегать IP-фрагментации DNS/UDP и использовать 1400 байт как рекомендуемый максимум, если нет меньшего ограничения. Фрагментация хрупка и может облегчать отравление кеша.

Действие TC не изменилось. Если ответ безопасно не помещается, сервер может отметить усечение; если фрагменты исчезают, запросившая сторона должна в итоге попробовать другой транспорт. TCP тоже может быть заблокирован или перегружен. Но архитектура продолжает отличать неполученные данные от полного ответа.

Узкое утверждение оказалось долговечным

TC не доказывает сбой DNSSEC, цензуру, атаку, отсутствие имени или владение им. Не всякое отсутствие Additional требует TC, и TCP не обязан оставаться единственным большим каналом навсегда.

Надёжен ровно узкий смысл: эта передача не доставила всё необходимое. DNS допустил дешёвый первый конверт, но не позволил его границе стать правдой о содержании.

Источники и границы

История основана на RFC 1035, RFC 2181, RFC 6891, RFC 7766, RFC 9210 и RFC 9715. Они не измеряют сегодняшнюю мировую долю TC, фильтрации или успешных повторов.