Кратко

  • В публичном руководстве Delegation Key от ARIN тип хеша 3 назван MD5, а его длина указана как 32. IANA выделяет тип хеша DS 3 для GOST R34.11-94; сейчас он помечен как устаревший.
  • Единица длины в таблице не указана. Хеш GOST из 256 бит занимает 32 октета или 64 шестнадцатеричных символа. Это различие не показывает, какие ограничения действительно проверяет API.
  • Все четыре текущие рекомендации IANA для типа 3 содержат MUST NOT, согласно RFC 9906. Исправить название не значит рекомендовать применение. API, зоны DNS, программы подписи и резолверы в этом исследовании не проверялись.

Сначала значение поля, затем разговор о сбое

Прежде чем объявлять проблему безопасности, полезно установить, что именно сравнивается. Здесь это две публичные расшифровки одного номера. В разделе Delegation Key справочника Reg-RWS организация ARIN ставит напротив типа хеша 3 название MD5. В реестре типов хеша DS у IANA номер 3 означает GOST R34.11-94. Различие касается функции, а не варианта написания.

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

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

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

В исследовании не выявлена отправка таких данных и не проверен соответствующий публичный ответ DNS. Не использовался закрытый аккаунт ARIN или ключ API, не создавались и не отправлялись данные DS. Нельзя заменять доказанный неверный ярлык утверждением, будто действующий сервис принимает, хранит или публикует MD5 под этим номером.

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

algorithm и digestType не делят один реестр

В справочнике Delegation Key находится внутри Delegation Payload. Среди его полей есть algorithm и digestType. Первое относится к алгоритму DNSKEY, второе к функции хеша DS. Оба могут быть целыми числами в одном сообщении, но относятся к разным пространствам значений. Близость в формате не делает их взаимозаменяемыми.

В опубликованном перечне алгоритмов есть 5, 7, 8, 10, 13, 14, 15 и 16 с названиями из семейств RSA, ECDSA и EdDSA. Отдельная таблица хешей содержит SHA1 для 1, SHA256 для 2, MD5 для 3 и SHA384 для 4. Длины перечислены как 40, 64, 32 и 96. Это содержание документа, а не проверенный список разрешённых значений работающего сервиса.

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

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

RFC 5933 ясно разводит номера GOST. Алгоритму подписи DNSKEY ECC-GOST был выделен 12, а типу хеша DS GOST R34.11-94 — 3. Тип хеша DS 3 не является алгоритмом DNSKEY 3. Не является он и значением 3 в поле протокола DNSKEY либо меткой ключа, в которой встречается та же цифра. Контекст поля определяет значение числа.

Хешируется не произвольная строка ключа

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

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

Текущее присвоение у IANA и исходное присвоение в RFC 5933 совпадают: тип 3 обозначает GOST. Пометка об устаревании не освобождает номер для MD5. Реестр способен сохранять значение старого идентификатора, одновременно запрещая его новое использование. Историческое распознавание и рекомендация к созданию материала не являются одним действием.

Здесь не утверждается, что MD5 отсутствует во всех технологиях, связанных с DNS, или вообще в других технических контекстах. Это была бы более широкая тема с другим набором доказательств. Установлен узкий факт: MD5 не является функцией, присвоенной типу хеша DS 3. Точная граница помогает сформулировать исправление, которое можно непосредственно проверить.

Длина без единицы не раскрывает проверку

Название функции сравнивается прямо. Со столбцом Digest Length нужно быть осторожнее. ARIN указывает 32, но не поясняет единицу. Соседние 40, 64 и 96 согласуются с количеством шестнадцатеричных символов. Такой ряд допускает правдоподобное прочтение, но не доказывает предел строки, который применяется API.

RFC 5933 задаёт длину хеша GOST как 256 бит. В октете восемь бит, значит данные занимают 32 октета. В шестнадцатеричном представлении на октет нужны два символа, всего 64. RFC 4034 описывает хеш DS как шестнадцатеричный текст без различения регистра букв и допускает пробелы. Размер данных и длина форматированной строки поэтому не должны смешиваться.

Если столбец считает шестнадцатеричные символы, 32 не описывает GOST для зарегистрированного типа 3. Если считаются октеты, число подходит GOST, но соседние строки требуют другого объяснения. Страница не разрешает этот выбор. Полезное исправление прямо называло бы единицу и поясняло обработку пробелов, а не оставляло догадку скрытым правилом приёма.

Из таблицы не следует, что ввод из 64 символов отклоняется или что ввод из 32 принимается. Декодирование, нормализация, последовательность проверки, сообщения об ошибках и хранение не исследовались в исполнении. Их можно изучать отдельно при подходящих разрешениях, но сравнение опубликованных длин не является таким испытанием.

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

Правильный GOST остаётся выведенным из применения

Замена MD5 на GOST восстановила бы смысл номера, но не сделала бы тип 3 рекомендуемым вариантом новой делегации. RFC 9906 вышел в ноябре 2025 года и исключает ECC-GOST и GOST R34.11-94 из использования в DNSSEC. Текущая строка IANA отражает это изменение в четырёх рекомендациях.

Все четыре содержат MUST NOT: применение для делегации, применение для проверки, реализация для делегации и реализация для проверки. Историческое описание необязательной реализации в RFC 5933 объясняет более раннее состояние, а не отменяет последующий отказ. Сослаться на прежнее MAY как на сегодняшнее разрешение проверки означало бы внести временную ошибку при исправлении ошибки имени.

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

RFC 9906 различает и состояние проверки. Если остаётся только путь на выведенных алгоритмах и нет другого допустимого пути аутентификации, предписанное обращение — insecure. Это не продолжение проверки этими алгоритмами с классификацией цепочки как bogus. Ни один термин не означает просто недоступность имени. Такое состояние не измерялось здесь для какой-либо зоны ARIN.

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

Родительская запись не равна всей системе DNS

Руководство ARIN по обратному DNS объясняет эксплуатационный контекст. После защиты обратной зоны оператор может сигнализировать данные DS родительской зоне и управлять ими по делегациям через ARIN Online или RESTful-сервис настройки. Обсуждаемый тип находится на границе между материалом ключей дочерней зоны и его описанием со стороны родительской.

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

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

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

Какие утверждения закрывает исправление

Шесть документов не являются шестью независимыми аудитами реализации. Таблица ARIN описывает интерфейс, IANA регистрирует номера, RFC 5933 задаёт исходное присвоение, RFC 9906 обновляет статус применения. Между стандартами есть преемственность. IANA цитируется не как организация, проверившая работу API у ARIN, а как источник присвоенного значения.

Чтобы воспроизвести сравнение, нужно сохранять контекст строки. MD5 без поля может потерять предмет, число 3 без пространства имён — смешаться с DNSKEY, а 32 без оговорки об единице — стать якобы установленным ограничением. Возвращение имени, номера и длины к исходному месту является организацией доказательства, не новым сетевым тестом.

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

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

Источники

  • Справочник форматов Reg-RWS от ARIN: поля Delegation Key, описанное определение имён по числам, типы и длины.
  • Реестр IANA типов хеша DS: присвоение типа 3 и текущие четыре рекомендации.
  • RFC 5933: отдельные номера GOST и хеш из 256 бит; исходные рекомендации относятся к прошлому состоянию.
  • RFC 9906: отказ от применения в ноябре 2025 года и предписанное обращение при проверке.
  • Руководство ARIN по обратному DNS: контекст родительского DS, не доказательство состояния определённой зоны.
  • RFC 4034: смысл полей DS, вход хеша и шестнадцатеричное представление; не текущий совет по выбору алгоритма.