Кратко

  • RFC 9558 закрепляет за GOST R 34.10-2012 номер алгоритма DNSSEC 23, а за GOST R 34.11-2012 — тип дайджеста DS 5 и точный формат объектов.
  • Это Informational RFC потока Independent Submission: он не выражает консенсус IETF и не удостоверяет криптографическую пригодность, реализацию или распространение.
  • Надёжный вывод складывается из отдельных квитанций: реестр, поддержка подписанта, публикация, DS родителя, возможности валидатора, проверенная цепочка и решение приложения.

Одна и та же зона оказалась Secure и Insecure

Оператор опубликовал DNSKEY с алгоритмом 23, создал RRSIG по GOST R 34.10-2012 и передал родителю DS с типом дайджеста 5. В собственной системе проверки цепочка дошла до доверенного якоря и получила статус Secure.

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

Подпись не признали неверной — до её проверки не существовало исполнимого пути. Именно здесь заканчивается власть регистра. IANA даёт объекту общее имя. Установленный код решает, можно ли с ним работать.

Статус публикации нельзя сокращать до слова RFC

RFC 9558 опубликован в апреле 2024 года как Informational в Independent Submission stream. Это не Internet Standards Track, документ не отражает консенсус сообщества IETF и не одобрен процессом стандартизации IETF. RFC Editor не заявляет о ценности спецификации для реализации или развёртывания.

Текст отдельно предупреждает: криптографические свойства российских национальных стандартов GOST R 34.10-2012 и GOST R 34.11-2012 здесь независимо не проверялись. Ни IETF, ни IRTF не анализировали их пригодность для конкретного применения.

Такая оговорка не запрещает добровольную реализацию. Она не позволяет выдать координацию формата за рекомендацию. RFC описывает, как согласованно представить байты; решение о доверии остаётся у оператора и полагающейся стороны.

В профиле важен порядок каждого байта

RFC выбирает 256-битный вариант подписи, 256-битный дайджест и набор параметров A. Точка эллиптической кривой Q=(x,y) занимает в DNSKEY ровно 64 октета: 32 октета x в little-endian, затем 32 октета y в том же порядке. Открытый ключ и подпись имеют по 512 бит, дайджест — 256.

Библиотека может хранить правильную математическую точку и всё же записать несовместимую DNSKEY из-за порядка байтов. Для существующих GOST-совместимых X.509 API документ даёт фиксированный 30-байтный префикс ASN.1 SubjectPublicKeyInfo. Это переходник формата, а не сертификат, доверенный якорь или полномочие.

RRSIG строится из входа RFC 4034: сначала GOST R 34.11-2012, затем подпись GOST R 34.10-2012. Псевдослучайное k из примера опубликовано ради воспроизводимости и прямо запрещено для реальных подписей. Совпадение тестового вектора не доказывает безопасность производственного генератора.

Номера 23 и 5 описывают разные стыки

IANA регистрирует ECC-GOST12 как алгоритм DNSSEC 23. В отдельном реестре GOST R 34.11-2012 имеет тип дайджеста DS 5 и статус OPTIONAL. Первый номер задаёт трактовку DNSKEY и RRSIG. Второй — способ связать DS родителя с DNSKEY ребёнка.

Корректная RRSIG без пригодного DS не продолжает доверие от родителя. Совпадающий DS без поддержки валидатора не образует путь. Даже при поддержке старый кэш, другой якорь или истёкшее окно подписи могут изменить вывод.

В проверяемую запись входят точные RRset DNSKEY, RRSIG и DS, точки наблюдения родителя и ребёнка, serial, inception и expiration, TTL, доверенный якорь, версия валидатора и перечень алгоритмов. Фраза «DNSSEC включён» не позволяет повторить решение.

Неподдерживаемый путь — не то же, что Bogus

Если все варианты исчезли из-за отсутствия поддержки, зона рассматривается как неподписанная. Bogus означает, что доступный для проверки путь не выдержал обязательных проверок. Эти состояния требуют разных действий.

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

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

Два KSK дают время, но удваивают поверхности состояния

RFC 9558 рекомендует подписывать зону двумя алгоритмами KSK, пока GOST-поддержка не станет шире, если GOST-only не выбран намеренно. Альтернативный путь сохраняет аутентификацию для валидаторов без алгоритма 23.

Одновременно растёт число ключей, DS, подписей, сроков, изменений у родителя и кэшированных состояний. RFC 6840 рекомендует принимать любую валидную RRSIG и считать RRset Bogus лишь при провале всех подписей. Более строгая локальная политика и разновременные кэши всё равно способны разойтись.

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

После DNSSEC решение всё ещё принадлежит приложению

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

DO запрашивает DNSSEC-данные, CD меняет режим проверки, AD при определённых условиях сообщает статус. Если канал от stub к рекурсивному резолверу не доверен или приложение статус не использует, один бит не становится сквозным доказательством.

Последняя квитанция называет выбранный резолвер, канал, полученный статус, правило приложения, принятое действие и наблюдавшийся эффект. RFC 9558 определяет новый объект; он не принимает это решение.

Источники

Источники