Resumo

  • A revisão 13 é um Internet-Draft ativo do DNSOP com intenção de Best Current Practice; não é RFC, aprovação ou prova de implementação, e seu estado pede uma revisão nova.
  • Um token único encontrado no owner name correto sustenta um vínculo causal estreito entre emissão e presença no DNS, mas não descreve todo o privilégio concedido.
  • Rótulos específicos do provedor e do serviço reduzem service confusion e collision; a pessoa que altera o DNS precisa ver o escopo antes de publicar.
  • Registro persistente, CNAME delegado, credencial de atualização, grant do produto e mudança de dono do domínio têm ciclos independentes.

Um nome genérico transforma contexto em suposição

Validação de controle de domínio é um mecanismo simples e valioso. O provedor gera um Unique Token, o usuário faz o valor aparecer no DNS e o provedor consulta o registro. Se o token é único e imprevisível, a correspondência liga aquele desafio à alteração observada.

A revisão 13 de Domain Control Validation using DNS recomenda TXT sob um owner name com prefixo de underscore específico da aplicação. O formato evita hostnames comuns e permite ao provedor consultar apenas o espaço que lhe pertence.

O nome também carrega contexto institucional. Se dois produtos usam um label genérico, a pessoa que publica não sabe qual sistema consumirá a prova. Um matching correto pode fechar a transação errada.

Por isso o provedor relevante e o serviço autorizado precisam ser inequívocos. Aplicações com escopos distintos devem considerar nomes distintos. Documentação pública explica o poder obtido, a duração e a forma de revogação.

Service confusion preserva o token e troca a intenção

O draft descreve um serviço malicioso que apresenta o desafio de outro provedor como se fosse parte de sua própria entrega. O usuário adiciona o TXT pedido. O segundo provedor encontra seu token e concede autoridade. A sequência criptográfica está intacta; o consentimento não.

Service collision é o caso adjacente: um Validation Record mal delimitado serve a mais de um provedor ou serviço. O problema não exige quebra de DNS. Ele nasce da reutilização de um namespace e de uma explicação insuficiente.

A defesa combina nome específico, token vinculado à transação, escopo legível e conferência de usuário e domínio. Nenhum elemento isolado basta. O label identifica o consumidor; o token identifica o desafio; o contrato protegido identifica o grant.

Dados sensíveis não precisam entrar no DNS. Conta, resource e escopo ficam em um registro de autorização, ligado ao digest do token e a um challenge ID.

“Domínio verificado” esconde privilégios diferentes

Uma prova de controle pode permitir certificado, mail, custom hostname, configuração, identidade social ou validação futura por intermediário. Cada efeito tem blast radius, persistência e reversibilidade próprios.

Esquemas existentes nem sempre distinguem escopo restrito e amplo. Se o produto usa um match para liberar um pacote inteiro, a equipe DNS executa uma decisão cujo conteúdo não recebeu.

Antes da mudança, mostrar provedor, serviço, conta, domínio, resource, privilege scope, persistência, validade e revogação. O aprovador aceita essa declaração. O TXT demonstra a etapa DNS da mesma transação.

Uma expansão posterior de produto precisa de nova autorização. Não se deve reinterpretar um verified antigo como consentimento para uma função recém-criada.

A identidade muda em cada handoff

O usuário autenticado pede o desafio. Outra pessoa ou automação controla DNS. Um intermediário pode operar o CNAME. Um resolver retorna a resposta. O provedor associa o resultado a uma conta e cria o grant.

Login correto não prova autoridade DNS. Autoridade DNS não prova que a conta de aplicação é a certa. Resposta do intermediário não prova contrato vigente. Matching do token não prova resultado do serviço.

O recibo preserva user/account, challenge, domain, owner name, token digest, provider, service, scope, emissão, expiry, resposta, CNAME, política, decisão e grant ID. Um vínculo ausente permanece unknown.

DNSSEC, quando aplicável, melhora a confiança na resposta. Não fornece semântica de produto. Autenticação forte da conta também não mostra que o administrador DNS viu o escopo.

Múltiplos TXT exigem identificar o match

Pode haver vários TXT no mesmo owner name. O provedor confirma ao menos um conforme sua especificação. Valores correntes, expirados e de outros fluxos podem coexistir.

Guardar apenas “found” impede auditoria. Registrar a RDATA exata, o token emitido, o momento, TTL, CNAME e demais valores. Quando uma RDATA usa vários character-strings, a comparação ocorre sobre sua concatenação; o valor canônico deve ser preservado.

Tokens vencidos devem ser removidos. Isso reduz ambiguidade, resposta DNS e superfície de amplificação. Se ninguém conhece o owner da limpeza, a relação já escapou do governo.

Expiração do record e do grant são relógios distintos

Uma validação one-off normalmente dispensa o record após confirmação. O provedor deve explicar a validade do desafio e quando removê-lo. O draft permite metadata expiry com timestamp ou never, além de política fora do DNS.

Há mais relógios: aceitação do token, TTL, revalidation cadence, sessão, grant, credencial de update e ownership epoch. Remover TXT não revoga necessariamente o acesso já concedido. Expirar token não remove capacidade de responder ao próximo.

O closeout verifica token rejeitado, record autoritativo removido, caches envelhecidos, revalidação parada, credential revogada e grant encerrado. expiry=never exige owner, justificativa, data de revisão e teste de withdrawal.

Delegação persistente é autoridade renovável

Um CNAME pode levar o challenge a um intermediário. Assim uma relação persistente gera várias validações one-off sem mudanças manuais. O benefício operacional vem justamente da capacidade futura.

Registrar intermediário, provider final, services permitidos, domains, accounts, credentials, duração, logs, revisão e saída. Cancelar contrato, remover CNAME, fechar conta do intermediário e retirar grants do provider são ações diferentes.

O teste de saída emite um desafio novo após revogação e confirma que o caminho antigo não responde. Também confere que grants existentes perderam efeito. Um resultado sem o outro deixa autoridade residual.

A existência do record não é renovação de intenção. Mudança de fornecedor, employee departure, account migration ou scope expansion pede nova aprovação.

Mudança de dono inicia outro epoch

Um domínio pode ser transferido. O novo dono talvez recoloque um valor histórico a partir de backup. Para validação persistente, o serviço poderia tratar o usuário anterior como ainda autorizado.

Pior: nova validação pode reativar recursos antigos da aplicação. Controle atual do domínio não prova direito a mensagens, configurações, secrets ou dados do dono anterior.

O provider cria um ownership epoch novo. Token e grant são novos, enquanto recursos históricos ficam isolados. Transferência legítima exige fluxo separado, evidência adicional e correção possível.

Reaparecer o mesmo TXT não é título de propriedade do histórico digital. A associação anterior deve continuar auditável sem ser herdada automaticamente.

Public suffix amplia o alcance invisível

Validação no nível de public suffix pode afetar muitos tenants. O documento geralmente recomenda não aceitar ownership na divisão ICANN da Public Suffix List. Casos de private suffix requerem controles adicionais.

Capacidade de criar um filho com underscore não significa representar todos os usuários do suffix. O validator identifica registrable boundary, delegated zone e update authority efetiva.

O record fala de um node. O grant pode cobrir milhares de nomes. Essa diferença deve aparecer na tela de autorização e no receipt.

Transporte confiável não escreve o contrato

Consulta autoritativa, DNSSEC ou outras defesas podem aumentar a confiança de que o provider observou o DNS pretendido. Elas não informam qual service scope o administrador aprovou.

Em direção oposta, um escopo bem descrito não corrige token aceito do domain errado. DNS receipt e authorization receipt precisam ser verdes e compartilhar user, domain e transaction.

Guardar query, chain, authoritative owner, TTL, tempo e security observation de um lado; account, resource, scope, grant e expiry do outro. O primeiro permite continuar; não substitui o segundo.

O status do draft limita a narrativa

No corte de evidência, revision 13 é active DNSOP Internet-Draft com intenção Best Current Practice. Datatracker diz que uma revisão é necessária após issue levantado pelo grupo. Não há RFC nem aprovação IESG.

As fontes estabelecem recomendações e threat model oficiais, não implementação, adoção, confusão real de serviço, certificado indevido, takeover ou incidente. A abertura é cenário analítico.

Versões futuras podem alterar texto e requisitos. Registrar document version e policy version evita transformar referência provisória em selo permanente.

Um receipt de escopo acompanha o token

Antes do challenge, registrar provider, service, user, account, domain, boundary, owner name, requested scope, persistence, token digest, issue/expiry e explicação mostrada ao aprovador.

Durante a validação, guardar query, response, matched RDATA, CNAME, resolver, DNSSEC observation, policy e decisão. Após ela, ligar grant ID, resource, effective scope, cadence, credential e remoção.

Para persistent relation, renovar. Para domain transfer, iniciar novo epoch. Para intermediary, preservar a cadeia de quem emitiu e recebeu cada authority. Correções são novos estados.

O outcome vem por último. Matching não prova provisioning, uso ou benefício. Cada camada produz seu próprio receipt.

A liderança deve impedir que um label vire autoridade comum

Um único challenge namespace usado por muitos produtos economiza integração. Também cria common-mode authority: erro, confusão ou persistence atravessa todas as funções.

O desenho seguro mantém provider/service attribution no nome, scope no contrato, transaction no token, ownership no epoch e result na aplicação. A automação continua rápida sem fingir que uma query respondeu todas as perguntas.

O fato estreito permanece: um token de challenge ativo apareceu no nome previsto. Identidade do serviço, privilege scope, user binding, persistência e resultado precisam ser comprovados à parte.

Fontes