Кратко

  • DET использует 2001:30::/28 и является допустимым, но немаршрутизируемым IPv6-адресом. Такая форма задаёт иерархию идентификатора, а не сетевую точку назначения и не координаты.
  • HHIT RR типа 67 хранит регистрационные метаданные и канонический сертификат; BRID RR типа 68 содержит статические сведения Broadcast RID и endorsements.
  • DNSSEC проверяет DNS-ответ, тогда как живая позиция, нынешнее владение ключом, доступ к закрытым данным, состояние операции и юридические полномочия требуют разных доказательств.

На экране нет отметки от радара и нет записи местного радиоприёмника. Зато вся регистрационная цепочка зелёная: обратное имя ответило, HHIT и BRID найдены, DNSSEC проверен, сертификат и endorsements действительны. Автоматическое правило готово объявить аппарат обнаруженным.

Именно это правило добавляет факт, которого не было в данных.

RFC 9886 стандартизирует DNS-регистрацию и поиск DRIP Entity Tags, или DET. Наблюдатель может узнать иерархию идентификатора, его открытый ключ и подтверждения регистрации. Сервер имён не наблюдает воздушное пространство. Разрешение имени закрывает вопрос о записи в реестре, но не измеряет физическое положение.

Путаницу провоцирует формат. RFC 9374 выделяет DET префикс 2001:30::/28 и называет HHIT допустимыми, хотя и немаршрутизируемыми IPv6-адресами. Это позволяет использовать 128-битные структуры и механизм обратных DNS-имён. Пакеты по такому адресу к аппарату не направляются, широта и долгота в нём отсутствуют.

Обратная зона префикса — 3.0.0.1.0.0.2.ip6.arpa. Отдельный DET преобразуется с перестановкой полубайтов, как IPv6, но запрос касается типов HHIT или BRID, а не обычного PTR. Возвращаются метаданные идентификатора.

Две записи подтверждают разные утверждения

Каждый DET должен разрешаться в HHIT. Для UAS Remote ID дополнительно обязателен BRID. Это не два варианта одного статуса.

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

BRID RR типа 68 хранит статические данные из контекста Broadcast RID. Его главная функция — публиковать один или несколько Broadcast Endorsements, выпущенных регистратором после регистрации. Запись может дополнить статический материал, пропущенный по радио, или помочь сверке.

Наличие BRID в DNS не доказывает, что полевой приёмник услышал эту передачу в текущем полёте. DNS — канал публичного реестра. Broadcast RID — локальное радиособытие со своим приёмником, временем и дальностью. Одинаковое название не объединяет события.

RFC 9434 подчёркивает: самозаявленный DET ещё не доказывает личность отправителя. Старый подписанный материал можно повторить. Текущее владение ключом требует подписи новых, изменяющихся и внешне проверяемых данных—например, времени и позиции, совпадающих с реально наблюдаемым аппаратом. Но аутентификация сообщения всё равно не равна независимому измерению позиции.

DNSSEC проверяет ответ, а не небо

RFC 9886 требует DNSSEC для apex-сущностей с самоподписанным каноническим сертификатом и рекомендует остальным. Без DNSSEC ложные ответы могут поддержать отказ в обслуживании, replay, имитацию или клонирование аппарата, захват регистрации DET, подмену метаданных и нарушение доверительных связей. Клиент без DNSSEC обязан пройти дерево сертификатов HHIT; endorsements BRID проверяются отдельно.

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

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

Указатель на закрытый реестр не даёт доступа

Публичный DNS может указать адрес закрытой информации. RFC 9886 намеренно не задаёт механизмы аутентификации, авторизации и учёта, защищающие персональные данные. RFC 9434 относит к закрытому слою серийный номер производителя, идентификатор operational intent и другие регулируемые сведения.

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

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

У публикации и полёта разные часы

Публикация HHIT для DET раскрывает открытый ключ, необходимый для проверки подписей. RFC 9886 рекомендует, когда возможно, не публиковать запись до возникновения потребности. UAS или компонент UTM мог бы сообщать о скором начале или завершении операции с Specific Session ID.

Это полезная идея для сокращения экспозиции, а не готовый протокол жизненного цикла. Сочетание just-in-time публикации и DNSSEC оставлено за рамками документа. Отсутствие может означать отсутствие полёта, сбой публикации, дефект делегирования или политику. Запись может остаться после посадки. Автоматизация должна сохранять причину, а не придумывать единый оперативный смысл.

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

Источники