Resumo

  • O Working Group Last Call de draft-ietf-dnsop-integration-04 termina em 7 de setembro de 2026. O registro ainda mostra um Internet-Draft ativo de WG, com intenção Informational; não é RFC, aprovação do IESG nem ação da IANA.
  • A proposta distingue a prova necessária para criar uma integração das decisões posteriores de sincronização, suspensão e recuperação. Uma resposta sobre controle de domínio em uma data não é mandato permanente sobre uma identidade de aplicação.

O documento em consulta não opera uma plataforma

O texto trata de situações em que um domínio do DNS global vira handle, apelido visível ou outro identificador. Ele reúne cuidados com colisões, experiência consistente, segurança e resiliência. Em 24 de agosto, os chairs abriram uma consulta para saber se o grupo deve avançar com publicação, com encerramento em 7 de setembro. O Datatracker descreve a revisão -04 como In WG Last Call, prevista para Informational, com IESG state I-D Exists. Não há resultado de consenso registrado.

O próprio rascunho diz que não prescreve um mecanismo específico e não tem ações IANA. Portanto, não muda contrato de registro, não ordena um registrador, não escolhe regras comerciais e não determina o desfecho de uma conta. DNSOP pode expor perguntas operacionais. Quem mantém um serviço continua responsável pelas respostas que prejudicam ou restauram uma pessoa real.

Validar agora não administra o depois

A seção de Domain Control Validation propõe que somente o registrante ou parte autorizada associada ao nome consiga estabelecer a integração. Evidência em DNS ou em endpoint bem conhecido pode apoiar a prova. Ela responde a uma pergunta limitada: quem apresentou o sinal exigido no instante em que o vínculo começou?

Não prova propriedade econômica, identidade de uma pessoa, poder de representação, validade contínua de uma delegação de subdomínio ou direito infinito a uma conta. Um registro DNS pode ser evidência forte sem se tornar a constituição do produto que o lê.

O texto separa essa etapa do ciclo de vida. Expiração, mudança de DNSSEC e remoção de um registro esperado podem mudar controle ou status depois da integração. Ignorar isso pode deixar alguém que não é o registrante atual controlando o nome dentro da aplicação. Não se afirma que isso ocorreu em um caso particular. A conclusão é mais cuidadosa: evidência antiga não deve virar autoridade futura sem uma decisão visível.

Sincronização é uma escolha que distribui perdas

O rascunho pede mecanismos documentados para quando o nome integrado deixar de acompanhar o DNS global. Cita falha temporária, sequestro DNS, comprometimento de servidor e possibilidade de re-integrar o domínio. Mas não define frequência de checagem, momento de suspensão, prazo de graça, autoridade de recuperação ou resposta a uma disputa.

Essas escolhas distribuem danos. Suspender cedo pode impedir um ataque e afetar um titular em uma queda curta; esperar pode preservar continuidade e manter uma associação velha após mudança de controle. Por isso, a decisão pertence ao operador que pode explicar e corrigir o efeito.

Um recibo de ciclo de vida pode registrar o mínimo: nome, método e instante da validação, relação alegada, versão de política, próximo gatilho, tratamento de falha temporária, responsável pela suspensão, caminho de recuperação, aviso e canal de correção. Cada mudança recebe nova linha. Não cria uma autoridade global; mostra a autoridade local que agiu.

As demais orientações também têm esse limite. Não congelar listas de TLD, não excluir nomes tecnicamente aptos sem razão técnica e não tratar nomes Unicode como texto comum melhora o desenho. Não decide quem um serviço deve aceitar, qual identidade persistirá ou como uma controvérsia será resolvida. DNSOP documenta operação DNS e faz ligação com IANA; não administra a vida de contas alheias.

Fontes

  1. DNSOP Working Group Last Call
  2. Datatracker: DNS Domain Name Integrations
  3. Carta do DNSOP
  4. RFC 2826
  5. RFC 9499
  6. Lista IANA de TLDs