Кратко

  • Редакция 13 — активный DNSOP Internet-Draft с предполагаемым статусом Best Current Practice, не RFC, не одобрение и не свидетельство внедрения; Datatracker требует новую редакцию.
  • Совпавший Unique Token в специализированном DNS owner name связывает challenge с появлением записи, но не описывает все выданные полномочия.
  • Token expiry, TTL, cadence повторной проверки, application grant, update credential, CNAME delegation и domain-ownership epoch имеют разные сроки.
  • Отзыв завершён лишь после отрицательной проверки нового challenge, удаления DNS и кешей, остановки revalidation, отзыва credential и прекращения grant.

У удаления нет единственного момента

DNS Domain Control Validation автоматизирует узкую проверку. Провайдер выпускает Unique Token для пользователя и домена, пользователь публикует значение, провайдер запрашивает DNS и сравнивает ответ. Достаточная уникальность и непредсказуемость поддерживают причинную связь между выпуском и появлением.

Revision 13 рекомендует TXT под application-specific underscore label. Провайдер обязан сопоставить токен, который выдал именно для этого domain. Это полезный receipt: конкретная задача дошла до DNS.

Но удаление записи меняет только authoritative state. Resolver cache может хранить старое значение. Провайдер может проверять по расписанию. Уже созданный grant может не зависеть от дальнейшего DNS вообще.

Поэтому withdrawal — цепочка, а не timestamp. Каждый переход имеет владельца и наблюдаемое условие завершения.

Provider и service должны быть видны в имени

Специальный owner name предотвращает столкновение с hostname и показывает DNS Administrator, какой сервис просит доказательство. Generic challenge label лишает действие контекста.

При service confusion один сервис может выдать чужой challenge за свой. Пользователь публикует точный token, а полномочие получает другой provider. Matching корректен, intent подменён.

Provider, product и service должны быть однозначны. Разным scopes могут понадобиться разные application names. Public documentation объясняет, что разрешает record, на какой срок и как отозвать.

Account и resource details не обязательно публиковать. Protected authorization record содержит их и связывается с DNS через challenge ID и token digest.

Domain verified не определяет privilege scope

Контроль DNS может разрешать certificate issuance, mail, custom hostname, hosting, social identity или delegated validation. Радиус, persistence и reversibility различаются.

Challenge scheme не всегда различает narrow и broad scope. Если один match открывает несколько продуктов, DNS team выполняет решение, смысла которого не видит.

До публикации требуется readable statement: provider, service, account, domain, resource, scope, persistence, expiry, revocation. Approval относится к нему, TXT — к исполнению DNS шага.

Расширение продукта требует нового approval. Старое verified не является бессрочным согласием на новые функции.

User binding — отдельный контроль

Application user запрашивает challenge. DNS Administrator вносит запись. Intermediary может отвечать по CNAME. Resolver возвращает ответ. Provider создаёт grant для account.

Login не доказывает DNS authority. DNS authority не доказывает владение application account. Intermediary response не доказывает действующий договор.

Receipt хранит user/account, challenge, domain, owner name, token digest, provider, service, scope, issue/expiry, response, CNAME, policy, decision, grant ID. Missing join остаётся unknown.

DNSSEC может повысить доверие к ответу, но не добавляет product semantics. Сильная authentication пользователя не подтверждает informed approval администратора.

Несколько TXT требуют указать принятый

В одном RRset могут быть current, expired и unrelated tokens. Application specification может принять хотя бы один match. Лог «нашли» не показывает, какой.

Нужны exact RDATA, issued token, query time, TTL, CNAME chain и остальные values. Несколько character-strings конкатенируются; audit хранит canonical comparison value.

Expired tokens удаляют, уменьшая ambiguity, response size и amplification surface. Неизвестный owner очистки показывает потерю governance.

Expiry и revocation не совпадают

One-off record обычно не нужен после проверки. Provider сообщает validity и безопасное время удаления. Draft допускает expiry timestamp, never или out-of-band policy.

Token acceptance, DNS TTL, revalidation cadence, session, grant, update credential и ownership epoch — разные часы. TXT deletion не отзывает grant автоматически. Token expiry не отзывает возможность ответить на следующий challenge.

Closeout фиксирует token rejection, authoritative deletion, cache aging, stopped revalidation, credential revocation и grant closure. Для expiry=never нужны owner, justification, review date и withdrawal test.

Persistent validation — возобновляемое полномочие

CNAME может делегировать challenge intermediary. Persistent relationship превращается в repeated one-off validations без ручного DNS.

Тем самым одобряется future process, а не только current value. Registry указывает intermediary, final provider, allowed services/domains, accounts, credentials, duration, logs, review, exit.

Contract termination, CNAME removal, account closure и grant revocation происходят раздельно. Exit test выпускает новый challenge и убеждается, что старый path больше не отвечает, а existing grants прекратились.

Record presence не равно current intent. Vendor change, employee departure, account migration и scope expansion запускают renewal.

Domain transfer открывает новый epoch

Новый владелец может восстановить старый TXT из backup. Persistent validation способна представить это как продолжение доступа прежнего user.

Опаснее automatic reactivation старых resources. Текущий контроль domain не доказывает право на historical messages, configuration или secrets.

Provider создаёт новый ownership epoch, token и grant, изолируя previous resources. Legitimate transfer проходит отдельный recovery с дополнительными evidence и correction path.

Повторное появление строки не является титулом на цифровую историю домена.

Public suffix показывает настоящий масштаб

Validation на public suffix может затронуть множество tenants. Draft обычно рекомендует не принимать ownership для ICANN public suffix; private suffix может требовать дополнительных checks.

Возможность создать underscore child не даёт права представлять всех. Validator определяет registrable boundary, delegated zone и effective update authority.

DNS record относится к одному node. Application grant может охватывать широкую population. Разница должна быть видна до решения.

Integrity ответа и смысл разрешения различны

Authoritative query, DNSSEC и resolver controls могут укрепить доверие к наблюдаемому DNS. Они не говорят, какой service scope был одобрен.

Ясный scope тоже не исправит token от wrong domain. DNS receipt и authorization receipt должны совпасть по user, domain и transaction.

Query, CNAME, owner, TTL, time и security observation хранятся отдельно от account, resource, scope, grant и expiry. Green DNS позволяет продолжить authorization; не заменяет её.

Статус документа ограничивает вывод

На дату freeze revision 13 — active DNSOP Internet-Draft с intended Best Current Practice. WG state говорит, что после raised issue нужен revised I-D. RFC и IESG approval нет.

Источники устанавливают official text и threat model, не implementation, adoption, реальную service confusion, unauthorized certificate, takeover или incident. Opening — analytical construction.

Следующая версия может изменить требования. Следует хранить document version и policy version, а не вечный compliance badge.

Withdrawal receipt должен пройти всю цепь

До challenge сохраняются provider, service, user, account, domain, boundary, owner name, scope, persistence, token digest, issue/expiry. При validation добавляются response, matched RDATA, CNAME, resolver, DNSSEC observation, policy, decision.

При grant связываются resource, effective scope, grant ID, cadence, removal instruction, credential. При withdrawal каждый link получает отрицательное доказательство.

Domain transfer создаёт new epoch. Intermediary authority периодически renewed. Corrections добавляют state вместо удаления истории.

Service outcome остаётся отдельным. Validation может пройти, provisioning — нет. Работающий service может использовать прежний path.

Руководство должно определить момент завершения

Фраза «мы удалили TXT» описывает действие DNS team. Фраза «провайдер больше не доверяет этой authority» требует наблюдения provider и application.

Отчёт разделяет token matched, record removed, cache expired, revalidation failed, grant revoked и outcome changed. Тогда неизвестная задержка видна, а не спрятана.

Узкий факт сохраняется: live challenge совпал с observed DNS value. Длительность authority и её прекращение требуют собственных receipts.

Источники