Кратко

  • RFC 5625 вышел в августе 2009 года как BCP 152 с одним автором; страница BCP 152 показывает подсерию ровно из одного RFC. RFC 8490 — Proposed Standard от марта 2019 года с шестью авторами.
  • Первый документ пишет правила для оборудования, которое останется в строю после смены протокола; второй — для пары программ, которые договариваются о состоянии. Ни один из них не обязывает того, кто решил не внедрять, и реестр хранит номер, а не работающую сеть.

Годы против секунд

В первом тексте чувствуется горизонт планирования. Автор писал для прошивки домашнего шлюза, которую никто не обновит, когда появится следующая расширение DNS. Отсюда аскетичная мораль: не мешай. Раздел 4.1 требует, чтобы прокси игнорировал незнакомые флаги DNS и передавал пакет как есть; раздел 4.4 — чтобы при вынужденном усечении ответа он выставлял бит TC; раздел 4.5 — чтобы он умел передавать пакеты с ресурсными записями TKEY (текст RFC 5625).

Положительные пожелания сформулированы слабее и это осознанно. Раздел 3 рекомендует быть настолько прозрачным, насколько возможно; раздел 4.4.1 говорит, что запрос, пришедший по TCP, следует передавать по TCP и не пробовать сначала UDP; раздел 5.2 советует оставить значение описанной опции пустым. Правило, рассчитанное на десять лет вперёд, может позволить себе быть скучным: единственное, что нельзя предсказать заранее, — это форма будущего расширения, поэтому запрет на вмешательство работает при любой форме.

Во втором тексте горизонт другой — не годы, а таймеры. Раздел 5.1 запрещает серверу начинать запросы DSO или односторонние сообщения, пока сессия DSO не установлена взаимно. Раздел 5.1.1 запрещает серверу, реализующему DSO, отвечать кодом DSOTYPENI на запрос Keepalive, потому что TLV Keepalive обязателен к реализации. Раздел 5.4.1 объявляет ответ DSO с нулевым идентификатором сообщения фатальной ошибкой, требующей немедленного разрыва соединения (текст RFC 8490).

Сложите три правила, и выйдет конструкция, существующая только вдвоём: сессия есть потому, что обе стороны её создали; один код отказа исчезает из доступного набора, потому что другая деталь обязательна; неверный идентификатор — не предупреждение, а конец разговора. Слабые места тоже про время: клиент должен подождать тридцать секунд, а если сервер сбросил соединение, отметить этот экземпляр службы как не поддерживающий DSO. Спецификация может научить читать паузу. Она не может заставить кого-то войти в разговор.

Кто ставит подпись и за кого

Подписей разное число, и это не мелочь оформления. В первом случае на титуле один человек — R. Bellis из Nominet UK, работа выросла из группы DNSEXT и черновика draft-ietf-dnsext-dnsproxy, что зафиксировано в записи Datatracker, прочитанной как сводка страницы, а не как полная история ревизий (Datatracker по RFC 5625).

Во втором на титуле шесть имён из пяти организаций: Беллис от ISC, Чешир от Apple, оба Дикинсона от Sinodun, Лемон от Nibbhaya Consulting и Пусатери без аффилиации. Документ вдобавок обновляет RFC 1035 и RFC 7766. Похоже, обязать две программы поддерживать общее состояние в одиночку действительно трудно.

Пустая страница опечаток

Внешний читатель может проверить здоровье документа по публичному журналу исправлений. На 18 октября 2026 года страница опечаток RFC 5625 и страница опечаток RFC 8490 не показывали ни одной записи, и ни одна информационная страница не указывала на заменяющий или последующий документ. Это утверждение о том, что было видно на этих страницах в тот день, и не больше.

Пустая страница допускает два прочтения с одинаковым лицом: текст выдержал использование или никто не собрался подать исправление. Снаружи их не различить. Та же оговорка касается истории работы: записи Datatracker по RFC 8490 и по RFC 5625 были доступны как сводки, поэтому видна только половина цепочки — известно, что один документ прошёл через DNSEXT, а другой через DNSOP, но не известно, какой черновик породил какую фразу.

И главное: свидетельств внедрения получить не удалось. Этот текст не утверждает, что RFC 5625 изменил поведение домашних маршрутизаторов, и не утверждает, что DSO работает в каком-либо выпускаемом резолвере. Это вопрос к программному обеспечению, а оно следов в просмотренном материале не оставило.

Что хранит реестр

В реестре параметров DNS у IANA значение OpCode 6 числится как DNS Stateful Operations со ссылкой на RFC 8490, а рядом стоит таблица DSO Type Codes с 0x0001 KeepAlive, 0x0002 RetryDelay и 0x0003 EncryptionPadding. Три строки, выделенные по процедуре и удерживаемые административной функцией, которая не зависит от того, кто написал документ.

Это и есть долговечная часть. Авторство RFC — датированный акт; строка реестра читается и тогда, когда автор сменил работодателя, отрасль и интерес. Но срок принадлежит реестру, а не заявителю. IANA хранит факт существования кода, а не факт его отправки по сети.

Граница, которую можно назвать

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

Не управлял он тем, что решает, есть ли у этого вес. Разработчик читает RFC 8490, сопоставляет стоимость состояния сессии с графиком выпуска прошивки и отказывается. Ни одна фраза документа до него не доходит — и потому реестр держит то, чего не держит подпись.