Резюме

  • 5 августа 2026 года IETF Datatracker перечислял за Ray Bellis десять RFC, включая только что опубликованный RFC 10029 о нескольких типах записей DNS (Multiple QTYPEs). На момент проверки активных проектов Internet-Draft не было. Индекс отражает работу за период и не означает единоличного авторства или повсеместного внедрения. [1]
  • Более ранняя спецификация DNS поверх TCP, RFC 5966, автором которой был Беллис, позже была заменена документом с пятью авторами — RFC 7766. Новый документ сделал TCP обязательной частью полноценной универсальной реализации DNS и рассматривал его как допустимый транспорт, а не только как аварийную повторную попытку после UDP. [3] [4]
  • RFC 7828 и RFC 8490 описывали состояние, возникающее при постоянных DNS-соединениях. В них определены способы сообщать время простоя, управлять сеансами, информировать о завершении и различать успех, сбой, тайм-аут и выключение. [5] [6]
  • RFC 8906 описывает само молчание как эксплуатационную проблему. Отсутствие ответа делает неразличимыми потерю пакетов, отсутствие поддержки функций, фильтрацию, ограничение скорости и неисправное поведение сервера. Документ рекомендует явные протокольные ответы в обычных условиях и описывает тесты для выявления сбоев. [7]
  • RFC 9619 закрепил практическое правило: обычный DNS-запрос содержит один основной вопрос. Затем RFC 10029 добавил опцию EDNS (Extension Mechanisms for DNS) — стандартный способ расширять обычные DNS-сообщения — для запроса связанных типов записей вместе с основным вопросом, с явным сигналом завершения, возвратом к отдельным запросам и настраиваемыми оператором ограничениями. [8] [9]

Маленький вопрос проходит через множество независимых систем

DNS-запрос начинается с имени и типа информации. Приложение может запрашивать IPv4-адрес, представленный записью A, или IPv6-адрес, представленный записью AAAA. Современная установка соединения может также требовать запись HTTPS, запись обнаружения службы или данные для проверки подписанного ответа.

Обычно приложение передаёт вопрос резолверу, предоставленному операционной системой. Этот резолвер может отправить его рекурсивному серверу. Рекурсивный сервер следует по делегированиям, пока не достигнет серверов, авторитетных для соответствующей части имени. Кэш может ответить на некоторые шаги. Между участниками могут находиться прокси, межсетевые экраны, балансировщики нагрузки и устройства трансляции сетевых адресов.

Весь этот путь не управляется одним автором стандарта или одним учреждением. Производители устройств пишут реализации. Сетевые операторы выбирают пропускную способность и фильтры. Операторы доменов поддерживают делегирования и авторитетные данные. Операторы резолверов решают, как повторять запросы и когда сдаваться. Приложения определяют, сколько пользователь будет ждать.

Такое разделение делает понятные сообщения ценными. Если авторитетный сервер сообщает, что имя не существует, резолвер получает ответ, который можно закэшировать и объяснить. Если сервер говорит, что тип запроса не реализован, клиент может решить, полезен ли другой метод. Если сообщение обрезано, клиент может повторить запрос по транспорту, который переносит более крупный ответ.

Молчание — иное. Оно не несёт причины. Клиент может ждать, повторять тот же путь, переключать транспорт, убирать расширение, спрашивать другой сервер или возвращать ошибку приложению. Каждый выбор отнимает время или меняет запрос. Обходное решение, помогающее с одним неисправным сервером, может скрыть другую проблему в другом месте.

Публичные работы, связанные с Ray Bellis, неоднократно подходят к этой границе. Документы не пытаются централизовать работу DNS. Они описывают, что участник должен отправлять, принимать, отклонять, таймаутить или повторять, чтобы независимые системы могли делать сбои менее двусмысленными.

DNS поверх TCP превратился из обработки исключений в обычную возможность

Многие усвоили упрощённое правило: DNS использует UDP, а TCP предназначен для необычно больших ответов или зонных передач. Такое описание отражает общую историю, но может превратить важную возможность в необязательное дополнение.

У UDP есть преимущества. Сервер может ответить на небольшой запрос, не поддерживая соединение. Простой обмен может завершиться быстро. Издержки появляются, когда ответ слишком велик, когда фрагментация ненадёжна или когда подмена адреса источника позволяет проводить отражение и усиление. DNSSEC и IPv6 способствовали увеличению ответов, а транспортные механизмы защиты приватности добавили причины вновь рассмотреть ориентированный на соединение DNS. [4]

RFC 5966, опубликованный в 2010 году с указанием Беллиса в качестве автора, устанавливал требования к реализации DNS поверх TCP. [3] Он не остался последним словом. В 2016 году RFC 7766, написанный Джоном Дикинсоном, Сарой Дикинсон, Ray Bellis, Эллисон Манкин и Дуэйном Весселсом, заменил его. [4]

Такая преемственность важна по двум причинам. Во-первых, она показывает, что вклад в стандарт может быть полезным и всё же заменённым. Поздняя группа может сохранить проблему, учесть эксплуатационный опыт и изменить нормативный текст. Устаревание в этом случае не означает, что прежний автор потерпел неудачу. Это означает, что читатели должны следить за цепочкой документов, а не останавливаться на знакомом номере.

Во-вторых, RFC 7766 сделал эксплуатационную границу яснее. Он потребовал, чтобы универсальные реализации DNS поддерживали и UDP, и TCP. Он позволил резолверам выбирать TCP по локальным эксплуатационным причинам, а не только после попытки UDP. Если подходящее TCP-соединение уже открыто, документ рекомендовал его переиспользовать. [4]

Для неспециалиста практический вывод прост. DNS-сервер, отвечающий на небольшие UDP-запросы, но неспособный обрабатывать TCP, не полностью совместим по новому требованию. Межсетевой экран, молча отбрасывающий TCP-порт 53, может вызывать сбои разрешения имён или долгие тайм-ауты приложений. Пользователь видит имя, которое «не работает», хотя само имя, адрес и авторитетные данные могут быть корректными.

RFC не доказывает, что каждая реализация соответствует требованию. Он задаёт публичное поведение, по которому оператор может проводить проверку. Отправляйте запросы по обоим транспортам. Наблюдайте, устанавливаются ли соединения, возвращаются ли ответы в том же соединении, выдерживают ли крупные ответы, и отражают ли тайм-ауты явную политику ресурсов или случайную фильтрацию.

Прокси может сохранить пакет, изменив его смысл

DNS-прокси распространены в шлюзах и локальных сетях. Клиент может считать, что общается с резолвером по ближнему адресу, тогда как прокси пересылает вопрос дальше. Это может быть удобно, но добавляет ещё одну реализацию, которая должна понимать размер сообщения, транспорт, флаги, расширения, коды ответа и возвратные пути.

RFC 5625, опубликованный в 2009 году с указанием Беллиса в качестве автора, фиксирует рекомендации по реализации DNS-прокси. [2] Его присутствие в реестре стандартов полезно для этой статьи не потому, что каждый прокси ему следует, а потому, что прокси делают различие между исходным и доставленным сообщением эксплуатационно важным.

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

Это повторяющаяся проблема интернет-инфраструктуры. У каждой промежуточной системы может быть локальная причина фильтровать или переписывать трафик. Однако сквозной результат измеряется тем, получает ли исходный участник ответ, который может интерпретировать. Экран настройки с надписью «DNS-прокси включён» не доказывает поведение этого пути.

Поэтому операторам нужны тесты, которые меняют больше, чем доменное имя. Они могут запрашивать известные и неизвестные типы записей, использовать обычный и расширенный DNS, сравнивать UDP и TCP, запрашивать достаточно большой ответ, чтобы задействовать обрезание, и проверять, сохраняются ли коды ошибок. Цель не в том, чтобы заставить каждое устройство немедленно реализовать каждую новую функцию. Цель — отличить неподдерживаемую функцию от устройства, которое скрывает свидетельства.

Документированная роль Беллиса здесь ограничена. RFC 5625 — это авторская публичная запись. Производители и операторы решают, реализовывать ли его и тестировать. Источник не предоставляет счётчик внедрений, список совместимых продуктов или измеренное снижение сбоев.

Поддержание TCP-соединения открытым создаёт решение о ресурсах

Превращение TCP в обычный транспорт DNS решает одни проблемы и создаёт эксплуатационные выборы. Сервер должен помнить состояние соединения. Он должен выделять память, сокеты, очереди и процессорное время. Клиенту нужно знать, можно ли переиспользовать спокойное соединение или оно скоро будет закрыто.

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

RFC 7828, соавторами которого выступили Пол Ваутерс, Джо Эбли, Сара Дикинсон и Ray Bellis, определил опцию edns-tcp-keepalive. [5] Она позволяет серверу сообщать тайм-аут бездействия, связанный с TCP-сеансом. Клиент может выразить заинтересованность в поддержании соединения открытым. Сервер может вернуть значение, основанное на его локальных ограничениях ресурсов, включая ноль, когда хочет, чтобы клиенты завершили незавершённую работу и закрыли соединение.

Опция — хороший пример координации без отказа от локального контроля. Стандарт определяет поле и его интерпретацию. Он не требует, чтобы каждый сервер поддерживал каждое соединение одинаковое время. Сервер остаётся ответственным за ёмкость. Клиент остаётся ответственным за соблюдение сигнала и решение, что делать дальше.

Документ также фиксирует осложнения. Долгоживущие сеансы могут быть нарушены, когда маршрутизация меняет адресата, достигаемого через anycast-адрес. Промежуточные устройства могут вмешиваться в опции EDNS или сообщения определённых размеров. Клиентам нужен возвратный механизм для путей, которые не переносят опцию чисто. [5]

Ни одна из этих оговорок не делает постоянные соединения бесполезными. Они показывают, почему тайм-аут должен быть наблюдаемым и почему оператору нужно больше, чем счётчик соединений. Полезные измерения включают коэффициент переиспользования, время установки соединения, причину закрытия по простою, число незавершённых запросов на момент закрытия, неудавшиеся возвратные попытки и различия между anycast-сайтами.

Поле стандарта не может выделить память или исправить межсетевой экран. Оно может сделать решение о ресурсах достаточно видимым, чтобы обе стороны могли реагировать. Это более скромное, но более полезное утверждение, чем «TCP делает DNS надёжным».

Состояний DNS потребовались состояния, которые обе стороны могли назвать

Сигнализация keepalive затронула одну часть более широкого вопроса. Если DNS-соединение сохраняется, как конечные точки управляют операциями уровня сеанса, которые не являются обычными запросами имени?

RFC 8490, соавтором которого был Беллис вместе с пятью другими авторами, определил операции DNS с сохранением состояния, или DSO (DNS Stateful Operations). [6] Он создал код операции DNS и структуру сообщения для функций сеанса. Первоначальные операции охватывают keepalive, задержку повторной попытки и заполнение шифрованием. Документ также допустил сообщения, инициируемые сервером, в постоянном сеансе.

Документ различает установление соединения и установление DSO-сеанса. Соединение может существовать до того, как DSO-сеанс станет активным. Запрос сеанса может быть успешным, завершиться ошибкой с кодом ответа или истечь по тайм-ауту. После установления обе стороны могут отправлять DSO-сообщения. Любая сторона может завершить работу, а сервер может сообщить задержку повторной попытки. [6]

Эта модель состояний важна, потому что «TCP-сокет открыт» — не то же самое, что «обе стороны согласились, что DSO-сеанс существует». Если считать их идентичными, можно скрыть незавершённое рукопожатие. Точно так же ожидание ответа DSO без ограничений оставило бы клиента в неопределённом состоянии.

RFC 8490 устраняет эту неопределённость с помощью определённых переходов и поведения при сбое. Тайм-аут при установлении сеанса заставляет клиента прервать соединение; в зависимости от обстоятельств он может переподключиться без DSO. Ненулевой код ответа указывает на неудачную попытку, позволяя обычной работе DNS продолжаться в подключённом, но бессеансовом состоянии. [6]

Механизм не устраняет всю двусмысленность. Потерянное соединение всё равно требует диагностики. Промежуточное устройство всё равно может нарушить трафик. Ёмкость сервера всё равно может измениться. Документ также не доказывает, что DSO широко развёрнут.

Его вклад — публичная запись состояния. Клиент может сказать, был ли он просто подключён, пытался установить сеанс, установил его, получил отказ, истёк по тайм-ауту или завершает работу. Эти метки могут появиться в журналах и тестах. Когда позднее команда проводит расследование, у неё есть больше, чем «DNS не сработал».

Молчание делает разные сбои одинаковыми

RFC 8906 придаёт центральной проблеме статьи её самую ясную форму. Написанный Марком Эндрюсом и Ray Bellis, он описывает эксплуатационную закономерность, при которой DNS-серверы не отвечают на корректно сформированные запросы. [7]

У отсутствующего ответа может быть несколько причин. Пакет мог потеряться. Сервер может не понимать опцию EDNS. Межсетевой экран может отбросить сообщение. Сервер под атакой может ограничивать ответы по скорости. Неисправная реализация может игнорировать неизвестный тип или флаг. Со стороны клиента эти разные условия выглядят как одно и то же пустое ожидание.

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

RFC 8906 отстаивает явные ответы в обычных условиях. Сервер, получивший неизвестный тип данных, может вернуть ответ, соответствующий распознанному типу, по которому у него нет данных. Для неизвестного кода операции определён ответ «не реализовано». Сервер должен отвечать по TCP, а межсетевой экран, отказывающий TCP, должен завершать соединение чисто, а не молча отбрасывать попытку. [7]

Документ признаёт исключение: серверу имён под атакой может потребоваться отбрасывать пакеты или ограничивать ответы. Эта эксплуатационная власть остаётся локальной. Проблема в том, что широко распространённое необъяснимое молчание мешает легитимным клиентам отличать меры защиты от неисправного поведения.

RFC также связывает поведение ответа с поддержкой делегирования. Он советует операторам родительских зон проверять, что записи серверов имён (NS), используемые для делегирования — записи, обозначающие серверы, ответственные за зону, — согласуются с записями в делегированной зоне. [7] Сервер, получающий запрос для зоны, которую он должен обслуживать, не должен просто исчезать. Явный ответ и непротиворечивое делегирование дают резолверу свидетельство о том, где лежит ответственность.

Это не обещание, что каждый запрос заслуживает неограниченных ресурсов. Это проектное предпочтение полезной информации о сбое. Отрицательный ответ, код ошибки, сброс соединения или сигнал повторной попытки можно обработать. Молчание перекладывает стоимость угадывания на каждого клиента.

Ответ об ошибке защищает бюджет повторных попыток клиента

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

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

Явный ответ сокращает дерево решений. Ошибка формата указывает на проблему с форматом запроса. «Не реализовано» указывает на операцию, которую сервер не поддерживает. Обычный отрицательный ответ говорит, что сервер понял вопрос, но у него нет совпадающих данных. Чистый отказ TCP показывает, что путь соединения был достигнут, даже если услуга недоступна. Не все эти исходы успешны, но каждый несёт больше эксплуатационной ценности, чем молчание.

RFC 8906 делает это различие центральным. Он документирует, как отсутствие ответа побуждает резолверы отключать EDNS и как такой возврат может мешать DNSSEC или новым функциям. Он также даёт операторам последовательность тестирования: убедиться, что обычный DNS работает, изменить расширенный запрос, а затем повторить исходный запрос, чтобы отличить постоянный сбой от обычной потери пакетов. [7]

Та же логика проявляется в DSO. Ненулевой код ответа сообщает клиенту, что установление сеанса не удалось. Тайм-аут указывает, что состояние не определено, и приводит к прерыванию соединения. Это разные состояния, и они должны оставаться разными в журналах. [6] Если рассматривать оба как одно событие «разъединено», можно отбросить свидетельства протокола.

RFC 10029 продолжает эту закономерность. Опция ответа сообщает, какие запрошенные типы были полностью обработаны. Отсутствующий тип не заставляет клиента гадать, спрятан ли его ответ где-то в сообщении. Клиент отправляет отдельный запрос для оставшегося. Если расширение не поддерживается, основной ответ всё равно можно использовать до возврата. [9]

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

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

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

Беллис и другие указанные авторы не устанавливают бюджет повторных попыток для каждого резолвера. Их документы определяют информацию о ответе и состоянии, которую может использовать локальное программное обеспечение. Оператор по-прежнему решает вопросы ёмкости, задержки, конфиденциальности и риска. Вклад стандартов — сделать больше ветвей различимыми до принятия этого решения.

Один вопрос стал основой для запроса нескольких видов данных

Сообщения DNS содержат поля счётчиков, включая QDCOUNT для числа вопросов. Исходный проводной формат, казалось, допускал несколько вопросов, но реализации не выработали надёжного общего поведения для многозапросных запросов.

RFC 9619, написанный Ray Bellis и Джо Эбли и опубликованный в 2024 году, разъяснил, что обычный DNS-запрос, как правило, несёт один вопрос. [8] Это правило сузило неопределённость, но приложениям часто нужны связанные типы для одного имени. Клиент, готовящий соединение, может хотеть данные A, AAAA и HTTPS. Отправка отдельных вопросов стоит дополнительных обменов и работы.

RFC 10029, автором которого был Беллис, опубликованный как Proposed Standard в июле 2026 года, адресовал этот случай без возврата к ненадёжной интерпретации нескольких вопросов. [9] Он сохраняет один основной вопрос и использует опцию EDNS для перечисления дополнительных типов записей, которые клиент хочет вместе с ним.

Ответ имеет собственную опцию. Соответствующий сервер возвращает эту опцию для допустимого запроса, даже если весь ответ обрезан. Опция перечисляет дополнительные типы, которые были полностью обработаны. Если ответ имеет несоответствие кода ответа или флага либо не помещается, сервер не включает этот тип, а не подразумевает полный успех. [9]

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

RFC также называет цену. Запрос дополнительных типов может увеличить работу сервера и потенциал усиления DNS-ответов. Поэтому он призывает к настраиваемым ограничениям, причём подходящее значение зависит от операционной среды. [9]

Эта закономерность напоминает прежнюю работу над транспортом и сеансами. Новая возможность полезна только тогда, когда поддержка, завершённость, ограничения ресурсов и возврат видимы. Стандарт определяет обмен. Операторы и разработчики решают, включать ли его, как ограничивать и как измерять результат.

Реестр стандартов показывает замену и передачу, а не единый завершённый проект

5 августа 2026 года профиль IETF для Беллиса перечислял десять RFC и не имел активных Internet-Draft. [1] Этот снимок не следует считать полной биографией. Это запись документов, связанных с человеком, на определённый момент.

Внутри этой записи авторство меняет форму. RFC 5625 и RFC 5966 называют Беллиса автором. RFC 7766, RFC 7828, RFC 8490, RFC 8906 и RFC 9619 — совместные. RFC 10029 снова называет Беллиса автором, одновременно отражая консенсус рабочей группы. [2] [3] [4] [5] [6] [7] [8] [9]

Замена RFC 5966 на RFC 7766 особенно полезна. Ранний текст остаётся доступным, но разработчики направляются к новой спецификации. Поздний документ добавляет авторов и учитывает больше эксплуатационного опыта. Беллис указан в обоих, однако стандарт не представлен как его частная собственность.

RFC 8490 обновил работу по DNS поверх TCP, добавив операции с состоянием. RFC 10029 опирается на разъяснение одного вопроса в RFC 9619. Документы ссылаются друг на друга, ограничивают друг друга и иногда заменяют друг друга. Такая цепочка позволяет передавать ответственность, не стирая прежнюю работу.

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

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

Нерешённая работа лежит на границе между протоколом и эксплуатацией

Публикация RFC не устраняет старые промежуточные устройства. Прокси по-прежнему может некорректно обрабатывать расширенные сообщения. Межсетевой экран по-прежнему может блокировать TCP. Сервер по-прежнему может исчерпать ёмкость соединений. Смена anycast-маршрута по-прежнему может направить постоянное соединение к другому сайту. Резолвер по-прежнему может тратить слишком много времени на угадывание после молчания.

Новые механизмы добавляют собственные вопросы. DSO создаёт состояние сеанса, которое нужно отслеживать и защищать. Запросы нескольких QTYPE могут сократить отдельные обмены, но увеличить работу и возможное усиление. Ограничения, защищающие один сервер, могут уменьшить пользу функции для клиента. Возврат сохраняет совместимость, но может скрывать низкую поддержку, если операторы измеряют только итоговый успех.

Это не причины отвергать стандарты, а причины разделять спецификацию и результат. Требование — это цель теста. Код ответа — свидетельство. Тайм-аут — переход состояния. Возврат — видимая ветвь. Ничто из этого не гарантирует, что конкретный сервис быстр или доступен.

Документированная работа Беллиса в этих пределах даёт последовательный эксплуатационный урок. DNS развивается безопаснее, когда участники сообщают, что они поняли, что завершили, что отклонили и что другая сторона должна попробовать дальше. Это делает распределённую систему более наблюдаемой, не создавая центрального оператора.

Вопрос, оставленный разработчикам и сетевым командам, измерим: по мере того как DNS добавляет транспорт, постоянные сеансы, расширения и комбинированные запросы, сохраняют ли их работающие системы достаточно явного поведения, чтобы сбой можно было классифицировать до того, как приложение сдастся? RFC не могут ответить за каждую сеть. Они делают возможным задать вопрос точно.

Источники

  1. IETF Datatracker,профиль Ray Bellis.
  2. RFC Editor,RFC 5625: DNS Proxy Implementation Guidelines.
  3. RFC Editor,RFC 5966: DNS Transport over TCP — Implementation Requirements.
  4. RFC Editor,RFC 7766: DNS Transport over TCP — Implementation Requirements.
  5. RFC Editor,RFC 7828: The edns-tcp-keepalive EDNS0 Option.
  6. RFC Editor,RFC 8490: DNS Stateful Operations.
  7. RFC Editor,RFC 8906: A Common Operational Problem in DNS Servers: Failure to Communicate.
  8. IETF Datatracker,RFC 9619: In the DNS, QDCOUNT Is (Usually) One.
  9. IETF Datatracker,RFC 10029: DNS Multiple QTYPEs.