Кратко

  • RFC 8005 позволяет HIP RR хранить открытую Host Identity, её HIT и необязательные имена rendezvous-серверов. Это средство обнаружения, а не проверка жизни узла.
  • DNSSEC подтверждает DNS-данные внутри цепочки доверия, TTL задаёт срок повторного использования кэша. Они не наблюдают актуальную связь HIT с адресом в RVS и применение закрытого ключа.
  • Обоснованный статус соединяет выбранный RR, адрес и регистрацию RVS, пересылку I1, аутентификацию по HI, завершение HIP-ассоциации и результат приложения.

Зелёный индикатор пережил перемещение

В 09:00 резолвер получает HIP RR мобильного узла. HI, HIT и имя RVS ожидаемые, DNSSEC проходит, TTL равен часу. Система контроля записывает: «личность проверена, узел достижим».

В 09:12 узел меняет сеть. Обновление нового адреса не доходит до RVS. DNS при этом остаётся корректным: опубликовано прежнее имя rendezvous, подпись действует, кэш ещё можно использовать. В 09:20 инициатор отправляет I1, а RVS пересылает пакет по старой привязке.

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

Открытая часть ключа не подтверждает его наличие сейчас

RFC 5205 определил тип 55 в 2008 году как Experimental. В 2016 году его заменил Standards Track RFC 8005. Запись содержит открытую HI, производный HIT и, при необходимости, доменные имена RVS.

HI — открытая часть пары ключей; HIT — сокращённый хеш-идентификатор. Они помогают подготовить обмен и не начинать его без предварительного знания идентичности отвечающей стороны. В DNS-ответе нет закрытого ключа и нет свежей подписи, сделанной им при запросе.

Поэтому RFC 8005 рекомендует не аутентифицировать партнёра только по HIT из DNS, а применять аутентификацию на основе HI. Обнаружить опубликованный идентификатор и увидеть применение соответствующего ключа в текущем обмене — разные события.

Если реестр активов сразу ставит authenticated=true, он удаляет этап, который должен дать доказательство. Закрытый ключ может быть отключён, хотя открытые данные всё ещё опубликованы правильно.

DNSSEC усиливает узкое утверждение

Подмена незащищённого HIP RR позволяет заменить ключевой материал или перенаправить I1. RFC 8005 требует канал целостности и аутентичности данных и указывает DNSSEC.

Документ тут же ограничивает смысл результата. DNSSEC защищает данные между публикующим зону DNS-сервером и HIP-узлом. Он не гарантирует доверие к субъекту, публикующему зону. RRSIG набора HIP нельзя трактовать как сертификат связи HI или HIT с именем владельца.

Статус secure силён в своей области: байты, цепочка, якорь, время и политика проверки. Он не видит хранилище ключей, таблицу RVS, маршрут IP и процесс приложения.

Криптографическая надёжность не расширяет семантику. Безупречная подпись защищает ровно то утверждение, которое подписано, и не добавляет состояние следующих систем.

TTL относится к кэшу

RFC 8005 требует удалить HIP RR, когда время с момента получения превысило TTL. Если запись нужна для начала связи, необходимо выполнить новый запрос.

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

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

Автоматизация любит TTL за возможность вычислить срок локально. Но из cacheAge < ttl следует допустимость DNS-данных, а не endpointLive=true.

Имя RVS и таблица RVS — разные источники

Мобильный узел публикует сравнительно стабильные имена RVS в DNS и отдельно сообщает серверу текущие IP-адреса. RFC 8004 описывает регистрацию, которую RVS проверяет перед пересылкой I1.

Имя может правильно разрешаться, хотя записи для HIT уже нет. Сервер может отвечать, но хранить прежний локатор. Даже успешная пересылка не подтверждает, что конечный узел принял пакет.

Честная цепочка выглядит так:

HIP RR опубликован → DNSSEC проверен → TTL действует → RVS выбран → регистрация актуальна → I1 переслан → HI аутентифицирована → ассоциация готова → результат наблюдался.

Каждая стрелка пересекает границу наблюдения. Отсутствующий следующий чек означает «неизвестно», а не наследует зелёный цвет предыдущего.

Несколько RR требуют сохранить связь полей

Одному имени могут соответствовать несколько HIP RR; способ выбора RFC 8005 не задаёт. Данные RVS могут различаться. При нескольких вариантах узел обязан проверить, что используемый RVS связан с используемой HI.

Если вынести все HI в один список, а все RVS в другой, база создаст пары, которых зона не публиковала. Во время ротации старые и новые записи сосуществуют, и новая идентичность легко соединяется со старым маршрутом.

Квитанция должна хранить RR целиком: алгоритм, HI, HIT, RVS, TTL, отпечаток ответа и причину выбора. Иначе локальная ошибка проекции будет выглядеть как сбой протокола.

Из чего состоит доказательство достижимости

Нужны имя запроса, резолвер, авторитетный сервер, времена и отпечаток пакета; полный RRset и связи внутри него; результат DNSSEC, якорь и политика; момент получения, возраст, TTL и повторный запрос. У A/AAAA для RVS свои сроки и проверка.

Динамическая часть содержит ID регистрации, HIT, локаторы, обновление, истечение, отмену и поколение конфигурации. Далее связываются отправка I1, получение RVS, поиск, пересылка и приём узлом. Затем фиксируются HI-аутентификация и состояния обоих партнёров, а полезный трафик и результат приложения остаются отдельными ступенями.

RFC 8005 добавил ECDSA, уточнил повторный запрос после TTL, множественные RR и формат нескольких RVS. Публикация документа не подтверждает миграцию работающего бинарного файла. Нужны версия, сборка, конфигурация и пакеты.

Чёткая граница не обесценивает HIP RR. Правильная панель сказала бы: «RR безопасен; TTL действует; регистрация RVS не подтверждена; достижимость неизвестна». Это сразу направляет проверку к потерянному обновлению, а не к зоне, выполнившей свою задачу.

Источники