Кратко

  • Написанная Ray Bellis RFC 5625 исходит из того, что простой DNS-прокси не способен знать все нынешние и будущие расширения. Поэтому неизвестные флаги, метки, типы и классы должны проходить, полные ответы, EDNS, TC, TCP и чувствительные к аутентификации байты — сохраняться, а действительно неверные сообщения и активная политика — давать наблюдаемый отказ.
  • Документ вышел в 2009 году как BCP 152. Он не доказывает современное соответствие устройств или повсеместное внедрение, а прозрачная пересылка не равна проверке DNSSEC. Его долгосрочный вклад — разделение полномочий: спецификации и конечные узлы владеют семантикой, прокси — ограниченным состоянием, доступностью интерфейсов и явно локальными решениями.

Флаг из будущего встречает прошивку из прошлого

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

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

RFC 5625, DNS Proxy Implementation Guidelines, была опубликована в августе 2009 года как Best Current Practice 152. Единственный автор — Ray Bellis, в то время работавший в Nominet UK. Документ прямо учитывает ограничения домашних шлюзов: небольшие аппаратные ресурсы, длинный цикл прошивки и невозможность заранее реализовать неизвестные расширения.

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

Историческое измерение с точной границей

Краткое изложение SAC035 и полный отчёт описывают контролируемое тестирование 24 домашних маршрутизаторов или межсетевых экранов для небольших офисов в июле и августе 2008 года.

Все 24 устройства могли напрямую маршрутизировать запросы DNSSEC к внешним резолверам. 22 предоставляли режим DNS-прокси; шесть из них испытывали затруднения с флагами DNSSEC или с проверенными ответами. 18 ограничивали UDP-ответы 512 байтами либо размером, связанным с MTU; только четыре возвращали до 4096 байт, и лишь одно проксировало DNS по TCP. Шесть устройств были полностью совместимы в стандартной конфигурации; ещё девять можно было настроить так, чтобы обойти несовместимый прокси.

Это не статистика современного рынка. Выборка состояла из 24 устройств, проверенных в 2008 году; продукты и практика изменились. Результаты доказывают лишь поведение этой исторической выборки. Но они ясно показывают механизм: функция, доступная обоим концам, исчезает в промежуточном узле.

Материалы одобрения IETF фиксируют сильный консенсус рабочей группы DNS Extensions и интерес поставщиков и покупателей. Это свидетельство процесса, а не данные об установленных устройствах.

Незнакомое значение не делает пакет неверным

Главная граница RFC 5625 проходит между неизвестной семантикой и внутренне неправильным сообщением. Если прокси не знает флаг заголовка DNS, он игнорирует его для собственной логики, но пересылает пакет. Так же обрабатываются разные формы меток, неизвестные QTYPE, QCLASS, TYPE и CLASS ресурсных записей.

Старый парсер не вправе сохранять правило «резервное поле равно нулю» после официального назначения значения. Иначе любое расширение ждало бы замены всего парка промежуточных устройств.

RFC 3597 задаёт общий принцип для неизвестных типов ресурсных записей: RDATA следует считать неструктурированной двоичной информацией, хранить и передавать без изменений. Узел не притворяется, что понимает запись; он сохраняет её для компонента, который понимает.

Неверный указатель сжатия или невозможные счётчики секций — другой случай. Такое сообщение может быть отброшено. Но RFC 5625 рекомендует, когда это безопасно, вернуть SERVFAIL вместо молчания. Клиент прекращает повторения, а оператор получает признак слоя, который отказал.

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

Полнота ответа содержится и в транспорте

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

RFC 5625 не допускает усечение только из-за старого порога 512 байт. Если локальное ограничение всё же требует усечения, TC должен быть установлен; полученный от upstream TC нельзя удалять. Объявленное ограничение позволяет восстановление, скрытое создаёт ложный успех.

Прокси должен принимать и пересылать DNS по TCP. Если клиент уже использует TCP, upstream-запрос тоже должен идти по TCP, а не понижаться до UDP. RFC 7766, позднее написанная Bellis и ещё четырьмя авторами, сделала TCP обязательным для реализаций DNS. Она укрепляет норму транспорта, но не доказывает всеобщего соответствия.

EDNS переносит расширения через запись OPT. Её наличие не должно приводить к отказу. RFC 6891 позднее установила, что соответствующая middlebox не должна навязывать лимит UDP 512 байт, а простой форвардер не должен менять или удалять OPT ни в одном направлении. Рекомендация 4096 байт в документе 2009 года отражает возможности того периода, а не постоянный максимум.

У прозрачного прокси остаётся зона ответственности

Тонкий прокси — не пассивный провод. Он сопоставляет ответ с LAN-клиентом, хранит состояние, выбирает резолвер и может менять исходящий Query ID. Он решает, на каких интерфейсах слушать и какой адрес объявлять по DHCP.

Для устойчивости к поддельным ответам RFC 5625 ссылается на RFC 5452, включая случайные идентификаторы запросов и исходные порты. Рандомизация снижает определённый риск, но не аутентифицирует ответ и не заменяет DNSSEC.

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

Доступность интерфейсов тоже является его прямой обязанностью. LAN-прокси не должен по умолчанию отвечать со стороны WAN, где способен стать отражателем. RFC 5358 описывает риск открытых рекурсивных серверов. Прозрачность для разрешённого клиента не требует публичной доступности.

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

Проверка Bellis начинается с отсутствующего в таблице значения

Профиль Ray Bellis в IETF Datatracker перечисляет десять RFC, включая RFC 5625. Страница команды ISC сегодня указывает его как Director of DNS Operations. Операционный взгляд заметен в критерии приёмки: важно не число знакомых функций, а поведение при встрече со следующей незнакомой.

Проходит ли новый флаг? Сохраняются ли байты неизвестного типа? Доходят ли TC и OPT? Остаётся ли TCP сквозным? Можно ли по разным свидетельствам отделить сознательную политику от незнания прошивки?

В более поздней RFC 8906 Mark Andrews и Ray Bellis превратили неожиданные поля, типы, версии, параметры и флаги EDNS, усечение и TCP в явные тестовые случаи. Неоднозначное молчание уступает место воспроизводимым результатам.

RFC 5625 не обещает, что прозрачность даст проверку DNSSEC, конфиденциальность или доступность. Она не отменяет выбор upstream, защиту интерфейсов или заявленную политику. Её граница уже: посредник не получает юрисдикцию над неизвестным. Он хранит путь, но не владеет смыслом проходящего протокола.

Источники