Кратко

  • Working Group Last Call по draft-ietf-dnsop-integration-04 заканчивается 7 сентября 2026 года. Это активный WG Internet-Draft с предполагаемым статусом Informational, а не RFC, одобрение IESG или действие IANA.
  • Проект различает доказательство для создания интеграции и последующие решения о синхронизации, приостановке и восстановлении. Проверка контроля домена в один момент не является бессрочным мандатом на идентичность приложения.

Last Call не является правилом эксплуатации

Документ предназначен для приложений, делающих глобальное DNS-имя видимым handle, псевдонимом или иным идентификатором. 24 августа chairs открыли обсуждение о продолжении публикации; срок истекает 7 сентября. Datatracker показывает версию -04 как In WG Last Call, с намерением Informational и состоянием IESG I-D Exists. Зафиксированного консенсусного результата нет.

Сам текст не предписывает конкретный механизм и не содержит IANA actions. Он не меняет договор реестра, не приказывает регистратору и не решает, какой аккаунт должна сохранить или заблокировать платформа. DNSOP может сформулировать эксплуатационные вопросы; ответ за вред и исправление остаётся у оператора приложения.

Проверка имеет дату

Domain Control Validation должна удостоверять, что интеграцию создаёт регистрант либо связанная с доменом уполномоченная сторона. Доказательством может служить DNS-запись или well-known endpoint. Это отвечает на узкий вопрос: кто предъявил требуемый сигнал при создании связи?

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

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

Синхронизация требует ответственного выбора

Проект предлагает документированные механизмы для несинхронизированного имени и упоминает временный сбой, DNS hijacking, компрометацию веб-сервера и повторную интеграцию. Он не выбирает частоту проверок, порог блокировки, льготный срок и орган восстановления. Эти параметры распределяют потери: ранняя блокировка может остановить захват и навредить законному регистранту при сбое; ожидание может сохранить старую связь после смены контроля.

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

DNSOP документирует эксплуатационные аспекты DNS и взаимодействует с IANA по DNS-реестрам. Это не делает группу оператором жизненного цикла чужого аккаунта. Рекомендации о TLD, Unicode и безопасном сравнении имён улучшают дизайн, но не решают, кого принимает приложение и как разрешает спор.

Источники

  1. DNSOP Working Group Last Call
  2. Datatracker: DNS Domain Name Integrations
  3. Устав DNSOP
  4. RFC 2826
  5. RFC 9499
  6. Список IANA TLD