Кратко
- Homenet Naming Authority создаёт и подписывает публичную зону, сохраняет закрытые ключи DNSSEC и работает скрытым первичным сервером; Distribution Manager и публичные авторитетные серверы обеспечивают внешнюю видимость.
- Взаимная TLS-аутентификация подтверждает участников защищённого канала, но не право на домен, состояние DS в родительской зоне, полное развёртывание серии или внешнюю валидацию.
- Утверждение о действующей публичной зоне требует связать право, подпись, передачу, распространение, делегирование, наблюдение и отзыв одной идентичностью поколения.
Перенумерация как проверка архитектуры
Провайдер меняет выданный дому IPv6-префикс. HNA формирует новые AAAA-записи и увеличивает серию зоны. DM получает обновление. Часть публичных серверов уже отвечает новым адресом, другая часть — старым. Рекурсивные кэши сохраняют прежний ответ, а домашний резолвер продолжает разрешать имя локально.
Ни одно из этих наблюдений само по себе не описывает всю систему. Локальная работоспособность не доказывает свежесть публичной стороны. Подписанная новая серия не доказывает её распространение. Корректно кэшированный старый адрес может быть уже недоступен. Статус «успешно» без времени и поколения скрывает именно тот переход, который требуется контролировать.
RFC 9526 распределяет полномочия сознательно. Дом выбирает имена и подписывает утверждение. Внешняя инфраструктура получает и раздаёт его. Родительская зона связывает ключ с делегированием. Внешние валидаторы видят результат. Автоматизация должна соединять доказательства этих действий, а не подменять их одним сигналом.
Публичная зона не равна home.arpa
Документ относится к Public Homenet Zone под зарегистрированным доменом. Внутренняя зона home.arpa остаётся непубличной и не является источником для безусловного экспорта.
HNA может обнаруживать имена и адреса через DHCP, mDNS, UPnP, PCP или ручную настройку. Затем применяется политика публикации. Link-local адреса следует исключать. Частные адреса и ULA иногда полезны через VPN, но разрешаемое имя не означает доступность сервиса для любого пользователя Интернета.
Поэтому первый журнал должен хранить выбор: включённые записи, исключения, версию политики, автора решения и назначение. Одна итоговая зона не объяснит, было ли имя камеры опубликовано намеренно, попало из автоматического обнаружения или пережило удалённое устройство.
Имена несут и устойчивый риск приватности. Они часто осмысленнее и долговечнее адресов, могут раскрывать тип устройства и привычки владельца. NSEC3 и шифрованный перенос уменьшают некоторые способы перечисления, но не отменяют публичные запросы и анализ трафика.
Подписант остаётся дома, отвечающий сервер — нет
HNA создаёт всё содержимое публичной зоны и подписывает его DNSSEC. Она же управляет закрытыми ключами. Архитектура не предусматривает передачу закрытого DNSSEC-материала Distribution Manager.
HNA — скрытый первичный сервер. Его адрес не должен появляться в публичном NS без дополнительной защиты, а обычные запросы из Интернета должны обслуживать серверы DNS Outsourcing Infrastructure.
Такое разделение не даёт подрядчику самостоятельно создать новое аутентичное содержимое. Но подрядчик контролирует получение новой версии, её распространение и возможное сохранение старой, пока подписи действуют. Дом владеет авторством, а DOI — значительной частью публичной досягаемости.
Статусы должны быть раздельны. «Подписано» содержит серию, хэш, DNSKEY и интервалы RRSIG. «Опубликовано» содержит перечень наблюдавшихся инстансов, возвращаемую серию и время. Первое состояние не сертифицирует второе.
Каналы управления и синхронизации меняют роли сторон
В Control Channel HNA инициирует соединение с DM. Стороны взаимно аутентифицируются по TLS и обмениваются параметрами делегирования, DS и адресом синхронизации.
В Synchronization Channel DM становится TLS-клиентом, а HNA — сервером и скрытым первичным источником. AXFR или IXFR переносит зону. NOTIFY ускоряет проверку, а таймеры SOA позволяют вторичному серверу искать обновления без уведомления.
Даже при одинаковых адресах это разные свидетельства. Управляющая сессия подтверждает участников согласно правилу доверия. Передача конкретной серии требует привязки к содержимому и readback. Ни одна из них не показывает, что произошло во внутреннем контуре распространения DOI.
Сертификат HNA также не равен праву на Registered Homenet Domain. Устройство, доменная учётная запись и ключ DNSSEC могут иметь разных владельцев и сроки жизни. Аутентификация, полномочие, выполнение и внешний результат образуют цепочку, а не одно понятие.
Самый публичный канал определяется самим провайдером
DM принимает зону как скрытый вторичный сервер и передаёт её публичным авторитетным узлам. RFC называет участок Distribution Channel, но допускает AXFR, копирование базы, REST и иные реализации.
Это сохраняет совместимость с существующими платформами, но создаёт провайдерскую обязанность доказывать результат. Успешный HNA–DM transfer не является квитанцией от каждого узла. Anycast может скрывать регионы, версии ПО и независимые очереди развёртывания.
Для каждого поколения нужны данные о принятой DM серии, применении на целях, возвращаемых SOA и DNSKEY, а также явное правило кворума. Внешние пробы из нескольких сетей полезны, но не заменяют внутренний список узлов.
Точное утверждение звучит так: «DM принял серию 108; четыре точки видели 108, одна — 107». Оно сохраняет границу знания. Слово «опубликовано» без деталей стирает её.
NOERROR подтверждает обещание, а не родительскую зону
HNA передаёт хэш KSK в DS RRset. Если DOI связан с регистратором или реестром, он может изменить родительскую зону. DM отвечает NOERROR, принимая обязательство разместить DS.
Ответ относится к DM. Он не является чтением parent, завершением реестровой операции или истечением кэшей. Старый DS может сохраниться, полномочие аккаунта может оказаться недостаточным, несколько значений могут сосуществовать неожиданно.
Безопасное делегирование существует, когда дочерняя зона подписана, родитель содержит правильный DS и валидатор строит цепочку. RFC требует подписывать зону даже без возможности устроить безопасное делегирование. Следовательно, правильная подпись может быть отделена от публичного доверия.
Следует хранить отправленный DS, ответ DM, независимое чтение parent и внешнюю валидацию. Один флаг «DNSSEC включён» не показывает место разрыва при ротации.
Право на домен возникает до протокольной сессии
DOI не должен обслуживать зону, пока не уверен, что HNA владеет зарегистрированным доменом. При этом доказательство владения оставлено за пределами RFC. Управленческое основание предшествует техническому обмену.
Если DOI одновременно регистратор, основанием могут быть аккаунт и договор. Независимому DNS-провайдеру нужна отдельная проверка. Доменное право, сертификат Control Channel и ключи DNSSEC могут иметь разных хранителей и процедуры восстановления.
План миграции обязан указать, кто меняет parent, какая идентичность HNA управляет DM, какой ключ подписал активную серию и когда старый провайдер перестанет отвечать. Резервная копия зоны не восстанавливает управляющую личность, а новый ключ не передаёт доменное право.
Отзыв раскрывает остаточную власть
HNA должна уметь удалить делегирование у выбранного DM. Получив инструкцию, DM прекращает обслуживание зоны и может вернуть NOERROR как подтверждение удаления.
Но публичные копии, NS и DS в parent, а также рекурсивные кэши живут по собственным часам. При миграции старый и новый сервисы могут отвечать одновременно.
Квитанция отзыва наблюдает отсутствие: старый DM, известные авторитетные цели, записи parent, срок подписи, TTL и старт нового провайдера. Пока старая площадка видима, сохраняется остаток операционной власти.
Удаление неактивной HNA дополнительно регулируется коммерческим соглашением. Право клиента отозвать и право провайдера очистить заброшенную услугу — разные полномочия с разными сроками и процедурами спора.
Несколько часов одной смены адреса
При make-before-break старый и новый префиксы некоторое время сосуществуют. При резкой смене старый исчезает раньше нового. HNA должна обновлять адрес синхронизации при загрузке, поскольку не знает длительность простоя и срок действия подписанной зоны.
Желаемый адрес, серия HNA, копия DM, публичные копии, parent и кэши меняются неатомарно. Мониторинг должен измерять возраст каждой версии, а не только доступность. Старый адрес может корректно находиться в кэше и уже не работать; новый может быть опубликован раньше правила межсетевого экрана.
Локальное разрешение при сбое WAN повышает устойчивость и приватность, но может скрыть публичную проблему от жильца. Проверка должна выполняться и внутри, и снаружи, с явным указанием поколения и времени.
Источники
- Информация о RFC 9526
- RFC 9526 в HTML
- RFC 9526 в тексте
- RFC 9526 в XML
- Запись IETF Datatracker
- Запись API Datatracker
- RFC 9527: настройка имён Homenet
- RFC 8499: терминология DNS
- RFC 2136: DNS UPDATE
- RFC 9103: перенос зоны по TLS
- RFC 8446: TLS 1.3
- RFC 4034: ресурсные записи DNSSEC
- RFC 7344: обслуживание доверия делегирования
- RFC 8375:
home.arpa - RFC 7788: Home Networking Control Protocol
- Heng Lu: Reality Layers
- Heng Lu: Running-Code Primacy
- Heng Lu: Minimum Initial Specification
Источники
- https://www.rfc-editor.org/info/rfc9526
- https://www.rfc-editor.org/rfc/rfc9526.html
- https://www.rfc-editor.org/rfc/rfc9526.txt
- https://www.rfc-editor.org/rfc/rfc9526.xml
- https://datatracker.ietf.org/doc/rfc9526/
- https://datatracker.ietf.org/api/v1/doc/document/rfc9526/
- https://www.rfc-editor.org/rfc/rfc9527.html
- https://www.rfc-editor.org/rfc/rfc8499.html
- https://www.rfc-editor.org/rfc/rfc2136.html
- https://www.rfc-editor.org/rfc/rfc9103.html
- https://www.rfc-editor.org/rfc/rfc8446.html
- https://www.rfc-editor.org/rfc/rfc4034.html
- https://www.rfc-editor.org/rfc/rfc7344.html
- https://www.rfc-editor.org/rfc/rfc8375.html
- https://www.rfc-editor.org/rfc/rfc7788.html
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
